isaca belgium architecture frameworks

ISACA BENEW YEAR EVENT 2011

JL ALLARD & ERIC MICHIELS

ArchitectureS

2

Architectures

29/01/2011ISACA Belgium, New Year Event 2011

Objectives Introduce architecture Introduce the 3 main models Motivate to start using them

when needed with the appropriate energy

3

Agenda

IntroductionEnterprise Information Architecture Model

(Zachman)Enterprise Security Architecture Model

(SABSA)Coffee pauseEnterprise IT Architecture Model

(TOGAF)Q&A


4

Introduction

Is this architecture?

Do not take the result of an activity for the activity itself


5

Introduction

Reason for architecture Seven thousand years of human history would

establish that the key to complexity and change is Architecture.

Architecture is a REPRESENTATION of the need The models

The models are recommended to make sure that what you build will respond to the complete need

Only the real context will indicate if you need to complete and document the full model Some ‘upper’ steps can be simplified, not by-passed!


6

Agenda




(TOGAF)Q&A


7

EIA Zachman


8

EIA - Zachman


The thinking part

The realization part

9

EIA1

Vertical dimension What: the inventory of information How: the [information] process(es) Where: the network, relationships, exchanges Who: the organization When: the timing Why: the motivation

Unlimited model (cyclinder)


10

EIA1

Contextual Level Scope, strategist & planner perspective The context that establishes the universe of discourse,

the inner and outer limits, the list of relevant constituents that must be accounted for in the descriptive representations (models) for the remaining Perspectives.

ENTERPRISE ARCHITECTURE OBJECTIVES, Gross Sizing, Scope

DESIGN ARTIFACTS BUBBLE CHARTS, Gross Sizing, Shape, Spatial

Relationships


11

EIA - Contextual

Examples A bank A school A lawyer firm A media A church (& Cie)

Use different information, processes, networks, organizations, motivations, timings


12

EIA – Practical Example


How to build confidence across EU in the identity management of natural persons? Initial idea

compare procedures based on BE vision + risk assessment

Try to define a ‘generic’ process Describe BE implementation Build a questionnaire

Describe concrete implementation Identify risk

Compare and decide

13

EIA –My experience


The ‘big picture’ What: 4 fundamental documents Who: actors -

Public: administration Private: Individuals, public ‘users’

Where: 2 locations and 3 communication channels Local & Central Administrations, Between persons & administrations, between administrations

How: 4 processes – When: permanent or ah-hoc Why: gain trust and prevent fraud & identity theft

Took about one hour to identify and 4 to document.

14

EIA2

Conceptual Level The Business, Executive & Owner perspective The recipient (customer) view of the end product, (e.g.

airplane, house, Enterprise, etc.). These descriptive representations reflect the usage characteristics of the end product, what the Owner(s) are going to do with the end product, or how they will use it once they get it in their possession. This is a view of what the Owner can think about relative to the use of the end product.

ENTERPRISE ARCHITECTURE MODEL OF THE BUSINESS, Enterprise as Seen by the

"Owner“ DESIGN ARTIFACTS

ARCHITECT'S DRAWINGS, Building as Seen by the Owner


15

EIA - Conceptual

Exemples Stadion - all sports have their own ‘design’:

Soccer, Football, Baseball, Athletics, Tennis, Basket ball, etc.

The ‘number’ of attendees The ‘money’ & technology available The city where it’ll take place (it must & will fit) The surrounding landscape


16

EIA - Conceptual


Church – all religions have their specificities Segregation priests/people; men/women The number of attendees The ‘money’ & technology available The city and landscape where it’ll take place (it must &

will fit)

17

EIA2 – Practical Example


Processes Process1: 3 activities Process2: 3 activities Process3: 4 activities Process4: 2 activities

Documents New information and documents

Actors: complete list + witness (& conditions)

Channels: 1 more + characteristics

Motivations: more detailed

Time needed: 5 days & discussions to draw.

18

The result?

Site survey in 8 countriesReport

Summary, SWOTWhy not deeper?

National cultures are different Similar concepts differentey implemented

Logical level (see next) too detailedWhat effect?

Support by European CommissionWhat next?

Exploit results Propose acceptable solutions


