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.
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.
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.