We keep getting a lot of comments suggesting that the SAP EA framework is merely a conceptual framework , consisting of collections of common knowledge that are helpful in creating enterprise architecture , but lack sufficient practical aspects for a SAP customer. Well, instead of responding to those comments again and again I'd like to post a blog and explain how the framework is a practical methodology that , when properly used will help you prepare for enterprise SOA . We realized that since the EA framework is a collection of common knowledge and common knowledge alone isn't always an attraction to customers, we would want to add tangible artifacts as an output of the framework for our customers . In order to make our framework attractive we focused on two main areas. We added and are still adding relevant SAP content into the framework (resource base) as accelerators for EA work (and we are now witnessing how those accelerators really reduce EA work). The second area where we are investing time and effort is in the alignment of the framework to the SAP architecture to help better our customers' readiness in using our products. In this post I would like to focus on the second area of development. If you’re a customer or a partner and have invested time on the ES workspace ( https://www.sdn.sap.com/irj/sdn/developerareas/esa/esworkplace ) or you’re a SDN user and you went through the ES Packages wiki page ( https://wiki.sdn.sap.com/wiki/display/espackages ) you probably noticed that enterprise services are exposed as interfaces from the process components. The exposed service interfaces are calling service operations exposed by business objects that are hosted inside the process component. If our framework were to help and enable you to identify service interfaces driven by business needs , and then aligned themselves to SAP process components, business objects and service interfaces, would they then be of practicable value to you? My guess is that the answer would be yes. Following our framework you’ll define sets of enterprise capabilities (business scenario groups, business scenarios, business processes) and process configuration variants together with their steps (business process modeling). From those capabilities you’ll identify conceptual services and Information components and Information objects. Then by following the framework methodology you’ll assign logical services to information components. Sounds familiar? Just this scenario starts from the business and helps you to define information components, Information worlds and logical services which derive from business needs. I already mentioned SAP knowledge embedded into the framework and with this information our architects can help you to create your information components, Information objects and logical services in such a way that they will both reflect your business needs and align to SAP process components, Business objects and enterprise service interfaces. This is just one example showing how the framework has many practicable aspects. I’ll expose more practical aspects of the framework soon, so stay tuned. Glossary: Conceptual service: a service needed by the enterprise to reach it objectives. Those services might be done by people, systems or combination of system and people but while defining conceptual service we are not dealing with this aspect. Logical Service: conceptual service that use information as input or output. Information object: Information that used by process actors to perform their tasks (invoice, customer, product …). Usually a logical view of the information reflect information object. Information objects composed from a collection of Global data types. Information component: information component are used to create conceptual model of the Information. Information component is a collection of information objects that usually reelect certain capability done by certain role or business unit. 
4 Comments
