sap_eaf_overview_guide v1.2

22
SAP EAF OVERVIEW GUIDE Reference: NL-F-P005 Version 1.1 – March 2007 1 OVERVIEW GUIDE

Upload: sap-stella-the-reporter-detective

Post on 15-Apr-2017

393 views

Category:

Software


1 download

TRANSCRIPT

Page 1: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 1

OVERVIEW GUIDE

Page 2: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 2

Contents

1. What is SAP EAF Enterprise Architecture? 31.1 So what are businesses? 31.2 So how can businesses become more effective? 41.3 How do the automated systems relate to each other? 51.4 How can businesses align to the right automated capabilities? 5

2. Why do I need Enterprise Architecture? 6

3. What are the specific business benefits? 7

4. So why do I need EA, I thought SOA was the answer? 12

5. What is SAP EAF ? 135.1 An extension to TOGAF 8 135.2 An extension based on SAP methods and experience 145.3 An extension based on Cap Gemini methods and experience 14

6. How does SAP EAF help deliver an effective Enterprise Architecture? 15

7. What specifically does SAP EAF contain? 167.1 The SAP EAF Extensions 167.2 The SAP EAF MetaModel 177.3 The SAP EAF Architecture Process 20

8. How do I use SAP EAF? 22

THIS DOCUMENT CONTAINS 22 PAGES INCLUDING TITLE PAGE

Page 3: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 3

1. What is SAP EAF Enterprise Architecture?

The following narrative provides a logical easy-to-understand explanation of how businesses andorganizations operate, and identifies in bold those terms that SAP EAF identifies as being key partsof an Enterprise’s Architecture.

It helps the first time user understand the terms used in SAP EAF.

1.1 So what are businesses?

Primarily, a business, whether in the private or public sector, grows from the vision of individualsto meet their perception of a need in society. As a business grows it invariably reaches the pointwhere it needs significantly more investment and may turn to stocks and shareholders to satisfythat need. The business as delivered through a hierarchy of organizations that will formrelationships, sometimes contractually, with suppliers and with one or more interested parties. Inthis situation, the original pioneering vision of the individuals may be supplemented, if notreplaced, by a focused profit requirement.

In either scenario, whether formally defined or not, the vision determines current business goalsand longer-term strategy. In turn, these give rise to shorter-term tactical objectives, owned byindividual actors (its employees or service providers), which collectively should realize theassociated goal. Goals and objectives are defined, tracked, and monitored by measures, such asKPIs. Some of these will influence the market through various business initiatives/developments ormarketing aims. Some of the marketing aims may be in partnership with interested parties, e.g., aspart of a consortium and/or strategic alliance.

Inevitably, there are external market drivers and influences, some global, which have a directimpact on some, if not all, objectives and goals. Over time, these external drivers can re-shape theoriginal vision and business direction. The drivers can be external market factors, e.g., petrolprice, or internal, e.g., product cost and volume targets.

The business operates within specific external constraints that can prevent the organization frompursuing particular approaches to meet its goals, for example, a tightly-defined regulatoryenvironment, or trade restrictions.

A business generates products, such as automobiles, and provides business services, such aspayroll services, for the market, which are manufactured or delivered to appropriate standards.

A business is an organization that contracts actors (its employees or service providers) to performvarious functions usually with other actors. Actors are assigned to defined roles in theorganization that have defined responsibilities and skills, for example, Financial Accountants withbook keeping skills. The business organization’s actors are typically organized around thebusiness functions, and 3rd party suppliers support these functions. In this context, the operationof a function is described by a set of processes. Organization units, and their respective actors,are based across many geographic locations.

The above concepts form the strategic context within which the business operates, and are asignificant proportion of the architecture of a business.

Page 4: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 4

Although functions are also appropriate to the business architecture, the business’s functions arerealized through actors performing one or more processes. Processes show the flow betweenfunctions or the operation of a function. A process can be decomposed into triggered or resultingevents, the business outputs or product of the process, controls or decision making steps that arecarried out and the functions required to execute the process.

To achieve greater efficiency and flexibility in its approach, an organization can decompose itsfunctions into specific defined business services, such as customer contact management, or spareparts stock control. Specific business services are defined where the function can be defined by anexplicit interface and where it needs explicit control and governance. The degree of granularity ofthe service is determined by the objectives and focus of the organization.

In order to ensure that interactions between service providers and service consumers agree on theexpected outcome, a service contract is formally defined. This will ensure that the service providesagreed qualities or levels of service.

1.2 So how can businesses become more effective?

One of the main routes for a business to become more effective at what it does, is to automatecertain key business processes using Information Technology. Not all parts of an organization areworth automating; not all automation that is feasible is necessarily desirable. The key for anybusiness is to ensure the right alignment between its business architecture and automationarchitecture so that it achieves the maximum return on its investment.

An organization may choose to automate an existing business service using information systems; inthis case, that business service becomes dependent on one or more units of applicationfunctionality, referred to as information system services.

