beyond a product view of architecture
DESCRIPTION
TRANSCRIPT
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
Renaissance Washington, DC
The primary usage of architecture…
4 April 21-23, 2008
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
The product-centric view in DoDAF is a compromise between Zachman and most modeling notions
8 April 21-23, 2008
Renaissance Washington, DC
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
Description(Detailed)
SystemCOMMS
Description
SystemInterface
Description(Detailed)
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
The heart of the DoDAF (or any framework) is the relationships between these primitive concepts…
14 April 21-23, 2008
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
DoD Net-Centric Data Strategy
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
Renaissance Washington, DC
* 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
DoD Net-Centric Data Strategy
Core Human Resources Information Standards
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Core Human Resources Information Standards
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
Our example Operational Concept Graphic abstracts very detailed process model data…
Phase 5 Validate & Refine (Weeks 16-18):
35 April 21-23, 2008
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
Thank You!Tim HunnicuttSenior AssociateBooz Allen Hamilton
Contact Information:[email protected]
40 April 21-23, 2008
Renaissance Washington, DC
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
Renaissance Washington, DC
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
Renaissance Washington, DC
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