The concept of On Demand Business fuses business and information technology (IT) to create new opportunities for enterprises to become faster, more responsive and more profitable. The most valuable thing you can buy yourself as an organization these days is flexibility — flexibility to meet new market demands and seize opportunities before they’re lost. To increase flexibility, businesses are looking at themselves as a collection of interconnected functions — discrete processes and services, such as sell covered option, check customer credit or authenticate user — and then deciding which of those functions are core or differentiating, and which can be commoditized or even outsourced. If you can mix and match these functions at will, you’ll have a tremendous competitive advantage in the marketplace. It’s a powerful idea. But to achieve this degree of flexibility in your business operations, you need an equally flexible IT environment. You need an environment that can take full advantage of both your legacy systems and the latest technologies. You need what’s called a service-oriented architecture, or SOA.
Changing to a service-oriented architecture wouldn’t be practical if there were no way to access and use your legacy applications and technologies. An SOA’s capacity to integrate existing systems and provide access to legacy data is one of its primary appeals. Many large enterprises are characterized by disparate and siloed systems and applications — horizontal integration has become the goal of businesses seeking greater agility in the global marketplace.
An SOA using open standards such as Web services can be an ideal way to link existing systems with one another and with new technologies. Using industry standards allows you to reuse existing software components. This means that integration is faster and easier. Open standards also allow you to quickly and efficiently leverage innovation developed in one part of your organization and disseminate it across the enterprise. This helps prevent unnecessary duplication of effort, increase the business value of innovation and create an incentive for innovation itself. Service-Oriented Modeling and Architecture facilitates integration with techniques for analyzing legacy applications, custom and packaged, to identify, specify and realize services for use in a service-oriented architecture. It breaks out the business functions of each existing application, identifying candidate services that can be used to realize business goals under the new architecture. It also identifies potentially problematic areas and highlights areas where new services need to be developed or sourced from an external provider.
But when it comes to start the “real SOA” project; a lof confusions and challenges might come to the mind of a customer. Here I’ll try to list the frequently Asked Questions from a customer point view on service modeling:
1. Do we need a corporate object model? How do we develop one?
2. Can we use the SAP object model as a starting point? How do we get access to SAP's object model?
3. Do we need corporate data standards? How do we develop those?
4. How do we develop the corporate services registry? What taxonomies should we use?
5. What is the appropriate granularity of services? How do we best orchestrate services?
6. How do we use industry standards for interfaces?
7. How do we use existing SAP interfaces? That so many questions are related to modeling should not come as a surprise; after all, abstract object and service modeling is new to many of SAP's customers. However, the need for modeling could become a source of concern for SAP and our customers because qualified resources that are trained and experienced in that area are scarce. This is one reason why SAP needs to work these new approaches into its methodologies and get consultants trained in them.
Conceptual Approaches:
There are a number of approaches that should be applied to these new implementation projects. First, we have to remember that the Enterprise SOA is a concept or a blueprint that should be used to guide long-term, not short-term project deliverables. Implementing an eSOA is an evolutionary process. Implementing SAP NetWeaver will not automatically give us an eSOA, nor is a full-blown implementation of SAP NetWeaver a prerequisite for an eSOA.
As stated above, the key to the eSOA is the abstraction of business events from the underlying applications. This is what allows us to decouple business innovation from system consolidation. In the early phase of implementing an eSOA, this is mainly affecting the design-time efforts more than the run-time environment. The abstraction can be achieved using a modern application server (such as the SAP Web AS) as the provider of enterprise services and the consumer of application services. The orchestration, mapping, and data transformation needed can be implemented in code on this application server. Later we might of course want to move to a full integration platform to achieve higher flexibility at lower cost, but much of the design-time modeling work can be done before that.
The customers' questions around modeling therefore need to be addressed before the implementation project is planned in detail.
1.1.1 Do we need a corporate object model? How do we develop one?
The corporate object model plays an important role in achieving the desired abstraction, so we will need one. Using a corporate object model as the basis for a canonical message format helps reduce complexity and the number of mappings required. However, it is very important to understand that we do not have to first develop a complete corporate object model before we can start an implementation project. The recommended, pragmatic approach is to start with a few key objects, and at first only model the core attributes, i.e. attributes that are relevant to most or all applications. Over time, the model will be enhanced in two ways: New objects are added and existing objects are expanded. Whenever we need to map interfaces for which we have not yet modeled the objects, we do this in a point-to-point fashion. How this fits into the overall implementation project will be discussed below.1.1.2 Can we use the SAP object model as a starting point? How do we get access to SAP's object model?
It is quite common for the SAP applications to be the dominant ones and also the strategic application platform of the customer. If this is the case, it makes sense to use at least parts of the SAP object model as a starting point for the corporate object model. That way, the effort and potential data loss involved in mapping the corporate objects to SAP objects is avoided. The SAP object model is available in the Business Object Repository, known as BOR. Currently no standard functionality for export of the object model into popular third party modeling tools such as Rational Rose exists, but the function group SWOR contains well-designed, easy-to-use, RFC-enabled function modules to access all relevant parts of the BOR.1.1.3 Do we need corporate data standards? How do we develop those?
Corporate data standards define how individual object instances are identified across all applications in the system landscape. If we do not implement corporate data standards, we will have to perform point-to-point data mappings between applications, even with an object model in place. How we should develop the data standards highly depends on the specific customer situation. For each object type, we can check whether suitable industry standards exist or whether we can identify an application that clearly "owns" this data.1.1.4 How do we develop the corporate service registry? What taxonomies should we use?
Even if we initially only have a few services available in our system landscape, we should start managing them in a corporate service registry. This registry should definitely be UDDI-compliant. We recommend using at least three logically separated registries: One for the application services available for enterprise services development, one for enterprise services available within the company, and one for enterprise services available outside the company. Whether the separation is achieved by using separate registries or by using a taxonomy has to be decided in each project.
When developing the corporate service registry, we need to ask ourselves how we want to organize the services, i.e. what taxonomies to use. Most likely the main use of the registry will be at design time, when a developer is looking for services to use. Therefore, we need one or more taxonomies that support the way a developer thinks about services. Useful taxonomies can for example be built around data objects and around application hierarchies.
For example:
Objects
Master Data
Employee Service: Get list of employeesService: Get details of employee…
Work CenterService: Get list of work centersService: Get details of work center…
Transactional Data
Production OrderService: Get list of production ordersService: Get details of production order…
ApplicationsHRService: Get list of employeesService: Get details of employee…ERPProductionService: Get list of work centersService: Get details of work centerControllingService: Get list of production ordersService: Get details of production order…
For the longer term service management and maintenance, it usually is helpful to have one taxonomy that reflects the organizational ownership of the services.
1.1.5 What is the appropriate granularity of services? How do we best orchestrate services?
The question of how to define a service and what services to use within the company is crucial. Finding the appropriate granularity is key: The more fine-grained the services are, the higher the degree of re-use possible. But this also requires a lot of logic in the orchestration. Please note that when we use the term granularity, we do not (only) mean the size of the interface, but rather on what level of detail the service supports a business process. A first principle is that each enterprise service, if at all possible from a business standpoint, should have an off-setting service that undo's the action of the original service. A second principle is that each enterprise service should be idempotent, i.e. that it performs an action exactly once no matter how many times it is called. Taken together, these two criteria give us pretty good guidance in a pragmatic approach to defining the granularity. If we also take into account that the definition of an enterprise service means that it corresponds to a business event, we will be able to identify a set of fairly coarse-grained services that are still reusable as our enterprise services. The enterprise services will typically be orchestrated out of application services. Service orchestration can be done in many ways: In a first step we might use coding in the Web AS to call the necessary application services and implement the logic to create the enterprise service. Later we will use the business process management capabilities of XI to do this. Whatever technology we choose, we probably want to implement some form of transactionality, so that the enterprise service becomes an atomic transaction. To do this we need some form of rollback. Since two-phase commit and similar approaches are virtually impossible to implement across existing applications, we need to take a more pragmatic approach using off-setting services and/or manual workflows.1.1.6 How do we use industry standards for interfaces?
If meaningful industry standards exist for the interfaces of our enterprise services we should strive to use them, also for internal application-to-application communication. If the industry standard interfaces are not sufficient for the internal communication, we should extend rather than modify them. At a minimum, when we define our service interfaces we should use the building blocks defined in UBL, the Universal Business Language (Universal Business Language is a library of standard electronic XML business documents such as purchase orders and invoices. UBL was developed by an OASIS Technical Committee with participation from a variety of industry data standards organizations. UBL is designed to plug directly into existing business, legal, auditing, and records management practices. It is designed to eliminate the re-keying of data in existing fax- and paper-based business correspondence and provide an entry point into electronic commerce for small and medium-sized businesses).1.1.7 How do we use existing SAP interfaces?
All the BAPIs and RFC-enabled function modules of SAP ERP are available as Web services as of any application built on Web AS 6.20 or later. For older versions of SAP applications, we can use RFC as the communication protocol between the integration platform (Web AS, XI, …) and the application. However, not all existing SAP interfaces are suitable to be used as enterprise or even application services. We recommend a dual approach to turning the SAP interface into a service: If the interface will be used as an enterprise service, the transformation should take place in the integration platform. If the interface will be an application service, the transformation should take place in the SAP application. This has more to do with the ownership of the interface than with any technical reasons; enterprise services should be centrally managed while each application is responsible for providing the appropriate application services.
Those are things to keep in mind when we start modeling in our project. But how do these new modeling tasks relate to traditional SAP implementation methodologies? How and where can we begin? What would be the best practices? Are there any case studies? Next time I’ll try to answer these questions and continue with our journey into deeper eSOA and service modeling where I’ll try to introduce you about SOMA (Service Oriented Modeling Architecture) concepts.
2 Comments
