Beyond a Product View of Architecture

Welcome Tim Hunnicutt

Senior AssociateBooz Allen Hamilton

Session Title:Beyond a Product View of Architecture

2 April 21-23, 2008

Renaissance Washington, DC

Session Overview

This session will discuss the application of presentation and visualization techniques to break out of the product-centric focus of most architecture (examples are primarily within the Department of Defense). The challenges facing a product-only architecture in gaining acceptance and application will be addressed. Additionally, it will be discussed how to leverage presentation/visualization techniques such as dashboards, graphical depictions, reference models, fusion products and composite products. The session will focus on a common example, centering around a complex BMPN-based process model and how a set of well-formed information-rich visualizations can be developed to enhance the application of architecture for business problems.

3 April 21-23, 2008


The primary usage of architecture…

4 April 21-23, 2008


The foundation of any architecture is integrated information…

Before we can create presentation and visualizations, we have to go through a process of gathering and relating information about the enterprise. Using some sort of modeling notation and tool.

5 April 21-23, 2008


The DoDAF is a traditional product-based architecture framework…

Typical Analysis Areas:

– Investment Review Board Analysis

– Business Process Re-engineering

– Data Management

– IT Portfolio Analysis

6 April 21-23, 2008


BPMN Relationship to DoDAF

The OV-6c portrays a relative order to Operational Activity execution

Each Operational Activity has a trigger (start)

Each Operational Activity has

a conclusion

(end)

The process flows within each diagram are

categorized by the Actor responsible

for the activity/event

These “swimlanes” also map to the

OV-2 roles

All process models use a common modeling notation (BPMN)

Data Objects map to OV-3 Information Exchanges

Gateways reflect OV-6a

Business Rules

7 April 21-23, 2008


The product-centric view in DoDAF is a compromise between Zachman and most modeling notions

8 April 21-23, 2008


IntegratedDictionary

ActivityModel(List)

OperationalNode

ConnectivityDescription

CommandRelationships

Chart

OperationalEventTrace

LogicalData

Model

ActivityModel Information

ExchangeMatrix

PhysicalData

Model

SystemFunctionalityDescriptionSystemInterface

Description(Detailed)

OperationalActivity toSystemFunction

Matrix

SystemInterface

Description(High-Level)

SystemInterface


SystemCOMMS

Description

SystemInterface


ActivityModel Operational

EventTrace/System

EventTrace

An AspectOf MultipleProducts

DoD Architecture Framework Products Operational View System View Technical View*

*Rules Not Explicit in Zachman

DoDAF 1.5 seems to be only a partial solution wrt to Zachman…

DoDAF Products

Mapped to the

Zachman Framewor

k

Presentation and

visualization can help fill in

the gaps.

9 April 21-23, 2008


During this session we’re going to take several looks at how process modeling relates to this…

Phase 4 Integrate (Weeks 13-15):

The example process model had 304 “steps”, plus multiple swimlanes and dozens of data objects. We’re going to relate this to both DoDAF and presentation/visualization.

10 April 21-23, 2008


The DoDAF is moving to a “Fit-for-Purpose” concept…

The intent is to go beyond the product-centric view to a data-centric view. This will be more flexible and address the gaps in the current framework.

To understand the implications of this change

we have to look “under the

hood”.

11 April 21-23, 2008


Using Presentation and Visualization techniques INCREASES the need for well-formed architecture data…

Before we can create presentation and visualizations, we have to really understand the information that is the core of architecture.

12 April 21-23, 2008


Policy

Standards

InformationExchanges

System DataExchanges

Data

OperationalActivities

Systems

Business Processes

BusinessRules

System Functions

OperationalRoles

The building blocks of architecture align to the primitives in the Zachman framework.

13 April 21-23, 2008


The heart of the DoDAF (or any framework) is the relationships between these primitive concepts…

14 April 21-23, 2008


Policy is a documented plan of action to guide decisions and achieve rational outcomes. It guides the process of making

