Architecture Frameworks Overview

Danial Ashmun PE March 2011

Architecture Overview:

Agenda
Context Frameworks Overview Life, the Universe, and Architecting DoD Architecture Framework TOGAF Zachman Frameworks FEAF ATAM Summary
Page 2

Architecture Overview:

Context Why Do We Need Architectures?

Mission Assurance Global Information Grid
critical competency for developing highly complex systems next generation, net-centric systems-ofsystems require formalized architecting approach requires use of DoD Architecture Framework (DoDAF) for all architectures developed by and for the Office of Secretary of Defense (OSD) mandates enterprise architecture development for all Departments/Agencies/ Offices/Administrations December 2008 update (note the shall): Program managers shall employ MOSA [Modular Open
Systems Approach] to design for affordable change, enable evolutionary acquisition, and rapidly field affordable systems that are interoperable in the joint battle space.

2004 DoD Mandate Memo

Office of Management & Budget DoD Instruction 5000.02

Architecture: Integral to Good Engineering

Page 3

So Many FrameworksSo Little Time

Framework
ACTIF AF-EAF CAF DAF DoDAF E2AF FEAF IAF* --MODAF NAF TEAF TISAF TOGAF Zachman Architecture cadre des Transports intelligents en France [Framework Architecture for Intelligent Transport in France] (US) Air Force Enterprise Architecture Framework (US) C4ISR Architecture Framework (Australian) Defence Architecture Framework (US) Department of Defense Architecture Framework Extended Enterprise Architecture Framework (US) Federal Enterprise Architecture Framework Integrated Architecture Framework Gartner Group Framework Index Architecture Framework (UK) Ministry of Defence Architecture Framework NATO C3 Systems Architecture Framework (US) Treasury Enterprise Architecture Framework (US) Treasury Information Sys Architecture Framework The Open Group Architecture Framework Zachman Framework for Enterprise Architecture

Focus Area
Methodology, Reference Architecture Development/Investment Guide Product Descriptions Product Descriptions Product Descriptions Classification, Methodology Components, Levels Methodology Classification/Organization Classification/Organization Product Descriptions Product Descriptions, COE, TRM, Development/Investment Guide Development/Investment Guide Methodology, TRM, Classification/Organization
COE Common Operating Environment TRM Technical Reference Model Page 4

*Proprietary to CapGemini

Architecture Certifications
Federal Enterprise Architecture Certification (FEAC) Institute www.feacinstitute.org Raytheon: 8 Federal, 26 DoDAF (in IIS & NCS) Lockheed-Martin : 100+ graduates Zachman International http://www.zachmaninternational.com/index.php/zachman-certified Zachman Certified Enterprise Architect The Open Group IT Architect Certification (ITAC); http://www.opengroup.org/itac TOGAF Certification; http://www.opengroup.org/togaf/cert Software Engineering Institute
http://www.sei.cmu.edu/training/certificates/architecture/index.cfm Software Architecture Professional Certificate Program ATAM Evaluator and Lead Evaluator Programs

Sun Microsystems Oracle Certified Master, Java EE 5 Enterprise Architect

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=326

ASD(NII)/DoD CIO Architecture & Interoperability Directorate Early stages defining competency & certification criteria for a DoD Architect
Page 5

Collaboration
Office of Assistant Secretary of Defense Networks and Information Integration (ASD/NII)
DoDAF 2.0 Working Group DoD Certified Architect program (upcoming)

The Open Group

Architecture Forum, Real-Time Embedded Systems Forum, SOA Working Group TOGAF/DoDAF Analysis; white paper published in Jan 07

International Council on Systems Engineering (INCOSE)

Architecture Working Group

Software Engineering Institute (SEI)

Assessment of Architecture Competency of Organizations Software and Systems Architecture initiatives Mission analysis approaches

Object Management Group (OMG)

Systems Modeling Language (SysML) UML Profile for DoDAF & MODAF (UPDM)

Zachman International
Mission analysis approaches New training and certifications

Page 6

Life, the Universe, and Architecting

The Language The Art Resources

Page 7

Life, the Universe, and Architecting:

The Language (Industry Context)