19

ISACA Belgium, New Year Event 2011

EIA3

Logical level The System, Architect, Designer, Engineer perspective The intermediary between what is desirable (Row 2) and what is

physically and technically possible (Row 4). … reflects the laws of nature, the system, or logical constraints for the design of the product. The logical view of the end product.

For Enterprises, this is the logical representation of the Enterprise which forms the basis for the white collar system, the recordkeeping system, of the Enterprise as well as the basis for the design of the blue collar system, the material manipulation system for manipulating the tangible aspects of the Enterprise.

ENTERPRISE ARCHITECTURE MODEL OF THE "SYSTEMS“, (the "Systematic Model"), Enterprise as

Seen by the "Designer“ DESIGN ARTIFACTS

ARCHITECT'S PLANS, Building as Seen by the Designer

29/01/2011

19

20

EIA3 - Logical

Exemples A house

Urbanism & technology requirements Harmonization with the landscape Roads and facilities (Electricity, Gas, Water, Drains) Garage or not Office or not? How many floors?

Drawings (both Conceptual and Logical)


21

EAI

Lower levels The most complex & tricky The most known and used No need for examples


22

EIA4


Technology, Engineer, Builder, Physical perspective The manufacturing Engineer, the General Contractor,

the employer of some technical capacity for producing the end product. These descriptive representations reflect the physical constraints of applying the technology in the construction of the product.

Contractor’s plan / Technology model drawings as constrained by Nature and Available

Technology (Building as Seen by the Builder)

INFRASTRUCTURE

23

EIA5


The Detailed representation Technician, Component, Subcontractor, Out-of-Context

perspective Detailed description that disassociates the parts or pieces of the

complex object for manufacturing purposes. This is the area of the configuration of the needs and means to respond to demands.Plays a part in the transformation from the media of the design (paper and ink or e-) of the product to the media of the end product itself (documents, voice, image, computers & networks).For Enterprises, these are the product specifications relating the technology constraints of Row 4 to the vendor products in which the technology constraints are materialized.

SHOP PLANS Descriptions of Parts/Pieces

24

EIA6


The ‘Functioning Enterprise’ The Worker, Operations perspective The physical manifestation of the end product itself.

The end result of the Architectural process. Although, technically, Row 6 is not Architecture

because it is not a representation (it is the actual thing), it is useful to incorporate it into the Framework graphic as it completes the Architectural picture.

The end object is to ensure that Row 6 represents what the Owners have in mind for the Enterprise at Row 2. The realization of the Concept

25

Agenda




(TOGAF)Q&A


26

ESA - SABSA

Sherwood Applied Business Security ArchitectureBorn 1995

Sarting point : ISO 7498-2 (open system interconnection), the 3 lower layers

Readjusted based on EIA Zachman (1999)Focus:

Enterprise Security Architecture Enterprise Security Service Management

With attributesAn © open-use model & methodology

From Business requirements to controls Ensures traceability across the model


27

ESA - Relations


Zachman SABSA

The Business View Contextual Security Architecture

The Architect’s View Conceptual Security Architecture

The Designer’s View Logical Security Architecture

The Builder’s View Physical Security Architecture

The Tradesman’s View Component Security Architecture

The Facilities Manager’s View Operational Security Architecture

28

ESA


Management

Governance

Technical

29

ESA matrix


30

ESA for Security Service Mgt


The content of the ‘transversalOperational layer

31

ESA – Development process


Natural break for signed approval

Don’t go straight to

select & implement solution!

Life-cycle:- Strategy & Concept- Design- Implement- Manage & measure

32

ESA - Business Attributes


ManagementOperationalRisk ManagemetLegal/regulatoryTechnical strategyBusiness strategyUser

Accessible, accurate, consistent, current, duty segregated, educated & aware, informed, motivated, reliable, supported, timely, usable

Information = missing? And the information attributes?

33

ESA – my view

Contextual What: What should be protected (key information & activities) Why: What’s at stake? Need for Security? Feared Events How: Security principles and standards to apply Who: Involvement of C-Suite, backbone of Security organization Where: Most important places to protect and central place for security

management/governance; network with externals When: Delays, target dates, calendars

