You are using an older browser that might negatively affect how this site is displayed. Please update to a modern browser to have a better experience. Sorry for the inconvenience!

Opinion: Digital Transformation? Start by Building a Service Platform

Unless you work for an organization whose business is technology, it fairly likely that the notion of software platforms (vs. applications, solutions, projects, etc.) might be somewhat abstract.  Having worked for a Fortune 500 technology shop, a Fortune 300 industrial, and now experiencing a variety of organizations in Healthcare as a consultant, I can say with certainty that the two perspectives are often quite a way apart.  In so many non-tech organizations, software simply equals applications.

As business leaders, we tend think of software in terms of applications that do specific things and, on occasion, in terms of that oh-so-expensive word, integration.  We go to a conference.  We see a great demo, and we focus on all the great features and the business problems solved.  Perfect.

Of course, we understand that it is not quite as simple as the vendor or consultant would have us believe.  No, we are not naïve.  We know we don’t have a green field and that functionality will have to be mapped to processes.   Old must be replaced with new.  Change management will need to play a big part.   We know that customization will be required, and we know we don’t exist on an island, and accordingly, that we’ll need data in and data out.  Integration must happen, and it will not be an easy task.   For all those reasons, we also know that when we hire our system integrator the bill will be high and the timeline long.

But, do we fully understand why these things are true each time we try to bring in a new application or build out a custom solution in our ecosystem?

Digital Transformation:  The Apps Are the Easy Part

Digital Transformation is all the rage in Healthcare today.  Patient Experience and Patient Engagement are two key areas where so many Healthcare Delivery Organizations are focusing their IT investments.  CRM, Patient Self-Service, Connected Patient Apps, and other new technologies are on seemingly every provider organization’s to-do list.  The number of healthcare organizations that have started taking on digital transformations in recent years is growing at an increasing pace.  However, like most industries, the results have definitely been mixed with common themes running through the list of challenges.

According to an IDG Research study, over half of digital transformation efforts are stalled or abandoned.  In that same survey, 64% of respondents identified Legacy Systems and Infrastructure as the top barrier to progress.  In the Healthcare world, that primarily points to EHR and Revenue Cycle Management.  Driven in part by regulation and government incentive, the last decade has seen mass adoption of EHR platforms by providers across the country – and with much success.  Much like the giant ERP and Order-to-Cash platforms found in other types of businesses, these EHR systems hold the key data at the core of the enterprise.  They are the systems on which operations occur and transactions get recorded.  Accordingly, they tend to be large scale (sometimes monolithic), difficult to change/upgrade, and not usually built with open integration in mind.

As a result, while there are myriad options for buying or building new digital capabilities on the front end of the digital transformation, making any of them work inevitably requires access to these crown jewel systems.  Stewards of these systems are rightly focused on stability.  After all, they are critical to the day-to-day operations of the business, and any disruption is unacceptable.  Integrating new systems at the pace desired to for innovation is unlikely to be supported – nor is it really responsible to the enterprise.

So, if this is the case, how can an organization ever reach the point where innovation becomes fast and new digital-age applications can be integrated efficiently into the ecosystem?

Where is the Platform?

The answer, surprisingly, has been around for quite a few years.  By isolating source applications with an abstraction layer and accessing them through services with well-defined interface contracts, we can effectively isolate the complexity of legacy systems and avoid solving the same integration problem over and over again each time we bring a new application on-line.   This architectural pattern is often referred to as SOA or Service Oriented Architecture, and its potential benefits have been well understood for some time as highlighted in this 2008 HIMSS report.

Does this mean we need to run out and implement SOA?  Of course, not.  What we are suggesting, however, is that we need to revisit our software ecosystem and ensure that we take a “platform” approach and make foundational investments to enable the outcomes that individual applications may provide.  Whether we build a full-blown SOA platform or just cobble together a well-designed set of services via an iPaaS (Integration Platform as a Service) vendor such as Mulesoft, the key is to have our foundational investments enable simple, vendor-neutral access to the capabilities of applications in our ecosystems – especially EHR, Rev Cycle Management, and other typically “legacy” systems.