ISO 42010*: Systems and Software Engineering Architecture Description
Sep 2000 Aug 2001 July 2007 Oct 2009 Mar 2010 IEEE 1471-2000 published ANSI adopts 1471-2000 ISO/IEC 42010:2007 ISO/IEC Committee Draft 7 (42010) ISO/IEC Committee Draft 21 out for comments

*Legacy IEEE 1471-2000: Recommended Practice for the Architecture Description of Software Intensive Systems
Page 8

Life, the Universe, and Architecting:

The Language
Architecture The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. ISO/IEC 42010:2007; IEEE 1471:2000 A resource that guides the development or description of an architecture A perspective of the overall architecture reflecting enterprise mission, strategies, goals, business drivers, business processes, information flows, and the supporting organizational structure An organization (or cross-organizational entity) supporting a defined business scope and mission (A Practical Guide to Federal Enterprise Architecture, 2001) The interrelation and integration of a Business Architecture and Technical Architecture, including as-is and to-be states with migration plan(s) A high-level system design free of implementation details; an architecture template A set of architectural guidelines focused on a specific aspect of an architecture (technical, business, services, data, performance) A perspective of the overall architecture reflecting the enterprises data, applications and technical components

Architecture Framework Business Architecture

Enterprise

Enterprise Architecture Reference Architecture Reference Model Technical Architecture

Page 9

Life, the Universe, and Architecting:

The Art of Systems Architecting

Dr. Mark Maier Dr. Eberhardt Rechtin Heuristics Categories Multitask, Scoping and Planning, Modeling,
Prioritizing, Aggregating, Partitioning, Integrating, Certifying, Assessing, Re-Architecting

Chapter 13: The Political Process and Systems Architecting Dr. Brenda Forman, Lockheed-Martin Corporation (retired) Facts of Life
Politics, not technology, sets the limits of what technology is allowed to achieve. Cost rules. A strong, coherent constituency is essential. Technical problems become political problems. The best engineering solutions are not necessarily the best political solutions.

Page 10

DoD Architecture Framework: Agenda

History Format Views & Viewpoints Summary

Page 11

DoDAF: History
Beginning in the early 1990s, the Department of Defense directed studies for ensuring interoperable and cost-effective military systems USAF Scientific Advisory Board Study, Summer 1993 Army Science Board study, early 1994 Defense Science Board study, 1994-95 Their recommendation: Undertake the development of architectures as the basis for acquisition An emphasis was placed on enterprise interoperability through architecture process and common architecture definition syntax

Page 12

DoDAF: History (2)

1996 1997 1998 1998-2003 2003 2004 Feb 2004 Feb released 2006 Sep 2007 Apr 2009 May C4ISR Architecture Framework 1.0 released C4ISR Architecture Framework 2.0 released CAF mandate memo released Interim DoDAF versions released DoD Architecture Framework 1.0 final draft released DoD Architecture Framework 1.0 released DoD Architecture Framework mandate/promulgation memo DoDAF 1.5 Final Draft released DoDAF 1.5 released DoDAF 2.0 released

Related Initiatives DM2: DoDAF Meta-Model (replaces Core Architecture Data Model) LISI: Levels of Information Systems Interoperability

Page 13

DoDAF: Views, Viewpoints

DoDAF 1.0
4 Views

All (AVs) Operational (OVs) Systems (SVs) Technical Standards (TVs)

DoDAF 1.5
4 Views

All (AVs) Operational (OVs) Systems (SVs) Technical Standards (TVs)

DoDAF 2.0
8 Viewpoints

All (AVs) Capability (CVs) Data & Information (DIVs) Operational (OVs) Project (PVs) Service (SvcVs) Standards (StdVs) Systems (SVs)

26 Products

29 Products

52 Products

DoDAF 2.0 uses ISO/IEC 42010 terminology

Page 14

DoDAF: Key Resources for Product Creation

Data Element Definition Tables in DoDAF 1.0 & 1.5, Volume II DoDAF 1.0 Deskbook DoDAF 2.0 Journal
http://cio-nii.defense.gov/sites/dodaf20/journal_exp3.html

Page 15

DoDAF 2.0 Viewpoints

Page 16