Conceptual: What: List of information processes and inventory of information Why: Risks to business objectives (short, mean, long term) How: General Security Policy Who: Key security actors & place in the organization +

communication channels Where: SGeneric security rules for the involved domains When: Recovery & Backup, generic action plan


34

ESA – unique selling points


Business Driven Enabling Business Usability

Holistic Approach Adding Value Inter-operability

Fit-for-Purpose Empowering Customers Supportability

Measurable Protecting Relationships Integration

Return on Investment Leveraging Trust Low Cost Development

Risk-based Cost / Benefit Assurance Scalability of Platforms

Managing Complexity Governance Scalability of Cost

Providing a Roadmap Compliance Scalability of Security

Simplicity & Clarity Fast Time to Market Re-usability

Lower Cost of Ownership Lower Operations Costs Lower Administration Cost

35

Enterprise Architecture

Zachman and SABSA offer Detailed guide Education Certification

www.zachmanframeworkassociates.com/ Wikipedia paper : correspondance with other

architecture modelswww.sabsa-institute.org/www.sabsa.org


http://www.zachmanframeworkassociates.com/

http://www.sabsa-institute.org/

http://www.sabsa.org/

36

Roles of architecture

Managing complexityProviding a framework & road mapSimplicity & clarity through layering &

modularisationBusiness focus beyond the technical domain


37

Benefits of Architecture (1)


Architecture delivers modular, re-usable technical infrastructure, effective operational and management processes, and meets a broad spectrum of business requirements for systems, including:

Usability The solution must be appropriate to the technical competence of the intended users and ergonomically acceptable to those users

Inter-Operability

The solution must provide for the long-term requirements for inter-operability between communicating information systems and applications

Integration The solution must integrate with the wide range of computer applications and platforms for which it might be required in the long term.

Supportability The solution must be capable of being supported in the environment within which it has been designed to be used.

Low Cost Development

The solution should be of modular design and hence capable of being integrated into a development programme at minimal cost.

Fast Time to Market

The solution should be capable of being integrated into a development programme with minimal delay.

38

Benefits of Architecture (2)


Scalability of Platforms The solution should fit with the range of computing platforms with which it might be required to integrate.

Scalability of Cost The entry-level cost should be appropriate to the range of business applications for which the solution is intended.

Scalability of Security Level

The solution should support the range of cryptographic and other techniques that will be needed to implement the required range of security strengths.

Re-Usability The solution should be re-usable in a wide variety of similar situations to get the best return on the investment in its acquisition and development.

Lower Operations and Administration Costs

The cost impact on systems operations should be minimised and the solution should provide an efficient means for administration to optimise the costs of this activity

39

Agenda




(TOGAF)Q&A


40

Agenda




(TOGAF)Q&A


41

TOGAF

The Open Group Architecture FrameworkTopics in this section

o Enterprise Architectureo The Open Group and Architectureo TOGAF in a “Nutshell”o TOGAF Relationship with other Frameworkso TOGAF Relevance

ObjectivesAt the end of my section, ask yourself:

“Should I learn/read more about TOGAF?”“Should I adopt TOGAF concepts”

“How to introduce TOGAF concepts in my context?”


42Enterprise Strategy

Fire and hope!

Enterprise Architecture

Business Operating Environmentand IT Infrastructure

TransitionPlanning

Group IT Architecture Definition

Infrastructure Design & Planning

Establish IT Competency Centre

End User Infrastructure Upgrade

Inter-company WAN (imple.)

Outsource New Core systems

Outsource Helpdesk and Desktop

Outsource network

Outsourcing Initiatives

Competency Centre Initiatives

Electronic Service Delivery

Data Warehouse

Customer Service Centre

Recognise and report problem

Diagnose problem

Escalate problem

Analyse problem

Log Problem

Close problem

Update customer

Resolve problem

Bypass and/or fix

Config. Management

Operations Management

Change Management

Call management

Operations management

Update customer

Perf and Capacity management

WAN infrastructureIntranet/Mail infrastructure

Customer ServiceData Warehouse

Graphical IS

B.U.B.U.

Document Management

Systems Management

Middleware

NETWORK

Planning/Design Initiatives

Infrastructure Initiatives