important organizational decisions, such as programs or spending priorities, and choosing among them on the basis of the impact

they will have.

Policy

15 April 21-23, 2008

Renaissance Washington, DCDepartment of Defense ● Human Resources Management

Civilian Human Resources Management ● Military Health System ● Military and Other Human Resources Management

Operational Activities

ACART

DITPR

ReferenceModels

Operational Activities populate the BEA

Operational Activities organize RMs

Operational Activities are fed to DITPR for mapping

Operational Activities are fed to ACART for mapping

BEAOperational activities describe the capabilities that

are normally conducted in the course of achieving a

mission or a business goal. They represent a

hierarchical decomposition of business activities and are discovered through

reference analysis and SME interviews.

16 April 21-23, 2008


The team created an Operational Activity, Node Tree (OV-5) by abstracting the detailed process steps…

Phase 5 Validate & Refine (Weeks 16-18):

17 April 21-23, 2008


ReferenceModels

DoD Net-Centric Data Strategy

BEA

Information Exchanges

Information Exchanges identify who exchanges what information, with

whom, why the information is necessary, and how the information exchange must occur. Information exchanges express the relationship

across operational activities, operational

nodes, and information flow.

Information Exchanges populate the BEA

Information Exchanges are mapped in RMs

Information Exchanges identify authorized and anticipated users for the NCDS

Information Exchanges are mapped to Core HR Information Standards

Core Human Resources Information Standards

18 April 21-23, 2008


Operational roles define who is responsible for

what activities within an organization, what

information is exchanged between roles, and how responsibilities within an organization shift over

time. Organizational roles can also define

stakeholder relationships.

BEA

ReferenceModels


Operational Roles identify net-centric service providers

Operational Roles are mapped in RMs

Operational Roles populate the BEA

Operational Roles

19 April 21-23, 2008


* Source: MODAF Version 1.1

Data is used to document the business information

requirements and structural business process rules of the architecture. It describes the information that is associated

with the information exchanges of the architecture and that are required to support a mission or business goals. It includes data elements, their attributes, their relationships and data-specific

business rules.

BEA

ReferenceModels



ACART

Data populates the BEA

Data organizes Data RMs

Data is fed to ACART for mapping

Data is built to support the NC Data Strategy

Data is the core of the HR Information Standards

Data

20 April 21-23, 2008


They created 35 high-level data objects…

Met weekly with representatives from the Services, DoD, and VA.

Created 15 process models and 1 integrated model which included 304 processes and 35 data objects which define:– Continuation of Military Service Decision– Conversion to Ability Assessment– Components of Compensation– Continuum of Care– Care Management Team (CMT)– Coordination of Recovery Care Plan (RCP)– Consolidated Access to Benefits– Convergence of Information

21 April 21-23, 2008


BEA

ReferenceModels

Business Processes populate the BEA

Business Processes are mapped in RMs

Business Processes

Business processes describe a time-ordered

examination of the information exchanges

that occur between operational roles. They

help define the role interactions and capture

end-to-end business processes.

22 April 21-23, 2008


The group was very resistant to “architecture”, but comfortable with “process modeling”…

Phase 2 Design & Build (Weeks 3-7):

Process models represented stakeholder interactions, information exchanges, and key concepts

23 April 21-23, 2008


Business Rules specify operational or business rules that

are constraints on the way that business is done in the

enterprise.At a top level, rules will at least

embody the concepts of operations and will provide

guidelines for the development and definition of more detailed rules and behavioral definitions

that will occur later in the architecture definition process.

BEA

Business Rules


Business Rules populate the BEA

Business Rules constrain HR Information Standards

ACART

Business Rules are fed to ACART for mapping

24 April 21-23, 2008


System Data Exchanges

BEA

System Data Exchanges populate the BEA

System Data Exchanges specify the characteristics of the system data exchanged between systems. System

data exchanges focus on the specific aspects of the

system data flow and the system data content.

25 April 21-23, 2008