Business Services provide or consume information in order to deliver their outcome. Informationcan be broken down into specific logical information components, such as ProductConfigurations, or Customer Details. Information components can be broken down further toindividual data entities, such as Customer and Contact.

The physical information components are represented as data store(s) that relate to other datastore(s), which reside on a data repository incorporated within a computer, populated by actors,and interrogated by a language.

Moving into the specific Applications Architecture, Information Systems Services are supported bya portfolio of application components that represent deployed and functioning IT systems. In orderto manage the complexity of technology, application components are often encapsulated as logicalapplication components that provide logical sets of features, for example, the stock control system,or physically deployed physical application components, for example, a deployed instance of SAPR/3 Materials Management. Physical application components may be very coarse grainedapplications, such as a deployed instance of an ERP system, through to deployed instances ofgranular (web-oriented) Enterprise Services, which reside on computers.

Applications components interface with other application components, maintain data stores ofinformation components, encapsulate data entities, are used at locations, are used by or servicebusiness organization units and actors, and are available over a communications network.

Page 5: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 5

1.3 How do the automated systems relate to each other?

Technically, the application components that make up the service are delivered using technologycomponents, or acquired IT products that run on platforms built from computers and networks.

Whereas technology components are typically generic and acquired from the market, applicationcomponents are configured and deployed for a particular organization to directly automatebusiness functions.

The complex array of technology components available lends itself to a classification into logicaltechnology components, or classes. For example, databases, operating systems and networks.These are then realized by the most appropriate physical technology components for the job inhand. For example, an organization may choose to use the SAP Netweaver development platform,Oracle 10g DBMS, or the Microsoft Windows Vista operating system. All of these are located atspecific geographical locations (such as Data Centers, Office Premises etc).

If a business chooses to automate a business service as an information systems service, it willneed to enable the service through a technical platform service. Platform services will include forexample the provision of centralized backup and recovery services.

1.4 How can businesses align to the right automated capabilities?

Given the rate of change in an organization, and the speed of technological advancement, it is alltoo easy for an organization to spend significant time and effort on automating the wrong function,or using the wrong technology.

An organization’s vision, its defined goals, objectives and measures, will contain explicit andimplicit requirements that define the business needs.

These requirements will often be based upon gaps that exist between where the organizationcurrently is, and where it wants to be. Once defined, these gaps can be filled by defining a set ofdependent work packages, such as programmes or projects, whose aim is to deliver businesstransformation.

In order to ensure that the organization’s goals, objectives, measures and requirements are met,they can be distilled into qualitative statements of business need or principles, which can then beused to govern the organization’s transformation. In order for the transformation to be formallyplanned and effectively designed and governed, a set of architecture models or architecturebuilding blocks can be used to describe aspects of the organization.

Page 6: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 6

2. Why do I need Enterprise Architecture?

Supporters of Enterprise Architecture who believe in the value of it, often do so on general groundsthat it is simply the smart thing to do.

In a similar way, to disciplines such as Project Management, Enterprise Architecture is now seen ascommon sense; why would you not adopt it as a core discipline in your organization?

However, as in any new initiative, there will be time, cost, and effort needed to design, initiate andembed it within an organization.

It is important therefore to provide a more comprehensive description of the benefits of EA, butalso the measures to use to overcome the generalities and convince people of its merit.

As ever, there are different stakeholders to consider, business users and IT practitioners, and thevalues of EA must be considered and presented in different ways to gain support from both groupsif the introduction of EA is to succeed.

Business users want a fast response from IT; they want IT aligned to its business strategy, and adependable, stable environment, in order to improve business performance.

IT practitioners want to make their own job easier and faster, and more reliable. This meansreducing complexity and cost.

Ultimately, the benefits of EA derive from the better planning, earlier visibility, and more informeddesigns that result when it is introduced.

The next section provides details of the specific benefits of Enterprise Architecture.

Page 7: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 7

3. What are the specific business benefits?

The specific benefits of Enterprise Architecture can be categorized into 2 key groups:

Business Benefits to which EA contributes

IT Benefits to which EA contributes

The table below provides example benefits, rationale, and potential KPIs for use in any benefitsrealization process.

Page 8: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 8

Figure 1 – Benefits of Enterprise Architecture

Stakeholder Benefit Type Benefit Rationale KPIBusiness Helps achieve

businessstrategy

Without an understanding of business,application and technical architecture, abusiness doesn’t know what it is going to taketo align and to implement IT to execute itsbusiness strategy. In essence, it doesn’t knowwhat it has or doesn’t have.

This ensures when planning programmes andprojects that effort is targeted onto thoseaspects that really matter, and this adds to thestrengths of the enterprise.

It means that IT investment is targeted on thekey business goals and performance.

It ensures the business can be early adoptersof new innovations and is not held back byIT.

This is the ability of IT to leverage an organization’s capability by a direct focusthrough understanding the strategy and intent. If everyone sees the same future,more can be done to achieve it.