OtherBusiness Unit SystemsKiosksTelemetry systemsetc

Initiatives focused on migrating to the new delivery environment

Planning/DesignInfrastructureOutsourcing

Initiatives focused on implementing the vision

Planning/designIT Competency centre

Key Group Decision Points

ArchitectureGovernance

BusinessArchitecture

IT Architecture

AEICorporate

YankeeGroup

SaturnGroup

YarnDivision

KnitsDivision

SenecaPlant

RaleighPlant

CashManagement

Shipping

Accounting

ComponentDesign

Yarn Buying

Order Entry

ComponentScheduling

YarnDyeing

Inventory

AssortmentPlanning

ComponentKnitting

Tagging & Packing

Business Structure

Business Locations

Pro

gra

m

focu

sE

nte

rpri

se w

ide f

ocu

s

Strategy

Planning

Designand

Delivery

Change Programs

Soln Outline Macro DesignMicro Design Devt, etc.

Programme ArchitectureGroup IT Architecture Definition







Outsource network




Data Warehouse



Diagnose problemEscalate problemAnalyse problemLog Problem

Close problemUpdate customer Resolve problem

Bypass and/or fixConfig. Management

Operations ManagementChange Management

Call managementOperations management

Update customer


WAN infrastructureIntranet/Mail infrastructureCustomer ServiceData Warehouse

Graphical IS

B.U. B.U. Document Management

Systems ManagementMiddleware

N E T W O R K



OtherB u sin ess U n it

S ys tem s

K io sks

Te lem etry sys tem s

etc


P lann ing /D es ign

In fras truc tu re

O u tsou rc ing


P lann ing /des ign

IT C om pe tency cen tre


Soln Outline Macro DesignMicro Design Devt, etc.

Programme ArchitectureGroup IT Architecture Definition







Outsource network




Data Warehouse



Diagnose problemEscalate problemAnalyse problemLog Problem

Close problemUpdate customer Resolve problem

Bypass and/or fixConfig. Management

Operations ManagementChange Management

Call managementOperations management

Update customer


WAN infrastructureIntranet/Mail infrastructureCustomer ServiceData Warehouse

Graphical IS

B.U. B.U. Document Management

Systems ManagementMiddleware

N E T W O R K



OtherB u sin ess U n it

S ys tem s

K io sks

Te lem etry sys tem s

etc


P lann ing /D es ign

In fras truc tu re

O u tsou rc ing


P lann ing /des ign

IT C om pe tency cen tre


Enterprise Architecture = “the city plan”

System Design= “the buildings”

Strategy = “the city’s purpose & goals”Technology

AvailabilityBusiness

OpportunityBus Strategy IT Strategy

“Enterprise Planning and Strategy”

An IBM View on Enterprise Architecture (EA)


43

EA According to IBM

Enterprise Architecture (EA) provides the business with IT capabilities for:o Managing the life cycle and value of current systems o Adding new systems and their infrastructure

As an integral part of the strategic planning process, the EA is the linkage between the business strategy, IT strategy and IT implementation

EA guides investment, cost reduction and design decisions to support the goal of optimizing return on IT investments (ROI)

EA specifies processes, standards, interfaces and common services for the deployment and management of IT assets that support business objectives

Enterprise Architecture defines an environment in which infrastructure and solutions can be built for both known and unforeseen future requirements

IBM believes that an Enterprise Architecture provides the vital linkages between “strategy” and “implementation” to support a

customers goal for aligning business and IT


44

The Open Group

Vision of Boundary-less Information Flow – with EA as a critical element for making the vision a reality, the TOGAF ADM provides an important toolset

“Making Standards Work” – extensive experience and track record in facilitating consensus to develop standards and operating a premier certification service

The Open Group works with customers, suppliers, consortia, and other standards bodies to

Capture, understand, address current and emerging requirements, establish policies, share best practices

Facilitate interoperability, develop consensus, evolve and integrate specifications & open source technologies

Offer a comprehensive set of services to enhance the operational efficiency of consortia Operate the industry’s premier certification service

Motif DCE (Open DCE)

AQRM

MILSForums

Architecture Platform Security

Identity Management Enterprise Management

Real Time and Embedded Systems

