EA and ESOA: Relationship Part 2

Transcription

1 Applies to: Enterprise Architecture (EA) and Enterprise Services Oriented Architecture (ESOA). Summary This is the second part in the two part article, where we look into the Services modeling methods prescribed by SAP EAF and ESOA based approach and how they complement each other. Author: Sri Rajagopalan Company: SAP America, Inc Created on: 18 September 2007 Author Bio Sri Rajagopalan is an Enterprise Architect with NCC organization at SAP America, Inc. Prior to SAP, he has been an Enterprise Solutions Architect for over seven years and has provided application, business process and data integration solutions for several initiatives with hi-tech industry. He holds a Master s degree in Engineering from Lamar University, Beaumont Texas. He is also an Open Group Certified Master IT Architect SAP AG 1

2 Table of Contents Applies to:...1 Summary...1 Author Bio...1 Executive Summary...3 Background...3 EA Based Approach...3 How to Model Business Services EAF Method...5 ESOA Based Approach...6 How to Model Services ESOA Method...6 Conclusion...6 Related Content SAP AG 2

3 Executive Summary In Part 1 of this article, we looked at the background of EA and ESOA and the relationship between these two key SAP initiatives. In this part, we will look into the Services modeling exercise prescribed by two complementary approaches provided by SAP namely, Enterprise Architecture discipline (utilizing SAP EA Framework) and Enterprise Services Oriented Architecture (ESOA). Background It is important to note that this article neither goes into the details of SAP EAF modeling nor ESOA Services modeling, but only identifies the touch points between the two approaches. The objective is to highlight the complementary nature of EA Framework & ESOA methodology and how the two approaches can be synthesized and employed to address customer s needs effectively. To obtain details of the methods, please see Related Content section for details. EA Based Approach Enterprise Architecture facilitates the understanding of the entire enterprise by analyzing both the architectural and non-architectural elements of an enterprise. Gartner Research (1), defines Enterprise Architecture as the process of describing, and the description of, the desired future state of an organization's business process, technology and information to best support the organization's business strategy. Therefore the primary output of developing enterprise architecture is to establish a roadmap to transform from a current state to a future state by defining a set of initiatives the priority & sequence of execution of those initiatives the necessary governance during the implementation of those initiatives SAP EA Framework (EAF) provides a well defined process with a structured approach to define the business context that forms the basis for the subsequent development of the Enterprise Architecture. SAP EAF also offers a structured and easily traceable representation of how enterprise s business processes & its various architectural assets support the enterprise s vision and strategy. One of the main components of SAP EAF is an Architecture Development Method (ADM), depicted in figure 1.0 below, which is patterned on TOGAF ADM and is made up of multiple phases organized in four different iteration cycles. The Architecture Context iteration deals with the initial mobilization of architecture activity by establishing the architecture approach, principles, scope and vision. In the context iteration, one of the key artifacts is the definition of Architecture Vision which includes analyzing the enterprise s business & technology capability and defining the target Operating Model for the business. The next iteration, Architecture Development, addresses the creation of architecture content by cycling through Business, Information Systems and Technology architecture phases SAP AG 3

4 Figure 1.0 SAP EAF Architecture Development Method (ADM) The Architecture definition iteration comprise distinct phases B, C & D for business, information system and technology architectures. Within the business architecture phase, EAF defines key terms such as Function, Service and Process. These three business entities can be considered to represent a continuum with clear distinctions described as follows. On one end of the continuum, Functions deliver business capabilities closely aligned to an organization, but not explicitly governed by the organization. Services support functions, encapsulate functions, have an explicit interface, a defined boundary and can be governed. On the other end of the continuum, Process represents the flow of functions or services. All these three entities can be decomposed into their sub-level entities to enable better analysis of the enterprise. What is a Business Service? - A business service in simple terms represents what an enterprise does. It characterizes a unit of business capability supported by a combination of people, process and/or technology. A business service may be internal to the business, exposed externally to a customer, partner, supplier etc. or may be something that the business consumes from an external party. A business service may be Fulfilled by manual processes, or may be fully automated Fulfilled within an organization, or outsourced to a partner Exposed to any combination of employees, customers, partners and suppliers Fulfilled at the point of use, at a divisional level, or as a corporate competency center 2007 SAP AG 4