It is difficult to estimate this value in monetary terms, but it can be appreciatedregardless.

Spin-off benefits also include eliminating changes required by heading in thewrong initial direction.

Without Enterprise Architecture, organizations frequently approve projects that,from all outward appearance, are not associated with any business strategy.

Organizational clout, supposedly self-funding business cases, andcompartmentalized decision processes drive these behaviors.

If you cannot easily identify the strategy supporting the funding decision, thenthere probably isn’t one.

Alignment of investment withbusiness strategy(This can be monitoredqualitatively via opinion surveytargeted at the CxO levelexecutives.)

Number of projects approvedthat are in compliance/not incompliance with businessstrategy

Business Faster time-to-market of new

innovationsand

capabilities

If IT can introduce new technologies fasterand functionalities faster to key businessareas, this ensures the organization canrespond faster to competitive pressures, anddeploy differentiating capabilities faster.

These areas are most likely to be spottedwhen business and IT staff collaborateclosely in the EA process.

The outcome is that technology is ready whenit is needed, transitions are smoother, andunnecessary change is minimized.

EA gives users faster delivery of new functionality and modifications, and easieraccess to higher quality, more-consistent and more-reliable information. Well-architected systems can more quickly link with external business partners.

A common symptom in organizations without a robust Enterprise Architecture isproject overruns. When new, important strategic projects are created, without acomprehensive understanding of the current state, the desired state, or theinterrelationships of processes, people, and technology affected by that project,unforeseen problems will occur resulting in project overruns.

If the architecture of the organization is known and familiar, the relative time toimplement new systems or capabilities is reduced.

Dependent opportunities to upgrade items or refresh the estate can be identifiedearly, and their impact on projects reduced.

New business capabilities orfeatures or service implementedfaster

Number of projectoverspends/overruns >xmonths or x% of budget

Page 9: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 9

Stakeholder Benefit Type Benefit Rationale KPI

There are many examples of organizations that are prepared to employ newtechnologies such as VoIP, single user sign-on, or Web-based services, becausethey did the upfront work on the target architecture was done and the means to getthere was defined.

Business More-consistentbusiness

processes andinformation

across businessunits

EA can unlock the power of information,unifying information silos that inhibitbusiness processes.

It identifies the processes, applications, anddata that need to be consistent if consistentbusiness decisions are to be made.

EA identifies opportunities for integrationand reuse that prevents the development ofinconsistent processes and information.

If an organization does not have visibility of its business process, information andhow this relates to IT infrastructure, information silos and inconsistent systems willresult.

This symptom has been exacerbated in recent years by mergers and acquisitions.These have added to the complexity of an organization’s IT estate resulting induplicate processes.

Especially important to users is the capability of integrating the information amongapplications and across data warehouses and data marts. By understanding anorganization’s data architecture, it can develop a standard data dictionary, anddevelop metadata standards to minimize data inconsistency.

Relative ease of access toinformation (This can bemonitored qualitatively viaopinion survey targeted at thespecific user groups)

Response time to businessdemands (This can bemonitored qualitatively viaopinion survey targeted at thespecific user groups)

Business Morereliability andsecurity, and

less risk

EA provides clear traceability betweenbusiness processes, data, user roles,applications and infrastructure.

A reliable architecture model aids consistencyand manageability, and an organization has amuch better chance of implementingcorporate standards and planning andmanaging to those standards on an ongoingbasis.

When changes occur that cause unplanned downtime or other problems, and noone understands who did it, how it happened, or why it happened, then the odds arehigh that it will happen again.

The IT environment itself is in a constant state of change. A change two or threecycles in the past may not have an impact until the worse possible momentsometime in the future, cascading across the enterprise.

If an organization does not have a clear model of its business, application andtechnical architecture and the dependencies and interrelatedness, and installedprocesses and standards to manage that environment, then there will be notraceability or accountability.

Rate of disruptions, availabilityof systems, number of untracedsecurity incidents

Page 10: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 10

Stakeholder Benefit Type Benefit Rationale KPIBusiness/IT Better

traceability ofIT costs

EA provides greater understanding of theinterrelated nature of business, application,and infrastructure assets.

This enables greater understanding of howthe architecture is structured, and enablesmore accurate cross-charging or servicebilling.

It enables high cost areas of the IT estate tobe identified more accurately, and a fairercost model to be developed.

Most organizations can identify the individual cost of an asset. However, manycannot understand the cost of an asset as it relates within the organization with allits interrelatedness and interdependencies.

IT departments can typically identify that a server costs so much, but they can’tidentify what organizations that server supports, what the maintenances costs are,or what critical business applications are using that server.

In many cases, organizations don’t have a mechanism to understand holisticallyall the costs associated with those related assets

% of IT OPEX that can beallocated to specificapplications or business units.

IT Lower IT costs- Design, buy,

operate,support,change

