Part one of this series 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 a 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, and 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 UDDI 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 tip) 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 offer our re-usable parts in the following bundles:
- Patient Administration
- Medical Activities and Patient Billing
- Medication and Material Management
- Medical Documentation and Coding
- Resource Planning and Scheduling
- Resource and 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 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.
My next tip 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.
Claudius Metze is a Business Solution Architect in the Industry Business Unit Healthcare
This content is reposted from the SAP Developer Network.
Copyright 2007, SAP Developer Network
SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.
Want to read more from this author? Click here to read Claudius Metze's Weblog. Click here to read more about Business Process Management on the SDN.
