Why SAP is entering the Enterprise Architecture Arena
Hans Diepstraten
Friday, 14 December 2007
The disciplines of Enterprise Architecture and Packaged Based Applications have traditionally not been close. The models used in Enterprise Architecture Frameworks such as TOGAF talk about Information Systems Architecture and Technology Architecture, and structure the various architectural and solution building blocks according to business functions provided. Package Based Application Suites such as SAP cover multiple business functions, and do so in a tightly integrated way. This makes it hard to identify individual reusable building blocks within the packaged solution suite. In many cases, enterprise architects have abstracted away this problem by treating a solution suite like SAP as a black box. With the ongoing transition of the SAP solution suite into a full-fledged SOA based platform, this black box is opening up fast. The SAP user interface is moving to the SAP NetWeaver portal, workflow processes are emerging from the back end into the process orchestration and presentation domains, and business intelligence reports are integrated with portal technologies to create role-based dashboards. This is resulting in significant impact on existing policies and strategies, as well as existing architectural and solution building blocks. For instance: in many companies the solution building block for user interaction is a best of breed portal like IBM Websphere Portal. New SAP releases offer new business functionality only accessible through the SAP NetWeaver Portal. Introducing this functionality in SAP means that the existing UI architecture policies and strategies have to be adapted. For this to happen the traditional view of SAP as a black box back end has to be exchanged for a different and open layer-based approach. The enterprise architects will have to start including the layers of the SAP SOA stack in their models and building blocks.
SAP understands that in the transition to the new SAP architecture (what they call “Enterprise SOA”) there will be a large impact on existing policies and strategies as outlined above. In general, a move to an Enterprise SOA requires a fundamental involvement of Enterprise Architecture. One cannot do without the other. SAP decided that they would align their product innovations with a generic approach to innovation using an enterprise architecture framework. Rather than developing their own proprietary framework, SAP looked at the available Enterprise Architecture Frameworks and chose to go with the industry-leading Open Group Architecture Framework (TOGAF) (see http://www.opengroup.org).
This summer saw the launch of the SAP Enterprise Architecture Framework, which is based on TOGAF but adds several enhancements specifically aimed at additional requirements for packaged applications and SOA.
The SAP Enterprise Architecture Framework
SAP has now released version 1.1 of its Enterprise Architecture Framework as part of their Solution Manager product. Solution manager is a separate SAP system which is intended to manage complete SAP solution landscapes across the full life cycle, from value mapping to project definition to implementation to change and request management (including incident management). For this purpose, it integrates with several third party solutions like IDS Scheer’s ARIS BPM environment for Process Modeling, HP/Mercury’s Test manager tooling for testing applications and Marval for Incident management in operations.
The SAP Enterprise Architecture Framework is included as a tool that can be accessed in the Methodologies area of Solution Manager. The tool consists of an extensive tree structure reflecting all TOGAF phases and work packages, with templates and accelerators attached to each phase/work package.
In its EAF SAP tackles a number of omissions and weaknesses in standard TOGAF. One example is that the EAF contains a formal meta model of enterprise architecture that makes explicit what relationships exist between the various concepts and artefacts mentioned in TOGAF. Another example is the introduction and explanation of engagement types and iteration characteristics. TOGAF only hints at selective use of its cycle steps in each iteration. The EAF contains a detailed analysis of use cases and instructions on how to go through a full iteration based on the use case and engagement type.
It is important to note that SAP fully intends to stay aligned with the TOGAF framework even if the current version of the EAF contains various new and currently proprietary elements. The Packaged Applications specific and SOA related content not present in the current version of TOGAF (8.1) has been officially submitted to the Open Group as a change request and is hoped to be available in TOGAF standard version 8.2.
With the introduction of the EAF SAP is taking an important first step towards aligning the world of Package Based applications and existing Enterprise Architecture best practices. For organizations with a significant SAP footprint in their IT it will be useful to determine possible use cases for this framework, especially if the TOGAF framework is already in use.
In a next blog entry I will go into more detail about the extensions to TOGAF contained in the EAF.
Be the first to write a comment
Only registered users can write comments. Please login or register.
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
