SOA200_EN_Col72_FV_A4[1]

SAP AG 2009

SOA200 SAP Enterprise SOA – Enterprise Architecture Framework - Level 1

THE BEST-RUN BUSINESSES RUN SAP

© SAP AG 2009

SOA200 - SAP Enterprise Architecture Framework - Level I

Software Components: None

Version 72

Material number: 50094077

SAP AG 2008

Copyright

Copyright 2009 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, Excel, 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, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, 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.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG.

This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice.

SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided 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 have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. 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.

SAP AG 2009

Unit 1a - Overview of TOGAF™ and SAF EAFUnit 1b - Overview of TOGAF™ and SAP EAF ComponentsUnit 1c - Content Metamodel

Unit 1 - Catalogs, Matrices and Diagrams Unit 1 - Architecture ProcessUnit 2 - Phase 0: Preliminary PhaseUnit 3 - Phase A: Architecture Vision

Unit 4 - Phase B: Business ArchitectureUnit 5 - Phase C: Information Systems Architecture - AppsUnit 6 - Phase C: Information Systems Architecture - DataUnit 7 - Phase D: Technology Architecture

Unit 8 - Phase E: Opportunities and SolutionsUnit 9 - Phase F: Migration PlanningUnit 10 - Phase G and H: Implementation GovernanceUnit 11 - Enterprise Architecture GovernanceUnit 12 – TOGAF™ and SAP EAF for Specific Engagements

Unit 13 - SAP-Specific MappingsUnit 14 – EA Tools for TOGAF™ and SAP EAF

Course Overview Diagram

TOGAF™ is a trademark of the Open Group

SAP AG 2007

The SAP Enterprise Architecture Education Curriculum


© SAP AG 2007


SOA 200 Course Background

SOA 200 Course Agenda

After Introductions and Logistics of the venue, we will explain the background to the SAP Enterprise Architecture Curriculum.

SAP AG 2009

A New SAP Enterprise Architect Certification

Business needs analysisStakeholder Surveys

InterviewsAnalysts feedback

Industry best Practice

SAP Certification program requirements

FeedbackConsolidation

Address the new Enterprise Architect role

Prepare for TOGAF™certification

Incorporate IT Industry and SAP best practice

Drive quality and consistency into growing SAP Ecosystem

Certification ProgramObjectives

Based on the key industry requirements and feedback, SAP has designed a new EA Certification program.

It will address the needs of the new Enterprise Architect role

It will ensure the existing SAP Certification program meets new customer requirements

It will incorporate IT Industry best practice

It is intended drive quality and consistency into the growing SAP Ecosystem ; for example, amongst the SAP Partner Community

SAP AG 2009

SAP Tiered Certification: New Program Framework

Master Enterprise Architect 7+ years of experience in Enterprise Architecture In- and externally recognized as an expert in his/her

Enterprise Architecture field Deep practical EA experience, integration, optimization

and architectural knowledge Ability to provide strategic vision and realization Ability to articulate EA at CxO level Leading teams and projects

Associate Enterprise Architect 1-3 years of experience in Enterprise Architecture Hands-on skills to successfully implement ERP solutions Foundation knowledge of at least one domain in

Enterprise Architecture Works in a mentored position within an experienced

team

Professional Enterprise Architect 3-7 years of experience in Enterprise Architecture Professional ERP experience, advanced solution and

process knowledge, industry expertise Deep knowledge of at least 1-2 domains in Enterprise

Architecture T-shaped: broad view across several dimensions, plus

deep capability to understand a specific area Works independently within teams to realize EA

projects, capability of mentoring others

Master Level:Expert knowledge in Enterprise Architecture

Professional Level:Advanced knowledge in Enterprise Architecture

Associate Level:Foundation level knowledge in Enterprise Architecture. Skills to contribute to EA projects.

There are 3 levels of certification designed to address the different levels, and requirements of Enterprise Architects.

There is a defined progression path between the 3 levels

Each level is certified based on a combination of experience, knowledge, training and examination.

SAP AG 2009

SAP Enterprise Architect Curriculum

SOA200

SAP Enterprise Architect Framework Level I

5 DaysSOA100

Enterprise SOA Fundamentals

3 Days 2 Days

SOA250

SAP Enterprise Architect Framework Level II

5 Days

Certified Professional SAP Enterprise Architect

5 Days

Certified Associate SAP Enterprise Architect

Certified Associate SAP Enterprise Architect Curriculum

Certified Professional SAP Enterprise Architect Curriculum

SOA230

ARIS Toolset for SAP EAF

2 Days

Certified Associate SAP Enterprise Architect

Here are the Associate and Professional Curriculums.

The Associate path is the one most relevant to you today as the SOA200 course is the culmination of that certification.

The curriculums are being rolled out during Q2 and Q3 2007.

It is assumed that candidates will attend the SOA100 course before this SOA200 course to get a thorough grounding in SAP’s Enterprise Service Adoption roadmap.

Following SOA200, further detailed courses in TOGAF™, the use of the ARIS IT Architect toolset, and a more in-depth SOA250 course are available.

SAP AG 2009



© SAP AG 2007




We will now examine the background behind the SOA200 course.

SAP AG 2009

Course PrerequisitesCourse Prerequisites

Required Knowledge:

Fundamental understanding of basic business processes

Fundamental understanding of Service Oriented Architecture principles

Recommended Knowledge:

Basic knowledge of The Open Group Architecture Framework (TOGAF™)

TOGAF™ Version 9 Enterprise Edition – Introduction (free download in .pdf format)

TOGAF™ Version 9 Member’s Edition – (download in .pdf format and online document in html format for Open Group members only)

TOGAF™ Version 9: A Pocket Guide (hard copy for purchase)

TOGAF™ Version 9 (hard copy manual for purchase)

* Required for SAP Associate Enterprise Architect Certification

The course prerequisites are a combination of Required and Recommended Knowledge.

Some of this can be gained by attending existing SAP Education courses.

Particularly important for the SOA200 course is that delegates have completed the required course prereading on the background to the The Open Group Architecture Framework.

SAP AG 2007

This course is intended for the following audiences:

Enterprise Architects

Business Consultants

Solution Architects

IT Architects

Technology Architects

IT Managers

Program Managers

Business Process Experts

Duration: 5 days

Target Audience

The course is intended for a range of different roles who may be exposed to, or require further knowledge in, Enterprise Architecture.

The course is a 5 day attendance based course.

Course notes are provided for you to take away and refer to later.

These training materials are not a teach-yourself program. They complement the explanations provided by your course instructor. Space is provided on each page for you to note down additional information.

There may not be sufficient time during the course to complete all the exercises. The exercises provide additional examples that are covered during the course. You can also work through these examples in your own time to increase your understanding of the topics.

SAP AG 2009

Course Goals

This course will prepare you to:

Understand The Open Group Architecture Framework (TOGAF™) and how it differs from previous versions

Understand the features and benefits of the SAP Enterprise Architecture Framework in detail

Understand the additional value SAP is providing to TOGAF™

Take the SAP Enterprise Architect Certification

The main goal is to prepare you to pass the SAP Associate Enterprise Architect Certification exam.

This is a 60 multiple choice question exam.

As part of that preparation, you will understand the features and benefits of the SAP Enterprise Architecture Framework and what differentiates it from The Open Group Architecture Framework – TOGAF™.

This is not a TOGAF™ Certification Course – although you will also leave with an understanding of TOGAF™ – there is a seperate course – SOA220 designed to provide TOGAF™ Certification.

SAP AG 2009

Course Objectives

After completing this course, you will be able to:

Articulate the concept and benefits of Enterprise Architecture

Promote Enterprise Architecture inside an organization

Understand and explain the features of Enterprise Architecture frameworks

Analyze the business drivers to derive Enterprise Architecture requirements

Detect critical deficiencies in business, application, data, and technology environment

Analyze & determine enterprise impact of technology, industry and market trends

Identify which existing governance processes in an organization need to be involved

Work on assignments in the Enterprise Architecture space

After this course, you will be equipped to introduce the concepts and value of Enterprise Architecture into your organisation, understand the different frameworks available, and the unique features of the SAP Enterprise Architecture Framework.

You will be able to rigorously analyse business drivers, business processes and functions in order to identify the Information Systems and Technology required to support the organisation on its business mission.

SAP AG 2007



© SAP AG 2007




The precise 5 day course agenda now follows...

SAP AG 2009

Course Content

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques

Architecture ContentFramework

(including metamodel)

TOGAF™ 9.0

Templates Examples Case Study

Additional Usage Guidelines

SAP Business Reference Models

SAP EAF Extensions

SAP Technology Reference Models

SAP ContentTools

SAPImplementation

Tools

EA ModelingTools

SAP Enterprise Architecture Framework

This course explains the components of the SAP Enterprise Architecture Framework for Enterprise SOA.

The framework is an extension to the existing Open Group Architecture Framework that provides the specific additions and mappings required to accelerate architecture development in a package and package services environment.

The framework is not SAP specific – although SAP Specific Mappings are provided – the framework is open to all to use free-of-charge – and could be used successfully within any package and package services environment.

In the next 5 days – we will explore each of the components on this diagram in detail.

SAP AG 2009

SOA200 - SAP Enterprise Architecture Framework - Level I Training Course


Unit 1a - Overview of TOGAF™ and SAP Enterprise Architecture Framework

In this first unit – 1a – we will examine the SAP Enterprise Architecture Framework in overview.

©SAP AG SOA200 1-1

SAP AG 2009

Overview of SAP Enterprise Architecture Framework

Contents:

What is Enterprise Architecture ?

The SAP Enterprise Architecture Initiative

Enterprise Architecture Frameworks

Introduction to TOGAF™

The SAP Enterprise Architecture Framework

©SAP AG SOA200 1-2

SAP AG 2009

Unit 8 - Phase E: Opportunities and SolutionsUnit 9 - Phase F: Migration PlanningUnit 10 - Phase G and H: Implementation GovernanceUnit 11 - Enterprise Architecture GovernanceUnit 12 - TOGAF™ and SAP EAF for Specific Engagements

Unit 4 - Phase B: Business ArchitectureUnit 5 - Phase C: Information Systems Architecture - ApplicationsUnit 6 - Phase C: Information Systems Architecture - DataUnit 7 - Phase D: Technology Architecture

Unit 1d - Catalogs, Matrices and Diagrams Unit 1e - Architecture ProcessUnit 2 - Phase 0: Preliminary PhaseUnit 3 - Phase A: Architecture Vision


Unit 13 - SAP-Specific MappingsUnit 14 - EA Tools for TOGAF™ and SAP EAF


©SAP AG SOA200 1-3

SAP AG 2009

Lesson Objectives

After completing this lesson, you will understand :

What Enterprise Architecture is

Its Benefits

What an EA Framework provides

TOGAF™ and what it provides

The background to the development of the SAP Enterprise Architecture Framework

©SAP AG SOA200 1-4

SAP AG 2009

What is Enterprise Architecture?

What is Enterprise Architecture?





To begin with – we need to define what Enterprise Architecture is – there are many interpretations largely due to the how Enterprise Architecture has evolved over the years, and the varied nature of the role of Enterprise Architect depending on what organisation and what industry sector we examine.

Next, we will examine the reason why Enterprise Architecture is important to SAP and why SAP has established its Enterprise Architecture Initiative.

Before examining, the SAP EAF specifically, we will examine a number of existing well-known frameworks and look at their features. We will focus on TOGAF™ specifically as this forms the foundations of the SAP EAF.

©SAP AG SOA200 1-5

SAP AG 2007


Source: Copyright © 2006 Gartner Research

Enterprise Architecture is:

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.

The definition of the steps required, and the standards and guidelines to get from the current state to the desired future state.

There are many definitions of Enterprise Architecture.

They all focus on the definition of the structure of the desired state of an organization, and how to optimize that structure to ensure the organization meet’s its goals most effectively

www.whatis.com - An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives

www.wikipedia.org - Enterprise Architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure and process architecture as well.

©SAP AG SOA200 1-6

SAP AG 2009

Components of Enterprise Architecture

BusinessStrategy

Requirements

Programs

Projects

PortfolioAnalysis

BusinessArchitectureBusinessArchitecture

Business Processes,Workflows, Transactions

and Collaboration

DataArchitectureDataArchitecture

Technology ArchitectureTechnology Architecture Software, Hardware, Server, OS, Network

ApplicationArchitectureApplicationArchitecture

Systems, Services,Functional Use Cases

Data, Business Objects,Exchange Formats,

Security and Privacy

There are six main components of an enterprise architecture:

A Business Strategy or Set of Requirements will define “what the organization wants to achieve”

A Business Architecture will describe the organization, people and processes that need to be put in place to make that happen.

An Application Architecture describes how those processes are automated in the form of business software applications and how these integrate with each other.

A Data Architecture describes how those applications use data to inform the people and processes.

A Technology Architecture describes the infrastructure platform that the Applications run on, and the Data is stored and manipulated on.

Based on a definition of the TO-BE architecture of the organization, a set of change programs and projects can be defined that align to the TO-BE architecture to ensure that the organization meets its desired objectives.

©SAP AG SOA200 1-7

SAP AG 2009

External Drivers for Enterprise Architecture

More Compliance

Clinger-Cohen Act, Sarbanes-Oxley, COBIT, BASEL II

Identify systems and processes that are impacted by requirements and regulations

Introduce technology and processes without jeopardizing compliance

More Security Extending the enterprise and empowering it with technology

comes at a price

Security breaches are as likely to come from inside as outside

Need to understand risk and how to mitigate it

More Privacy

Price of failing to prevent inadvertent and intentional privacy breaches has never been higher.

Easily compromised by single points of vulnerability in process and technology, but by maintaining archives of data that should not have been preserved.

More Technology Refresh

Must be done cheaper, faster, and better in mind

Must be non-disruptive, affordable, and done smaller budgets

Drive for Productivity Globalization and scaling is driving complexity in the

organization

Need to identify cost avoidances and earnings enhancements.

The Clinger Cohen Act 1996 is designed to improve the way the US federal government acquires and manages information technology (IT).

The Sarbanes Oxley Act 2002 legislation is wide ranging and establishes new or enhanced standards for all U.S. public company boards, management, and public accounting firms , post Enron and Worldcom.

Basel II is the second of the Basel Accords , which are recommendations on Banking laws and regulations issued by the Basel Committee on Banking Supervision.

The Control Objectives for Information and related Technology (COBIT) is a set of best practices (framework) for information (IT) management created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI) in 1992. COBIT provides managers, auditors, and IT users with a set of generally accepted measures, indicators, processes and best practices to assist them in maximizing the benefits derived through the use of information technology and developing appropriate IT governance and control in a company.

With the general increased security agenda around the world, and the extension of organization's systems to the internet, how systems are built and protected, how they are hosted, and how they are accessed, becomes increasingly important to understand and manage.

As information becomes ubiquitous with the development of My Space, Google Maps, and electronic commerce, so the need to ensure data protection is implemented at the appropriate level is required. How information is created, managed, stored and disposed of in an organization becomes critical to understand.

As organizations strive to provide new and innovative products and services, the pressure on existing legacy systems increases, driving technology refresh programs to ensure the organization’s investment in technology is well managed. How business processes, data and software is implemented on the technology infrastructure becomes critical to understand in order for the organization to carry on its current services whilst introducing new ones.

©SAP AG SOA200 1-8

SAP AG 2009

Internal Drivers for Enterprise Architecture

Better planning, earlier visibility, and more informed designs will improve the chances of achieving these goals

Improve IT and business alignment

Just like Project Management; why would you not adopt it as a core discipline in your organization?

Business users want:

a fast response from IT

IT aligned to its business strategy

a dependable, stable environment, in order to improve business performance

IT practitioners want:

to make their own job easier and faster, and more reliable.

reduce complexity and cost.

Internally, Enterprise Architecture is the management discipline being introduced to meet the external drivers, but also to maximize the response from IT to the Business, and to ensure IT remains reliable, as simple as possible, and as inexpensive as possible.

EA brings benefits to both the Business and to IT, through the form of better planning, earlier visibility and more informed designs and plans.

Similar to Project Management, as a discipline it is becoming recognized as an essential function in an organization.

©SAP AG SOA200 1-9

SAP AG 2007

What Research has found

(Source : Ross, Weill, and Robertson – MIT CISR – 2006)

Massachusetts Institute of Technology (MIT)

Centre for Information Systems Research

Analyzed over 300 firms in 23 countries E.g. UPS, Johnson and Johnson, Dow Corning, Delta, BT, Toyota, Pfizer,

Nestle, Merrill Lynch

Why do they succeed ?

The study found 3 key disciplines as part of their “Foundation for Execution”

They had a clear Operating Model

Defines the level of process integration and standardization when delivering goods or services

They had established effective Corporate Governance

To ensure Business and IT achieve strategic objectives

They had defined an Enterprise Architecture

Organizes the logic of the business, information and technology to reflect the operating model

Takes the operating model from Vision to Reality

©SAP AG SOA200 1-10

SAP AG 2009

Benefits of Enterprise Architecture to the Business

It helps an organization achieve its business strategy

Without understanding business, application and technical architecture, a business doesn’t know what it has or doesn’t have

Faster time-to-market of new innovations and capabilities

If IT can introduce new technologies faster and functionalities faster, the organization can respond faster to competitive pressures faster

These areas are most likely to be spotted when business and IT staff collaborate closely in the EA process

More consistent business processes and information across business units

EA can unlock the power of information, unifying information silos that inhibit business processes

Identify processes, applications, and data that need to be consistent if consistent decisions are to be made

More reliability and security, and less risk

EA provides clear traceability between business processes, data, user roles, applications and infrastructure

It helps an organization achieve its business strategy

This means IT investment is targeted on the key business goals and performance.


This means Technology is ready when it is needed, transitions are smoother, and unnecessary change is minimized.

More consistent business processes and information across business units

This means opportunities for integration and reuse are identified that prevents the development of inconsistent processes and information.


This means a reliable architecture model aids consistency and manageability


SAP AG 2009

Benefits of Enterprise Architecture to IT

Better traceability of IT costs

EA provides greater understanding of the interrelated nature of business, application, and infrastructure assets

Lower IT costs - Design, buy, operate, support, change

A clear understanding of AS-IS and TO-BE architecture, and plan of how to progress from one to the other

Faster design and development

Earlier preparation for new technologies, smarter timing of projects, and the reuse of development best practices, standard designs and components

Less complexity

To solve duplication and overlap, an organization needs a comprehensive view of its applications, software, and infrastructure and their interrelatedness.

Standardization drives IT procurement efficiencies due to economies of scale

Less IT risk

Developing a TO-BE architecture and a managed migration plan means IT will be prepared to deliver new capabilities in a timely manner

IT effort will be aligned with the strategy and unexpected surprises will be avoided


This means greater understanding of how the architecture is structured, and enables more accurate service billing


This means investment can be tailored to the areas of most need, avoid duplication and identify reuse more frequently


This results in earlier preparation for new technologies, smarter timing of projects, and the reuse of development best practices, standard designs and components

Less complexity

This means Reduced skills maintenance, training, fewer support staff and simpler upgrades also result

Less IT risk

This enables efficient transitions to new capabilities.


SAP AG 2009

Triggers for Enterprise Architecture in the real world 1/2

Mergers and Acquisitions

Merging business services from multiple parties and removing duplication

Understanding the structure of the new organization in terms of business, data, applications and technology

Divestiture

Splitting business services between multiple parties

Understanding which parts of the business, data, applications and technology need to be transferred, segregated

Outsourcing

Transferring business services to a third-party

Understanding which functions, information and technology need to be changed

Competitive Environment

The need to deliver innovative services

Understanding how to change business processes, services and roles in a timely manner


SAP AG 2009





Legislation coming into force

New Data Privacy Legislation

Understanding which datasets, organizational roles and applications are affected

Technology Change

SAP introduces Netweaver platform and Enterprise SOA, or a specific technology goes out of support

Understanding which applications, interfaces, and roles are affected, and how to maximize potential

Global Consolidation and Standardization

Understanding where processes and systems are duplicated and identifying where consolidation and standardization can occur

Specific change events trigger organizations to adopt Enterprise Architecture

Despite the external and internal drivers for EA being compelling, specific events tend to trigger an organization's adoption of EA.

For example

A major change is required in business architecture (following a Merger/Acquisition or Divestiture)

A change in business strategy, goals and objectives requires a business change program to migrate to a new TO-BE state

A new technology becomes available that the organization wishes to capitalize on

New legislation coming into force drives changes in business processes, systems or data

Change drives the need for Enterprise Architecture as the organization needs to understand the impact of the change, and how it will facilitate the change


SAP AG 2009








SAP AG 2009

SAP Enterprise Architecture Initiative

EA tools, templates, examplesand guidelines

Integrated architecturedevelopment method and EA framework

Trained, certified and experiencedEnterprise Architects

Dedicated training and certification for Enterprise Architects

TRAINING

SERVICES

METHODOLOGY

TOOLS

SKILLS & RESOURCES

EA community including internal andexternal stakeholders

COMMUNITY

EAF

Vision, mission statements forEA, service offerings for projects and

management

SAP has defined its own Enterprise Architecture Initiative

This is made up of 6 streams :

Skills and Resources – recruiting, training and deploying SAP’s Global Hub of Enterprise Architects to work with customers and other SAP consultants

Methodology – the development and integration of the SAP EAF into existing SAP reference models

Tools – the SAP EAF and associated SAP and EA Tools

Services – a set of EA Services that customers can benefit from, to kickstart their Enterprise Architecture initiative

A Training Program (already shown in the Introduction Unit to this SOA200 course)

A Global Community connected via the internet (via SAP SDN)


SAP AG 2009








SAP AG 2007

What is an Enterprise Architecture Framework ?

Architecture development, maintenance and governance is complex

A framework provides a tool for:

Designing a broad range of architectures

Evaluating different architectures

Selecting and building the right architecture for an organization

Ensures the right components are developed as part of the architecture

Embodies best practices and acknowledged wisdom

A framework does not:

make architecture design an automatic process

provide a replacement for experienced Enterprise Architects

A framework should:

Reduce cost of development

Avoid regular reinvention of the wheel

Access to accumulated best practice process and capability

Provides a corporate memory for successes and failures


SAP AG 2007

What do Frameworks provide ?

So what existing Frameworks are used ?

A process to translate business requirements into IT architecture

Identify information requirements

Probe for supporting information and assumptions

Identify constraints and risk

A process to create useful models

Develop a consistent and comprehensive model

Show multiple views to communicate the model effectively

A process to validate, refine and expand the model

Verify assumptions

A process to manage the architecture

Monitor the model and update it

Persuade management that architecture principles cannot be ignored

Show system designers that architecture simplifies the problem


SAP AG 2009


!

Process Driven

VendorSpecific

Open Standard

ArtifactDriven

IndustrySpecific

DoDAF IFEAD IAFGartnerZachman TOGAF™TEAF SAP EAFFEAF

!

!! !!

= Yes and No. There is ambiguity about whether the framework can be 100% aligned to this characteristic. (See Slide Notes)

= Yes, this framework demonstrates this characteristic

This slide shows the some of the most popular frameworks used in the world today. It is not a comprehensive list but aims to show a representative sample

Frameworks tend to be :

Open – i.e. anyone can use them

Industry Specific – i.e. they have grown out of a specific industry problem or initiative and been tailored to the needs of that industry

Artifact Driven – i.e. they define what you need to produce not how to do it

Process Driven – i.e. they define how you need to do it – but not what to produce

Vendor specific – i.e. they are developed by a specific vendor of services/software

Zachman originated from the Manufacturing Industry and so in some cases does not always translate to all industries

SAP EAF is vendor-independent, but also contains SAP Specific Mappings.

DoDAF, FEAF and TEAF do contain example artifact specifications but are more process-centric.

QUESTION : What other frameworks deserve a mention ? What frameworks do people have most experience in here ?


SAP AG 2009

Other Vendor Specific Frameworks

Vendor Name Concepts

CSC Catalyst Enterprise Architecture Method

Processes, organisation, location, data, application,

technology

IBM Enterprise Architecture Consulting Method

(best practices)

Component Business Modeling - CBM

Business activities, valuechain

Service Oriented Analysis and Design - SOMA

Services, contracts

HP HP Global Method for IT Strategy and Architecture -ITSA

Business view, functionalview, technical view, implementation view

CSC has a global methodology for delivering all of its services called Catalyst. This incorporates the standard Catalyst Enterprise Architecture methodology, which has recently been updated to incorporate SOA patterns.

IBM has several methodologies for EA planning. These include its Enterprise Architecture Consulting Method, Component Business Model (CBM), and Service-Oriented Modeling and Architecture (SOMA). CBM addresses the business architecture domain, while SOMA tackles the application and technology domain.

HP has a global methodology for delivering all of its IT strategy consulting services called HP Global Method for IT Strategy and Architecture (ITSA). This incorporates a standard EA methodology, which uses TOGAF™ methodology.


SAP AG 2009

Other Vendor Specific Frameworks

Vendor Name Concepts

Atos Origin Atos Enterprise Architecture

Context, business, information , application,

infrastructure architecture

Accenture Enterprise Architecture Planning Methods

Information technolgoyenablement, alignment, management & delivery

Bearingpoint ProvenCourse for SOA Strategy, process, controls, technology

CSC has a global methodology for delivering all of its services called Catalyst. This incorporates the standard Catalyst Enterprise Architecture methodology, which has recently been updated to incorporate SOA patterns.

IBM has several methodologies for EA planning. These include its Enterprise Architecture Consulting Method, Component Business Model (CBM), and Service-Oriented Modeling and Architecture (SOMA). CBM addresses the business architecture domain, while SOMA tackles the application and technology domain.

HP has a global methodology for delivering all of its IT strategy consulting services called HP Global Method for IT Strategy and Architecture (ITSA). This incorporates a standard EA methodology, which uses TOGAF™ methodology.


SAP AG 2009

Artifact-Driven - The Zachman Framework

ENTERPRISE ARCHITECTURE – A FRAMEWORK TM

DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why

SCOPE(CONTEXTUAL)

ENTERPRISE MODEL (CONCEPTUAL)

??

Owner

SYSTEM MODEL (LOGICAL)

DESIGNER

TECHNOLOGY MODEL (PHYSICAL)

Builder

DETAILED REPRESEN-TATIONS (OUT-OF-CONTEXT)

FUNCTIONING ENTERPRISE

Sub-Constructor

SCOPE(CONTEXTUAL)

ENTERPRISE MODEL (CONCEPTUAL)

??

Owner

SYSTEM MODEL (LOGICAL)

DESIGNER

TECHNOLOGY MODEL (PHYSICAL)

Builder

DETAILED REPRESEN-TATIONS (OUT-OF-CONTEXT)

FUNCTIONING ENTERPRISE

Sub-Constructor

One of earliest frameworks

A positioning framework for artifacts

A way of categorizing deliverables

Not process-driven

History in Manufacturing

Broad acceptance


SAP AG 2007

Vendor Framework - Gartner’s Enterprise Architecture Framework

Perspective

Conceptual

Logical

Implementation

Architecture Viewpoints

Business Information Technical

Process Principles Org Requirements Functional Map

Logical ProcessModel

Organizational Rules

Detailed Org Models Detailed Process

Design

Inf. Principles Intgration Req‘s Information Flow Map

Data StewardshipRequirements

Data Design Rules Application Boundary

Models

Data interchangeprotocols

Application designpatterns

Service Level Reqmts

S‘ware Delivery Principles

Asset Criticality

Technical ReferenceModel (unpopulated)

Infrastructure Design Rules

Technical standards Infrastructure

Patterns

Process centric

Separation of concerns

Categorizes aspects

A holistic approach

Influential

Driven by industry analysts as opposed to EA Practitioners

Theoretical

Vendor specific


SAP AG 2007

Industry Specific - Department of Defense Architecture Framework (DoDAF)

ConceptualWHAT?

LogicalHOW?

PhysicalWITH WHAT?

BusinessOrganization Model

SystemConceptual Model

SoftwareConceptual Model

Node ConnectivityModel

SystemsLogical Model

Integration Model

Information FlowDiagram

System Phy


sicalModel

ImplementatModel

ion

OPERATIONAL CONTEXT

WHY?WHY?OPERATIONAL VIEW

SYSTEM VIEW

TECHNICAL VIEW

feedbackfrom theFIELDED

BASELINE

REQUIRE-MENTS &

CONSTRAINTS

STATE OF THE ARTUse of OFF-THE-SHELF CONCEPTS / PRODUCTS


History in Defense

Broad acceptance in Defense

Limited holistic perspective

Process/Planning centric

DoDAF was released in 2003 and supersedes the C4ISR Framework from 1996 put together as a response to the need for increasing joint and multi-national military operations.

DoDAF contains Guidelines for building architectures

A high level process for how to build the architecture A discussion of the data and tools required in that process Detailed descriptions of 26 different products/artifacts needed ; for example, logical data models,

systems-system matrix, technology standards catalog DoDAF has been expanded to include a set of reference models in line with FEAF

the DoD Performance Reference Model is a tool to help DoD managers more clearly justify and better manage their proposed IT investments.

the DoD Business Reference Model maps to the FEA BRM Lines of Business and sub-functions, and integrates DoD-specific Lines of Business and sub-functions

the DoD Service Component Reference Model classifies Service Components with respect to how they support business and/or performance objectives

The DoD Technical Reference Model outlines the standards, specifications, and technologies that collectively support the secure delivery of business and application components

The DoD Data Reference Model classifies data and DoD information with respect to how it supports the business of DoD and the government

Other derivative frameworks based on DoDAF include the NATO Architecture Framework (NAF) and Ministry of Defense (United Kingdom) Architecture Framework (MODAF).

SAP AG 2007

Portfolio of Products and Components.

End = Roadmap for Enterprise ImplementationCatalogues of used Standards

Timeframe of Change

•Enterprise Transformation Plan

•Enterprise Priority Setting

•Business Case

•Enterprise IS Alignment Impact

e.g. Blue Print of Technology Implementation

Interaction = Concepts of Service Layering

•Enterprise Technology Standards

Positioning = Allocation of IT Services ~ TRM

•Enterprise Infrastructure Profile

Type of Inter-Connection

•Enterprise Communication Profile

•Enterprise Security Profile

•Enterprise Governance Profile

•Enterprise Hardware Systems Profile

Node = Enterprise Business System Environm.

•Functional Requirements

Link = Enterprise Business System Connection

Characteristics = Time, Availability, Security, Maintainability, etc.

•As-Is Enterprise Infrastructure

Level of Inter-Connection

•Quality of Services

•Non-Functional Requirements

•TI Principles

• Enterprise Inter-Connection portfolio

• Enterprise Inter-Connection Qualityof Services (e.g. Security)

Extended Enterprise Inter-Connection

End = To-Be Inter-Connection Definitions

•Enterprise Inter-Connection Governance

•Enterprise Inter-Connection Standards

•Enterprise Inter-Connection Principles•Enterprise TI Portfolio

•Enterprise Business -Technology Enablers

Technology Goals, Drivers and Concepts

Node = Major Enterprise Business Location

•Enterprise Technology Infrastructure policy

•Enterprise Responsibility of TI

•Locations in which the Business Operates

•Enterprise Guiding Principles

Technology -Infrastructure

End = Roadmap for realization

e.g. Design of Application & Components

Priority = Dependencies

•Make or Buy Decision

• Implementation Roadmap

Timeframe of Change

•Business Case

•Governance Plan

•Security Impact

•Tools for Development / Implementation

Quality = Solution Interface Characteristics

Viewpoints = Selection of a Product SolutionsStructure = Spectrum of Styles & Solutions sets

Solutions for Interoperability

• Product-Specific Reference Solution (PSRS)

• Map PSRM to Product Solutions and options, etc.

End = PSRS

•Enterprise Interoperability Governance

Extended Enterprise Interoperability

•Enterprise Interface portfolio

•Enterprise Interoperability Standards

•Enterprise Collaboration Principles

End = To-Be Interoperability Definitions

•Enterprise Interoperability Quality of Services (e.g. Security)

•Enterprise Interoperability Policy

Systems Goals, Drivers and Concepts

•Enterprise Application portfolio

•System Development policy

•Enterprise Responsibility of IS

•Enterprise Guiding Principles

End = As-Is / To-Be Information-System landscape

•Business - Technology EnablersInformation –Systems

End = Activities to be supported by ICT

e.g. Information Roadmap

Selection = Set of ICT Supported Objects

Interface = Type of Information Exchange

Impact of Change

•Business Case

•Security Plan

• Information Systems Roadmap

•Type of Triggers / Events

Relation = Information Flow

•Grouping of Information Objects

•Type of Information Exchange•Formal / Informal

•Grouping of Information Resources

Solutions of Information Interaction

End = Information Solutions Sets

• Grouping of Information Types

Priority = Dependency of InformationDomains = Functional Areas


• Information Characteristics

End = Information ResourcesI/O = Business Resources


Policy = Business Purpose

Level of Information Interaction


• Information Relations

Activities = Critical / Overhead

Activities the Business Performs

Activities = Generic or Specific

• Internal / External Activities in Scope

• Internal / External Dependencies

•Ownership of Information

•Enterprise Information Policy

•Responsibilities & Competencies

End = Information Situation

Information

Business

What?

Conceptual Level

Goals & Objectives Requirements

What?

Conceptual Level


How?

Logical Level

Logical Representation

How?

Logical Level


With what?

Physical Level

Solution Representation

With what?

Physical Level


When?

Transformational Level

Enterprise Impact

When?


Enterprise Impact

Contextual Level

Vision / Strategy Business / Technology

DriversScope

Why?

Contextual Level


DriversScope

Why?

•Extended Business Drivers

•Scope of Collaboration

•Business Goals & Objectives, KPI’s

Business Goals, Drivers and Concepts

Ends/Means = As-Is / To-Be Business Situation

•Environmental Dynamics, e.g. Laws

Viewpoints = Competition, Value Net, etc.

•Corporate Strategic Plans

•Extended Guiding Principles

•Extended Business Drivers

•Scope of Collaboration

•Business Goals & Objectives, KPI’s



•Environmental Dynamics, e.g. Laws


•Corporate Strategic Plans

•Extended Guiding Principles

Structure = Interfaces


Level of Interoperability

•As-Is Information Systems Environment



• Information-Systems Behaviour


•Abstraction & Precision of Data

•Program Goals & Objectives

•Business Relationships

End = Business Purpose

•Business Requirements

Level of Business Collaboration

Characteristics = Time, Flexibility, Availability, Security, Maintainability, etc.


•Budget of Change

•Stakeholders / Win-Win Conditions

End = PIRS

•Shared & Pluggable IS Services / Solution sets

Type of Interoperability

•Product-Independent Reference Solution (PIRS)

•Choice of Middleware Technologies

Standards = IS Interoperability Standards

• Information Resources

• Information Tasks / Activities

Viewpoint = Interaction Perspective

• Information Objects & Relations

Type of Information Interaction

• Information Interaction• Information Flow Characteristics

End = Information Behaviour

• Information Locations

•Value Net Position

•Business Commitment

•Business Area Structure

Viewpoint = Business PerspectiveEnd = Business Behaviour

•Organisation Structure

Type of Business Collaboration

•Role Players / Actors

•Business Rules

•Business Culture

Connectivity = Middleware / Messaging, etc.

•Technology Overview

Node = Hardware + System Software, etc.

End = Structure of Relations, Products + Specifications

Solutions of Inter-Connection

•Solutions & Products for Inter-Connection

• Formats of Communication

•Security Integration

•Business Functions structure and relations

•Business Knowledge

Solutions of Business Collaboration

End = Business Outcome / Business Solutions

•Business Objects

•Business Benefits

•Technology Possibilities

•Business Tasks / Activities

•Business Resources •Enterprise Budget Plan

e.g. Business Process Redesign or Outsourcing

Granularity of Change

End = Enterprise Business Transformation

•Enterprise Transformation Roadmap

•Enterprise Business Case

•Enterprise Priority Plan

•Enterprise Governance Plan

Environmental Level

Value Net Relations Cooperating /

Collaborating Elements

With Who?

Environmental Level

Value Net Relations Cooperating /

Collaborating Elements

With Who?

Information = Critical / Overhead

Extended Enterprise Information Exchange

Information = Generic or Specific

•Activities out of Scope

•Extended Dependencies

•Parties Information Confidentiality

•Extended Information Exchange Services

•Extended Information Ownership

End = Ext. Enterprise Information Exchange

Information = Critical / Overhead

Extended Enterprise Information Exchange

Information = Generic or Specific

•Activities out of Scope

•Extended Dependencies

•Parties Information Confidentiality

•Extended Information Exchange Services

•Extended Information Ownership

End = Ext. Enterprise Information Exchange

Abstraction Levels

Aspect Areas

• Interface Definitions & Standards

• Interface Solutions• Implementation of Quality of Services

• Official & De-facto IS Standards

•Refinement Technical Reference Model

•Refinement Technical Reference Model

•Technical Reference Model & Standards

• IS Functions & behaviour

•Collaboration Contracts, Service Levels

•Scope of the Collaborative value

•Collaborative Business Goals & Objectives

Extended Enterprise Value Net

•Law & Regulations

Viewpoint = Collaborative Value, etc.

•Collaborative Value Parties

Ends/Means = As-Is / To-Be Collaborative Environment

•Collaboration Contracts, Service Levels

•Scope of the Collaborative value

•Collaborative Business Goals & Objectives

Extended Enterprise Value Net

•Law & Regulations

Viewpoint = Collaborative Value, etc.

•Collaborative Value Parties

Ends/Means = As-Is / To-Be Collaborative Environment

Open Standard - Extended Enterprise Architecture Framework (IFEAD)



Broad acceptance

Neutral/Open

Holistic Perspective


SAP AG 2009

ViewPointsViewPoints

Security / GovernanceSecurity / GovernanceSecurity / GovernanceArchitecture Architecture

BusinessBusinessBusiness InformationInformationInformation Information-Systems

InformationInformation--SystemsSystems

Technology-InfrastructureTechnologyTechnology--InfrastructureInfrastructure

Contextual Level


DriversScope

What?What?What?

Conceptual Level


How?How?How?

Logical Level


With what?With what?With what?

Physical Level


When?When?When?


Organisational Impact

Why?Why?Why?

Abstraction Levels Abstraction Levels Abstraction Levels

Aspect Areas Aspect Areas Aspect Areas

• TI Portfolio

• Business - Technology Enablers

Technology Goals, Drivers and Concepts

Node = Major Business Location

• Technology Infrastructure policy

• Responsibility of TI

• Locations in which the Business Operates

• Guiding Principles

• Integration Policy

Systems Goals, Drivers and Concepts

• Application portfolio

• System Development policy

• Responsibility of IS


End = To-Be Information-System Situation

• Business - Technology Enablers

Activities = Critical / Overhead

Activities the Business Performs

Activities = Generic or Specific

• Activities in Scope

• Dependencies of others

• Confidentiality of Information

• Information Policy

• Responsibilities & Competencies

End = Information Situation

• Business Drivers

• Scope of the Change

• Business Goals & Objectives, KPI’s



• Environmental Dynamics, e.g. Laws


• Corporate Strategic Plans


Node = Business System Environment

• Functional Requirements

Link = Business System Connection


• As-Is Infrastructure

Level of Inter-Connection

• Quality of Services

• Non-Functional Requirements

• TI Principles

Structure = Interfaces


Level of Interoperability

• As-Is Information Systems Environment



• Information-Systems Behaviour


• Abstraction & Precision of Data

Domains = Functional Areas


• Information Characteristics

End = Information ResourcesI/O = Business Resources


Policy = Business Purpose

Level of Information Interaction


• Information Relations

• Project Goals & Objectives

• Business Relationships

End = Business Purpose

• Business Requirements

Level of Business Collaboration

Characteristics = Time, Flexibility, Availability, Security, Maintainability, etc.


• Budget of Change

• Stakeholders / Win-Win Conditions

Interaction = Concepts of Layering

• Technology Standards

Positioning = Allocation of Services

• Infrastructure Profile

Type of Inter-Connection

• Communication Profile

• Security Profile

• Governance Profile

• Hardware Systems Profile

End = PIM

• Shared & Pluggable Services

Entities = Classes, Attributes & Associations

Type of Interoperability

• MDA Platform-Independent Modelling (PIM)• Business functionality and behavior

• Many Middleware Technologies

Standards = MDA Development Standards

• Information Resources

• Information Processes

Viewpoint = Human Perspective

• Information Objects & Relations

Type of Information Interaction

• Information Interaction

• Information Flow Characteristics

End = Information Behaviour

• Information Locations

• Value Net Position

• Business Commitment

• Business Area Structure

Viewpoint = Business Perspective

End = Business Behaviour

• Organisation Structure

Type of Business Collaboration

• Role Players / Actors

• Business Rules

• Business Culture

Connectivity = Middleware / Messaging, etc.

• Technology Overview

Node = Hardware + System Software, etc.

End = Structure of Relations, Products + Specifications

Solutions of Inter-Connection

• Solutions & Products for Inter-Connection

• Formats of Communication

• Security Integration

Quality = Component Characteristics

Viewpoints = Characteristics of a View

Structure = Spectrum of Styles

Solutions for Interoperability

• MDA Platform-Specific Modelling (PSM)

• Map PSM to application interfaces, code, GUI descriptors, SQL queries, etc.

End = PSM

• Type of Triggers / Events

Relation = Information Flow

• Grouping of Information Objects

• Type of Information Exchange•Formal / Informal

• Grouping of Information Resources

Solutions of Information Interaction

End = Information Outcome

• Grouping of Information Types

Priority = Dependency of Information

• Business Functions structure and relations

• Business Knowledge

Solutions of Business Collaboration

End = Business Outcome

• Business Objects

• Business Benefits

• Technology Possibilities

• Business Tasks / Activities

• Business Resources

Portfolio of Products and Components.

End = Roadmap for implementationCatalogues of used Standards

Timeframe of Change

• Transformation Plan

• Priority Setting

• Business Case

• IS Alignment Impact

e.g. Blue Print of Technology Implementation

End = Roadmap for realization

e.g. Design of Application & Components

Priority = Dependencies

• Make or Buy Decision

• Implementation Roadmap

Timeframe of Change

• Business Case

• Governance Plan

• Security Impact

• Tools for Development / Implementation

End = Activities to be supported by ICT

e.g. Information Roadmap

Selection = Set of ICT Supported Objects

Interface = Type of Information Exchange

Impact of Change

• Business Case

• Security Plan

• Information Systems Roadmap

• Budget Plan

e.g. Business Process Redesign or Outsourcing

Granularity of Change

End = Business Transformation

• Transformation Roadmap

• Business Case

• Priority Plan

• Governance Plan

Vendor Framework - Cap Gemini’s Integrated Architecture Framework



Categorizes aspects

Driven by EA Practitioners

A holistic approach

Limited acceptance

Vendor specific

Cap Gemini’s IAF was developed during the 1990s and its form and structure is heavily influenced by Zachman.

At the heart of the framework is a detailed multimodal, and set of roadmaps of how to populate that metamodel

It is recognized as one of the leading vendor specific frameworks and is used by many organizations.

Version 1 was in 1995

Version 4 is the current version as of June 2007.

“Capgemini stands out from the others as being more experienced at EA planning for SAP customers by a very large margin. Its Integrated Architecture Framework (IAF) EA Methodology has developed over the past 11 years, and is now a very mature and detailed product. It uses the TOGAF™ methodology for the higher levels, where it is more complete”

“How SAP Customers Can Manage Enterprise Architecture, Part 2: The Role of SAP’s European Partners” AMR Research Note (2006) Derek Prior, Natalie Burgess

Cap Gemini EA experience and IAF, along with TOGAF™, were used to develop the SAP EAF.


SAP AG 2007

Industry Specific - US - Federal Enterprise Architecture Framework (FEAF)

Federal Enterprise Architecture (FEA)

Business Reference Model (BRM)• Lines of Business• Agencies, Customers, Partners

Service Component Reference Model (SRM)• Service Domains, Service Types, Components• Access, Delivery Channels

Technical Reference Model (TRM)• Technologies, Standards, Specifications• Component Framework

Data Reference Model (DRM)• Business-focused data standardization• Cross-Agency Information Exchanges

Bu

siness &

Perfo

rman

ce-D

rivenA

pp

roach

Performance Reference Model (PRM)

• Government-wide Performance Measures & Outcomes• Line of Business-Specific Performance Measures & Outcomes

Co

mp

on

ent

-Based

Arch

itecture

The FEAF Methodology

An Enterprise Architecture Reference Architecture Framework

US Government Standard

Broad US Government Acceptance

Holistic perspective


The US Federal CIO Council published the Federal Enterprise Architecture Framework (FEAF), Version 1.1, in September 1999 as a response to the Clinger-Cohen Act (1996). The FEAF promotes shared development for U.S. federal processes, interoperability, and sharing of information among U.S. federal agencies and other governmental entities. It provides a detailed process and a set of views and models as guidance to Federal Agencies.

In 2002, based on FEAF, a Federal Enterprise Architecture was started. Five reference models have been developed and were published :

Performance Reference Model (PRM) – a framework for performance measurement providing common output measurements, allowing agencies to better manage the business of government, and a means to measure the success of IT investment.

Business Reference Model (BRM) - a framework facilitating a functional view of the lines of business, independent of the agencies, bureaus and offices performing them

Service Component Reference Model (SRM) - classifying Service Components according to how they support business and performance objectives. It serves to identify and classify horizontal and vertical Service Components supporting federal agencies and their IT investments and assets

Technical Reference Model (TRM) component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service capabilities

Data Reference Model (DRM) standard description and discovery of common data and the promotion of uniform data management practices.


SAP AG 2007

Functional

Information

Organisational

InfrastructureEnabler

Who and Why

What, How Much, andHow Frequently

How, Where, and When

Industry Specific - US - Treasury Enterprise Architecture Framework (TEAF)

FunctionalView

Information View

OrganizationalView

InfrastructureView

Bu

ilder

Per

spec

tive

Des

ign

er

Per

spec

tive

Ow

ner

Per

spec

tive

Pla

nn

erP

ersp

ecti

ve

History can be traced to FEAF

US Treasury Standard

Broad US Treasury Acceptance

Limited Holistic perspective


In July 2000, the Department of the Treasury published the Treasury Enterprise Architecture Framework.

The TEAF provides guidance to Treasury bureaus concerning the development and evolution of information systems architecture; a unifying concept, common principles, technologies, and standards for information systems; and a template for the development of the enterprise architecture.

The TEAF describes an architectural framework that supports Treasury's business processes in terms of work products. This framework guides the development and redesign of the business processes for various bureaus in order to meet the requirements of recent legislation in a rapidly changing technology environment. The TEAF prescribes architectural views and a set of essential and supporting work products to portray these views

TEAF contains specifically :

Guidance on the roles/responsibilities required and configuration management

Guidance on developing an EA approach

Guidance on creating an architecture repository

Example views and work products (i.e. architecture models and artifacts)


SAP AG 2009

Open Standard - The Open Group Architecture Framework (TOGAF™)

TOGAF is a trademark of the Open Group

Based on TOGAF™ 9 materials licensed from The Open Group Copyright © 2009

Includes an Architecture Development Method

Driven by EA Practitioners

Open Standard, Neutral

Broad acceptance

Holistic perspective


SAP AG 2009

Open Frameworks have an inter-related history

influenced

ISO/IEC14252

influenced

influenced

influenced

influencedinfluenced

influenced

influencedinfluenced

influenced

influenced

supported by

supported by

Supported by

adopted by

references

references

references

1985 1990 1995 2000 2005

influenced

influenced

influenced

influenced

Zachman1987

EAP1992

TISAF1997

FEAF1999

IAF v11996

IAF v3 EE2001

TAFIM

JTA

DoD TRMC4ISR1999

TOGAF™1995

TOGAF™2002

DoD AF2003

FEAF2003

E2AF2003

UVA Model1994

Zachman2003

XAF2003

TEAF2000

TOGAF™8.1

TOGAF™9.0

EAF2007

2009

influenced

influenced

influenced

influenced


SAP AG 2009

From TOGAF™ 8.1 to SAP EAF

SAP Enterprise Architecture team set up in August 2006

Enterprise Architects (most external to SAP) were recruited in 3Q and 4Q 2006

Discussions with Capgemini in 4Q 2006 for a joint EA Framework development

Development of SAP EAF started in January 2007 and completed in April 2007.

Launched at Sapphire and Open Group conferences April 2007.

SAP EAF content made available to customers, partners and the Open Group.

Successful customer pilot in UK June/July 2007.

SAP EA Services, SOA200 training course and Associate SAP EA certification developed in 2Q 2007.

Over 50 SOA200 training courses have been run globally – SOA200 is now SAP’ssecond most popular training course worldwide!

Successful adoption of SAP EAF by major SAP customers and many successes


SAP AG 2009

SAP EAF has contributed many significantadditional elements to TOGAF™ 9.0

© SAP 2008

TOGAF™ 8.1 SAP EAF TOGAF™ 9

2002 2007 2009

Standards

SAP Extensions


SAP AG 2009

Framework Summary

Most EA Frameworks :

have different evolutions

serve different purposes

are different in scope

are based on different Principles

have different Structures

are supported by different approaches

EA Frameworks originate from :

System Vendors – to provide a competitive solution

Consultancies – as a service differentiator

End-user organizations – for competitive advantage

Open standards forums - e.g. The Open Grouphttp://www.enterprise-

architecture.info

ISBN 1-4120-1607-X


SAP AG 2009







After Introductions and Logistics of the venue, its first useful to explain the background to the SAP Enterprise Architecture Curriculum.


SAP AG 2009

Why TOGAF™?

A reliable, proven method for developing an Enterprise Architecture developed by the Open Group

An open standard

Vendor neutral

TOGAF™ considered to be the most relevant Framework for SAP customers

Freely licensed

Intended to be tailored

http://www.opengroup.org

Posix -

Results from 2006 survey of TechEd attendees and online ASUG survey

33%0.54

22%0.35

18%0.29

11%0.13

8%0.06

4%0.04

2%0.03

2%0.01

1%0.17

TOGAF™ -

Zachman -

Gartner -

Capgemini -

DoDAF MoDAF -

FEAF -

OtherFW -

0 0,1 0,2 0,3 0,4 0,5 0,6

Question III.3: What are relevant frameworks for your sector?

Graph 11: Importance of enterprise architecture frameworks (108 responses)

Mean

NASCIO -

1%0.01

E2AF -


So we mentioned TOGAF™ – what is it ?

Ideal as its open, freely licensed, vendor neutral.

Reliable, proven

Open Group standard – SAP sponsor

The world had enough frameworks – feedback from Sapphire and TechEd last year said you didn’t want a vendor specific method


SAP AG 2009

What is TOGAF™?

An architectural framework not an architecture

Vendor-neutral – developed by user consensus

A valuable tool for:

Designing a broad range of architectures

Assisting the evaluation of different architectures

Selecting and building the right architecture for an organization

Presents a set of services, standards, design concepts, components and configurations

Guides the development of specific architectures

Correct use of TOGAF™ will lead to:

The use of common principles, assumptions and terminology

The development of information systems with better integration and interoperability, especially with respect to issues that affect the whole enterprise



SAP AG 2009

TOGAF™ Background

Developed by an International Consortium of IT Suppliers and Customers

Encourages development of Enterprise Architecture

Based on proven best practice

Learns from experience in other industries

Vendor-Neutral, generally applicable

Designed to be tailored

Future direction determined by broad industry consensus

A continuing base of Enterprise Architecture knowledge

All can contribute

All can benefit

Broadly adopted

Growing base of certified practitioners



SAP AG 2009

TOGAF™ is steered by The Open Group

The Open Group is a vendor and technology-neutral consortium, operating as ‘not-for-profit’, established in 1996 through the merger of X/Open and the OSF

Over 300 member organizations from industry, government and academia, with over 6,000 participants in The Open Group activities from 19 countries

50% of members from North America, 25% from Europe, and 25% from Asia-Pacific; all constituents work together in an open process

Key activities:

Defining, integrating and evolving standards to support Open systems e.g. UNIX

Certifications e.g. UNIX, LDAP and conformance testing

Vision of Boundaryless Information Flow™ with Enterprise Architecture as a key element

SAP is a Platinum member of the Open Group



SAP AG 2009

From TOGAF™ 8.1 to TOGAF™ 9

TOGAF™ 9 development has been underway since 2003

The development process was managed through the Open Group Architecture Forum

In 2008 Cap Gemini worked intensively on a fast-track submission which effectively became the TOGAF™ 9 draft specification, based on SAP EAF and other artefacts, materials and best practise

The TOGAF™ 9 draft was approved by the Open Group board in October 2008

TOGAF™ 9 was launched at the Open Group Conference in San Diego, February 2009


SAP AG 2009

TOGAF™ Components

TOGAF™ 9 – 744 pages of content!

Part I: Introduction

Part II: Architecture Development Method Core of TOGAF™. Step by step guidelines to develop

an enterprise architecture.

Part III: ADM Guidelines & Techniques Collection of guidelines and techniques applicable to

TOGAF™ and the ADM

Part IV: Architecture Content Framework Structured metamodel for architectural artifacts and

overview of typical architectural deliverables.

Part V: Enterprise Continuum & Tools Taxonomies and tools to categorize and store output

of architecture activites

Part VI: TOGAF™ Reference Models TOGAF™ Foundation Architecture, TRM, III-RM

Part VII: Architecture CapabilityFramework Organization, processes, skills and roles required to

operate an architecture function within an enterprise.

Parts III and IV are the sections containing the most significant new content

Most of these additional elements were taken directly from SAP EAF Summary

TOGAF™ Enterprise Continuum & Tools

TOGAF™ ADM & Content Framework

TOGAF™ Capability Framework

Architecture Development Method (Part II)

Architecture Capability Framework (Part VII)

Enterprise Continuum & Tools (Part V)

ADM Guidelines & Techniques (Part III)

Architecture Content Framework

(Part IV)

TOGAF™ Reference Models (Part VI)

Business Vision and

Drivers

Business Capabilities

Informs the Business

of the current state

Ensures Realization

of Business Vision

Informs the capability

Refines

Understanding

Business needs feed into method

Delivers new business solutions

Operational changes cause updates

Sets targets, KPIs, budgets for

architecture roles

Drives need for Architecture Capability

maturity

TOGAF™ Enterprise Continuum & Tools

TOGAF™ ADM & Content Framework

TOGAF™ Capability Framework

Architecture Development Method (Part II)

Architecture Capability Framework (Part VII)

Enterprise Continuum & Tools (Part V)

ADM Guidelines & Techniques (Part III)

Architecture Content Framework

(Part IV)

TOGAF™ Reference Models (Part VI)

Business Vision and

Drivers

Business Capabilities





Ensures Realization

of Business Vision


Ensures Realization

of Business Vision

Ensures Realization

of Business Vision



Refines

Understanding

Business needs feed into method

Refines

Understanding

Refines

Understanding

Business needs feed into methodBusiness needs feed into method






architecture roles


maturity


architecture roles


architecture roles


maturity


maturity



SAP AG 2009

The TOGAF™ Technical Reference Model


The objective of the TOGAF™Technical Reference Model is to provide a widely accepted core taxonomy

To facilitate communication

To enable systems to be analyzed in a consistent manner

To link to public databases of open standards

The Technical Reference Model comprises

A Taxonomy

An associated Technical Reference Model graphic

Qualities

Qualities

Infrastructure Applications Business Applications

Communication Infrastructure

Communications Infrastructure Interface

Network Services

Operating System Services

System

& N

etwo

rkM

anag

emen

t

So

ftware E

ng

ineerin

g

Application Platform Interface

Data M

anag

emen

t

Lo

cation

& D

irectory

Data In

terchan

ge

Intern

ation

al Op

eration

s

Tran

saction

Pro

cessing

Secu

rity

Grap

hics &

Imag

e

User In

terface

TOGAF™ acknowledges that one of the great difficulties in developing an architecture framework is in choosing a TRM that works for everyone.

The TOGAF™ TRM was originally derived from the Technical Architecture Framework for Information Management (TAFIM) TRM (which in turn was derived from the IEEE 1003.0 model -, ISO/IEC TR 14252 (IEEE Std 1003.0)).

The TRM is "platform-centric": it focuses on the services and structure of the underlying platform necessary to support the use and re-use of applications (i.e., on application portability).

In particular, it centers on the interfaces between that platform and the supported applications, and between the platform and the external environment.

TOGAF™ recognizes that organizations will need to develop their own TRM


SAP AG 2009

The TOGAF™ Standards Information Base (SIB)

A public database of open industry standards with links to conformant products

Available for web enabled access

http://www.opengroup.org/sib.htm

Search or full listing - With user guide

Structured according to the service categories of the TOGAF™ TRM

Can be used to:

Define particular services

Define properties of components

Be the basis of procurement procedures

Keeps the architecture up to date with the latest IT industry consensus


The Standards Information Base (SIB) is an Open Group database that can be used to dynamically generate lists, structured according to the TOGAF™ Technical Reference Model taxonomy, of the standards endorsed by The Open Group for use in open systems architectures.

The SIB can be used as a basis for defining (by service) all the standards that make up the target architecture, and all the software building blocks that will be used to implement it.

Originally held as part of the TOGAF™ document set, the Standards Information Base is now held in a database with web-enabled user access. You can access the SIB selectively through a search interface, according to your own defined criteria. Alternatively, you can view the entire SIB.

Both lists are generated dynamically from the database.


SAP AG 2009

TOGAF™ Building Blocks

Package of FunctionalityInterfaces Interoperates

Considers implementation and usageEvolves to exploit technology and standards

May be assembled from other Building Blocks May be a subassembly of other Building Blocks

Is reusable, replaceable, and well specified

TOGAF™ defines components of the architecture framework as building blocks.

A well designed set of building blocks can extend the lifecycle of legacy developments and improve the ROI



SAP AG 2009

Enterprise Architecture

IT Architecture

The Scope of TOGAF™ Enterprise Architecture

Technology Architecture How the technology fitstogether

Business ArchitectureHow the business isorganised to meet it’s objectives

Information Systems ArchitectureHow information systemssupport the objectives ofthe business

Baseline “As Is” Target “To Be”



SAP AG 2009

The TOGAF™ Architecture Development Method 2/6

AArchitecture

Vision

AArchitecture

Vision

RequirementsManagement


HArchitecture

ChangeManagement

HArchitecture

ChangeManagement

GImplementation

Governance

GImplementation

Governance

FMigrationPlanning

FMigrationPlanning

EOpportunities& Solutions


DTechnologyArchitecture


CInformation

SystemArchitectures

CInformation

SystemArchitectures

BBusiness

Architecture

BBusiness

Architecture

PreliminaryFramework &

Principles


Principles Prepare the organization for a

successful architecture project

Every stage of the project should be based on and validate current business

requirements



SAP AG 2009


AArchitecture

Vision

AArchitecture

Vision



HArchitecture

ChangeManagement

HArchitecture

ChangeManagement

GImplementation

Governance

GImplementation

Governance

FMigrationPlanning

FMigrationPlanning





CInformation

SystemArchitectures

CInformation

SystemArchitectures

BBusiness

Architecture

BBusiness

Architecture


Principles


Principles Develop architectures at

three levelsBUSINESS

SYSTEMS

andTECHNOLOGY

In each case develop

the baseline “as is”and target “to be”and analyse gaps

Establish an Architecture Vision for a single project



SAP AG 2009


AArchitecture

Vision

AArchitecture

Vision



HArchitecture

ChangeManagement

HArchitecture

ChangeManagement

GImplementation

Governance

GImplementation

Governance

FMigrationPlanning

FMigrationPlanning





CInformation

SystemArchitectures

CInformation

SystemArchitectures

BBusiness

Architecture

BBusiness

Architecture


Principles


Principles

Identify majorimplementation

projects

Analyse cost benefits and risk.

Produce implementation

roadmap



SAP AG 2009


AArchitecture

Vision

AArchitecture

Vision



HArchitecture

ChangeManagement

HArchitecture

ChangeManagement

GImplementation

Governance

GImplementation

Governance

FMigrationPlanning

FMigrationPlanning





CInformation

SystemArchitectures

CInformation

SystemArchitectures

BBusiness

Architecture

BBusiness

Architecture


Principles


Principles Ensure that the implementation

project conforms to the architecture



SAP AG 2009


AArchitecture

Vision

AArchitecture

Vision



HArchitecture

ChangeManagement

HArchitecture

ChangeManagement

GImplementation

Governance

GImplementation

Governance

FMigrationPlanning

FMigrationPlanning





CInformation

SystemArchitectures

CInformation

SystemArchitectures

BBusiness

Architecture

BBusiness

Architecture


Principles


Principles

Ensure that the architecture responds to

the needs of the enterprise



SAP AG 2009

The TOGAF™ Resource Base

The TOGAF™ Architecture Development Method is complemented by a wide range of advice and guidance based on industry best practice, for example: Architecture Governance Architecture Board Architecture Contracts Architecture Description Language Architecture Maturity Models Architecture Patterns Architecture Principles Architecture Reference Models and comparisons Architecture Skills Framework Architecture Tools Architecture Diagrams Business Scenarios Case Studies Other Architecture Frameworks TOGAF™ and the Zachman Framework



SAP AG 2009

Summary - The case for TOGAF™

The TOGAF™ Enterprise IT Architecture is a strategic plan for the IT systems within an enterprise

Description of the existing systems

Baseline architecture

Analysis and description of business and future system needs for your enterprise

Business requirements

Target architectures

Phased, prioritised plan to evolve towards the target

Migration plan

Architecture Governance



SAP AG 2009

Using TOGAF™ in an organization

TOGAF™ is designed to be flexible

Organizations may already have investments in a Foundation Architecture to use alongside TOGAF™ e.g.

Industry specific reference models can be used instead of TRM

Standards can be accessed other than via the SIB

Building blocks Information Bases

The Architecture Development Method (ADM) can be modified or merged with other methodologies

The strength of its flexibility to be adapted and applied to anyorganization in any industry no matter what their state

The combination of the TOGAF™ components gives the greatest benefit



SAP AG 2009

The SAP Enterprise Architecture Framework and TOGAF™ 9





The SAP Enterprise Architecture Framework and TOGAF™ 9


SAP AG 2009

SAP EAF extends TOGAF™ 9.0

TOGAF™ 8 EAF TOGAF™ 9

2002 2007 2009

Standards

SAP Extensions


SAP AG 2009

What is in the SAP Enterprise Architecture Framework?

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools

SAP Enterprise Architecture FrameworkSAP Tool Guides and Integration IDS-Scheer / ARIS Implementation of

Framework

Tool Guide for Solution Composer, Service Marketplace, Roadmap Composer, Solution Manager, Quick-Sizer, System Landscape Directory, Enterprise Services Repository

SAP-Specific Mappings SAP Enterprise Architecture Framework

terminology to SAP terminology mapping

SAP product to TOGAF™ TRM mapping

SAP Enterprise Architecture Framework method to SAP method mapping

SAP Glossary

Reference Content SAP Business Maps

SAP-TOGAF™ TRM Reference Model

SAP Product Availability Matrix


SAP AG 2009


EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools


Usage Guidelines Framework tailoring Engagement Initiation Using EA to implement SOA Service Contracts Business Capability Assessment Technology Capability Assessment IT Governance Impact Assessment Solution Architecture Scoping Glossary Case Studies and Examples

Case studies from real-world SAP architecture engagements

“BEEST case study” worked example

Examples for all defined architecture views and matrices

Candidate Architecture Principles


SAP AG 2009


EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools


Architecture Method Iterative architecture process

description

Worksheet for each architecture phase identifying inputs, steps and outputs

Narrative for each architecture phase explaining how to conduct the phase

Metamodel Architecture metamodel

Defined set of architecture catalogs, diagramms, and matrices


SAP AG 2009

Summary

This is the end of Unit 1a -Overview of the SAP Enterprise Architecture Framework

You should now understand :

What Enterprise Architecture is

Its Benefits

What an EA Framework provides

TOGAF™ and what it provides

The rationale behind the SAP Enterprise Architecture Framework

The background to the development of the SAP Enterprise Architecture Framework

The next Unit explains the Components of the framework in more detail

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools




SAP AG 2009

Unit 1b – Overview of TOGAF™ and SAP EAF Components


©SAP AG SOA200 2-1

SAP AG 2009

Overview of Components

Contents:

Overview of Framework Components

SAP EAF Process

SAP EAF Narratives and Accelerators

SAP EAF Metamodel

SAP EAF Catalogs, Matrices and Diagrams

SAP Specific Mappings

SAP EAF Case Study

ARIS Reference Implementation

©SAP AG SOA200 2-2

SAP AG 2009







©SAP AG SOA200 2-3

SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand thekey components of TOGAF™ and EAF in overview:

The process and why we need it

The narratives and accelerators and why we need them

The metamodel and why we need it

The catalogs, matrices and diagrams and why we need them

SAP Specific Mappings and why we need them

SAP EAF Case Study and why we need it

ARIS Reference Implementation and why we need it

©SAP AG SOA200 2-4

SAP AG 2009



SAP EAF Process

SAP EAF Metamodel



SAP EAF Case Study


©SAP AG SOA200 2-5

SAP AG 2009

SAP EAF Framework overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools


Let us look the major components of the Framework in a more detailed way….

This slide shows the major components and the artifacts that are available within each of these components

Going down from the top there is an overall description of the framework, SAP tooling environment, SAP content mappings, a supplier independent framework and a resource base

We can look at each of these components, the artifacts they contain in the subsequent sections and what benefits each one of these components offer during an EA engagement

©SAP AG SOA200 2-6

SAP AG 2009

SAP EAF Framework overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools


Reference Content SAP Business Maps

SAP-TOGAF™ TRM Reference Model

SAP Product Availability Matrix

SAP Tool Guides and Integration IDS-Scheer / ARIS Implementation of

Framework

Tool Guide for Solution Composer, Service Marketplace, Roadmap Composer, Solution Manager, Quick-Sizer, System Landscape Directory, Enterprise Services Repository

SAP-Specific Mappings SAP Enterprise Architecture Framework

terminology to SAP terminology mapping

SAP product to TOGAF™ TRM mapping

SAP Enterprise Architecture Framework method to SAP method mapping

SAP Glossary

Usage Guidelines Framework tailoring Engagement Initiation Using EA to implement SOA Service Contracts Business Capability Assessment Technology Capability Assessment IT Governance Impact Assessment Solution Architecture Scoping Glossary

Case Studies and Examples Case studies from real-world SAP

architecture engagements

“BEEST case study” worked example

Examples for all defined architecture views and matrices

Candidate Architecture Principles


description



Metamodel Architecture metamodel

Defined set of architecture catalogs, diagramms, and matrices

©SAP AG SOA200 2-7

SAP AG 2009

Detailed SAP EAF Document ViewOverall Description of SAP EAF

Supplier Independent Framework

Usage Guidelines

Templates , Examples and Case Studies

Architecture Development Method Content Metamodel

005: SAP EAF Executive Guide

000: SAP EAF Overall Process

002: SAP EAF Metamodel and View 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: Phase Worksheet

105: Phase Narrative






(App & Data)


IS – Data ArchitectureDescription

Technology Architecture Description

Opportunities and Solutions Description

Migration PlanningDescription








Architecture Change Management Description

Implementation GovernanceDescription

Requirements Management Description







Architecture Examples

101: ExampleArchitecturePrinciples

102: SAP EAF Tailoring Guide

104: Architecture CaseStudies in a Packaged

Environment

106: IT Governance

Review

201: Business Capability

Assessment

202: Technology Capability/ Maturity Assessment

203: Engagement Initiation 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


Templates Other Examples BEEST

007: SAP EAF Glossary

708: SAP EAF to SAP Method Mapping

802: BenefitsTracking

Guidelines

902: Solution ArchitectureTerms of Reference

903: Release Strategy

Guidelines

001: SAP EAF Overview

709: SAP Glossary

Let us look the major components of the Framework in a more detailed way….

This slide shows the major components and the artifacts that are available within each of these components

Going down from the top there is an overall description of the framework, SAP tooling environment, SAP content mappings, a supplier independent framework and a resource base

We can look at each of these components, the artifacts they contain in the subsequent sections and what benefits each one of these components offer during an EA engagement

©SAP AG SOA200 2-8

SAP AG 2007

SAP EAF Process


SAP EAF Process

SAP EAF Narratives and Accelerators

SAP EAF Metamodel

SAP EAF Catalogs, Matrices and Views


SAP EAF Case Study


©SAP AG SOA200 2-9

SAP AG 2009

A recap on the TOGAF™ ADM

TOGAF™ ADM provides a number of architectural phases (e.g. Business Architecture, Information Systems Architecture) in a cycle an overall process template for architectural

activity

TOGAF™ points out some architecture iterations

TOGAF™ ADM provides a narrative of each architecture phase, describing the phase in terms of objectives, approach, inputs, steps and outputs. an informal definition of the architecture content

structure and deliverables

TOGAF™ ADM provides cross-phase summaries on requirements management, phase inputs and phase outputs

TOGAF™ ADM provides a cross-phase section explaining the concept of architecture building blocks, which allow the Enterprise to be segmented into re-usable components.


Let us do a quick recap on TOGAF™

TOGAF™ ADM is a multi-phased method and it explicitly defines 4 distinct architecture domains

With in each phase, it has a narrative that is made up of objectives, approach, inputs, steps and outputs

TOGAF™ also addresses “requirements management” which serve as cross-phase touch point and inputs/outputs between phases

TOGAF™ introduces a concept of architecture building blocks that allow the enterprise to be segmented into re-usable components enabling a better analysis of the enterprise


SAP AG 2009

The evolution of the TOGAF™ ADM

TOGAF™ 8.1, SAP EAF and TOGAF™ 9.0

Preliminary Phase

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information System Architecture

Phase D: Technology Architecture

Phase E: Opportunities and Solutions

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture Change Management

Requirements Management

The essence of the TOGAF™ 8.1 ADM (the wheel) has been retained in TOGAF™ 9

New SAP EAF concepts such as Iteration Cycles and Process Styles (As-Is or To-BeFirst) have been carried forward directly and without change into TOGAF™ 9

Summary


SAP AG 2009

The concept of Iteration Cycles introduced in SAP EAF has been carried forward directly into TOGAF™ 9

Architecture Context Iterations

Architecture Definition Iterations

Architecture Deployment Iterations

Transition Planning Iterations


SAP AG 2009

The concept of Process Styles (As-Is or To-Be first) introduced in SAP EAF has been carried forward directly into TOGAF™ 9

Architecture Context

Architecture Definition Transformation Planning Architecture Deployment

SAP EAF Phase Initial Iteration Iteration 1 Iteration 2 Iteration n Iteration 1 Iteration n Iteration 1 Iteration n

Prelim Core Informal Informal Informal Light

Vision Core Informal Informal Informal Informal Informal Light

Business ArchitectureAs-Is Informal Core Light Core Informal Informal Light

To-Be Informal Informal Core Core Informal Informal Light

Application ArchitectureAs-Is Informal Core Light Core Informal Informal Light


Data ArchitectureAs-Is Informal Core Light Core Informal Informal Light


Technology ArchitectureAs-Is Informal Core Light Core Informal Informal Light


Opportunities and Solutions Informal Light Light Light Core Core Informal Informal

Migration Planning Informal Light Light Light Core Core Informal Informal

Implementation Governance Informal Informal Core Core

Change Management Informal Informal Informal Informal Informal Core Core

Core = primary focus activity for the iteration

Light = secondary focus activity for the iteration

Informal = potential activity in the iteration, not formally mentioned in the method


SAP AG 2009

More practical guidance has been added to the new TOGAF™ 9.0 phase descriptions

Phase 0: Preliminary Phase Similar to EAF, some new concepts

Phase A: Architecture Vision Similar to EAF, some new concepts

Phase B: Business Architecture Similar to EAF, same viewpoints

Phase C: Information System Architecture Similar to EAF, same viewpoints, generic

Phase D: Technology Architecture Similar to EAF, same viewpoints, generic

Phase E: Opportunities and Solutions Significantly improved over 8.1 and EAF

Phase F: Migration Planning Significantly improved over 8.1 and EAF

Phase G: Implementation Governance Different from EAF, very light in content

Phase H: Architecture Change Management Similar to EAF

Requirements Management Similar to EAF, very light in content


SAP AG 2009

Benefits

SAP EAF Process extends TOGAF™ ADM Process to cope with more specific Package and Service-Oriented scenarios

SAP EAF Process follows the TOGAF™ ADM AP EAF follows an open, vendor-neutral process

Why re-invent a perfectly good wheel ?

SAP EAF easily understandable by existing TOGAF™ Practitioners

SAP EAF Process extends the TOGAF™ ADM Can be tuned for different engagement models

SAP EAF Process more precisely defines specific tasks, products and terminology

Provides the hooks into SAP Specific Products and Services where required

What are the benefits of using EAF ADM and the overall process?

They provide more specific task advice and are more prescriptive on the steps an EA needs to take during the engagement


SAP AG 2009

TOGAF™ and SAP EAF Metamodel


SAP EAF Process




SAP EAF Case Study



SAP AG 2009

What is a metamodel ?

A metamodel is a precise definition of the constructs and rules needed for creating models of things

We create models because it is often too difficult to build the real thing

Metamodels are an attempt at formalizing the constructs of models

We create models as part of Enterprise Architecture because its too difficult to practice on a real enterprise

A Metamodel can be used as the data schema for an Enterprise Architecture Resource Base

Example of metamodel: UML class Diagram

So what is a metamodel

Define metamodel (notes – give the example of a map or globe)

Models help us to simplify complex subjects and facilitate easier understanding

They formalize the constructs of models

Since an enterprise is very complex, we develop a number of models to sufficiently describe various aspects of an enterprise

Finally the most important use of a EA metamodel is that it serves as a data schema for EA tools and resource base (for e.g. the metamodel objects can be mapped to the native objects of a EA tool such as ARIS by IDS Scheer)


SAP AG 2009

Structured Metamodel for SAP EA Framework Content (Simplified)

Underlying the catalogs, matrices and diagrams is a structured content metamodel. This can be implemented in a tool, or used as a checklist to support less formal modeling approaches

The TOGAF™ 9.0 metamodel is almost identical with the SAP EAF metamodel

In TOGAF™ 8.1 IAF concepts have been added to fill perceived gaps in the TOGAF™ narrative (e.g. Contracts, Information Components, Logical and Physical abstraction, etc)

An informal Conceptual, Logical, Physical abstraction layering is used in the Information Systems and Technology domains.

Business architecture is layered according to motivation, organization and function

Business Information System

Technology

Motivation

Organization

Function

Application Data


Implementation Governance Assets

Architecture Requirements

Strategic Context

Change Roadmaps

This slide depicts the content metamodel at the highest level of abstraction and captures all aspects of an enterprise, both architectural and non-architectural

The metamodel can be thought of three stripes or layers with the top and the bottom stripe depicting the non-architectural aspects of an enterprise

The middle stripe contains the architectural entities of an enterprise

Looking at the architecture context, it contains “strategic context” which forms the input to the architectural entities, “requirements” that are generated by developing the EA and identifying the gaps between “As-is” and “to-be” architectures and the “Change roadmaps” which identify the initiatives, their priority and the sequence of those initiatives

The business architecture attempts to model the motivational elements of the enterprise, how the enterprise is organizationally structured and what business capabilities it currently possesses

Information Systems artifacts tend to model the IT systems which include both applications and data (as classified by TOGAF™ ADM)

Technology artifacts capture procured technology assets that are used to implement, deploy and realize Information System solutions (including the HW/SW and Communication protocols)


SAP AG 2009

Structured Metamodel for SAP EA Framework Content

Business Information System Technology

Motivation

Organization

Function

Application Data

PlatformServices

LogicalTechnology Components

PhysicalTechnology Components

Data Entities

LogicalInformation

Components

PhysicalInformation

Components

Information System

Services

LogicalApplication

Components

PhysicalApplication

Components

Business Services ,

Contracts , Service Qualities

Processes , Events , Controls ,

ProductsFunctions

Organization Location Actor , Role

Drivers Goals Objectives Measures




Strategic Context

Change Roadmaps

Requirements Contraints Assumptions Gaps Work Packages

Capability and MaturityAssessments

TailoredArchitecture Method

Business Principles , Objectives and Drivers

ArchitecturePrinciples

ArchitectureVision

Standards Guidelines Specifications

Statements of Work

Transformation Plans

Underlying the catalogs, matrices and diagrams is a structured content metamodel. This can be implemented in a tool, or used as a checklist to support less formal modeling approaches

The TOGAF™ 9.0 metamodel is almost identical with the SAP EAF metamodel

In TOGAF™ 8.1 IAF concepts have been added to fill perceived gaps in the TOGAF™ narrative (e.g. Contracts, Information Components, Logical and Physical abstraction, etc)

An informal Conceptual, Logical, Physical abstraction layering is used in the Information Systems and Technology domains.

Business architecture is layered according to motivation, organization and function

Getting to the next level of details, we can look at the individual elements of each one of the metamodel entities

Go through Business, Info Systems and Technology architecture entities briefly….

EAF is built on TOGAF™ in collaboration with Capgemini and hence we have adopted IAF concepts to augment EAF


SAP AG 2009

Benefits of the Metamodel

Formalizes the definition of our enterprise Architecture

Aids communication and understanding

We know what we need when

Formalizes the relationships between objects

Clearer Business-IT traceability and alignment

Enables SAP Specific Mapping

Unit 13 - Review of SAP-Specific Mappings

Enables EA Tool Mapping

Unit 14 - ARIS extensions for SAP EAF

What are the benefits of the metamodel?

The metamodel formalizes the definition of EA and this facilitates common communication and understanding of the concepts

Formalizes the relationships between objects or entities and provides a much clearer and complete business-IT traceability

Enables SAP specific and EA tool specific mappings


SAP AG 2009




SAP EAF Case Study



SAP EAF Process



SAP AG 2007

EnterpriseSecurity

QA / Standards Groups

ProductSpecialists

TechnicalSpecialists

ProgrammeManagement Office

Procurement

HR

Executive

Line Management

BusinessDomainExperts

IT ServiceManagement

ApplicationManagement

InfrastructureManagement

Data / VoiceCommunications

Line

Management

Executive

Functional /Business ProcessExperts

CxO

Stakeholder Types

CorporateFunctions

End- UserOrganization

SystemOperations

ProjectOrganization


Motivation

Organization

Function

Application Data

PlatformServices



Data Entities

LogicalInformation Components

PhysicalInformation Components

Information System Services

LogicalApplication

Components

PhysicalApplication

Components

Business Services,

Contracts,Service Qualities

Processes, Events, Controls,

ProductsFunctions

Organization Location Actor, Role




Requirements

Strategic Context

Change Roadmaps

Requirements Contraints Assumptions Gaps Work Packages

Business Strategy Technology StrategyBusiness Principles,

Objectives and DriversArchitecturePrinciples Architecture Vision


Stakeholders with interest in Architecture

EAF requires to produce a Stakeholder map of the enterprise to ensure what “views” we need to produce as a part of this engagement later

Depending upon which stakeholder community their viewpoint of the enterprise is going to be slightly different

Metamodel organizes information about the enterprise so stakeholders can view and use specific parts of it relevant to them

EAs are interested in all of it in overview while others are only interested in parts

For e.g. END USER ORG – interested in objectives/measures/processes/functions

SYSTEMS OPERATIONS interested in platform services and technology

Enables us to design views specific to that stakeholder – see these later


SAP AG 2009

How do we present information to Stakeholders?

Metamodel

“Real World” Enterprise

Application Platform

Reference Models

-

Database Object

Database Object

DatabaseObject

Database Object

?Queries / Analysis Catalogs , Matrices

and Diagrams

Stakeholder Views

Stakeholder

Standard CatalogsMatrices and Diagrams

Architecture

Resource Base

InfrastructureCon solidation Extension Governance Extension

Process Modell ingExtension Data Mod elling Extension

Business / IT Al ignmentExtension CoreContent

ARCHITECTURE VISION, CONTEXT AND ROADMAP

BUSINESS ARCHITECTURE

TECHNOLOGY ARCHITECTUREAPPLICATION

ARCHITECTUREDATA ARCHITECTURE

AssociatedWith All Objects

Organisat ion Unit

Goal

Objective

MeasureGovernanceExtension

(Business, Informa tion System) ServiceServices are Contained in Core , Business / IS split supports the Bus iness / IT Alignment Extension

Function

Process

Actor

Role

ControlProcess Extension

EventProcess Extension

ProductProcess Extension

Data Entity

Logical Information ComponentData Extension

LocationInfr ast ructureConsolidation

Ex tens ion

Physica l Information Component

Data Exte nsion

Logical ApplicationComponent

Physical ApplicationComponentInf rastructure

C onsolidation Extension

Logical Technology Component

Infras tructure Consolidat ionExtension

Physical Technology Component

Pr inciple Constraint Requirement

Contrac tGovernanceExtension

Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Hostedin

IsHosted inIsHosted inEncapsulates

Encapsulates

Resideswithin

SuppliesIs Supplied By

IsRealised by Realises

Operateson

Is processedby

Provides, consumes

Is accessed and updated through

Resides within

Isimplemented on

Providesplatform forImplements

Is realisedthrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongst o

Co

nsum

es

Partici patesin

Interacts with, Performs

Performstaskin

Generates, Resolves

Produces

Is ProducedbyIs owned by

Owns

Suppor ts, Isper formed by

Accesses

Can beaccessed by

Orchestrates, decomposes

Supports, Isrealised by

Is bounded by

Provides governedinterf aceto access

Produces

IsProducedby

Involves

Part icipatesin

Involves

Is Resolved by, IsGeneratedby

Generates, Resolves

IsResolved by

Is Resolved by, Is Generated by

Resol vesSupports, Isrealised by

Orchestrates,

decompo

ses

Ensurescorrectoperationof

Isguided

by

Governs, Measures

Is governedand measuredbyIsProv ided to

Is owned and governed by

Is tracked against

Sets performancecrit eria for

Sets performancecriter ia for

Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises

Service QualityGovernanceExtension

Applies to

Meets

Applies to Meets

Is Performedby

Is Supplied orConsumed by

Supplies or Consumes

InfrastructureCon solidation Extension Governance Extension

Process Modell ingExtension Data Mod elling Extension

Business / IT Al ignmentExtension CoreContent






Organisat ion Unit

Goal

Objective


(Business, Informa tion System) ServiceServices are Contained in Core , Business / IS split supports the Bus iness / IT Alignment Extension

Function

Process

Actor

Role




Data Entity


LocationInfr ast ructureConsolidation

Ex tens ion

Physica l Information Component

Data Exte nsion



C onsolidation Extension


Infras tructure Consolidat ionExtension



Contrac tGovernanceExtension

Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Hostedin


Encapsulates

Resideswithin


IsRealised by Realises

Operateson

Is processedby

Provides, consumes


Resides within

Isimplemented on


Is realisedthrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongst o

Co

nsum

es

Partici patesin


Performstaskin

Generates, Resolves

Produces


Owns

Suppor ts, Isper formed by

Accesses

Can beaccessed by



Is bounded by

Provides governedinterf aceto access

Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguided

by

Governs, Measures



Is tracked against

Sets performancecrit eria for

Sets performancecriter ia for

Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby



Going through the EAF process, the deliverables required in each & every phase can be produced

They can be presented in a format (e.g. a Diagram) to satisfy the needs of a specific stakeholder group

Define matrices and catalogs of relevant architectural information

Capture all these deliverables in a common resource base that all can access


SAP AG 2009

Catalogs, Matrices and Diagrams 1/2

How Catalogs are defined


SAP AG 2009

Catalogs, Matrices and Diagrams 2/2

How Diagrams are defined


SAP AG 2009

Benefits of SAP EAF Catalogs, Matrices and Diagrams

Specific descriptions of each catalogs, matrix and diagram

Integrated into the TOGAF™ Process

Integrated into the TOGAF™ Metamodel

Integrated into an SAP EAF Stakeholder Map

Application Architecture

Core Diagrams

Catalogs

Matrices

Extension Diagrams

Data Architecture

Core Diagrams

Catalogs

Matrices

Extension Diagrams

Technology Architecture

Core Diagrams

Catalogs

Matrices

Extension Diagrams

Business Architecture

Core Diagrams

Catalogs

Matrices

Extension Diagrams

Functional Decomposition Diagram

Application Communication Diagram

Application / User Location Diagram

Conceptual / Logical ER Diagram

Data Dissemination Diagram

Data Entity/ Business Function Matrix

Environments /Locations Diagram

Organisation / Actor Catalog

Role Catalog

Actor/ Role Matrix

Application Portfolio Catalog

Technology Portfolio Catalog

Technology Standards Catalog

Service / Function Catalog

Role/ System Matrix

Data Entity/ Information ComponentCatalog

Location Catalog

Platform Decomposition Diagram

System / Data Matrix

Process Flow Diagram

Use Case Diagram

Organization Chart Diagram

Event Diagram

Process / System Realization Diagram

Enterprise Manageability Diagram

Data Lifecycle Diagram

Data Security Diagram

Networked Computing /Hardware Diagram

Communications Engineering Diagram

Process / Event / Control/ Product Catalog

Driver / Goal / Objective Catalog

System / Organisation Matrix

System / Function Matrix

System / Technology Matrix

Application Interaction Matrix

Business Interaction Matrix

Business Footprint Diagram

Service / Information Diagram

Goal /Objective / Service Diagram

Software Engineering Diagram

Software Distribution Diagram

Application Migration Diagram

Data Migration Diagram

Class Hierarchy Diagram

Processing Diagram

Contract / Measure Catalog

Interface Catalog

Core ContentBusiness / IT AlignmentExtension

Data Modelling ExtensionProcess ModellingExtension

Governance ExtensionInfrastructureConsolidation Extension

Architecture Vision

Core Diagrams

Value Chain Diagram Solution Concept Diagram

Matrices

Stakeholder Map Matrix

Opportunities and Solutions

Core Diagrams

Project Context Diagram Benefits Diagram

Requirements

Catalogs

Requirements Catalog

Preliminary

Catalogs

Principles Catalog

SAP EAF Catalogs, Matrices and

Diagrams provide stakeholder

content for Package and Service-Oriented

scenarios

This slide shows the detailed description of all the views, catalogs and matrices that need to be produced during each Phase in the EAF

The list of EA content related deliverables are integrated in to the EAF process, metamodel and the stakeholder map

The color codes represent which type of extension the artefact belongs to

It also identifies which of these deliverables are mandatory and which ones are optional

Typically in an engagement, the EA has to decide whether all or a subset of these deliverables need to be produced as a result of an engagement


SAP AG 2009



SAP EAF Process



SAP EAF Case Study




SAP AG 2009

Detailed Component ViewOverall Description of SAP EAF


Usage Guidelines









Case Study Material










(App & Data)























101: ExampleArchitecture

Principles



Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base
















Guidelines



Guidelines


709: SAP Glossary

Looking at the detailed components view, the focus of this Unit is highlighted in the red rectangles

We will go through the SAP specific mappings in detail

EAF offers a number of Accelerators and usage guides to support the EA during an engagement


SAP AG 2009

Why SAP Specific Mappings? 1/4

Business Solutions

Business Applications

mySAPBusiness Suite

Integration & Appl. Infrastructure

Computing Infrastructure

SAP xApps

Web

Sphere

.NE

T

SAP NetWeaver

TOGAF™ provides a holistic, vendor-neutral mechanism to describe an enterprise

SAP EAF provides a holistic, vendor-neutral mechanism to describe an enterprise featuring packages and packaged services

But . . . .

What about organizations with a significant investment already in SAP Products and Services ?

What about organizations planning a significant investment in SAP Products and Services ?

How can these customers accelerate their Enterprise Architecture development ?

How can organization’s re-use SAP’s Product Architecture ?

“Why should I spend months inventing my application architecture, when SAP provides me one ‘out-of-the-box” ?

The key difference between TOGAF™ & EAF is that TOGAF™ provides a holistic, vendor-neutral mechanism to describe any enterprise whereas

EAF provides a holistic, vendor-neutral mechanism to describe an enterprise featuring packages and packaged services

We included SAP specific mappings to satisfy the needs of organizations that already has significant SAP footprint or planning to transform to a significant SAP footprint

Support the enterprises to take an accelerated path to EA development

Support their re-use of SAP’s product architecture as much as possible


SAP AG 2009


SAP Business Reference

Content

SAP EAF Extensions

SAP TechnologyReference Models

SAP BusinessReference Models

SAP LandscapeContent

System Landscape Directory (SLD)

Solution Composer(Solution Maps)

Product Availability Matrix (PAM) S

olutio

n Ma

nager

Enterprise Service Repository (ESR)

Scenario & Process Component List

Technology

view

Business view

Applicationview

Let us look at why the EAF contains SAP specific mappings and why they are really important


SAP AG 2009



Content

Resource BaseExtensions







olution

Manage

r



Technology

view

Business view

Applicationview

SAP Reference Model content

Reusable models and patterns

Use directly or as template

If we closely examine the content and tools - like say Solution Composer or SLD

We can find two kinds of content

The first kind is the SAP content has a set of Reference Models – which serve as a starting point for tailoring or can be used “As-is”


SAP AG 2009



Content

Resource BaseExtensions







olution

Manage

r



Technology

view

Business view

Applicationview

SAP Landscape content

Accurate view of the AS-IS situation

What is running? What is installable? What is buyable?

The second is landscape Content – Help us understand things about our current or future technology architecture

It also helps to determine what is currently running, what can I install at what version and what I can buy off the shelf


SAP AG 2009

The Benefits of SAP Specific Mappings

Develop consistent, quality architectures quicker

SAP Specific Mappings enable the use of SAP’s Business and Technical Reference Models in Enterprise Architecture engagements

These can be re-used as part of solutions to promote consistency A Technical Reference Model (TRM) promotes the consistent use of IT

capability across the business, and effective re-use of building blocks TOGAF™ provides a Technical Reference Model to use as a useful,

consistent, structured definition of the application platform SAP Specific Mappings provide an SAP-specific Technical Reference

Model (TRM)

Again looking at the benefits of this component of the Framework

SAP content mappings facilitate the use of SAP Business and Technical reference models

They promote consistency

Similarly SAP content mappings also provide SAP specific TRM that references industry specific and cross-industry application products

NetWeaver based Application and integration platform products


SAP AG 2009

SAP Specific Mappings Summary

Create consistent, quality architectures quicker

How can these customers accelerate their Enterprise Architecture development ? Re-use of Architecture building

blocks and models

How can organization’s re-use SAP’s Product Architecture ? TOGAF™ Architecture Continuum is

designed for this purpose

Need for consistent taxonomy SAP EAF and SAP Specific Glossary

Need for SAP Specific Mappings Each SAP EAF Metamodel Entity

relates to SAP Specific Entity

Need for consistent classification of SAP Products SAP Specific TOGAF™ TRM

Source of Data SAP Term SAP EA Term

Solution Composer

Solution Manager

Business Goal

Business Objective

KPI

Value Chain

Value Chain Element

Business Scenario Group

Business Scenario

Scenario Configuration Variant

Process

Process Configuration Variant

Process Step

Business Participant

Employee, SAP Role

Measure

Objective

Goal

Driver

Role

Actor

Organisation

Location

Micro-Level Function

Service Contract

Macro-Level Function

Business Service

Solution Composer (NetWeaver Solution Map)

Service Marketplace Product Availability Matrix

System Landscape Directory

Software Component

Product Instance / Deployment Unit

Product Version

Product

IT Scenario

Platform Service






Software Component


Product Version

Product

IT Scenario

Platform Service






Software Component


Product Version

Product

IT Scenario

Software Component


Product Version

Product

IT Scenario

Platform Service



SDN ES WorkplaceEnterprise Service Repository

Business Object Node

Business Object

Process Component

Process Component

Enterprise Service

Process Component

Enterprise Service

Data Entity

Physical Information Component

Logical Information Component

Information System Service

Physical Application Component

Logical Application Component

Roadmap Composer Architecture Development MethodStrategy and Implementation

RoadmapsRoadmap Composer Architecture Development MethodStrategy and Implementation

Roadmaps

Service MarketplaceQuickSizer

Non-Functional RequirementsInfrastructure RequirementsService MarketplaceQuickSizer

Non-Functional RequirementsInfrastructure Requirements

Master Data

The SAP specific mappings are geared towards accelerating customer’s EA development

Enable the enterprise to re-use SAP Product architecture (in line with TOGAF™ Enterprise Continuum)

Provide an consistent taxonomy

Relate each Metamodel entity to SAP specific entity

SAP Specific TRM which classifies SAP products consistently


SAP AG 2009


SAP EAF Case Study


SAP EAF Process



SAP EAF Case Study



SAP AG 2009

SAP EAF Case Study

Catalog AuthoringService

CatalogPersonalization

Service

Catalog SearchService

CatalogComparison &

Promotion

Product Master Price Config Rules Customer Master Invoice Quota Contracts

ContractManagement

e-Price

ImpCRM

SAP R/3

ImpSales

DMS

BYB

e-ProcurementSAP BW

CRM

BEEST Portal

ImpDM S

mySAP SCM

Legacy CRM

ImpPrice

SAP VMS

Customer Relations W arehouse Supply Chain Management

Spare Par ts ManagementBackend SystemsSales & Marketing

Dealer LandscapeBEEST Systems

RNI Systems

ht tp/TCP

http/TCP

ht tp/TCP

http/TCP

Custom Interface

RFC

RFC

RFC

RFC

RFCCustom In terface

RFC

RFC

RFC

RFC

RFC

Custom Interface

RFC

Custom Interface

Custom Interface

Custom Interface

Custom Interface

TOGAF™ provides some examples of architecture content

SAP EAF provides an integrated case study

Based on a well-known SAP Education Case Study

Used to test the SAP EAF during its development

Worked through examples of all the main architecture products

The case study was intended to fulfill the shortcomings of TOGAF™

TOGAF™ offers very few examples of architecture content

EAF has an integrated case study to illustrate the concepts of the Framework with a practical application

Serves as a test of EAF during its development

The case study contains examples of key architectural deliverables from each phase


SAP AG 2009

BEEST - an Automotive OEM

An automotive company founded in 1931

Founded by Dr Ferdinand Beest

One of the world’s most profitable car manufacturers

11,668 employees

Products:

High performance sports cars made in Germany in the premium segment

Differentiators: performance, design and quality

Operations:

Focus Areas: Design, Engine Production, Sales and Marketing

Component manufacturing and final assembly partly outsourced for some models

BEEST value added: 10%-20%

Strategic Business Areas :

“Aftersales” due to revenue potential (car service training and spare partsdelivery)

Other business areas: Consulting, Engineering, IT and Financial Services to external customers

This slide provides an overview of BEEST Company


SAP AG 2009

Automotive Case Study in ARIS IT Architect

Case Study has been put together using ARIS

Proves the SAP EAF

Proves the ARIS Reference Implementation

Ability to demonstrate the SAP EAF more interactively

Show stakeholders what is possible, and an example of what can be done

Case Study is not used as part of SOA200

BEEST case study has been modeled in ARIS (using IT Architect & Business Architect products)

The tool based modeling helps to demonstrate EAF more interactively

Note that the case study is not part of this course by will be heavily featured in a follow on course called SOA250


SAP AG 2009



SAP EAF Process



SAP EAF Case Study




SAP AG 2007

Why we need Tools

Easier maintenance of architecture as the business and IT landscape changes

More effective knowledge sharing across the whole organization

Provides stakeholders with models most relevant to their role

More effective governance of artifacts

Promotes re-use of models

Promotes more consistent quality as the models are integrated

Everyone uses the same language

Provides one source of the truth properly managed

……not unmaintained, unconnected Visio and Excel files !

We need EA tools because…..

Following the initial population of the tool with the necessary objects, it becomes very easy to maintain the architecture as the business & IT landscape changes

The facilitates more effective knowledge sharing across the enterprise

Stakeholders can focus on the models that are very relevant to them

Facilitates governance and re-use of models

Normalizes the understanding of EA concepts

One source of truth about enterprise assets


SAP AG 2007

SAP EAF Reference Implementation in ARIS IT Architect 1/2

One of the models shown here as an example


SAP AG 2009

Summary

This is the end of the SAP EAF / TOGAF™Components Overview

You should now be aware of the different components :

ADM / Process

Metamodel

Catalogs, Matrices and Diagrams


SAP EAF Case Study


The next phase explains the metamodel in more detail

We are at the end of this unit and in Summary….

We reviewed the various components to SAP EAF and you should be familiar with the following components… (Notes – go through the bullet items)

In the next unit we will cover the EAF metamodel in more detail


SAP AG 2009

SOA200 - SAP Enterprise ArchitectureFramework - Level I Training Course

Unit 1c – Content Metamodel

©SAP AG SOA200 3-1

SAP AG 2009

Content Metamodel

Contents:

Introduction to the Content Metamodel

Rationale for the extension of TOGAF™ 8.1

Metamodel Concepts

Metamodel Entities and Relationships

Metamodel Extensions


©SAP AG SOA200 3-2

SAP AG 2009




Unit 8 - Phase E: Opportunities and SolutionsUnit 9 - Phase F: Migration PlanningUnit 10 - Phase G and H: Implementation GovernanceUnit 11 - Enterprise Architecture GovernanceUnit 12 - TOGAF™ and SAP EAF for Specific Engagements

Unit 13 - SAP-Specific MappingsUnit 14 - EA Tools for TOGAF™ and SAP EAF


©SAP AG SOA200 3-3

SAP AG 2009

Introduction to the TOGAF™ Content Metamodel


Rationale for the Extension of TOGAF™ 8.1

Metamodel Concepts




©SAP AG SOA200 3-4

SAP AG 2009


Business Information System

Technology

Motivation

Organization

Function

Application Data




Strategic Context

Change Roadmaps

The TOGAF™ Content Metamodel ensures we have a precise definition of the constructs and rules when creating architecture models

The Metamodel can be used as the data schema for an Enterprise Architecture Resource Base

It precisely defines each object

It precisely defines each relationship

This enables :

Definition of stakeholder “viewpoints”

Formal mappings with SAP reference models and products

A schema for an EA Tool to be developed

The SAP EAF metamodel provides a complete listing of the concerns that need to be understood in order to implement a large scale IT solution, whether ESOA or package-based.

By using the SAP EAF metamodel as an independent, authoritative checklist, it is possible to verify the completeness of thinking in any roadmap, or in customer strategies and visions.

Very few architecture frameworks contain a formal metamodel – Gartner provide a “value map” or high level metamodel, Cap Gemini’s IAF is one of the most complete metamodels.

By defining a formal metamodel, we can formalize the definition of an object and understand its potential relationships to other objects

This ensures we have a robust “information model” supporting our Enterprise Architecture

©SAP AG SOA200 3-5

SAP AG 2009




Metamodel Concepts




©SAP AG SOA200 3-6

SAP AG 2009

Rationale for the extension of TOGAF™ 8.1 1/2

TOGAF™ 8.1 did not contain a formal metamodel

TOGAF™ 8.1 did not precisely define key terms

TOGAF™ 8.1 did not precisely define views

In order to support the architecture tooling and interoperability required with package and service vendor reference models, we need to be more explicit about the way architecture is described, otherwise it is impossible to create these links

Architecture DevelopmentMethod

Enterprise Continuum Resource Base

Solutions Continuum Architecture Continuum

Table of Views

Glossary

Case Studies

ReferenceMaterials, Tools,

Techniques

Industry Architectures

Foundation Architectures

Common Systems Architectures

OrganizationArchitectures

Industry Solutions

Products and Services

Systems Solutions

Organization Solutions

TOGAF™ TRM

Phase Descriptions

Phase Inputs

Phase Outputs

Use of Keywords

Architecture Building Blocks Concept

Input and Output Descriptions

Phase Inputs

Phase Outputs

Use of Keywords

TOGAF™ 8.1

©SAP AG SOA200 3-7

SAP AG 2009

Rationale for the extension of TOGAF™ 2/2

How TOGAF™ 8.1 defined architecture viewpoints

How TOGAF™ 8.1 defined architecture entities

TOGAF™ 8.1 provided a narrative of each phase that contains reference to particular entities such as Business Service. The representation of these entities in a metamodel (entity, viewpoint, relationship, attribute) was left to the interpretation of the user. TOGAF™ 8.1 also provided a set of example viewpoints that were defined in name only, with no examples given

TOGAF™ 8.1 provided a narrative of each phase that contains reference to particular words, such as Business Service.

TOGAF™ 8.1 provided a glossary of terms but 80% of the key objects like Function or Business Service were not defined.

The representation of these words in a metamodel (entity, view, relationship, attribute) is therefore left to the interpretation of the user.

TOGAF™ 8.1 also provided a set of example views that were not defined beyond their name.

©SAP AG SOA200 3-8

SAP AG 2009

Metamodel Concepts



Metamodel Concepts




©SAP AG SOA200 3-9

SAP AG 2009

Concepts

Formal and Informal modeling Some architecture artifacts need formal modeling

Data Entities, Physical Technology Components etc

Others do not Statement of Work, Architecture Vision, Transformation Plans

Not everything needs to be in a metamodel

Core Metamodel Entities and Relationships What needs to be recorded ?

How is it inter-related ?

Explained shortly

Core and Extension Content Core content designed not to be altered or changed

Optional extensions defined to keep the core metamodel lightweight

Explained shortly

Catalogs, Matrices and Diagrams Viewpoints to meet the needs of the organization’s stakeholders

Unit 1D of this course (next) covers this

Just as in any Enterprise Architecture engagement, we have defined a set of principles in our extension of TOGAF™ and the creation of the metamodel.

The merging or removal of entities in the core metamodel is not recommended

These principles have been rigorously adhered to during the development of the metamodel.


SAP AG 2009


Introduction to the SAP EAF Metamodel


Metamodel Concepts





SAP AG 2009

SAP EAF Metamodel (Simplified by phase)

Business

Information System

TechnologyData Application


Architecture Realisation

Preliminary


Architecture Vision

Opps, Solutions & Migration Planning Implementation Governance

Preliminary Architecture Vision

Architecture Principles, Vision and Requirements artifacts are intended to capture the surrounding context of formal architecture models, including strategic context that forms input for architecture modeling, requirements generated from the architecture and change roadmaps showing transition between architecture states.

Business artifacts capture architectural models of business operation, looking specifically at factors that motivate the enterprise, how the enterprise is organizationally structured and also what functional capabilities the enterprise possesses.

Information Systems artifacts capture architecture models of IT systems, looking at applications and data in line with the TOGAF™ ADM phases

Technology artifacts capture procured technology assets that are used to implement and realize Information System solutions.


SAP AG 2009

SAP EAF Metamodel (Main Entities)


Motivation

Organization

Function

Application Data

PlatformServices



Data Entities

LogicalInformation

Components

PhysicalInformation

Components

Information System

Services

LogicalApplication

Components

PhysicalApplication

Components

Business Services, Contracts,

Service Qualities

Processes , Events, Controls,

ProductsFunctions






Architecture Vision

Implementation Governance

Requirements Contraints Assumptions Gaps

Business StrategyAssessments

TailoredIT Strategy Business Principles , Objectives and Drivers

ArchitectureVision

Stakeholders

Preliminary

ArchitecturePrinciples


Opportunities, Solutions and Migration Planning

Capabilities Work PackagesArchitecture

Contracts


SAP AG 2009

Key Entities 1/2

DRIVER An external or internal condition that motivates the organization to meet or redefine its

goals Global banking crisis giving reduced access to external capital

GOAL A high-level statement of intent or direction for an organization. Typically used to

measure success of an organization Deliver the best customer service in our industry

OBJECTIVE A time-bounded milestone for an organization used to demonstrate progress towards a

goal Increase capacity utilization by 30% by the end of 2009

ORGANISATION A self contained unit of resources with line management responsibility, goals, objectives

and measures. Organizations may include external parties and business partner organizations. The BEEST Automotive Organization

ACTOR A person, organization or system that has a role that initiates or interacts with activities.

Actors may be internal or external to an organization. A Sales representative who travels to visit customers

ROLE The usual or expected function of an actor, or the part somebody plans in a particular

action or event. An actor may have a number of roles. Warehouse Supervisor

FUNCTION Delivers business capabilities closely aligned to an organization, but not explicitly

governed by the organization. Make-to-Order Manufacturing

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

In either scenario, whether formally defined or not, the vision determines current business goals and longer-term strategy. In turn, these give rise to shorter-term tactical objectives, owned by individual actors (its employees or service providers), which collectively should realize the associated goal. Goals and objectives are defined, tracked, and monitored by measures, such as KPIs.

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


SAP AG 2009

Key Entities 2/2

BUSINESS SERVICE Supports business capabilities through an explicitly defined interface and is explicitly

governed by an organization. Credit Checking

PROCESS Represents flow of control between functions and/or services. A process flow describing

the Purchase Request Processing function, showing controls and events

APPLICATION COMPONENT An encapsulation of application functionality that is aligned to implementation structuring.

Purchasing Application

DATA ENTITY An encapsulation of data that is recognized by a business domain expert as a thing

Purchase Order

TECHNOLOGY COMPONENT An encapsulation of technology infrastructure that represents a class of technology

product or specific technology product. SAP Supply Chain Management

PLATFORM SERVICE A technical capability required to provide enabling infrastructure that supports the delivery

of applications. SAP NetWeaver Business Process Management

One of the main routes for a business to become more effective at what it does, is to automate certain key business processes using Information Technology. Not all parts of an organization are worth automating; not all automation that is feasible is necessarily desirable.

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

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

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

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

The complex array of technology components available lends itself to a classification into logical technology components, or classes. For example, databases, operating systems and networks. These are then realized by the most appropriate physical technology components for the job in hand. 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 at specific geographical locations (such as Data Centers, Office Premises etc).


SAP AG 2009

Core Entities and their RelationshipsOrganisation

Function

Application Component

IS Service

IS Service

IS Service

Driver

Goal


IS Service

IS Service

Organisation

Actor

Organisation

Data Entity

Data Entity

Technology Component Technology Component

Platform Service

Platform Service

Platform Service

Platform Service

Role

Data Entity Business Service

Business Service

Function

Function

Function

Function

Function

Function

Objective

Function

Data Entity

RoleActor

Function

Functions described units of business capability at all levels of granularity. The term function is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. Any bounded unit of business function should be described as a function.

Business Services support organizational objectives and are defined at a level of granularity consistent with the level of governance needed. A Business Service operates as a boundary for one or more functions. The granularity of Business Services is dependent on the focus and emphasis of the Business, as reflected by its Drivers, Goals and Objectives. A service in SOA terminology (i.e. a deployable unit of application functionality) is usually an Information Systems Service and typically made available as part of an Application Component

Business Services are deployed onto application components. Business Services may be realized by business activity that does not relate to IT, or may be supported by IT. Business Services that are supported by IT are deployed onto Application Components. It is possible for a Business Service to be supported by multiple Application Components, but this is problematic from a governance standpoint and is symptomatic of Business Services that are too coarse grained, or Application Components that are too fine grained.

Application components are deployed onto technology components. An application component is implemented by a suite of technology components. For example, an application, such as “HR System” would typically be implemented on several technology components, including hardware, application server software and application services.


SAP AG 2009

Refining the Relationships…what do stakeholders need?

EnterpriseSecurity


ProductSpecialists



Procurement

HR

Executive

Line Management






Line

Management

Executive


CxO

Stakeholder Types

CorporateFunctions

End - UserOrganization

SystemOperations

ProjectOrganization


Motivation

Organization

Function

Application Data

PlatformServices



Data Entities

LogicalInformation

Components

PhysicalInformation

Components


LogicalApplication

Components

PhysicalApplication

Components


Service Qualities


ProductsFunctions






Architecture Vision




TailoredIT Strategy Business Principles, Objectives and Drivers

ArchitectureVision

Stakeholders

PreliminaryArchitecture

Principles



Capabilities Work Packages ArchitectureContracts

One of the common factors in Enterprise Architecture Frameworks is their definition of stakeholder views.

Zachman began this theme in the 1980s

Zachman uses a two dimensional classification model based around the 6 basic communication interrogatives (What, How, Where, Who, When, and Why) intersecting 6 distinct model types which relate to stakeholder groups (Visionary, Owner, Designer, Builder, Implementer and Worker) to give an holistic view of the enterprise which is being modeled.

TOGAF™ considers the stakeholder groups in a more everyday fashion – relating the stakeholder groups to typical roles one finds in an organization.

We can then define each entity that each role is likely to be interested in.


SAP AG 2009

Content Metamodel (Main Entities including Extensions)


Motivation Organization Function - Static Function - Dynamic


TECHNOLOGY ARCHITECTURE

APPLICATION ARCHITECTURE

DATA ARCHITECTURE

Organisation Unit

MeasureGovernance Extension

Function Process

Actor

Role ControlProcess Extension



LocationInfrastructure

Consolidation Extension

ContractGovernance Extension

Driver

Service QualityGovernance Extension

Information System ServiceServices Extension

Data Entity


Physical Information ComponentData Extension


Physical ApplicationComponent

Infrastructure ConsolidationExtension




Platform Service

Business Service

Core Content

ServicesExtension

Data ModellingExtension

Process Modelling

ExtensionGovernance

Extension

InfrastructureConsolidationExtension

Principle Constraint Requirement GapWork

PackageAssumption

ExtensionMotivation

Goal

Objective

Motivation Extension



Measure - A quantitative performance indicator or success factor that can be traced on an ongoing basis to determine successful operation and progress towards objectives and goals – e.g. A Capacity Utilization KPI

Contract - An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction e.g. A Purchase Request service contract between an OEM and its main parts supplier

Service Quality - A preset configuration of non-functional attributes that may be assigned to a service or service contract – e.g. The Purchase Request Processing service provides a throughput rate of approx. 100,000 requests per 9-to-5 working day.

Event -An organizational state change that triggers processing –e.g. Purchase request approved

Control - A decision making step with accompanying decision logic used to determine execution approach for a process or to ensure that a process complies with governance criteria e.g. A sign-off control on the Purchase Request Processing process that checks whether the total value of the request is within the sign-off limits of the requestor

Product - Output generated by the business. The business product of the execution of a process – e.g. The Bullet GT automobile built by the BEEST luxury car manufacturer.

Location - A place where business activity takes place and can be hierarchically decomposed – e.g. BEEST’s Leipzig Assembly Plant where the Bullet GT is made.


SAP AG 2009

The need for Extensions

TOGAF™Core Content Metamodel

MotivationExtensions

Infrastructure Consolidation

Extensions

DataExtensions

Process Modelling

Extensions

Services Extensions

Governance Extensions

The removal or merging of entities in the metamodel is not recommended

Entities and relationships have been included for a reason

Extensions provide the ability to tailor the metamodel without losing consistency


SAP AG 2009

Content Metamodel showing Extensions and Relationships

White entities are “core” and should not be omitted Coloured entities are “extensions” and can be optionally added


SAP AG 2009


Introduction to the SAP EAF Metamodel


Metamodel Concepts





SAP AG 2009

The need for Metamodel Extensions 1/2

Extension to support in-depth operational governance

Extension to support linkage of drivers, goals and objectives to organizations and services

Extension to support data modelling

Extension to support consolidation of applications and technology across locations

Extension to support process modelling

Core Content Metamodel

MotivationExtensions


Extensions

DataExtensions


Process Modeling

Extensions

Service Extensions

Extension to support definition of discrete business and application services

TOGAF™ does consider Process Modeling in Business Architecture more formally than the other extensions listed here, and more formally than that required by Enterprise Architecture

It is therefore shown as included in TOGAF™ as an extension


SAP AG 2009

The need for Metamodel Extensions 2/2

Motivation Allows business functions, services and supporting applications, data and technology to be aligned

with overarching strategic business drivers, goals and objectives.

Governance allows additional structured data to be held against objectives and business services, supporting

operational governance of the landscape.

Services allows more sophisticated modeling of the service portfolio by creating a concept of IS Services in

addition to the core concept of Business Services. IS Services are directly supported by applications and creating the layer of abstraction relaxes the constraints on Business Services whilst simultaneously allowing technical stakeholders to put more formality into an IS Service catalogue.

Process Modelling allows detailed modeling of process flows by adding events, products and controls to the metamodel.

Typically Enterprise Architecture does not drill into process flow, but in certain process-centric or event-centric organizations, it may be necessary to elaborate process in a much more formal manner using this extension module.

Data allows more sophisticated modeling of the encapsulation of data. The core model provides a Data

Entity concept which supports the creation of data models, which is then extended by this extension to include the concept of an Information Component. Information Components form a Logical or Physical encapsulation of abstract Data Entities into units that can be governed and deployed into applications.

Infrastructure Consolidation intended to be used in landscapes where the application and technology portfolios have become

fragmented and the architecture seeks to consolidate the business as usual capability into a smaller number of locations, applications or technology components.

The metamodel extensions are defined as the typical areas that drive an Enterprise Architecture engagement.

They are not a definitive set but provide a guide to Enterprise Architects early on in an engagement of what objects will need to be examined and analyzed


SAP AG 2009

Motivation Extension 1/2


Organisation Unit


Business Service

ContractGovernance

Extension

Governs, Measures

Is governed and measured byIs tracked against

Sets performancecriteria for


Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises

Service QualityGovernance

Extension

Applies to

Meets

Applies to Meets

Goal

Objective

Driver


SAP AG 2009

Motivation Extension 2/2

The scope of this extension:

Creation of new metamodel entity for Driver that shows factors generally motivating or constraining an organization

Creation of new metamodel entity for Goal that shows the strategic purpose and mission of an organization

Creation of new metamodel entity for Objective that shows near to mid-term achievements that an organization would like to attain

This extension should be used in the following situations:

When the architecture needs to understand the motivation of organizations in more detail when the standard business or engagement principles and objectives that are informally modeled within the core content metamodel

When organizations have conflicting drivers and objective and that conflict needs to be understood and addressed in a structured form

When service levels are unknown or unclear


Organisation Unit


Business Service

ContractGovernanceExtension

Governs, Measures




Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Extension

Applies to

Meets

Applies to Meets

Goal

Objective

Driver


SAP AG 2009

Governance Extension 1/2


Organisation Unit


Business Service

ContractGovernance

Extension

Governs, Measures




Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Extension

Applies to

Meets

Applies to Meets

Goal

Objective

Driver


SAP AG 2009

Governance Extension 2/2

The scope of this extension:

The ability to apply measures to objectives and then link those measures to services

The ability to apply contracts to service communication or service interactions with external users and systems

The ability to define re-usable service qualities defining a service level profile that can be used in contracts.

Creation of additional viewpoints to show ownership and management of systems


When an organization is considering IT change that will result in a significant impact to existing operational governance models

When an organization has granular requirements for service levels that differ from service to service

When an organization is looking to transform its operational governance practice

When an organization has very strong focus on business drivers, goals and objectives and how these trace to service levels.


Organisation Unit


Business Service

ContractGovernance

Extension

Governs, Measures




Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Goal

Objective

Driver


SAP AG 2009

Services Extension 1/2




Organisation Unit

Objective

Business Service

FunctionProcessActor

Data EntityApplicationComponent

Technology Component

Owns and governs

Extends

Provides, consumesIs accessed and updated through

Is implemented onProvides

platform forImplements

Is realisedthrough

ConsumesIs bounded by

Provides governedinterface to access

Supports, isrealised by

Orchestrates,

decomposes

Is Provided toIs owned and governed by

Is trackedagainst

IS Service

ImplementsAutomated

Components of

AutomatedBy


SAP AG 2009

Services Extension 2/2




Organisation Unit

Objective

Business Service

FunctionProcessActor

Data EntityApplicationComponent

Technology Component

Owns and governs

Extends




Is realisedthrough

ConsumesIs bounded by


Supports, isrealised by

Orchestrates,

decomposes

Is Provided toIs owned and governed by

Is trackedagainst

IS Service

ImplementsAutomated

Components of

AutomatedBy

The scope of this extension is as follows:

Creation of IS Services as an extension of Business Service


When the business has a preset definition of its services that does not align well to technical and architectural needs.

When business and IT use different language to describe similar capabilities

Where IT service is misaligned with business need, particularly around the areas of quality of service, visibility of performance and management granularity.

Where IT is taking initial steps to engage business in discussions about IT architecture


SAP AG 2009

Process Modelling Extension 1/2


Organisation Unit

Business Service

Function

Process

Actor




Participatesin

Generates,

Resolves

Produces


Owns

Orchestrates,

decomposes


Produces

Is Producedby

Involves

Is Resolved by,

Is Generated by

Generates,

Resolves

Is Resolved by

Is Resolved by,Is Generated by

ResolvesSupports, Isrealised by

Ensures correctoperation of

Isg

uid

edby

Orch

estra

tes,de

com

pose

s


SAP AG 2009

Process Modelling Extension 2/2

The scope of this extension is as follows: Creation of Events as triggers for

processes

Creation of Controls that business logic and governance gates for process execution

Creation of Products to represent the output of a process

Creation of Event views to track triggers and state changes across the organization

This extension should be used in the following situations: Where the architecture must pay

specific attention to state and events

Where the architecture is required to explicitly identify and store process control steps, for example to support regulatory compliance

Where the architecture features critical or elaborate process flows


Organisation Unit

Business Service

Function

Process

Actor




Participatesin

Generates,

Resolves

Produces


Owns

Orchestrates,

decomposes


Produces

Is Producedby

Involves

Is Resolved by,

Is Generated by

Generates,

Resolves

Is Resolved by

Is Resolved by,Is Generated by



Isg

uided

by

Orch

estra

tes,d

ecomp

oses


SAP AG 2009

Data Extension 1/2


APPLICATION ARCHITECTUREDATA ARCHITECTURE

Business Service

Actor

Data Entity


LocationInfrastructureConsolidation

Extension



Physical ApplicationComponentInfrastructure


Is Hostedin

Is Hosted inEncapsulates

Encapsulates

Resides within

Is Realised by

Operateson

Is processedby

Provides, consumes


Resides within

Implements

Is realisedthrough

Contains

Is Supplied or Consumed by



SAP AG 2009

Data Extension 2/2

The scope of this extension is as follows: Creation of Logical Information Components that group Data Entities into encapsulated modules

for governance, security and deployment purposes

Creation of Physical Information Components that implement Logical Information components and are analogous to databases, registries, repositories, schemas and other techniques of segmenting data

Creation of Data Lifecycle, Data Security and Data Migration views of the architecture to show data concerns in more detail

This extension should be used in the following situations: Where the architecture features significant complexity and risk around the location, encapsulation,

management of or access to data


APPLICATION ARCHITECTUREDATA ARCHITECTURE

Business Service

Actor

Data Entity



Extension





Is Hostedin

Is Hosted inEncapsulates

Encapsulates

Resides within

Is Realised by

Operateson

Is processedby

Provides, consumes


Resides within

Implements

Is realisedthrough

Contains




SAP AG 2009

Infrastructure Consolidation Extension 1/2




Organisation Unit

Business Service

Actor

Data Entity



Extension








Platform Service

Operates in

Operates in

Is Hostedin

Is Hosted inIs Hosted inEncapsulates

Encapsulates

Resides within

Supplies Is Supplied By

Is Realised by Realises

Operateson

Is processedby


Resides within



Is realisedthrough

Contains


Co

nta

ins

Co

nta

ins

Co

nta

ins

Co

nta

ins


SAP AG 2009

Infrastructure Consolidation Extension 2/2

The scope of this extension is as follows: Creation of a Location entity to hold the location of IT assets and external consumers of service Creation of Logical and Physical Application components to abstract the capability of an application away from

the actual applications in existence Creation of Logical and Physical Application components to abstract product type from the actual technology

products in existence Creation of additional views focusing on the location of assets, compliance with standards, structure of

applications, application migration and infrastructure configuration

This extension should be used in the following situations: Where many technology products are in place with duplicate or overlapping capability Where many applications are in place with duplicate or overlapping functionality Where applications are geographically dispersed and the decision logic for determining the location of an

application is not well understood When applications are going to be migrated into a consolidated platform When application features are going to be migrated into a consolidated application




Organisation Unit

Business Service

Actor

Data Entity



Extension








Platform Service

Operates in

Operates in

Is Hostedin


Encapsulates

Resides within

Supplies Is Supplied By


Operateson

Is processedby


Resides within



Is realisedthrough

Contains

Is Supplied or Consumed byC

on

tain

s

Co

nta

ins

Co

nta

ins

Co

nta

ins


SAP AG 2009


Introduction to the Content Metamodel

Rationale for the Extension of TOGAF 8.1

Metamodel Concepts





SAP AG 2009


Formalizes the definition of our enterprise architecture

Aids communication and understanding

We know what we need to produce, when and how

Formalizes the relationships between objects

Clearer Business-IT traceability and alignment

Enables SAP-Specific Mapping

Unit 13 - SAP-Specific Mappings

Enables EA Tool Mapping

Unit 14 – EA Tools for TOGAF and SAP EAF


SAP AG 2009

Summary

This is the end of the Content Metamodel Unit


What a metamodel is

The rationale behind extending TOGAF 8.1 and introducing a content metamodel

The concepts adopted in the design of the metamodel

The entities and relationships in the metamodel

The metamodel extensions

The benefits offered by the metamodel

The next phase explains the Catalogs, Matrices and Diagrams in more detail


SAP AG 2009


Unit 1d - Catalogs, Matrices and Diagrams

©SAP AG SOA200 4-1

SAP AG 2009


Contents:

Meeting the Needs of Stakeholders

Catalogs

Matrices

Diagrams

Putting them to together to create Architecture

Questions and Answers

©SAP AG SOA200 4-2

SAP AG 2009


Unit 1d- Catalogs, Matrices and DiagramsUnit 1e - Architecture ProcessUnit 2 - Phase 0: Preliminary PhaseUnit 3 - Phase A: Architecture Vision





©SAP AG SOA200 4-3

SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand the reason for, and the structure of :

Catalogs

Matrices

Diagrams

How they address stakeholder concerns

How they are put together to form an architecture

©SAP AG SOA200 4-4

SAP AG 2009



Catalogs

Matrices

Diagrams



©SAP AG SOA200 4-5

SAP AG 2009

Meeting the Needs of Architecture Stakeholders

Architecture stakeholders are diverse and numerous

We need to verify that the AS-IS architecture is accurate and up-to-date

We need to verify that the TO-BE architecture will meet their needs

Architecture needs to be meaningful to each stakeholder

One single architecture model is too complex to apply to all stakeholders

We should use “Viewpoints” of our architecture in different forms

A stakeholder is a party who affects, or can be affected by, the organization's Enterprise Architecture

Project Organization System OperationsEnd-User Organization

External

Executives

Line Management

Business Domain Experts

Procurement HRProgram

Management Office

Enterprise Security


IT Service Managment

Service Desk




Executives

Line Management

Business Process/ Functional Experts

Technical Specialist

Product Specialist

Corporate Functions

Regulatory BodiesSuppliers

Data Owners

CxO

“Stakeholder” is a party who affects or can be affected by the organization’s EA

As a typical EA effort always has enterprise wide impact, there are number of Stakeholders and stakeholder categories that need to be taken into account

The stakeholders can help EA to verify and validate the “As-is” architecture is accurate and up-to-date

The EA need to ensure the target architecture will meet the Stakeholder needs effectively

More importantly, when we model various architectural domains during an EA engagement, one single model will be too complex and will not apply to all stakeholders

Different parts of the model must be presented as different “Viewpoints” to satisfy the needs of various Stakeholders

©SAP AG SOA200 4-6

SAP AG 2009

How TOGAF™ addresses Stakeholders 1/2

TOGAF™ identifies the stakeholders of architecture, their typical interest in architecture and provides techniques for tailoring architecture output to meet stakeholder needs.

EnterpriseSecurity


ProductSpecialists



Procurement

HR

Executive

Line Management






Line

Management

Executive


CxO

Stakeholder Types

CorporateFunctions


SystemOperations

ProjectOrganization


Motivation

Organization

Function

Application Data

PlatformServices



Data Entities

LogicalInformation

Components

PhysicalInformation

Components


LogicalApplication

Components

PhysicalApplication

Components


Service Qualities


ProductsFunctions






Architecture Vision





ArchitectureVision

Stakeholders


Principles




©SAP AG SOA200 4-7

SAP AG 2009

How TOGAF™ addresses Stakeholders 2/2

EnterpriseSecurity


ProductSpecialists



Procurement

HR

Executive

Line Management






Line

Management

Executive


CxO

Stakeholder Types

CorporateFunctions


SystemOperations

ProjectOrganization

Required architecture

deliverables are dependent on

stakeholder role, interest and

influence

Stakeholder “Power Grid”

Hig

h

High

Lo

w

Low

Po

wer

Level of Interest

Keep Satisfied

Minimal Effort

Key Players

Keep Informed

TOGAF™ identifies the stakeholders of architecture, their typical interest in architecture and provides techniques for tailoring architecture output to meet stakeholder needs.


Motivation

Organization

Function

Application Data

PlatformServices



Data Entities

LogicalInformation

Components

PhysicalInformation

Components


LogicalApplication

Components

PhysicalApplication

Components


Service Qualities


ProductsFunctions






Architecture Vision





ArchitectureVision

Stakeholders


Principles




TOGAF™ prescribes a methodical step by step approach and a set of tools to

Identify the Stakeholders

Analyze the Stakeholders

Understand their needs and

Determine which set of deliverables need to be produced for each of the stakeholder or stakeholder groups

Let us look at each of the steps in detail

©SAP AG SOA200 4-8

SAP AG 2009

Identify the key stakeholders of the Enterprise Architecture Brainstorm who the main EA stakeholders are.

Think of the people who are affected by it, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion.

E.g. Senior executives, Project Organization roles, Customer Organization roles, System Developers, Alliance partners, Suppliers, IT Operations, and Customers

Develop a good understanding of each stakeholder Record and classify each one using a matrix

Work out the power, influence and interest of each stakeholder Indicates the strategy to adopt for engaging with them

Stakeholder Analysis 1/2

MMLMMMJeff BrownCFO

HMLHMHJohn SmithCIO

Required support

Required commitment

Current commitment

Required understanding

Current understanding

Ability to disrupt the

change

StakeholderStakeholder Group

High

Low

Power

Interest HighLow

KeepSatisfied

Manage Closely

Monitor (Minimum Effort)

KeepInformed

Michael Smith

Dora Brown

Piers Marshall

Maureen Moss

Janet Blechar

Amanda McKay

Jose Hernanz

Mike Wilkins

The stakeholder analysis involves both identifying the key Stakeholders and analyzing them

Develop a good understanding of each of the Stakeholder or Stakeholder groups

Develop a Power/Interest quadrants and place the Stakeholder or Stakeholder groups in each quadrant

This will help identify the strategy needed to engaging with them and fulfill their needs

©SAP AG SOA200 4-9

SAP AG 2009

Stakeholder Analysis 2/2

For each stakeholder group Identify the Viewpoints that the Architecture Engagement needs to produce and

validate to deliver an effective Architecture Model.

Produce a Stakeholder Map using the template provided by TOGAF™

RoadmapsBusiness

Footprint/Strategy MapApplication

CommunicationFunctional

Decomposition

KEEP SATISFIED

This stakeholder group is interested in prioritizing, funding and aligning change activity. An understanding of project content and technical dependencies between projects adds a further dimension of richness to portfolio management decision making.

Project Portfolio Managers

Program Management

Office

Corporate Functions

Business Footprint/Strategy MapGoal/Objective/Service

ModelOrganization Chart

KEEP SATISFIED

This stakeholder group is interested in the high level drivers, goals and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business.

CEO, CFO, CIO, COO

CxOCorporate Functions

ViewpointsCLASSRATIONALEEXAMPLE

ROLESCLASS

STAKEHOLDER CATEGORY

Continuing with the analysis

For each Stakeholder or Stakeholder group, clearly identify what Viewpoints need to be produced

This slide provides a quick example of the stakeholder matrix/map that can be developed


SAP AG 2009

How do we present information to Stakeholders?

The metamodel structures architectural information to meet stakeholder needs.

Most architecture stakeholders do not actually need to know or see the whole model

Most are only concerned with specific issues what functionality does this

application support?”

“which processes will be impacted by this project?

In order to meet the needs of these stakeholders, we use the TOGAF™ concept of Viewpoints: Catalogs

Matrices

Diagrams

Once the Stakeholder map has been developed, next is to determine how to present the information to the Stakeholders

The Content Metamodel provides the details of what information is needed to fulfill the needs of the Stakeholders

Usually, most Stakeholders do not actually require or even interested to see the whole model

They are generally concerned about specific aspects the architecture models namely

What functionality does this application support or

Which processes will be impacted by this project

In order to meet the needs of these Stakeholders, TOGAF™ uses the concept of Viewpoints, which can be Catalogs, Matrices or Diagrams


SAP AG 2009

Definition of Catalogs, Matrices and Diagrams

Catalogs Lists of building blocks of a specific type, or of related types, that are used for

governance or reference purposes. For example, an application catalog listing all the applications used in an

organization .

Matrices Grids that show relationships between 2 or more metamodel entities. Matrices are used to represent relationships that are list-based rather than

graphical in their usage For example, a CRUD matrix showing which applications Create, Update and

Delete a particular type of data is difficult to represent visually.

Diagrams Renderings of architectural content in a graphical format to allow stakeholders

to retrieve and examine the required information. Diagrams can also be used as a technique for graphically populating

architecture content or for checking the completeness of information that has been collected.

TOGAF™ defines a complete set of architecture diagrams to be created in an engagement. organization chart). Each of these diagrams may be created multiple times for an architecture with different style or content coverage to suit stakeholder concerns.

Let us look at the definition of Catalogs, Matrices and Diagrams

Catalogs…

Matrices….

Diagrams….


SAP AG 2009

Catalogs, Matrices and Diagrams Produced in a TOGAF™Architecture Engagement

A typical TOGAF™architecture has a set of catalogs, matrices and diagrams

Some diagrams and catalogs are optional and are only required in specific types of engagement

Each engagement will tailor this approach to engagement size, engagement vision, stakeholder need, etc.

Other outputs not shown in this diagram are also produced, such as capability assessments, specifications, etc.


Core Diagrams

Catalogs

Matrices

Extension Diagrams

Data Architecture

Core Diagrams

Catalogs

Matrices

Extension Diagrams


Core Diagrams

Catalogs

Matrices

Extension Diagrams


Core Diagrams

Catalogs

Matrices

Extension Diagrams



Application and User LocationDiagram

Class Diagram /


Data Entity/ Business Function Matrix

Environments and LocationsDiagram


Role Catalog

Actor/ Role Matrix





Role/ System Matrix

Data Entity/ Data ComponentCatalog

Location Catalog




Business Use Case Diagram

Organization DecompositionDiagram

Event Diagram

/ Process/System Realization

Diagram

Enterprise ManageabilityDiagram



Networked Computing /Hardware Diagram


Process / Event / Control/ Product Catalog


System / Organisation Matrix






Service/Information Diagram

Goal/Objective/Service Diagram





Entity Hierarchy Diagram

Processing Diagram

Contract/ Measure Catalog

Interface Catalog

Core ContentServices / Extension

Data ModellingExtension

Process ModellingExtension

GovernanceExtension

InfrastructureConsolidation Extension

Architecture Vision

Core Diagrams


Matrices



Core Diagrams

Project Context Diagram Benefits Diagram

Requirements

Catalogs


Preliminary

Catalogs

Principles Catalog

System Use-Case Diagram


This slide depicts the deliverable map of a typical EA engagement organized by EAF phases (this is really an eye chart)

It contains a large number of Catalogs, Matrices and Diagrams

Some Diagrams are mandatory while others are optional

Not all these deliverables are applicable to every single engagement, the idea is to tailor this to fit the engagement size, vision and stakeholder needs

There are other deliverables shown here besides Catalogs, Matrices and Diagrams


SAP AG 2009

Catalogs


Catalogs

Matrices

Diagrams




SAP AG 2009

Catalogs by Architecture Phase

Preliminary



Data Architecture


Requirements

Principles catalog

Organization / Actor Catalog


Role Catalog


Location Catalog

Process / Event / Control / Product Catalog



Interface Catalog

Data Entity / Data Component Catalog




This is a listing of all the catalogs again organized by each TOGAF™ Phase.


SAP AG 2009

Matrices


Catalogs

Matrices

Diagrams




SAP AG 2009

Matrices by Architecture Phase


Data Architecture



Architecture Vision Stakeholder Map Matrix


Actor / Role Matrix

System / Organization Matrix

System / Role Matrix



Data Entity / Business function Matrix


System Technology Matrix

This is a listing of all the Matrices again organized by each TOGAF™ Phase


SAP AG 2009

Diagrams


Catalogs

Matrices

Diagrams




SAP AG 2009

Core Diagrams by Architecture Phase



Data Architecture



Architecture Vision Value Chain Diagram

Solution Concept Diagram




Product Lifecycle Diagram



System / Use Case Diagram

Class Diagram


Environments and Locations Diagram


Project Context Diagram

Benefits Diagram

This is a listing of all the Core Diagrams organized by each TOGAF™ Phase


SAP AG 2009

Extension Diagrams by Architecture Phase


Data Architecture



Goal / Objective / Service Diagram

Business Use Case Diagram

Organization Decomposition Diagram


Event Diagram









Entity Hierarchy Diagram


Processing Diagram

Network Communications Diagram


This is a listing of all the Extension Diagrams organized by each TOGAF™ Phase


SAP AG 2009



Catalogs

Matrices

Diagrams




SAP AG 2009

The Process for creating ArchitectureBusiness .

Application .

Data .

Technology .

Structure Context Operation




Functional DecompositionDiagram

ApplicationCommunication Diagram

Application and User Location Diagram

Class DiagramData Dissemination

DiagramData Entity / Business

Function Matrix



RoleCatalog

Actor / Role Matrix



Technology Standard Catalog


Role / System Matrix

Data Entity / DataComponent Catalog

LocationCatalog

PlatformDecomposition Diagram


Use CaseDiagram

Organisation Chart Diagram

Event Diagram





NetworkedComputing/

Hardware Diagram

CommunicationEngineering Diagram



System / FunctionMatrix




Contract / MeasureCatalog

Mandatory Diagram

Optional Diagram

Mandatory Catalog

Matrix


Business FootprintDiagram


Goal /Objective/Service Diagram






Processing Diagram

Interface Catalog

Optional Catalog

So how do we assemble all the pieces of the complex puzzle called Enterprise Architecture

Enterprise Architecture in general is often defined as providing Structure, Context and enables operations of Service-Oriented Architecture (SOA)

This slide provides another picture of the deliverables organized by Structure, Context and Operations


SAP AG 2009

Catalogs, Matrices and Diagrams in more detail

Each individual Catalog, Matrix and Diagram will be explored in more detail during the relevant Phase

Unit 4 - Phase B: Business Architecture

Unit 5 - Phase C: Information Systems Architecture – Applications

Unit 6 - Phase C: Information Systems Architecture – Data

Unit 7 - Phase D: Technology Architecture

We will certainly explore phase specific Catalogs, Matrices and Diagrams in detail as we go through the subsequent phases.


SAP AG 2009

Automating Catalogs, Matrices and Diagrams

Catalogs, Matrices and Diagrams are all concepts that are well supported by leading Enterprise Architecture tools.

In environments where tools are used to model the architecture, such tools typically support mechanisms to search, filter and query the Architecture Repository.

On-demand querying of the Architecture Repository (e.g. who owns Business Services?) can be used to generate ad-hoc catalogs, matrices and diagrams of the architecture.

As this type of query is by nature required to be flexible, it is therefore not restricted or defined within the TOGAF™ model.

Unit 14 explains how we do this in more detail

Now let us look at the automation of the Catalogs, Matrices and Diagrams

These concepts are well supported by leading EA tool vendors

If an enterprise engages a EA tool and creates an inventory of all the EA assets, then the tool typically support to search, filter and query the architecture repository

Most of the tools also support on-demand querying to generate these deliverables ad-hoc

As the nature of the query warrants a good bit of flexibility it is more left as tool capability rather than restricted or defined within the TOGAF™ model

We will look at the tools in more detail in a subsequent session


SAP AG 2009

How do we present information to Stakeholders ?

Metamodel

“Real - World” Enterprise

Database Object

Database Object

DatabaseObject

Database Object

?

Reference Models


Ad-Hoc Queriesand Reporting

StakeholderViews

Stakeholder


Architecture

Repository

InfrastructureConsolidation Extension Governance Extensi on

Pro cess Modell ingExtension Data Modelling Extension

Business / IT Al ignmen tExtension CoreContent





AssociatedWith All Ob jects

Organisat ion Unit

Goal

Objective


(Business, Information System) ServiceServ ices are Contained in Core , Bus iness / IS split supports the Bus iness / IT Alignment Ext ension

Function

Process

Actor

Role




Data Entity

Logical Information ComponentDa ta Extension

LocationInfrast ructureConsolidation

Ex tens ion

Phys ical Inform ation Component

Data Extension


Physical ApplicationComponentInf rastr ucture



Infrastruc ture Consolidat ionExtension




Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Host edin


Encapsulates

Resideswithin


I sRealised by Realises

Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedt hrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin


Performstask in

Generates, Resolves

Produces


Owns

Supports, Isperformed by

Accesses

Can beaccessed by

Orches trates, decomposes


Is bounded by

Provides governedinterfacet o access

Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguidedby

Governs, Measures

Is governedand measuredbyIsProvided to


Is tracked against


Sets perf ormancecriteria for

Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby











Organisat ion Unit

Goal

Objective



Function

Process

Actor

Role




Data Entity



Ex tens ion


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Host edin


Encapsulates

Resideswithin



Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedt hrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin


Performstask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by


Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby



Going through the EAF process, the deliverables required in each & every phase can be produced

They can be presented in a format (for e.g. a Diagram) to satisfy the needs of a specific stakeholder group

Define matrices and catalogs of relevant architectural information

Capture all these deliverables in a common resource base that all can access


SAP AG 2009

Summary

This is the end of the Catalogs, Matrices and Diagrams Unit

You should now understand the reason for, and the structure of :

Catalogs

Matrices

Diagrams

How they address stakeholder concerns

How they are put together to form an architecture

The next unit explains the TOGAF™ Architecture Development Methodology (ADM)


We reviewed the TOGAF™ Catalogs, Matrices and Diagrams and you should be familiar with the following..…

In the next unit we will cover the TOGAF™ Process in more detail


SAP AG 2009


Unit 1e - Architecture Process

©SAP AG SOA200 5-1

SAP AG 2009

The TOGAF™ Architecture Process

Contents:

Framework Overview

The need for an Iterative Approach

Introduction to Iterations in TOGAF™

The TOGAF™ Process

©SAP AG SOA200 5-2

SAP AG 2009







©SAP AG SOA200 5-3

SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand:

The TOGAF™ ADM process

How TOGAF™ handles AS-IS and TO-BE First approaches

How iteration is an integral part of the TOGAF™ Process

©SAP AG SOA200 5-4

SAP AG 2009

Review of the TOGAF™ ADM





©SAP AG SOA200 5-5

SAP AG 2009

A review of the TOGAF™ ADM

TOGAF™ ADM provides a number of architectural phases (e.g. Business Architecture, Information Systems Architecture) in a cycle an overall process template for architectural activity

TOGAF™ ADM provides a narrative of each architecture phase, describing the phase in terms of objectives, approach, inputs, steps and outputs. The TOGAF™ documentation defines the

approach, content structure and deliverables

TOGAF™ ADM provides cross-phase summaries on requirements management, phase inputs and phase outputs

TOGAF™ ADM provides a cross-phase section explaining the concept of architecture building blocks, which allow the Enterprise to be segmented into re-usable components.


From a process perspective, TOGAF™ provides one of the richest processes of all frameworks.

©SAP AG SOA200 5-6

SAP AG 2009






©SAP AG SOA200 5-7

SAP AG 2009

Iteration in TOGAF™

TOGAF™ is presented in a way that may lead the inexperienced to a waterfall approach

Cycling around the TOGAF™ ADM wheel completion of one phase of architecture work directly feeds into subsequent phases

Iterating between TOGAF™ phases iterating across phases (e.g. returning to Business Architecture on completion of Technology

Architecture)

Cycling around a single TOGAF™ phase repeated execution of the activities within a phase for elaborating architectural content

The ADM is iterative, over the whole process, between phases, and within phases.

For each iteration of the ADM, a fresh decision must be taken as to:

the breadth of coverage of the enterprise to be defined

the level of detail to be defined

the extent of the time horizon aimed at, including the number and extent of any intermediate time horizons

the architectural assets to be leveraged in the organization's Enterprise Continuum

©SAP AG SOA200 5-8

SAP AG 2009

Problems for Package and Service-Oriented Environments 1/3

Business Architecture• Business Baseline Description• Principles, Reference Models, Viewpoints and Tools• Architecture Models• Select Building Blocks• Formal Review• Review Non-Functional Criteria• Complete Business Architecture• Gap Analysis and Report

Application Architecture• Applications Baseline Description• Principles, Reference Models, Viewpoints and Tools• Architecture Models• Identify Candidate Application Systems• Formal Review• Review Non-Functional Criteria• Complete Applications Architecture• Gap Analysis and Report

Little value in defining and signing-off of a business process before a packaged solution has been selected

The choice of packaged solution is likely to fundamentally impact the business process.

Avoid the need to approve architectures multiple times or re-visit signed-off deliverables.

Carrying out as-is and to-be analysis across multiple TOGAF™ phases before finalizing

Avoid looking at as-is and to-be for a specific phase and then moving to the next phase.

Information Systems and Technology constraints will have a significant impact on the Business Architecture It is unwise to carry out TOGAF™ phases in waterfall sequence

Avoid formal approval of the architecture in each phase

Define formal checkpoints at the conclusion of several cross-phase iterations

A Package or Service-Oriented environment brings new stresses

©SAP AG SOA200 5-9

SAP AG 2009


Alignment of Business, Applications and Data with Technology

Typically the overriding factor in determining optimum architecture.

Using an iterative approach, considerations can be addressed in parallel before gaining formal commitment to a specific approach

Ready availability of prototype or demonstration systems

Opportunity to evaluate decisions much earlier in the process.

Using an iterative approach, allows initial passes to identify areas of architectural risk or uncertainty, and then dropping into prototyping to address these areas.

So what makes Enterprise Architecture in Package and Service-Oriented environments different?


SAP AG 2009


Team sizes are typically larger

Need to incorporate functional and technical product expertise, alongside business and technical domain expertise from the end-user organization.

Architecture needs to progress at high speed

Off the critical path of a wider solution definition team.

An iterative approach supports this need by removing checkpoint barriers and allowing partial architectures to be used to facilitate progress in other areas.

The risk profile is less uniform than in custom build environments

Application vendors provide relatively complete platforms

Solution definition in these environments lower risk

Flashpoints of risk around sizing, integration, migration and platform gaps.

Using an iterative approach supports accelerated completion of architectural activity in low risk areas, without preventing more detailed assessment in more challenging areas

So what makes Enterprise Architecture in Package and Service-Oriented environments different?


SAP AG 2009







SAP AG 2009

TOGAF™ - coping with Iteration

TOGAF™ defines an overall iterative process to cross the ADM architecture phases in a way that supports Package and Service-Oriented environments.

ArchitectureContext Iterations

ArchitectureDefinitionIterations

ArchitectureDeploymentIterations

TransitionPlanningIterations


To assist with the previous issues and stresses, TOGAF™ defines a set of iteration cycles


SAP AG 2009

Overall Structure of Iterations





The TOGAF™ iterative process divides the TOGAF™ ADM wheel into a number of sections that support iterative completion of architecture activities to achieve a specific purpose.

The TOGAF™ ADM defines a formal checkpoint at each phase of the ADM wheel. The TOGAF™ iteration cycles are intended to supersede the phase checkpoints, allowing instead for a formal review at the completion of each multi-phase iteration cycle


SAP AG 2009

Iteration Cycles

Architecture Context iteration

initial mobilization of architecture activity by establishing the architecture approach, principles, scope and vision.

Architecture Definition iteration

creation of architecture content by cycling through Business, Information Systems and Technology architecture phases.

Transition Planning iteration

creation of formal change roadmaps for a defined architecture

Architecture Deployment iteration

governance of change activity progressing towards a defined future state architecture.

Each one of the TOGAF™ iteration cycles can be executed a number of times. Some iteration cycles can be executed once, whereas others have a minimum number of cycles. For some iteration cycles, each iteration follows the same process. However, where there are a minimum number of iterations for an iteration cycle, the process differs slightly for each of the mandatory iterations


SAP AG 2009

The TOGAF™ ProcessThe SAP EAF Process in detail






SAP AG 2009

TOGAF™ Process Styles

Two process styles exist within TOGAF™:

“As-Is First”

An assessment of the current state landscape is used to identify problem areas and improvement opportunities.

suitable when a future state solution is not clearly understood and agree upon.

“To-Be First”

The target state solution is elaborated in detail and then mapped back to the current state in order to identify change activity.

suitable when a future state solution is agreed at a high level and where the organisation wishes to avoid proliferating current business practice into the To-Be model.

TOGAF™ addresses these process styles as variants within a single iterative process.


SAP AG 2009

Process for “As-Is First” Style Architecture Definition

CoreCoreInformalInformalInformalInformalInformalChange Management

CoreCoreInformalInformalImplementation Governance

InformalInformalCoreCoreLightLightLightInformalMigration Planning

InformalInformalCoreCoreLightLightLightInformalOpportunities and Solutions

LightInformalInformalCoreCoreInformalInformalTo-Be

LightInformalInformalCoreLightCoreInformalAs-IsTechnology Architecture


LightInformalInformalCoreLightCoreInformalAs-IsData Architecture


LightInformalInformalCoreLightCoreInformalAs-IsApplication Architecture


LightInformalInformalCoreLightCoreInformalAs-IsBusiness Architecture

LightInformalInformalInformalInformalInformalCoreVision

LightInformalInformalInformalCorePrelim

Iteration nIteration 1Iteration nIteration 1Iteration nIteration 2Iteration 1Initial IterationTOGAF Phase

Architecture DeploymentTransformation PlanningArchitecture DefinitionArchitecture

Context





SAP AG 2009

Process for “To-Be First” Style Architecture Definition

CoreCoreInformalInformalInformalInformalInformalChange Management

CoreCoreInformalInformalImplementation Governance

InformalInformalCoreCoreLightLightLightInformalMigration Planning

InformalInformalCoreCoreLightLightLightInformalOpportunities and Solutions

LightInformalInformalCoreLightCoreInformalTo-Be

LightInformalInformalCoreCoreInformalInformalAs-IsTechnology Architecture


LightInformalInformalCoreCoreInformalInformalAs-IsData Architecture


LightInformalInformalCoreCoreInformalInformalAs-IsApplication Architecture


LightInformalInformalCoreCoreInformalInformalAs-IsBusiness Architecture

LightInformalInformalInformalInformalInformalCoreVision

LightInformalInformalInformalCorePrelim

Iteration nIteration 1Iteration nIteration 1Iteration nIteration 2Iteration 1Initial IterationTOGAF Phase

Architecture DeploymentTransformation PlanningArchitecture DefinitionArchitecture

Context





SAP AG 2009


Initial Iteration

To establish the approach, principles, scope and vision for the engagement

This iteration comprises a pass through the Preliminary and Architecture Vision phases of the ADM

This is necessary as Framework and Principles may need to be modified once the Vision is completed



SAP AG 2009

Architecture Definition - AS-IS First


Iteration 1 Define the current state architecture A pass through the Business Architecture,

Information Systems Architecture and Technology Architecture phases of the ADM, focusing on definition of the current state. Opportunities, Solutions and Migration Plans are examined in less detail to drive out the focus for change and test feasibility.

Iteration 2 Define the future state architecture and

gaps A pass through the Business Architecture,

Information Systems Architecture and Technology Architecture phases of the ADM, focusing on definition of the future state and gaps against the current state. Opportunities, Solutions and Migration Plans are examined in less detail to test viability.

Iteration n Refine current state, future state and gaps Subsequent Architecture Definitions

attempt to correct and refine the future state to achieve a target that is beneficial, feasible and viable.


SAP AG 2009

Architecture Definition - TO-BE First

Iteration 1 Define the future state architecture A pass through the Business Architecture,

Information Systems Architecture and Technology Architecture phases of the ADM, focusing on definition of the target state. Opportunities, Solutions and Migration Plans are examined in less detail to drive out the focus for change and test feasibility.

Iteration 2 Define the current state architecture and

gaps A pass through the Business Architecture,

Information Systems Architecture and Technology Architecture phases of the ADM, focusing on definition of the current state and gaps against the future state. Opportunities, Solutions and Migration Plans are examined in less detail to test viability.

Iteration n Refine the current state, future state and

gaps Subsequent Architecture Definitions attempt

to correct and refine the future state to achieve a target that is beneficial, feasible and viable.



SAP AG 2009

Transition Planning


Iteration 1 Define and agree a set of improvement

opportunities, aligned against a provisional transformation roadmap.

The initial iteration of transition planning seeks to gain buy in to a portfolio of solution opportunities in the Opportunities and Solutions phase of ADM. This iteration also delivers a provisional migration plan.

Iteration n Agree the transformation roadmap, refining

the identified improvement opportunities to fit.

Subsequent iterations of Transition Planning seek to refine the migration plan, feeding back issues into the Opportunities and Solutions phase for refinement.


SAP AG 2009

Architecture Deployment


Iteration 1 Mobilize architecture governance

and change management processes.

The initial Architecture Deployment iteration establishes a process for architectural governance of change and also puts in place the appropriate people, processes and technology to support managed access to and change of the defined architecture.

Iteration n Carry out architecture governance

and change control.

Subsequent iterations of the Architecture Deployment cycle focus on period reviews of change initiatives to resolve issues and ensure compliance.


SAP AG 2009

Summary

This is the end of the TOGAF™ Process overview

You should now understand : The TOGAF™ ADM process

How TOGAF™ handles different engagement types

How TOGAF™ handles AS-IS and TO-BE First approaches

How iteration is an integral part of the TOGAF™ process

The next phase is the first phase of the ADM – the Preliminary Phase



SAP AG 2009


Unit 2 – Phase 0 - Preliminary Phase

©SAP AG SOA200 6-1

SAP AG 2009

Contents:

Introduction to Preliminary Phase

SAP EAF Extensions

Tailoring Guide

Enterprise Architecture Principles

IT Governance Checklist

Populating the Metamodel


SAP EAF Preliminary Phase: Framework and Principles

©SAP AG SOA200 6-2

SAP AG 2009







©SAP AG SOA200 6-3

SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand :

How to assess current EA maturity in the organization

How to assess the agreed shape and scope for the Architecture Engagement

How to choose a set of SAP EAF extensions that will be used

How to implement a metamodel structure for the development of Enterprise Architecture

How to link the Architecture Engagement into existing customer governance and change management processes

How to assess the current IT governance of the organization

How to formulate a set of business and architecture principles and populate the principles catalog

©SAP AG SOA200 6-4

SAP AG 2009

Objectives and Scope

The Preliminary Phase is about deciding on the tools and approach we will use to tackle an architecture engagement.

As in any task, before we start, it is useful to :

Prepare and initiate activities required to meet the business directives

define the approach we will take and the tools we will use so as to better plan the next stage

define a set of principles, or rules and guidelines that will define the approach and the decision making process

©SAP AG SOA200 6-5

SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools




extending TOGAF™ ADM



©SAP AG SOA200 6-6

SAP AG 2009

Overall Description of SAP EAF


Usage Guidelines









Case Study Material










(App & Data)


























Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base
















Guidelines



Guidelines


709: SAP Glossary

Detailed Component View

The key references in the Preliminary Phase are :

NL-F-P007 – SAP EAF Glossary

NL-F-P102 – SAP EAF Tailoring Guide

NL-F-P100 – Phase Worksheet

NL-F-P105 – Phase Narrative

NL-F-P101 – Example Architecture Principles

NL-F-P106 – IT Governance Review

©SAP AG SOA200 6-7

SAP AG 2007



SAP EAF Extensions

Tailoring Guide





©SAP AG SOA200 6-8

SAP AG 2009

Preliminary Phase - Overview

The Preliminary phase of TOGAF™ is about defining "How we do Architecture" in the enterprise concerned.

There are two main aspects to this: defining the framework to be used; and defining the architecture principles that will form and guide any architecture work.


The Preliminary Phase is about deciding on the tools and approach we will use to tackle the engagement.

“Defining the framework” is about how we will adopt the SAP Enterprise Architecture Framework and if necessary tailor it

We need to review the components of the SAP EAF for applicability, and then tailor them as appropriate to the circumstances of the individual organization

“Defining the architecture principles” is about defining a set of general rules and guidelines,, that inform and support the way in which we will approach the architecture development.

Principles are intended to be long-lasting and are not intended to be frequently amended.

©SAP AG SOA200 6-9

SAP AG 2009

Preliminary Phase – Main Objectives

To review the organizational context for conducting enterprise architecture

To identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive to create an enterprise architecture and determine their requirements and priorities from the enterprise, their relationships with the enterprise, and required working behaviors with each other

To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process

To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned

To confirm a governance and support framework that will provide business process and resources for architecture governance through the ADM cycle

To select and implement supporting tools and other infrastructure to support the architecture activity

To define the architecture principles that will form part of the constraints on any architecture work



SAP AG 2009

Preliminary Phase - Approach

Defining the enterprise scope in general

Identifying key drivers and elements in the organizational context

Defining the requirements for architecture work

Defining the architecture principles that will inform any architecture work

Defining the framework to be used

Defining the relationships between management frameworks

Evaluating the enterprise architecture maturity

This phase is based on some ideas of the Zachman Framework



SAP AG 2009

TOGAF™ has to co-exist with other methods

Source: Opengroup

Business Capability Management (Business Direction and Planning) that determines what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures.

Portfolio/Project Management Methods that determine how a company manages its change initiatives.

Operations Management Methods that describe how a company runs its day-to-day operations, including IT.

Solution Development Methods that formalize the way that business systems are delivered in accordance with the structures developed in the IT architecture.



SAP AG 2009

Legend slide for phases in TOGAF™ and EAF

Reference Input

Output

Reference Input

Non Architectural Input

Output

Output

PhaseName

Non Architectural Input

Architectural Input

Architectural Input

Architectural Input

Templates and Examples



Additional SAP EAF step




SAP AG 2009

TOGAF™ Preliminary Phase – Inputs and Outputs

TOGAF™ Framework

Organizational Model for Enterprise Architecture

Other frameworks (if required)

Board strategies and board business plans, business strategy, business principles,

business goals, and business drivers, when pre-existing

Tailored Architecture Framework,

Initial Architecture Repository

PreliminaryPhase

Major frameworks operating in the business; e.g., portfolio/project management

Governance and legal frameworks, including architecture governance strategy, when pre-existing

Budget for scoping project

Partnership and contract agreements

IT strategy

Existing Architecture Principles

Existing Architecture Repository, if any


Existing Architecture Framework, if any

Business Principles, Business Goals, and Business Drivers

Request for Architecture Work

Governance Framework

SAP EAF provides a comprehensive set of extensions to facilitate the Preliminary Phase as shown here on the Phase Worksheet.

Be aware that there are many other useful inputs and templates to this Phase as shown on the diagram


SAP AG 2009

TOGAF™ Preliminary Phase – Overview of Steps

Implement Architecture Tools

TOGAF™ ADM

Define EA Team and Organization

Scope the Enterprise Organizations

Confirm Governance/Support Frameworks

Select /Tailor Architecture Framework(s)

Identify / Establish Architecture Principles

TOGAF™ and EAF combined.


SAP AG 2009

TOGAF™ ADM - Steps

Scope the Enterprise Organizations Impacted Identify core enterprise (units) - those who are most affected and achieve most value

from the work

Identify soft enterprise (units) - those who will see change to their capability and work with core units but are otherwise not directly affected

Identify extended enterprise (units) - those units outside the scoped enterprise who will be affected in their own enterprise architecture

Identify communities involved (enterprises) - those stakeholders who will be affected and who are in groups of communities

Identify governance involved, including legal frameworks and geographies (enterprises)

Confirm Governance and Support Frameworks Review existing governance frameworks and their requirements towards EA

Review existing support frameworks (operational frameworks, portfolio management frameworks)



SAP AG 2009


Define and Establish Enterprise Architecture Team and Organization

Determine existing enterprise and business capability (TOGAF™ is not clear about a method for this)

Conduct an enterprise architecture/business change maturity assessment, if required (TOGAF™ is not clear about this)

Identify gaps in existing work areas

Allocate key roles and responsibilities for enterprise architecture capability management and governance

Define requests for change to existing business programs and projects:

Inform existing enterprise architecture and IT architecture work of stakeholder requirements

Request assessment of impact on their plans and work

Identify common areas of interest

Identify any critical differences and conflicts of interest

Produce requests for change to stakeholder activities

Scope new enterprise architecture work

Determine constraints on enterprise architecture work

Review and agree with sponsors and board

Assess budget requirements



SAP AG 2009


Identify and Establish Architecture Principles

Derive Architecture Principles from Business Principles

Select and Tailor Architecture Framework(s)

Tailor terminology, process, and content


Select an implement architecture tools

TOGAF™ provides example criteria



SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions

Tailoring Guide






SAP AG 2009

Additions / Modifications according to SAP EAF

SAP EAF Preliminary Phase Worksheet

SAP EAF Overall Process Document

SAP EAF Preliminary Narrative Document

SAP EAF Tailoring Guide

TOGAF™ ADM Preliminary Narrative

SAP EAF Applicability Review

Business Goals and Drivers

Confirmed IT Governance and Support Strategy

Architecture Principles

BEEST Case Study

SAP EAF Templates


SAP EAF Case Study

Perform SAP EAF Maturity Review

Preliminary

Phase

Architecture Tooling Environment

SAP EAF Tooling Strategy

SAP EAF Tool Migration

Overview of SAP Tools

SAP EAF Executive Guide

SAP EAF Document Maps

Tailored Architecture Process and Metamodel

Roadmap Composer Whitepaper

Additional Inputs

Additional supporting material

Additional outputs

Additional step(s)

SAP EAF provides a comprehensive set of extensions to facilitate the Preliminary Phase as shown here on the Phase Worksheet.

Be aware that there are many other useful inputs and templates to this Phase as shown on the diagram


SAP AG 2009

Preliminary Phase – TOGAF™ and SAP EAF

SAP EAF Extensions



TOGAF™ ADM

Define EA Team and Organization

Scope the Enterprise Organizations

Confirm Governance/Support Frameworks

Select /Tailor Architecture Framework(s)

Identify / Establish Architecture Principles

TOGAF™ and EAF combined.


SAP AG 2009

EAF Extensions


According to TOGAF™ this step is considered as part of “Define and Establish Enterprise Architecture Team and Organization” step

SAP added a formal step for this activity

The EAF Maturity review also is a service offering of SAP (templates and accelerators are available via SAP contacts)

The SAP EAF Tailoring Guide defines the steps involved in defining i.e. tailoring the framework

The level of EA Maturity in the organization will influence the framework that is adopted

Existing IT Governance and Support models are essential for the Enterprise Architect to understand

A set of architecture principles should be defined that can be traced to Business Drivers/Goals/Objectives ; for example, I want to “x” therefore I need to develop a “y” architecture

The type and depth of Tools support should be discussed and defined early.


SAP AG 2009

Tailoring Guide


SAP EAF Extensions

Tailoring Guide






SAP AG 2009

Tailoring Guide

TOGAF™ discusses the issues involved in adapting the ADM but only at a generic level

The main focus of the Preliminary Phase will be to map or tailor the TOGAF™Framework to the requirements of the customer organization

The Tailoring Guide is provided to guide the Enterprise Architect through the mapping process

It should be used primarily in the Preliminary Phase (“Select and Tailor Architecture Framework(s)”)

Determine SAP EAF Maturity

DetermineEngagement

Shape

Select SAP EAF Extensions

DetermineStandard

Terminology

DetermineMetamodel Structure

DetermineintegratedProcesses

Covered in the SAP EAF Tailoring Guide

Identifies EA maturityof the organisation

and how SAP EAF isbest applied

Identifies how theEnterprise requirementsdiffer from the core SAP

EAF positioning

Identifies whichcomponents of the

framework are requiredwithin the enterprise

Maps SAP EAF standard terminology

to the terminologyalready in use within

the enterprise

Allows for enterprisespecific modifications

to the SAP EAF metamodel

Aligns SAP EAF processes with existingenterprise processes

for projects and governance

TOGAF™ does discuss the issues in adapting the TOGAF™ ADM under the chapter “Adapting the ADM”.

SAP EAF provides a more specific set of tasks to tailor the SAP EAF for the engagement in hand


SAP AG 2009

Tailoring Guide: Step 1 - Determine SAP EAF Maturity

TOGAF™ discusses the issues of EA Maturity as part of its Resource Base It is recognized that an evaluation of an organization's

EA practices against a maturity model determines the level at which the organization currently stands.

A maturity assessment highlights the practices on which the organization needs to focus that will contribute to he greatest improvement and a return on investment.

TOGAF™ refers to two existing models:

US Department of Commerce (DoC) has developed an IT Architecture Capability Maturity Model (ACMM) to aid in conducting internal assessments

http://www.osec.doc.gov/cio/arch_cmm.htm

The Institute for Enterprise Architecture Development provides a freely-available model to download

http://enterprise-architecture.info/EA_Methods.htm

The SAP Enterprise Service Adoption Method already includes an E-SOA maturity model, and an E-SOA Maturity Assessment Service that can also be used.

The results can be graphically represented for Senior Executives

The next version of SAP EAF will address Package and Package Service Maturity more formally.

0

1

2

3

4

5Business IT-Alignment

Governance

People

Architecture Process

Architecture Development

Stakeholder Involvement

Communication

Influence and Impact

Readiness

Expectation

Consider

Scope and Authority - what scope does EA team have ? What power and authority does it have?

Impact - what impact is it having ? Evidence of key decisions - how much reuse and alignment is actually happening ?

Stakeholder Engagement - do the team have a stakeholder plan? What is the view of the CTO, the CIO, the CFO on the value that EA is delivering ?

Deliverables - how complete is the architecture ? Does the organization have an up-to-date AS-IS and TO-BE view

Business Context - how are the team patched into business strategy ? Is the architecture largely technical ?

Resources - are the team resourced with correct skills ? How is resource vs. workload balanced ?

Application to Future Strategy - how do the team drive future strategy ? Are they reactive or proactive ? What is the attitude to innovation ?


SAP AG 2009

Tailoring Guide: Step 2 - Determine Engagement Shape

Determine shape of the proposed engagement Is it top-down ? If so, how much weighted ? Is it Rapid ? If so, how rapid ?

The Slider Model helps calibrate this The dimensions chosen are typical of the dimensions that influence the shape of the engagement They are deliberately overlapping Use the slider model in discussions with Stakeholders to work out the degree of focus The earlier the shape can be determined ; the more the work can be planned upfront and the less

risk on the engagement

Stakeholder Viewpoint

PowerPoint / Excel

Top Down

EA

Full SAP

Light (good enough)

Rapid (1-3 weeks)

Tailored

Waterfall

Full Scope

RealizationViewpoint

EA Tool

Bottom Up

Solution Architecture

Partial SAP

Full (detailed / comprehensive)

Larger project(1-3 months)

Template

Interative

Single Domain

The slider model provides a simple graphical tool to baseline and calibrate the views of stakeholders

When they say Top Down do they mean fully Top Down ? Or a mix

When they say they need flexibility……just how flexible do they need to be ?

Another useful tip is to define an example of what each extreme means ;for example

Waterfall = one proceeds from one phase to the next in a purely sequential manner – only proceeding to the next once signoff of the first phase has occurred


SAP AG 2009

Tailoring Guide: Step 3 - Select Extensions (TOGAF™ view)

Which extensions do you need ? Care is needed : easy to choose all extensions for fear of leaving something out Needs to be balanced against the time, effort, and complexity that will result Keep the initial engagement paired down to a core, so that progress is faster, and value can be

realized earlier. This helps to gain stakeholder support early.

TOGAF™ 9

Extensions enable us to keep the Framework as light as possible for the task in hand.

Be careful : don’t include them all “just in case” : be ruthless


SAP AG 2009

Tailoring Guide: Step 3 - Select Extensions (SAP view)

Core Content Metamodel



ExtensionsData Extensions

SAP’s view is similar to TOGAF™’s view However, SAP believes that there is no need for “Motivation Extensions”. Entities affected by that

extension should be considered as core. Guidance on selecting extensions - NL-P-P102 - SAP EAF Metamodel and View Definition.

Business / IT Alignment Extensions

Process Modelling Extensions

SAP EAF

Extensions enable us to keep the Framework as light as possible for the task in hand.

Be careful : don’t include them all “just in case” : be ruthless


SAP AG 2009

Tailoring Guide: Step 4 - Determine Standard Terminology

TOGAF™ TERMCUSTOMER

ENGAGEMENT TERM

Function Capability

Location Site

Measure KPI

Terminology is key in Enterprise Architecture

Lack of agreement on precise meanings of terms can cause problems of communication

One person’s “function” is another person’s “capability” or “value chain”

SAP EAF provides :

NL-F-P102 – SAP EAF Glossary – TOGAF™ compliant standard set of terms

NL-R-P709 – SAP Glossary – SAP standard terms

The output

an agreed set of terminology to be used when developing and governing Enterprise Architecture in the customer organization

Define a standard glossary for the engagement – ensure examples are provided so there is less chance of misunderstanding – and so people can think about the definition in real-world terms


SAP AG 2009

Tailoring Guide: Step 5 - Determine Metamodel Structure

The selection of extensions will determine this

NL-F-P002 – SAP EAF Metamodel Definition provides further detail and advice

The key questions to resolve are: Based on the terminology agreed,

do metamodel entities need to be added, removed or changed? White entities are “core” and not to

be omitted Red/Blue/Green entities are

“extensions” and can be omitted Entity renaming is possible Modification and removal of entities

is not recommended

Based on the extensions required, what metamodel entity extensions are needed?

Are there existing tools that need to be mapped to the metamodel? If so, how does the Tool’s internal data model affect the engagement?

Do the customer’s existing tools support the TOGAF™ metamodel ?

Each metamodel extension translates to a given set of “added entities”

Modification (e.g. merging of Goal and Objective) or Removal of Entities is not recommended

Renaming of entities is allowed (e.g. Goal renamed to Aim)

Examine existing Architecture Tools and Artifacts for the entities that they use


SAP AG 2009

Tailoring Guide: Step 6 - Determine Integrated Processes

If the following questions cannot be answered, there is a high risk the engagement will proceed in a vacuum……

How will the EA engagement link into existing customer governance and change management processes ?

Business Planning How are business opportunities and business problems prioritized and

reviewed? How does the current business planning process work in the organization? How are new business propositions created and how do they turn into

approved projects?

Program Management Is there a Project or Program Management Office that monitors and tracks

projects in the customer organization and their status? What existing programmes and projects are already in-flight?

Procurement How are new applications, software, and technology procured in the

organization?

Change Management What is the current scope of ‘business-as-usual’ change to applications,

software and hardware

To establish how Enterprise Architecture governance works, and its effectiveness, it is important to understand the key processes that sit on the edge of Enterprise Architecture.


SAP AG 2009



SAP EAF Extensions

Tailoring Guide






SAP AG 2009


How to define Principles :

A poor set of principles will quickly become disused, and the resultant architectures, policies, and standards will become arbitrary and lack credibility.

E.G. “We will use a relational database wherever possible”

A good set of principles once embedded, will be referred to frequently and will provide consistent guidance to an organization as it changes.

E.G. “The business processes regarding the Bill of Materials do not differ between central planning and the plants. Therefore we will use the same SAP IPPE application centrally and decentrally”

How to apply Principles :

Principles are used to provide a decision making framework to align decisions against its business and technology strategy.

The rationale of each principle provides a basis for justifying architecture decisions

An organization must develop appropriate policies and procedures to support adherence of the principles.

A set of Example Architecture Principles applicable in a Package and Packaged Services context is provided

“Compose solutions from existing services in preference to using out-of-the-box packages”

“Buy solutions in preference to building them”

A template for collecting and sorting Principles is provided

Principles provide a set of guidance to help our decision making process.

This is better than basing decisions on someone’s favorite process, technology or some other, often arbitrary, criterion

Architecture Principles are defined by the Business Strategy/Principles

For example, a Business Principle

We will become "one company" sharing customer information and leveraging synergies across the group.

Would result in an Architecture Principle

The architecture must support sharing of customer information across lines of business with “one version of the truth”. Product information can be maintained individually

QUESTION : Can you think of other examples of good and bad architecture principles ?


SAP AG 2007



SAP EAF Extensions

Tailoring Guide






SAP AG 2009


Questions to uncover package and package service related IT governance impacts These impacts are often not immediately apparent

Structured according to the COBIT IT Governance Framework COBIT is an IT governance framework and supporting toolset from the IT Governance Institute® (ITGI)

http://www.isaca.org

PLAN AND ORGANISE

Suitability of project and program management approach

New package specific standards or service specific standards will be required

Contract and Procurement changes

Specialist external skills requirements

ACQUIRE AND IMPLEMENT Change management processes will increase in complexity

Specific additional technical environments may be needed

DELIVER AND SUPPORT An application support team will be required

The organization will need to commit to a training program in the package.

The organization will require package/service specific expert users

MONITOR AND EVALUATE Need to monitor and Evaluate IT Performance

A service-based approach will bring more complex requirements to manage and monitor performance

The SAP Enterprise Service Adoption Method already includes a SOA Organization and Governance Assessment Service that can also be used.

If a package or packaged service environment is being considered as part of the TO-BE Vision – what impact will it have on current IT Governance ?


SAP AG 2007



SAP EAF Extensions

Tailoring Guide






SAP AG 2009

Populating the Metamodel 1/2


SAP AG 2007


ARCHITE

PrinciplePrincipleAssociatedWith All Objects


RE

Goal

Objective

Driver

Sets performance

Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Con

sum

es

anderns

Operates in

Although at this stage we may not have a structured EA Tool in place, we will already start to discover and capture key information for the EA Model.

In particular, we need to be able to trace Business and Architecture Principles back to specific drivers, goals and objectives

Bear this in mind as you capture the information.


SAP AG 2009

Preliminary Phase - Catalogs, Matrices, and Diagrams

Catalog, Matrix or Diagrams

Purpose

Principles Catalog

The principles catalog captures principles of the business and architecture principles that describe what a “good” solution or architecture should look like. Principles are used to evaluate and agree and outcome for architecture decision points. Principles are also used as a tool to assist in architectural governance of change initiatives.

The Principles Catalog contains the following metamodel entities :

Principle

The following concepts are informally modeled :

Business Principles, Objectives and Drivers

Tailored Architecture Method

The only formally modeled concept is the Principles Catalog

SAP EAF provides an example Principles catalog as at this stage, formal tooling is unlikely to be in place


SAP AG 2009

Example Principles Catalog

The differentiating value of the IT landscape needs to be understood, and the focus and strategy set accordingly.

Following selection of services to outsource, an outsource management and review process will be required and a process for setting SLAs, reviewing and revising them periodically, and granting exceptions must be established.

Third-party vendors may handle the operation more efficiently.

Enterprises may then be able to focus resource more on operating and extending differentiating services.

Outsourcing stable services with an agreed set of SLAs and OLAs.

Outsource stable non differentiating services

IMPLICATIONSRATIONALESTATEMENTNAME

More time and effort will be required upfront before new technologies are available for incorporation into solutions; however, this will significantly minimize the cost, risk and time later to correct unforeseen issues.In order to realize the benefits of managed introduction of new technologies, detailed architectural standards and guidelines will need to be developed and followed closely.

This reduces implementation risk, enables more effective project planning, and ensures that any duplication or inconsistency in the solution is removed as early as possible in the project.

When introducing new solution classes or types within an organization; a defined lifecycle should be followed. Careful system selection, proof-of-concept and pilot stages should be followed.

Control and manage the implementation of new solutions.

This will increase an organization’s dependency on the vendor of the system, as opposed to an organization’s internal or supplier development teams. For example, an organization may be constrained by a vendor’s product roadmap and release schedule where there is a need to incorporate new functionality into the package to support new requirements.

Buying pre-existing tools from the market which could be tuned to the requirement of the enterprise would :• reduce the time-to-market of new value propositions, • reduce technical risk• increase system stability• reduce the need for the organization to possess deep technical development capability

Buy in preference to build everything from scratch especially when similar tools are readily available in the market.

Buy solutions in preference to building them

Here are three example principles.

The Rationale i.e. why are we doing it – should refer to the Business Strategy or a specific formal Business Objective


SAP AG 2009

Summary

This is the end of the Preliminary Phase

You now have an understanding of : How to assess current EA maturity in the

organization and how the TOGAF™ will be used

How to assess the agreed shape and scope for the Architecture Engagement

How to choose a set of TOGAF™ and SAP EAF extensions that will be used

How to implement a metamodel structure for the development of Enterprise Architecture

How to link the Architecture Engagement into existing customer governance and change management processes

How to assess the current IT Governance of the organization

How to formulate a set of Business and Architecture Principles and populated the Principles Catalog

The next phase is Architecture Vision



SAP AG 2009

Unit 3 –Phase A: Architecture Vision


©SAP AG SOA200 7-1

SAP AG 2009

TOGAF™ Phase A: Architecture Vision

Contents:

Introduction to Architecture Vision

SAP EAF Extensions

Business Capability Assessment

Technology Capability Assessment



©SAP AG SOA200 7-2

SAP AG 2009







©SAP AG SOA200 7-3

SAP AG 2007

Lesson Objectives

After completing this lesson, you will be able to understand construct :

An Approved Statement of Architecture Work and Scope

A set of Architecture Principles

An Architecture Vision including

A definition of the Business Capability of the customer organization

A definition of the Technical Capability of the customer organization

©SAP AG SOA200 7-4

SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools


Usage Guidelines Framework tailoring Engagement Initiation Using EA to implement SOA Service Contracts Business Capability Assessment Technology Capability

Assessment IT Governance Impact

Assessment Solution Architecture Scoping Glossary





In this Unit we are going to focus on the Architecture Vision phase

©SAP AG SOA200 7-5

SAP AG 2009



Usage Guidelines









Case Study Material










(App & Data)


























Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base
















Guidelines



Guidelines


709: SAP Glossary



We will revisit Stakeholder map, go through the narrative in more detail

We will also look at the capability assessments (both Business & Technology)

Finally we will look at the Engagement Initiation Guide in detail

©SAP AG SOA200 7-6

SAP AG 2010



SAP EAF Extensions





©SAP AG SOA200 7-7

SAP AG 2009

Architecture Vision Phase - Overview

The Architecture Vision phase is about validating the business principles, goals and drivers, defining the scope of the architecture engagement, understanding the relevant stakeholder objectives and articulating an architecture vision that meets the key business requirements


What is the Vision phase about?

In this phase we validate the business principles, goals and drivers developed in the “Prelim” phase

Define the scope of the engagement

Understand stakeholder expectations and finally

Articulate a “Vision” that meets customer’s requirements

©SAP AG SOA200 7-8

SAP AG 2009

Architecture Vision Phase – Main Objectives

To ensure that the engagement has the support and commitment of the necessary line management and other stakeholders

To define and organize an architecture development cycle within the overall context of the architecture framework

To validate the business principles, business goals, and strategic business drivers of the organization and the enterprise architecture Key Performance Indicators (KPIs)

To define the scope of the Baseline Architecture effort

To define the relevant stakeholders, and their concerns and objectives

To define the key business requirements and constraints of the engagement

To articulate an Architecture Vision and formalize the value proposition that demonstrates a response to those requirements and constraints

To secure formal approval to proceed

To understand the impact on other enterprise architecture development cycles ongoing in parallel


©SAP AG SOA200 7-9

SAP AG 2009

Architecture Vision Phase - Approach

Receive a Request for Architecture Work from the sponsoring organization to the architecture organization

Define scope of engagement

Define priorities

Set up vision for solution

Base on enterprise vision, goals objectives

Base on business processes (model in necessary)

Define first-cut baseline and target solution

Relate vision, solution, and approach to principles, drivers, objectives set in the Preliminary phase, update if necessary

Define and document vision and solution in Statement of Work



SAP AG 2009

TOGAF™ Architecture Vision Phase – Inputs and Outputs

Architecture VisionPhase

Architecture reference materials


Business Principles, Business Goals, and Business Drivers

Architecture Repository


Tailored Architecture Framework

Approved Statement of Architecture Work,

Refined statements of Business Principles, Business Goals, and Business Drivers

Architecture Principles

Capability Assessment

Tailored Architecture Framework (for the engagement)

Architecture Vision

Communications Plan

Additional content populating the Architecture Repository

Let us first look at Vision Phase as prescribed in TOGAF™ ADM first and then look at what extensions we have made to EAF

This slide shows the inputs and outputs of Architecture Vision Phase

Key inputs are Request for Architecture work, Principles, goals and strategic drivers that were either developed in the Prelim phase or from existing documentation within the enterprise

Key output are SOW, Vision document, Updated requirements document, updated/refined principles/goals/drivers


SAP AG 2009

TOGAF™ Architecture Vision Phase - Overview of Steps

Develop Architecture Vision

Define Scope

Evaluate Business Capabilities

Assess Readiness for Business Transformation

Confirm and Elaborate Architecture Principles

Establish the Architecture Project

Identify Stakeholders, Concerns, and Business Requirements

Confirm and Elaborate Business Goals, Business Drivers, and Constraints

Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval

Define the Target Architecture Value Propositions and KPIs

TOGAF™

We have reviewed the detailed steps of this phase as prescribed by TOGAF™ ADM.

In addition, we can see the EAF specific extensions which includes the business and technology capability analysis




SAP AG 2009



Embed the project within organization

Incorporate project management framework


Identify candidate vision components and requirements

Identify candidate scope boundaries for the engagement

Identify stakeholder concerns, issues, and cultural factors that will shape how the architecture is presented and communicated

Revisit the set of TOGAF™ extensions originally selected in the Preliminary Phase, and determine which Stakeholder Catalogs, Matrices and Diagrams are required


This slide depicts the detailed Steps per TOGAF™ ADM that need to followed while conducting this phase starting with Establishing the Project all the way to Confirm SOW and approval


SAP AG 2009



If already defined, ensure that they are consist and current


Perform business capability review (what capabilities will an organization need to fulfill its business goals and business drivers?)

Assess implications to organization, process and market

Create value chain diagrams for baseline and target scenarios

TOGAF™ is unclear about how to do this but provides some ideas for a capability review report

SAP recommends also to consider implications to governance processes:

NL-V-P206- IT Governance Checklist provided as part of Preliminary Phase accelerators

SAP IT governance is based on COBIT

A checklist of potential areas of impact to IT governance that may result from implementing a package or packaged service centric architecture

Based on the results of this questionnaire, additional IT governance and support related components may be added to the Architecture Vision, and the Statement of Architecture work.




SAP AG 2009


Assess Readiness for Business Transformation (e.g. Following the Canadian Government Business Transformation Enablement Program (BTEP))

In order to achieve the vision some readiness factors have to be implemented. They can be assessed like this (baseline and target)

Example: “Need for Enterprise Information Architecture”




SAP AG 2009


Example -Template: Summary

Will lead to a first idea of a roadmap


Ser Readiness Factor Urgency Readiness StatusDegree of

Difficulty to Fix

1

2

3

4

5

6

7

8

9

10

11

12

Vision

Desire/willingness/resolve

Need

Business case

Funding

Sponsorship and leadership

Governance

Accountability

Workable approach and execution model

IT capacity to execute

Departmental capacity to execute

Ability to implement and operate



SAP AG 2009


Define Scope

Specific scope considerations when considering package or packaged services when setting the Statement of Architecture Work

Horizontal Scope – Breadth of Coverage

Vertical Scope – How much detail

Time Period to Consider

Areas of theEnterprise to

Consider

ArchitectureOutputs to be

Created

How much time is available for the engagement ?

When are first deliverables needed by ?

What is driving the production of the Enterprise Architecture ?

What level of detail is needed for each metamodel entity ?

Are Enterprise, Enterprise Solution or Solution architectures are needed or not ?

What existing Architecture artifacts are there ?

Which Enterprise areas are covered by Packages or Package Services ?

What potential functionality gaps exist ?

Which organizational functions are in-scope ?is a significant geographical diversity of process within

the organization ?Are all operational units to be covered ?

Are externally provided services in-scope ?

Are all TOGAF™™ core catalogs, matrices and diagrams to be

produced ?

Which TOGAF™™ Extensions are being used ?



SAP AG 2009


Confirm and Elaborate Architecture Principles, including Business Principles


Draw high-level view of the Baseline and Target Architectures

draw a simple solution concept diagram

Draw business scenarios (TOGAF™ provides outlines, templates, and guidelines for this, but not linked to the metamodel of TOGAF™)




SAP AG 2009



Develop the business case for the architectures and changes required

Produce the value proposition for each of the stakeholder groupings

Assess and define the procurement requirements

Review and agree the value propositions with the sponsors and stakeholders concerned

Define the performance metrics and measures to be built into the enterprise architecture to meet the business needs

Assess the business risk

Identify the Business Transformation Risks and Mitigation Activities




SAP AG 2009



Identify new work products that will need to be changed

Provide direction on which existing work products, including building blocks, will need to be changed

Identify the impact of change on other work products and dependence on their activities

Based on the purpose, focus, scope, and constraints, determine which architecture domains should be developed, to what level of detail

Assess the resource requirements and availability

Define the performance metrics to be met during this cycle

Develop the specific enterprise architecture Communications Plan

Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures

Gain sponsor's sign-off to proceed




SAP AG 2010

SAP EAF Extensions


SAP EAF Extensions





Now that we have reviewed the baseline from TOGAF ADM, let us look at the EAF specific extensions


SAP AG 2009


SAP EAF Vision Narrative Document


SAP EAF Engagement Initiation Guide

TOGAF™ ADM Vision Narrative

SAP EAF Vision Phase Worksheet

BEEST Case Study

SAP EAF Templates

Architecture

Vision

Phase

How EA Supports SOA Whitepaper

SAP EAF Glossary

SAP EAF Stakeholder Map

Additional Inputs

Additional supporting material

Additional outputs

Additional step(s)

IT Governance Impact Assessment




IT Governance Impact Report

Stakeholder Map

Evaluate Technology Capability

This slide shows the details of all the inputs we need for the phase which includes

Phase specific inputs

Reference material/accelerators and

Pre-existing or previous phase inputs.

The slide also shows the typical outputs from the phase which is a bit of an elaboration compared to TOGAF™ ADM

It also identifies the key steps of the phase


SAP AG 2009

Architecture Vision Phase – TOGAF™ and EAFSAP EAF Extensions



Define Scope


Assess Readiness for Business Transformation

Confirm and Elaborate Architecture Principles






TOGAF™




SAP AG 2009

EAF Extensions


SAP feels that at this point of time it is important to assess the technological capabilities of the organization

Result will be what technology capabilities will be required to enable or support the target business capabilities

This will provide valuable input to TOGAF™ business readiness transformation

The SAP EAF Tailoring Guide defines the steps involved in defining i.e. tailoring the framework

The level of EA Maturity in the organization will influence the framework that is adopted

Existing IT Governance and Support models are essential for the Enterprise Architect to understand

A set of architecture principles should be defined that can be traced to Business Drivers/Goals/Objectives ; for example, I want to “x” therefore I need to develop a “y” architecture

The type and depth of Tools support should be discussed and defined early.


SAP AG 2010



SAP EAF Extensions






SAP AG 2009

Consider Business and Technology Capability

Crucial when defining an Architecture Vision to consider the target operating model of the customer organization

Key input to the Business Architecture phase.

Need to understand how, at the organizational unit level, an organization wants to categorize itself

But how to analyze business capability ? NL-V-P201- Business Capability Assessment provides a guide of how to do this

Crucial to have a clear understanding of the business’ technology capability to support its services

Allows effective service governance measures, organization and support toolsets to be realized

Allows understanding the business criticality of services to be delivered

But how to analyze technical capability ? NL-V-P202- Technology Capability Assessment provides a guide of how to do this

These tools help to define a robust Architecture Vision

The complete assessment may not be possible before the end of the Vision Phase

Outstanding tasks may be carried forward into Phase B – Business Architecture

Now let us go through some of the crucial considerations while performing the capability assessments

Understand “Target business operating model” (this operating model may or may not be explicitly defined)

Clearly understand how technology capability will support its Services

Some of the tasks may be carried forward to the next phase, business architecture


SAP AG 2009


TOGAF™ refers to the Business Scenario analyses as a way to formulate an architecture vision and elicit business requirements

Business Scenarios often imply detailed process flow which in turn inherently imply rules and interrelationships therefore constraints.

SAP EAF covers business capabilities using a slightly different approach

The Architecture Vision should focus on providing an end-to-end view of what the business does not how the business does it.

In order to this we need to :

Identify required capabilities

Analyze their value, market exposure, market differentiation and volatility

NL-V-P201- Business Capability Assessment explains how to do this

Identify thebusinesscapabilities to deliver the vision

Identify realizationoptions that will beinvestigated

Identify qualitivecriteria to supportclassification

Examine qualitivecriteria and determinerealization

Refine targetoperating modeland engagementscope

Covered in the SAP EAF Business Capability Assessment

TOGAF™ approach to this is based on Business Scenario analysis and to extract business requirements based on this

This approach is heavily constrained as it inherently implies detailed process flow

EAF adopts a capability analysis technique to provide a more end-to-end view of WHAT the business does instead of HOW the business does it

Business capability assessment provides a step by step approach for the capability analysis

The five key steps are…..


SAP AG 2009

Step 1 - Identify the business capabilities to deliver the vision

Example Output SAP Business Map

Identify the business capabilities that are required to deliver the architecture vision Use organization charts, process models, operational support models, management

reports Use Industry Reference Models Create a “capability map”

Suppliers & Partners

Customers & Channels

Engineering Procurement Manufacturing Sales & Distribution Customer Service

Enterprise Management & Support

Time-to-Market

New Product Development and Introduction

Life-cycle Data Management

Supplier CollaborationStrategic Sourcing

Operational Procurement and Inbound Logistics

Build-to-Order

Supply-to-line

Manufacturing Enterprise Asset Management

Sales & MarketingBrand and Customer Management

Vehicle Lifecycle Management

Vehicle Planning & Forecasting Order-to-Delivery

Customer ServiceWarranty Management

Interaction Center

Service Parts Planning Service Parts Execution

Suppliers & Partners

Customers & Channels

Engineering Procurement Manufacturing Sales & Distribution Customer Service


Time-to-Market

New Product Development and Introduction

Life-cycle Data Management

Supplier CollaborationStrategic Sourcing

Operational Procurement and Inbound Logistics

Build-to-Order

Supply-to-line


Sales & MarketingBrand and Customer Management

Vehicle Lifecycle Management

Vehicle Planning & Forecasting Order-to-Delivery


Interaction Center


Step 1 is to identify and develop a business capability map

We can utilize SAP business maps as a starting point to do this

There is an example of such a Capability Map based on IBM CBM


SAP AG 2009

Step 2 - Identify realization options that will be investigated

Identify a number of strategic choices that must be addressed bythe architecture

Which capabilities should be supported by applications?

Which capabilities should be outsourced vs. in-sourced?

Which capabilities should be supported by a package vs. Custom-build?

Narrowing down the options will reduce the scope and complexity of defining the desired approach to realize business capability.

Step 2 is to identify the realization options to fulfill the business capabilities identified in Step 1

Narrowing down the options will reduce the complexity of the work effort subsequently


SAP AG 2007

Step 2 - Identify realization options that will be investigated

Criticality of the Capability to the Organization

Enabling vs. Mission Critical

Core Business vs .Context

Cost of Operating the Capability

Fixed Overhead of Operating Capability

Transactional Cost to Serve

Cost vs. Industry/Organization Metrics

Exposure of the Capability

Market vs. Internal

Size of the User Community

Diversity and Distribution of the User Community

Performance of the Capability

Perception of the Capability

Stability of the Capability

Effectiveness of the Capability

Constraining Factors

Regulatory Constraints

Cross Capability Dependencies

Obsolescence Constraints

Resource Availability to Support Change

Political Constraints

Level of Understanding

Committed Activties

Sourcing

Outsource vs. Insource Business Process

Outsource vs. Insource Business Process Support

Share Competency at Corporate Level

Source from Preferred Supplier vs. at Point of Need

Resourcing/Automation

Fully Automate vs. Use Automation Support vs. Manual Fulfilment

Industrialized vs. Intimate Fulfilment

End-User Self Service vs. Enabled Service

Implementation

Perpetuate Current State vs. Adopt Industry Leading Practice vs. Adapt Industry Leading Practice vs. Pioneer Industry Leading Practice

Management Focus

Perform Capability vs. Perform Capability Consistently

Perform Capability vs. Perform & Measure and Analyze vs. Perform, Measure, Analyze and Optimize

Exposure

Departmental vs. Corporate

Internal vs. Market Exposed

Robustness and Agility

Availability vs. Cost

Resilience vs. Cost

Flexibility vs. Cost

Implementation Priority

Immediate, High Priority vs. FirstAvailable Opportunity vs. Mid-Term Priority vs. Desirable in the Longer Term

Inputs Outputs

BusinessCapability

There are a number of dimensions to be considered which are listed in the document in more detail


SAP AG 2007

INNOVATION STANDARD-IZATION

COMMODI-TIZATIONINVENTION

Courtesy to G. Moore’s “Living on the Fault Line”

One technique for identifying options - Core Context Analysis

MissionCritical

Activities

EnablingActivities

CONSOLIDATE

COREFocus: Differentiation

CONTEXTFocus: Productivity

COMPOSE

INS

OU

RC

E

OU

T-T

AS

K

RETIREINVENTS

CA

LE

Key indicator of where an organization should concentrate effort in order to realize the most business benefit

Another good technique to identifying which business capability to focus on is Geoffrey Moore’s CORE-CONTEXT model

The lifecycle of any business process starting with Invention to Commoditization


SAP AG 2009

Step 3 - Identify qualitative criteria to support classification

VALUE TO THE BUSINESS

TARGET OPERATING MODEL

CRITICALITY

DIFFERENTIATOR

High Market Leader Enterprise SOA/Best of Breed / Custom-built / Offer to market as Service

High To Expectation Package / ERP

Medium To Expectation Package / ERP

Low Not Required Ignore (leave in legacy) / Outsource / Consume external service

Create a decision making framework to support classification of identified capabilities into different realization models Identify the qualitative criteria that needs to be collected as an input to evaluation

Identify the realization options that will be considered

Identify which qualitative factors and values will result in which realization options

Identify how the resulting analysis will be validated and agreed with stakeholders

For example, how will we address provision of the technical capability? When should we consider an ERP Package approach ?

When should we consider a Packaged Services approach ?

The outcome of this analysis may result in updated Architecture Principles

Step 3 is to identify the Qualitative criteria for these business capabilities to further classify them into difference realization models

Create a decision making Framework with Business Value and Business Criticality as key parameters


SAP AG 2009

Step 4 - Examine qualitative criteria and determine realization

Examine the qualitative criteria of each business capability and determine the desired realization strategy

A common technique is the application of color coding to the existing capability model in order to create “heat maps” of capability realization

The example below is from a Consultancy Business Capability Model

BusinessDevelopment

AccountManagement

EngagementDelivery

RiskManagement

PeopleManagement

Practice &Finace Mgt

Information &Technology

MarketingStrategy

M M

Targeting

M M

StrategicAccountPlanning

L H

StrategicEngagement

Planning

M M

Risk Strategy

RegulatoryStrategy

(Lobbying & Reacting)

Standard Setting

StrategicSkilling &

ResourcingM L

Top TalentStrategy

L L

FinancialPlanning

M M

StrategicSourcing

M L

InformationTechnology

Strategy

M L

Dir

ect/

Str

ateg

yM

ana

gem

ent

Mon

itor

/ D

ete

ct/R

eac

t/C

ontr

ol

MarketingManagement

ProspectQualification

OpportunityManagement

L L

ClientManagement

M M

Sales ProcessManagement

EngagementProject

Management

Escalation /Issues

Management

ConflitResolution

L H

Risk Control

Quality and Legal Review

L L

PeopleAssessment

M L

CapacityManagement

M M

FinancialControls

PracticePerformance Management

Service Management

EnterpriseContent

Management

StandardsCompliance

Target Competency

B = BaseC = CompetitiveML = Market Leader

Exe

cutio

n

MarketingCampaignsAdvertising

MarketResearch

RelationManagement

L H

ProposalCreation

Client & TeamCollaborationResourcingContractingEngagement

PlanningEngagement

Execution

Client Billing

L L

Client Acceptance

L H

EngagementAcceptance

RecruitmentHR

AdministrationDevelopment

& Training

TalentManagement

Financial & Mgt Accounting

FinancialReporting

MethodologyDevelopment

Training CourseDevelopment

Content Creation

Service Delivery

StandardsCreation

Application Delivery & Maintenance

InformationManagement

Revenue / Cost

Revenue

High = $150MMed = $70MLow = $10M

High = $160MMed = $75MLow = $11M

Cost

“Hot“ componentMarketingStandards

© IBM

Step 4 is to examine the qualitative criteria identified in Step 3 and determine realization model

A common technique is to develop a heat map based on the CBM approach referred to in Step 1


SAP AG 2009

Step 5 - Refine target operating model and engagement scope

The outcome of this analysis will be : a set of business capabilities and their priority

a view of how those capabilities need to be developed and delivered, as part of..

a vision of the organization’s target operating model

Expected output of this phase is NOT to formally decompose functions or catalogue services

Business Services are identified as a part of the Business Architecture phase.

The Business Capability Assessment feeds back into Architecture Vision articulate an architecture vision that will address the requirements, within the defined scope

and constraints, and conforming to the business and architectural principles.

generate the first, very high-level, definitions of the as-is (baseline) and to-be (target) environments, from both a business and technical perspective.

The outcome can be used to populate the TOGAF™ Business Transformation Roadmap

Based on the assessment in the previous 4 steps, refine the target operating model and engagement scope

The outcome mostly focuses on what the business capabilities are, which one should be the priority, how they need to be realized and defining the target operating model

Please note that this exercise will not delve into Function/Process or Service decomposition (which will be covered in Business Architecture phase)

The business capability assessment feeds back in to the Architecture Vision

In a way, this phase generates the very first high-level definitions of baseline (“as-is”) and target (“to-be”) business and technical environments


SAP AG 2010



SAP EAF Extensions






SAP AG 2009


In addition to TOGAF™ business capability assessment SAP EAF provides a Technology Capability Assessement

NL-V-P202- Technology Capability Assessment.

This assessement covers SOA and EA topics

It links technology capabilities back to Business Capabilities focussing on re-use and shared business services

Business, technology and support areaddressed

This assessment can also be used as a separate service offering

As we have covered earlier, TOGAF™ does not explicitly include an assessment of the capability to support package or packaged service based Technology architecture

It is critical to the success of the Architecture Vision due to two key reasons

The assessment should be carried out with well known techniques such as structured interviews and other due diligence

EAF provides an Accelerator that contains a set of maturity matrices to score the capabilities

Let us go through those maturity matrices in detail


SAP AG 2009

Analyze IT Landscape Capability

IT Landscape Capability

Item Priority Capability

Architecture:The customer architecture is, fundamentally, a services based architecture lending itself to the addition of further service elements

Technology Re-Use:There is an established practice of technology re-use and service sharing.

Runtime environment:The runtime environment is already available to run enterprise and application services, Web services, or compound services.

Platform & people connectivity:A platform is already available to connect people to enterprise and application services, Web services, or compound services.

Platform & information connectivity:A platform is already available to connect information sources and receivers to enterprise and application services, Web services, or compound services.

Platform availability: The concept is in place that describes how to make an enterprise service highly available and robust from the business perspective.

Platform capacity management:The platform in place is capable of providing a predictable behavior (sizing), support for different levels of service availability, and growth in line with the business needs.

This Step deals with the first dimension of Technology Capability assessment


SAP AG 2009

Analyze Business Organization Capability

Business Organization Capability


Shared Service Mindset: The existing customer mindset already lends itself to SOA and the use of shared services. The customer is already utilizing Packaged Based services.

Shared Service Value: The business fully understands the use and value of shared and common services throughout the organization.

Business Process Maturity:Business processes are formally managed, documented and institutionalized. Business process flows and information criticality understood.

Business Change Management: Formal Change Management is in place to ensure that Business Service change requests are understood, managed and implemented in an appropriate manner. The Business responds well to changes and quickly adopts new process.

Business organization dimension


SAP AG 2009

Analyze Support Organization Capability

Capability of Support Organization


Business Alignment:Support is aligned to business services. Issues, problems and incidents are dealt with based on business criticality. The support organization has a strong awareness of business service priorities.

Service Management Process:Industry best practice support and Service Management processes in place, managed and used by the IT and user community (ITIL, COBIT etc). Resource and capacity in place or easily achievable to manage further services.

Support Toolset:Effective toolset in place for the trapping, monitoring and tracking of events and problems. Interface readily available for additional services or is extendable

Support Organization:Organization aligns with Service Management process. Expertise and resource in place, or can be easily acquired to support additional services.

Architectural Governance:The architecture is governed effectively to ensure that changes and issues are facilitated to reflect the business needs. Formal Change Management is in place to ensure that Business Service change requests are understood, managed and implemented in an appropriate manner.

End-end Service View:The support organization has a full understanding of how the end to end business services are delivered across the IT landscape. This is documented and conforms to Configuration Management practices.

Service Levels Managed:Service Level Agreements (SLAs) and Service Review processes are in place and are actively used. SLAs reviewed and actively managed to ensure appropriate quality of the delivered services.

Supporting organization dimension


SAP AG 2009

Analyze Information Capability

Information Capability


Documented:Business Information fully documented with a clear understanding of the associated business value. Information owners identified. Data lifecycle documented and managed.

Information Flows:Information flows across the application and technology landscape understood and documented. Data shared and accessible wherever value is added or costs are reduced as a result.

Cleanliness:Information “clean” and formatted consistently throughout the business. No “dirty” data is able to enter the environment. New data or interfaces are added in a managed way.

Non Replicated:Information not duplicated within a number of systems or held in stand-alone or point solutions. Information subsets exist only where necessary.

Data Migration Capability:Data migration requirements are understood and the capability to cleanly import or export data exists or can be implemented with confidence.

Data Legislation:Industry or government legislation is fully understood and adhered to. Additional services can be quickly aligned to meet these.

Information dimension


SAP AG 2009

Analyze Priority vs. Capability

Score the outcome

A strong score - minimal additional work will be required to cater for the successful adoption of packaged solutions in the Service-Oriented Enterprise.

A poor score - additional work-stream activities are required to prepare the organization for the architectural implementation and / or the successful ongoing management of the implemented solution

The outcome enables the Vision to be modified appropriately

0

1

2

3

4

5

Information Capability

IT Landscape Capability

Business Organization Capability

Support Organization Capability

Capability

Priority

Once the maturity matrices have been filled out the overall score should be analyzed to evaluate the priority and capability of the enterprise

A Strong score means…..

A Poor score means….

The assessment’s outcome should be fed back into the Vision document


SAP AG 2010



SAP EAF Extensions





Let us now look at the metamodel and the Vision phase specific entities, deliverables etc


SAP AG 2009



SAP AG 2009


ARCHITECTURE VISION, CONTEXT AND ROADMAPAssociatedWith All Objects

Principle Constraint Assumption Gap Work Package

Redraw if needed

Needs to be readible


SAP AG 2009


Goal

Objective

Driver

Con

sum

es

Is trackedagainst

Motivates

Creates

Addresses

Is realisedthrough

Realises

Supplies

ARCHITECTURE VISION, CONTEXT AND ROADMAPAssociatedWith All Objects

Principle Constraint Assumption Gap Work Package

This slide highlights the entities that are relevant to Architecture Vision phase


SAP AG 2009

Architecture Vision Phase - Catalogs, Matrices, and Diagrams 1/2

The following concepts are informally modeled:

Business Principles, Objectives and Drivers

Architecture Vision

Statement of Work

The formally modeled concepts are:


Value Chain Diagram


What are the aspects of Vision phase that are formally and informally modeled


SAP AG 2009

Architecture Vision Phase - Catalogs, Matrices, and Diagrams 2/2

Catalog, Matrix or Diagram

Purpose


The purpose of the stakeholder map is to identify the stakeholders for the architecture engagement, their influence over the engagement and their key questions, issues or concerns that must be addressed by the architecture framework.

Understanding Stakeholders and their requirements allows an architect to focus effort in areas that meet the needs of stakeholders.

Due to the potentially sensitive nature of stakeholder mapping information and the fact that the Architecture Vision phase is intended to be conducted using informal modeling techniques, no specific metamodelentities will be used to generate a stakeholder map.

Value Chain Diagram

A Value Chain Diagram provides a high-level orientation view of an enterprise and how it interacts with the outside world. In contrast to the more formal Functional Decomposition Diagram developed within the Business Architecture phase, the Value Chain Diagram focuses on presentational impact.

The purpose of this view is to quickly on-board and align stakeholders for a particular change initiative, so that all participants understand the high-level functional and organizational context of the architecture engagement.


A Solution Concept Diagram provides a high-level orientation of the solution that is envisaged in order to meet the objectives of the architecture engagement. In contrast to the more formal and detailed architecture Diagrams developed in the following phases, the Solution Concept represents a “pencil sketch” of the expected solution at the outset of the engagement.

This Diagram may embody key objectives, requirements and constraints for the engagement and also highlight work areas to be investigated in more detail with formal architecture modeling.The purpose of this Diagram is to quickly on-board and align stakeholders for a particular change initiative,so that all participants understand what the architecture engagement is seeking to achieve and how it is expected that a particular solution approach will meet the needs of the enterprise.

The key matrix and Diagrams are described on this slide

Go through the purpose of each artifact briefly…..


SAP AG 2009

Example Stakeholder Map Matrix

Stakeholder Group

Stakeholder Ability to disrupt the change

Current understanding

Required understanding

Current commitment

Required commitment

Required support

CIO John Smith H M H L M H

CFO Jeff Brown M M M L M M

Stakeholder analysis should be used during the Vision Phase to identify the key players in the engagement

Complex architectures are extremely hard to manage, not only in terms of the architecture development process itself, but also in terms of getting buy-in from the large numbers of stakeholders touched by it.

NL-F-P006 Stakeholder Map provides a template stakeholder map and a step-by-step guide

The output is a Stakeholder Map matrix

We have covered this in detail earlier and here is an example of Stakeholder map matrix


SAP AG 2009

Example Value Chain View Suppliers &

Partners Customers &

Channels Engineering Procurement Manufacturing Sales & Distribution Customer Service


Time-to-Market

New Product Development and Introduction Life-cycle Data Management

Supplier Collaboration

Strategic Sourcing Operational Procurement and Inbound Logistics

Build-to-OrderSupply-to-line


Sales & Marketing

Brand and Customer Management Vehicle Lifecycle Management Vehicle Planning & Forecasting

Order-to-Delivery


Interaction Center


An example of Value Chain View


SAP AG 2009

Example Solution Concept Diagram

Innovation FrameworkInnovation Framework

Portfolio ManagementPortfolio Management Integrated Product DevelopmentIntegrated Product Development

Enterprise PlatformEnterprise Platform

Process ManagementProcess Management

Develop an enterprise wideplatform that establishescontext for Innovation, Global product development, Qualityand ComplianceCentralized and standardizeddocument managementsystemProduct definitions aretransferable betweenmanufacturing sites

Establish a sustainableand comprehensibleglobal system to make decisions.

Focus on economicvalue creation.

Put forward -thinkinginto where thebusiness is going.

n

n

-

Manage ContinuousInnovation, Enableeffectivecollaboration within<Customer> and Partners, Design of streamlined businessprocesses supportedby legal/ procurementframework

Streamline “ innovation ” & “product development ” processes where processes are standardized, predictable and repeatableManage processes effectively to improve efficiencyBuild maturity in organizational capabilities

An example of Solution Concept view


SAP AG 2009

Summary

This is the end of the Architecture Vision Phase

You should now know how to create : An Approved Statement of Architecture

Work Scope and constraints Stakeholder Map Matrix An agreed set of TOGAF™ extensions to be

used; An agreed, defined Engagement Schedule The engagement Project Plan

Refined statements of Business Principles, Business Goals and Strategic Drivers

A set of Architecture Principles An Architecture Vision

A definition of the Business Capability of the customer organization

A definition of the Technical Capability of the customer organization


The next phase is Business Architecture


We reviewed the Vision phase in detail and you should be able to create the necessary outputs.… (Notes – go through the bullet items)

In the next unit we will cover Business Architecture phase in more detail



Exercises

Unit: Architecture Vision

Topic: Business Capability Analysis

At the conclusion of this exercise, you will be able to:

Understand a technique to analyze enterprise wide business capabilities

Determine which capabilities are “CORE” and which ones are “CONTEXT” to an enterprise

Define appropriate and valid options for realizing those capabilities

Scenario

To develop an Architecture Vision, SAP EAF prescribes that a business and capability assessment be performed. The output of such assessments will become an input to developing an Architecture Vision. In this exercise, students will utilize one of the techniques of performing the business capability assessment and evaluate the realization options for fulfilling those capabilities.

1-1 Steps for the Exercise 1-1-1 Please refer to any one of the industry specific business solution maps in

Solution Composer 1-1-2 Decompose Business Capabilities/Functions 1-1-3 Develop a CORE-CONTEXT analysis of the business capabilities for this

enterprise (Consider business value, criticality and differentiator as key parameters for your evaluation)

1-1-4 Document your findings in the template shown in the next section 1-1-5 Present your findings to the team

1-2 Template for this Exercise

Business Function or Capability

CORE (1) CONTEXT Realization Option (2)

Comments

Notes 1-2-1 Determine CORE or CONTEXT using the criteria below

Business Value Business Criticality

For additional Criteria provided in Step 2 of Business Capability Assessment



1-2-2 Realization options to consider Automated Vs manual

Out-source Vs In-source

Custom application (best of breed) Vs Packaged SW

Build Vs Buy

Consume internally or from outside

1-3 Questions to cover during group presentation 3 pt1-3-1How did you determine the capability is CORE or CONTEXT? Discuss with

the class. 1-3-2 What is the rationale behind “Realization Option”? 1-3-3 What is your key learning point?

Solutions

Unit: Architecture Vision

Topic: Business Capability Analysis

1-1 One possible solution

Business Function or Capability

CORE CONTEXT Realization Option Comments

Product Development

Core Automated

In-source

Custom Development

Build

Collaboration

Differentiator

Time-to-market

Improve service delivery; reduce time-to-market; develop new markets

Service Execution Core Automated

In-source

Packaged SW

Buy

Consume internally

Criticality

After Sales Support

Improve customer service; service delivery

Enterprise Asset Management

Context Automated

Outsource

Packaged

Buy from outside

Business value

Operations Support

Reduce Administration; improve business processes; reduce operating costs & increase efficiency



SAP AG 2009

Unit 4 - SAP EAF Phase B: Business Architecture


©SAP AG SOA200 8-1

SAP AG 2009

TOGAF™ Phase B: Business Architecture

Contents:

Introduction to Business Architecture Phase

SAP EAF Extensions

Service Contracts


Catalogs, Matrices, and Diagrams

©SAP AG SOA200 8-2

SAP AG 2009







©SAP AG SOA200 8-3

SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools


Usage Guidelines Framework tailoring Engagement Initiation Using EA to implement SOA Service Contracts Business Capability Assessment Technology Capability

Assessment IT Governance Impact

Assessment Solution Architecture Scoping Glossary





In this Unit we are going to focus on the Business Architecture Phase

©SAP AG SOA200 8-4

SAP AG 2009



SAP EAF Extensions

Service Contracts



©SAP AG SOA200 8-5

SAP AG 2009

Business Architecture Phase - Overview

The Business Architecture phase is about defining the As-Is and To-Be business architectures for the organization, detailing the roadmap towards the To-Be architecture, and identifying key work packages in the roadmap.


What is the Business Architecture phase about?

In this phase

We define the “as-is” and “to-be” business architectures for the enterprise

Define a roadmap to get to “to-be” architecture and

Identify key work packages in the roadmap

©SAP AG SOA200 8-6

SAP AG 2009

Business Architecture - Main Objectives

To describe the Baseline Business Architecture

To develop a Target Business Architecture, describing

the product and/or service strategy

the organizational, functional, process, information, and geographic aspects of the business environment

To analyze the gaps between the Baseline and Target Business Architectures

To select and develop the stakeholder-relevant architecture viewpoints

To select the relevant tools and techniques to be used in association with the selected viewpoints

Based on material licensed from the Open Group Copyright © 2009

©SAP AG SOA200 8-7

SAP AG 2009

Business Architecture Phase - Approach

The Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work

The scope of the work in this phase will depend to a large extent on the enterprise environment and existing materials (Business Strategy, IT Strategy, Business and IT requirements)

Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort:

New business processes will necessarily involve a lot of detailed work

If the focus is more on the To-Be Architectures in other domains (application systems, data/information, infrastructure), then don’t go into unnecessary detail


©SAP AG SOA200 8-8

SAP AG 2009

TOGAF™ Business Architecture Phase - Inputs and Outputs

BusinessArchitecture

Phase



Business Principles, Goals, Drivers

Approved Statement of Architecture Work



Updated Statement of Architecture Work

Validatd Business Principles, Goals, Drivers

Draft Architecture Definition Document

Draft Architecture Requirements Specification

Communications Plan


Architecture Principles, if existing

Enterprise Continuum

Architecture Vision


Business Architecture components of an Architecture Roadmap

©SAP AG SOA200 8-9

SAP AG 2009

TOGAF™ Business Architecture Phase - Overview of Steps

Finalize Business Architecture

Resolve Impacts Across the Architecture Landscape

Perform Gap Analysis

Define Roadmap Components

Conduct Formal Stakeholder Review

Select Reference Models, Viewpoints, and Tools

Develop Baseline Business Architecture Description

Develop Target Business Architecture Description

Create Architecture Definition Document

TOGAF™



SAP AG 2009



Select Reference Models

Many valuable reference models, viewpoints and tools are available to support creation of a business architecture.

SAP provide a collection of Business Maps that define reference models for various industries and solution type

Determine Overall Modeling Process

Structured Analysis – Identifies the key business functions within scope of the architecture, and maps those functions onto the organizational units within the business

Use Case Analysis – The breakdown of business level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability

Process Modeling – The breakdown of a function or business service through processmodeling allows the elements of the process to be identified, and permits the identification of lower level business services or functions



SAP AG 2009


Select Reference Models, Viewpoints, and Tools (cont.)

Identify Required Service Granularity Level, Boundaries, and Contracts TOGAF™ articulates the difference between functions and services by defining

services as having explicit interfaces, measures and boundaries.

There is a need to identify which components of the architecture are functions and which are services.

The granularity of Business Services should be determined according to the business drivers, goals, objectives and measures for this area of the business. Finer grained services permit closer management and measurement, but also require greater effort to govern

Identify Required Catalogs of Business Building Blocks

Identify Required Matrices

Identify Required Diagrams

Identify Types of Requirement to be Collected Functional and Non-functional requirements

Assumptions, Constraints

Domain-specific Business Architecture principles

Policies , Standards

Guidelines, Specifications



SAP AG 2009



The Business Baseline provides a view of current state architecture

Scope and level of detail will depend on the extent to which existing business elements are likely to be carried into the target business architecture



Perform trade-off analysis to resolve conflicts (if any) among the different views

Validate that the models support the principles, objectives, and constraints

Test architecture models for completeness against requirements

Identify gaps between the baseline and target:

Create gap matrix (-> example next slide)



SAP AG 2009

TOGAF™ Gap Matrix Example

Example from SAP Case Study project focusing on Application Architecture

To-be (x-axis)

As-is (y-axis)SAP R/3 VMS DMS SAP IPC Eliminated Apps

SAP R/3

System of

record for BP,

Product master

data and

configuration

rules

VMS

Supports

configuration

rules

DMS

Supports

configuration

rules

BYB

Catalog is

published and

supports product

pricing function

Replaced with

SAP IPC

ImpSales

Legacy

application that

supports RNI’s

catalog

management

process

Replaced with

VMS

New Apps

SAP IPC is a new

application that

will be added to

landscape


SAP AG 2009


Define Roadmap Components Following creation of a Baseline Architecture, Target Architecture, and gap analysis results,

a business roadmap is required to prioritize activities over the coming phases

Phase Phase Category Gap Name or

Classification

Criticality (High,

Medium or Low)

Priority (High,

Medium or Low)

Priority

Ranking

Business Service Gaps Catalog authoring service

High High 1

Catalog

personalization service

High High 1

Catalog search High High 1

Process Gaps Lack of automation Medium Medium 2Best practices High Medium 2

Organizational Gaps Streamline Medium Medium 2

Training Medium Medium 3

Information System Application Integration High High 2Application

replacements

High High 2

Master data High High 2Data Data migration

considerations

High High 2

Unicode conversion High High 2

Technology Technology Standards Medium Medium 3Infrastructure Medium Medium 3

Safe harbor status Medium Low 3

SAP Case Study

example


SAP AG 2009



Does this Business Architecture create an impact on any pre-existing architectures?

Have recent changes been made that impact on the Business Architecture?

Are there any opportunities to leverage work from this Business Architecture in other areas of the organization?

Does this Business Architecture impact other projects (including those planned as well as those currently in progress)?

Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)?



SAP AG 2009



Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture

SAP recommends not to do this step

Finalize the Business Architecture

Select standards for each of the building blocks, re-using as much as possible from the reference models

Fully document each building block

Conduct final cross-check of overall architecture against business goals

Document rationale for building block decisions in the architecture document

Document final requirements traceability report

Document final mapping of the architecture within the Architecture Repository

Finalize all the work products, such as gap analysis results



SAP AG 2009



Document rationale for building block decisions in the Architecture Definition Document

Prepare the business sections of the Architecture Definition Document, comprising some or all of:

A business footprint (a high-level description of the people and locations involved with key business functions)

A detailed description of business functions and their information needs

A management footprint (showing span of control and accountability)

Standards, rules, and guidelines showing working practices, legislation, financial measures, etc.

A skills matrix and set of job descriptions



SAP AG 2009

Example: Architecture Definition Document according to TOGAF (Phase B)

Table of Content: Architecture Definition Document

Scope

Goals, objectives, and constraints

Architecture principles

Baseline Architecture

Architecture models (for each state to be modeled): Business Architecture models

Data Architecture models

Application Architecture models

Technology Architecture models

Rationale and justification for architectural approach

Mapping to Architecture Repository: Mapping to Architecture Landscape

Mapping to reference models

Mapping to standards

Re-use assessment

Gap analysis

Impact assessment



SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions

Service Contracts

Populating the MetaModel


Now we can look at the EAF specific extensions


SAP AG 2009


Business

Architecture

Phase


BEEST Case Study

SAP EAF Templates

SAP EAF Business Architecture Narrative

SAP EAF Metamodel and View Definition

TOGAF™ ADM Business Architecture Narrative

SAP EAF Business Architecture Worksheet

SAP EAF to SAP Terminology Mappings

SAP EAF Glossary

Service Contract Guidelines

Additional Inputs

Additional outputs

Additional step(s)

Updated Business Requirements, Policies, Standards, Guidelines and Specifications

Updated Service Contracts (draft)

Update Business Services, Contracts

Solution Composer Whitepaper


SAP AG 2009

Business Architecture Phase - TOGAF™ and EAFSAP EAF Extensions

Update Business Services and Contracts

Finalize Business Architecture









TOGAF™


SAP AG 2009

Business Architecture Phase - SAP EAF Extensions

Before we continue, we need to introduce some terms:

Function. A function is a thing that a business does. Services supportFunctions, are Functions and have Functions, but Functions are not necessarily Services. Services have more specific constraints than Functions.

Business Service. A Business Service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. A Business Service is supported by combinations of people, process and technology.

Information System Service. An Information System Service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. Information System Services are directly supported by applications and have associations to SOA service interfaces.


SAP AG 2009

Business Architecture - Functions and Flows

Level 0 Functions

wholegoods,

invoices

DealersProduceproducts

Developnew products

Wholegoodslogistics

marketrequirements

marketrequirements

and forecasts

whole goods

forecasts

components

wholegoods,invoicesproduct

designs

Suppliers

Customerssupplier

selection,supply

requirements

spareparts

marketlaunch plan

industryand competitor

information

spaeparts

spare parts,invoices

orders

spare parts,invoices

orders

orders

promotion

Marketproducts

Spare partslogistics

supplyrequirements


SAP AG 2009

Example: Functions in Federal Government (FEAF Business Reference Model)


SAP AG 2009

Example: Business Services in Federal Government (FEAF Service Reference Model)


SAP AG 2009


Business Services

are independent of business function

are tracked by Measures (KPIs) to determine successful operation and progress towards objectives and goals

meet Service Qualities

preset configuration of non-functional attributes

are governed by Contracts

An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction


SAP AG 2009



Identify Business Services


SAP AG 2009


Update Business Services and Contracts (cont.)

Design Services, consider governance processes

Once you know you need a service, and want to automate it

You will need to architect its provision and how its governed

Service Oriented Application

Service Container

Service InterfaceService

Operation

Enterprise Service

Data

Functionality

State ReferenceData

TransactionData

Packages

Components

ObjectsConfiguration

Service Consumer

Policy

Registry/ Repository

Service Location

Service Policy

Service Interface

Service Presentation

User

Security Enforcement and ManagementBusiness Event Management

Business Information Management

Service LifecycleManagement

DevelopmentTooling

Software Lifecycle

Management

System Operation


SAP AG 2009


Update Business Services and Contracts (cont.)

Update Contracts (TOGAF™ and SAP provide similar templates for service contracts)

What are the various attributes of Service Contracts

This slide summarizes the classification of Service contract attributes

The details of General, Business, NFR and Technical attributes


SAP AG 2009

Service Contracts


SAP EAF Extensions

Service Contracts



Let us look one of the key deliverable that clearly differentiates Functions from Services – Service Contracts


SAP AG 2009

Service Contracts in TOGAF™ and SAP EAF

TOGAF™ Technical Reference Model

Service Contracts relate to qualities in the TOGAF™ TRM

SAP also considers Service Contracts between Business Units

Service qualities are specified in detail during the development of the Target Architecture, and then used on an ongoing basis to govern and measure the success of the architecture

Service Contracts need special consideration in SOA environments. TOGAF™ and SAP EAF provides insight and assistance with this

Qualities

Qualities




Network Services


System

& N

etwo

rkM

anag

emen

t

So

ftware E

ng

ineerin

g

Application Platform InterfaceD

ata Man

agem

ent

Lo

cation

& D

irectory

Data In

terchan

ge

Intern

ation

al Op

eration

s

Tran

saction

Pro

cessing

Secu

rity

Grap

hics &

Imag

e

User In

terface

Besides defining the components of TRM, TOGAF™ also talks about a set of attributes that are applicable across the components

TOGAF™ addresses the concept of Services in general


SAP AG 2009

SAP example: How to define Service Contracts

For each candidate Service identified, the following steps are then required: Define the Service

Identify what value the Service provides to prospective consumers

Describe the functionality of the Service

Delineate quality of service and applicability constraints

Define the constraints on the types of consumers or other consumption requirements

Define semantic formats for requests

Identify conditions for particular outcomes and behaviours

Determine the flow of processes and activities and steps leading to outcomes

Document the information defined as Service Contracts

SAP also recommends a bottom-up analysis based on available services as part of the Enterprise Package or Package Services that already exist in an organization.

Consult an existing Service Repository (e.g. SAP ES Workplace – screenshot opposite) https://www.sdn.sap.com/irj/sdn/esworkplace

Use available Solution Maps (e.g. SAP’s Solution Composer tool) to identify candidate services.

http://www.sap.com/solutions/businessmaps/index.epx

Getting into the details of Service contracts

Once the Services have been defined in the earlier steps, for each Service it is important to define the service contracts. The contracts typically include

Name & define the Service, what functionality it provides, quality characteristics, how it can be invoked etc

SAP EAF also recommends a bottom-up analysis of available existing services namely Enterprise package or Package Services that already exist in the organization

It prescribes to consult an existing Service Repository or use the Solution maps to identify candidate Services


SAP AG 2009

Service Contract Template

General Reference

Name

Description

Source

Owner

Type

Version

Technical Invocation

Invocation Preconditions

Master Data Impacted

Behaviour Characteristics

Post Condition

Non-Functional Requirements Throughput

Throughput period

Growth

Growth period

Service times

Peak profile short term

Peak profile long term

Security requirements

Response requirements

Business RACI

Service name ‘caller’

Service name ‘called’

Business Objects (CRUD)

Functional Requirements

Importance to the process.

Quality of information required

Contract control requirements

Result control requirements

Quality of Service

Service Level Agreement

What are the various attributes of Service Contracts

This slide summarizes the classification of Service contract attributes

The details of General, Business, NFR and Technical attributes


SAP AG 2009

Service Contracts and Governance for SOA

The Plan

To avoid this

Service Contracts

Key tools for communicating and enforcing policies.

ensure a healthy provider/consumer relationship and help to establish an agreement and maintain trust between these parties.

A precise and unambiguous agreement for how the provider and consumer interact

Service Policies

The nature of SOA (highly distributed, heterogeneous and very dynamic) means that it is critical for SOA artifacts to be governed by specific business, technical and regulatory policies.

Policies must be used to validate services before they are published, and as a basis for enforcing specific standards and behaviours at run time.

Standard policies apply to all services and reduce “local solutions”

Service Lifecycle Management

Ensuring the quality, performance and applicability of services that are published

Providing a means for consumers to discover and reuse services and other artefacts

Managing versions, security and state-change of services and other artefacts

Assessing and managing the impact of change across a network of consumers.

Services are activity managed

Service Metadata

Let us look at the relationship between Service Contracts and Governance, how the contracts facilitate effective Governance

One of primary advantage is that Service Contracts stop the proliferation of SOA Chaos and Services sprawl

Contracts

They serve as a key tool to communicate and enforce policies

Describes the interaction between consumer and provider precisely

Both get what they expect and no surprises

On the policy end SOA policies cannot be hard coded into an application and can only be coupled with Services

Lifecycle Management - Service artefacts need to be managed across a complete lifecycle

Metadata - In traditional IT environments, metadata is typically defined within the code of systems and applications


SAP AG 2009



SAP EAF Extensions

Service Contracts




SAP AG 2009


The entities relevant to Business Architecture phase is in the forefront


SAP AG 2009

Approach to creating the architecture

Diagram

Catalog

Matrix

SAP EAF artefact

Business .

Application .

Data .

Technology.

FunctionalDecomposition

Application– Data

ApplicationCommunication


Conceptual / LogicalER Diagram

Data DisseminationDiagram

Data Entity / Business Function

Environments and Locations

Organisation / Actor

RoleActor/ Role

Application Portfolio

Technology PortfolioTechnology Standards

B. Service / Function

Role / System

Data Entity / DataComponents

Location

PlatformDecomposition

System / Data

Process Flow

Use Case

Organisation Decomposition

Organisation Chart

Events

Process / System Realisation

Enterprise Manageability

Data Lifecycle

Data Security

Data- System

NetworkedComputing /

Hardware

Communications

Standards

Process/ Event / Control / Product

System / Organisation

System / Function

System / Technology

System / Location

Application Interaction

Business InteractionContract / Measure

Driver / Goal / Objective

Business Footprint

B. Service / Inform.

Goal/ Objective/Service

Software Engineering

Software Distribution

Application Migration

Data Migration

Data Hierarchy

Processing

Cost

Interface Catalog

System Use Case

Product Lifecycle

So how do we assemble all the pieces of the complex puzzle called Enterprise Architecture

Enterprise Architecture in general is often defined as providing Structure, Context and enables operations of Services Oriented Architecture

This slide provides another view of the deliverables organized by Structure, Context and Operations


SAP AG 2009

Catalogs, Matrices, and Views


SAP EAF Extensions

Service Contracts




SAP AG 2009

Business Architecture Phase - Catalogs, Matrices and Diagrams

Most concepts are formally modeled apart from Standards, Guidelines, and Specifications

The formally modeled concepts are :

Catalogs Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog

Matrices Business Interaction Matrix Actor / Role Matrix

Core Diagrams Business Footprint diagram Business Service/Information

diagram Functional Decomposition

diagram Product Lifecycle diagram Organizational chart (SAP

extension) Extension Diagrams

Goal/Objective/Service diagram

Use-case diagram Organization Decomposition

diagram Process Flow diagram Event diagram

This slide shows the concepts that are formally modeled

All the deliverables are architecturally relevant except for Standards, Guidelines and Specifications

We will go through each one of the artifacts in more detail


SAP AG 2009

Business Architecture Phase - Catalogs 1/3


Purpose


The purpose of the Organization / Actor catalog is to capture a definitive listing of allparticipants that interact with IT, including users and owners of IT systems.

The Organization / Actor catalog contains the following metamodel entities:

Organization Unit, Actor, Location may be included in this catalog if an independent location catalog is not maintained


The purpose of the Driver / Goal / Objective catalog is to provide a cross organizationalreference of how an organization meets its drivers in practical terms through goals,objectives and optionally measures.

The Driver / Goal / Objective catalog contains the following metamodel entities:

Organization Unit, Driver, Goal, Objective, Measure may optionally be included

Role Catalog The purpose of the Role catalog is to provide a listing of all authorization levels or zoneswithin an enterprise. Frequently, application security or behavior is defined against locallyunderstood concepts of authorization that create complex and unexpected consequenceswhen combined on the user desktop.

The Role catalog contains the following metamodel entities:

Role

Notes – Describe each catalog briefly


SAP AG 2009



Purpose

Business Service / Function Catalog

The purpose of the Service / Function catalog is to provide a functional decomposition in aform that can be filtered, reported on and queried, as a supplement to graphical functionaldecomposition Diagrams.

The Service / Function catalog contains the following metamodel entities:

Organization Unit, Business Function, Business Service, Information System Service may optionally be included here

Location Catalog The Location catalog provides a listing of all locations where an enterprise carries outbusiness operations or houses architecturally relevant assets, such as data centers or enduser computing equipment.

The Location catalog contains the following metamodel entities:

Location

Process / Event / Control Catalog

The Process catalog provides a hierarchy of processes, events that trigger processes,outputs from processes and controls applied to the execution of processes.

The Process / Event / Control / Product catalog contains the following metamodel entities:

Process, Event, Control ,Product



SAP AG 2009



Purpose


The Contract / Measure catalog provides a listing of all agreed service contracts and theoptionally the measures attached to those contracts. It forms the master list of ServiceLevels agreed to across the Enterprise.

The Contract / Measure catalog contains the following metamodel entities:

Business Service Optionally Information System Service Contract Measure



SAP AG 2009

Example Catalogs

InfrastructureConsolidation Extension Governance Extension

Process ModellingExtension Data Modelling Extension

Business / IT AlignmentExtension Core Content






Organisation Unit

Goal

Objective


(Business, Information System) ServiceServices are Contained in Core , Business / IS split supports the Business / IT Alignment Extension

Function

Process

Actor

Role




Data Entity



Extension


Data Extension







Principle Constraint Requirement


Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Hostedin


Encapsulates

Resides within



Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedthrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Participatesin


Performstask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by


Produces

Is Producedby

Involves

Participatesin

Involves


Generates, Resolves

Is Resolved by



Or chestrates,

decom

poses


I sgu id

edby

Governs, Measures

Is governed and measured byIs Provided to


Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby





Role Catalog


Location Catalog




SAP AG 2009

Example Catalogs


Also includes Location Catalog


SAP AG 2009

Example Catalogs


Business Drivers Business Goals Objectives 2009

Increased complexity

Increased competitive pressure

Increased globalisation

Increased trade consolidation

Speed of time to market

Fastest growing company in our market share

Improve profitability in market unit X through innovation and streamlining

Rapid growth and higher earnings in market unit Z

Long-term growth in APJ through building up market positions

Develop real estate

Constant adaptation to a market situation featuring keen competition on marketing, innovation, cost-efficiency, and new investments and acquisitions

Evaluate and compare the individual markets’ stage of development, risk profile and potential profitability within the overall portfolio

Streamline / harmonise distribution of resources between different regions

Centralise back-office functions

Create centres of excellence in areas such as innovation


SAP AG 2009

Example Catalogs

Role Catalog

SAP PACE profiles


SAP AG 2009

Example Catalogs



SAP AG 2009

Business Architecture Phase - Matrices

PurposeCatalog, Matrix or View

The purpose of this matrix is to show which actors perform which roles, supporting definitionof security and skills requirements.

Understanding actor to role relationships is a key supporting tool in definition of trainingneeds, user security settings and organizational change management,

The Actor / Role Matrix shows the following metamodel entities and relationships: Actor Role Actor performs Role relationships

Actor / Role Matrix

The purpose of this matrix is to depict the relationship interactions between organizationsand business functions across the enterprise.

Understanding Business Interaction of an enterprise is important as it helps to highlight valuechain and dependencies across organizations.

The Business Interaction Matrix shows the following metamodel entities and relationships: Organization Business Function Business Service Business Service communicates with Business Service relationships Business Service is dependent on Business Service relationships


Notes – Describe each matrix briefly


SAP AG 2009

Example Matrices

CIO

Ent

erpr

ise

Arc

hite

ct

Ent

erpr

ise

Des

ign

Aut

hori

ty

Tec

hnic

alD

esig

n A

utho

rity

IT M

anag

emen

t For

um

Bus

ines

s U

nit H

ead

Bus

ines

s U

nit S

ervi

ce O

wne

r

Bus

ines

s U

nit A

pplic

atio

nA

rchi

tect

Hea

dof

Str

ateg

yan

d A

rchi

tect

ure

Infr

astr

uctu

reS

trat

egi

st

Infr

astr

uctu

reS

olut

ion

Arc

hite

ct

Arc

hite

ctur

eC

onfig

urat

ion

Man

ager

Ent

erpr

ise

Infr

astr

uctu

reA

rchi

tect

Hea

dof

Impl

emen

tatio

n

Infr

astr

uctu

reD

esig

ner

Strategy Lifecycle RolesArchitecture Refresh I R A I C C R C C C I I R I C CArchitecture Roadmap I C A I R C C I C R I I R C C I CBenefits Assessment I I I I I I I I I R R I C AChange Management C I A I I I R I I I R R CFramework Refresh C C C C C I C A I I I R C C IProject Lifecycle RolesSolution Architecture Vision I I I A I I C C I I R I C C RLogical Solution Architecture A I I C C I I R I C C C RPhysical Solution Architecture A I I C C I I R I C R C RDesign Governance A I I C C I I R I C R C CArchitecture Configuration Management C I I R R R A

R = Responsible for carrying out the role

A = Accountable for actors carrying out the role

C = Consulted in carrying out the role

I = Informed in carrying out the role

Ext

ern

alV

endo

rs/

Sup

plie

rs

Strategy and ArchitectureActors

InfrastructureImplementation

Actors

IT O

pera

tions

Office of CIO Actors

Steering Group Actors

Business Unit Actors

Pro

ject

Man

ager

Consuming Business Services Engineering Procurement Manufacturing Sales and Distribution Customer ServiceEngineeringProcurement

ManufacturingContract for

supply of materials

Contract for supply of sales forecasts

Sales and Distribution

Contract forsupply of product

specification

Contract forsupply of product

Customer Service Contract for fulfillment of customer orders

Providing Business Services

• Example Business Interaction Matrix

Example Actor - Role Matrix

Example of a matrix


SAP AG 2009

Business Architecture Phase - Core Diagrams


Purpose


A Business Footprint Diagram describes the links between business goals, organizational units, business functions and services, and maps these functions to the technical components delivering the required capability.

A Business Footprint Diagram demonstrates only the key facts linking organization unit functions to delivery services and is utilized as a communication platform for senior (CxO) level stakeholders.

Business Service / Information Diagram

The Business Service / Information Diagram shows the information needed to support one or more Business Services. The Business Service / Information Diagram shows what data is consumed by or produced by a Business Service and may also show the source of information.


The purpose of this Diagram is to show on a single page the capabilities of an organization that are relevant to the consideration of an architecture.

By examining the capabilities of an organization from a functional perspective, it is possible to quickly develop models of what the organization does without being dragged into extended debate on how the organization does it.


The purpose of the Product Lifecycle diagram is to assist in understanding the lifecycles of key entities within the enterprise. Understanding product lifecycles is becoming increasingly important with respect to environmental concerns, legislation, and regulation

Equally, organizations that create products that involve personal or sensitive information must have a detailed understanding of the product lifecycle during the development of Business Architecture in order to ensure rigor in design of controls, processes, and procedures.

Notes – Describe each CORE Diagram briefly


SAP AG 2009

Example Core Diagrams



SAP AG 2009


Business Service / Information Diagram

Complaint Handling

Service

Complaint

CommonFaults

CustomerDetails

CustomerDetails

ComplaintResolution

Examples of CORE Views


SAP AG 2009





SAP AG 2009





SAP AG 2009

Business Architecture Phase - Extension Diagrams


Purpose

Organization Decomposition Diagram

An Organization Decomposition Diagram describes the links between Actor, Roles and Location within an organization tree. An organization map should provide a chain of command of owners and decision makers in the organization.

Event Diagram The purpose of this Diagram is to depict the relationship between events and process.Certain events such arrival of certain information (e.g. customer submits sales order) or a certain point in time (e.g. end of fiscal quarter), causes work and certain actions need to be undertaken within the business.

These are often referred to as “Business Events” or simply “Events” and are considered as “triggers” for a process.

The Diagram could be adapted to show event variation across global business units to highlight harmonization opportunities.

Goal / Objective / Service Diagram

The purpose of a Goal / Objective / Service Diagram is to define the ways in which a Service contributes to the achievement of a business vision or strategy.

Services are associated with the Drivers, Goals, Objectives and Measures that they support, allowing the enterprise to understand which services contribute to similar aspects of business performance.

Notes – Describe each Extension view briefly


SAP AG 2009

Business Architecture Phase - Extension Diagrams


Purpose

Use-case diagram A Business Use-Case diagram displays the relationships between consumers and providers of business services. Business services are consumed by actors or other business services and the Business Use-Case diagram provides added richness in describing business capability by illustrating how and when that capability is used.

The purpose of the Business Use-Case diagram is to help to describe and validate theinteraction between actors and their roles to processes and functions. As the architectureprogresses, the use-case can evolve from the business level to include data, application, and technology details. Architectural business use-cases can also be re-used in systems design work.

Process Flow diagram

The purpose of the Process Flow diagram is to depict all models and mappings related to the process metamodel entity.

Process Flow diagrams show sequential flow of control between activities and may utilize swimlane techniques to represent ownership and realization of process steps. For example, the application that supports a process step may be shown as a swim-lane.In addition to showing a sequence of activity, process flows can also be used to detail thecontrols that apply to a process, the events that trigger or result from completion of a process, and also the products that are generated from process execution.

Notes – Describe each Extension view briefly


SAP AG 2009

Example Extension Diagrams

Organizational Decomposition Diagram

org-Worldwide Public Affairs and Policy

rol-CEO

rol-WolrdwideCommunications

rol-Philanthropy/Stakeholder Advocacy

rol-Worldwide Policy

rol-Federal Government relations

rol-Field Based Govt. Relations rol-Wolrdwide

Medical

rol-Safety RiskManagement

rol-ScienceAdvocacy

org-Chief MedicalOfficer

rol-WolrdwideResearch

rol-WorldwideDevelopment

rol-WorldwideResearch Affairs

org-GlobalResearch & Development

rol-ViceChairman

rol-Global Manufacturing

rol-CFO

rol-WorlwideStrategic Planning

rol-Animal Health

rol-Worldwide Licensingand Business Develoment

rol-Wolrdwide Technology

rol-Business Services

rol-Wolrdwide Investor Development

rol-Internal Audit

rol-FinancialStrategy

rol-HumanResources

rol-Site Leader(s)

rol-Wolrdwide PharmaceuticalOperations

loc-US

loc-Japan/ASIA

loc-Europe

loc-Middle East

loc-Canada

org-Wolrdwide talentDevelopment and HR

rol-Talent Development

rol-HealthWelness

rol-Planning

rol-Diversity and Inclusion

rol-compensation and Benefits

org-GeneralCounsel

rol-Intellectual Property

rol-Employment Law

rol-Line Support

rol-Litigation/Regulatory

rol-Business Transactions

rol-Complinace Officer


SAP AG 2009


Event Diagram

Examples of Extension Views


SAP AG 2009


Goal-Objective-Service Diagram

gol-Increaserevenues

obj-creating newline of cars by the

end of...

obj-"aftersales“market

Function-sales and marketing

cap-Marketing

cap- campaign

cap-Order-to-Delivery

rol - CFO

rol-VP Marketing rol-VP Sales

cap-Sales

cap-Pre-Owned vehica...

cap-Pre-sale

Examples of Extension Views


SAP AG 2009


Use Case Diagram

ContractDepartment

Proposal Process

<<include>>

Quote Process

Order Process

Customer

Billing Distributor

<<include>>

Supplier

Finace Company

Executive Decision Maker

Executive Decision Maker

Installation & Commissioning

Manufacturing

Post-Sale Services

Example of Extension view


SAP AG 2009



Example of Extension view


SAP AG 2009

Summary

This is the end of the Business Architecture Phase

You should now know how to develop : A Target Business Architecture including:

Catalogs

Matrices

Diagrams

Service Definitions and Contracts

Gap Analysis

Technical Requirements

Business Architecture Roadmap

Updated business requirements

The next phase is Information SystemsArchitectures - Applications


We reviewed the Business Architecture phase in detail and you should be able to develop the necessary outputs.…

In the next unit we will cover Information System Architecture phase in more detail



Exercises

Unit: Business Architecture

Topic: Business Service Definition


A technique to perform business function decomposition

Decompose business functions into multi levels and define candidate Business Services

Utilize SAP reference model ES Workplace to identify the Enterprise Services available to support a Business Service

Scenario

Business Architecture is the first phase of “Architecture Development” iteration and it includes three key elements namely Motivation, Organization and Function.

The functional element comprises business processes, business functions and business services, business events and business controls. While analyzing the business architecture it is imperative to perform a functional and process decomposition to define business services at appropriate levels of granularity and draw the service boundaries.

In this exercise, you will utilize SAP EAF prescribed techniques to decompose a specific business function (utilizing SAP Solution Map) and define two Business Services.

1-1 Steps for the Exercise

1-1-1 Continue with the industry solution map you chose in the previous exercise (Vision phase) and select a specific business function

1-1-2 For this business function define at least three business goals

1-1-3 For each of the goals identified in the previous step, define at least two objectives (note – each objective must clearly contain a measure and a timeline)

1-1-4 Decompose the business function in to multi levels (utilizing Solution Map as a reference)

1-1-5 Once the functions are decomposed, identify two business services. For each of the business service defined, assign an appropriate owner of the service within the enterprise.

1-1-6 Present your results to the group

1-1-7 Use ES Workplace to identify candidate Enterprise Service to automate that capability - https://www.sdn.sap.com/irj/sdn/esworkplace


https://www.sdn.sap.com/irj/sdn/esworkplace


Exercises

Unit: Phase B: Business Architecture

Topic: Service Contracts


Understand how to define a Service Contract

While analyzing the business architecture it is imperative to perform a functional and process decomposition to define business services at appropriate levels of granularity, draw the service boundaries and define service contracts.

In this exercise, you will utilize SAP EAF prescribed techniques and templates to define a service contract for a specific Business Service.

2 What you need to do now

Identify a Business Capability from a Solution Map in Solution Composer

http://www.sap.com/solutions/businessmaps/index.epx

Figure 1 – Example Business Map in Solution Composer

Continue with the High-Tech industry exercise from the previous exercise, select a

specific business function

Define a couple of Goals and Objectives for that function


Identify a business service, which will fulfill the following criteria

The service can be governed

You can clearly define its interfaces

Can be tied to an organization unit

Can assign a clear owner of the service within the enterprise

Use ES Workplace to identify candidate technical services to automate that capability


Figure 2 – Example Enterprise Services shown in ES Workplace




Develop a service contract for this service and define its attributes (Please use the example format shown below)

ATTRIBUTE

TYPE ATTRIBUTE DESCRIPTION

General Reference BEEST-SVC-2001

General Name Catalog Authoring Service

General Description This service creates the BEEST global catalog that contains BEEST’s portfolio of

product offerings that will be utilized by various consumers (internal & external). The

catalog will eventually be published in different format namely website, EDI and print.

Since BEEST has operations around the globe, the global catalog is then localized to

generate country catalog and published in key language(s) within each country to fulfil

the needs of customers/dealers worldwide.

General Source The sources of this artefact include “Global Catalog Manager” with Sales & Marketing

organization and the sales package/Product release documents from product lifecycle

management (PLM) team within BEEST

General Owner The owner of the artefact is the delegated representative of Anna Ads, Head of Sales &

Marketing.

General Type The service creates catalog content and as “Content” is a classification of enterprise

data, the service can hence be defined as a “data related service”.

General Version Version 2007-03 (representing year and the week of the year the contract is

developed).

Business RACI Responsible - Anna Ads, Head of Sales & Marketing

Accountable - Direct report of Anna Ads

Consulted - Sales & Marketing regional heads.

Informed - Sales & Marketing regional managers

Business Service name

‘caller’

4 instances of BEEST Website (supporting multiple regions) – Subscriber of this

service

Catalog subscription service embedded within website of 12 Premium Importers

Catalog subscription service by 8 Platinum level, 10 Gold level and 20 Silver level

BEEST dealers

Business Service name

‘called’

“Catalog authoring” Service

Business Functional

Requirements

Catalog authoring service includes the following functions

Develop sales catalog

Add/Introduce new product line to the catalog

Manage product lifecycle

Develop catalog structure

Pricing (various country currency)


ATTRIBUTE


Merchandizing

Develop sales kits and bundles

Define display pages

Import images and CAD diagrams

Load electronic catalog data

Export/Publish catalog

Business Importance to

the process

Catalog authoring is a service that supports several core processes of BEEST. If this

service is unavailable the catalog content will be stale until the service is resumed.

SLA should address the time window within which the service should resume if

interrupted.

Business Quality of

information

required

The catalog should be accurate with no errors in grammar, product content description,

effectivity dates (for ex. Sales start & end dates, Marketing begin and end dates) and

appropriate prices with their valid from and valid to dates.

Business Contract control

requirements

Catalog authoring is stateful and the various “states” of the catalog content is

tracked within the application that supports authoring functionality. The four states

are namely Draft, Ready for Review, Approved, Final/Release)

Global catalog is not released until the content reaches “Final/Release” state

Creation and update of the catalog with product data within a certain time window

after product master data is released by PLM team

Catalog not published to the website and to the dealers until approved by the

designated catalog manager within each region

Business Result control

requirements

Validation of pre-defined business rules for products

Validation of Price of each product, sales kit or sales bundle

Monitoring of successful publication

Number of pages translated in to additional languages

Monitoring and logging of catalog publication time window (Start & end

timestamps)

Business Quality of

Service

Catalog authoring should be continuous with no interruption in the service.

Sufficient coverage of catalog authors should be made available throughout the

year.

Availability of skeleton crew of authors available every working day of the year

except for official national holidays.

Business Service Level

Agreement

Catalog authoring service should create content such that the catalog is available

on website by no later than 0800 local time (for each country)

The following predefined frequency and time cut off should be adhered to while

making the catalog available

Global catalog – Bi-monthly

Country catalog with local currency – Weekly

Product content to the configurator - Daily

Configurator rules (engineering, mechanical and price) – Weekly


ATTRIBUTE


EDI & XML versions of the catalog - Weekly

Product catalog in print - Monthly

Non-Functional

Requirements

Throughput 40 GB catalog content to the website

100,000 hard copy printed material to the dealers & sales partners

Non-Functional

Requirements

Throughput

period

Pre-defined frequency

For website publication the content creation should be completed within the

allocated time window

For Gold and Silver level dealers, print publication is mailed on demand within 72

hours of the request

Non-Functional

Requirements

Growth Total number of dealer and sales partners growth

o 50 by YE 2007

o 75 by YE 2008

o 100 by YE 2009 (following launch of Bullet GT)

Web traffic growth

o 20% of users year to year

o 20% in data volume year to year

Non-Functional

Requirements

Growth period See above

Non-Functional

Requirements

Service times Electronic publishing only during week days

Print publishing only during week days

Non-Functional

Requirements

Peak profile

short term

All electronic publication happens during non-office hours

All print publication peak happens during promotional campaigns (frequency

determined on demand)

Non-Functional

Requirements

Peak profile long

term

Non-Functional

Requirements

Security

requirements

BEEST Website has a subscription based on pre-set timer

Premium importers and Platinum level dealers have a dedicated toll free number

and a website to contact BEEST marketing team

Gold and Silver dealers have a dedicated website

Non-Functional

Requirements

Response

requirements

Content creation should begin within 24 hours from the time product master is

released

Content creation should be complete and made “Final/Release” the Tuesday

before product marketing launch (marketing launch always done on Monday)

Technical Invocation Invoked by the release of product data with “final” status


ATTRIBUTE


Technical Invocation

Preconditions

Importers and dealers should have gone through registration and activation

process with BEEST

Customer master records exist and contracts with dealers/importers in place

Appropriate translation of all the content in the native country language

Technical Business

Objects

Product master data (all components & accessories)

Catalog content (marketing content, technical specifications, support information

and images)

Configuration rules

Product list price range (USD and local currency)

Customer master data (includes customer, dealer, importer and sales partners)

Technical Behaviour

Characteristics

This service invokes the following child services

o Content translation service (external service provider)

o Spot currency exchange rates (to determine local currency)

o Catalog activation and publication service

Be aware of the following criteria for Service Granularity

Granularity defines the amount of functionality a Service should encapsulate (Coarse grained Service encapsulates huge chunks of functionality and exchanges vast amounts of data, while fine grained Service encapsulates small units of functionality and exchanges small amounts of data. For e.g. “Cancel PO” and “Look up a postal code” Services.

Boundaries & Scope

Ownership

Governance

How well it supports the defined Goals & Objectives?

Level of definition detail of enterprise goals/objectives/KPIs/SLAs, level of definition detail of the SLAs of the service and how well both can be mapped?

Is the service consumed within the enterprise and/or by partners/customers?

Is the service performed in-house or outsourced?

How well the services defined at a conceptual level can be mapped to implementable services defined by the package (e.g. Enterprise services from SAP)?


Degree and extent of re-use which indicates whether the service is going to be used by multiple processes across the enterprise or only by one process (ideally the service should be reused in multiple processes)

Is the service for single use or multiple use (ideally the service should be multiple use)?

Independence - In theory, services should be defined in such a way that they can be defined, designed and deployed independent of each other. As packages/packaged services offer a tight integration of process, data and application functionality, the independence of the services cannot be assumed and is a key consideration to define service granularity.

Be prepared to present your example to the group in 30 mins

2-1 Identify what value the Service provides to prospective consumers

2-2 Describe the functionality of the Service

2-3 Delineate quality of service and applicability constraints

2-4 Define the constraints on the types of consumers or other consumption requirements

2-5 Identify conditions for particular outcomes and behaviours

2-6 Determine the flow of processes and activities and steps leading to outcomes

2-7 Document the information defined as Service Contracts


Solutions

Unit: SAP EAF Phase B: Business Architecture

Topic: Service Contracts

1-1 Example Answer - Business Function: Product Development

Goals & Objectives:

Improve service delivery;

Reduce time-to-market;

Develop new markets

Improving Regulatory Compliance

Improve auditability of information and actions

Improving Service Delivery

Collaborate with business partners

Increasing Revenue

Develop new markets

Reduce time-to-market & volume

Reducing Operating Costs & Increasing Efficiency

Accelerate development cycle

Reduce administration, improve business processes

Business Functions Improve service delivery

Reduce time-to-market

Develop new markets

Comments

Strategic Portfolio management

x x

Project Planning

And execution X x

Development Collaboration

X x x

Process Engineering X x

Quality Engineering x x x

Engineering functions comply with Six Sigma/ISO 9003

Standardized interfaces exist for engineering functions

Can be tied to Org Unit: (QA/QC Unit) in Eng Division

VP of Eng is one of stakeholders



SERVICE CONTRACT

GENERAL

Name: Quality Engineering

Description: Quality engineering means incorporating quality throughout the entire product development process. This starts with defining deliverables and quality gates within a project, includes inspection planning as well as efficient supplier management and maintenance of quality related documents. In some industries, stability studies are also part of this process.

Source: QA Team

Owner: VP, Engineering

Type: Quality related service

Version: 1.0

BUSINESS

RACI

Responsible - VP Eng.

Accountable – Director QA

Consulted – Production/Development/Customers

Informed – Sales & Marketing

Service Name ‘caller’: 10 Production Lines, Field Services

Service Name ‘called’: Quality Engineering Service


SERVICE ACTORS - RESPONSIBILITY

BEEST External Actors

BEEST Importers, Dealers & Customers (Person) – Consumer of this Service

BEEST Online website (per country in local language) (application) – Mechanism that will be used by BEEST customers/dealers to consume the catalog information while shopping on BEEST website

BEEST Print Publishers (Org unit) – Hard copy publication of BEEST product catalog meant for dealers and sales partners

BEEST Importers (Person & Org unit) – Importers within each country or geography

BEEST Internal Actors

BEEST Sales & Marketing regional representatives (Person) – They edit the catalog with appropriate marketing collateral

BEEST Online configurator (application) – Application that relies on product content of the catalog

Catalog content Quality Assurance team (Org unit) – Ensure that the catalog look and feel complies with corporate standards

Catalog content approver (Person) – Formally approves the content before publishing to the web

BIC (Org Unit) – IT Infrastructure services for hosting BEEST online website and all applications

FUNCTIONAL REQUIREMENTS

Intuitive UI which will support dialog interactions for the content authors

Ability to import product master data from SAP R/3 on demand

Facility to augment the base catalog with marketing collateral

Drag & drop features to insert images, CAD diagrams into catalog content

TECHNICAL REQUIREMENTS

6 second response time while navigating from one screen to another

24x7 availability as the authoring is done by users around the globe


MAP TO ES WORKPLACE

Quality Engineering

Quality engineering means incorporating quality throughout the entire product development process. This starts with defining deliverables and quality gates within a project, includes inspection planning as well as efficient supplier management and maintenance of quality related documents. In some industries, stability studies are also part of this process.

SAP ERP Corporate Services – Quality Management solution - best fit

1-2 Example Answer - Revision and Update Communication Service

GOALS & OBJECTIVES

Improving Regulatory Compliance

Improve auditability of Information and actions

Increasing Revenue

Reduce time-to-market & volume

Develop new markets

Improving Service Delivery

Collaborate with business partners

Reducing Operating Costs & Increasing efficiency

Reduce administration, improve business processes

Accelerate development cycle

SPECIFIC GOAL

Extend Design Superiority

Reduce Time to Market (R&D - Production)

SPECIFIC OBJECTIVES

Enhance Collaboration & Accountability

Promote Reusability

Leverage Current Capability

SERVICE CONTRACT


Time to MarketTime to Market

Product Development

Product Launch & Life Cycle Management

Project Planning & Execution Services

Development Collaboration Services

Prototyping & Ramp Up Services

Service ContractService Contract(Revision and Update Communication)

Service Requirement

R & D Manufacturing

BUSINESS SERVICES ELABORATION

Can it be governed – YES

KPI measurement of Time to Market

Clearly define Interfaces – YES

Clear definition of INPUTS and OUTPUST of both service provider

Tied to Organizational Unit – YES

R & D and Manufacturing

Tied to a Owner – YES/MAYBE

Director of Product Design & Director of Manufacturing


Solutions

Unit: Business Architecture

Topic: Business Service Definition

2-1 First Level of Functional Decomposition

BEEST Financial

Services (BFS)

BEEST Engineering

Services (BEG)

BEEST Consulting Services

Car Top Systems

(CTS)

BEEST Info & Communicatio

n Systems (BIC)

Finance HR

BEEST Design Group

BEEST

Sales &

Marketing Manufacturing Supplier

Collaboration and

Operational Procurement

R&D

2-2 Second Level of Functional Decomposition

Vehicle Life Cycle

Brand & Customer

Management

Marketing Campaigns

Roof systems (CTS)

IT Infrastructure Services (BIC)

After Sales Pre-Owned Car Sales

New Car Sales

Design services &

Luxury brand Men’s

accessories (BDG)

Sales & Marketing

Process optimization

& design services (FASST

Consulting)

SAP related services for automotive

industry (MBP)

Leasing, Financing &

Car insurance Services (BFS)

Concept development

through vehicle

integration services (BEG)

2-3 Next levels of Functional Decomposition


Order Capture &

Management

Payment Processing

Indirect Sales Pre-sales Activities

Direct Sales

After Sales

New Car Sales

Vehicle Administration

Vehicle Searching & Locating

Indirect Sales

Vehicle Order Tracking

Vehicle Configuration &

Pricing

Vehicle Configuration & Pricing

Access Management

Catalog Management

Guided Selling

Dynamic Pricing

Order & Quote Management

Contract Management

Configuration Management

Business Service Candidate


SAP AG 2009

Unit 5 – Phase C:

Information Systems Architecture - Applications


©SAP AG SOA200 9-1

SAP AG 2009

TOGAF™ Phase C: Information Systems Architecture - Apps

Contents:

Introduction to IS Architecture Phase - Applications

SAP EAF Extensions



©SAP AG SOA200 9-2

SAP AG 2009







©SAP AG SOA200 9-3

SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand howto:

develop an AS-IS and a TO-BE Application Architecture including:

Catalogs

Matrices

Diagrams

develop Gap Analyses

record Business and Technical Requirements

create an Application Architecture Roadmap

©SAP AG SOA200 9-4

SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools







©SAP AG SOA200 9-5

SAP AG 2009

Detailed Document ViewOverall Description of SAP EAF


Usage Guidelines









Case Study Material










(App & Data)


























Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base

SAP - Specific Mappings















Guidelines



Guidelines


709: SAP Glossary

The key references in the Information Systems - Application Phase are :

NL-A-P400 – Phase Worksheet

NL-A-P402 – Phase Narrative

©SAP AG SOA200 9-6

SAP AG 2009



SAP EAF Extensions



©SAP AG SOA200 9-7

SAP AG 2009

Information Systems Architecture Phase - Overview

The Information Systems Architecture phase is about defining As-Is and To-Be application and data architectures for the organization, detailing the roadmap towards the To-Be architecture and identifying key work packages in the roadmap.


The Information Systems Architecture Phase is about defining both the application and data architecture.

The scope of the business processes supported in this phase is limited to those that are now or need to be supported by Information Technology

The objective here is to define the major kinds of application system necessary to process the data and support the business architecture defined in Phase B.

©SAP AG SOA200 9-8

SAP AG 2009

Why do Application Architecture first?

IS Architectures involve a combination of Data and Applications Architecture, in either order. TOGAF™has no preferences for one or the other way.

SAP EAF recommends Application Architecture is performed first :

Packages or packaged services provide a combination of technology infrastructure and business application logic

Some organizations take an application-driven approach, where key applications form the core of mission-critical business processes,

SAP EAF assumes some functionality will be delivered through a packaged or packaged service solution

The Application Architecture phase must examine commercially available solution models in addition to traditional requirements and current state analysis.

Commercially available templates may need to be adopted at the expense of the business ideal.

In general, TOGAF™ recommends that architecture definition is an iterative activity and that not all answers can be completed in a single cycle.

DataArchitecture

ApplicationArchitecture

©SAP AG SOA200 9-9

SAP AG 2009

IS Architectures - Applications Phase - Main Objectives

TOGAF™ is not very clear about objectives of this phase

SAP EAF states the following main objectives:

Map Business Services and/or Business Functions defined in the Business Architecture phase into a set of Application Components, which form a logical representation of deployable systems.

Define what kinds of application systems are relevant for the engagement, and what those applications need to do in order to manage data and to present information to the human and computer actors in the enterprise.

Define applications and their capabilities without reference to particular technologies. The applications are stable and relatively unchanging over time, whereas the technology used to implement them will change over time based on the technologies available from vendors and changing business needs.


SAP AG 2009

IS Architectures - Applications Phase - Approach

TOGAF™ makes some general comments about the approach:

Review relevant Application Architecture Resources in the repository

Review generally available ressources, e.g. OpenGroup Reference Models, OMG‘s domain specific software models, ebXML etc.

SAP EAF‘s approach is as follows:

Architecture definition is an iterative activity and not all answers can be completed in a single cycle. The exact engagement schedule and determination of iteration cycles is defined during the Architecture Vision phase.

Application Architecture should execute at least two iterations, with one cycle focusing on As-Is and the other on To-Be. Gap analysis takes place during the second iteration.

Application Architecture will include at least one iteration of Data Architecture

There will be several sub-iterations within the Data and Application domains required to complete a single iteration of the overall TOGAF™ cycle.


SAP AG 2009

TOGAF™ IS Architectures Phase Inputs and Outputs (for App and Data)

IS Architecture -Applications

Phase




Application Principles, if existing






Information systems components of an Architecture Roadmap

Communications Plan

Architecture Vision

Data Principles, if existing

Statement of Architecture Work





SAP EAF tackles Applications Architecture first

The aim is to define what application systems are relevant to the enterprise for it to achieve its goals and objectives, and what those applications need to do in order to manage data and to present information to the human and computer actors in the enterprise.

The applications should be described as logical groups of capabilities that manage the data objects in the data architecture and support the business functions in the Business Architecture.

The applications and their capabilities are defined without reference to particular technologies. For example, “customer contact application” or “financial ledger application” as opposed to SAP CRM.


SAP AG 2009

TOGAF™ IS Architecture - Applications Phase -Overview of steps

Finalize the Application Architecture






Develop Baseline Application Architecture Description

Develop Target Application Architecture Description


TOGAF™


This diagram shows the SAP EAF process for creating Application Architecture and the SAP EAF Extensions.

SOURCE OF INFORMATION


Application Support Experts

Existing Applications Inventory or Catalog

Existing Application Architecture Models

Applications Management Support Documentation

Automated Enterprise Management Systems

QUESTION : How can we find out :

What applications link to what other applications via interfaces ?

What systems are used by what organization units ?

What roles use what systems ?

What functions use what systems ?


SAP AG 2009



Select Buildings Blocks

Definition of applications allows a mapping to be created between the applications required and the building blocks that represent or provide the capabilities for that application.

In a package and packaged services environment, it is likely that additional vendor specific tools may provide the information required to identify these building blocks (e.g. SAP’s Solution Composer, or Enterprise Service Repository).

Select catalogs, matrices, and diagrams

Identify Types of Requirement

Functional and non-functional requirements

Assumptions

Constraints

Domain-specific Application Architecture principles

Policies, Standards

Guidelines

Specifications



SAP AG 2009



It should be produced by collecting existing information and, as far as practical, re-engineering this information into the TOGAF™ metamodel so that it can be leveraged as the basis of a future state architecture.

Scope and level of detail will depend on the extent to which existing business elements are likely to be carried into the target application architecture


Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture.

The scope and level of detail to be defined will depend on the relevance of the applications elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist.



SAP AG 2009


Perform Gap Analysis Test the architecture for completeness and consistency

Create gap matrix

Identify building blocks to be carried over, classifying as either changed or unchanged

Identify eliminated / new building blocks

Identify gaps and classify as those that should be developed and those that should be procured

Gap matrixexample



SAP AG 2009



An high-level application roadmap is required to prioritize activities over the coming phases

This roadmap will support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase


Does this Application Architecture create an impact on any pre-existing architectures?

Have recent changes been made that impact the Application Architecture?

Are there any opportunities to leverage work from this Application Architecture in other areas of the organization?

Does this Application Architecture impact other projects (including those planned as well as those currently in progress)?

Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)?



SAP AG 2009



An high-level application roadmap is required to prioritize activities over the coming phases



Does this Application Architecture create an impact on any pre-existing architectures?

Have recent changes been made that impact the Application Architecture?

Are there any opportunities to leverage work from this Application Architecture in other areas of the organization?

Does this Application Architecture impact other projects (including those planned as well as those currently in progress)?

Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)?



SAP AG 2009


Conduct Formal Stakeholder Review (not done in SAP EAF) Conduct an impact analysis, to identify any areas where the Business and Data

Architectures (e.g., business practices) may need to change to cater for changes in the Application Architecture

If needed revisit Business and / or Data Architecture

Identify any constraints on the Technology Architecture

Finalize the Application Architecture Select standards for each of the building blocks, re-using as much as possible from the

reference models


Conduct final cross-check of overall architecture against business requirements



Document final mapping of the architecture within the Architecture Repository;

Finalize all the work products, such as gap analysis

Create Architecture Definition Document (TOGAF™ gives an outline of this document) Document rationale for building block decisions

Complete Application Architecture sections in document



SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions




SAP AG 2009


Information

Systems

Application

Architecture

Phase


BEEST Case Study

SAP EAF Templates

SAP EAF Application Architecture Narrative


SAP EAF Data Architecture Narrative

TOGAF™ ADM IS Applications Narrative

SAP EAF IS Architecture Worksheet


SAP EAF Glossary


Additional Inputs

Additional outputs

Additional step(s)

Current State Data Architecture (draft)

Target Data Architecture (draft)

Perform iteration of Data Architecture

Determine Data Entities Encapsulation



SAP AG 2009

IS Architectures - Applications Phase - TOGAF™ and EAF

SAP EAF Extensions

Perform Iteration of Data Architecture

Determine Data Encapsulation


Finalize the Application Architecture









TOGAF™















SAP AG 2009

IS Architecture Phase – Applications - SAP EAF Extensions

Perform iteration of Data Architecture

Before proceeding to assess the integration requirements, application dependencies and deployment considerations, it would typically be necessary to conduct a more formal assessment of the data impacts associated with the to-be landscape.

At this stage it is recommended to perform an iteration of Data Architecture.

Determine Data Entities Encapsulation

Once the Data requirements for to-be applications have been assessed, it is necessary to make choices on how and where data will be encapsulated across the application landscape.

Each time an application requires access to a Data Entity, a choice must be made to determine if the application should access data locally or remotely, thereby generating requirements for application integration.


Implications on the overall service SLA either due to custom interfaces between packages & non-packages or new data flows

Interaction between service enabled and non-service enabled application components

Performance implications (e.g. availability) of application components


SAP AG 2009



SAP EAF Extensions




SAP AG 2009



SAP AG 2009




Data Entity

gical Information Component

Data Extension


Physical ApplicationComponent

InfrastructureConsolidation Extension

LogicalCom

InfrastructuExt

PhysicalCom


Encapsulates

Resides within


Operateson

Is processedby

umes Is implemented on


Is realisedthrough

,

Start by identifying the Information System Services

Business services specifically provided by an automated IT-based solution

E.g. Purchase Request Processing

It is important to define what we mean by Logical and Physical Applications :

Logical Application Component is an encapsulation of application functionality that is independent of a particular implementation.

E.g. Organization X Purchase Request Processing Enterprise Service

An application, application module, application service or other deployable component of functionality.

E.g. A configured and deployed instance of the SAP Purchase Request Processing Enterprise Service


SAP AG 2009

Approach to creating Architecture

Diagram

Catalog

Matrix

Add. EAF artefact

Business .

Application .

Data .

Technology.


Application– Data








Role Actor/ Role




Role / System

Data Entity/ DataComponents

Location


System / Data

Process Flow

Use Case


Organisation Chart

Events



Data Lifecycle

Data Security

Data- System


Hardware

Communications

Standards



System / Function

System / Technology

System / Location




Business Footprint


Goal /Objective/Service




Data Migration

Data Hierarchy

Processing

Cost

Interface Catalog

System Use Case

Product Lifecycle

This diagram shows the approach to creating an Application Architecture – starting with base structure, then the context, then the operation of the applications.

This approach provides a logical approach – ensuring that the base application portfolio is in place before moving onto more extensive matrices.


SAP AG 2009

Catalogs, Matrices, and Views


SAP EAF Extensions




SAP AG 2009


Most concepts are formally modeled apart from:

Standards, Guidelines, and Specifications

Catalogs


Interface Catalog

Core Diagrams

Application to Application Communication Diagram


System Use Case Diagram

Extension Diagrams







Matrices





For each catalog, matrix or diagram:

Populate each one based on the existing information gathered

Validate each one against each other to identify gaps

For example, do all Systems have more than one role accessing them ? Are all Systems providing a Function ?

Validate with Application Management staff

Are all systems being supported ?

Are their systems being supported but not used by the business ?

Validate with Business Process Expert staff

Are all systems present and are they providing the right service ?

Validate with Senior Executives

Confirm current AS-IS and proposed TO-BE explaining which applications will provide which services and why


SAP AG 2009

IS Architecture Phase - Applications - Catalogs


Purpose


The purpose of this catalog is to identify and maintain a list of all the applications in theenterprise. This list helps to define the horizontal scope of change initiatives that may impactparticular kinds of applications.

Existing application registries and repositories, such as SAP’s Solution Manager and SystemLandscape Directory products also provide input into this catalog from an As-Is and To-Beperspective

The Application Portfolio Catalog contains the following metamodel entities :

Information System Service Logical Application Component Physical Application Component

Interface Catalog The purpose of this catalog is to scope and document the interfaces between applications toenable the overall dependencies between applications to be scoped as early as possible.

The Interface Catalog contains the following metamodel entities :

Logical Application ComponentPhysical Application ComponentApplication communicates with Application relationship

QUESTION : How would we ensure we captured all interfaces ? What would we use to verify this ?


SAP AG 2009

Example Catalogs 2/3



SAP AG 2009


Interface Catalog


SAP AG 2009

IS Architecture Phase – Applications - Matrices 1/2


Purpose


Business functions are performed by organizational units. Some of the functions andservices performed by those organizational units will be supported by IT systems

The relationship between these two entities is a composite of a number of metamodelrelationships that need validating : Organization Units own Services Actors that belong to Organization Units use Services Services are realized by Logical/Physical Application Components


People in an organization interact with systems. During this interaction, these peopleassume a specific role to perform a task; for example, product buyer.

The relationship between these two entities is a composite of a number of metamodelrelationships that need validating : Role accesses Function Function is bounded by Service Services are realized by Logical/Physical Application Components


Business functions are performed by organizational units. Some of the business functions and services will be supported by IT systems

The relationship between these two entities is a composite of a number of metamodelrelationships that need validating : Function is bounded by Service Services are realized by Logical/Physical Application Components


SAP AG 2009

IS Architectures Phase - Applications - Matrices 2/2


Purpose


The purpose of the Application Interaction matrix is to depict communications relationships between systems (i.e., application components).The mapping of the application interactions shows in matrix form the equivalent of the Interface Catalog or an Application Communication diagram.The Application Interaction matrix is a two-dimensional table with Application Service, Logical Application Component, and Physical Application Component on both the rows and the columns of the table.The relationships depicted by this matrix include: Application Service consumes Application Service Logical Application Component communicates with Logical Application Component Physical Application Component communicates with Physical Application Component


SAP AG 2009

Example Matrices 1/2

APPLICATION (Y-AXIS) AND

ORGANISATION UNIT (X-AXIS)

CUSTOMER SERVICES

PROCUREMENT AND

WAREHOUSINGHR

CORPORATE

FINANCE

SAP HR X X X

SIEBEL X X

SAP FINANCIALS

X X X

PROCURESOFT X X

APPLICATION (Y-AXIS) AND

FUNCTION (X-AXIS)

CALL CENTRE 1ST

LINEWAREHOUSE

CONTROLVACANCY FILLING

GENERAL LEDGER MAINTENANCE

SAP HR X X X X

SIEBEL X X

SAP FINANCIALS

X X X

PROCURESOFT X X

System – Role Matrix System – Organization Matrix

System – Function Matrix

APPLICATION (Y-AXIS) AND FUNCTION

(X-AXIS)

CALL CENTRE

OPERATOR

CALL CENTRE

MANAGER

FINANCE ANALYST

CHIEFACCOUNTANT

SAP HR X X X X

SIEBEL X X

SAP FINANCIALS

X X X X

PROCURESOFT X X

Here are example matrices populated with example content

The intersections of the matrices can be enhanced

Instead of X which indicates a positive relationship between the row and column

We can add attributes ; for example, CRUD for Create, Read, Update, Delete


SAP AG 2009

Example Matrices 2/2


Application Service /

Application ServiceService 1 Service 2 Service 3 Service 4

Service 1 X X X X

Service 2 X X

Service 3 X X X X

Service 4 X X


SAP AG 2009

Core Diagrams


Purpose


The purpose of this Diagram is to depict all models and mappings related to “communication’between Applications in the meta model entity.

It shows application components and interfaces between components.

Interfaces may be associated with Data Entities where appropriate. Applications may be associated with business services where appropriate. Communication should be logical and should only show intermediary technology where it is architecturally relevant.


This Diagram shows the geographical distribution of applications.

It can be used to show where applications are used by the end user; the distribution of where the host application is executed and/or delivered in thin client scenarios; the distribution of where applications are developed, tested and released; etc.


A System Use-Case diagram displays the relationships between consumers and providers of application services. Application services are consumed by actors or other application services and the Application Use-Case diagram provides added richness in describing application functionality by illustrating how and when that functionality is used.The purpose of the System Use-Case diagram is to help to describe and validate the interaction between actors and their roles with applications. As the architecture progresses, the use-case can evolve from functional information to include technical realization detail.Architectural system use-cases can also be re-used in more detailed systems design work.

The style of the views produced will to some extent depend on the EA Tools used and the symbols offered by them

These are simple examples produced in MS Visio


SAP AG 2009

Example Core Diagrams 2/4


The style of the Diagrams produced will to some extent depend on the EA Tools used and the symbols offered by them



SAP AG 2009



This Diagram highlights location constraints and issues. Thediagram shows applications and locations. It may also show

actors. It may also show interactions between actors and applications. It may also show interactions between applications. It may also show services encapsulated within the applications.

Los Angeles

An actor

Chicago

An actor

New York

An actor

USA

New Jersey

Germany

An actor

Application 3

UK

An actor

Application 2

Japan

An actor

Application 5

Application 4

Application 1




SAP AG 2009



Source: www.processwave.net




SAP AG 2009

Extension Diagrams


Purpose


The purpose of this Diagram is to clearly depict the sequence of events when multiple applications are involved in executing a business process. It enhances the Application to Application Communication Diagram by augmenting it with any sequencing constraints, and handoff points between batch and real-time processing.


This Diagram shows how one or more applications interact with application and technology components that support operational management of a solution. This Diagram is really a filter on the application-application communication Diagram, specifically for Enterprise Management class software.


This Diagram identifies application migration from AS-IS to TO-BE application components. It enables a more accurate estimation of migration costs by showing precisely which applications and interfaces need to be mapped between migration stages.


This Diagram breaks applications into packages, modules, services and operations from a development perspective. It enables more detailed impact analysis when planning migration stages, and analyzing opportunities and solutions.


This shows how application software is structured and distributed across the estate. It is useful in systems upgrade or application consolidation projects.This Diagram shows how physical applications are distributed across physical technology and the location of that technology.


SAP AG 2009

Example Extension Diagrams 1/3


Systems Management

ToolingApplication

Problem Management

Logging and Reporting Error Alerting

Backup and Restore Tooling

This Diagram show how one or more applications interact withapplication and technology components that support operational management of a solution. This Diagram is really a filter on theapplication-application communication Diagram. This diagram

may also show support personnel access to administrative functions of the system. This diagram may also addressenvironment migration configuration managment, etc.

UML sequence (most detail) and activity diagrams (less detail) canbe used, or a less formal swimlaned flowchart (least detail). BPMN is also an option. The decision on diagram form will depend on thelevel of detail and formality. Generally, the non-formal Diagram isbest suited of stakeholders, but specific areas of architecture risk

need to be addressed in more detail. The diagram can showorganisations, actors, application components, data entities and

architecturally significant technology compenents.

Bu

sin

ess

Un

it S

erv

ice

Ow

ne

rE

nte

rpri

se In

fra

stru

ctur

eA

rchi

tect

Identify Technology Strategy impacts on

Architecture

ReDiagram ArchitecturePattems and Refresh

Architecture Principies

Refresh ConceptualTechnology

Infrastructure Service Catalogue

Refresh Logical Technology Infrastructure Component

Catalogue

Refresh Technology Standards

Identity Business Strategy Impacts on

Architecture

Technical Architecture Process – Architecture Refresh

Ent

erp

rise

A

pp

licat

ion

Arc

hite

ct

Ent

erp

rice

De

sig

n

Au

tho

rity Re-taseine target

Architecture

Refresh ConceptualInformation Systems Service Catalogue

Refresh ConceptualInformation Systems Service Catalogue

Process- System Realization Diagram




SAP AG 2009


Breaks applications into packages, modules, services and operations from a development

perspective. May show dependenciesbetween functional components


Vehicle Service Data

VehicleProfile Service

VehicleService

Data System

App App

CustomerService

CustomerSystem

App

Organization

Help

User

ApplicationSecurity Matrix

Customer

CustomerProfile Ul

TO-BE CRM Application


AS-IS Billing Application

Customer

Account

AS-IS Sales Application

Customer

Order History

Complaint

Sales Calls

Temp Staging Application

Customer

Account

Complaint

Customer

Account

Complaint

Sales Call

Sales Calls

Customer




SAP AG 2009



Diagram




SAP AG 2009

Summary

This is the end of the Information Systems Architecture Phase – Applications

You should now understand how to develop : A Target Application Architecture including:

- Catalogs Application Portfolio Catalog

Interface Catalog

- Matrices System / Organization Matrix



- Diagrams Application to Application

Communication Diagram


Service Definitions and Contracts

Gap Analysis results


Application Architecture Roadmap

Application Architecture Report

Updated Business Requirements

The next phase is Information Systems Architecture -Data



SAP AG 2009

Unit 6 –Phase C:

Information Systems Architecture - Data



SAP AG 2009

TOGAF™ Phase C: Information Systems Architecture -Data

Contents:

Introduction to IS Architecture Phase - Data

SAP EAF Extensions




SAP AG 2009








SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to: After completing this lesson, you will be able to understand how to: develop an AS-IS and a TO-BE Data Architecture

including:

Catalogs

Matrices

Diagrams



create a Data Architecture Roadmap


SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools








SAP AG 2009



Usage Guidelines









Case Study Material










(App & Data)


























Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base
















Guidelines



Guidelines


709: SAP Glossary

The key references in the Information Systems – Data Phase are :

NL-I-P502 – Phase Narrative


SAP AG 2009



SAP EAF Extensions




SAP AG 2009

Information Systems Architecture Phase - Overview

The Information Systems Architecture phase is about defining As-Is and To-Be application and data architectures for the organization, detailing the roadmap towards the To-Be architecture and identifying key work packages in the roadmap.


The objective here is to define the major types of data necessary to support the business architecture defined in Phase B.

The aim is to understand how data is produced and consumed by the business functions of the enterprise.

This provides insight not only into the flow of information across the enterprise, but also identifies the authoritative sources for different information types and the integrated views of information that will be required.

Typically, this is done at the “data entity” level (for example, "customer" or "product")

The analysis involves understanding what business processes produce a specific data entity and which business processes consume the data.


SAP AG 2009

IS Architectures - Data Architecture Phase - Main Objectives

To define the major types and sources of data necessary to support the business, in a way that is:

Understandable by stakeholders

Complete and consistent

Stable

This effort is not concerned with database design

The goal is to define the data entities relevant to the enterprise, not to design logical or physical storage systems



SAP AG 2009

IS Architectures - Data Architecture Phase -Approach

Understand and address data management issues:

A clear definition of which application components in the landscape will serve as the system of record or reference for enterprise master data

Will there be an enterprise-wide standard that all application components, including software packages, need to adopt?

Clearly understand how data entities are utilized by business functions, processes, and services

Clearly understand how and where enterprise data entities are created, stored, transported, and reported

What is the level and complexity of data transformations required to support the information exchange needs between applications?

What will be the requirement for software in supporting data integration with the enterprise's customers and suppliers

Consider also data migration and data governance scenarios



SAP AG 2009

Data Architecture Maturity Model

StandardsFew, silo’d standards

Some standards for shared system data

Standards for most common services data

Standards for all data essential to business success

Governance

Quality

Deployment

Limited data/process governance – within silos

Limited data/process governance for shared processes and systems

Data/process governance in place for essential common services

Governance for all data/processes essential to business success

Sporadic efforts - within silos

Systemic programs for common services data

Comprehensive program for business critical data

Data management efforts isolated and inconsistent

Cross functional and cross business data management

Data management deployed for shared services

Ongoing, constantly improving program

Data standards exist for cross functions May cross domains as per requirements Measured against reference values

Data standards exist for essential data used by shared services

Cross domain exist for shared services Measured against quality dimensions & tested

Data standards exist for data across enterprise Systematic process for enterprise data Validated across data domains and rigorously

tested

Attempts to define roles & responsibilities from data governance perspective

Governance automation is sporadic Data access controls limited except for

compliance data

Data roles and responsibilities standardized for shared services

Automation varies by data domain or service area

Security, authorizations, and enforcement uniform for shared services data

Data roles & responsibilities standardized for enterprise data

Processes and workflows uniformly implemented and automated in standard tools

Cross system data access controls in place and monitored

Initiative for compliance and major pain points Cost known for shared services

Data cleanup processes are proactive IT services support capable monitoring Standardized tools used across shared

services processes Acceptable data quality levels are defined,

monitored and shared across business

Cost known for impact on data quality on enterprise process performance

Data cleanup proactive and part of enterprise business process improvement project

Six sigma based methodologies utilized Standardized tools used across all enterprise

data processes Data quality levels are actively monitored at

Enterprise level

Focus is primarily at the Enterprise level and not on Operational level

Integration ad-hoc Limited knowledge of data management

best practices

Data management not integrated with business process management

Voluntary attempts to integrate data Limited data management best practices

included in project methodology

Data management deployed to support shared services

Data management integrated into project methodology for all shared services

Best practices consistently used

Data management deployed to support enterprise processes

Data management integrated into project methodology for IT and Business initiatives

Best practices fully integrated into IT and Business project management tools & methods

Level 1Level 2

Level 3Level 4

ArchitectureSystem “Silos” within each Business

Some systems shared across some Businesses

Standardized IT & Business

Process Architectures for common services

Business Strategy drives IT & Business Process Architecture

IT produces functional areas specific solutions at business direction

IT inventory not useful for managing IT Limited use of SOA and Web Services

IT attempts a common solution framework Initial efforts to create inventory within

specific functional areas Web services shared across businesses

IT & Business Enterprise Architecture roadmap Inventory for managing shared services SOA is implemented

IT viewed as a strategic enabler Inventory used for IT business management Enterprise SOA is implemented

Stages of Adoption

Unknown cost of poor data quality Data cleanup is reactive Few data metrics and sporadic reviews Non-standard quality measurement tool Basic quality measurement is basic

Data standards exist for some silos Data standards limited to one data domain Cannot be measured or tested

Data roles and responsibilities not rigorously defined

Out of the box governance automation Out of control data access

Attempt to determine cost to justify cleanup efforts

Data cleanup occurs only when data quality causes significant problems

Conflicting data metrics and not monitored Attempts to standardize data quality tools Definition of acceptable data levels is non-

existent


SAP AG 2009

ASUG Enterprise Data Management Survey

Maturity of Best Practices Adoption Is Important

It is clear that greater maturity of adoption of Enterprise Data Management Best Practices has a tangible impact on the performance of SAP customers.

A measured, comprehensive approach works best. ASUG surveys confirm that companies that created a data management program that addressed all 5 dimensions had better results than those that emphasized only one or two dimensions


SAP AG 2007

In organizations, most data is related to each other

Partial example

Operational assets

Properties

Networkconnections

Customer billing

address

Customer accountrecords

Customer group

Customer segmentation

Maintenance records

Asset performance

Meter records

Relationship Key

One to oneOne to many Many to many

For each service pipe or sewage/effluent outlet

For m

ete

redprop

erties

This is the data architecture


SAP AG 2009

Be aware of different data types

External Organisations

Addresses, Areas

Consents

Environmental data

External regulation

Demand forecast

Products & Services

Customers

Projects

Operational Assets

Network model

Quality plan

Non-operational assets

Suppliers

Purchased Products & Services

Stores

People

Organisation Structure

Market Surveys

Customer Transactions

Events

Jobs & Schedules

Volume measures

Quality samples

Supply transactions

Stock

People transactions

External Data AggregatedMaster Data Transaction Data Management Data

= Many connections

Business Plans

Policies & Procedures

Asset Management Plan

Financial Data

Non-financial Performance Data

Statutory reporting

Asset transactions


SAP AG 2009

TOGAF™ IS Architectures Phase - Inputs and Outputs (for App and Data - recap)

IS Architecture -Applications

Phase




Application Principles, if existing






Information systems components of an Architecture Roadmap

Communications Plan

Architecture Vision

Data Principles, if existing







SAP AG 2009

TOGAF™ IS Architectures - Data Phase - Overview of Steps

Finalize the Data Architecture






Develop Baseline DataArchitecture Description

Develop Target DataArchitecture Description


TOGAF™



SAP AG 2009



Select relevant Data Architecture viewpoints (for example, stakeholders of the data - regulatory bodies, users, generators, subjects, auditors, etc.; various time dimensions - real-time, reporting period, event-driven, etc.; locations; business processes)

Identify appropriate tools and techniques (including forms) to be used for data capture, modeling, and analysis (Entity-relationship diagram, Class diagrams, Object role modeling)

Many valuable reference architectures are available The Department of Defense Architecture Framework (DoDAF) Logical Data Model

ARTS Data Model for the Retail industry

Energistics Data Model for the Petrotechnical industry

SAP provides a collection of Solution Maps that define reference models for various industries and solution types, including inputs to create SAP EAF Information Components.



SAP AG 2009



In an SAP environment, the following standard Data Definitions may also be referred to : SAP Master Data Definitions and Global Data Types

SAP Transaction Data

SAP Standard Message Types (e.g. IDOCs)

Service Definitions

SAP Data Dictionary, Business Object Repository

Determine Overall Modeling Process, e.g. Collect data-related models from existing Business Architecture and Application

Architecture materials

Rationalize data requirements and align with any existing enterprise data catalogs and models; this allows the development of a data inventory and entity relationship

Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application

Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived



SAP AG 2009



Identify Required Catalogs, Matrices, and Diagrams, e.g.

Set up organization's data inventory

Link to Business Service/Information diagram created in Business Architecture

Data Entity/Business Function

Class diagram, Data Migration diagram, Class Hierarchy diagram

In an SAP environment, the following standard Data Definitions need to bereferred to : SAP Master Data Definitions

SAP Global Data Types (based on UN/CEFACT) (Ref. 2)

SAP Business Object Catalogue

SAP Standard Message Types

Service Definitions

BAPI Documentation

SAP Data Dictionary, Business Object Repository



SAP AG 2009



Identify Types of Requirement Functional and non-functional requirements

Assumptions

Constraints

Domain-specific Data Architecture principles

Policies, Standards

Guidelines

Specifications

Develop Baseline Data Architecture Description

It should be produced by collecting existing information and, as far as practical, re-engineering this information into the TOGAF™ metamodel so that it can be leveraged as the basis of a future state architecture.

Scope and level of detail will depend on the extent to which existing business elements are likely to be carried into the target application architecture



SAP AG 2009


Develop Target Data Architecture Description

Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture

The scope and level of detail to be defined will depend on the relevance of the applications elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist


Test the architecture for completeness and consistency

Create gap matrix (-> see Application Architecture)

Identify building blocks to be carried over, classifying as either changed or unchanged

Identify eliminated / new building blocks

Identify gaps and classify as those that should be developed and those that should be procured



SAP AG 2009



An high-level data roadmap is required to prioritize activities over the coming phases



Does this Data Architecture create an impact on any pre-existing architectures?

Have recent changes been made that impact the Data Architecture?

Are there any opportunities to leverage work from this Data Architecture in other areas of the organization?

Does this Data Architecture impact other projects (including those planned as well as those currently in progress)?

Will this Data Architecture be impacted by other projects (including those planned as well as those currently in progress)?



SAP AG 2009


Conduct Formal Stakeholder Review (not done in SAP EAF)

Conduct an impact analysis, to identify any areas where the Business and Application Architectures (e.g., business practices) may need to change to cater for changes in the Data Architecture

If needed revisit Business and / or Application Architecture

Identify any constraints on the Technology Architecture


Select standards for each of the building blocks, re-using as much as possible from the reference models


Conduct final cross-check of overall architecture against business requirements



Document final mapping of the architecture within the Architecture Repository;

Finalize all the work products, such as gap analysis

Create Architecture Definition Document (TOGAF™ gives an outline of this document)

Document rationale for building block decisions

Complete Data Architecture sections in document



SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions




SAP AG 2009


Information

Systems

Data Architecture

Phase


BEEST Case Study

SAP EAF Templates




TOGAF™ ADM IS Data Narrative

SAP EAF IS Architecture Worksheet


SAP EAF Glossary


Additional Inputs

Additional outputs

Additional step(s)

Current State Data Architecture

Target Data Architecture

Return to Application Architecture

Identify Data Impact on Governance



SAP AG 2009

IS Architectures - Applications Phase - TOGAF™ and EAF

SAP EAF Extensions










Develop Baseline DataArchitecture Description

Develop Target DataArchitecture Description


TOGAF™


SAP AG 2009

IS Architecture Phase - Data - SAP EAF Extensions


If this is the iteration of data architecture within the application architecture phase, return to application architecture


A key user community to be specifically considered is the Data Owner community. This activity should examine data dependencies on existing data quality, data security, data sharing, and data archiving processes, and how each is effectively operated and managed.

There may be existing specific Architecture Governance standards, such as standard XML/XSD schema, or data security and quality guidelines that need to be complied with.

The TO-BE Data Security Diagram and TO-BE Data Migration Diagram will be useful at this point.


Assessment of data qualities may result in impacts to Business Service contracts and require refinement of the Business Architecture


SAP AG 2009


Introduction to Technology Architecture Phase

SAP EAF Extensions




SAP AG 2009



SAP AG 2009


DATA ARCHITECTURE

,

Data Entity



Data Extension

Ph

Is Hosted

in

Encapsulates

Encapsulates

Resides within

OpeIs processedby

Provides , consumes


Resides within

ResolvesIs Provided to

ned and rned by

Is tracked against

criteria for





Identify the data entities needed to support the service :

A data entity- An encapsulation of data that is recognized by a business domain expert as a thing – e.g. a Purchase Order

It is important we differentiate between logical and physical information components :

A logical information component - A boundary zone that encapsulates related data entities to form a logical location to be held External Procurement Information

A physical information component - A boundary zone that encapsulates related data entities to form a physical location to be held SAP Purchase Order Business Object, comprising Purchase Order header and item Business Object Nodes.


SAP AG 2009


Diagram

Catalog

Matrix

Add. EAF artefact

Business .

Application .

Data .

Technology.


Application– Data








RoleActor/ Role




Role / System


Location


System / Data

Process Flow

Use Case


Organisation Chart

Events



Data Lifecycle

Data Security

Data - System


Hardware

Communications

Standards



System / Function

System / Technology

System / Location




Business Footprint


Goal/ Objective/Service




Data Migration

Data Hierarchy

Processing

Cost

Interface Catalog

System Use Case

Product Lifecycle

This diagram shows the approach to creating a Data Architecture – starting with base structure, then the context, then the operation of the data.

This approach provides a logical approach – ensuring that the base data portfolio is in place before moving onto more extensive matrices.


SAP AG 2009



SAP EAF Extensions




SAP AG 2009


Most concepts are formally modeled apart from:


Catalogs


Core Diagrams

Conceptual/Logical E-R Diag


Extension Diagrams




Data Hierarchy Diagram


Matrices

Data Entity / Business Function Matrix


For each catalog, matrix or view :



For example, do all Entities have at least one Function accessing them ? Are all Entities hosted by a System ?

Validate with Data Stewardship/Records Management staff

Has all data been accounted for ?

Is all data under formal governance ?

Validate with Business Process or Domain Expert staff

Are all data entities present and are they providing the right service ?

Validate with Senior Executives

Confirm current AS-IS and proposed TO-BE explaining which data will provide which services and why


SAP AG 2009

IS Architecture Phase - Data - Catalogs


Purpose


The purpose of this catalog is to identify and maintain a list of all the data entities/information components in the enterprise. This list helps to define the scope of data cleansing, collection and migration initiatives that may impact particular kinds of applications. An agreed data portfolio allows a standard set of corporate data to be defined and governed.

The Data Entity / Data Component Catalog contains the following metamodelentities : Data Entity Logical Information Component Physical Information Component

QUESTION : How would we ensure we captured all entities ?


SAP AG 2009

Example Catalogs



SAP AG 2009

IS Architecture Phase - Data - Matrices


Purpose

Data Entity / Business Function Matrix

The purpose of this matrix is to depict the relationship between data entities and business functions within the enterprise.

Business functions are supported by business services with explicitly defined boundaries and will be supported and realized by business processes.

The Data Entity / Business Function Matrix shows the following entities and relationships:

Data Entity Business Function Data Entity relationship to owning Organization Unit


The purpose of this matrix is to depict the relationship between systems (i.e., application components) and the data entities that are accessed and updated by them.

Systems will create, read, update and delete specific data entities that are associated with them. For example, a CRM application will create, read, update and delete customer entity information.

The System / Data Matrix is a 2-dimensional table with Logical Application Component on one axis and Data Entity on the other axis.


SAP AG 2009

Example Matrices

BUSINESS FUNCTION (Y-AXIS) AND DATA ENTITY

(X-AXIS)

CUSTOMER MASTER BUSINESS PARTNER CUSTOMER LEADS PRODUCT MASTER

Customer Relationship Management

Business partner data management service

Owner – Sales & Marketing business unit executive

Function can Create, read, update and delete customer master data

Business partner data management service

Owner of data entity (person or organization)

Function can Create, read, update and delete

Lead Processing Service Owner – Customer

Relationship Manager Function can only Create,

read, update customer leads

N/A

Supply Chain Management

Customer Requirement Processing Service

Owner – Supply Chain Manager

N/A N/A Product data management service

Owner – Global product development organization

Data Entity – Business Function Matrix

System - Data MatrixAPPLICATION (Y-AXIS)

AND DATA (X-AXIS)DESCRIPTION OR COMMENTS DATA ENTITY DATA ENTITY TYPE

SAP CRM System of record for customer master data

Customer data Master data

Commerce Engine System of record for order book Sales orders Transactional data

Sales Business Warehouse Warehouse and data mart that supports North American region

Intersection of multiple data entities (e.g. All sales orders by customer XYZ and by month for 2006)

Historical data


The intersections of the matrices can be enhanced

Instead of a simple X which indicates a positive relationship between the row and column

Here we have added further attributes


SAP AG 2009

IS Architecture Phase - Data - Core Diagrams


Purpose

Conceptual / Logical Entity-Relationship Diagram

The key purpose of this diagram is to depict the relationships among the Critical Data Entities within the enterprise.

This diagram is developed to clearly present the relationships and to help understand the lower level Data Models for the enterprise.


The purpose of this diagram is to show the relationship between data entity, business service and application components.

The diagram shows how the logical entities are to be physically realized by application components.

Additionally the diagram may show data replication and system ownership of the master reference for data. In this instance it can show two copies and the master-copy relationship between them.


SAP AG 2009


Conceptual / Logical Entity-Relationship Diagram


WarehouseWarehouse

Customer

Order History

Stock

WarehouseWarehouse

Customer

Order History

Stock

BillingBilling

Customer

Account Balance

Invoice History

BillingBilling

Customer

Account Balance

Invoice History


Online AccountSelf Service

Online AccountSelf Service

Account

Information

ActorUpdateAccount

CustomerProfile

Trigger

Contact Process

Payment

ServiceRequest

Agent

CustomerInformation

Customer

Appeal

Enquiry

Complaint

I.C2

I.A1

I.C1

P.A12

P.CS13

P.CS5

A.C2

A.A4

T.P8

T.C19 T.C16

T.C1



SAP AG 2009

IS Architecture Phase - Data - Extension Diagrams


Purpose


This Diagram is an essential part of managing business data throughout its lifecycle from conception until disposal within the constraints of the business process.

Each change in state is represented on the Diagram which may include the event or rules that trigger that change in state.


Data is considered as an asset to the enterprise and Data security simply means ensuring that enterprise data is not compromised and that access to it is suitably controlled. The purpose of the Diagram is to depict which Actor (person, organization or system) can access which enterprise data. This relationship can be shown in a matrix form between two objects or can be shown as a mapping.


Data migration is critical when implementing a package or packaged service based solution.

The Diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability.

EntityHierarchy Diagram

The purpose of this Diagram is to show the Technical Stakeholders a perspective of the Entity Hierarchy. The advantage of this Diagram is that it allows the Stakeholders a technical Utilization/Usage Diagram of the Data Entity. This Diagram gives the stakeholders an Idea of who is using the Data, how, why and when.


SAP AG 2009


Data Lifecycle Diagram Data Security Diagram

New Dispatched

New

Closed Archived Deleted

Fulfilled Invoiced Paid Closed Archived Deleted

Fulfilment Order

Customer Order

Intelligence Officer

Traffic Officer

Issue Fixed Penalty Notice

Classify Intelligence

Issue Court Summons Prosecution

Notices

Encounters

Informant

ProsecutionOfficer

Evidence

Targets

Record Intelligence

Record Intelligence


SAP AG 2009



ABM mySAPCRM

mySAPERP

mySAPSRM

CCB

BDW

MRPA

VLC (oneper geo)

SourceStaging

Transformation & Data Quality

TargetStaging

System of Record for Vendor

Master & Contracts

System of Record for Material Master & Order history

System of Record forCustomer Master

Source of Customerrecords

Source of order his tory

Source of Material data

Source of vendor data

“As- Is” applicationcomponents

Data migration technology components “To- be” applicationcomponents

Data Hierarchy Diagram

Authorised UserAuthorised User

Vehicle TesterVehicle Tester

Trainer/BookerTrainer/Booker

IndividualIndividual

KeeperKeeper

Purchaser/NomineePurchaser/NomineeCustomerCustomer

DriverDriver OrganisationOrganisation

Driving InstructorDriving Instructor

Taxi Driver

Driving ExaminerDriving Examiner

ManufacturerManufacturer

OperatorOperator

DealingDealing

Driving ExaminerDriving Examiner




SAP AG 2009

Summary

This is the end of the Information Systems Architecture – Data Phase

You should now understand how to develop :

A Target Data Architecture including: Catalogs

- Data Entity / Information Component Catalog

Matrices

- Data Entity / Business Function Matrix

- System / Data Matrix

Diagrams - Conceptual / Logical E-R Diagram

- Data Dissemination Diagram



Data Architecture Roadmap

Data Architecture Report

Updated Business Requirements

The next phase is Technology Architecture



Exercises

Unit: Information System Architecture

Topic: Sources for determining Baseline Architecture


Understand the typical people, systems and/or other sources you need to consider to determine the base line architecture for Application and Data Architectures

Scenario

Identify ROLES, DATA SOURCES, SYSTEMS and REFERENCE MODELS that you would typically use to gather information related to “as-is” or current Application and Data Architectures


1-1-1 List the set of Roles (people) you would contact within the enterprise or customer to understand about current Application & Data Architectures

1-1-2 Identify the list of data sources you would rely on

1-1-3 Identify the systems or applications that can be utilized to get an overview of current Application and Data Architectures

1-1-4 What reference models (both SAP and non-SAP) you would leverage to get a better understanding of the current Application and Data Architectures

1-2 Suggested Template

Roles Data Sources Systems Reference Models



Solutions

Unit: Information System Architecture

Topic: Sources for determining Baseline Architecture

1-1 Solution for Application Architecture


Application Owner Corporate Portal – that stores Application Architecture Blueprint


SAP Scenario Component List

Lead Application Architect Application Inventory Database or Repository SAP Product

Availability Matrix

IT Program Manager Help Desk systems Solution Composer

IT Project Manager Application Architecture Library Solution Manager

Business Process Expert Enterprise PMO

Enterprise Architect

Application Development Manager

Application Operations Support Manager



1- 2 Solution for Data Architecture


Data Steward Data Standards Library or Repository


Business object repository

Data Architect ABAP Workbench

Data Custodian Enterprise Services Repository

IT Project Manager Enterprise Services Workplace

Enterprise Architect

Application Development Manager

Corporate Data Standards Manager

SAP AG 2009

Unit 7 – Phase D: Technology Architecture



SAP AG 2009

TOGAF™ Phase D: Technology Architecture

Contents:


SAP EAF Extensions




SAP AG 2009

Unit 1a - Overview of TOGAF™™ and SAF EAFUnit 1b - Overview of TOGAF™™ and SAP EAF ComponentsUnit 1c - Content Metamodel



Unit 8 - Phase E: Opportunities and SolutionsUnit 9 - Phase F: Migration PlanningUnit 10 - Phase G and H: Implementation GovernanceUnit 11 - Enterprise Architecture GovernanceUnit 12 – TOGAF™™ and SAP EAF for Specific Engagements

Unit 13 - SAP-Specific MappingsUnit 14 – EA Tools for TOGAF™™ and SAP EAF



SAP AG 2009

Lesson Objectives


develop an AS-IS and a TO-BE Technology Architecture including:

Catalogs

Matrices

Diagrams



create a Technology Architecture Roadmap


SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools








SAP AG 2009



Usage Guidelines









Case Study Material










(App & Data)


























Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base
















Guidelines



Guidelines


709: SAP Glossary

The key references in the Technology Architecture are :

NL-T-P600 – Phase Worksheet

NL-T-P602 – Phase Narrative


SAP AG 2009



SAP EAF Extensions




SAP AG 2009

Technology Architecture Phase - Overview

The Technology Architecture phase is about defining the As-Is and To-Be technology architectures for the organization, detailing the roadmap towards the To-Be architecture, and identifying key work packages in the roadmap.


The Technical Architecture Phase is about defining the technology required to deliver the applications and data required by the Business to achieve its goals

The scope of the business processes supported in this phase is limited to those that are now or need to be supported by Information Technology

The objective here is to define the major kinds of technology necessary to process the data and run the applications defined in Phase B.


SAP AG 2009

Technology Architecture Phase - Main Objectives

Map application components defined in the Application Architecture phase into a set of technology components. Technology components represent software and hardware components, available from the market or configured within the organization into technology platforms.

Define baseline and target views of the technology portfolio

Support cost assessment for particular migration scenarios



SAP AG 2009

Technology Architecture Phase - Approach

TOGAF™ is very weak in Technology Architecture and how to do it.

Considerations cover:

Existing IT services as documented in the IT repository or IT service catalog

TOGAF™ Technical Reference Model (TRM)

Generic technology models relevant to the organization’s industry ‘‘vertical’’ sector

Technology models relevant to Common Systems Architectures

Components and underlying services necessary to provide an integrated information infrastructure.


SAP AG 2009

TOGAF™ Technology Architecture Phase - Inputs and Outputs

TechnologyArchitecture

Phase



Technology Principles, if existing



Validated Technology Principles



Technology Architecture components of an Architecture Roadmap

Communications Plan

Architecture Vision



Business, Data, and Application Architecture components of an Architecture Roadmap





SAP AG 2009

TOGAF™ Technology Architecture Phase - Overview of steps

Finalize the Technology Architecture






Develop Baseline TechnologyArchitecture Description

Develop Target Technology Architecture Description


TOGAF™

Based on material licensed from the Open Group Copyright © 2009















SAP AG 2009


Select reference models, viewpoints, and tools

Determine Overall Modeling Process Define a taxonomy of platform services and logical technology components (including

standards)

Identify relevant locations where technology is deployed

Carry out a physical inventory of deployed technology and abstract to fit the taxonomy

Look at application and business requirements for technology

Check the technology in place is fit for purpose to meet new requirements (i.e. does it meet functional and non-functional requirements)?

Determine configuration of the selected technology

Determine impact (time, quality, budget, cost of ownership)

Identify Required Catalogs, Matrices, and Diagrams of Technology Building Blocks In a package and packaged services environment, it is likely that additional vendor

specific tools may provide the information required to identify these building blocks (e.g. SAP’s Solution Composer)

Outside of a pure SAP environment building block information may be identifiable from the System Landscape, Technology standards and product portfolio information held within the organization


SAP AG 2009


Select reference models, viewpoints, and tools (cont.)

Identify Types of Requirement to be Collected Functional Requirements, Non-functional requirements (-> see next slides)

Assumptions, Constraints

Domain-specific Technology Architecture principles

Policies, Standards

Guidelines

Specifications

Select (technology related) Services



SAP AG 2009


Develop Baseline Technology Architecture Description (cont)

Identify the relevant Technology Architecture building blocks

Model Technology Architecture using the building block (mapping may be needed)

Many valuable reference architectures are available

SAP provides a collection of Solution Maps that define reference models for various industries and solution types, including SAP supplied technology components (including applications, Enterprise Services and infrastructure software)

SAP provides the Enterprise Service Workplace cataloging available Enterprise Services

The SAP EAF supplies a mapping of SAP products to the TOGAF™ Technology Reference Model (TRM). This identifies available products and their purpose



SAP AG 2009

Non-Functional Requirements 1/2

Performance Throughput

Response time

Availability Beware crude percentages

Recovery How quickly do we need to be back up and running ?

Scalability Upper bounds on the volumes of business that the system is required to handle

Security Who (roles, client machines) can access What (programs and data).

Existing Standards to be complied with


SAP AG 2009

Non-Functional Requirements 2/2

Usability May sometimes be considered as functional requirements

Maintainability Ease of modification, fault removal or of environmental change

Testability - ease of validating the modified software

Stability – few unexpected effects after modifications

Portability Adaptability - Opportunity for adaptation to different specified technical

environments without further development effort

Installability - Effort needed to install the software in a newly specified environment

Replaceability - Opportunity to replace by other software offering the same functions

Safety Audit trails


SAP AG 2009

Example: Technology Reference Model

SECURITYMANAGEMENT

DATA MANAGEMENT DEVELOPMENT

OFFICE AUTOMATION USER DEVELOPMENT

SYSTEMS MGT/ENGRG

LINE OF BUSINESS

INFORMATION SERVICES

COMMUNICATIONS

PLATFORM

APPLICATIONS

USER INTERFACE

GUI (Windows, Macintosh)

Mid-range Mainframe Client Server PC-Desktop

Scanners Voice Activation Printers Data Capture

Laptops/Notebooks

Desktop

Application

Database

Network

Facility

Project Methodology

Strategy & Planning

Change Management

Administration Management

Skills Management

Quality AssuranceManagement

CommunicationsSystems Management

Data ResourceManagement

Operations/ProductionManagement

Application Portfolio Management

End User ComputingManagement

Word Processing

Spreadsheet

E-Mail

Language Translation

Presentation Graphics

Calendar/Scheduling

Internet Browser

Object Oriented Tools

Document Management

Accounting, HR

Merchandising

Distribution

Supply Chain: ECR

Store Operations

DBMS and Data Dictionary

Query Tools/DSS/EIS

Transaction Managers, Gateways and Middleware

Groupware

Prototyping Tools

Application Programming Interface and CASE Tools

Testing and Debugging Tools

Programming Languages

Version Control

Library Management

Performance/Capacity Management

Job Scheduling/Output Management

Storage, Compression, Mirroring and Recovery

Communications Protocols

Local Area Network OS

Topology

VSAT

Network Transport

Network Mgt Utilities

Bar Coding/EDI

Wireless

Voicemail

Video Conferencing

Telephone/FAX Modems

Routers, Hubs

Fiber, wiring

Adapter cards

Technology Reference Models enable us to standardize and classify our approach to technology

Classify how many different types of Word Processors, Distribution System Software or Laptops we have


SAP AG 2009


Develop Target Technology Architecture Description

Perform gap analysis (using the gap matrix)

Define roadmap components

Resolve impacts across the Architecture Landscape Does this Technology Architecture create an impact on any pre-existing architectures?

Have recent changes been made that impact the Technology Architecture?

Are there any opportunities to leverage work from this Technology Architecture in other areas of the organization?

Does this Technology Architecture impact other projects?

Will this Technology Architecture be impacted by other projects?

Conduct formal stakeholder review

Finalize the Technology Architecture Fully document each building block

Conduct final cross-check of overall architecture against business goals




SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions




SAP AG 2009


Information

Systems

Data Architecture

Phase


BEEST Case Study

SAP EAF Templates

SAP EAF Technology Architecture Narrative


SAP EAF Technology Architecture Worksheet


SAP EAF Glossary


Additional Inputs

Additional outputs

Additional step(s)

(none)

Mapping of TOGAF™ TRM to SAP

Updated Technology, Policies, Standards, Guidelines and Specifications


SAP AG 2009

Technology Architecture Phase - SAP EAF Extensions

There are no additional steps according to EAF

But SAP EAF provides additional

examples and templates are provided

inputs to TOGAF™ steps

SAP EAF also recommends to update Policies, Standards, Guidelines and Specifications during the execution of TOGAF™ steps


SAP AG 2009

Example: Mapping to Business Drivers

Business and Application Drivers Required Technology Infrastructure

The client needs global, “real-time” access to data from all locations. For example, a mechanic needs to access vehicle history for a truck that came from across the country, for a customer who needs a repair done quickly.

high speed network, enterprise wide data access, and client/server applications

The client needs to collect data electronically at the point of transaction to reduce cost, errors, and the time required to access information related to the transaction.

hand held computers and an enhanced Shop Management System

A flexible architecture that will allow applications and data to exist across different platforms and emerging technologies.

standardized network protocol and “middleware” software product that make platform access appear transparent

An architecture that can grow incrementally as processing requirements increase.

routed network to provide new sites access to all other locations; and hardware platforms that are easily expandable

The need to integrate data from various sources throughout the organization to show key relationships.

client/server applications and “middleware”software

The need to make applications “easy to use” and reduce training costs.

applications with Graphical User Interfaces (GUIs)

Business drivers help us determine our technology architecture


SAP AG 2009

Example: Consider the Future Technology Radar

Time Of Impact (years)

2006 1 2 3 4 5

Ser

vice

Bus

ines

s Im

pact

Low

Medium

Transformational

QuantumComputing

Biometrics SOA

Federated ID

NanoComputing

SemanticWeb

Multi-AgentSystems

Ontologies

SensoryNetworks

Tablet PC

RSS

E-Paper

Wikis

Desktop Linux

Virtualisation

Web Services

ESB

Grid

VoIP

Business Rules

Engines

Rich Internet

ApplicationsWiMAX

Ultra-MobilePC

PositioningSystems

UltraWideband

HolographicStorage

4GTelematics

Web 2.0

Dashboards

When considering TO-BE Technology Architecture, one needs to consider :

New technology trends

New innovations that could help the Business achieve its goals

The maturity state of the technology ; if it is very new ; be prepared to spend extra time doing a pilot evaluation

The potential impact of the introduction of that technology on the business architecture


SAP AG 2009

Example: SAP Instance Strategy 1/2

Different Options available

Decentralized Centralized

Every project/function/ business unit operates its

own SAP instance

Multiple instances (two to n) due to business needs / company structure / commonality and

project advance

One instance for all projects/all business

units/all functions

RDBMS

RDBMS

RDBMS

RDBMS

RDBMS RDBMS RDBMS

RDBMS

RDBMS

RDBMS

RDBMS

RDBMS


SAP AG 2009

Example: SAP Instance Strategy 2/2

Centralized De-centralized

Business Model

Semi-autonomous hybrid Lines of business Operational guidance Some shared processes

Holding company Different customer base Different markets Different channels Different products Unique processes

Vision as an integrated (global) business

Strategic control Common customers Common products Common processes

SAP Deployment Model

Core design based on template Several-to-many installations Some common rules or guidelines Some local flexibility

Multiple designs Multiple installations Total local autonomy

Single design Single installation Mandatory adherence to

standards


SAP AG 2009



SAP EAF Extensions




SAP AG 2009



SAP AG 2009





Physical Technology

Component

Platform Service

Is Hosted in


ed by Realises

Providesplatform for

,




Identify the logical technology components required to fulfill that service

An encapsulation of technology infrastructure that is independent of a particular product.

A class of technology product. E.g. Supply Chain Management software as part of an ERP Suite.

Identify the Platform Services required

A technical capability required to provide enabling infrastructure that supports the delivery of applications e.g. Data Management, Transaction Processing

Identify the physical technology components required to provision the logical technology components

A specific technology infrastructure product or technology infrastructure product instance. E.g. SAP BBPCRM 5.0


SAP AG 2009


Diagram

Catalog

Matrix

Add. EAF artefact

Business .

Application .

Data .

Technology.


Application– Data








RoleActor/ Role




Role / System


Location


System / Data

Process Flow

Use Case


Organisation Chart

Events



Data Lifecycle

Data Security

Data- System


Hardware

Communications

Standards



System / Function

System / Technology

System / Location




Business Footprint


Goal /Objective/Service




Data Migration

Data Hierarchy

Processing

Cost

Interface Catalog

System Use Case

Product Lifecycle

This diagram shows the approach to creating a Technology Architecture – starting with base structure, then the context, then the operation of the data.

This approach provides a logical approach – ensuring that the base technology portfolio is in place before moving onto more extensive matrices.


SAP AG 2009



SAP EAF Extensions




SAP AG 2009


Most concepts are formally modeled apart from :



Catalogs



Matrices

System Technology Matrix

Core Diagrams



Extension Diagrams

Processing Diagram



For each catalog, matrix or Diagram :



For example, do all Systems have Technology supporting them ? Do we know where each environment is hosted ?

Validate with Application Management staff

Is all application software being supported ?

Are all technology platforms modeled ?

Ensure all “environments” are modeled

Validate with Technology Support staff

Are all technology platforms and environments modeled ?

Ensure application and server virtualization and shared infrastructure is correctly understood

Validate with Senior Executives ; for example, the CTO or the Service Manager

Confirm current AS-IS and proposed TO-BE explaining which technology will provide which services and why

Confirm existing concerns and potential solution options


SAP AG 2009

Technology Phase - Catalogs


Purpose


The purpose of this catalog is to identify and maintain a list of all the technology in use across the enterprise, including hardware, infrastructure software and application software. An agreed technology portfolio supports lifecycle management of technology products and versions and also forms the basis for definition of technology standards.

The Technology Portfolio Catalog contains the following metamodel entities :

Platform ServiceLogical Technology ComponentPhysical Technology Component


This catalog documents the agreed standards for technology across the enterprise. Covering technologies, and versions, the technology lifecycles, and the refresh cycles for the technology.Depending upon the organization this may also include location or business domain specific standards information.

The Technology Portfolio Catalog contains the following metamodel entities :

Platform ServiceLogical Technology ComponentPhysical Technology Component

QUESTION : How would we ensure we captured all technology components ?


SAP AG 2009



Customer example – Hardware related


SAP AG 2009




SAP AG 2009

Technology Phase - Matrices

Catalog, Matrix or Catalog

Purpose


This matrix documents the mapping of business systems to technology platform.

This matrix should be aligned with and complement one or more Platform decomposition Diagrams.

The System / Technology Matrix shows:

Logical / Physical Application Components Platform Services, Logical Technology Components and Physical

Technology Components Physical Technology Component realizes Physical Application Component

relationships


SAP AG 2009

Example Matrices

LOGICAL APPLICATION COMPONENT

PHYSICAL TECHNOLOGY COMPONENT

SERVER ADDRESS IP ADDRESS

ABM Web server - node 1 [email protected] 10.xx.xx.xx

Web server - node 2 [email protected] 10.xx.xx.xx

Web server - node 3 [email protected] 10.xx.xx.xx

App server – node 1 [email protected] 10.xx.xx.xx



Database server (production)

[email protected] 10.xx.xx.xx

Database server (stating) [email protected] 10.xx.xx.xx

Load balancer and Dispatcher

Dispatcher server [email protected] 242.xx.xx.xx

TECH FUNCTION

HARDWARE LOGICALHARDWARE PHYSICAL

SOFTWARE LOGICAL

SOFTWARE PHYSICAL

Load balancing

Name – BalancerVendor - IBMServer Type – eServerClustered – NoNo. of Nodes – N/AServer logical address

[email protected] Window

– Sun 0100 to 0300

Model/Type – IBM P7xxSerial Number –

1S4568Processor Type -

RISC Power p5Number of

Processors - 4 wayMemory - 1GB Hard drive - 40 GBIP - 11.xx.xx.xx

Product- IBM Load balance managerVendor - IBMOS – UNIX based

SW Components – LB v3.2 (list all the other components of the SW product)AIX 10.2.1License Type -Enterprise wide

licenseLicense expiry

date - 12/31/2008

System Technology Matrices



SAP AG 2009

Technology Phase - Core Diagrams


Purpose


These Diagrams depict which locations host which applications, identify what technologies and/or applications are used at which locations, and finally to identify the locations from which business users typically interact with the applications.


Depicts the technology platform that supports the operations of the Information System architecture. The Diagram covers all aspects of the infrastructure platform and provides an overview of the enterprise’s technology platform.


SAP AG 2009


USA


ChicagoNew JerseyUS Production

US Pre-Production

US ITL

Global Dev

US DR

JapanJapan Production

Japan Pre-Production

Japan ITL

UKUK Production

UK Pre-Production

US ITL

GermanyGermany Production

Germany Pre-Production

Germany ITL


SAP AG 2009



SAP NetWeaver™

Com

pos

ite A

ppl

ica

tion

Fra

me

wor

k

PEOPLE INTEGRATION

Multi channel access

Portal Collaboration

INFORMATION INTEGRATION

Bus. Intelligence

Master Data Mgmt

Knowledge Mgmt

PROCESS INTEGRATION

Integration Broker

BusinessProcess Mgmt

APPLICATION PLATFORM

J2EE

DB and OS Abstraction

ABAP

Life Cycle

Mgm

t

…



QUESTION : What is the impact of server virtualization and high availability environments on the Platform Decomposition View ?


SAP AG 2009

Technology Phase - Extension Diagrams


Purpose

Processing Diagram

This Diagram focuses on deployable units of code/configuration and how these are deployed onto the technology platform. A deployment unit represents grouping of business function, service or application component.

The organization and grouping of deployment units depends on separation concerns of the presentation, business logic and data store layers and service level requirements of the components.

Network Computing / Hardware Diagram

Starting with the transformation to client-server systems from mainframes and later with the advent of e-business and J2EE, large enterprises moved predominantly into a highly network based distributed network computing environment with firewalls and demilitarized zones.

The purpose of this Diagram is to show the “as-deployed” logical view of application components in a distributed networking computing environment.

Communications engineering Diagram

The communications map Diagram describes the means of communications, the method of sending and receiving information, between these assets in the Technology Architecture. The communications engineering Diagram will take logical connections between client and server components and identify network boundaries and network infrastructure required to physically implement those connections.


SAP AG 2009


Processing Diagram

LoadBalancer

and Dispatcher

WebserverWeb

server

Web server cluster-node 3 (ABM)

DFS Distributed File System (html,

images)

ApplicationServer

ApplicationServerApp Server

cluster - node 3 (ABM)

Database (ABM

Production)

Database (ABM

Staging)

Web servercluster

Web server cluster-node 2 (eCommerce)

ApplicationServer (Order

Engine)

Database App Server (SAP

ERP-SD)Database

App Server (SAP SCM)

Firewall Firewall Firewall

LoadBalancer

and Dispatcher

Internet Zone DMZ Intranet Zone



SAP AG 2009


Firewall

InternetAP Dealer Workstation

Cisco Routers -Virtual Load Balancer

Firewall

Firewall

Internet

F5 Load Balancers

Firewall

F5 Load Balancers

NA Dealer Workstation

Database LANProduction LAN

North American DMZ

North American Intranet

Holden DMZ Holden LAN

2 Mbps

New or Modified Components

Existing Components

2 Mbps

2 Mbps

2 WebSEAL Servers Sun Fire V240 Server 2*1GHz CPU, 8GB RAM or spare equipment from Holden Portal decommissioning

2 Terminal Emulation Servers Sun FireV240 Server 2*1GHz CPU, 8GB RAM or

spare equipment from Holden Portal decommissioning

Holden Applications VOL, COLD, Warranty Online,

Warranty File Transfer (HFTS), PartsOnline, Bulletins etc.

8 WebSEAL Servers Sun FireV240 Server 2 * 1GHz CPU,

8GB RAM 2x36GB HDD(internal)

2 SunONE Portal Servers Sun Fire V1280 Server 12CPU, 24GB

RAM

WebSEAL Junctioned APP Servers - OWB etc Sun Fire

V480 4 * 1GHz CPU 8GB RAM

1 Interwoven Server Team Site, OpenDeplovSUN Fire V210, 1 GHz,

2GB RAM

2 LDAP CostumersSUN Fire V240, 2 x 1 GHz CPU, 8GB RAM

EntityDatabase

2 User AdminServers SUN FireV240, 2 x 1 GHz CPU, 8GB RAM

2 Oblix NetPoint and TAM Servers SUN V480, 1 x 1 GHz CPU, 16GB RAM

2 LDAP Servers - Multi-Master SunOne and IDAR

SUN Fire V880, 8CPU 16GB RAM




SAP AG 2009



SECURITY LDAP

WEBSEAL

LDAP Master Server

Sun Directory Server 5.2

Sun, Solaris 10

LDAP Server Storage

EMC Symmetrix

LDAP ConsumerServer Storage

EMC Symmetrix

LDAP ConsumerServer

Sun, Solaris 10

WebSeal

LoadBalancer

LoadBalancer

LDAPServer

LDAP Consumer

Server

LDAPConsumer

Storage

LDAP Load BalancingF5 Big-IP 5000 device v4.5

LDAP Load BalancingF5 Big-IP 5000 device v4.5Load

Balancer

LDAPServer

LDAPServer

Storage

LDAPServer

Storage

LDAP Consumer

Server

LDAPConsumer

Storage

Portal ServerSun Portal v7 Portal

LDAP (Sun Directory Server v5.2) Sun

Application Server Sun Solaris 10

Portal Server Storage

EMC Symmetrix

Portal Administration ServerForms-based Login Sun Web

Server 6.2BEA Weblogic Application

Server 9.1(3 instances) Sun, Solaris 10

Portal Administration

Server StorageEMC Symmetrix

TAM, Oblix & CustomVSP Code 1

Sun Web Server 6.2(2 instances)

JRUN Server Tivoli Access Manager 6

Oblix COREid 10 Solaris 10

WebSeal Load BalancingF5 Big-IP 5000 device v4.5

WebSeal Load BalancingF5 Big-IP 5000 device v4.5

LoadBalancer

WebSeal WebSeal WebSeal WebSeal WebSeal WebSeal WebSealWebseal Servers (8+)

Tivoli Access Manager Sun, Solaris 10

Portal, TAM, Oblix and CustomVSP Code

Portal ServerSun Portal v7 Portal LDAP (Sun Directory

Server v5.2) Sun Application Server

Sun Solaris 10

Portal Server Storage

EMC Symmetrix

Portal Administration ServerForms-based Login Sun Web

Server 6.2BEA Weblogic Application

Server 9.1(3 instances) Sun, Solaris 10

Portal Administration Server StorageEMC Symmetrix

TAM, Oblix & CustomVSP Code 1

Sun Web Server 6.2(2 instances)

JRUN Server Tivoli Access Manager 6Oblix COREid 10

Solaris 10

Portal AdminServer

Portal AdminServer

Portal AdminServer

Storage

Portal AdminServer

Storage

Portal Server

Portal Storage

Portal Server

Portal Storage

TAM, Oblix

Server

TAM, Oblix

Server

Load BalancerLoad Balancer

LDAP ConsumerServer StorageEMC Symmetrix

LDAP ConsumerServer

Sun, Solaris 10

LDAP Master Server

Sun Directory Server 5.2

Sun, Solaris 10

LDAP Server Storage

EMC Symmetrix

Enterprise Management Tools, such as HP Open View can provide up-to-date views of the current technology architecture

QUESTION – what other tools might be useful here ?


SAP AG 2009

Summary

This is the end of the Technology Architecture Phase

You should now understand how to develop:

A Target Technology Architecture including: Catalogs

- Technology Portfolio Catalog

- Technology Standards Catalog

Matrices

System Technology Matrix Diagrams

- Environments and Locations Diagrams

- Platform Decomposition Diagram



Technology Architecture Roadmap

Technology Architecture Report

The next phase is Opportunities and Solutions



Exercises

Unit: Business, Information System and Technology Architecture

Topic: Group Discussion on EAF Artifacts


Determine the value, importance and use of each of the SAP EAF prescribed artifacts in Business, Information System and Technology Architecture phases (Phases B, C & D)

Scenario

You are now part of a cross-functional Enterprise Architecture team. You have been assigned a task to develop the Enterprise Architecture for your enterprise. It is your task to guide the cross functional team through the SAP EAF Architecture Development Method process. You have to determine, which artifacts you would focus on developing for your enterprise.


1-1-1 Refer to the Catalogs, Matrices and Diagrams summary from Business, Information System and Technology Architecture phases (Units 4, 5, 6 & 7)

1-1-2 Discuss as a team the validity, importance and usefulness of each of the Catalog, Matrix and Diagram prescribed for Business, IS and Technology Architecture phases

1-1-3 Classify each artifact as “Critical”, “Important” and “Nice to have” and compile them in a spreadsheet

1-1-4 Present your findings to the class

1-2 Suggested Template

SAP EAF ADM Phase

Type of Artifact

Artifact Name Critical Important Nice to Have Comments

Catalog Organization/Actor catalog Explain reasons

Matrix Business Interaction Matrix Explain reasons


Diagram Business Footprint diagram Explain reasons

Repeat above for other Catalogs, Matrices and Diagrams in Business Architecture

Repeat above for Application Architecture, Data Architecture and Technology Architecture



Solutions

Unit: Business, Information System and Technology Architecture

Topic: Group Discussion on EAF Artifacts

1-1 One possible Solution

SAP EAF ADM Phase

Type of Artifact

Artifact Name Critical Important Nice to Have

Comments

Catalog Organization/Actor catalog

X Needed to define access controls and security reasons

Matrix Business Interaction Matrix

X Explain reasons


Diagram Business Footprint diagram

X To clearly understand and establish traceability of a single goal all the way down to a technology component.


X This is critical information to understand the complete inventory of applications in the enterprise

Catalog

Application Interface Catalog

X This is very domain specific and is of great interest to application architects. Hence it is critical for Application Architects and very important for Enterprise Architects.

Matrix System/Function Matrix

X Absolutely vital information for an EA. It is critical to understand which functions are being supported by which application components within the enterprise


Diagram Application to Application Communication Diagram

X Application landscape diagrams are a visual depiction of the application catalog and they provide an nice overview of the application architecture

Catalog Technology Portfolio Catalog

X This is critical information to understand the complete inventory of technology components in the enterprise


Matrix System/Technology Matrix

X Absolutely critical to understand the mappings



between the application and its technology components. It is the technology components that support the operations of the application (in other words it is where rubber hits the road)

Diagram Platform Decomposition Diagram

X This is very domain specific and of great interest to Technology Architects and very important for Enterprise Architects.

SAP AG 2009

Unit 8 –Phase E: Opportunities and Solutions



SAP AG 2009

TOGAF™ Phase E: Opportunities and Solutions

Contents:

Introduction to Opportunities and Solutions

SAP EAF Extensions

Example outputs


SAP AG 2009








SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand how to

Consolidate outputs from Phases A - D

Set up an Implementation and migration strategy

Develop a High-level implementation plan


SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools







In this Unit we are going to focus on “Opportunities & Solutions” Phase


SAP AG 2009

Detailed Component ViewOverall Description of SAP EAF


Usage Guidelines









Case Study Material










(App & Data)























101: ExampleArchitecture

Principles



Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base















802: Portfolio View

Guidelines



Guidelines


709: SAP Glossary


We will go through the narrative in detail

NL-O-P800 – Phase Worksheet

NL-O-P801 – Phase Narrative

NL-O-P803 – Solution Architecture Terms of Reference

NL-O- P802 – Portfolio View Guidelines


SAP AG 2009



SAP EAF Extensions

Example outputs


SAP AG 2009

Opportunities and Solutions Phase - Overview

The Opportunities and Solutions phase is about defining a consolidated and agreed roadmap for change across Business, Application, Data and Technology domains.

Change activity identified in previous A-D phases are prioritized, packaged, and sequenced for implementation.


What is the “O & S” phase about?

In this phase we define a consolidated Roadmap for change across all the architecture domains

As EAF supports packages & packaged Service implementation, it is during this phase all the change activities identified in the “Architecture Definition” phases (A-D) are packaged, prioritized and sequenced for implementation


SAP AG 2009

Opportunities and Solutions Phase - Main Objectives

To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities

To review and confirm the enterprise's current parameters for and ability to absorb change

To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks

To generate and gain consensus on an outline Implementation and Migration Strategy



SAP AG 2009

Opportunities and Solutions Phase - Approach

Phase E is the first phase which is directly concerned with the structure of how the Target Architecture will be implemented

Phase E concentrates on how to deliver the architecture. Work packages are set up considering IT and Business priorities and dependencies

Consolidate, integrate, and analyze the information gained in the previous phases

Co-existence and interoperability issues (from a business, information, and technology perspective) are examined and clarified

Development of a series of Transition Architectures that show incremental progress from the Baseline Architecture to the Target



SAP AG 2009

TOGAF™ Opportunities and Solutions Phase - Inputs and Outputs

OpportunitiesAnd Solutions

Phase





Governance Models and Frameworks

Consolidated and validated Architecture Roadmap

Transition Architecture

Implementation and Migration Plan

Refined and updated versions of the Architecture Vision, Business Architecture, Information

Systems Architecture, and Technology Architecture phase deliverablesCommunications Plan

Architecture Vision



Change Requests (for existing business programs

and projects)




Architecture Reference Materials

Product Information


SAP AG 2009

TOGAF™ Opportunities and Solutions Phase -Overview of steps

Formulate High-Level Implementation and Migration Strategy

Refine and Validate Dependencies

Review IT Requirements from a Functional Perspective

Consolidate and Reconcile Interoperability Requirements

Confirm Readiness and Risk for Business Transformation

Determine/Confirm Key Corporate Change Attributes

Review and Consolidate Gap Analysis Results from Phases B to D

Identify and Group Major Work Packages

TOGAF™

Identify Transition Architectures






































Create Portfolio and Project Charters and Update the Architectures









Determine Business Constraints for Implementation















SAP AG 2009



Create an Implementation Factor Assessment and Deduction Matrix

Assess Transition Capabilities of Corporate and Partner Organizations

Document findings in matrix above



SAP AG 2009


Determine/Confirm Key Corporate Change Attributes (cont.)

Assess Transition Capabilities of the Enterprise and IT Organization, considering

The organization and culture of the enterprise and the IT organization

The enterprise personnel skill sets

The gap analysis between the Baseline and Target Architectures

Document findings in Factor Assessment and Deduction Matrix

Determine Business Constraints for Implementation

Review Corporate Strategic Plan

Business drivers should be linked to implementation issues and documented in the Implementation Factor Assessment and Deduction matrix

Review the Enterprise Architecture Maturity Assessment (-> Prelim Phase)

Update the Implementation Factor Assessment and Deduction matrix with any actions, activities, initiatives, and projects that have to be undertaken

Review Corporate Line-of-Business Strategic Plans

Identify any initiatives, portfolios, projects, or activities

Update Implementation Factor Assessment and Deduction matrix



SAP AG 2009



Create a Consolidated Gaps, Solutions, and Dependencies Matrix

Review the Phase B, C, and D Gap Analysis Results Create CRUD of gaps and solutions

Update Implementation Factor Assessment and Deduction matrix

Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix Any additional "factors" should be added to the Implementation Factor Assessment and

Deduction matrix



SAP AG 2009



Assess the IT Requirements from a Functional Perspective

Determine Issues Associated with Functional Integration Update Implementation Factor Assessment and Deduction matrix Consolidated Gaps,

Solutions, and Dependencies matrix


Consolidate Interoperability Requirements

Reconcile Interoperability Requirements with Potential Solutions


Business dependencies

Information dependencies

Workflow dependencies

IT dependencies

Foundation dependencies

Rationalize and Consolidate Dependencies



SAP AG 2009



Assess the ability of the organization to adapt to change and capture the associated risks (-> Architecture Vision)

Update Transition Architecture(s)


Determine Overall Strategic Implementation Direction Greenfield

Revolutionary

Evolutionary

Determine an Implementation Approach Quick win (snapshots)

Achievable targets

Value chain method



SAP AG 2009


Identify and Group Major Work Packages

Identify Major Work Packages For every gap identified state if it is new development or based upon a existing product

and/or solution that can be purchased

Group like solutions together as potential work packages

Analyze the Work Packages with Respect to Business Transformation


Identify Transition Architecture and Capability Increments

Group Portfolios and Projects into Increments

Create Portfolio and Project Charters and Update the Architectures

Create the Portfolio Charters (TOGAF™ does not provide a guideline for this)

Create the Transition Architectures (-> outline next page)

Conduct Overall Architecture Updates



SAP AG 2009

Example: Transition Architecture Structure according to TOGAF™



SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions

Example outputs


SAP AG 2009

TOGAF™ Opportunities and Solutions Phase - Inputs and Outputs

Opportunitiesand Solutions

Phase

SAP EAF Opportunities and Solutions Phase Worksheet

SAP EAF Opportunities and Solutions Narrative Document

SAP EAF Solution Architecture Engagement ToR

SAP EAF Portfolio View Guidelines Solution Architecture Projects


SAP AG 2009

SAP EAF Extensions

SAP provides additional SAP-specific inputs to this phase, containing

SAP packaged services approach

SAP portfolio methods

SAP best practices (Roadmap Composer or Solution Manager)

TOGAF™ is very redundant in this phase. There are overlaps to work already done in other phases. SAP suggests to tailor the activities of this phase to a more consistent approach

There are key SAP specific factors to be considered in an implementation approach

Define Implementation Strategy

Define Configuration Strategy

Define Development Strategy

Define Business Rollout Strategy

Define Customer Release Strategy

Develop a Customer Competence Center Strategy


SAP AG 2009

Example outputs


SAP EAF Extensions

Example outputs


SAP AG 2009

Ph

ase 2 part 2

Ph

ase 2 part 1

Years 4 - 5Years 2 - 3Years 1

As-Is

Program C Program D

Pro

gra

m A

To-Be

Pro

gra

mB

PROJECT B3

PROJECT B4

PROJECT B2

PROJECT B1

PROJECT C1

PROJECT C2

PROJECT C3

PROJECT D1

PROJECT D2

PROJECT D3

PROJECT A1

PROJECT A2

PROJECT A3

PROJECT A6

PROJECT A7

PROJECT A4PROJECT A5

Example High Level Roadmap

This is an example of high level roadmap


SAP AG 2009

Build the Consolidated Architecture Roadmap (1/5)

6 months 1 year 2 years

Time

1.5 years

Short term Midterm Long term

Business ProcessesRoad map for business processes

Order EntryOrder Management (IDoc)Order Entry

Clearing

Validation CheckATP CheckGTS Check

Credit Check

Order Processing

InvoicingControlling EXAMPLE

Collect and draw dependencies. Make estimations about duration of process implementations. Stretch project timeline because of capacity constraints or contingency. Bring business processes into first draft of timeline.


SAP AG 2009


2007

Time

2008

Short term Midterm Long term

ApplicationsRoad map forapplicationlandscape

PlatformRoad map forTechnology platform e.g. SAP NetWeaver™


From the defined road map for the identified functions, services and processes, map to third-party applications from strategic application vendors e.g. SAP ERP

Step 2

EXAMPLE


Clearing


Credit Check

Order Processing

InvoicingControlling


SAP AG 2009




Clearing


Credit Check

Order Processing



SAP® R/3 “P01” 4.6c

SAP R/3 “P02” 4.6c“P03” SAP ERP 6.0

Lotus DB

Siebel CRMSAP CRM 6.0

Hyperion

ER

PC

RM

SE

M

EXAMPLE


SAP AG 2009


PlatformsRoad map toapplicationlandscape


EXAMPLE


Clearing


Credit Check

Order Processing



SAP® R/3 “P01” 4.6c

SAP R/3 “P02” 4.6c“P03” SAP ERP 6.0

Lotus DB


Hyperion

ER

PC

RM

SE

M

PlatformRoad map forTechnology platform e.g. SAP NetWeaver™

From the defined roadmap for applications, map to technology infrastructure and platform components from strategic vendors e.g. SAP NetWeaver, MS .NET

EXAMPLE


SAP AG 2009



EXAMPLE


SAP® R/3 “P01” 4.6c

SAP R/3 “P02” 4.6c“P03” SAP ERP 6.0

Lotus DB


Hyperion

ER

PC

RM

SE

M

PlatformRoad map for technology landscapeSAP NetWeaver™

SAP XI / BPM 3.0 SAP XI / BPM 4.0

SAP Portal 6.0 SAP Portal 7.0

SAP MDM 3.0PoC

PoC

PoC

SAP BW 3.5PoC SAP BW 7.0

SAP BW 7.0


Clearing


Credit Check

Order Processing


EXAMPLE


SAP AG 2009

Example Implementation Plan

PROJECT 1

PROJECT 2

PROJECT 3

PROJECT 4

PROJECT 5

PROJECT 6

PROJECT 7

PROJECT 9

PROJECT 9

Q2 ‘05 Q3 ‘05

Key Implementation MilestonesProject Timeline

Q4 ‘05 Q1 ‘06 Q2 ‘06 Q3 ‘06

High Level Dependencies

A typical program level implementation plan that shows key milestones and dependencies


SAP AG 2009

Summary

This is the end of the Opportunities and Solutions Phase

You should now understand how to

Consolidate outputs from Phases A - D

Set up an Implementation and migration strategy

Develop a High-level implementation plan

The next phase is Migration Planning


We reviewed the Opportunities & Solutions Phase and you should be familiar with the following..… (Notes – go through the bullet items)

In the next unit we will cover the Migration Planning in more detail



SAP AG 2009

Unit 9 – Phase F: Migration Planning



SAP AG 2009

TOGAF™ Phase F: Migration Planning

Contents:

Introduction to Migration Planning

SAP EAF Extensions

Migration analysis using TOGAF™ Viewpoints


SAP AG 2009








SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand how to further develop:

An Implementation and Migration Plan


SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools






In this Unit we are going to focus on the “Migration Planning” Phase


SAP AG 2009



SAP EAF Extensions

Migration Planning Considerations


SAP AG 2009

Migration Planning Phase - Overview

The Migration Planning phase is about finalizing an Implementation and Migration plan for the work packages defined in the Opportunities and Solutions phase.

Migration Planning includes consideration of benefit, cost, resource, technical feasibility and schedule


The Migration Planning Phase is about taking the various implementation projects in priority order from Phase E.

Migration Planning is based on the idea that to manage major organizational change, we should manage complexity and risk by proceeding through a number of discrete “stages”.

We need to assess each project or work package for its dependencies, and for its costs and benefits.

The objective is to develop a validated, detailed implementation and migration plan to demonstrate we can move the organization from its AS-IS to its TO-BE state in valid stages.

QUESTION : Who has done migration planning before ? What are the challenges you faced ?


SAP AG 2009

Migration Planning Phase - Objectives

To ensure that the Implementation and Migration Plan is coordinated with the various management frameworks in use within the enterprise

To prioritize all work packages, projects and building blocks by assigning business value to each and conducting a cost/business analysis

To finalize the Architecture Vision and Architecture Definition documents in line with the agreed implementation approach

To confirm the Transition Architectures defined in Phase E with relevant stakeholders

To create, evolve and monitor the Implementation and Migration Plan providing necessary resources to enable the realization of the Transition Architectures, as defined in Phase E



SAP AG 2009

Migration Planning Phase – Approach

The main focus of Phase F is the creation of a viable Implementation and Migration Plan in co-operation with the portfolio and project managers.

Phase F activities include assessing the dependencies, costs and benefits of the various migration projects. The prioritized list of projects will form the basis of the detailed Implementation and Migration Plan that will supplement the architectures with portfolio and project-level detail assigning tasks to specific resources.

The Implementation and Migration plan is part of a family of plans issued by enterprise management frameworks that have to be closely co-ordinated to ensure the business value is delivered and that the resources are made available to complete the necessary work. The phase ensures that all concerned agencies outside of the Enterprise Architecture world are aware of the scope and impact of the Implementation and Migration plan and its implications with respect to their activities.

Finally, the architecture evolution cycle should be established to ensure that the architecture stays relevant, and lessons learned should be documented to enable continuous process improvement.



SAP AG 2009

TOGAF™ Migration Planning Phase - Inputs and Outputs

Migration PlanningPhase





Governance Models and Frameworks

Finalized Architecture Definition Document

Communications Plan

Architecture Vision



Change Requests for existing Projects and Programs



Architecture Reference Materials

Consolidated and validated Architecture Roadmap


Transition Architecture, Version 1.0

Implementation and Migration Plan, Version 0.1

Finalized Architecture Roadmap

Finalized Transition Architecture

Architecture Contracts for implementation projects

Re-Usable Architecture Building Blocks

Requests for Architecture Work for the architecture aspects of implementation projects (if any)

Implementation Governance Model

Change requests arising from lessons learned

Finalized Architecture Requirements Specification

Implementation and Migration Plan, Version 1.0


SAP AG 2009

TOGAF™ Migration Planning Phase - Overview of steps







TOGAF™Determine/Confirm

Key Corporate Change Attributes

































Generate the Architecture Implementation Roadmap (Time-lined) and Migration Plan

Establish the architecture evolution cycle and document lessons learned

Confirm Transition Architecture increments/phases and update Architecture Definition Document

Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation

Estimate resource requirements, project timings, and availability/delivery vehicle

Confirm management framework interactions for Implementation and Migration Plan

Assign a business value to each project















SAP AG 2009

Step 1 - Confirm management framework interactions for Implement

There are four management frameworks that have to work closely together for the Migration plan to succeed namely: Business Planning that conceives, directs, and provides the resources for all of the

activities required to achieve concrete business objectives/outcomes.

Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain; currently IT governance addresses many of these requirements.

Portfolio/Project Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes.

Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes.

If some of these areas are not managed, then the enterprise architect/CIO should at least create an ad hoc management framework capability with a plan to mature and formalize it over time.

The Implementation and Migration Plan will impact and consequently have to be reflected in each one of these frameworks. In the course of this step, understand the frameworks within the organization and ensure that these plans are co-ordinated and inserted in a summary format within the plans of each one of these frameworks.

The outcome of this step may be that the Implementation and Migration plan will not be discrete but part of a different plan produced by another one of the frameworks with enterprise architecture participation.



SAP AG 2009

Step 2 - Assign a Business Value to each Project

Establish and assign business values to all of the projects and project increments. The intent is to first establish what constitutes business value within the organization, how it can be measured, and then apply it to each one of the projects.

Confirm Organizational Business Value, Return on Investment (ROI) and Performance Measurement Parameters to ensure that the business value parameters are well-understood and serve as the basis for the creation and monitoring of the Implementation and Migration Plan.

Assign Risk to the Projects and Project Increments. The Consolidated Gaps, Solutions and Dependencies Assessment from Phase E has a column of risks for each of the activities. The action is to aggregate the risks associated with each activity for the projects.

Assign Business Value to the Projects and Project Increments. Develop an estimated value to the business for each project, with business management input.

Determine Continuous Value Assessment Technique. This assessment could be developed through the use of a matrix based on a value index dimension and a risk index dimension. This activity should be conducted by both business and IT representatives. These measures will be used in portfolio management where the projects are often assessed with respect to this value-risk matrix with size and status (performance measurement) being graphically displayed. Value in this case should be largely premised upon strategic fit that is directly attributed to the enterprise architecture.



SAP AG 2009

Business Value Assessment Technique

The value index should include criteria such as compliance to principles, financial contribuution, strategic alignment, and competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity and impact of failure. Each criterion should be assigned an individual weight. The index, criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known.


Project E

Project B Project

D

Project A

Project F

Project C

Project G Project

H


SAP AG 2009

Step 3 - Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle

Determine the required resources and times for each project and provide the initial cost estimates for the projects. The costs should be broken down into capital (to create the capability) and operations and maintenance (to sustain the capability).

Determine Personnel and Infrastructure (Capital) costs. For personnel, this estimate should include costs associated with training, moving and severance. Ensure that all infrastructure costs are captured e.g. office space, furniture, hardware and software that has to be acquired.

Determine Operations and Maintenance costs. These costs are associated with the Total Cost of Ownership (TCO) for a Solution Building Block (SBB). These costs are triggered after the SBB has been handed over to Operations Management from the Project Delivery organization.

Determine Transition Architecture/Project Increment Timings. The determination of resources will enable an initial estimate of the time that the projects will take. The gross estimate should be included for every SBB being envisaged.

Assess Best Delivery Vehicle. The enterprise architect should use this estimate to look at the resources available within the organization and determine whether the delivery vehicle should be internal, by contract, or a combination of both. In many organizations, the implications of contracting are time-consuming, but the availability of the enterprise architecture should greatly facilitate the compotion of the Statement of Architecture Work and result in well-focused bids that address the requirements of the enterprise.



SAP AG 2009

Step 4 - Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

Prioritize the projects by ascertaining the business value delivered by the projects against the cost of delivering them. The approach is to first determine the net benefit of all of the projects, then verify that the risks have been effectively mitigated and factored in. Afterwards, the intent is to gain consensus to create a prioritized list of projects based upon benefit and risk that will provide the basis for resource allocation.

Derive Cost Benefit Analysis for the Migration Projects. Use the previously derived business drivers from Phase E to initiate the cost/benefit analysis and drive the Return on Investment (ROI). The ROI has to be cleatr and take into account the stakeholders.

Validate the Risk Assessment. In this activity the architect reviews the risks documented in the Gaps, Solutions and Dependencies report and ensures the risks for the project have been mitigated. Update the project list with risk-related comments.

Prioritize the Projects. Using the previously calculated net benefits, and the Gaps, Solutions and Dependencies Analysis, get consensus amongst the stakeholders to agree upon a prioritization of the projects and a validation/update of the corporate risk assessment based upon the prioritization. Prioritization criteria will include the key business drivers identified in Phase E as well as those relating to individual stakeholders’ agendas such as Reduction of costs

Consolidation of services

Ability to handle change

A goal to have a minimum of “interim” solutions (that often become long-term or strategic!)



SAP AG 2009

Step 5 - Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document

An incremental implementation infers that concurrent activity may occur on multiple Transition Architectures that are defined to the necessary, but minimum, level of detail.

Confirm Transition Architecture Time-Spans. The first activity is to agree the time-span of an increment. This is challenging and has to take into account the area where the architecture has to be implemented and the results of the analysis of the enterprise list of events and timings e.g. in a government agency the tendering process may end up determining how long an increment may be; in other enterprises this could be the budgetary cycle. Ultimately it is the availability of funding that will determine whether increments move forward or not.

Confirm Business Value Delivered by the Increments. Once the length of the increment is clearly established, review gap analyses, dependencies, and prioritized portfolios/projects and validate that discrete business outcomes can be delivered in increments. This should be completed at the portfolio level as entire projects may be re-scheduled to allow others to move forward more rapidly. A successful basic strategy is to focus on projects that will deliver short-term pay-offs and so create an impetus for proceeding with longer-term projects.

Update Previously Created Architecture Deliverables. If the implementation approach has shifted as a result of confirming the implementation increments, update the Transition Architectures to reflect the revised direction. Update the Architecture Definition, assigning project objectives and aligning projects and deliverables with the enterprise architecture increments.



SAP AG 2009

Step 6 - Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan

This step generates the Implementation and Migration Plan sequence and details. The main feature of architecture planning is that there will be a great deal of concurrent activity and the Implementation and Migration Plan will be the “Glue” holding all of these artifacts together. Much of the detail for the plan has already been gathered and this step brings it all together using accepted portfolio/planning and management techniques.

Confirm Enterprise Architecture Evolution. There is a need to confirm the actual evolution of the architecture to co-ordinate the development of several instances of the various architectures. Resources have to be assigned to move the architectures ahead in a coherent manner.

Enterprise Architecture State Evolution. This part of the Implementation and Migration Plan will show the proposed state of the architectures at various levels of detail depending upon how far in the future the snapshot is. The snapshot describes the functionality delivered by the enterprise architecture at a particular point in time.

Detailed Implementation and Migration Plan. The enterprise architect should complete this activity in conjunction with the portfolio and project management staff, whose primary responsibility will be to govern the implementation of the Target Architecture.

Incorporate Project Schedules. Projects will take their assigned roles and ensure that their deliverables are thoroughly planned. Their project plans should be rolled up into the Implementation and Migration Plan.

Plan the Migration Details. The Migration Plan must focus on the actual handover of the constructed project elements and their integration into the infrastructure. The Migration Plan must also cater for ongoing operations and maintenance of delivered projects.



SAP AG 2009

Step 7 - Establish the Architecture Evolution Cycle and Document Lessons Learned

Enterprise architectures must be kept up-to-date or they will slowly become irrelevant, superseded by Project or Solution architectures. The time required to translate a change from the strategic to the project architecture is significant and must be understood and catered for within the organization. Furthermore, lessons learned are crucial within a learning organization and should be documented and assessed as part of the enterprise evolution process.

Confirm the Enterprise Architecture Evolution Cycle. The set of architectures are dynamic and the transformation cycle will have to be subject to strict control in order to ensure that the architectures remain relevant and provide the critical guidance to projects. There is no point in creating a family of architecture artifacts that are not going to be properly maintained as they will become obsolete relatively quickly; there has to be a regular update mechanism built into the architecture transformation process. Allow sufficient time to execute this update cycle, considering the many activities that must be coordinated.

Confirm the Enterprise Architecture Management Processes. Release management is particularly important so that everybody is able to contribute in a timely manner and that architects within the enterprise are using the authoritative architectures. Configuration management is also critical to ensure that architectures are co-ordinated and accurately reflect current and planned reality.

Document Lessons Learned. Lessons learned should be documented and treated as governance artefacts, reviewed and actioned in the form of one or more change requests, or changes in processes, organization, or whatever is needed to improve the development and implementation of enterprise architecture.



SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions



SAP AG 2009

SAP EAF Migration Planning Phase - Inputs and Outputs

Migration PlanningPhase

SAP EAF Migration Planning Phase Worksheet

SAP EAF Migration Planning Narrative Document

SAP EAF Portfolio View Guidelines

Detailed Implementation and Migration Plan

Solution Architecture Projects


SAP AG 2009



SAP EAF Extensions



SAP AG 2009

Migration Analysis using TOGAF™ Viewpoints

The Enterprise Architect needs to ensure that not only is the “To-Be” Vision position sustainable, but so are all the intermediate steps in between

Phase F’s goal is to ensure that, at the end of each migration stage, the organization, its people, processes and technologies form a coherent whole

Otherwise, the business suffers and its rate of change is drastically reduced…….

We need to find the most efficient route across the stepping stones.

So how do we actually perform migration analysis ?

TOGAF™ does not explain this in detail

SAP EAF provides a step-by-step approach


SAP AG 2009

The Migration Problem

The conventional design problem is:

what is it going to look like ?

it tends to only focus on the vision

The migration problem is:

when will it look like that ?

what changes must or might be synchronised ?

for de-synchronised changes….

what is the sequence ?

what is the intermediate structure ?

what does it look like today ?

what is already in the pipeline ?

do people understand the progression ?

Only when we know the answers can we construct a realistic Implementation and Migration plan

Firstly, we need to remember that up until now, we have been in design model

we have only been concerned with what will the architecture be composed of, what new components do we need, what old ones can we remove

We need to switch into migration mode

Consider how we will implement the new components and in what sequence

Otherwise all our good work will stay on the shelf

If we can’t explain how to implement it, then who can ?


SAP AG 2009

Migration is a multi-dimensional problem

Stage 1

Vision


systems

technicalenvironments

foundation

business

Stakeholder Viewpoints

Time Stage n

Information Systems

Technology

Business

People

Transitionstages

The plan and stages an organization has to take to get from the current state to the future state in incremental steps is rarely a linear process

We need to consider how the architecture changes (whether Business, Information Systems or Technology) at each of the “transition stages”

SAP AG 2009

Transition architecture stages can be verified using the TOGAF™ Content Metamodel, Viewpoints and EA Tools

Metamodel


Database Object

Database Object

DatabaseObject

Database Object

?

Reference Models


Queries / Analysis Catalogs, Matrices

and Diagrams

Stakeholder Viewpoints

Stakeholder


Architecture

Repository









Organisat ion Unit

Goal

Objective



Function

Process

Actor

Role




Data Entity



Ex tens ion


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Host edin


Encapsulates

Resideswithin



Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedt hrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin


Performstask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by


Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby











Organisat ion Unit

Goal

Objective



Function

Process

Actor

Role




Data Entity



Ex tens ion


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Host edin


Encapsulates

Resideswithin



Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedt hrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin


Performstask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by


Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby




SAP AG 2009

Operational aspects must be considered

Existing operational release cycles need to be considered, for example :

Operating System Security Patches

Database Security Patches

Package and Package Service Update Pack Releases

Business needs have to be considered

Business timelines

Data movement restrictions must be considered

User impact

Cost implications

Agreeing a Release Strategy within the migration plan will improve the viability of that plan

Release Management maturity

Test Management maturity

Training Management maturity

SAP EAF document NL-M-P903 – Release Strategy is provided as guidance at this stage

When are most of the organization on annual leave ?

When are operational systems taken down for regular maintenance patching ?

Does the business have an operational calendar ?

Does IT have a service maintenance calendar ?

QUESTION –Can you think of other Release Strategy issues to consider during Migration Planning ?


SAP AG 2009

Program management is not a TOGAF™-specific activity

There are many different methodologies, practices and frameworks to support this phase of the framework

The UK Government have supported the development of several key methods and frameworks that have been successfully implemented across the world Prince2 is a Project Management methodology

http://www.ogc.gov.uk/prince2/ This covers Project Initiation

MSP (Managing Successful Programmes) is a program management methodology http://www.ogc.gov.uk/guidance_managing_successful_projects.asp This covers Program Planning and Program Initiation

ITIL (IT Infrastructure Library) provides a cohesive set of bestpractices covering IT Service Management http://www.ogc.gov.uk/guidance_itil.asp This covers Release Management and Change Management

We can see that Phases E and F of TOGAF™ start to overlap with existing methods and frameworks.

This is natural as we are entering the phase of program planning

Question : can you think of other relevant frameworks and methods here ?


SAP AG 2009

MSP - Managing Successful Programmes

Managing Successful Programmes (MSP) is a structured, flexible framework to manage and control a program.

It is managed by the UK Office of Government Commerce.

Worldwide, MSP is becoming best practice for Program Management.

There is a close link between MSP and PRINCE2™.

MSP includes advice on Identifying and Defining a Program

The diagram here shows the Framework overview


SAP AG 2009

ITIL - IT Infrastructure Library

ITIL is best practice in IT Service Management.

It is managed by the UK Office of Government Commerce.

Worldwide, ITIL is the most widely used best practice for IT Service Management.

ITIL includes specific guidance on Release Management which is part of the ITIL “Service Support” function.

The diagram here shows the Framework overview


SAP AG 2009

Other Useful Methods you may come across

Six Sigma - a process improvement methodology to systematically improve processes by eliminating defects

to create new processes in a way that results in a more predictable, mature and defect-free performance

SAP’s Business Value Assessment Methodology SAP’s end-to-end value selling process – it focuses on assessment of business

drivers and ‘pain points’, business case development, and roadmap creation

SAP’s Accelerated SAP (ASAP) – implementation methodology for SAP A roadmap to develop a program for a multi-site deployment of SAP

IBM Rational SUMMIT Ascendant It provides processes, practices, and guidance on all aspects of program

management.

Maintained by Price WaterhouseCoopers Consulting and are now part of IBM's Rational brand

Deloitte Industry Print Provides detailed process maps and leading practices for individual industries,

allowing companies to document and redesign their business processes without having to start from scratch. Those customized maps can then be used to link business processes with SAP transactions and reports.


SAP AG 2009

Summary

This is the end of the Migration Planning Phase

You should now understand how to develop : A Detailed Implementation and Migration Plan

The next phase is Implementation Governance

At this point, the Enterprise Architect hands over the actual implementation of the programmes, projects and work packages to others who are expert in this field

The Enterprise Architect must now turn attention to governance of the implementation to ensure that the TO-BE Architecture Vision is implemented in line with the principles, requirements, and concerns that have been used


SAP AG 2009

Unit 10

Phase G: Implementation Governance

Phase H: Architecture Change Management



SAP AG 2009

SAP EAF Phase G and H: Implementation Governance

Contents:

Introduction to Implementation Governance

SAP EAF Extension

Introduction to Architecture Change Management


SAP AG 2009








SAP AG 2009

Lesson Objectives


Why Implementation Governance is crucial to manage the baselinedArchitecture from the previous phases

How Change Management processes need to be implemented to ensure this happens

How TOGAF™ focuses on project-specific governance

Unit 11 will go into more depth on this topic.


SAP AG 2009

Framework Overview

EnterpriseContinuum

ReferenceModels

CapabilityFramework

IterativeADM

ADM Guidelines&

Techniques



TOGAF™ 9.0




SAP EAF Extensions


SAP ContentTools

SAPImplementation

Tools

EA ModelingTools







In this Unit we are going to focus on the Implementation Governance


SAP AG 2009



Usage Guidelines









Case Study Material










(App & Data)


























Environment

106: IT Governance

Review


Assessment





Architecture

Resource Base






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










Guidelines



Guidelines


709: SAP Glossary



We will go through the narrative in detail


SAP AG 2009



SAP EAF Extensions



SAP AG 2009

Implementation Governance Phase - Overview

The Implementation Governance phase is about ensuring that change activity complies with the principles, models, standards and guidelines identified within the architecture.

Implementation Governance also provides a mechanism for bottom-up architecture evolution and provides a path for issue escalation.


What is the Implementation Governance phase about?

This phase is to ensure that all change activities comply with the principles, models, standards and guidelines established within the architecture

It provides a mechanism for bottom-up architecture evolution

It provides a clear part for issue escalation and their resolution

Implementation governance concerns itself with the realisation of the architecture through change projects. It is about the mechanisms and controls that should be in place to make sure the project is implemented according the architecture delivered in phase B, C and D.


SAP AG 2009

Implementation Governance – Main Objectives

To formulate recommendations for each implementation project

To govern and manage an Architecture Contract covering the overall implementation and deployment process

To perform appropriate governance functions while the solution is being implemented and deployed

To ensure conformance with the defined architecture by implementation projects and other projects

To ensure that the program of solutions is deployed successfully, as a planned program of work

To ensure conformance of the deployed solution with the Target Architecture

To mobilize supporting operations that will underpin the future working lifetime of the deployed solution



SAP AG 2009

Implementation Governance – Approach

Deploy the Target Architecture as a series of transitions. Each transition represents an incremental step towards the target, and each delivers business benefit in its own right

Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase

Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap

Follow the organization's standard for corporate, IT, and architecture governance

Use the organization's established portfolio/program management approach, where this exists

Define an operations framework to ensure the effective long life of the deployed solution

Establish the connection between architecture and implementation organization through the Architecture Contract



SAP AG 2009

Implementation Governance Phase - Inputs and Outputs

ImplementationGovernance

Phase






Architecture Contract (signed)

Compliance Assessments

Change Requests

Architecture-compliant solutions



Architecture Vision


Architecture Definition Document

Architecture Requirements Specification

Architecture Roadmap



Architecture Contract



SAP AG 2009

TOGAF™ Implementation Governance Phase -Overview of Steps

Perform Post-Implementation Review and Close the Implementation

Perform Enterprise Architecture Compliance Reviews

Implement Business and IT Operations

Confirm Scope and Priorities for Deployment with Development Management

Identify Deployment Resources and Skills

Guide Development of Solutions Deployment

TOGAF™



SAP AG 2009



Review migration planning outputs and produce recommendations ondeployment

Identify enterprise architecture priorities for development teams

Identify deployment issues and make recommendations

Identify building blocks for replacement, update, etc.

Perform gap analysis on enterprise architecture and solutions framework

Produce a gap analysis report


Identify system development methods required for solutions development

Ensure that the systems development method enables feedback to the architecture team on designs



SAP AG 2009



Document Architecture Contract

Obtain signature from all developing organizations and sponsoring organization

Update Enterprise Continuum directory and repository for solutions

Guide development of business & IT operating models for services

Provide service requirements derived from enterprise architecture

Guide definition of business & IT operational requirements

Carry out gap analysis between the Solution Architecture and operations

Produce Implementation Plan


Review ongoing implementation governance and architecture compliance for each building block

Conduct post-development reviews

Close development part of deployment projects



SAP AG 2009



Carry out the deployment

Publish new Baseline Architectures to the Architecture Repository and update other impacted repositories, such as operational configuration management stores


Conduct post-implementation reviews

Publish reviews and close projects

Based on TOGAF™ ™ 9 materials licensed from The Open Group Copyright © 2009


SAP AG 2009

SAP EAF Extensions


SAP EAF Extensions


Now we can look at the EAF specific extensions


SAP AG 2009


Implementation

Governance

PhaseSAP EAF Business Architecture Narrative


SAP EAF Implementation Governance Phase Worksheet

SAP EAF Implementation Governance Narrative


SAP EAF Glossary

Additional Inputs

Additional outputs

Additional step(s)

Impact Analysis

Review Project Approach and Output


SAP AG 2009

Implementation Governance Phase - TOGAF™ and SAP EAF

SAP EAF Extensions

Review Project Approach and Output







TOGAF™


SAP AG 2009

Implementation Governance Phase - SAP EAF Extensions

In addition to the guidelines given in TOGAF™ SAP EAF provides

Architecture to Solution Handover Checklist Projects and programs will need to follow the architecture

roadmap/standards/guidelines during the actual design of the solution.

The checklist covers the hand-over from architecture to solution implementation when implementing packages and or packaged services

Package and Package Services Compliance Review Checklist

A specific checklist based on the TOGAF™ checklist


SAP AG 2009



SAP EAF Extensions



SAP AG 2009

Architecture Change Management Phase - Overview

The Architecture Change Management phase is about ensuring that architecture assets are maintained and identifying the impacts that result from architecture change.

Architecture Change management considers top-down changes to strategy, bottom-up changes filtering through the implementation governance process and external market factors.


What is the architecture change management phase about?


SAP AG 2009

Architecture Change Management - Main Objectives

To ensure that baseline architectures continue to be fit-for-purpose

To assess the performance of the Enterprise Architecture itself and make recommendations for change

To assess changes to the framework and principles set up in previous phases

To establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G

To maximize the business value from the architecture and ongoing operations

To operate the Governance Framework



SAP AG 2009

Architecture Change Management - Approach

Manage changes to the architecture in a cohesive and architected way to ensure that the architecture achieves its original target business value

Monitoring governance requests, new developments in technology, and changes in the business environment

Update enterprise architecture in a flexible manner according to business growth and evolvement

Perform capacity measurement and give recommendations for planning (e.g. solution architectures might not scale)

The governance body must establish criteria to judge whether a Change Request warrants just an architecture update or whether it warrants starting a new cycle of the Architecture Development Method (ADM).



SAP AG 2009

Architecture Change Management - Drivers

New technology reports

Asset management cost reductions

Technology withdrawal

Standards initiatives

Business-as-usual developments

Business exceptions

Business innovations

Business technology innovations

Strategic change


SAP AG 2009

Change Severity Checklist

Is it a Simple Change?

Does it only impact only one stakeholder class / low no’s of people ?

E.g. New financial accounting rules applied to General Ledger

Does it only impact one domain?

E.g ten operating systems impacted reduced – but no change to application or business architecture

Does it involve adding or removing small numbers of metamodel object instances in the same domain

E.g. adding one or two new Data Entities in Data Architecture domain, or a new process in the Business Architecture domain ?

Does it impact the updating of metamodel attributes alone?

E.g. the name or version of a technology component

If yes - progress via normal ITIL Change Management processes

Then Enterprise Architect updates Architecture Model as part of day-to-day operations


SAP AG 2009


Is it an Incremental Change?

Does it only impact one stakeholder class?

Does it impact less than two domains?

E.g a new operating system upgrade means the application will need to be upgraded and redesigned?

Does it involve adding or removing small numbers of metamodel object instances in two domains?

E.g. adding one or two new Data Entities in Data Architecture domain, plus new business processes in the Business Architecture domain ?

Does the change involve changing the Technical Reference Model or an existing Building block that has already been re-used in a number of instances?

Is the change significant enough to require retraining of staff?

If yes - progress via Architecture Change Management

Ensure changes are resolved across Business, Information Systems and Technology Architecture Domains

Then update Architecture Models


SAP AG 2009


Is it a Complex Change? – progress via new architecture engagement by following the SAP EAF process again

Are there significant new Business Drivers, Goals and Objectives that mean the Business Strategy is changing?

Has a significant event like a Merger/Acquisition or Divestiture occurred that will impact the architecture of all domains?

Are there new technology developments that have significant business user impact? E.g. availability of affordable mobile computing in a wireless mode

Are there new technology components and guidelines for use in deployment of the architecture ? For example, web service standards

Does the change impact two stakeholder classes or more?

Does it impact two domains or more?


SAP AG 2009


Does it involve adding or removing large numbers of metamodel object instances in more than two domains ?

E.g. adding one or two new Data Entities in Data Architecture domain, plus new business processes in the Business Architecture domain, plus new Technology classes in the Technical Reference Model that impacts the Technology Architecture?

If yes - progress via new architecture engagement

Following the SAP EAF process again

Enterprise Architect needs to agree and scope a new Request for Architecture Work as detailed in Unit 3 – Architecture Vision and Unit 12 – Using SAP EAF in Architecture Engagements


SAP AG 2009

Architecture Change Management - Inputs and Outputs

ArchitectureChange

ManagementPhase






Architecture Contract (updated)



New Requests for Architecture Work



Architecture Vision

Architecture Definition Document

Architecture Requirements Specification

Architecture Roadmap

Change request (business)

Change request (technology)

Architecture Contract

Change request (lessons learned)




Changes to architecture framework

Architecture updates


SAP AG 2009

TOGAF™ Architecture Change Management Phase -Overview of Steps

Manage Governance Process

Provide Analysis for Architecture Change Management

Develop Change Requirements to Meet Performance Targets

Establish Value Realization Process

Deploy Monitoring Tools

Manage Risks

TOGAF™

Activate the Process to Implement Change


SAP AG 2009


Establish Value Realization Process

Influence business projects to exploit the enterprise architecture for value realization (outcomes).

Deploy Monitoring Tools

Monitor technology changes which could impact the Baseline Architecture

Monitor business changes which could impact the Baseline Architecture

Business value tracking; e.g., investment appraisal method to determine value metrics for the business objectives

Monitor enterprise architecture capability maturity

Track and assess asset management programs

Track the QoS performances and usage

Determine and track business continuity requirements



SAP AG 2009


Manage Risks

Manage enterprise architecture risks and provide recommendations for IT strategy

Provide Analysis for Architecture Change Management

Analyze performance

Conduct enterprise architecture performance reviews with service management

Assess Change Requests and reporting to ensure that the expected value realization and Service Level Agreement (SLA) expectations of the customers are met

Undertake a gap analysis of the performance of the enterprise architecture

Ensure change management requests adhere to the enterprise architecture governance and framework



SAP AG 2009


Develop Change Requirements to Meet Performance Targets

Make recommendations on change requirements to meet performance targets and development of position to act

Manage Governance Process

Arrange meeting of Architecture Board (or other Governing Council)

Hold meeting of the Architecture Board with the aim of the meeting to decide on handling changes (technology and business and dispensations

Activate the Process to Implement Change

Produce a new Request for Architecture Work and request for investment

Ensure any changes implemented in this phase are captured and documented in the Architecture Repository



SAP AG 2009

Summary

This is the end of the Implementation Governance and Architecture Change Management Phases

You should now understand : Why Implementation Governance is

crucial to manage the baselinedArchitecture

How Change Management processes need to be implemented to ensure this happens

Enterprise Architecture Governance is a wider topic to be covered in the next Unit


We reviewed the Architecture Change Management Phase and you should be familiar with the following..…

In the next unit we will cover Enterprise Architecture Governance in more detail


SAP AG 2009

Unit 11 - Enterprise Architecture Governance



SAP AG 2009

Contents:

Putting Implementation Governance into context

The Five Dimensions of EA Governance

How the SAP EAF helps EA Governance


Enterprise Architecture Governance


SAP AG 2009








SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand how:

How TOGAF™ focuses on project-specific governance

The wider scope of Enterprise Architecture Governance

Enterprise- wide Architecture Governance is about managing and controlling architectures at an enterprise-wide level

Failure to consider Governance will mean all your good architecture work will be in vain.

An EA Governance Framework is made up and what it needs to contain


SAP AG 2009




In Unit 11, we will break out of the TOGAF™ ADM process and explain what exactly Enterprise Architecture Governance is.

We will explain why it is important and why we need it

We will explain The Five Dimensions of Governance – five key concepts to implement in your organization if EA Governance is to succeed


SAP AG 2009

Implementation Governance and Architecture Change Management

TOGAF™ Phases G and H are part of a wider EA Governance Framework

TOGAF™ Implementation Governance covers:

Governing the projects identified in Phase E using architecture contracts

It is essentially a project start-up process

But what about projects already started ?

But what about projects not part of your strategic architecture program ?

Are architecture contracts workable ?

Do you have a defined Solution Lifecycle ?

Wider Architecture Governance is key

TOGAF™ Architecture Change Management covers:

Change management for the new architecture baseline post Phase F

The process by which you determine whether there’s a valid change or not

How do you know all changes are being tracked ?

It relies on a wider Architecture Governance framework

It is important to realize that TOGAF™ does not provide the whole solution for Enterprise Governance in an organization ; a wider framework is needed.


SAP AG 2009

What is Enterprise Architecture Governance? 1/2

EA Governance ensures Business-IT alignment

“The practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level”

As defined by The Open Group

There are many definitions of “governance” from Oxford English Dictionary to Wikipedia…..

This is the Open Group definition of Enterprise Architecture Governance

Management and control of architecture at the enterprise level.


SAP AG 2009

What is Enterprise Architecture Governance? 2/2

Enterprise Architecture

Business Strategy and Planning

Research and

Innovation

Programs and Projects

ServiceDelivery

Landscape

Provide Evidence of Architecture Compliance

Support and Align Projects to

Strategic Roadmap

Set Strategy and Vision Support Effective

Governance

Monitor Obsolescence

Learn fromOperations

Support and Model

IT Landscape

Align innovation to strategy, using

“proof of concepts”

Monitor Technology Innovations and Align to Vision

EA Governance does not and cannot operate in isolation

In order for EA Governance to perform management and control – it needs to work closely with other organization functions – otherwise it becomes overly bureaucratic

EA Governance typically does not operate in isolation, but within a hierarchy of governance structures, which, particularly in the larger enterprise, can include all of the following :

Corporate Governance

Information Technology (IT) Governance

Architecture Governance

The Business Strategy process sets a vision that EA will align to – the EA function then ensures that business / information system / technology architecture are aligned to that.

The EA Function ensures projects comply with the architecture and its principles

Projects need to provide quality deliverables to ensure such compliance is clear

EA defines the Service Delivery landscape and monitors obsolescence – and of course strategic service issues must be taken onboard by the EA Function

EA has a responsibility to keep informed of new innovations – and help the business – via proof of concepts – this enables early engagement.


SAP AG 2007

Why is EA Governance important? 1/2

Because this…………..“

Without your hard efforts to design and build a new solution will gradually be eroded by tactical changes


SAP AG 2007

Why is EA Governance important? 2/2

Will turn into this……….

Signed

One Frustrated CEO

“ “


SAP AG 2007

Symptoms of Architecture Governance breakdown

Projects are initiated before we realise it……the solution has been chosen by a senior manager before the users’ requirements have been confirmed“ “

Our budget round for next year is made up of a series of “good ideas” that aren’t aligned to our corporate business strategy“ “

Projects end without delivering their promised benefits and leaving duplicated processes and systems……everything gets more complex“ “

We have defined our TO-BE Information Architecture and a set of Design Standard, but no-one takes any notice of them………..“ “

We have 3 ERP systems, and 10 flavors of UNIX to support…….and our three main Operational systems will soon be out of extended maintenance“ “

Our solutions are tactical rather than aligning to strategic objectives. This is leading to a loss of economies due to duplication and little if any reuse.“ “

What happens if there is no Enterprise Architecture governance ?

Nobody checks if projects did what they set out to do

Nobody checks that the design was followed

Nobody checks that tactical projects don’t start

Nobody checks next years plan is aligned

Nobody checks the spread of technology duplication

Nobody checks solutions follow the strategy which means strategic systems are not reused


SAP AG 2009

How do I implement Enterprise Architecture Governance?

All these elements are critical for successful Enterprise Architecture Governance

Implement a system of controls over architecture components and activities

Organization and Roles

Ensure the effective introduction, and evolution of architectures

Processes

Implement a system of compliance with standards

Templates and Standards

Establish effective management of processes

Tools

Implement a monitoring framework to show performance

KPIs

We can stop these problems happening by :

Setting up a Governance organization and relevant roles – to monitor and control creation of architectures

Setting up processes so the key aspects of architecture are managed and controlled

Setting up standards and templates that projects can follow so its clear from the start what needs to happen

Provide tools to effectively manage the process as generally in any organization there are many programs and projects to govern ; and not enough time or people to do it

Set up a monitoring framework as there will be pressure to prove its working from senior management


SAP AG 2009





SAP AG 2007

Ent

erpr

ise

Arc

hite

ctur

eP

roje

cts

and

Pro

gram

s

Solution Implementation Lifecycle

The Five Dimensions of Governance

Governance Framework

2. Processes 3. Standards and Templates

1. People and organization

Business Strategy and Planning

5. KPIs and Monitoring

4. Tools

Res

earc

h a

nd

In

no

vati

on

Ser

vice

Del

iver

yL

and

scap

e

There are five key dimensions we need to examine :

People and Organisation

Processes

Standards

Tools

KPIs and Monitoring


SAP AG 2009

1. People and organization

Design Authority

IT Strategy Board

ProgramDesign

Authority

Project A

ProgramDesign

Authority

Project B

Project C

Project D

Service Delivery

Management

ProgramManagement

Office

IT Strategy Board

sets the overall governing IT strategy

The Design Authority responsible for governing

and maintaining the architecture that delivers the strategy

co-ordinates, shapes and reviews all programs

Program Design Authorities delegated responsibility

for shaping and review an individual program

Projects use their own staff to

ensure their own developments are controlled

The overall structure generally acts under the direction of the IT Strategy Board

A Design Authority or Architecture Governance Board is established

Due to the breadth of programs and projects in an organization ; delegated responsibility may be passed down to Program Design Authorities

Projects are then aligned to programs


SAP AG 2009

1. Terms of Reference for the Design Authority

Early Design Direction Outline and Detailed Solution

Design Governance

Update Enterprise Architecture to

deployed systems, gather best practice

Provide early design direction to programs / projects prior to feasibility stage

Support the development of designs throughout the project lifecycle Ensure that dependencies and interfaces across projects and

between individual programs are proactively managed and resolved Be the next escalation point to resolve issues that could not be dealt

with at the Program Design Authority level

The key terms of reference for a Design Authority are to provide early design direction to programs and projects

It is more difficult to influence a program or project once it is up and running, once budgets have been set, and once expectations have been set

The Design Authority should not be purely a “gate” to pass through.

The EA Governance process should also involve a balanced proactive, consultative approach via the Program Enterprise Architects and Solution Architects

Checkpoints are however needed through the solution lifecycle to ensure outline and detailed designs are tracked

An end of project review is required

The Design Authority provides a resolution point for architectural dependencies

The Design Authority provides an escalation point for program DA’s


SAP AG 2009

1. People and Organization

Design Authority

Enterprise Architect 2

IT Strategy Board

Infrastructure Architect

Program Design Authority

Project A

Solution Architect 1

Principal Architect

BusinessAnalyst 1

Program Design Authority

Principal Architect

CIO Service Manager

BusinessChampions


Service Manager

Project B


BusinessAnalyst 2



Project C


BusinessAnalyst 3

Project D


BusinessAnalyst 4

CIO chairs the IT Strategy Board

Principal Architect chairs the Design Authority

Enterprise Architects aligned to programs and

assurance the program architecture

specialize in Business, Application, Data or Technology

Solution Architects aligned to projects and assure

the solution architecture

Other roles play their part : Business Analysts or Domain

Experts

Service Manager

Infrastructure Architects


SAP AG 2009

2. Processes - Governance according to COBIT 1/3

COBIT is an IT governance framework and supporting toolset from the IT Governance Institute® (ITGI)

http://www.isaca.org

IT G

ove

rnan

ceIn

sti

tute

® (

ITG

I)

Enterprise Architecture Governance is a subset of wider IT Governance

There is already a standard framework for IT Governance we need to be aware of


SAP AG 2009


IT G

ove

rna

nce

Inst

itu

te®

(IT

GI)


SAP AG 2009


ACQUIRE AND IMPLEMENT

SelectStrategic

Technology

ProduceOutlineDesigns

ProduceDetailedDesigns

PLAN ANDORGANIZE

StrategicSupplierWatch

StrategicTechnology

Watch

MaintainIT

Vision

Maintain Enterprise

Architecture

AssureDesigns

DemonstrateInnovationMONITOR

AND EVALUATEMonitor

EAKPIs

DELIVER AND SUPPORT

MaintainSolutionResource

Base

SolutionHandback

Monitor Operations +

Obsolescence

If we examine the key COBIT functions and processes…

We can identify the specific EA functions and processes that are part of this


SAP AG 2009

2. Example TO-BE Level 0 Process Map

Enterprise ArchitectureGovernance

Develop a set of integrated EA Governance processes

SelectStrategic

Technology

StrategicSupplierWatch

SupplierSelection

StrategicTechnology

Watch

MaintainIT

Vision

Maintain Enterprise

Architecture

BusinessRoadmap

BusinessVision

ProduceOutlineDesigns


AssureDesigns

ProjectLifecycle

ProduceDetailedDesigns

Testing

BusinessEngagement

DemonstrateInnovation

ServiceDelivery

MaintainSolutionResource

Base

SolutionHandback

Monitor Operations +

ObsolescenceTOGAF™

Phase H

TOGAF™Phase

G

Approved DesignsAlign Vision Align Roadmap

High Level Test Strategy

Requirements Agreed

Approved DesignsNew Opportunities

Service Acceptance

So what sort of processes do we need ?

A process to ensure that vision and architecture remain aligned

A set of processes to monitor project lifecycle – outline and detailed designs – link to requirements management – design will help testing too

A process to ensure that as solutions are built and delivered – the Architecture Resource Base is updated

A process to ensure new business/technology ideas are put together with the business to promote innovation

A process to select strategic technology


SAP AG 2009

2. Processes

In order for EA Governance to function efficiently, we need:

A clear set of business processes linked to existing programs and projects

Which roles perform what tasks and when

A clear set of task descriptions

What happens at each process step

A clear set of RACI matrices

Who is Responsible, Accountable, Consulted, Informed

A set of review checklists for key design artifacts

We can setup a new organization but we need clear processes for people to follow

This means we need to develop a clear set of process maps, and task descriptions – to define who does what and when

A RACI matrix for each process defines which roles are “responsible” , “accountable”, “consulted” and “informed”.

A set of standard checklists ensure EA Governance is always consistent


SAP AG 2009

3. Standards and Templates

Standards ensure : Enterprise complexity is reduced Solutions can be maintained

efficiently Business and IT are aligned

Templates ensure : the right information is available the right quality is produced consistency between projects

Typical standards needed include: Business Process Standards

How are processes to be modeled and documented?

Design Standards How will we use UML ?

Infrastructure Standards What infrastructure technology will we

standardize on

Typical templates needed include: Statement of Opportunity

What’s the problem?

Outline Design How do I intend to build it?

Detailed Design How am I actually building it?

Support Model How will what is built be supported?

Typically a project will want to know with what it needs to comply with

Standards ensure a common approach across the whole enterprise

Templates ensure the right information is captured consistently


SAP AG 2009

4. Tools









Organisation Unit

Goal

Objective


(Business, Information System) ServiceServices are Contained in Core , Business / IS split supports the Business / IT A lignment Extension

Function

Process

Actor

Role




Data Entity



Extension


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Opera tes in

Is Hostedin


Encapsulates

Resides within

SuppliesIs Supp lied By

Is Realised by Real ises

Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedth rough

Contains

Co

nta

ins

Co

nta

ins

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Participatesin


Performstask in

Generates, Resolves

Produces

Is Produ cedbyIs owned by

Owns


Accesses

Can beaccessed by


Su pports, Isrealised by

Is bounded by


Produces

Is Producedby

Involves

Participatesin

Involves


Generates, Resolves

Is Resolved by


Resolves


Orch

estrates,

decom

poses


Isgu

idedb

y

Governs, Measures



Is tracked against

Sets perfor mancecriteria for


Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is real isedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby

Is Suppl ied or Consumed by










Organisation Unit

Goal

Objective


(Business, Information System) ServiceServices are Contained in Core , Business / IS split supports the Business / IT A lignment Extension

Function

Process

Actor

Role




Data Entity



Extension


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Opera tes in

Is Hostedin


Encapsulates

Resides within

SuppliesIs Supp lied By

Is Realised by Real ises

Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedth rough

Contains

Co

nta

ins

Co

nta

ins

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Participatesin


Performstask in

Generates, Resolves

Produces

Is Produ cedbyIs owned by

Owns


Accesses

Can beaccessed by


Su pports, Isrealised by

Is bounded by


Produces

Is Producedby

Involves

Participatesin

Involves


Generates, Resolves

Is Resolved by


Resolves


Orch

estrates,

decom

poses


Isgu

idedb

y

Governs, Measures



Is tracked against

Sets perfor mancecriteria for


Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is real isedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby

Is Suppl ied or Consumed by


Tools are needed to :

Enable easy maintenance of architecture as the business and IT landscape changes

Efficient share architecture knowledge sharing across the whole organization






Tools help prevent :

Proliferation of non-standard artifacts

Unmaintainable Visio and Excel files

Knowledge locked away in only one person

In any organization, there are a large number of projects/architects/stakeholders

Architecture creates a wealth of useful and essential material

The right people need quick access to it and the right people need to control its creation

For this to occur we need tools

Tools ensure architecture models are easier to maintain – any changes can be made once and applied in all artifacts – instead of needing to update 100s of documents

Tools ensure up-to-date architecture models are shared effectively – this helps acceptance

Reuse of models is easier – it is natural to reuse a model if one knows it exists in the resource base, as opposed to a model that is tucked away in a filing cabinet or on somebody’s PC


SAP AG 2009

4. Common objects promote common standards

EA Tools model the enterprise, and promote common models based on a single source of the truth

Metamodel


Database Object

Database Object

DatabaseObject

Database Object

?

Reference Models



and Diagrams

Stakeholder Views

Stakeholder


Architecture

Repository









Organisat ion Unit

Goal

Objective



Function

Process

Actor

Role




Data Entity



Ex tens ion


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Host edin


Encapsulates

Resideswithin



Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedt hrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin


Performstask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by


Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby











Organisat ion Unit

Goal

Objective



Function

Process

Actor

Role




Data Entity



Ex tens ion


Data Extension









Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Host edin


Encapsulates

Resideswithin



Operateson

Is processedby

Provides, consumes


Resides within

Is implemented on


Is realisedt hrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin


Performstask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by


Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by



Orchestrates,

decompo

ses


Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises


Applies to

Meets

Applies to Meets

Is Performedby



If we model the enterprise using common terminology and a common metamodel

We can implement our Architecture Repository in a tool

The tool can provide standard models, catalogs, matrices and diagrams to stakeholders


SAP AG 2009

5. KPIs and Monitoring 1/2

Key Benefits of Enterprise Architecture

Helps achieve business strategy


More-consistent business processes and information across business units





Less complexity

Less IT risk

How do we know its working or not ?

How do we measure the benefits we are creating ?

How do we convince the sceptics that it’s not a pointless exercise?

The Final 5th dimension is KPIs and Monitoring

We need to be able to prove tangible benefits


SAP AG 2009

5. KPIs and Monitoring 2/2

% AS-IS and TO-BE architectures complete# of Implementation and Migration Plans# of Projects engaging design assurance# of Programs with Enterprise Architects

EA Coverage

# Solution designs approved/rejected# and frequency of design reviews# Architecture Change Requests# Programmes with Enterprise Architects

EA Processes # Enterprise Architects in place# Enterprise Architects trained# Enterprise Architects certified# Approved standards in place

EA Presence

# Projects initiated linked to drivers/goalsBenefits identified of initiated Projects Ease of access to information(“Boundaryless Information Flow”)# Process improvements identified

Business Benefits IT cost savings achieved through EA# Applications retired/consolidated# Technologies retired/consolidatedSimplification of IT landscape

IT Benefits

In considering KPIs, we need to ensure we have a balanced approach.

Kaplan and Norton (1992) introduced the concept of a “balanced scorecard” so that we do not focus on one element at the expense of all others

The idea is that KPIs and Monitoring processes should balances the financial perspective with customer, process, and employee perspectives

Typical focus areas are :

What Business Benefits have we generated from Enterprise Architecture ?

What IT Benefits have we generated from Enterprise Architecture ?

How complete in scope is the Enterprise Architecture ?

How effective are the EA Processes ?

Do we have the right Organization, People and Roles in place to deliver ?


SAP AG 2009

What happens if you follow the 5 Dimensions ?

There are no surprises….

Programmes and Projects are aligned to the Business Strategy

The organizations requirements and technical constraints are met

When solutions are assembled

Everything is in place at the right time

The right people are involved, as early as possible

When projects are initiated

Architecture & design risks spotted early in the project

Issues trapped quickly

We develop and maintain a successful Enterprise Architecture which means

The problem is understood

The solution solves the problem

How the solution will work is understood

Elements of the solution can be reused to build other solutions

What does success look like ?


SAP AG 2009

Summary

The challenge in building a successful Enterprise Architecture is to keep people –including both IT and business-side staff – focused on the architecture goals…….

for that to happen, Governance is the critical success factor.

You should now understand : How TOGAF™ focuses on project-specific

governance The wider scope of Enterprise Architecture

Governance That Enterprise- wide Architecture Governance

is about managing and controlling architectures at an enterprise-wide level

Failure to consider Governance will mean all your good architecture work will be in vain.

Solutions will become tactical, unaligned to strategic objectives.

Loss of efficiency as re-use wanes and duplication increases

An EA Governance Framework contains 5 key dimensions : Organization, Process, Standards, Tools and KPIs.

EA Governance is about managing and controlling your architecture

Once you have spent thousands of dollars/euros creating your architecture – you could waste it if it is not effectively controlled

It is a key technique in keeping the business and IT aligned

“The key to enterprise architecture (EA) effectiveness is governance, and the key to governance is intervention in IT projects. EA effectiveness is thus tied to project governance. Project governance is also key to aligning IT activity to business goals, cost control and providing IT value. EA efforts need to implement processes to maintain awareness of project initiation and to introduce design scrutiny and guidance in a systematic fashion. However, creating multiple non-integrated processes for project governance to serve the various goals will introduce an intolerable level of bureaucracy. Rather, what is needed is an integrated approach to project governance that will encumber project delivery as little as possible while addressing architecture, alignment and cost control requirements. IT organizations that do not implement effective project governance will be unable to achieve high level of architecture compliance and will have no effective means to manage to business goals or to attain a meaningful degree of cost control”

Project Governance and Enterprise Architecture Go Hand in Hand - Gene Leganza (Giga Research, 2003)



SAP AG 2009

Unit 12 - TOGAF™ and SAP EAF for Specific Engagements


We have learned and reviewed quite a bit about EA discipline and TOGAF™ in the past 2 or 3 days

In this Unit, we are going to look at the practical side of TOGAF™ and we are going to focus on “How we can use TOGAF™ for Architecture Engagements”.


SAP AG 2009

Using TOGAF™ for Specific Engagements

Contents:

Starting Architecture Engagements

Architecture Context in TOGAF™

Understanding the Type of Engagement



SAP AG 2009








SAP AG 2009

Lesson Objectives


The TOGAF™ ADM process and its limitations in engagement management

How TOGAF™ handles risk management


How to use TOGAF™ successfully in engagements


SAP AG 2009





Risk Management in TOGAF™


SAP AG 2009


So now you know all the steps Just follow the steps ….its easy

No…not that easy…this is the real world What if the customer has no business strategy

or vision ? What if the information is not available ? What if you can’t speak to the right people ?

Consider the risk to the engagement Value to the customer declines Their satisfaction with the end product will

decline

So well I have sat through a 5 day course on TOGAF™, read through a lot of material and now I am going to engage with a customer and simply follow the steps…

In real world, it is not that easy, simple and straight forward

Quite often, the customer may not have a well defined business strategy or vision

The information may not exist or readily available

You may not get access to speak to the right people

As you all are aware, the risk to the engagement is huge

The value we provide to our customer declines and the customer satisfaction will be impacted


SAP AG 2009

TOGAF™ and Architecture Engagements 1/2

TOGAF™ doesn’t cover these issues It provides a template for a Request for

Architecture Work from a customer To formally document :

Organization sponsors Organization's mission statement Business goals (and changes) Strategic plans of the business Time limits Changes in the business environment Organizational constraints Budget information, financial constraints External constraints, business constraints Current business system description Current architecture/IT system description Description of developing organization Description of resources developing organization

has available

Again TOGAF™ has served a mother for very many frameworks but it clearly has some gaps

TOGAF™ considers “Request for Architecture” work as a major input in to each of the phases

TOGAF™ merely provides the content for “Request for Architecture” as only bullet items without any description or examples


SAP AG 2009

TOGAF™ and Architecture Engagements 2/2

TOGAF™ provides the format for a Statement of Architecture Work

To formally document : Statement of work title Project request and background Project description and scope Architecture vision Managerial approach Change of scope procedures Responsibilities and deliverables Acceptance criteria and procedures Project plan and schedule Support of the enterprise continuum Signature approvals

This is formally signed off at the end of Phase A-Architecture Vision

But we may have spent weeks of effort up until that point……….the scope could have grown significantly

The second is “SOW” as a major output from Phase A

Again here TOGAF™ identifies the content as broad bullet items without description or example

TOGAF™ requires SOW to be formally signed off at the end of Phase A

Note that we need to define acceptance criteria – SAP EAF provides a list of completion criteria at the end of each phase – but does not define the level of detail or accuracy required – this will depend on the engagement, resource, time and priorities


SAP AG 2009







SAP AG 2009



Initial Iteration

To establish the approach, principles, scope and vision for the engagement

This iteration comprises a pass through the Preliminary and Architecture Vision phases of the ADM

This is necessary as Framework and Principles may need to be modified once the Vision is completed

Gain an early understanding of key issues, goals, and risks

Two key steps in SAP EAF need to be considered

As we have seen in the past two days, EAF classifies the TOGAF™ wheel as cross-phased four different iterations

The first iteration, “Architecture Context” comprises Preliminary and Vision phases

This iteration focuses on establishing approach, principles, scope and vision for the engagement

The first iteration is a pass through these two phases as principles need to be revised/modified once the vision phase is completed

The context iteration is to gain an early understanding of key issues, goals and risks

There are two key steps in this iteration that are described in “Tailoring guide” and “Engagement Initiation guide”


SAP AG 2009

Understand the Customer’s Requirements early

Determine EA Maturity

DetermineEngagement Shape

SelectTOGAF™Extensions

DetermineStandard Terminology

DetermineMetamodel Structure

DetermineintegratedProcesses

Covered in the SAP EAF Tailoring Guide

Identifies EA maturity of theorganisation and how TOGAF™ isbest applied

Identifies how theEnterprise requirementsdiffer from the core SAP EAF positioning

Identifies whichcomponents of theframework are requiredwithin the enterprise

Maps TOGAF™standard terminologyto the terminologyalready in use withinthe enterprise

Allows for enterprisespecific modificationsto the TOGAF™content metamodel

Aligns TOGAF™processes withexisting enterpriseprocesses for projectsand governance

SAP EAF Tailoring Guide provides useful advice at this stage

Step 2 – Determine Engagement Shape

Discussion with stakeholders at this early stage are important to set the scope

Stakeholder View

PowerPoint /Excel

Top Down

EA

Full SAP

Light (good enough)

Rapid (1-3 weeks)

Tailored

Waterfall

Full Scope

Realization View

EA Tool

Bottom Up

Solution Architecture

Partial SAP

Full (detailed / comprehensive)

Larger project (1-3 months)

Template

Interative

Single Domain

The first key step spelled out in the Tailoring guide is to determine engagement Shape, in other words what kind of an engagement this is going to be

SAP EAF offers a slider tool to evaluate this with about ten parameters to consider

This slider tool will also help to understand how we started and how we are progressing through the engagement

The parameters range from stakeholder view vs realization view, desktop tool vs formal EA tool, top-down vs bottom up, EA vs Solution Architecture, Level of SAP footprint, Duration of the effort etc….


SAP AG 2009

Understanding the Vision early

DetermineEngagement Scope and Constraints

ConsiderBusiness and Technology Capability

Consider IT Governance

DetermineEngagement Schedule

RefineTOGAF™Tailoring

Finalize Visionand Statementof Work

Covered in Engagement Initiation Guide

Identifies architectureactivities to beconsidered within theengagement

Identifies Business and Technology focus areasin order to meet thearchitecture vision

Identifies operational implications of thedesired solution vision

Identifies theTOGAF™ iterationcycles, deliverablesand timing

Allows furtherframework tailoring to meet the specific needsof an architecture visionand set of stakeholders

Refine the vision and statement of workbased on what can bepractically achieved

SAP Engagement Initiation Guide also provides useful advice

Step 1 – Determine Scope and Constraints

Understand what is expected of the engagement

Understand the scope

Understand what will prevent you achieving the engagement goals

Horizontal Scope – Breadth of Coverage

Vertical Scope – How much detail

Time Period to Consider

Areas of the Enterprise to

Consider

Architecture Outputs to be

Created

The second key step spelled out in the SAP EAF Engagement Initiation guide is to determine engagement scope and constraints

The EA should clearly understand what is expected of the engagement and its scope

And more importantly the constraints that will prevent the EA from achieving the engagement goals


SAP AG 2009







SAP AG 2009

Managing Risks and Issues 1/2

Typical Risks or Issues for an EA engagement How much elapsed time is available for the engagement ? What customer resources are available – are the right

people available to start ? What vendor or consultancy resources are available? Do

they have appropriate skills i.e. EA and industry knowledge? What is the customer budget expectation ? What is the process for getting diary appointments with

senior staff? Is the right level of sponsorship available ? Will the right

people make the time for you or will you spend the first 6 weeks running after people?

How long will it take to get Statement of Work signed off? Will you be working at risk ?

When are the first deliverables needed by ? What is driving the production of Enterprise Architecture ? Are Enterprise, Enterprise Solution or Solution architectures

needed or not? What existing Enterprise Architecture artifacts are there ? Does the customer have a valid business strategy ? How

detailed or complete is it ? Does the customer have a TO-BE vision but want to know

how to get there?


SAP AG 2009

Managing Risks and Issues 2/2

Actively managing issues and risks A risk is something that might happen An issue is something that has already

happened Plan their mitigation and assign actions for

follow-up Review their status regularly (typically every

week) Do not simply “go through the motions”

There are several risks or issues to consider and let me point out a few of very important & critical ones here

Is the right level of sponsorship available ?

What is driving the production of Enterprise Architecture ?

Does the customer have a valid business strategy ? How detailed or complete is it ?

Does the customer have a TO-BE vision but want to know how to get there ?

Risks are something that is likely to happen and an issue is something that is already happened but hasn’t been resolved yet

Risks can either be addressed to eliminate them, mitigated with proper action or simply accepted

While issues must be resolved


SAP AG 2009

Risk Management according to TOGAF™

TOGAF™ describes two levels of risk that should be considered:

Initial level of risk: Risk categorization prior to determining and implementing mitigating actions.

Residual level of risk: Risk categorization after implementation of mitigating actions (if any).

The process for risk management consists of the following activities:

Risk classification

Risk identification

Initial risk assessment

Risk mitigation and residual risk assessment

Risk monitoring

Risk Management is an integral part of enterprise architecture.

Practitioners are encouraged to use their corporate risk management methodology or extend it using the guidance provided by TOGAF™

In the absence of a formal corporate methodology, enterprise architects can use the guidance provided by TOGAF™ as best practice



SAP AG 2009

TOGAF™ Risk Classification Scheme

TOGAF™ suggest combining effect and frequency to come up with a preliminary risk assessment

There are no hard and fast rules with respect to measuring effect and frequency. TOGAF™ provides guidelines based upon existing risk management best practices.


Effect could be assessed using the following example criteria:

Catastrophic infers critical financial loss that could result in bankruptcy of the organization.

Critical infers serious financial loss in more than one line of business leading to a loss in productivity and no return on investment on the IT investment.

Marginal infers a minor financial loss in a line of business and a reduced return on investment on the IT investment.

Negligible infers a minimal impact on a line of business' ability to deliver services and/or products.

Frequency could be indicated as follows:

Frequent: Likely to occur very often and/or continuously.

Likely: Occurs several times over the course of a transformation cycle (possibly once every 36 months).

Occasional: Occur sporadically (not more than once per year).

Seldom: Remotely possible and would probably occur not more than once in the course of the entire transformation.

Unlikely: Will probably not occur during the transformation effort.

Combining the two factors to infer impact would be conducted using a heuristically-based but consistent classification scheme for the risks. A potential scheme to assess corporate impact could be as follows:

…



…

Extremely High Risk (E): The transformation effort will most likely fail with severe consequences.

High Risk (H): Significant failure of parts of the transformation effort resulting in certain goals not being achieved.

Moderate Risk (M): Noticeable failure of parts of the transformation effort threatening the success of certain goals.

Low Risk (L): Certain goals will not be wholly successful.

These impacts can be derived using a classification scheme, as shown in the example here.

SAP AG 2009







SAP AG 2009

TOGAF™ and Architecture Engagements

TOGAF™ provides the format for a Statement of Architecture Work

To formally document : Statement of work title Project request and background Project description and scope Architecture vision Managerial approach Change of scope procedures Responsibilities and deliverables Acceptance criteria and procedures Project plan and schedule Support of the enterprise continuum Signature approvals

This is formally signed off at the end of Phase A – Architecture Vision

But we may have spent weeks of effort up until that point……….the scope could have grown significantly

The second is “SOW” as a major output from Phase A

Again here TOGAF™ identifies the content as broad bullet items without description or example

TOGAF™ requires SOW to be formally signed off at the end of Phase A


SAP AG 2009



Merging business services from multiple parties and removing duplication

Understanding the structure of the new organization in terms of business, data, applications and technology

Divestiture

Splitting business services between multiple parties

Understanding which parts of the business, data, applications and technology need to be transferred, segregated

Outsourcing

Transferring business services to a third-party

Understanding which functions, information and technology need to be changed





SAP AG 2009


Specific change events trigger organizations to adopt Enterprise Architecture

Legislation coming into force

New government legislation coming into force e.g. Data Protection Act (UK), Freedom of Information Act (US), EU directives on information privacy

Understanding which datasets, organizational roles and applications are affected

Technology Change

A vendor makes a significant change to its technology platform or ‘stack’e.g. SAP NetWeaver BPM, or a specific technology goes out of support

Understanding which applications, interfaces, and supporting infrastructure are affected, and how to maximize potential

Global Consolidation and Standardization, Cost Reduction

Understanding where processes and systems are duplicated and identifying where consolidation and standardization can occur

Despite the external and internal drivers for EA being compelling, specific events tend to trigger an organization's adoption of EA.

For example

A major change is required in business architecture (following a Merger/Acquisition or Divestiture)

A change in business strategy, goals and objectives requires a business change program to migrate to a new TO-BE state

A new technology becomes available that the organization wishes to capitalize on

New legislation coming into force drives changes in business processes, systems or data

Change drives the need for Enterprise Architecture as the organization needs to understand the impact of the change, and how it will facilitate the change


SAP AG 2009

Turning EA Triggers into TOGAF™ Process

Architectural Governance of Change Implementation

Architectural Definition of Bounded Change Initiatives

Architectural Definition of Foundational Change Initiatives

Architectural Portfolio Management of Projects

Architectural Portfolio Management of the Landscape

Supporting Business Strategy

TOGAF™ Engagement TypeEA Trigger TOGAF™ ADM Iteration



Transition Planning

Architecture Definition AS-IS First


Architecture Definition TO-BE First

Divestiture

Outsourcing of Business ProcessShared Services

Competitive Environment / Innovation / New Goals and

Objectives

Technology Change

Globalization / Consolidation /Cost Reduction

Need for IT Transformation / Consolidation

Need to improve Service Levels

EA Triggers translate into TOGAF™ Engagement Types

A specific EA trigger would lead to a specific TOGAF™ Engagement Type

For example, the need for better IT Service Management could translate into “Architecture Portfolio Management of the IT Landscape”

For example, a Merger/Acquisition/Divestiture could translate into “Architectural Definition of Foundational Change Initiatives”


SAP AG 2009

TOGAF™ Engagement Classes and Types 1/2

Enterprise Architecture can assist an organization in a number of different contexts.

IDENTIFICATION OF REQUIRED CHANGE DEFINITION OF CHANGE

IMPLEMENTATION OF CHANGE

Architectural Portfolio Management of the

Landscape



Architectural Definition of Foundational Change

Initiatives



Let us look the typical scenarios where EA discipline will assist

The scenarios can be broadly classified as Identification, Definition or Implementation of the required change

Each of the classifications has its own scenarios namely

Supporting an overarching business strategy (M&A, Divestitures)

Architecture portfolio management of complex IT landscape (how to rationalize the complexity)

Architecture portfolio management of complex IT projects (how to rationalize the multiple goals/drivers)

Foundational change initiatives

Bounded change initiatives

Finally Architecture governance


SAP AG 2009

TOGAF™ Engagement Classes and Types 2/2

What appears to be the initial context……is often not the root cause of the problem

IDENTIFICATION OF REQUIRED CHANGE DEFINITION OF CHANGE

IMPLEMENTATION OF CHANGE

Architectural Portfolio Management of the

Landscape



Architectural Definition of Foundational Change

Initiatives




SAP AG 2009

Identification of Required Change 1/3

Supporting Business Strategy As the business strategies, objectives, goals and drivers

change, it is necessary for IT to change in order to maintain alignment.

The creation of new business strategies can be supported by Enterprise Architecture through:

Providing visibility of change opportunities

Providing elaboration on the practical impacts of a particular strategic choice

Providing tests on the feasibility or viability of a particular strategic direction

Key Processes are : Architecture Context

Architecture Definition

Key Focus is : Look at the As-Is First

Broad, shallow consideration given to the IT landscape in order to address a specific strategic question

define terms for more detailed architecture efforts to address strategy realization.

Let us go through each of the six scenarios in detail and understand which processes within the EAF will be applicable

Supporting overarching business strategy – That touches and impacts the entire enterprise

Merger & Acquisition and high profile divestitures

EA provides visibility to change opportunities

It elaborates the practical impacts of that strategic choice

Finally it serves as a good test to evaluate the feasibility and viability of the strategy

In this type of engagement, we have to go through Architecture context and definition iterations (Phases 0, A-D)

The key focus should be on the “As-is” architectural style

One mile wide and inch deep view of IT landscape

Provide an outline of detailed architecture efforts required to address the strategy


SAP AG 2009


Architectural Portfolio Management of the Landscape

Common practice across large organizations for Service Management to provide operational reporting and management of the IT portfolio.

Enterprise Architecture can add further dimension to Service Management reporting, by supporting a linkage between operational performance and the strategic need for IT.

Using the traceability between IT and business inherent, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g. cost, functionality, availability, responsiveness)

Determine areas where misalignment is occurring and change needs to take place.

Key Processes are : Architecture Context


Key Focus is :

Look at the As-Is First

Focus on physical assessment of current state applications and technology infrastructure to identify improvement opportunities

Pay attention to the constraints of maintaining business as usual.

Architecture portfolio management of complex IT landscape

This is more operations focused

It is typical for service providers & management to provide operational reporting & management of IT landscape

EA adds another dimension and structure to reporting by providing a link between operational performance and strategic need for IT

Identifies the areas they are misaligned


The key focus should be on the “As-is” architectural style

Perform a physical assessment of current state of applications and technology infrastructure

Identify constraints and barriers to maintaining business as usual


SAP AG 2009


Architectural Portfolio Management of Projects: It is common practice across large organizations for a Program Management organization

to provide operational reporting and management of the change portfolio.

Enterprise Architecture can add a further dimension to project portfolio management reporting, by supporting a linkage between project scope, architectural impact and business value.

Architectural factors can be added to other quantitative project factors to support strategic decision making on project priority and funding levels.

Key Processes are : Transition Planning


Key Focus is: Projects, and project

dependencies

Landscape impacts to align project sequencing in a way that is architecturally optimized

ImplementationPlan

development

ArchitectureModel

operational

delivery milestone 2delivery milestone 1

view A1

view B1

view C1

delivery milestone 4

B4

A4 C4


B3

A3 C3

this workpackage

B2

A2 C2

this project

anotherproject

anotherwork

package

ImplementationPlan

development

ArchitectureModel

operational

delivery milestone 2delivery milestone 1

view A1

view B1

view C1


B4

A4 C4


B3

A3 C3

this workpackage

B2

A2 C2

B2

A2 C2

this project

anotherproject

anotherwork

package

Architecture portfolio management of IT portfolio

This is more program management focused

It is typical for PMO to provide operational reporting & management of IT project

EA adds another dimension and structure to reporting by providing a link between project scope, architectural impact and business value

Architectural factors can be added to other quantitative factors to determine funding and priority

In this type of engagement, we have to go through Transition planning and Architecture deployment iterations (Phases E-H)

The key focus should be on

Projects and their dependencies

Align project sequence such that they optimize the architecture


SAP AG 2009

Definition of Change 1/2

Architectural Definition of Foundational Change Initiatives (Enterprise Solution Architecture) Foundational change initiatives are change efforts that have a known objective, but are not strictly

scoped or bounded by a shared vision or requirements.

In foundational change initiatives, the initial priority is to understand the nature of the problem and to bring structure to the definition of the problem.

Once the problem is more effectively understood, it is possible to define appropriate solutions and to align stakeholders around a common vision and purpose.

Key Processes are :



Key Focus is :

As-Is First then Transition Planning

Focus on elaborating a vision through definition of current state

Identifying what needs to change to transition the current state to the vision.

Project GHI

Project DEF

Project ABC

Project XYZ

WP 3

WP 6

WP 2

WP 4

WP 5

WP 1

Strategic Business ImpactTactical Strategic

Ris

kL

ow

Hig

h

0- 3 months 3- 6 months 6- 12 months 12+ months

2 months

3 months

6 months

24 months

6 months

CommencementTimescale

3 months

Project GHI

Project DEF

Project ABC

Project XYZ

WP 3

WP 6

WP 2

WP 4

WP 5

WP 1

Strategic Business ImpactTactical Strategic

Ris

kL

ow

Hig

h

0- 3 months 3- 6 months 6- 12 months 12+ months

2 months

3 months

6 months

24 months

6 months

CommencementTimescale

3 months

Foundational change initiatives

These are change initiatives where the goals/objectives are known but the scope are not clearly known or bounded by common vision

EA will help to understand the problem and bring structure to the definition of the problem

EA also provides structure to the development of the solution


The key focus should be on “as-is” architectural style

Identifying what needs to change to transform from current state to vision or target state


SAP AG 2009

Definition of Change 2/2

Architectural Definition of Bounded Change Initiatives (Solution Architecture) Bounded change initiatives are change efforts that

typically arise as the outcome of a prior architectural strategy, evaluation or vision.

In bounded change initiatives, the desired outcome is already understood and agreed upon.

The focus of architectural effort in this class of engagement is to effectively elaborate a future state solution that addresses the identified issues, drivers and constraints.

Key Processes are :


Key Focus is :

To-Be First then Transition Planning

Focus on elaborating the future state to meet a previously defined and agreed vision, scope or set of constraints.

Use future state as a basis for analysis to avoid

perpetuation of current, sub-optimal architectures.

Firewall

InternetAP Dealer Workstation

Cisco Routers -Virtual Load Balancer

Firewall

Firewall

Internet

F5 Load Balancers

Firewall

F5 Load Balancers

NA Dealer Workstation

Database LANProduction LAN

North American DMZ

North American Intranet

Holden DMZ Holden LAN

2 Mbps

New or Modified Components

Existing Components

2 Mbps

2 Mbps

2 WebSEAL Servers Sun Fire V240 Server

2*1GHz CPU, 8GB RAM or spare equipment from

Holden Portal decommissioning

2 Terminal Emulation Servers Sun Fire V240 Server 2*1GHz

CPU, 8GB RAM or spare equipment from Holden Portal

decommissioning

Holden ApplicationsVOL, COLD, WarrantyOnline, Warranty File

Transfer (HFTS), PartsOnline, Bulletins etc.

8 WebSEAL Servers Sun Fire V240 Server 2 * 1GHz CPU, 8GB RAM 2x36GB HDD(internal)

2 SunONE Portal Servers Sun Fire V1280 Server

12CPU, 24GB RAM

WebSEAL JunctionedAPP Servers - OWB etc Sun Fire V480 4 * 1GHz

CPU 8GB RAM

1 InterwovenServer Team Site, OpenDeplov SUN Fire V210, 1 GHz,

2GB RAM

2 LDAP Costumers SUN Fire V240, 2 x 1 GHz CPU, 8GB

RAM

EntityDatabase

2 User AdminServers SUN

Fire V240, 2 x 1 GHz CPU, 8GB

RAM

2 Oblix NetPointand TAM

Servers SUN V480, 1 x 1 GHz CPU, 16GB RAM

2 LDAP Servers - Multi-Master SunOne and IDAR

SUN Fire V880, 8CPU 16GB RAM

Bounded change initiatives

These are change initiatives that resulted from prior architectural strategy, evaluation or vision

Here the scope & desired outcome is already understood and known

Elaborate a future state solution that addresses the identified issues, drivers and constraints

In this type of engagement, we have to go through Architecture definition iterations (Phases B-D)

The key focus should be on “as-is” architectural style followed by Transition planning

Ensure the current state sub-optimal architectures do not perpetuate into future state architecture


SAP AG 2009

Implementation of Change

Architectural Governance of Change Implementation Once an architectural solution model has been

defined, it provides a basis for solution architecture, design and implementation.

In order to ensure objectives and value of the defined Enterprise Architecture are met, we need continued governance of the implementation process to support design review, architecture refinement and issue escalation.

Key Processes are : Architectural Governance of Change

Implementation


Key Focus is :

Use the Enterprise Architecture vision, constraints, principles, requirements, future state definition and transition roadmap

Ensure that projects realize their intended benefit

Ensure projects are aligned with each other and with wider business need.

The final scenario is Governance of change implementation

Once the solution is define, Governance ensures we

Follow what we defined

Processes are in place to ensure design complies with architecture

A clear path for escalation of issues and their resolution

In this type of engagement, we have to go through Implementation Governance and Architecture deployment iterations (Phases E-H)

The key focus should be

Ensure projects realize their intended benefit and we have a mechanism to track them

Ensure projects are aligned with each other and with wider business need


SAP AG 2009

Exercise 1 - Risks and Mitigations 1/3

In the next 15 minutes

Pick an assignment

Identify what TOGAF™ engagement type it is

Identify the approach you would take

Identify 5 key risks to look for

Identify a useful mitigation for each risk

Come back and present your findings


SAP AG 2009


The Head of IT Infrastructure of Acme Corporation calls you in ; his key issues are:

Spiraling operating costs of IT operations

Lack of visibility of business projects and their IT demands

Inability to forward forecast IT operating costs

Duplication and lack of efficiency

The CEO of Acme Corporation calls you in ; her key issues are:

How to accelerate the merger with Wile E. Coyote Dynamite Corp

How to keep pace with the nearest rival, Road Runner Corp


SAP AG 2009


The Chief Architect of Acme Corporation calls you in; his key issues are:

The business users are initiating development projects with their own preferred partners and solutions

Projects not delivering what they agreed they would

Convincing the Board of the value of BPM and SOA


SAP AG 2009

Exercise 2 - Project Issues 1/2

In the next 15 minutes Based on your previous example

and working

Work out a mitigation strategy for the following issues….

Come back and present your findings


SAP AG 2009

Exercise 2 - Project Issues 2/2

The Head of IT Infrastructure of Acme Corporation Project The Program Office Director has gone on long-term sick leave

The Head of Finance cannot provide you with costs of running each application

The last Data Centre Asset Audit took place 3 years ago before the recent merger

The CEO of Acme Corporation Project You cannot get access to the Due Diligence information on the merger with

Wile E. Coyote Dynamite Corp

You find out the merger will go through in 1 months time

The CEO’s next free diary slot is in 2 weeks time

The Chief Architect of Acme Project The Head of Procurement post has been vacant for the last 3 months

The Project Management Lifecycle used by Acme does not include formal project closedown and Post Implementation Review steps

Acme has just signed a $100 million contract with EDS outsourcing Applications Management for the next 10 years

You have 30 minutes with the Board of Directors next week to convince them of the value of ESOA


SAP AG 2009

Summary

This is the end of the Using TOGAF™ for Specific Engagements unit

You should now understand : The TOGAF™ ADM process and its limitations in

engagement management

How TOGAF™ handles risk management


How to use TOGAF™ for specific engagements

The next phase explains SAP-Specific Mappings


We should understand how to use TOGAF™ for specific engagements

How TOGAF™ addresses various engagement types



Exercises

Unit: Use EAF for EA Engagements

Topic: Apply EAF for a Scenario


Effectively apply EAF for a scenario provided

Scenarios

1. The Head of IT Infrastructure of Acme Corporation calls you in and his key issues are:

Spiraling operating costs of IT operations

Lack of visibility of business projects and their IT demands

Inability to forward forecast IT operating costs

Duplication and lack of efficiency

2. The CEO of Acme Corporation calls you in and her key issues are:

How to accelerate the merger with Wile E. Coyote Dynamite Corp

How to keep pace with the nearest rival, Road Runner Corp

3. The Chief Architect of Acme Corporation calls you in and his key issues are:

The business users are initiating development projects with their own preferred partners and solutions

Projects not delivering what they agreed they would

Convincing the Board of the value of ESOA

4. The CEO of ABC Corporation calls you in and her key priorities are

Divest their manufacturing operations to BCD corporation in the far east and the divestiture must be complete within 120 days per government guidelines

Carve out all IT applications that support the manufacturing operations

Maintain clear delineation of all enterprise data assets

Demonstrate and report compliance to federal agencies


1-1-1 Pick one scenario from above



1-1-2 Identify which SAP EAF “Engagement Type” your selected scenario falls under

1-1-3 Identify which ADM phases are applicable for this scenario

1-1-5 Once the ADM phases are identified, what will be your focus area?. Would you go through “As-Is” iteration or “To-be” iteration and Explain why?

1-1-6 At a high level, identify the approach or initiatives you would undertake to address the issues of the scenario you have selected

1-1-7 Present your findings to the class

Solutions

Unit: Use EAF for EA Engagements

Topic: Apply EAF for a Scenario

1-1 Solution for Scenario 1 Address issues of Head of IT Infrastructure of Acme Corporation Overarching Business Strategy

1-1-1 Engagem ent Type Architectural Portfolio Management of the IT Landscape (Enterprise

Architecture) 1-1-2 Key Focus areas:

a. Look at the As-Is First b. Focus on physical assessment of current state applications and technology

infrastructure to identify improvement opportunities Duplication? Obsolescence? Capacity planning based on TO-BE roadmap?

c. Pay attention to the constraints of maintaining business as usual How are current projects managed and assessed by service

management? d. Identify the To-Be Roadmap to help forecast future impacts

Identify Non-Functional Requirements and outline architecture changes

Ensure the forecast changes are translated into budget forecast 1-2 Solution for Scenario 4

ABC Divesting its Mfg to BCD 1-2-1 Identify what SAP EAF “ type” it is

Overarching Business Strategy Support high-profiled divestiture

1-2-2 Identify the approach you would take Clearly define the “Business Operating Model” of the merged entity Identify high-level “Organizing Principle” for the merged entity Deal with the customers first (front end) or Supply Chain

Management/Manufacturing operations first (back end) Identify the tactical projects to deal with “burning issues” Determine “Master” enterprise architecture (considering all domains) ABC as Master with BCD migrating to ABC BCD as Master with ABC migrating to BCD Combination of both Or Totally a “Green field” approach



SAP AG 2009

Unit 13 - SAP-Specific Mappings



SAP AG 2009

Review of SAP-Specific Mappings

Contents:

Why SAP-Specific Mappings ?

Example Content

Detailed Mapping Explanation

The SAP Technical Reference Model



SAP AG 2009








SAP AG 2009

Lesson Objectives

After completing this lesson, you will be able to understand how:

SAP-Specific Mappings provide significant value to TOGAF™

TOGAF™ maps specifically to SAP Reference and Landscape Content

A SAP-Specific Technical Reference Model enables standardization and reuse in an Enterprise Architecture


SAP AG 2009

Why SAP Specific Mappings?


Example Content





SAP AG 2009


Business Solutions


Business Suite

Integration & Appl. Infrastructure

Computing Infrastructure

SAP xApps

Web

Spher

e

.NE

T

SAP NetWeaver

“Why should I spend months inventing my applications architecture, when SAP provides me one ‘out-of-the-box” ?

TOGAF™ provides a holistic, vendor-neutral mechanism to describe an enterprise

But . . . . What about organizations with a significant

investment already in SAP Products and Services ?

What about organizations planning a significant investment in SAP Products and Services ?

How can these customers accelerate their Enterprise Architecture development ?

How can organization’s re-use SAP’sProduct Architecture ?

The challenge is how can we leverage the existing SAP Platform Architecture as effectively as possible when we build our Enterprise Architecture

There is no need to spend weeks documenting the TO-BE Application or Data Architecture if it is highly likely that SAP Products will be used in the organization as part of an existing strategy


SAP AG 2009



Content

SAP EAF Extensions






Product Availability Matrix (PAM)



Technology

view

Business view

Applicationview


TOGAF™ 9


Method

Content Framework &

Metamodel

Templates, Examples and Case Studies

ADM Guidelines and Techniques

So

luti

on

Ma

nag

er

Iterative ADM


SAP AG 2009



Content

SAP EAF Extensions









Technology

view

Business view

Applicationview

SAP Reference Models provide reusable models and patterns

that can be used directly or as a template for architecture content

TOGAF™ 9


Method

Content Framework &

Metamodel



So

luti

on

Ma

nag

er

Iterative ADM


SAP AG 2009



Content

SAP EAF Extensions









Technology

view

Business view

Applicationview

SAP Landscape content provides an accurate picture of the ‘As is’ situation e.g. what is running? What is installable? What is buyable?

TOGAF™ 9


Method

Content Framework &

Metamodel



So

luti

on

Ma

nag

er

Iterative ADM


SAP AG 2009


How you use the Mappings depends on the engagement

An entity in the TOGAF™ Content

Metamodel…

SAP Product

SAP Software Component Version

SAP SolutionSAP Application

is related to what is… … buyable

… installable… running

Other SAP Content Elements

can be used … … as an idea

… as a template …or can be directly included

Two conceptual approaches :

Map TO-BE entities to the required SAP Products, Solutions and Components

Reverse-engineer the AS-IS landscape when creating the AS-IS baseline


SAP AG 2009


How you use the Mappings depends on the engagement

An entity in the TOGAF™ Content

Metamodel…

SAP Product

SAP Software Component Version

SAP SolutionSAP Application

Other SAP Content Elements

has which influence on the EA?

allows to remove which installation?


SAP AG 2009

Possible Approaches 1/2

TOGAF™ ContentMetamodel

SAP Technology

Reference

Content


Content

SAP

Landscape

Content




Solution Manager



21

6

Logical

view

Business view

Product view

5

4

3

If the TOGAF™ model is created completely independently (arrow #1) then building relationships to SAP reference content will require significant additional effort.

One option is to take the SAP repository as a primary input and just extend or remove objects where required (arrow #2). These object pools are either delivered by SAP together with its products (e.g. Solution Manager) or can be obtained from public sources like the SAP’s internet representation as well as from SAP’s support platform (SAP Service Marketplace).

As an alternative option to take, copy and updating pre-defined content from SAP is to really use and reference it. In this case, creating the relationships from TOGAF™ content to the SAP’s reference content is simple, as long as no major changes are made, since it is a one-to-one mapping and only additional and significantly modified objects have to be re-related to SAP content (arrow #3).

For the Enterprise Architect, the decision has to be made whether the relation is primarily established on the product level or on the business model level. Following the latter has the advantage that the responsibility to maintain the relationship between the business and the product view lies at SAP but on the other side the flexibility to describe the business view of the respective company independently from the SAP reference way is limited.

This degree of freedom is created, when the content of the business view is used as input (arrow #2), maintained separately and then linked afterwards to the SAP product view.


SAP AG 2009

Possible Approaches 2/2

TOGAF™ Content Metamodel

SAP Technology

Reference

Content


Content

SAP

Landscape

Content




Solution Manager



21

6

Logical

view

Business view

Product view

5

4

3

Once the relations between TOGAF™ and SAP reference content are established, the tracking from the TOGAF™ model down to the SAP products and to a certain extent to the (internal) logical view (product and software architecture) becomes possible on a conceptual level (arrow #4).

From there on, the further navigation into the companies IT landscape in terms of actually deployed SAP components (and in some cases also to non-SAP elements) is available (arrow #5).

Although, a possible approach is to model the EA with the TOGAF™ content metamodel completely independent from SAP models and contents and just relate to existing and deployed SAP components on the concrete landscape level (reverse arrow #6), this approach is not recommended as this will require extra effort in terms of reverse engineering tasks.

There will also be no guarantee that the modeled relationships are finally correct and consistent with the business architecture. In addition, these relationships have to be reconfirmed or even rebuilt every time a product update takes place. Therefore it is reasonable to leave the maintenance of this part of the model, including its structural content of the system landscape directory to SAP. The operational part of the model shall be related to the relevant TOGAF™ content metamodel entities (arrow #6).


SAP AG 2009

Example Content


Example Content



SAP-Specific Mappings Summary


SAP AG 2009

Business Objectives = Objectives

KPIs = Measure

Process = Function

Employee Role = Role

Enterprise Services= Application

Component

Mapping Solution Composer content

QUESTION : Is everyone aware of SAP’s Solution Composer Tool ?

If we examine the Pools section of Solution Composer we can see how the SAP Reference Model can be mapped onto the TOGAF™ Content Metamodel.


SAP AG 2007

Mapping the Enterprise Service Repository content

Logical/Physical Information Components

QUESTION : Is everyone aware of SAP’s Enterprise Service Repository Tool ?

Here we can examine potential Logical and Physical “information components”


SAP AG 2007

Mapping Scenario and Process Component List content

Logical Application Components

QUESTION : Is everyone aware of SAP’s Scenario and Process Component List Tool ?

Here we can examine potential Logical “information components”


SAP AG 2007

Mapping Product Availability Matrix content

Logical and Physical Technology Components

QUESTION : Is everyone aware of SAP’s Product Availability Matrix Tool ?

Here we can examine potential Logical and Physical “technology components”


SAP AG 2009

Tool Exercises

Solution Composer

A water utility customer wants to upgrade its legacy customer billing platform ; it already uses SAP CRM and ERP. It is interested in providing a “billing service” for 3rd party companies. Give 3 example KPIs it could develop to measure its efficiency

What are the 6 sub-processes in the Business Map for residential billing ?

What SAP Product supports the billing of third parties ?

Enterprise Service Repository

The Water Utility also performs enterprise asset management of its water meters which are used to bill the customer What Enterprise Service Interface is available to accept maintenance requests from

its outsourced meter reading service ?

Process and Component List

What other products are needed to run the Third Party Billing product ?

Can we upgrade from SAP R/3 4.0B ?

Product Availability Matrix

When does mainstream maintenance end on the latest version ?


SAP AG 2007

Mapping SAP Netweaver Solution Map content

User Productivity Enablement

Running an Enterprise Portal

Enabling User Collaboration

Business Task Management

Mobilizing Business Processes

Enterprise Knowledge Management

Enterprise Search

Data Unification Master-Data Management Enterprise Data Warehousing


Enterprise Reporting, Query, and Analysis

Business Planning and Analytical Services

Enterprise Data Warehousing


Enterprise Search

Business Event Management

Business Activity Monitoring Business Task Management

End-to-End Process Integration

Enabling Application-to-Application Processes

Enabling Business-to-Business Processes

Business Process Management

Enabling Platform Interoperability


Custom Development Developing, Configuring, and Adapting Applications Enabling Platform Interoperability

Unified Life-Cycle Management

Software Life-Cycle Management SAP NetWeaver Operations

Application Governance and Security Management

Authentication and Single Sign-On Integrated User and Access Management

ConsolidationEnabling Platform Interoperability

SAP NetWeaver Operations

Master-Data Management



Enterprise SOA Design and Deployment

Enabling Enterprise Services

SAP IT Scenarios = Platform Services

QUESTION : Is everyone aware of SAP’s Netweaver Solution Map ?

Here we can examine potential Platform Services


SAP AG 2009



Example Content





SAP AG 2009

The importance of Taxonomy

How do we relate a vendor-neutral framework to vendor-specific Products and Services ?

TOGAF™ Glossary

Defines specific terms used in TOGAF™ and provides examples

Designed to be vendor-neutral

SAP Glossary

Defines specific terms used in SAP Products and Services

Based on standard SAP Taxonomy

Designed to be vendor-specific !

We need standard glossaries before we attempt to map the concepts

Example: the TOGAF™ term - Physical Technology Component

A specific technology infrastructure product or technology infrastructure product instance.

SAP CRM

Example SAP-Specific Term

SAP.Product

SAP.Products are either SAP.Applications or SAP.Solutions which are (as a specific SAP.Product Version) on the SAP price list and are always branded with “SAP,” or “SAP xApp” in external communications.

SAP CRM

SAP SCM

SAP for Automotive


SAP AG 2009

Map each TOGAF™ Metamodel Entity to SAP Entity

Application ModelsTechnical Models

Enterprise Services

Business ModelsTOGAF™ Content Metamodel

Defines Key Entities and Relationships to formalise Architecture Models

We can then map each TOGAF™ content metamodel entity to each SAP entity


SAP AG 2009

TOGAF™ to SAP Taxonomy Mapping

Business Goal

Business Objective

KPI

Value Chain

Fine-Grained

Coarse-Grained

Coarse-Grained

Fine-Grained


Motivation

Measure

Objective

Goal

Driver

TOGAF™ Terms

Data

Data Entity



Business Object

Process Component

Organization / Actor

Role

Actor

Organisation

Location


Employee, SAP Role

Value Chain Element

SAP Taxonomy & TermsValue Chain Element


Application




Enterprise Service Interface

Process Component

SAP Application

SAP Application Component

Technology

Platform Service




ProductBusiness Scenario


Product Version

Business Scenario Map

Software Component

IT Scenario

Software Component Version

Function


Service Contract


Business Service

Process

Process


Process Step Master Data

This diagram shows the completed mapping by the main architecture domain areas of the TOGAF™ content metamodel

In each domain, there is a progression of granularity as the need arises to define more and more fine detail

SAP AG 2009

The Content Metamodel

We will now “zoom in” on the different parts of the metamodel to show the different SAP entities can be directly mapped to the TOGAF™ content metamodel


SAP AG 2009

SAP – Solution ComposerBUSINESS ARCHITECTURE

SAP.Business Goal

SAP.Business Objective

is covered by

helps to achieve

Goal

Objective

Driver

Creates

Addresses

Is realisedthrough

Realises

SAP.BusinesScenario

is supported by

is achieved by

supports

SAP.Processsupports

SAP.Productis covered by

covers

is covered by

contains

is part of


Objective


Is trackedagainst

SAP – Solution Composer

SAP .BusinesScenario

SAP.KPIis equivalent to

is measure for

SAP .Business Objective

is covered by

is measured by

is supported by

SAP.Process SAP.Productis covered by

covers

contains

is part of

supports

Business Goals, Objectives And Measures


Goals and Objectives can be directly mapped

Care is needed however when mapping to Organization specific Goals and Objectives as the SAP Reference Model assumes a specific Goal to Objective mapping

The recommendation is to map to only one – ideally Objective at the lower level

The established relationship on the different solution maps helps to determine

which objectives are finally supported by which SAP product

if SAP offers products to support reaching a given objective

which objectives can’t be reached by implementing existing SAP products

Similar to the business objectives, Solution Composer offers a pool of Key Performance Indicators (SAP.KPIs) which might be used as templates to define measures for different objectives. On the different scenario-oriented Solution Maps these KPIs are assigned to Business Scenarios (SAP.Business Scenarios).

It is important to note, that there is no direct relationship between defined SAP.Business Objectives and SAP.KPIs as exist on the TOGAF™ content metamodel between Objective and Measure.


SAP AG 2009

SAP EAF: Organizational Entities

BUSINESS ARCHITECTURE SAP – Solution Composer

SAP.Industry ValueChain Element

Organisation Unitrepresents

SAP.Business Participant

Actor

Location

Role SAP.Employee Rolerepresents

represents

Organizational aspects occur in SAP content in different contexts. In some cases SAP.Value Chain Elements might be related to an organization unit.

Another type of Organization Unit used in the SAP model for SAP.Business Scenario Maps is SAP.Business Participant.

The third organizational entity is the SAP.Employee Role (Synonym: SAP.SAP Role) which is governed in a corresponding Solution Composer Pool.

You should be aware, that these entities do not have a relationship to a runtime environment.

Different SAP products might bring predefined roles as content (e.g. Portal roles, Backend roles etc.) of the software product which will be maintained and extended in the concrete company’s environment.

SAP provides several technical solutions (e.g. SAP Role Expert, SAP Access Enforcer) and several adapters (e.g. Active Directory, Novell Directory etc.) to implement such a central repository with different capabilities.


SAP AG 2009

Functions

SAP – Solution Composer

SAP – Solution Manager


SAP.Business ScenarioGroup

SAP.Business Scenario

SAP.Process

SAP.ProcessConfiguration Variant

SAP.Process Step

is equivalent to

is a sequence of

is part of

is part of

groups

SAP.Industry ValueChain

SAP.Value Chain Element

consists of

belongs to

consists of

belongs to

(Macro-Level) Function

Business Service

(Micro-Level) Function

SAP.Product

utilize

is utiliized by

is composed of

is used withinis covered by

is part of

has ais a variant of

covers

Within the TOGAF™ content metamodel there is the generic concept of a Function. A certain level is indicated as a Business Service which supports certain business capabilities through an explicitly defined interface and is explicitly governed by an organization. Coarser granularity functions are considered as a Macro-Level Function whereas fine granular functionality is named as Micro-Level function.

Since the borderline can be chosen in the context of a concrete enterprise or even in a certain area, the level of similar granularity cannot be set in general.

Macro-Level Function could be related to all hierarchies beginning with SAP.Value Chain Element down to SAP.Process although we expect in reality, that SAP.Process is a good candidate for a Business Services.

The dotted lines illustrated that in principle SAP.Process could be either related to the Macro- or the Micro level as well.

The current granularity of the existing SAP content leads to the point that process steps are mostly located on the Micro-Level Function.


SAP AG 2009

Processes

BUSINESS ARCHITECTURE SAP – Solution Composer

SAP.Industry ValueChain

Process

is equivalent to

SAP.Business ScenarioMap

is represented on

The object type Process represents from the TOGAF™ perspective those specific functions which are representing a flow of control (business and not technical wise).

SAP content expresses these flows only in a very limited way since these might be to a large extent very customer specific and represent the competitive difference


SAP AG 2009

Data Entities

DATA ARCHITECTURE

Data Entity



Encapsulates

Resides within SAP Enterprise Service Workplace

Business Object

contains

SAP Scenario and Process Component List

Process Component

Is the SAP representation

of a

SAP Solution Manager

Master Data

In order to find equivalent entities for Data Architecture, one has to understand that SAP does not explicitly provide a data architecture with their contents and models. The relevant data are rather embedded within the process flow description as provided by SAP.Business Scenario Maps,

Solution Manager identifies Master Data objects by functional area and a list of these can be obtained.

The entity holding the business process data is the SAP.Process Component. SAP.Process Component is a container for one and more semantically related SAP.Business Objects.

A process component also provides a frame in terms of exposed service interface to control and manage the usage of contained business objects. Thus, it is reasonable to map the TOGAF™ logical information component to SAP.Process Component and SAP.Business Object to the TOGAF™ data entity.

An instance of a physical information component is not separable from the actual production environment in a certain company. SAP as an ISV can only deliver a frame to guide the customer to build physical information components. Therefore, there will be by definition no mapping.

The SAP Enterprise Service Workplace is the physical location to decompose from SAP.Process Component to SAP.Business Objects.


SAP AG 2009

Application Components

SAP Scenario and Process Component List SAP Solution Composer

SAP – Enterprise Service Workplace





Is Realised by

ProcessComponent

ScenarioComponent

SAP Product & Version

SAP Solution / Application

Is composed of

Is grouped into

Is representedin businesssense by

Business Scenario

Business Process

can be detailed in

Is set of

specifies therealization of

Is part of

can beproivided by a

specifies therealization of

encapsulatesparts of

applicationfunctionalities

Is providedwithin

is related to

SAP ApplicationComponent

describes technicalfunctionalities of a


The TOGAF™ content metamodel introduces the Application Component entity as the building block of architecture on this level and distinguishes between the logical and the physical level. Since the physical level describes the actual operational production environment of an application in a certain company, SAP as an independent software vendor (ISV) cannot provide by definition Physical Application Components.

Even pre-configured products (like SAP All-in-One), products which can be hosted (like SAP CRM on Demand) or even specific hosting offerings from SAP Hosting cannot be considered on that level as Physical Application Components because there is always specific configuration and adoption effort needed to bring those products into operation. Only the actual running and customized application for the given customer can be finally related on the physical level.

Following business trends, SAP or other outsourcing providers offer increasingly complete packages (“Software-As-A Service”) which will lead to the fact, that physical application components may become part of SAP content.

A Logical Application Component is the relevant starting point for the TOGAF™ content metamodel side towards SAP object types. A Logical Component is an encapsulation of application functionality that is independent of a particular implementation. Therefore it makes sense to relate this entity first of all to the SAP.Application or SAP.Solution.

The Scenario & Process Component List (SCL & PCL) is the location to decompose from that top level SAP entity and identify realization alternatives as well as business scenarios and processes implemented by this application.


SAP AG 2009

Information System Service & Logical Application Component


SAP – Enterprise Service WorkplaceAPPLICATION ARCHITECTURE


ProcessComponent

ScenarioComponent

SAP Solution / Application

Is composed of

Is grouped into

can beproivided by a

Provide informationto operate the

application(physical) within the

SAP ApplicationComponent



Enterprise Service InterfaceInformation System

Servicesupports

On the SAP side, there are two equivalences to the Information System Service defined by TOGAF™.

First, there are SAP. Process Components which are the Service Provider in terms of supporting a set of SAP. Enterprise Service Interfaces, and second the SAP. Scenario Components which are coarse granular and do not explicitly support Enterprise Service Interfaces.

The first can be found either in the Enterprise Service Workplace or the SCL & PCL, the latter only in the SCL&PCL repository.


SAP AG 2009

Technology Components (1)

SAP Solution Composer SAP Scenario and Process Component List




SAP Product

SAP Software Component

IT Practice

IT Scenario

consists of

structures technicalcapabilities of

such as CompositionPlatform includes

identifies

Is represented bycertain types of

Platform Service

Supplies

Is Supplied By

From a technical architectural perspective, TOGAF™ defines a Technology Component at the logical and physical level. The corresponding connection points on the SAP side are mainly to SAP.Product but in some cases there are relevant SAP.Software Components which have to be considered as Logical Technical Components as well.

In relation to the TOGAF™ TRM, each infrastructure application as well as each business application can be interpreted as a logical technology component. Each IT Scenario given by the SAP NetWeaver Solution Map would represent a Logical Technology Component.

A clear mapping from SAP content to the TOGAF™ entity Platform Service cannot be provided since platform services describe a certain area of (technical and infrastructural) capabilities which are provided by a Logical Technology Component


SAP AG 2009

Technology Components (2)

SAP Scenario and Process Component List and SAP System Landscape Directory

SAP Product Version



Infrastructure Consolidation Extension


Realises

SAP Software Component VersionIs represented by

certain Software Component Types

SAP Instance / Deployment Unit

Is represented by SAP technology product

Is assigned to

defines the smallest deployment unit of

defines the product scope based of

Is a logical / phyicalServer

Getting down to the level of Physical Technical Component, a closer view on the technical decomposition of SAP.Products and SAP.Software Components is required.

An SAP technology component is realized by versioning of products and software components.

Their instantiations are built by a so-called SAP Instance (alias to main or central instance).

In accordance with the TOGAF™ content metamodel definition these three entities (SAP.Product Version, SAP.Software Component Version and SAP.Instance/Deployment Unit) should be related to physical technology components

SAP’s System Landscape Directory identifies exactly which of the above Products, Components are installed on a customer’s SAP landscape.


SAP AG 2009

The full mapping of SAP Tools to the TOGAF™ Framework

Source of Data SAP Term TOGAF™ Term

Motivation

Organization / Actor

FunctionSolution Composer

Solution Manager

Business Goal

Business Objective

KPI

Value Chain

Value Chain Element


Business Scenario


Process


Process Step


Employee, SAP Role

Measure

Objective

Goal

Driver

Role

Actor

Organisation

Location


Service Contract


Business Service

Data

Application

Technology




Software Component


Product Version

Product

IT Scenario

Platform Service



SDN ES WorkplaceEnterprise Service Repository Business Object Node

Business Object

Process Component

Process Component

Enterprise Service

Data Entity






Methodology

Requirements

Roadmap Composer Architecture Development MethodStrategy and Implementation

Roadmaps

Service MarketplaceQuickSizer

Non-Functional RequirementsInfrastructure Requirements

Master Data

NL-R-P705 – Overview of SAP Tools provides more detail on how each Tool is applied in TOGAF™


SAP AG 2009


Why SAP Specific Mappings ?

Example Content






SAP AG 2009

The TOGAF™ Technical Reference Model


The objective of the TOGAF™Technical Reference Model is to provide a widely accepted core taxonomy

To facilitate communication

To enable systems to be analyzed in a consistent manner

To link to public databases of open standards

The Technical Reference Model comprises

A Taxonomy

An associated Technical Reference Model graphic

Qualities

Qualities




Network Services


System

& N

etwo

rkM

anag

emen

t

So

ftware E

ng

ineerin

g


Data M

anag

emen

t

Lo

cation

& D

irectory

Data In

terchan

ge

Intern

ation

al Op

eration

s

Tran

saction

Pro

cessing

Secu

rity

Grap

hics &

Imag

e

User In

terface

TOGAF™ acknowledges that one of the great difficulties in developing an architecture framework is in choosing a TRM that works for everyone.

The TOGAF™ TRM was originally derived from the Technical Architecture Framework for Information Management (TAFIM) TRM (which in turn was derived from the IEEE 1003.0 model -, ISO/IEC TR 14252 (IEEE Std 1003.0)).

The TRM is "platform-centric": it focuses on the services and structure of the underlying platform necessary to support the use and re-use of applications (i.e., on application portability).

In particular, it centers on the interfaces between that platform and the supported applications, and between the platform and the external environment.

TOGAF™ recognizes that organizations will need to develop their own TRM


SAP AG 2009

TOGAF™ High Level Technical Reference Model

High Level TRM recognizes :

Three major entities

Applications


Communications Infrastructure

Two interfaces


Communications InfrastructureInterface)

Diversity

Applications

ApplicationPlatform

CommunicationsInfrastructure

Application PlatformInterface

CommunicationsInfrastructureInterface



SAP AG 2009

TOGAF™ Detailed Technical Reference Model

Business Applications implement business processes for a

particular enterprise or vertical industry the internal structure of Business

Applications relates closely to the specific application software configuration selected by an organization.

E.g. inventory management services used in the retail industry

Infrastructure Applications, provide general-purpose business

functionality, based on Infrastructure services.

Widespread availability as commercial off-the-shelf software

uneconomic to consider custom implementation

E.g. Document editing and presentation

Platform Services Common services required by the


Communications Infrastructure provides the basic services to

interconnect systems and provide the basic mechanisms for opaque transfer of data


InfrastructureApplications

Application Programming Interface

Communication Infrastructur Interface



Network Services

Grap

hic

s & Im

ag

e

Data

Ma

na

gem

en

t

Da

taIn

terc

han

ge

Intern

atio

na

l Op

era

tion

s

Use

r Interfac

e

Lo

cation

& D

irecto

ry

Tra

ns

actio

nP

rocess

ing

System

& N

etwo

rkM

an

ag

emen

t

Sec

urity

So

ftware E

ng

ineerin

g

Qualities

Qu

alit

ies

Qu

alities

Qualities


The detailed TRM splits Applications into Business and Infrastructure Applications

The Application Platform is broken down into the common services required.

So why do we need a TRM ?

Many IT systems today come fully equipped with many advanced services, which are often taken for granted by the purchaser.

For example, SAP comes with software that implements services from most if not all of the service categories of the TOGAF™ TRM.

Since the purchaser of such a system often does not consider anything "smaller" than the total bundle of services that comes with the system, that service bundle can very easily become the "platform".

Indeed, in the absence of a Technology Architecture to guide the procurement process, this is invariably what happens.

It is important for an Enterprise Architect therefore to understand the specific functions that SAP provides.


SAP AG 2009

High Level TRM - SAP Mapping 1/2

Diversity

Applications

ApplicationPlatform




Organizations using or planning to use SAP Products and Services will find an SAP Specific TRM valuable


SAP AG 2009

High Level TRM - SAP Mapping 2/2

Organizations using or planning to use SAP Products and Services will find an SAP Specific TRM valuable

Customer Specific Solutions

SAP IndustryApplications

Partner Applications

SAP Applications

System Middleware Abstraction (OS & DB)

OS & Communication Infrastructure

SAP Technology Platform

SAP Business Process Platform

Customer Specific Solutions

SAP IndustryApplications

Partner Applications

SAP Applications

System Middleware Abstraction (OS & DB)

OS & Communication Infrastructure

SAP Technology Platform

SAP Business Process Platform

Application PlatformInterface

CommunicationsInfrastructure Interface

Diversity

Applications

ApplicationPlatform


Diversity

Applications

ApplicationPlatform


the TRM, and these in turn relate to the Business Application and Infrastructure Application designations.

The core SAP products (ERP, CRM etc) along with more specific industry solutions (meeting the specific requirements of more than 20 different industries) are considered to be within the Applications Layer, and would be considered Business Applications.

In addition, a growing number of Infrastructure Applications are available addressing the needs of defined business scenarios as well as generic functionality considered as infrastructure applications from the TOGAF™ perspective.

These are summarized mainly under the product name SAP NetWeaver®. The underlying NetWeaver application platform was originally specific to the SAP solution, but it has evolved to an open integration environment on which overall partner or customer specific implementations can be developed, deployed and integrated.

The complete set of different solutions, components and platform is named the SAP Business Process Platform which follows completely the principles of an enterprise SOA.

SAP as a whole does not provide specific operating system or communication services (although a few exceptions may exist).


SAP AG 2007

The SAP Ecosystem

Customer Product

Partner Application

SAP Application

Market / Sales

A product is delivered to oneor more customers

One or more industry marketchannels require a product

A product is comprised byone or more applications

Parts are delivered by oneor more partners

An application can belogical or physical, butit is associated with a software or hardware

asset

As an independent software provider (ISV), SAP delivers business solutions to more than 36,200 customers from different industries in more than 120 countries around the world.

Besides providing standard business applications, SAP also helps customers to build their specific applications to best fulfill customer specific requirements.

Thus, the SAP Product Portfolio includes SAP as well as partner or third party applications


SAP AG 2007

Understanding SAP Products

SAP Products and Components Model

Key entities are Product, Product Version and Instance for the external view

Software Component and Software Component Version represents the internal development view of SAP software.

Product

Product Version

Software Component

1

1..*

Instance

-is assigned to1..*

1..*

Software Component Version

Logical/Physical Application System

*

-is deployed on*

-includes

*

0..*

-is comprised of

*

*

-is assigned to

*

-groups *

1

1..*

Any Software Component can have many versions ; this is how SAP sees the software internally

Any Product can have many versions ; this is how customers see the software externally

Products are composed of components that are then installed as an Instance


SAP AG 2009

Example: Technical Information about SAP Products 1/2

Products and Versions

SAP CRM 3.1

SAP CRM 4.0

SAP CRM

...

SAP Web AS 6.20

SAP Web AS...

SAP BBPCRM

Software Components

and Versions

SAP BBPCRM 4.0SAP BBPCRM 4.0


……

SAP BASIS

SAP BASIS 6.20SAP BASIS 6.20

SAP BASIS 4.6CSAP BASIS 4.6C

……

SAP Kernel

SAP Kernel 6.20SAP Kernel 6.20

SAPKernel 4.6CSAPKernel 4.6C

……

PI_BASIS

PI_BASIS 2003_1_620PI_BASIS 2003_1_620

PI_BASIS 2002_2_620PI_BASIS 2002_2_620

……

InstancesInstancesSAP Web AS ABAPSAP Web AS ABAP

SAP ABA 620

SAP BASIS 6.20

…

SAP Java Run TimeSAP Java Run Time

SAP J2EE Engine 6.20

SAP JCO 2.0

…

......

…

InstancesInstances

CRM ServerCRM Server

SAP BBPCRM 4.0

SAP BASIS 6.20

…

CRM IPCCRM IPC

CRM IPC 4.0

CRM ...CRM ...

…

…


SAP CRM 3.1

SAP CRM 4.0

SAP CRM

...

SAP Web AS 6.20

SAP Web AS...


SAP CRM 3.1

SAP CRM 4.0

SAP CRM

...

SAP Web AS 6.20

SAP Web AS...

SAP CRM 3.1

SAP CRM 4.0

SAP CRM

...

SAP Web AS 6.20

SAP Web AS...

SAP BBPCRMSAP BBPCRM

Software Components

and Versions



……

SAP BASISSAP BASIS


SAP BASIS 4.6CSAP BASIS 4.6C

……

SAP KernelSAP Kernel

SAP Kernel 6.20SAP Kernel 6.20

SAPKernel 4.6CSAPKernel 4.6C

……

PI_BASISPI_BASIS

PI_BASIS 2003_1_620PI_BASIS 2003_1_620

PI_BASIS 2002_2_620PI_BASIS 2002_2_620

……


SAP ABA 620

SAP BASIS 6.20

…



SAP JCO 2.0

…

......

…

InstancesInstances


SAP BBPCRM 4.0

SAP BASIS 6.20

…

CRM IPCCRM IPC

CRM IPC 4.0

CRM ...CRM ...

…

…


SAP ABA 620

SAP BASIS 6.20

…



SAP JCO 2.0

…

......

…

InstancesInstances

SAP Web AS ABAPSAP Web AS ABAP

SAP ABA 620SAP ABA 620


……



SAP JCO 2.0SAP JCO 2.0

……

......

……

InstancesInstances


SAP BBPCRM 4.0

SAP BASIS 6.20

…

CRM IPCCRM IPC

CRM IPC 4.0

CRM ...CRM ...

…

…

InstancesInstances




……

CRM IPCCRM IPC

CRM IPC 4.0CRM IPC 4.0

CRM ...CRM ...

……

……


The SAP Product and Component model is part of the overall SAP information model, which is derived from the Common Information Model (CIM) and especially from the CIM core and CIM application part (http://www.dmtf.org).

Within the model, the product and components are represented by the central information entities Product, Product Version and Instance for the external view where as Software Component and Software Component Version represents the internal development view of SAP software.


SAP AG 2009

Example: Technical Information about SAP Products 2/2

Product SAP APO

Product Version SAP APO 3.0A

Main instance 1

SAP Kernel 4.6C

SAP Basic 4.6C

SAP ABA 4.6C

SAP BW 2.0B

SAP APO 3.0A

Main instance 2

APO COM 3.0A

APO Live cache 3.0A

SAP provide a product called “Advanced Planning and Optimization”

Advanced Planner and Optimizer is designed to help a company improve production planning, pricing, scheduling, and product shipping. APO works by getting real-time updates from retailers about customer demand. The updates are used to create APO "demand triggers" that take into account many complex variables, such as the delivery schedule of raw materials and productions cycles, to forecast the right amount of product mix the company will need to meet future customer demands.

This shows the SAP APO product which is sold in Product Version SAP APO 3.0A.

This Product Version contains the Software Component Versions:

SAP APO 3.0A,

SAP BW 2.0B,

SAP ABA 4.6C,

SAP Basis 4.6C, and

SAP Kernel 4.6C.

In addition, it also contains the Software Component Versions APO COM 3.0A and APO LIVECACHE 3.0A in an additional instance (also called main/central instance). Each of these instances is formed from several independent component versions.


SAP AG 2007


The SLD acts as a central information provider for an organization‘s SAP system Software components that are currently installed. Software components that can theoretically be installed Automatic updates allow the SLD to always contain up-to-date information about the installed system

landscape. The SLD therefore provides an up-to-date Technology Baseline of installed SAP systems. The SLD also contain a PPMS/PAM dataset showing what products SAP delivers, what

components each product comprises, what interdependencies exist between single components, etc.


SAP AG 2007





Communication Intfrastructure


Network Services

Gra

phics &

Ima

ge

Da

taM

ana

gem

en

t

Data

Interch

ang

e

Intern

ation

al

Op

era

tions

User In

terface

Lo

cation

& D

irectory

Tra

nsactio

nP

roce

ssing

System

& N

etw

ork

Ma

nag

em

ent

Security

So

ftware E

ngine

erin

g

Qualities

Qua

litie

s

Qualities

Qualities







Network Services

Gra

phics &

Ima

ge

Da

taM

ana

gem

en

t

Data

Interch

ang

e

Intern

ation

al

Op

era

tions

User In

terface

Lo

cation

& D

irectory

Tra

nsactio

nP

roce

ssing

System

& N

etw

ork

Ma

nag

em

ent

Security

So

ftware E

ngine

erin

g

Qualities

Qua

litie

s

Qualities

Qualities

TRM - Business Applications (1)

SAP NetWeaver

SAP for <Industry>

SAP Enterprise Portal

SAP Master Data Mgmt

SAP Business Intelligence

SAP Exchange Infrastructure

SAP xApps

SAP xApp Resource& Program Mgmt

SAP xApp ProductDefinition

SAP xApp Mergers & Acquisition

...

SAP PackagedSolutions

Service Management for < Industry>

Financial Insights for <Industry>

...

---

...

SAP for Aerospace & Defense

SAP for Automotive

...

SAP Business Suite

SAPAll -in-One

SAP SmartBusiness Solutions

SAP Business One

SAP Business One Server

SAP ERPAnalyticsFinancials

Human ResourcesCorporate Services

Operations

SAP PLM

SAP SCM

SAP SRM SAP CRM

Regarding business applications, SAP products are distinguished into the following four product groups :

Cross-Industry Business Solutions which provide general functionality for all different types of enterprises

Specific Industry Solutions to cover specific requirements of a certain industry but which rely to a large extent on the cross-industry solutions and

Smart Business Solutions for mid-size and small companies

xApps which provide more specific functionality

This is the current SAP ordering scheme for SAP products, however it is likely to change over time.


SAP AG 2007







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities


This shows the SAP TRM for Cross-Industry Business Solutions which provide general functionality for all different types of enterprises.


SAP AG 2007







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities


This shows the SAP TRM for Cross-Industry Business Solutions which provide general functionality for all different types of enterprises.


SAP AG 2007







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities


Specific Industry Solutions to cover specific requirements of a certain industry but which rely to a large extent on the cross-industry solutions.


SAP AG 2009







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taInte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

User Inte

rface

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etwork

Ma

nag

eme

nt

Secu

rity

So

ftwa

re E

ng

inee

ring

Qualities

Qua

litie

s

Qualities

Qualities

TRM Mapping - Business vs. Infrastructure Applications

In terms of mapping to the TOGAF™ TRM, the assignment of SAP products to either the business (BA) or the infrastructure application (IA) group is in most cases not possible, as some products in one of these categories can be considered as a business application, where as others have clearly an infrastructure focus.

A well-defined decision is probably not required, so the table below indicates how the product categories currently map.


SAP AG 2007

TRM Mapping - Infrastructure Components

This shows an example of the section for SAP Infrastructure Applications (excluding Netweaver)


SAP AG 2007







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taIn

terch

ang

e

Inte

rna

tiona

l O

pe

ration

s

Use

r Interfa

ce

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etw

ork

Man

ag

eme

nt

Se

curity

Softw

are E

ngin

ee

ring

Qualities

Qua

litie

s

Qualities

Qualities







Network Services

Grap

hics &

Ima

ge

Da

taM

ana

gem

en

t

Da

taIn

terch

ang

e

Inte

rna

tiona

l O

pe

ration

s

Use

r Interfa

ce

Locatio

n&

Directo

ry

Tran

sactionP

rocessing

System

& N

etw

ork

Man

ag

eme

nt

Se

curity

Softw

are E

ngin

ee

ring

Qualities

Qua

litie

s

Qualities

Qualities

TRM Mapping - Infrastructure Components: NetWeaver







Data Unification Master-Data Harmonization Master-Data ConsolidationCentral Master-Data Management







Business Event Resolution Business Task Management










Application Governance & Security



SAP NetWeaver Operations Master-Data ConsolidationEnterprise Knowledge Management

Enterprise Service Architecture – Design & Deployment








Data Unification Master-Data Harmonization Master-Data ConsolidationCentral Master-Data Management







Business Event Resolution Business Task Management










Application Governance & Security



SAP NetWeaver Operations Master-Data ConsolidationEnterprise Knowledge Management

Enterprise Service Architecture – Design & Deployment


Notice that most of the components are part of one product SAP NetWeaver 2004 or SAP NetWeaver 2004s respectively (with a few exceptions).

From SAP’s point-of-view, a core element of the business process platform is a technical environment in which companies run their business processes.

A business process platform provides an extensible repository of enterprise services definitions, application logic that implements those services in a reusable fashion and a technology platform, the SAP NetWeaver® platform, to enable, integrate, compose, deploy and manage service-enabled applications.

As mentioned, SAP introduces a more problem oriented way to cluster the different capabilities in a problem-oriented manner. This cluster is named IT Practices. To each of these IT Practices, list of IT Scenarios is assigned to each IT Practice. IT Scenarios are approaches or possible courses of action that can be performed using SAP NetWeaver.


SAP AG 2007







Network Services

Gra

phics &

Imag

e

Data

Man

ag

eme

nt

Data

Inte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

Use

r Interface

Loca

tion

& D

irecto

ry

Tran

sactionP

roce

ssing

System

& N

etw

ork

Ma

nag

em

ent

Se

curity

Softw

are E

ngin

ee

ring

QualitiesQ

ualit

ies

Qualities

Qualities







Network Services

Gra

phics &

Imag

e

Data

Man

ag

eme

nt

Data

Inte

rcha

nge

Inte

rnatio

na

l O

pe

ration

s

Use

r Interface

Loca

tion

& D

irecto

ry

Tran

sactionP

roce

ssing

System

& N

etw

ork

Ma

nag

em

ent

Se

curity

Softw

are E

ngin

ee

ring

QualitiesQ

ualit

ies

Qualities

Qualities

TRM Mapping - Platform Services


SAP AG 2009

Benefits of the SAP Technical Reference Model

SAP as a leading application and infrastructure software vendor provides numerous software products

The Enterprise Architect needs to rapidly understand the SAP Product family and how it fits into the overall Enterprise Architecture of an organization

The TRM SAP Mapping provided as part of SAP EAF provides an ideal starting point and gives consistent definitions for SAP customers

This can be used as a basis for the development or enhancement of an organization’s own Technical Reference Model

Promotes re-use, accuracy and consistency

The SAP TRM enables an organization using the TOGAF™ TRM to enhance it with SAP products easily.


SAP AG 2009



Example Content





SAP AG 2009


Create consistent, quality architectures quicker

How can these customers accelerate their Enterprise Architecturedevelopment?

Re-use of Architecture building blocks and models

How can organization’s re-use SAP’s Product Architecture?

TOGAF™ Architecture Continuum is designed for this purpose

Need for consistent taxonomy

TOGAF™ Glossary and SAP Glossary

Need for SAP-Specific Mappings

Each TOGAF™ Content Metamodel Entity maps to a SAP-Specific Entity

Need for consistent classification of SAP Products

SAP-Specific TRM


SAP AG 2009

Other SAP Specific Mapping Documents

TOGAF™ Glossary

SAP Glossary

Overview of SAP Tools

Roadmap Composer

Solution Composer

Solution Manager

SDN ES Workplace


Product Availability Matrix


Quick Sizer

Solution Composer Whitepaper

Roadmap Composer Whitepaper

SAP Method Mapping


SAP AG 2009


How can these customers accelerate their Enterprise Architecturedevelopment ?

Re-use of Architecture building blocks and models

How can organization’s re-use SAP’s Product Architecture ?

TOGAF™ Architecture Continuum is designed for this purpose

Need for consistent taxonomy

TOGAF™ Glossary and SAP Glossary

Need for SAP-Specific Mappings

Each TOGAF™ Content Metamodel Entity maps to a SAP-Specific Entity

Need for consistent classification of SAP Products

SAP-Specific TRM


NL-R-P705 – Overview of SAP Tools provides more detail on how each Tool is applied in the SAP EAF.


SAP AG 2009

Summary

This is the end of the SAP-Specific Mappings Unit


How SAP-Specific Mappings provide significant value to TOGAF™

How TOGAF™ maps specifically to SAP Reference and Landscape Content

How the SAP-Specific Technical Reference Model enables standardization and reuse in an Enterprise Architecture

The next phase explains EA Tools for TOGAF™ and SAP EAF


Exercises

Unit: SAP Specific Mappings

Topic: Map EAF metamodel entities to SAP Content


Understand what each metamodel entity defined in SAP EAF means in SAP terms, terminology and content

Understand the relationship between entities in one architecture domain to another

Learn how each metamodel entity manifests itself into SAP content

Scenario

SAP EAF explicitly defines a metamodel that contains a set of key entities that can be utilized to describe an enterprise. It is very important to understand what each metamodel entity means in generic terms and more importantly how each of the entity can be mapped to the content, terms and terminology of the SAP world.

It is important to note that SAP terms, terminology and content have been in usage for several years prior to the launching of SAP EAF. EAF itself is an extension to TOGAF and hence it is imperative to have a good understanding of how the EAF content can be mapped to SAP content.


1-1-1 Select the same industry solution map you started with in exercise from Unit 03 (Industry solution maps can be obtained from either Solution Composer or ES Workplace on SDN website)

1-1-2 For this industry, map the following metamodel entities (given in next section) to SAP content

1-1-3 Leverage any SAP reference or your own experience & background to complete this exercise

1-2 Metamodel entities to be mapped

EAF Metamodel Entity

SAP Content or Example

Comment

Goal

Objective

Role

Function

Process

Measure







Solutions

Unit: SAP Specific Mappings

Topic: Map EAF metamodel entities to SAP Content

1-1 Solution to Metamodel entity mapping Steps for the Exercise

EAF Metamodel Entity

SAP Content or Example Comment

Goal 1) Increase revenue Represents a strategic intent

Objective 1.1) Reduce time to market by 20% (relative to today) by December 2009

1.2) Reduce Volume of products by 10% by YE 2009and

1.3) Focus on top 20% of products that yield 80% revenue

Quantified by a measure and a timeline. These objectives clearly go towards meeting the above goal

Role Procurement Officer, Receiver, Payer, AP Clerk, Buyer, Payer

Typical Roles involved in P2P process

Function Indirect Procurement

Process Procure to Pay

Measure Purchasing Values

Percentage of Purchased Orders sent via Internet

Source Cycle Time

Total Source Lead Time

Key KPIs for Procure to Pay Process


1) PCMS (Procurement Contract Management System)

2) IPM (Indirect Procurement Manager)

3) Supplier Portal

Business application name


1) PCMS v 2.0

2) IPM v 3.1

3) Supplier Portal v 4.0

Application releases that is currently in production. This is tied to business application portfolio release cycles to keep track of functionality that is constantly added to these applications



Physical Technology Components Logical



Software Hardware

UI Layer IBM HTTP Web Server Server - IBM Intellistation Pro Server

OS – Windows NT

Application Layer Custom Java Application (JDK 1.2.2)

Server - IBM P 502 Server

OS – IBM AIX 6.2

PCMS

DB Layer IBM DB2 v 7.1 Server - IBM P 502 Server

OS – IBM AIX 6.2

UI Layer SAP GUI 640 Client Workstation

Windows XP

Application Layer SAP ECC 5.0 Server - IBM P 502 Server

OS – IBM AIX 7.2

IPM

DB Layer Oracle 10.g Server – HP S5000

OS – HP-UX 11.8

Supplier Portal Application Layer SAP Enterprise Portal 7.0 Server – HP S5000

OS – HP-UX 11.8

SAP AG 2009

Unit 14 - EA Tools for TOGAF™ and SAP EAF



SAP AG 2009

EA Tools for TOGAF™

Contents:

Introduction to Enterprise Architecture Tools

TOGAF™ implementation using ARIS IT Architect


SAP AG 2009








SAP AG 2009

Lesson Objectives


Why EA Tools are important when managing an Enterprise Architecture

How TOGAF™ deals with EA Tools

How a reference implementation of TOGAF™ was implemented in ARIS IT Architect


SAP AG 2009



TOGAF™ and EA Tools

TOGAF™ implementation in ARIS IT Architect


SAP AG 2009

The Role of Enterprise Architecture Tools

Metamodel


Database Object

Database Object

DatabaseObject

Database Object

?

Reference Models



and Diagrams

Stakeholder Views

Stakeholder


Architecture

Repository


Process Modell ingExtension Data Modelling Extensio n

Business / IT Al ignmentExtension CoreConte nt






Organisat ion Unit

Goal

Objective


(Business, Information Sy stem) ServiceServ ices are Contained in Core , Bus iness / IS split supports the Business / IT Alignment Extension

Function

Process

Actor

Role


EventProcess Extensi on


Data Entity



Extension

Physical Inform ation Component

Data Extension




Logical Technology Compone nt

Infras truc ture Consolidat ionExtension

Physic al Technology Compone nt



Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Hostedin

I sHosted inIsH osted inEncapsulates

Encapsulates

Resideswithin


IsR ealised by Realises

Operateson

Is processedby

Provides, consumes


Resides wit hin

Is implemented on

P rovidesplatform forImplements

Isrealisedthrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin

Interacts with, Per forms

Performst ask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by

Provides governedinterfaceto access

Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by


Resol vesSupport s, Isrealised by

Orchestrates,

decompo

ses

Ensurescor rectoperationof

Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises

Service QualityGovern anceExtension

Appliesto

Meets

Applies to Meets

Is Performedby




Process Modell ingExtension Data Modelling Extensio n

Business / IT Al ignmentExtension CoreConte nt






Organisat ion Unit

Goal

Objective


(Business, Information Sy stem) ServiceServ ices are Contained in Core , Bus iness / IS split supports the Business / IT Alignment Extension

Function

Process

Actor

Role


EventProcess Extensi on


Data Entity



Extension

Physical Inform ation Component

Data Extension




Logical Technology Compone nt

Infras truc ture Consolidat ionExtension

Physic al Technology Compone nt



Gap Work Package

Driver

Platform Service

Owns and governs

Operates in

Operates in

Is Hostedin

I sHosted inIsH osted inEncapsulates

Encapsulates

Resideswithin


IsR ealised by Realises

Operateson

Is processedby

Provides, consumes


Resides wit hin

Is implemented on

P rovidesplatform forImplements

Isrealisedthrough

Contains

Con

tain

s

Con

tain

s

Con

tain

s

Con

tain

s

Contains

Belongs to

Co

nsum

es

Partici patesin

Interacts with, Per forms

Performst ask in

Generates, Resolves

Produces


Owns


Accesses

Can beaccessed by



Is bounded by

Provides governedinterfaceto access

Produces

IsProducedby

Involves

Part icipatesin

Involves


Generates, Resolves

IsResolved by


Resol vesSupport s, Isrealised by

Orchestrates,

decompo

ses

Ensurescor rectoperationof

Isguidedby

Governs, Measures



Is tracked against



Is trackedagainst

Is motivated by

Motivates

Creates

Addresses

Is realisedthrough

Realises

Service QualityGovern anceExtension

Appliesto

Meets

Applies to Meets

Is Performedby



We require Tools to automate and standardize the delivery of architecture models to stakeholders

By having a common metamodel and a common set of catalogs, matrices, and diagrams we can deliver these to the right stakeholders


SAP AG 2007

Why we need Tools

Easier maintenance of architecture as the business and IT landscape changes

More effective knowledge sharing across the whole organization


More effective governance of artifacts





……not unmaintained, unconnected Visio and Excel files !

We can promote consistency and one common “corporate memory” of the enterprise architecture

We can centralize unmaintained and unconnected artifacts to promote accuracy and reuse


SAP AG 2009

Consider how your EA Resource Base will integrate

Projects will tend to have their own tools and models

How do we ensure consistency and re-use ?

TestsPlans

CodeChanges,Defects,

Etc.

Models

Requirements

Project 1 repository

Visual Models

EA Process Ref Architecture

Business, Information & Technology Lists(Actions, Direction, Goals, Principles, Policy,

Services, Technology, Systems, Stakeholders, etc.)

EA Repository

TestsPlans

Code

Changes,Defects,

Etc.

Models

Requirements

Project 2 repository

TestsPlans

Code

Changes,Defects,

Etc.

Models

Requirements

Project N repository

We will concentrate on the Enterprise Architecture Resource Base in this Unit

However, Enterprise Architects will need to consider how an EA Tool is linked to Project Resource Bases


SAP AG 2009

The BPM and EA Tools markets are converging…

Sources: "Magic Quadrant for Business Analysis Tools, 2006," January 2006; "Magic Quadrant for Enterprise Architecture, 1Q06," 1Q06.

BPM Tools EA Tools

Gar

tner

®

What will be your Tools Strategy for Enterprise Architecture ?

There are many different toolsets on the market – each has different functionality

Take 10 minutes to brainstorm, the top 5 issues you see as being essential when choosing an EA Tool


SAP AG 2009

Example EA Tool Market Analysis from Forrester

Fo

rres

ter®

Market analysis from research companies such as Gartner and Forrester can be useful in order to create a short-list of vendors, but bear in mind that there may be enterprise-specific considerations that may dictate the selection of a vendor or product outside the ‘leader board’ for EA tools.


SAP AG 2009






SAP AG 2009


TOGAF™ does not require or recommend any specific tool.

In recognition of the problems that Enterprise Architects face in this area, TOGAF™ provides a set of evaluation criteria for selecting architecture tools to develop the various architecture models and views that are required.

Individual enterprises may wish to adapt these generic evaluation criteria to their particular circumstances and requirements.

An EA tool vendor/product selection exercise would typically produce weightings of the various criteria that can be used to produce a “score” for the specific tools under evaluation.

The Open Group also provides a TOGAF™ Tools Conformance Certification – in February 2009 there were 15 vendors/products certified as conforming to the TOGAF™ 8 specification. Details can be found at http://www.opengroup.org/TOGAF™/cert/select_prod.tpl

It is expected that most leading EA tool vendors/products will ultimately support the TOGAF™ 9 content metamodel and the production of catalogs, matrices and diagrams according to the TOGAF™ 9 specifications.


SAP AG 2009






SAP AG 2009

IDS Scheer ARIS Platform

ARIS Business ArchitectARIS IT ArchitectARIS IT DesignerARIS Business Publisher…

ARIS Process Performance ManagerARIS Audit Manager…

ARIS BSCARIS Business Optimizer…

ARIS for SAP NetWeaverARIS UML Designer…

IDS Scheer®

IDS Scheer provides a family of products that are useful in an Enterprise Architecture engagement.

The other tools mentioned so far provide similar equivalent modules ; for example :

Portfolio Planning

Business Modelling

IT Modelling

Publishing Content

What follows is an example of how we adapted a tool to support the TOGAF™ content metamodel.

This is not a specific recommendation from SAP for ARIS as the EA tool of choice to support TOGAF™ – any EA tool that has a user-extensible internal metamodel could be used to support the TOGAF™ metamodel.


SAP AG 2009

Mapping TOGAF™ to ARIS IT Architect - Entities

Take each TOGAF™ Content Metamodel Entity

Identify the Object within the ARIS Toolset that maps closest to that entity

Modify and extend as necessary

Phase Metamodel Object ARIS Object Type ARIS Product

Context Constraint Risk ARIS Business Architect

Context Gap Risk ARIS Business Architect

Context Location Location ARIS Business Architect

Context Principle Technical Term ARIS Business Architect

Context Requirement Technical Term ARIS Business Architect

Business Actor Position ARIS Business Architect

Business Business Service Functional Cluster ARIS Business Architect

Business Contract Information Carrier ARIS Business Architect

Business Control Function (Control) ARIS Business Architect

Business Driver Strategy/Objective ARIS Balanced Scorecard

Business Event Event ARIS Business Architect

Business Function Function ARIS Business Architect

Business Goal Objective (Strategic Objective) ARIS Balanced Scorecard

Business Measure KPI Instance ARIS Business Architect

Business Objective Objective ARIS Balanced Scorecard

Business Organization Unit Organizational Unit ARIS Business ArchitectBusiness Process Function ARIS Business Architect

SAP have provided an ARIS Reference Implementation for TOGAF™ based on ARIS IT Architect.

We have mapped each TOGAF™ content metamodel entity to the ARIS object library

We did not customize the TOGAF™ metamodel

We added the attributes we needed to the core model


SAP AG 2009

Mapping TOGAF™ to ARIS IT Architect - Diagrams

Take each TOGAF™ Diagram

Identify the View within the Toolset that maps closest to that Diagram

Modify and extend as necessary

We have mapped each TOGAF™ Diagram to the ARIS View Library


SAP AG 2007

Introducing BEEST - an Automotive OEM

An automotive company founded in 1931 Founded by Dr Ferdinand Beest One of the world’s most profitable car manufacturers 11,668 employees

Products: High performance sports cars made in Germany in the premium

segment Differentiators: performance, design and quality

Operations: Focus Areas: Design, Engine Production, Sales and Marketing Component manufacturing and final assembly partly outsourced for

some models BEEST value added: 10%-20%

Strategic Business Areas : “Aftersales” due to revenue potential (car service training and spare

parts delivery) Other business areas: Consulting, Engineering, IT and Financial

Services to external customers

We have provided an SAP EAF Case Study (which features in the SOA250 Course) and provided this as an ARIS Repository.

A demonstration of this now follows


SAP AG 2009

BEEST Case Study content using ARIS IT Architect 1/2

This screenshot shows and example of a TOGAF™ Diagram using ARIS with the BEEST case study content


SAP AG 2009

BEEST Case Study content using ARIS IT Architect 2/2

This screenshot shows and example of a TOGAF™ Diagram using ARIS with the BEEST case study content


SAP AG 2009

Summary

This is the end of the EA Tools for TOGAF™ and SAP EAF Unit


Why EA Tools are important when managing an Enterprise Architecture

How TOGAF™ and SAP EAF deal with EA Tools

How a reference implementation of SAP EAF was implemented in ARIS IT Architect

Congratulations, this is the end of the SOA200 – SAP Enterprise Architecture Framework Level 1 course !