System functions are actions performed by

systems to support the operational activities required by a mission

or business goal. System functions

BEASystem Functions populate the BEA

ReferenceModels

System Functions populate RMs for system mapping

ACART

System Functions are fed to ACART for mapping

DITPR

System Functions are fed to DITPR for mapping

System Functions

26 April 21-23, 2008


Systems

BEA

ACART

DITPR

Systems populate the BEA

Systems are fed to ACART for mapping

Systems are fed to DITPR for mapping

Systems support organizations and

operational roles by automating the information

exchanges between operational activities that

support a mission or capability.

27 April 21-23, 2008


Standards

Standards guide the development of systems by providing requirements

with which systems developers must comply. Standards also provide

guidelines against which the system evaluators can gauge technical

parameters of the system

28 April 21-23, 2008


Well-formed architecture data, residing in a capable repository presents infinite opportunities for business use…

Working with the DoDAF community, we are trying to create some best-practices to help the architecture and business communities understand each other.

29 April 21-23, 2008


An architect’s two primary jobs are communication and mediation…

The EA MUST be understandable to ALL the

stakeholders!But not ALL of the EA has to

be understandable to ALL stakeholders!

GraphicsReference Models

Low detailHighly structured models

Physical modelsHighly Detailed

GraphicsLogical ModelsModerate detail

30 April 21-23, 2008


Levels Descriptions Stakeholders

Level 1: Planners/Decision

Authority

•Defined as senior level decision makers who review and make final approvals or strategic decisions

•Require high-level overviews which quickly touch on the key concepts of the architecture products

•Must understand why the initiative will be beneficial to the DoD at large

•Capability/portfolio managers•Defense Acquisition Board (DAB)•Doctrine developers •Joint Staff J-6•JROC•Operational planners: ROI analysis

Level 2: Process Owners

•Defined as programs managers and/or process owners with direct staff oversight and perhaps technical systems expertise and have some level of control and/or budget authority

•Require high-level conceptual briefings detailing process and progress of effort

•Must understand what overall impact the architecture product will have on their organization

•Acquisition managers•Analysts (Operational)•Capability Analysts•Information assurance•Program managers•Warfighters

Level 3: Program Managers

•Defined as implementers of the initiative as well as system owners and functional managers affected by the implementation

•Require documents/information detailing the specifics of initiative implementation and workload

•Must understand the impact that implementation will have on organizational positions, workload, and process

•Operational developers/architects•Requirements/functional analysts

Level 4: Integrator •Defined as the system architects and functional managers affected by the implementation

•Require specific details and documentation on how to implement and use the products

•Must understand the how and why of implementation as well as the necessary system changes and their benefits

•Chief engineers•Development system architects •Developers•Requirements/functional analysts •System engineers •Testers•Tool vendors/industry support partners

Level 5: Developer •Defined as the system developers / coders•Require specific details and documentation on how to implement the products

•Must understand the how of implementation as well as the necessary system changes

•Combat Developers•Material Developers

(CIOs)

(Strategic Architects)

(Capability Architects)

(System Architects)

(Developers)

Understanding stakeholder requirements is vital for successful presentation of EA data…

31 April 21-23, 2008


Presentation Technique: Dashboards

Integrate architecture information to create business context– Number of Systems supporting an Operational Activity– Number of Systems modifying a Data Element

Fuse Architecture Information with other Business Information– Cost per System Function– Training Requirements Per Operational Role

1stQtr

2ndQtr3rdQtr

4thQtr

0102030405060708090

1stQtr

2ndQtr

3rdQtr

4thQtr

EastWestNorth

32 April 21-23, 2008


Presentation Technique: Graphical Depictions

Graphics enable understanding of and add accessibility to architecture information– Operational Concept

Graphics aligned to business capabilities and enterprise priorities within the architecture engage stakeholders and attract them to the more detailed portions of the architecture

– The use of graphics in products facilitate instant understanding.

Most people understand pictures faster and easier than they do text or model-based document.