Summary of DoDAF
Remember
DoDAF 1.0 specifies 26 architecture products collected into 4 Views DoDAF 1.5 specifies 29 architecture products collected into 4 Views DoDAF 2.0 specifies 52 architecture products collected into 8 Viewpoints DoDAF is the evolution of the C4ISR Architecture Framework (CAF), first published in 1996 DoDAF does not specify modeling notation or methodology Key resources to develop DoDAF products: DoDAFs Data Element Definition Tables (1.0 and 1.5) DoDAF 1.0 Deskbook On-line Journal: http://cio-nii.defense.gov/sites/dodaf20/journal_exp3.html DoDAF 2.0 Web Site: http://cio-nii.defense.gov/sites/dodaf20

Page 17

TOGAF: Agenda
The Open Group TOGAF: History TOGAF: Format TOGAF: Parts 1 - 4 Tools, Training & Resources Summary

Page 18

TOGAF: The Open Group

A global consortium of industry, government, and academia with more than 350 member companies
http://www.opengroup.org

Key Activities
Defining, integrating and evolving standards to support Open systems
e.g., the UNIX specification

Certification Authority for

UNIX, POSIX, LDAP, DII COE, CORBA, WAP, S/MIME

Conformance testing

Established in 1996 through the merger of

X/Open Company Ltd. (founded in 1984) Open Software Foundation (founded in 1988)
Page 19

TOGAF: A Brief History

Started with DoDs Technical Architecture Framework for Information Management (TAFIM) Millions of $$, several years spent on its development TAFIM 3.0 transitioned from DoD to The Open Group in 1995
Preliminary: Framework & Principles

Renamed to TOGAF The Open Group leveraged from Volumes 2 & 3 of TAFIM Release History First 7 versions released annually; focused on Technical Architecture Version 8.0 and beyond extended into Enterprise Architecture Version 8.1 released at end of 2003 Version 8.1.1 released at end of 2006 Version 9 released February 2009 There are Licensing & Membership guidelines for its use know them! If using TOGAF in developing a system/enterprise for a customer,
you must either have a commercial license, or be a member of the Architecture Forum
Phase A: Architecture Vision Phase H: Architecture Change Management Phase B: Business Architecture

Phase G: Implementation Governance

Requirements Management

Phase C: Information Systems Architecture

Phase F: Migration Planning Phase E: Opportunities & Solutions

Phase D: Technology Architecture

A comment on the IT verbiage (broad context) TOGAF uses the term IT to distinguish our type of architect from a civil architect
Page 20

TOGAF: Format
704 pages HTML on-line @ open group web site http://www.opengroup.org/architecture/togaf9-doc/arch Hardcopy The Open Group also publishes a bound version, available from their web site Sections Part 1: Introduction Part 2: Architecture Development Method (ADM) Part 3: ADM Guidelines & Techniques Part 4: Architecture Content Framework Part 5: Enterprise Continuum and Tools Part 6: TOGAF Reference Models Part 7: Architecture Capability Framework Part 8: Appendices
Page 21

TOGAF - ADM
Preliminary: Framework & Principles

Architecture Development Method (ADM) General

Primary focus of TOGAF Step-by-step instructions on how to architect

Phase A: Architecture Vision Phase H: Architecture Change Management Phase B: Business Architecture

Sections
Introduction Phases Preliminary through H Architecture Requirements Management

Phase G: Implementation Governance

Requirements Management

Phase C: Information Systems Architecture

Phase F: Migration Planning Phase E: Opportunities & Solutions

Phase D: Technology Architecture

Page 22

TOGAF: Architecture Views

http://www.opengroup.org/architecture/togaf9-doc/arch/chap35.html TOGAF views Versus DoDAF productsand viewpointsand. models.and. Some TOGAF Views Business Views Enterprise Security View System Engineering View Software Engineering View Communications Engineering View Data Flow View Enterprise Manageability View Acquirers View

Page 23

TOGAF: Tools, Training & Resources

Tools

IBM/Telelogic/Popkin System Architect Sparx Systems Enterprise Architect Metastorm ProVision <others as certified>
Phase H: Architecture Change Management Preliminary: Framework & Principles

Phase A: Architecture Vision

Training
Architecting-the-Enterprise
http://www.architecting-the-enterprise.com

Phase B: Business Architecture

Phase G: Implementation Governance

Requirements Management

Phase C: Information Systems Architecture