A clear understanding of AS-IS and TO-BEarchitecture, and the migration plan of howto progress from one to the other, will enablethe implementation of duplicate systems tobe avoided, and acquisition integration to beaccomplished effectively.

By understanding what it has, what it needs,what is redundant, an organization can tailorits investment to the areas of most need, andidentify reuse more frequently.

If development standards and guidelines are in place that define the boundaries ofwhat it is possible for the application developer or infrastructure builder to do, andin effect describe how to behave when creating new capabilities, this can increasethe efficiency of development projects whilst also enable the solution designer tohave considerable freedom of choice in creating a solution where appropriate.

Cutover costs forupgrades/conversions

Support cost (reduced due toless asset diversity)

Monitoring/tracking level (costsreduced)

IT Faster designand

development

The development of enterprise architectureenables earlier preparation for newtechnologies, smarter timing of projects, andthe reuse of development best practices,standard designs and components

The reuse of existing services, components and infrastructure, and the applicationof standards can reduce development time and reduce support requirements.

Level of reuse (leveragingcosts, implement faster, better)

IT Lesscomplexity

Enterprise Architecture is an ideal tool toidentify duplicate and overlapping processes,services, data hardware and software.

Standardization drives IT procurementefficiencies due to economies of scale.

CIOs should regularly monitor the size and complexity of their IT infrastructureand application portfolios.

It is common to see organizations that have no defined management mechanism toidentify an “end of life” technology or optimize application portfolios. Theincreasing complexity adds overhead costs, while also increasing risk to project

Product diversity (more offewer products) (no. ofproducts per class in place,guidelines, new systems)

Number of consolidated

Page 11: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 11

Stakeholder Benefit Type Benefit Rationale KPI

Reduced skills maintenance, training, fewersupport staff and simpler upgrades also result.

To solve duplication and overlap, anorganization needs a comprehensive view ofits applications, software, and infrastructureand their interrelatedness.

delivery schedules.

Savings estimates range from 10 percent to 30 percent of infrastructure costs,which are typically 50 percent of IT operating budgets. A 2001 Meta Groupsurvey reported a 30 percent average reduction in IT total cost of ownership forcompanies with mature IT architectures and standards.

Fewer products, as opposed to many, means higher unit volumes and better abilityto support the products and plan timely transitions that respond both to the businessneed and the technology progress rate. Familiarity also provides experience onperformance, risk and maintenance. Sound choices often enable an ability tomonitor and track the system in consistent ways that help deliver better clientservice. Even IT personnel demands are made simpler.

multiple redundant systems

Number of avoided purchases(e.g., another enterpriseRDBMS)

Technical infrastructure skillsdiversity

IT Less IT risk Developing a TO-BE architecture and amanaged migration plan will mean that the ITfunction will be prepared to deliver the newcapabilities in a timely manner — generally,faster than the competition.

The IT effort will be aligned with the strategyand unexpected surprises and demands willbe avoided This will enable efficienttransitions to new capabilities.

Capacity planning and monitoring improvesas system retirements and upgrades can beplanned in advance,

A clear two to three year plan for the enterprise is a typical product on EnterpriseArchitecture. Using this, the organization can forecast the required budget, makerealistic commitments, and plan in good time for IT changes.

An organization without a strategic plan is often consumed day-to-day with thenext “emergency”. While some may say “what’s wrong with that? Everyone isfocused on what matters” the situation is not healthy for IT or for the business.

With focus on the short term, and without adequate time to plan, each new solutionis at risk for becoming another silo. Increasingly, more time is spent trying to makeeach new solution “fit in” than on the solution itself.

Capacity planning becomes very difficult in such environments, which in turncauses further unplanned capacity and system upgrades. This causes further projectoverruns.

Rate of urgent infrastructureprojects (reactive)

Downtime/availability

Occurrence of short-livedproducts (more stable)

Number of projects incompliance, not in compliance,returned for modifications,proceeded without change,requested waiver(s), waiversgranted/rejected

% of Projects accepted intoService Delivery without issue

Cost/Time vs. original budgetadjusted by % of originalrequirements/% high severitydefects

Page 12: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 12

4. So why do I need EA, I thought SOA was the answer?

Alignment between business and IT within an organization is a fundamental challenge facing SOAadopters. However, even with a fully aligned organization, there are still significant differencesbetween an SOA landscape and a traditional IT landscape that create new points of stress andfocus.

Whilst providing much greater business flexibility and agility, the breaking up of siloed businessfunctions and applications into services comes at a cost, in that it creates a much more fine grainedIT landscape that needs to be managed. As a by-product producing finer-grained capabilities, anincreased volume of services must be managed (100s or 1000s of services as opposed to 10s or100s of applications) with correspondingly increased complexity around the usage of andinteraction between services.

Technology can provide tooling to address many of these stress points, but the real issue here isthat effective operation of a Service Oriented Architecture requires a much more formalizedunderstanding or the IT landscape with explicit linkages to the business it supports.