So, how come we aren’t all further along?  As intelligent business people, we understand the value that foundational investments bring.   We get that investments in tooling make a factory production more efficient.  We get that documentation makes processes durable.  We definitely grasp the basic notion that when set out to construct a building, a platform (literally a foundation) in necessary order to make all the other elements stable and strong.  So why is that with modern software solutions – especially in an Enterprise context – do we so often overlook the notion of a platform?

A Mothership Is Not a Platform, Nor Does Integration Equal a Platform

But wait.  We DO already have a platform.  Those legacy systems are themselves platforms, no?  We run our business on Oracle E-Business Suite or SAP or some other behemoth of an ERP.  We’re a Cerner or an Epic shop.  Our EHR is our platform.  After all, the vast majority of our staff uses one more of the various modules, and it is a foundational piece to our operations.   All true – but none of this suggests the existence of an agility enabling platform in our IT ecosystem.

Well, it’s not just the ERP or the EHR, we say.  We have also purchased middleware technology (maybe even an iPaaS solution), and many of our applications are integrated together.  We have ETL process.  We use web services.  Did you hear me?  Web. Services.  We definitely have a platform…  Don’t we?

Nope.  Not quite.  Middleware technology is definitely an enabler (and certainly a platform by strict definition) that might even be considered a prerequisite to a functioning platform for our purposes, but it is not quite sufficient on its own.


OK, So What Do You Mean by Platform?

So, for our purposes, a Platform is a foundational set of software services that enable rapid integration of new technology into the ecosystem and provide several key characteristics:

  • Simplicity – By organizing services in functional, business process-related manner and executing any cross-application complexity within the service layer, a platform allows custom application developers and new third-party apps to “blindly” request the information and services they need without having deep knowledge of the ecosystem.
  • Loose Coupling – By removing vendor-specific concepts in the interface (i.e. talking to EHR vs. talking to Cerner) and executing any mapping/translation in a service layer (rather than in any application), platforms help avoid vendor lock and enable rapid change in an integrated world.
  • Common Protocol / Methodology – The platform dictates the available protocols (REST vs. SOAP) and methods (file vs. table/view-based batches), service granularity, and service availability (which applications/users are allowed and how much). This greatly lowers the cost of operating the platform and creates economies for developers and integrators as well.
  • Accessibility – By organizing services in logical manner and centralizing access to all services to a single location, the platform makes the various data and services for the whole ecosystem more accessible to developers and integrators.

Using a simplified Healthcare ecosystem as an example, here’s what such a platform might look like at a conceptual level:


Like the picture describes, our ideal case is a well-design service platform – an exercise in abstraction.   At the heart is indeed a middleware platform that provides for common framework (protocol, methodology, security, policy).  On top of that, each organization layers well-designed services that adequately abstract away the vendor-specific implementations of each application.  This often means even having to abstract on top of well-standardized interfaces such as FHIR.  Often even if the interface is standardized, semantic translation is still required to arrive at a vendor-neutral language which all applications in the ecosystem can speak.  These elements in place, the platform presents coherent, easily understood APIs to developers and integrators who in turn can rapidly add new capabilities to the ecosystem.


Why Don’t We Have A Platform (or At Least a Better One)?

It really does seem logical – to have a platform that is.   And, in fact, most organizations have had multiple iterations of platforms that may or may not have persisted through technological and organizational change.  However, it is all too common to find ourselves without a platform that adequately meets our needs and conforms to the definition we discussed above.   Why?

There are probably many old adages that end with a similar punchline, which goes something like, “if you want to know why, just follow the money”.  Just.  Follow.  The.  Money.  Indeed, there has rarely been a statement proven true so often.

ROI Is Not Always Your Friend

Most organizations, regardless of size, engage in relatively rigorous planning for any significant projects. Appropriately, pretty much all of them require analysis of Return on Investment (ROI).  After all, businesses must exercise fiscal responsibility.  ROI is typically calculated based on the assumed changes that the project will deliver with well-understood benefits starting at go-live.  However, in the case of software platforms, the benefits are only conceptually understood.   We know that the platform will improve our ability to introduce new technology into the ecosystem quickly.  We know it will reduce the cost of integration.  We know we will be more agile.   We may even know by how much.  However, because the realized benefits are predicated on future projects that have not occurred yet, we can only provide ROI in terms of assumed future investments.  In other words, we can’t know with certainty how much the platform investment will return or when it will do so.  That is a challenging business case for anyone to make.