What’s the downside to

using graphics?

33 April 21-23, 2008


Graphical representations must tie back to the architecture they introduce…

Major operational concepts called out.

Highest level actors identified.

Strategic goals integrated into the graphic.

34 April 21-23, 2008


Our example Operational Concept Graphic abstracts very detailed process model data…

Phase 5 Validate & Refine (Weeks 16-18):

35 April 21-23, 2008


Presentation Technique: Reference Models

Reference models provide linkages from operational activities to key architectural concepts, both within and outside of the enterprisePresenting the architecture linkages in a desk reference, versus a set of diagrams and reports, provides a means for quickly retrieving multiple pieces of information

BRM driven by underlying OV-5

What’s the role of

taxonomy in enterprise

architecture?

36 April 21-23, 2008


Presentation Technique: Composite Products

Most business owners are interested only in their particular business area and its immediate interconnectionsCreating specific sub-architecture product sets tailored to specific business user groups by building sub-architecture graphics

This allows for small “snapshots” of the architecture to be captured and displayed to a particular business owner.

37 April 21-23, 2008


Presentation Technique: Fusion Products

Fusion products accommodate the need to occasionally have formal ties between data not stored in the architecture and architecture informant.Examples:•COST per system function•Cost per business process step•Detailed System Metadata per system

The intent is to facilitate detailed analysis without the unintended consequence of the EA data been categorized as “Sensitive” or worse.

38 April 21-23, 2008


Conclusion - Architecting and Engineering─ Two Sides of the Same Problem*

Architecture Specification

Engineerible Requirements

collective vision, goals, constraints,and other needs of the stakeholders

representations of economicallyproducible components that can be

assembled to construct the functional whole

Analysisof Function

Iteratively decompose and separate a primarily

functionalrepresentation of

a whole

Iteratively composeseparate elements to form a coherent whole

Synthesisof Form

Engineering

Architecting

Critical point

*Walt Okon,DoD Architecture TrainingTown Hall MeetingDec 12, 2007

If architecture and engineering are not

the same thing, then the

approaches might be different.

39 April 21-23, 2008


Thank You!Tim HunnicuttSenior AssociateBooz Allen Hamilton

Contact Information:[email protected]

40 April 21-23, 2008


Segment Architecture: Depiction

Segment architecture development is a collaborative process forming a bridge between enterprise-level planning and the development and implementation of solution architecture.

– It is used to provide a detailed results-oriented architecture (baseline and target) and a transition strategy for a portion or segment of the enterprise. Recommended by the Federal Enterprise Architecture Program Management Office, OMB

41 April 21-23, 2008


EA Product Audiences

Management – Primarily concerned with cost, compliance, and schedule

– Executives– Certification Analysts– Portfolio Managers

Functional – Primarily concerned with function and human factors (acceptance, usability, etc.)

– Stakeholders– SMEs– Action Officers– End-Users

Technical – Primarily concerned with technical solutions and standards– Information Assurance Managers– Net-Centric Implementers– SOA Implementers– Technical Standards Managers

Developers and Implementers (Transformation Analysts) – Primarily concerned with suitability of documentation to their needs)

– Business Analysis– Process Re-engineers– Emerging Technology Analysts

42 April 21-23, 2008


Though originally directed to only use BPMN, as complexity increased, stakeholders found value in using other EA products too

Achieved consensus by adapting to fit stakeholder needs

Individual Process Models15 process models consisting of 304

processes and 35 data objects

High Level Process Model

19 processes outlining the entire continuum and the simultaneous

and iterative nature of many processes

Node Tree (OV-5)80 operational activities providing an

overview of all 15 process models

High Level Operational Concept Graphic (OV-1)

Executive-level diagram to socialize new concepts

Integrated Process Model1 process model including all processes, data objects, swim

lanes, and gateways from the 15 sub-process models

Integrated Dictionary (AV-2)

Definitions for all processes, events, gateways, data

objects, and swim lanes