Without this understanding, there is a very real risk that the possibilities of SOA will lead to anorganically developed IT landscape, characterized by:

Proliferation of unplanned, misaligned services at inappropriate levels of granularity, knowas “service sprawl”Inability to carry out impact assessment and consequent overspend on infrastructure orpoor quality of serviceMultiple technology stacks that are costly to support and do not interoperate, creatingislands of services tied to implementation specifics that result in a brittle IT landscape andhigh operational costs, due to more complex service management and IT operationsInability for potential service consumers to identify services for re-use, resulting induplicated capability, lack of visibility and increased integration complexity

Enterprise Architecture is the application of architectural discipline to the end-to-end Enterprise,treating the Enterprise or industry value-chain as a system. What Enterprise Architecture providesin an SOA context is a set of tools and techniques to link top-down Business-Led SOA to bottom-up Developer-Led SOA in a robust and maintainable way that addresses many of the non-technicalchallenges associated with SOA adoption.

Enterprise Architecture defines structured traceable representations of business and technology thatlink IT assets to the business they support in a clear and measurable way. These models in turnsupport impact assessment and portfolio management against a much richer context.

Enterprise Architecture defines principles, constraints, frameworks, patterns and standards thatform the basis of design governance, ensuring aligned services, interoperability and re-use

Further discussion of this topic is provided in NL-F-P008 “How Enterprise Architecture SupportsA Service Oriented Architecture.

Page 13: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 13

5. What is SAP EAF ?

5.1 An extension to TOGAF 8

SAP EAF is an extension of the TOGAF Enterprise Architecture Framework specifically designedto support the effective adoption of package and package services solutions in the Service-Oriented Enterprise.

TOGAF is a framework – a detailed method and supporting tools – for developing enterprisearchitecture. It is described in a set of documentation published by The Open Group and may beused freely by any organization wishing to develop an enterprise architecture for use within thatorganization.

The TOGAF Architecture Development Method is a generic method for architecture development,which is designed to deal with most system and organizational requirements. However, it will oftenbe necessary to modify or extend the ADM, to suit specific needs. (TOGAF 8.1 Manual, 2002).

SAP EAF is a complementary set of additions to TOGAF to support the specific characteristics ofpackages and services.

SAP EAF was developed during Q4 2006 and Q1 2007 by a joint team of over 30 SAP and CapGemini Enterprise Architects, most of which are TOGAF 8.1 accredited practitioners.

The key features of SAP EAF are that it is:

Vendor agnosticTechnology independentSolution independentNot a new EA Framework built from scratchBased on TOGAF 8.1 / 9 as the source for methods, definitions and visualizationsA set of artifacts, examples and training materials highlighting the ‘delta’ from TOGAFProvided with patterns, templates, accelerators and reference models for services-basedpackaged solutions, and in particular for SAPProvided with EA Tools, Training and Case Study supportAlready proven with customers

SAP EAF is targeted for training and rollout during Q2 2007.

As well as TOGAF, SAP EAF draws on a wealth of experience from SAP and Cap Gemini in theintroduction of Enterprise Architecture to organizations.

Page 14: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 14

5.2 An extension based on SAP methods and experience

SAP is the world's leading provider of business software. Today, more than 38,000 customers inmore than 120 countries run SAP applications-from distinct solutions addressing the needs of smalland midsize enterprises to suite offerings for global organizations. SAP employs more than 39,300people in more than 50 countries.

SAP has a substantial commitment to Enterprise Architecture and the adoption of Enterprise SOA.

SAP’s existing Simple, Agile Architecture Framework (SAAF) was created during 2005 toaccelerate enterprise SOA adoption with the release of the SAP ERP 2005 and Enterprise Services.This was based on TOGAF and designed to support specific SAP package and service components.

SAAF was used as a source for SAP EAF extensions.

SAAF has been implemented within the ARIS family of modeling tools from IDS Scheer. Theframework itself and the supporting toolset are aligned with current and future SAP software toolse.g. Solution Manager, Solution Composer, and SAP’s new Service-Oriented components.

5.3 An extension based on Cap Gemini methods and experience

Cap Gemini is one of the top five IT services and consulting companies worldwide. Cap Gemini isa global leader in consulting, technology, outsourcing, and local professional services, and operatesin more than 30 countries. It employs over 75,000 people in North America, Europe, and the AsiaPacific region.

Cap Gemini is one of the strongest, vendor neutral architecture practices in the world – with accessto the experience of building and operating architecture frameworks for more than 10 years.

Cap Gemini has a substantial commitment to SAP in general and a sustained commitment todriving Enterprise SOA/NetWeaver forwards over the last 3 years. It is also demonstrates a majorcommitment to standards bodies – in particular the Open Group.

Cap Gemini’s existing Integrated Architecture Framework (IAF) is accredited by the Open Groupand complementary with TOGAF, and was used as a source for SAP EAF extensions.

Figure 2 – SAP EAF and how it is constructed