Core Technology Methods & Best Practices

SOA-WG

Certifications• UNIX• LDAP• WAP• S/MIME• ITAC / ITSC• NASPL

LDAP / CCI

http://www.opengroup.org/sanfrancisco2008/

Architecture Practitioner Conferences


45

TOGAF is …..

An Enterprise Architecture FrameworkA generic framework for developing architectures to meet different

business needsNot a “one-size-fits-all” architectureDescriptive and not proscriptive (where possible)

One of the most accepted and “most popular” Enterprise Architecture frameworks

Vendor independentDeveloped and evolved by members of The Open Group

Architecture Forum Often used “in tandem with” other methods

Zachmann FrameworkRUPDODAF / MODAF

There is an increasing market demand for TOGAF Certified Architects

TOGAF Case Studies: Open Group web sitehttp://www.opengroup.org/architecture/togaf8-doc/arch/chap35.html


46

1994: Requirement 1995: TOGAF Version 1 1996: TOGAF Version 2 1997: TOGAF Version 3 1998: TOGAF Version 4 1999: TOGAF Version 5 2000: TOGAF Version 6 2001: TOGAF Version 7 2002: TOGAF Version 8 2003: TOGAF Version

8.1 2006: TOGAF Version

8.1.1 2009: TOGAF Version 9

TOGAF, the “de facto” Enterprise Architecture

standard


47

What does TOGAF Version 9 contain?

• Central to TOGAF is the Architecture Development Method (ADM) – a step by step approach to develop an EA

• The method is supported by a number of Guidelines and Techniques

• The Architecture Content Framework is a structured metamodel for architectural artifacts, ABBs, deliverables

• This produces content to be stored in the repository which is classified according to the Enterprise Continuum

• The repository is initially populated with the TOGAF Reference Models

• The Architecture Content Framework discusses the roles and responsibilities required to stablish and operate an architecture practice


48

The ArchitectureDevelopment Method

The core of TOGAFA proven way of developing

an architectureSpecifically designed to

address business requirements

An iterative methodA set of architecture views to

ensure that a complex set of requirements are adequately addressed

The ADM supports the concept of iteration at three levels: Cycling around the ADM Iterating between phases Cycling around a single phase


49

ADM Phases Overview

TOGAF Document Categorization Modelo A model to structure release

management of the TOGAF specification itself

Content of the TOGAF specification is categorizedo TOGAF Core: fundamental

concepts that form the essence of TOGAF

o TOGAF Mandated: normative parts of TOGAF. Elements considered central to its usage, without which the framework would not be TOGAF

o TOGAF Recommended: a pool of resources referenced in TOGAF as ways in which Core and Mandated processes can be accomplished

o TOGAF Supporting: additional resources not referenced in the other three categories


50

Deliverables, Artifacts and Building Blocks

Deliverables Formal products Contractually specified Outputs from a project A deliverable can

contain many artifacts Building blocks

Components that can be combined with other building blocks to deliver architectures and solutions

Can be defined at various levels of detail

ABBs: describe required capability shaping the …

SBBs: represent the components to be used to implement the required capability

Artifacts Fine grained products describing an architecture from

a specific viewpoint Examples: use-cases, architectural requirements,

network diagrams, etc. Classified as:

Catalogs (lists of things) Matrices (showing relationships between things) Diagrams (pictures of things)

Artifacts make up the content of the Architecture Repository


http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/02_concepts1.png

51

The Enterprise Continuum

Sets the broader context for the Architect Explains how generic solutions can be leveraged and specialized in

order to support requirements of an individual organization Provides a view of the Architecture Repository that shows the

evolution of the related architectures from GENERIC to SPECIFIC, from ABSTRACT TO CONCRETE, from LOGICAL to PHYSICAL


http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/39_entcon_oview.png

52

Architecture Repository

Supports Enterprise Continuum

Stores different classes of Architectural Output at different levels of abstraction

These outputs are created by the ADM


http://www.opengroup.org/architecture/togaf9-doc/arch/Figures/02_concepts3.png

53

Interaction between TOGAF and other Management Frameworks

Two key elements of EA Framework

Definition of deliverables

Description of method for production

