877-991-1991

Healthcare IT Blog

Architecture vs. Marketecture

Published on 01/29/2013 by Jim Fitzgerald
Category: Healthcare IT

One of the most common problems our consultants and engineers face when remediating a troubled technology infrastructure is DRG code 666.7890 Koolaidius Vendoratum Overdosensis.  It’s a fairly common diagnosis.  Hardware Vendor has cool new system.  Customer staff member likes cool new system. Customer staff member wants QZX-15 certification on cool new system to improve their negotiating position at the next review.  Customer staff member attends “lunch and learn.” Customer staff member attends “golf and gulp”.  Truck pulls up to hospital.  Cool new system is installed in volume, along with a whole bunch of ancillary hardware and software that may or may not add value to the overall solution.  Don’t get me wrong – we’re fun people at PPI. We like to travel, entertain, and interact just like anyone else – and we love technology – it’s our dominant gene. What we don’t like is when technology infrastructure design is mixed with vendor product marketing agendas, resulting in “marketectures”. Technology Marketecture is not Technology Architecture. “One size fits all” is for disposable hospital slippers and bathrobes.

As so often happens, the process outlined above begins with the best of intentions on all sides, but it gets skewed by issues with perspective. The hospital IT staffer in charge of the acquisition can sometimes get overwhelmed by the breadth and depth of the hardware vendor product offering. Similarly, it is likely next to impossible to expect the hardware vendor to understand everything there is to know about the needs and dependencies of MEDITECH, Fuji, Kronos, and the 40 other things they are likely to uncover in the hospital data center. As they work together to fit a solution to a problem, they may focus on one or two major pain points like capacity and scalability, for example, when the real issue that we find ex-post-facto bringing their system to its knees is poor design or implementation. Over and over again, the architectural process suffers from what I will call the rush to simplify. From the hospital IT staffer’s perspective, there are not enough hours in the day to balance their operational responsibilities with their strategic planning needs. From the technology vendors’ perspective there are quota pressures, pre-built solution templates, and a limited pool of pre-sales resources. Thus the rush to simplify overwhelms the need to embrace and manage complexity.

Managing complexity is, well, complex. It means taking the time to document specific issues with specific systems, to understand what applications can and cannot live together in a common VM cluster or storage pool, to understand that one application backs up and recovers differently then another, and to appreciate that from time to time you need a screw instead of a nail, or a steel I-beam instead of a 2X6.  This is part and parcel of why we choose to remain vendor neutral at Park Place International.  Nobody can solve everybody’s problems.  Sometimes a “single vendor solution” is the right solution, but more often, it’s a hybrid of technology, software, and services from multiple sources.  We don’t fit the diagnosis to the drug, we try to fit the drug to the diagnosis. There’s a lot of great technology out there, but in the immortal words of our local coffee chain here in the Northeast “What are you drinkin’?

Jim Fitzgerald is Executive Vice-President and CTO of Park Place International where he is responsible for technology solutions strategy, development, and quality spanning the entire Park Place portfolio of Technology Integration, Technical Consulting, and Cloud Services.  In his 28 year career, Jim has enjoyed the opportunity to observe and participate in the evolution of network computing platforms and their application to business and healthcare workflows.  His current passion is helping hospitals developing the right mixture of local and cloud-delivered services in order to achieve operational sustainability.



top