Resources
The Open Group
Architecture Forum web site Phase E: http://www.opengroup.org/architecture Opportunities & Solutions Certification Information (architects, tools, training, consultants) http://www.opengroup.org/togaf/cert/cert_prodlist.tpl?CALLER=index.tpl
Phase F: Migration Planning Phase D: Technology Architecture

Page 24

Summary of TOGAF
Key Points TOGAF is several things, but the primary focus is the Architecture Development Method (ADM) TOGAF is the evolution of the US Department of Defenses Technical Architecture Framework for Information Management (TAFIM) TOGAF uses the acronym IT looselyand frequently TOGAFs focus is architecting methodology, not products or modeling notation A commercial license, or Open Group Architecture Forum membership, is required in order to use TOGAF for developing an architecture for an external customer
Page 25

Zachman Framework: Agenda

History Overview Framework Rules Usage Tools, Training & Resources Summary

Page 26

Zachman Framework: History

1987 1992 Today

Page 27

Zachman Framework: Overview

The Zachman Framework is a generic classification schema for descriptive representations of any complex object
Aircraft, skyscraper, software-intensive system, business, you name
it

Intentionally avoids recommending architecture description language(s) or modeling styles Depicts the categorization of information through perspectives (rows) and abstractions (columns)
Rows Columns viewpoints of those involved in enterprise development interrogatives reflecting key aspects of the enterprise [what, how, where, who, when, why]
Page 28

Zachman Framework: Variants

Zachman International has released 3 variants of the Zachman Framework Introduced in Zachmans second article [1992] Concept of a frameworks continuum Membership requirements in order to acquire access these

Variant Types
Product Framework Enterprise Framework Profession Framework Classification Framework
Page 29

Zachman Framework: Framework Rules*

The columns have no order Each column has a simple, basic model The basic model of each column must be unique Each row represents a distinct, unique perspective Each cell is unique The composite or integration of all cell models in one row constitutes a complete model from the perspective of that row The logic is recursive

*John Zachman, J.F. Sowa; Extending and Formalizing the Framework for Information Systems Architecture, IBM Systems Journal, Vol. 31, No. 3 (1992); IBM Publication G321-5488
Page 30

Zachman Framework: Usage

It is not practical to believe you will ever have all the models made explicit, Enterprise-wide, horizontally and vertically integrated at excruciating levels of detail.

This is not a problem. Use this tool in the manner that provides you the most ROI. To categorize primitive data about the enterprise that you will later model in

some manner To support business process descriptions As a master checklist to ensure all perspectives are considered As a communication vehicle between stakeholders To ensure alignment between your deployed system and the defined customer vision To define which architectural artifacts you want to produce

Page 31

Zachman Framework: Tools, Training & Resources

Tools Sybase PowerDesigner 15 Troux Architect Sparx Systems Enterprise Architect IBM/Telelogic/Popkin System Architect Training & Certification Zachman International
http://www.zachmaninternational.com/index.php/education-services/20coursesconferenceson-site-services/10-courses http://zachmaninternational.com/index.php/home-article/42#maincol On-site sessions can also be arranged

Resources Articles & white papers

Many recent Zachman papers are also available at www.brcommunity.com

Books
Zachmans CD-book

Page 32

Summary of the Zachman Framework

Key Points The ZFW is a classification schema to organize primitive architectural information Does not prescribe specific models, modeling notation, or methodology Can be used to describe any complex entity Defines 6 perspectives of an architecture
Legacy: Planner, Owner, Designer, Builder, Subcontractor, Functioning enterprise Latest: Strategists, Executive Leaders, Architects, Engineers, Technicians, Workers

Defines 6 abstractions of an architecture What, How, Where, Who, When, Why

Page 33

FEAF: Agenda
Purpose Overview Practical Guides Process Transition to Reference Models Summary

Page 34

FEAF: Purpose
Reasons Developed
Organize United States Federal information on a Federal-wide scale Promote information sharing among US Federal organizations Help US Federal organizations develop their architectures Help US Federal organizations quickly develop their IT investment
processes Serve customer needs faster, better, and cost effectively

Recommended for Use In

US Federal Government-wide efforts Multi-Federal Agency efforts Whenever US Federal business areas and substantial Federal
investments are involved with international, State or local governments

Page 35