SAP EAFSAP EAF

MethodologyMethodology EA ToolsEA Tools

TOGAF 8.1TOGAF 8.1

SAAFSAAFIAFIAF

Page 15: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 15

6. How does SAP EAF help deliver an effective Enterprise Architecture?

An effective Enterprise Architecture can:

Enable the effective delivery of business capability ;Ensure alignment of business and IT drivers;Provide a consistent view of the business and IT landscape;Ensure the application of consistent rules and practices across an organization.

By providing a set of clear process steps, a defined metamodel, and a set of core deliverables, SAPEAF can support all these views of an effective Enterprise Architecture.

By gaining stakeholder buy-in and agreeing the scope early on in the program, SAP EAF (likeTOGAF) can ensure the key stakeholders do not jeopardize the program due to lack ofinvolvement.

By ensuring the scope is agreed early in the program, SAP EAF can help avoid scope creep, and atthe same time the identification of key deliverables can ensure that key areas do not ‘fall down thecracks’.

By developing an EA definition using the ADM and progressing through the Business, InformationSystems, and Technology Architectures, SAP EAF ensures that the decisions made are alwaysbeing considered from the business perspective, ensuring continuing alignment of the business andIT and ensuring the business imperatives continue to be the driving force in the EA definition.

In addition to the above, because SAP EAF has focused on delivering a framework optimized forpackages and packaged services architectures, it ensures that rules and practices affected by thistype of architecture can be followed across the business and technical domains in a consistentmanner, rather than having them being invented each time a new package is introduced.

Finally, unlike TOGAF, SAP EAF provides specific guidelines, case study examples, and a definedset of core deliverables to ensure that the EA in an organization does not need to start from a blanksheet of paper when they start a program but can instead reuse this information collected frommultiple previous experiences, allowing the EA to kick start the SAP EAF program and toaccelerate quickly into the EA definition, ensuring a faster decision making process and helpingmaintain momentum, rather than stalling progress in a way that EA may have caused in the past.

Page 16: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 16

7. What specifically does SAP EAF contain?

7.1 The SAP EAF Extensions

The SAP EAF Extensions are made up of the following as shown in Figure 3 below:

Overall Descriptions of the extensions;

A Supplier Independent Framework including methodology, guidelines, templates, and adetailed case study;

An SAP Tooling Environment providing professional tools to aid the creation of anEnterprise Architecture;

SAP Specific Mappings showing how TOGAF concepts can be specifically mapped to theSAP Product Set;

A Resource Base of reference models and accelerators to use during the creation of anEnterprise Architecture.

Figure 3 – The SAP EAF Extensions

Supplier Independent Framework

Usage Guidelines

Templates, Examples and Case Studies

Architecture Development Method Content Metamodel

Overall Description of SAP EAF005: SAP EAF Executive Guide

000: SAP EAF Overall Process

002: SAP EAFMetamodel andView Definition

003: SAP EAF DocumentMaps and Wallchart

SAP EAF Phase Descriptions

006: SAP EAF Stakeholder Map

Case Study Material

Prelim Description Vision Description Business ArchitectureDescription

IS – ApplicationArchitecture Description

100: PhaseWorksheet

105: PhaseNarrative

200: PhaseWorksheet

205: PhaseNarrative

300: PhaseWorksheet

303: PhaseNarrative

400: PhaseWorksheet

(App & Data)

402: PhaseNarrative

IS – Data ArchitectureDescription

TechnologyArchitecture Description

Opportunities andSolutions Description

Migration PlanningDescription

502: PhaseNarrative

600: PhaseWorksheet

602: PhaseNarrative

800: PhaseWorksheet

801: PhaseNarrative

900: PhaseWorksheet

901: PhaseNarrative

Architecture ChangeManagement Description

Implementation GovernanceDescription

Requirements ManagementDescription

1100: Phase Worksheet

1101: Phase Narrative

1000: Phase Worksheet

1001: Phase Narrative

1200: Phase Worksheet

1201: Phase Narrative

Architecture Examples

101: ExampleArchitecturePrinciples

102: SAP EAFTailoring Guide

104: Architecture CaseStudies in a Packaged

Environment

106: ITGovernance

Review

201: BusinessCapability

Assessment

202: Technology Capability /Maturity Assessment

203: EngagementInitiation Guide

302: Service ContractGuidelines

008: How Enterprise ArchitectureSupports a Service Oriented

Architecture

Resource Base

SAP-Specific Mappings

SAP Tooling Environment

Business ReferenceModels

Technology ReferenceModels

SAP Implementation ToolsSAP Modeling ToolsSAP Content Tools

704: Mapping of TOGAF TRM to SAP 707: SAP EAF to SAP Terminology Mappings

701: SAP EAF Tooling Strategy

706: ARIS Tooling Reference Implementation 702: Roadmap Composer Whitepaper700: Solution Composer Whitepaper

705: Overview of SAP Tools

Provided within SAP tools