Compounding this problem is that most funding for major IT projects are driven by functional business areas.  This makes a lot of sense since it is the introduction of a capability into their business area that will produce the measurable change that drives ROI.  However, from a platform standpoint, it creates interests that are not well-aligned.  Business stakeholders are rightly concerned about their own business.  They are not interested in spending additional dollars that may serve the greater good at some point in the future while driving down their own ROI today.  Even when they understand and support the notion of platform building (with funding), the interests are often compromised during the project as scope or timeline considerations put platform building in the back seat.


What’s an IT leader to do?

IT leaders want to be good partners.  We all want to help transform the business and make tangible contributions.  No one wants to the roadblock or source of friction that impedes progress.  However, sometimes the state of IT ecosystems places IT leaders in challenging situations as the tide of requirements for new applications and technologies continues rise.

What IT leaders really need is to get is a larger allocation of capital spending for “Tech-for-Tech” investments – such as service platforms.  We want to invest more in the foundation and tooling that will enable to IT be to a more nimble and responsive partner as the business’ innovation needs accelerate.  However, as discussed above, there are some common structural challenges that make such an allocation of investment unlikely.  So, what is a good IT leader to do?

Nothing, Head-On Confrontation, Subversion – All Bad Options

Well, of course, we can always do nothing.  We can continue to have challenging, often delayed projects  that incur more and more technical debt.  We can let the web of point-to-point integrations and one-off solutions further impair our ability to respond to changing needs in timely fashion.  This happens surprisingly often and can persist for quite some time.  Yes, it’s unhealthy, but when it’s status quo, the motivation to change tends to be muted.

We can also apply our trade and make the logical arguments up the chain.  After all, there is a “right” way to do it, right?  We can confront business leaders head-on and argue for foundational investments to take priority over functional projects.   We can take a hard line with consultants and vendors who do not conform to IT governance and do not flex their designs to accommodate our long-term interests.  Perhaps some victories will be won, but typically, these types of tactics end up with poor outcomes.

There is always the option of subverting company processes and redirecting funding solely at the IT leaders’ discretion – of course, for the greater good.  However, that is an approach that is almost certain to catch up with the responsible parties quickly as projects come in late or under scope.

There are more practical strategies available, of course.   They tend to require a longer window to play out, but they also have much better overall outcomes.

IT as a Vendor:  Earn Credibility through Service

As noted before, part of the challenge of funding foundational projects is that ROI is theoretical – always removed at least by one degree.  Benefits cannot be realized until a project that utilizes that foundation is funded and executed.  As such, the business case for the foundational investments is much harder to make.  In head-to-head comparison with competing funding requests whose ROI is direct, there is no way to win the mathematical argument without a ton of assumptions being accepted, and when decision makers are asked to accept assumptions (i.e. risk), the credibility and perception of alignment with company strategy of the requestor becomes a practical consideration.

So, how do we maximize credibility?  IT leaders need to behave like those who have to develop strong credibility just to survive:  vendors.  This is a very difficult task if the culture is not already aligned, as the change is as much about culture and staff mentality than executable tactics.  Despite the captive customer, IT leaders must instill the same customer-orientation and urgency that good vendors must have.  They must consider the business their true customers rather than merely other, less technical, departments.

To deliver the type of service and relationship that generates trust and credibility, the IT organization from top to bottom must be focused on:

  • Commitments and Expectations – Commitments must be made responsibly and held as sacrosanct, with above-and-beyond effort to ensure promises are kept. Along the way, expectations must be carefully managed – no surprises.
  • Optimistic Posture – Can-do has to be the mentality and the message conveyed. Justified or not, IT shops at large are often viewed as being more interested in how something can’t be done rather than how a vision can be brought to fruition.  A positive and enthusiastic approach – or at least an open-minded posture – when discussing requests goes a long way.
  • Consultative Sales – IT leaders must be partners in solving problems with their business counterparts. They must approach from the business’ perspective, offer meaningful input/advice, and actively “sell” their solutions (not just identify cost and time of others’ solutions).
  • Responsiveness and Urgency – From basic helpdesk tickets to the most critical capital projects, IT staff engaging the business (Technician to CIO) must be responsive. Business requests have to be treated with urgency.  SLAs should be beaten, not met.