FEAF: Overview
FEAF defines 8 components required for developing/maintaining the FEA
1. Architecture Drivers external stimulus that cause the FEA to change 2. Strategic Direction ensures that changes are consistent w/FEA direction

3. Current Architecture represents current state of the enterprise. (note: full characterization may be beyond its worth and maintenance.) 4. Target Architecture represents target state for enterprise in context of the strategic direction

Page 36

FEAF: Overview (2)

5. Transitional Processes
apply the changes from the current architecture to the target architecture in compliance w/architecture standards focus on a subset or a smaller enterprise within the FE provide documentation and basis for managing or implementing changes standards, voluntary guidelines, best practices, all of which focus on interoperability

6. Architectural Segments 7. Architectural Models 8. Standards

Page 37

FEAF: Overview (3)

FEAF defines 4 levels of enterprise architecture
Level 1
20,000-foot view Outlines the 8 components necessary for developing and maintaining the architecture

Level 2
10,000-foot view Separates Business and Design processes, and describes their relationships

Level 3
5,000-foot view Expands the Design Architecture into Data, Applications, & Technology

Level 4
1,000-to-500 foot view Calls out the Zachman Framework and Steven Spewaks Enterprise Architecture Planning as enablers to facilitate enterprise architecture development

Page 38

FEAF: Practical Guide

The Practical Guide to Federal Enterprise Architecture was published in 2001 This supporting document is a key resource for leveraging the FEAF

Page 39

FEAF: Reference Models History

1996
Congress passes the Clinger-Cohen Act, authorizing a Chief Information Officer (CIO) for all federal agencies responsible for developing and maintaining an integrated information technology architecture (now interpreted to mean enterprise architecture) Executive Order 13011 establishes the US Government CIO Council

1999 2001

CIO Council authors the Federal Enterprise Architecture Framework (FEAF) CIO Council authors A Practical Guide to Federal Enterprise Architecture Office of Management & Budget (OMB) requires business case reviews for all significant IT projects. OMB Circular A-130 established the guidelines for these investments. Presidents Management Agenda recognizes the significance of information management as a core mission of government, emphasizing the development of a federal enterprise architecture

2002

Federal Enterprise Architecture Program Management Office (FEA-PMO) established Federal Enterprise Architecture Business Reference Model Version 1.0 published Federal Enterprise Architecture Business Reference Model Version 2.0 published Federal Enterprise Architecture Business Reference Model Addendum 2.1 published (3 pages) Federal Enterprise Architecture Performance Reference Model Version 1.0 published Federal Enterprise Architecture Service Component Reference Model Version 1.0 published Federal Enterprise Architecture Technical Reference Model Version 1.0 published Federal Enterprise Architecture Data and Information Reference Model Version 1.0 published

2003

2005 2007 2010

Federal Enterprise Architecture Consolidated Reference Model (CRM) Version 1.0 published Federal Enterprise Architecture Data and Information Reference Model Version 2.0 published Federal Enterprise Architecture Consolidated Reference Model (CRM) Version 2.3 published Federal Enterprise Architecture Assessment Framework Version 2.1 published
Page 40

FEAF: Reference Models Documents

Page 41

FEAF: Reference Models Relationships

Federal Enterprise Architecture

DoD Enterprise Architecture
Air Force Enterprise Architecture

Page 42

Summary of FEAF & Reference Models

Remember The FEAF document describes 4 levels of enterprise architecture and 8 components required for developing/maintaining an architecture The FEAF broadly describes some architectural products, but without much detail The Practical Guide to Federal Enterprise Architecture is a key supporting document to the FEAF, and should be used as a supplemental resource The Practical Guide to Federal Enterprise Architecture provides methodology guidance A Federal EA Consolidated Reference Model and DoD EA Reference Models have been published and should be leveraged as appropriate for your architecture activities

Page 43

ATAM : Agenda
History Overview Artifacts of ATAM Evaluators and Facilitators Tools, Training & Resources Summary

Page 44

ATAM : History
Developed from 1997-2000 by the Software Engineering Institute at Carnegie-Mellon University Its predecessor was the SEIs Software Architecture Analysis Method (SAAM) First technical report published in August 2000 Evaluating Software Architectures [Clements, et. al.] published by Pearson Education, 2001

Page 45