5 How to Model Business Services EAF Method Within the Business Architecture Phase, SAP EAF prescribes the development of business architecture with a top down approach utilizing structured modeling and well proven hierarchical decomposition techniques to decompose business functions and processes. In addition, the framework also prescribes defining the boundaries of a Service and setting its granularity to facilitate its effective governance. In other words, the focus is to define the business services without emphasizing on how they will be fulfilled or consumed within the enterprise. The overarching purpose of this modeling is to identify business capabilities and express them in terms of business services thereby facilitating the representation of the enterprise as Service- Oriented Enterprise. The business services thus defined can be realized or fulfilled by a combination of People, Process and Information Systems that provide enterprise services or web services built using SOA architectural style. In theory any function or a process can be defined as a business service. At the highest level an enterprise can be considered as made up of macro level functions which comprises of multiple end to end business processes or business services. Each of these functions or business processes can be further decomposed and can be thought of orchestrating lower level Services and/or processes. The granularity of business services is dependent on the focus and emphasis of the business, as reflected in its drivers, goals and objectives. Hence, the decomposition is not solely driven by business functionality but also considers other non-functional characteristics of the business such as security, availability, latency and loose coupling of these Services. The structured approach prescribed in SAP EAF will help identify and define business services that Facilitate re-use of the Service within the enterprise Determine how these Services need to be fulfilled thereby enabling their sourcing decisions (insource or out-source) Enable defining common capabilities across the enterprise as Shared Services In addition to the overall modeling of business architecture, this phase also requires creating a set of catalogs, matrices and views. Among them Goal/Objective/Service view, Process catalog and Business Interaction matrix enhance the ESOA based Services modeling approach. The relevance of each one of these deliverables is briefly explained below. Goal/Objective/Service View - Defines ways in which a business service contributes to similar aspects of business performance and also to the achievement of a business vision or strategy. Process catalog Provides a hierarchy of processes, events that trigger processes, outputs from processes and controls applied to the execution of processes. Business interaction Matrix Depicts the relationship between consuming and providing business services. Following the Phase B, the next phase in SAP EAF is the Information System Architecture covering both application and data architectures. Similar to Phase B, this phase also requires developing an overall model of the enterprise s application architecture and prescribes the development of a set of matrices depicting the relationships between applications and business service, applications to business functions and application to business process respectively across the enterprise. This ensures that applications in the landscape are clearly identified and mapped to the business services/processes they support. This is very critical in step 2 of ESOA modeling approach SAP AG 5

6 ESOA Based Approach Much like EAF being a collection of methods, methodologies, techniques and tools, SAP ESOA is also a process, rather than a product, with its own set of methods and methodologies. In this section, let us look at the ESOA based approach and focus on two methods offered by SAP Consulting. The first is an overarching methodology to develop an ESOA Roadmap for a specific customer; the second one is the Services modeling, design and Implementation method which can be thought as another method within the overall Roadmap methodology. ESOA Roadmap development is a 5 step method starting with conducting an ESOA Pulse Check to developing detailed Recommendations for transforming customer s current architecture to be ESOA compliant. Following the initial Pulse Check, two subsequent steps include the following Defining ESOA relevant scenarios This step comprises of in depth analysis of the processes to identify which ones have high potential for Service enablement and followed by a detailed analysis to identify the Services that cover specific segments of the overall process. Building ESOA based Architecture This step includes mapping business processes and Services, identified in the previous step, to the application architecture and building out the to-be application architecture. How to Model Services ESOA Method Once the potential processes that are relevant for ESOA scenario and Service enablement are identified, the modeling method in ESOA based approach prescribes a top-down method to identify all the Services from a consumer perspective. The key activities in this modeling approach are as follows; 1. Identify the Services from the consumer viewpoint agnostic to the availability of the service within the enterprise. 2. Identify backend application or process components from the provider viewpoint that will deliver the Services identified in step Allocate Services identified in step 1, to the application or process components identified in step Determine how to implement and fulfill the Service, buy or build If the decision from step 4 is to buy the Service from SAP, then the customer can select from a few hundred Enterprise Services already published by SAP. Or alternatively communicate the specifications of the Service to the SAP Enterprise Services (ES) community who can develop the service and make it available as a productized service. If the decision is to build the Service, then the ESOA modeling approach provides a detailed approach to (i) design those services starting from how to define the process component, the business objects and extend the global data types that meet the specific requirements of the Service and (ii) implement & deploy those Services. Conclusion Both EAF and ESOA based approaches attempt to align business with IT and in a way represent a blueprint to the future state of the enterprise or a specific segment of it. SAP EAF can serve as an organizing logic, produces a strategic architecture that will help the enterprise transform to the desired target state and in turn can guide the development of ESOA roadmap. At a high level, EA architecture models prescribed within EAF will establish a clear traceability of the enterprise s architectural assets to its business goals, objectives & strategy. During the development of EA, the artifacts produced 2007 SAP AG 6

7 Provide a better structure and context for the architects to work with Facilitate a better understanding about the relationships among various architectural assets of the enterprise namely (i) business processes (ii) applications that automate those processes (iii) data entities that are exchanged between the application components and (iv) finally the technology that support the deployment of those application components This better understanding can serve as good basis to carry out ESOA modeling and eventually the development of ESOA roadmaps. It is very important to align the approaches of EA & ESOA on a common path and clearly understand when to employ the specific modeling effort. Also it is critically important to correlate EA and ESOA such that redundancy in the work effort across the enterprise eliminated. Related Content 1. Gartner Research 2. Enterprise Services - How to guide 3. SAP EA Framework (available free of licensing fee from SAP Roadmap Composer or SAP Solution Manager) SAP AG 7

8 Copyright Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iseries, pseries, xseries, zseries, z/os, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/os, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mysap, mysap.com, xapps, xapp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings ( Code ) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent SAP AG 8