These things may or may not be foreign to a given IT organization, but they common to nearly all successful vendor organizations.  Taking a page from their external partners is the best way to raise IT credibility with stakeholders (i.e. budget holders) and build a strong relationship where trust and credibility become implicit.

When the relationship becomes strong, IT will be perceived as top-notch service provider and indispensable partner.  At that point, the Head-On approach becomes practical, and it becomes far more likely that funding for foundational investments will be supported.

Strong Architecture and Good Partners

Of course, there are things we can do in parallel.  We can take small-steps and leverage the reusable portion of work from each project to build a platform one block at a time.  Conceptually, this makes great sense and seems wonderfully simple.   However, this is surprisingly difficult in practice.  Each project has its own timeline pressures and resource limitations.  Project teams are often ephemeral in nature, so there may not be contiguous vision at the execution level.   As a result, we end up with the opposite of what we desire.   We get complexity, lack of reusability, and proprietary configurations (vendor lock).

To avoid this outcome, IT leaders need to practice high-discipline in two key areas:  Architecture and careful Partner/Vendor Selection.

A strong architecture practice – preferably with gated design governance processes that intersect projects – ensures that new development and implementation into the ecosystem conforms to the vision and roadmap for the IT ecosystem.  By governing designs (and thus new engineering activity), Architecture ensures that a platform evolves over time in a manner that supports reusability, loose-coupling and proper abstraction, consistency, and other desirable characteristics that will make the organization progressively more stable, responsive, and nimble.

The other key component necessary to build up a platform over time is the careful selection of partners.  If you’ve worked in internal IT long enough, you are sure to have a story or two to share about being “run over” by a consultant or technology vendor.  We’ve all experienced the story.   A high-end consultant engages the business (budget-owner), and a technology project is chartered.  As the project proceeds, you realize that any measures of governance and standards that you have put into place as a technology organization are suddenly negotiable – even optional.  The consultant, motivated to deliver efficiently and meet timeline goals to which they have committed, pushes hard to do things “their way”.  And, in fairness, as experts, they are charged with sharing and advocating their best practices.  Unfortunately, they often suffer from “greenfield syndrome” – acting as if each project is delivered into a new environment without the complexity that legacy brings.   The inevitable result is delay, change orders, and even failure – for which root cause is often identified as IT being a barrier.

IT Leaders, to the extent they can control or exert influence in the selection process, must take into consideration the characteristics of the vendor and the relationship dynamics.  While competency and value are still the main drivers, they are focused on the short-term objectives of the specific project.  For the long-term interest of the organization – specifically the evolution of platforms – IT leaders need to seek partners who are knowledgeable, but flexible and focused on long-term partnerships.  IT should advocate for a model, regardless of vendor and selection process, where the vendor is a subcontractor to IT, who is effectively the prime vendor providing a service to the business.  When interests are aligned in this manner, and the vendor is flexible and interested in influencing, but still adapting to the IT organization’s standards and processes, we can ensure that design decisions in each project will contribute to the steady growth of platforms and alignment to long-term vision.

Perfect Worlds Do Not Exist.  Start Somewhere.

As most Healthcare IT leader have experienced in recent times, the demand for Digital Transformation in its various incarnations is here.  Every day business leaders’ needs to innovate with new capabilities and new applications increases.  The pressure will not be dissipating anytime soon.

While it would be ideal to freeze as much change as possible and focus on building out a strong platform.  However, a 6-12 month halt to functional progress is unpalatable to most businesses.  Also, as discussed above, dedicated funding toward significant foundational projects is unusual.

IT leaders are best served to take whatever steps they can, using the strategies available to them (such as those highlighted here), and direct investments toward building coherent platforms that will improve agility and ease the challenges of future innovation.