ATAM : Overview
Purpose
assess the consequences of architectural decisions in light of quality
attribute requirements.
Risks, sensitivity points, tradeoff points

Not intended to precisely predict quality attribute behavior

Scope to Perform an ATAM

3 days (per SEI) 10-20 people (including stakeholders)

Benefits
Clarified QA requirements Improved architecture documentation Documented basis for architectural decisions Identified risks early in the life-cycle Increased communication among stakeholders
Page 46

ATAM : Overview: 4 Phases

Phase 0: Partnership & Preparation

Phase 1: Initial Evaluation

Phase 2: Complete Evaluation

Phase 3: Follow-Up

Duration: Varies

Duration: 1.5 - 2 days each for Phase 1 and Phase 2 Meeting: Typically conducted at customer site

Duration: Varies

Meeting:

Primarily via phone, email

Meeting:

Primarily via phone, email

Carnegie Mellon University Page 47

ATAM : Overview: 9 Steps

Presentation
1. Present the ATAM 2. Present business drivers 3. Present architecture

Investigation / Analysis
4. Identify architectural approaches 5. Generate quality attribute tree 6. Analyze architectural approaches
Carnegie Mellon University

Testing
7. Brainstorm and prioritize scenarios 8. Analyze architectural approaches

Reporting
9. Present results
Page 48

ATAM : Artifacts Utility Trees & Scenarios

Example
Carnegie Mellon University

Data Latency Performance Transaction Throughput New products Modifiability Change COTS

(L,M) Reduce storage latency on customer DB to < 200 ms. (M,M) Deliver video in real time.

(H,H)

Add CORBA middleware in < 20 person-months. Change web user interface in < 4 person-weeks. Power outage at site1 requires traffic redirected to site2 in < 3 seconds. Network failure detected and recovered in < 1.5 minutes.

Utility H/W failure Availability

(H,L) (H,H)

(H,H) COTS S/W failures Data confidentiality Data integrity (H,M)

Credit card transactions are secure 99.999% of the time. Customer DB authorization works 99.999% of the time.
Page 49

Security

(H,L)

ATAM : Tools, Training & Resources

Tools
N/A

Training
Software Engineering Institute, Carnegie Mellon University
ATAM Evaluator, Lead Evaluator http://www.sei.cmu.edu/training/p31.cfm http://www.sei.cmu.edu/training/p32.cfm http://www.sei.cmu.edu/training/certificates/architecture/atame.cfm

Resources
SEI ATAM site
http://www.sei.cmu.edu/architecture/tools/atam/index.cfm

SEI Certification Program site

http://www.sei.cmu.edu/training/certificates/architecture/index.cfm http://www.sei.cmu.edu/architecture/tools/systematam

Paul Clements, et. al. book: Evaluating Software Architectures

Page 50

Summary of ATAM
Remember

The ATAM is a 9-step process focusing on the quality attributes of an architecture Carnegie Mellon Universitys Software Engineering Institute has established a program to formally certify ATAM Evaluators and Lead Evaluators Raytheon has dozens of certified ATAM Evaluators spanning all Business areas

Page 51

Wrap-Up: Additional Reading

Department of Defense Architecture Framework 2.0 http://cio-nii.defense.gov/sites/dodaf20/archives.html Volume 1: Sections 1 through 3 (32 pages) Volume 2: Section 1 (22 pages) The Open Group Architecture Framework TOGAF Part 1 (Introduction -- 2 sections: Introduction, Core Concepts)
http://www.opengroup.org/architecture/togaf9-doc/arch

Zachman Framework for Enterprise Architecture www.zachmaninternational.com,

http://docushare1.app.ray.com/docushare/dsweb/View/Collection-37159 John's 1987 IBM Systems Journal paper John's 1992 IBM Systems Journal follow-up paper "The Framework for Enterprise Architecture: Background, Description, and Utility; Zachman "Enterprise Architecture: The Issue of the Century; Zachman

Federal Enterprise Architecture Framework All of section 1 in the Practical Guide to FEA (4 pages)
http://www.gao.gov/bestpractices/bpeaguide.pdf

Architecture Tradeoff Analysis Method http://www.sei.cmu.edu/publications/documents/00.reports/00tr004.html

Sections 1, 2, 3, 8, 9 (28 pages)
Page 52