Popularity of TOGAF:Can be used in conjunction with any of other popular frameworks (ITIL, CMMI, COBIT, PRINCE2, PMBOK, MSP, ...)

Framework-agnostic: fill in the framework you already have


54

Synergy between Frameworks

Zachman Framework

Federal Enterprise Architecture Framework

TOGAF ADMArchitecture Development Method

Other Frameworks

Support orGuidance

There is no “one size fits all” framework “TOGAF ADM is strong in process aspect” “Zachman is strong in the area of EA Models” “FEAF is performance based” “DODAF focuses on Composite Models”

Often, organizations adopt several frameworks and methodologies and integrate that with their own solutions delivery practice


55

Where TOGAF meets RUP

TOGAF is not an alternative to RUP Although many models and subjects are held

in common between the two frameworks They have different drivers and purposes

RUP is technology architecture-driven TOGAF is business architecture-driven In RUP, business requirements are gathered

to design and deliver a software-based system

In TOGAF technology is seen as a way to realize a business vision

The purpose of RUP as a Software Development Life Cycle (SDLC) methodology is to support timely and effective applications delivery

TOGAF's purpose is to support enterprise architecture implementation and maintenanceArticle by Vitalie Temnencohttp://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html

BA, ISA, TA handed over to implementation teams

Artifact Flow between

TOGAF and RUP


56

TOGAF in Eclipse Process Framework

EPF and TOGAF (Armstrong Process Group)• http://www.aprocessgroup.com/news/apg_atpl_launch.asp• http://www.aprocessgroup.com/togaf/published/index.htm


57

ArchiMate as EA Modeling Langauge

This results in this language framework:1. The Business layer offers products

and services to external customers, which are realised in the organization by business processes (performed by business actors or roles)

2. The Application layer supports the business layer with application services which are realised by (software) application components

3. The Technology layer offers infrastructural services (e.g., processing, storage and communication services) needed to run applications, realised by computer and communication devices and system software

Due to the heterogeneity of the methods and techniques used to document the architectures, it is very difficult to determine how the different architectural domains are interrelated

For optimal communication between domain architects, needed to align designs in the different domains, a clear picture of the domain interdependencies is indispensable

Conclusion: a language for modelling Enterprise Architectures should focus on inter-domain relations


58

ArchiMate and TOGAF ADM

TOGAF’s scope is broader and in particular addresses more of the high-level strategic issues and the lower-level engineering aspects of system development ArchiMate is limited to the Enterprise Architecture

level of abstraction and refers to other techniques both for strategies, principles and objectives, and for more detailed, implementation-oriented aspects

Although there is no one-to-one mapping between ArchiMate viewpoints and TOGAF there is a fair amount of correspondence, but there are also some mis-matches

TOGAF views are confined to a single architectural layer ArchiMate viewpoints that deal with the relationships between architectural layers,

such as the product and application usage viewpoints This is where ArchiMate could nicely complement TOGAF


59

Yes

No

Yes

TOGAF 8 Certified?

StepwiseDevelopment? TOGAF 9

Certified

TOGAF 9 Foundation

TOGAF 8-9 Advanced Bridge Exam

TOGAF 9 Part 2 Exam

No

TOGAF 9 Part 1 Exam

SampleSample

TOGAF 9Combined Part 1 & Part 2 Exam

TOGAF Adoption by Professionals

100 %

80 %

60 %

40 %

20 %

0 %

TOGAF Demand TrendThe chart provides the 3-month moving total beginning in 2004 of permanent IT jobs citing TOGAF within the UK as a proportion of the total demand within the Processes & Methodologies category.

TOGAF Certification Path


60

Conclusions around TOGAF

Adoption and use of TOGAF An effective, industry standard framework and method for

Enterprise Architecture Vendor, tool, and technology neutral Complementary to, not competing with, other frameworks

Participation in the Architecture Forum Worldwide forum for Architecture practitioners Network with peers and industry experts Allows to contribute to, and leverage “work in progress” Help further development of Enterprise Architecture as a

discipline and a profession

A growing number of vendors support TOGAF with methods, tools, education and certification


61

Thank You for Your Attention

Eric MichielsOpen Group Distinguished Chief ArchitectTOGAF 9 Certified [email protected]
