- This topic has 8 replies, 6 voices, and was last updated 10 years, 9 months ago by
.
-
Topic
-
-
Replies
-
-
-
I have this discusion from time to time with upper management to no significant avail probably because we seem to keep finding a way to get it done.
I personally think I would like the ratio of 1 integration engineer for every 100 interface threads but doubt I will ever see that day working here.
We don’t even come close and I can tell you that what we do with so few people is insufficient.
We have a 6 person integration team that just compeleted upgrading to Cloverleaf 6.0 and have 1,563 interface threads altogether (908 in TEST and 655 in PROD) and have 6 million messages a day flow through PROD.
That comes to 260 interface threads per person, which by my measure means we would need to add 9 or 10 more people to get to my desired ratio today.
Here are some reasons we can still tread water:
– I do much of our own system admin like LPARs, file system layout, HA architecture, FTP access and user IDs, etc., so I have more controll of what impacts us
– we do scratch installs of cloverleaf on clean LPARs when doing upgrades and activate one site at a time so no more in place big bang
– good longevity and stability on our integration team (10 – 15 years for most of the team members), which creates tremendous site specific depth of understanding
– strong team mentoring and synergy
– telecommuting for better 24×7 coverage
– standards and methodologies and multiple sites with some change control guidelines
– TCL procs are argument driven and reuseable
– we avoid writing TCL procs if the work can be done in the xlate
– we have some highly expereinced and adaptable people on our team that get alot done, so loosing even one of those might need 3 or more people to replace them
We are about to start the EPIC project and I’ve been told to expect an addition of 2 people, even though the number of interface theads I anticipate will perhaps double because they want additional environments besides just TEST and PROD.
The trend has been about how to be creative enough to do more with less.
I still believe doing it right instead of doing it over saves time and frustration in the long run but I’m being worn down more these days on that point, too.
One person on our team used to make me laugh by saying the following, but I’m not lauging anymore:
“We the unwilling,
led by the unknowing,
have been asked to do so much,
for so long,
with so little,
that we are now prepared to do anything with nothing.”
Oh yeah and we rotate the on-call pager amongst us each week.
We are literally being worked to death.
Strangely enough we telecommute alot even though not widely popular because we can get so much more done that way, so keep that in mind as a way to increase productivity.
However, be careful what you wish for because telecommuting will make it easier to work 24×7 with only naps.
Another thing a team mate told me the other day I found entertaining, “You can’t get gunfighter wages setting in the saloon.”
I can see his point but if I have to gun down 3 people at least put 3 bullets in my gun not just one bullet.
Russ Ross
RussRoss318@gmail.com -
What do people count as an interface? A Cloverleaf thread? The unique combination of source thread/destination thread? The unique combination of message types/source thread/destination thread? Or…?
Just curious. I have only counted threads but have wondered if others were using more interesting/accurate metrics.
-
Good question worth clarifying because some people call an integration an interface. I consider an interface what we call a thread in cloverleaf, which can be one sender or one listener.
The reason I count interfaces/threads is because that is quantifiable without interpretation and potentially represents a failure point the integration engineer has to support.
When it comes to what is an integration I’ve seen a varity of interpretations ranging from
1) a single pair of sender/listener interfaces
2) the entire pathway from a source system through cloverleaf to a destination system
Since I want to avoid the inconsistant interpretations, I prefer to stay with measuring the more basic unit of work at the interface/thread level.
Russ Ross
RussRoss318@gmail.com -
Here at McFarland Clinic, two of us handle Cloverleaf and Epic Bridges with production traffic in the 700K/day range. With Epic you can wind up with many environments, but we only interface to four of them (PRD, TST, REL, BLD). For Epic version upgrades we create additional environments with interfaces. We each have 10+ years experience.
Bill – we look at thread count, but if you’re talking traffic volume we use outgoing message counts.
-
-
I count interfaces based on message types: ADT, ORM, ORU, etc … You can have one thread for a vendor that receives ADT and orders on it, that’s two in my book, not one.
Another example is that we have an Epic inbound charge interface that receives charges messages from 4 sources. That’s 4 total, not 5, and certainly not 1.
Any localhosts in our sites do not count.
-
Here at Henry Ford Health we have 9 interface resources, with varying levels of skillset. Prior to our Epic implementation we had 4 resources, but as we are implementing Epic across the health system, we needed to increase staffing to handle the re-development of the interfaces with Epic.
We have 350+ interfaces across 5 hospitals, processing about 4 million outbound transactions daily.
Russ, I think you are definitely understaffed in terms of your Epic implementation. When you consider that you will be re-developing a majority of your interfaces, you will certainly require additional staffing. All of those existing interfaces were likely developed over time, so you were able to get the job done with the staffing that you have, but now you will be re-developing them in a very short time-frame.
One of the things that we ran into here at HFHS is that our Epic implementation is primarily staffed by operational resources rather than IT. So, when things come up that require an “IT mindset”, the interface team has become the “Face of IT” and we get pulled into things that are not interface related.
With respect to “what is an interface”, I concur with Michael’s methodology in that the type of data further defines an interface rather than just a pure thread count.
Thanks,
Jim Cobane
Henry Ford Health
-
- The forum ‘General’ is closed to new topics and replies.