Provided within SAP tools

Templates Other Examples BEEST

007: SAP EAFGlossary

708: SAP EAF to SAP Method Mapping

802: BenefitsTracking

Guidelines

902: Solution ArchitectureTerms of Reference

903: ReleaseStrategy

Guidelines

001: SAP EAF Overview

709: SAP Glossary

Page 17: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 17

The two main constituents of SAP EAF are:

The SAP EAF MetaModel

The SAP EAF Architecture Process

These are now discussed.

7.2 The SAP EAF MetaModel

SAP EAF provides an explicit metamodel as an extension to the TOGAF ADM and Resourcesrelating to content. The intention of this metamodel is to take the implicit references to contentstructure within TOGAF and make them explicit, specifically:

SAP EAF defines a set of architectural metamodel entities and relationships. TOGAFuses specific keywords, such as “Application”, “Location” and “Business Service”, butdoes define specifically which of these concepts should be modeled in the architecture andhow they should be modeled. SAP EAF provides a list of metamodel entities (things in thearchitecture), metamodel relationships (relationships between things in the architecture)and metamodel attributes (how the things in the architecture are described).

SAP EAF provides a set of architectural views. TOGAF provides a list of examplearchitectural views, but does not define mandatory criteria for compliance. TOGAF alsodoes not describe the majority of views and does not specify the content or presentation.SAP EAF lists a set of mandatory and optional views, defines which metamodel entitiesshould be present in each view and provides an example of each view.

SAP EAF explicitly defines all keywords that are used in the architecture. TOGAFrelies on interpretation or common understanding for many of the architectural termsintroduced in the ADM. SAP EAF provides specific definitions of each term, providing amuch more formalized and explicit description. This is critical in areas where a term isused to mean several different things in the industry. For example, words such as process,function and service are interpreted in different ways across the IT industry.

Page 18: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 18

SAP EAF uses the terminology of the TOGAF ADM as the basis for a formal metamodel. Thefollowing core terms are used within SAP EAF:

Actor. A person, organization or system outside the consideration of architecture modelbut interacts with itApplication Component. An encapsulation of application functionality that is aligned toimplementation structuring.Business Service. Supports business capabilities through an explicitly defined interfaceand is explicitly governed by an organizationData Entity. An encapsulation of data that is recognized by a business domain expert as athing. Logical data entities can be tied to applications, repositories and service and may bestructured according to implementation considerations.Driver. An external opportunity or threat that motivates the organization to meet or re-define its goalsFunction. Delivers business capabilities closely aligned to an organization, but notexplicitly governed by the organizationGoal. A high-level statement of intent or direction for an organization used to alignapproach and measure successObjective. A time-bounded milestone for an organization used to demonstrate progresstowards a goal.Organization. A self contained unit of resources with line management responsibility,goals, objectives and measures. Organizations may include external parties and businesspartner organizations.Platform Service. A technical capability required to provide enabling infrastructure thatsupports the delivery of applicationsRole. An actor assumes a role to perform a taskTechnology Component. An encapsulation of technology infrastructure that represents aclass of technology product or specific technology product.

Some of the key relationship concepts related to the SAP EAF core metamodel entities aredescribed below:

Process is only ever used to describe flow.Function described units of business capability at all levels of granularity.Business Services support organizational objectives and are defined at a level ofgranularity consistent with the level of governance needed.Business Services are deployed onto application components.Application components are deployed onto technology components. .

Page 19: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 19

Figure 4 below shows the entities and relationships that are present within the core SAP EAFmetamodel:

Figure 4 – The SAP EAF Metamodel

Page 20: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 20

7.3 The SAP EAF Architecture Process

The SAP EAF Architecture Process supplements the TOGAF Architecture Development Method(ADM), describing the specific TOGAF extensions to be used. Detailed SAP EAF guidance onhow to complete a specific phase within the ADM is contained in the SAP EAF phase narrativesand the TOGAF ADM itself.

The Architecture Development Method is the major component of TOGAF and provides guidancefor architects on a number of levels:

TOGAF ADM provides a number of architectural phases (e.g.Business Architecture, Information Systems Architecture,Technology Architecture) in a cycle, as an overall process templatefor architectural activityTOGAF ADM provides a detailed narrative of each architecturephase, describing the phase in terms of objectives, approach, inputs,steps and outputs. The inputs and outputs sections provide aninformal definition of the architecture content structure anddeliverablesTOGAF ADM provides cross-phase summaries on requirementsmanagement, phase inputs and phase outputsTOGAF ADM provides a cross-phase section explaining the conceptof architecture building blocks, which allow the Enterprise to besegmented into re-usable components, described by architectures andthen re-combined to construct new architectures. For example,creation of a web application building block that could be used tosupport architecture definition for many specific web applications

The SAP EAF process is optimized for usage in Packages and Services centric environments.There are a number of constraints relating to such environments that make it impractical to use astrict waterfall method and where an iterative approach is ideally suited. The following key factorsinfluence the decision to use an iterative model within SAP EAF:

In a Packages and Services environment, the level of alignment of Business, Applicationsand Data architectures with available technology is typically the overriding factor indetermining an optimum architecture. Using an iterative approach, Business,Application, Data and Technology considerations can be addressed in parallel beforegaining formal commitment to a specific approach

In a Packages and Services environment, the ready availability of prototype ordemonstration systems provides an opportunity to evaluate functional and technicaldecisions much earlier in the process. Using an iterative approach allows initial passesthrough the architecture to identify areas of architectural risk or uncertainty and then todrop into prototyping to address these areas.

In a Packages and Services environment team sizes are typically larger, due to the needto incorporate functional and technical product expertise into the team alongside businessand technical domain expertise from the customer organization. These larger teams meanthat the architecture needs to progress at high speed and specifically focus on takingarchitecture off the critical path of a wider solution definition team. An iterative approach

Page 21: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 21

supports this need by removing checkpoint barriers and allowing partial architectures to beused to facilitate progress in other areas.

In a Packages and Services environment, the risk profile of the solution is less uniformthan in custom build environments. Because Packages and Services vendors providerelatively complete platforms for systems implementation, solution definition in theseenvironments are typified by low risk levels across large portions of the landscape withparticular flashpoints of risk around security, sizing, integration, migration and platformgaps. Using an iterative approach supports accelerated completion of architectural activityin low risk areas, without preventing more detailed assessment in more challenging areas.

The SAP EAF process divides the TOGAF ADM wheel into a number of sections that supportiterative completion of architecture activities to achieve a specific purpose.

Architecture Context iterations allow initialmobilization of architecture activity byestablishing the architecture approach,principles, scope and vision.Architecture Definition iterations allow thecreation of architecture content by cyclingthrough Business, Information Systems andTechnology architecture phases. Theseiterations also allow viability and feasibilitytests to be carried out by looking atopportunities and migration planning.Transition Planning iterations support thecreation of formal change roadmaps for adefined architectureArchitecture Deployment iterations supportgovernance of change activity progressingtowards a defined future state architecture.

Each one of the SAP EAF iteration cycles can be executed a number of times. Some iterationcycles can be executed once, whereas others have a minimum number of cycles. For someiteration cycles, each iteration follows the same process. However, where there are a minimumnumber of iterations for an iteration cycle, the process differs slightly for each of the mandatoryiterations.

ArchitectureContext Iterations

ArchitectureDefinitionIterations

ArchitectureDeploymentIterations

TransitionPlanningIterations

Page 22: SAP_EAF_Overview_Guide v1.2

SAP EAF OVERVIEW GUIDE

Reference: NL-F-P005Version 1.1 – March 2007 22

8. How do I use SAP EAF?

Like TOGAF, SAAF and IAF, SAP EAF is an architecture framework and as such can never beexpected to be a prescriptive set of instructions that can be slavishly followed in the same way thata cook book recipe can.

SAP EAF provides a methodology, based on TOGAF, that an Enterprise Architect can use andwithin that methodology it has a series of activities or steps that if followed will allow an EA todefine an Enterprise Architecture. Some of these steps may be detailed in nature whereas othersmay have to be more abstract and require more input and thought from an Enterprise Architectbefore a defined way forward is established.

Even where the latter is true though, SAP EAF provides a significant amount of assistance in theform of narratives, worksheets, suggested deliverables, and key additional content to help the EAdecide what needs to be done and how an activity may be best approached.In addition SAP EAF also provides key case study example deliverables to demonstrate to the EAwhat SAP believe ‘good’ might look like for particular deliverable within an Architecture.

Given the above then it is clear that SAP EAF is not meant to teach someone to be an EnterpriseArchitect, but is meant to be used by someone experienced in architecture who needs a moreformal approach to what has traditionally been an almost abstract activity.

When commencing a SAP EAF engagement then it is important that the EA, or EA’s, understandthat the approach to take is to follow the SAP EAF methodology as documented in the narratives ofeach of the phases.

Each phase has a narrative that details the activities that have been identified as key to that phase ofthe architecture, but this is supported by a worksheet detailing the individual inputs and outputs andsupporting reference material that the EA can draw on when executing a particular phase.

There is a danger however, that following individual narratives could have meant an inconsistentresult if the phases are not aligned effectively, therefore SAP EAF also provides a series of higherlevel documents (of which this is one) and wall charts detailing the architecture activity maps, gapanalysis activities and the interfaces between the phases and these should be available to all EAsduring a SAP EAF engagement to ensure consistency of approach and also consistency ofexpectation.

Within SAP EAF however, there is still a need to tailor the framework itself, and this should beaddressed early in the cycle, to ensure the framework is fit for purpose and that the relevant parts ofthe framework – particularly the metamodel, can support the requirements of the clientorganization. To ensure this the framework tailoring should be considered as detailed in the SAPEAF tailoring guide