In Engineering a Business Process Platform for Healthcare Part 1 - Support for Core and Context of my blog series I explored a way for organizations to meet the dual challenge of supporting increased efficiency and flexibility in basic support processes ("context") while at the same time better enabling innovation and new approaches that bring competitive advantage ("core"). I concluded that the platform approach could help solve this challenge - and promised to bring an example from the mid 50's. Well, here it is... 
For those of you who didn't know this car, Karmann-Ghia was quite famous at the time. The interesting thing is, that it shares the majority of the parts with the well-known Volkswagen Beetle. To me, this is an example for a successful adoption of a platform concept using a stable and robust core to "invent" or "specialize" on top of it. Put yourself in the shoes of the automotive engineers, and you'll see that they had to answer similar questions like today's business process platform developers: Which parts of the car should become platform elements? How to describe the re-usable parts? How big or how small should they be? How can we ensure that parts from different suppliers fit in and work together? Which skills and toolsets are necessary to build something on top of the platform? As you can see the questions are really common, but now let's take a more closer look at the answers... Which parts qualify for the platform?Very simple, those that we will need to re-use for our "new thing". At SAP we've decided to execute a two-way strategy to identify the re-usable parts (i.e. Services), outside-in by analyzing representative business processes in Healthcare and looking at industry standards like HL7 or IHE. Inside-out by leveraging our deep integration knowledge which we put into our products during the past decades. Plus, we're not doing this alone but take advantage of our strategic partnerships and, equal important, we work directly with our community. A Community Definition Group (CDG) consisting of Healthcare customers and partners is currently working on the re-usable parts in the area of Patient Administration - you can still join this one or one of the other working groups which we will kick-off later this year. How to describe the re-usable parts?Besides the more technical description of Services using an Common Standards - Security - Web Services Security (WS-Security) based registry, I think much value lies in explaining the full business context. SAP uses the Wiki format to provide business needs, integration points, scenario description as well as models (the value of models will be subject of my next blog) in addition the actual service description. The Wiki format allows additions or comments from the community, for example, the exchange of best practices or experiences with the services. For Healthcare, we have decided to offer our re-usable parts in the following bundles:Patient Administration, Medical Activities & Patient Billing, Medication & Material Management, Medical Documentation & Coding, Resource Planning & Scheduling, Resource & Supply Chain Management plus one bundle for Collaborative Health Networks. Expect the first Wiki based documentation for these bundles after the summer break. How big or how small should they be?In the past our interfaces (e.g. BAPI) were largely driven by the internal application data model. For example, to support an external admission workflow you had to use multiple BAPI's to search patients, create patients, create a case and so on. Enterprise Services in contrast, aim at supporting a whole process step. So they are usually less granular and hide more complexity. For example, the service "CreatePatientEncounterBasedOnAdmissionNotification" would not only comprise all the single operations listed above, but also handle the distinction whether it was a new patient or not. How can we ensure that parts from different suppliers fit and work together?Technically the Web Services standards ensure the interoperability between different vendors or applications. Semantic interoperability however, requires more and that's why SAP currently invest much effort in creating a semantic model that will be able to satisfy different viewpoints (Industry Standards for the Healthcare Industry like HL7, IHE, country-specific legal "standards", administrative vs. medical views etc.). Both, the right granularity as well as harmonized and standardized interfaces distinguish a "pure" web service from an Enterprise Service designed to offer optimal process support. Which skills and toolsets are necessary to build something on top of the platform?In order to truly fuel innovation and re-use, we need to overcome the traditional barriers. Too often, new ideas are simply to costly when using hard-wired programming technologies. Here's where composition offers tremendous help. Without writing a single line of code, you can compose an application in minutes or hours rather then weeks or months. And besides the gaining in time, it is important to note that nearly everybody, especially you as Business Process Experts can do it, even if you've never programmed before. In case you're not convinced yet, let me tell you that even Harald Pitz, our head of the Industry Business Unit created an application within minutes ;-)). For those of you who want to learn more, make sure that you check out all the information available in SDN and BPX. And of course, don't miss the Healthcare specific Easy-to-use, visually cool, and useful – That’s our Healthcare Management Cockpit, Stefan Weigand. My next blog will concentrate on the value of models in engineering a business process platform. I will share with you some insights of SAP's methodology as well as some outcomes already available.
For those of you who didn't know this car, Karmann-Ghia was quite famous at the time. The interesting thing is, that it shares the majority of the parts with the well-known Volkswagen Beetle. To me, this is an example for a successful adoption of a platform concept using a stable and robust core to "invent" or "specialize" on top of it. Put yourself in the shoes of the automotive engineers, and you'll see that they had to answer similar questions like today's business process platform developers:
2 Comments
