Building an Actionable Enterprise Architecture

1
Building an Actionable Enterprise Architecture

• Presented by
• Cherokee Information Services, Inc.
• at the
• OMG Government Domain SIG
• OMG TC Meeting
• Tampa FL,
• February 16, 2006

2
Problem Statement

• The quality of analysis (and therefore the
  quality of decision making) is directly related
  to the depth, breadth, accuracy and understanding
  of the inter-relationships within, and between,
  organizations, their processes, information, and
  implementing technology.
• Typically this is represented in the form of an
  Enterprise Architecture (EA).
  
• Enterprise architecture was adopted by Federal
  agencies as a standard benchmark for informing
  
• Risk Analysis
• Investment Decisions
• System Acquisition and Development Processes
• Documentation
• Performance Analysis

3
Current State of Enterprise Architecture

• Information is generally in a variety of places
  and may or may not be up-to-date thus making it
  very difficult to do broad (enterprise level)
  analysis and reporting.
• Typically there is non-conformity to maturity
  standards, indicating a lack of quality control
  and effective configuration management of the
  products.
• The entire enterprise must be modeled in order to
  produce the data repository necessary to better
  enable analysis and enhance decision support.
  
• Maturation and maintenance of EA information are
  often not fully articulated, nor implemented and
  therefore quickly lose value.
  
• Development involves labor intensive, time
  consuming, intrusive efforts that produce only a
  snapshot of a single point in time.
  
• In essence, the current approach has not
  realized the promise of Enterprise Architecture.

4
Current State of EA
Challenge is exacerbated by limited information
exchange between current modeling tools.
5
What is the Promise of Enterprise Architecture?

• Zachman outlined that a successfully implemented
  Enterprise Architecture Framework would be

• Simple
• Easy to understand, non technical, purely
  logical
  
• Comprehensive
• Addresses the Enterprise in its entirety
• A Language
• Helps you to think about complex concepts and
  communicate them precisely

• A Planning Tool
• Helps make better choices since they are not made
  in a vacuum
  
• A Problem Solving Tool
• Enables you to work with abstractions, to
  simplify, to isolate simple variables
  
• Neutral
• Defined independent of tools or methodologies

6
Cherokees Way Ahead

• Cherokee recognized that the full benefit of EA
  could not be easily, nor cost effectively,
  realized without significant change to the manner
  in which it is developed, maintained, and used.
• The solution was not in the development of the EA
  views, but in the capture of the data that
  produces the views, with accuracy, and
  facilitates delivery and maintenance of EA type
  information.
• Cherokees Capture, Maturation, and Maintenance
  of Data (CMMD) methodology effects the transition
  from the current as-is state of architecture and
  investment decision documentation to a dynamic
  enterprise management solution, an Actionable
  Integrated Architecture (AIA).

7
The CMMD Methodology Solution

• The Capture Process leverages information from
  many disparate sources and compiles the
  information into a common, database structured
  repository.
• Existing data developed in SA, Rose, ARIS, Metis,
  Proforma, or similar toolsets is reused.
  
• The Maturation Process consists of
  rationalization and normalization of the data
  through a managed data cleansing process.
  
• The Maturation Process helps identify risks, and
  development of risk mitigation strategies.
  
• The Maintenance Process aligns the lifecycle
  management of the information with the
  organization's governance and decision making
  policies and processes.
• Alignment means near-real-time analytical
  decision support because the AIA continues to
  reflect the current state of the enterprise.

8
New Paradigm
9
The CMMD Methodology Solution

• Starts with Developing Scenarios and Use Cases
• Follows SEI Architectural Trade-off Analysis
  Methodology (ATAM)
  
• Identifies Analysis Requirements (and Associates
  Data Types) Required to be Supported by EA
  
• What types of questions, concerns, risks, and
  capability questions need to be answered to
  support contingency planning and assist the
  decision making process in the response and
  recovery phases?

10
Operational Scenario

• Stimulus A catastrophic weather event (e.g.
  hurricane) takes communications infrastructure
  out of service 3 million customer lines, 38 911
  call centers, 100 broadcast stations, over 250
  cell sites rendered inoperable.
• Scenario coordination of emergency and rescue
  services, communication to public requiring
  services, not possible for several days. This
  resulted in absence of rescue services.
• Response technological upgrade communications
  backbone (add emergency service satellite access,
  wi-fi, improved spectrum availability) enhance
  comms interoperability through spectrum sharing,
  satellite supported public broadcast, Software
  Defined Radio (SDR) technology, and most
  importantly interoperable comms networks
  supported by compatible equipment.

11
The CMMD Methodology Solution

• Next is the Creation of a Meta-Data Model which
  guides the information gathering process
  
• The schema aligns to DoDs Core Architecture Data
  Model (CADM) or a similar database structure
  
• The Schema supports investment decision, the
  system engineering process, and oversight
  requirements
  

12
Meta Model to Support Analysis
13
The CMMD Methodology Solution
14
The Benefits of CMMD
Consistency 35
Consistency 85
15
Governance ArchitectureEnterprise
Management/Oversight
16
The Benefits of CMMD

• Cherokees Capture, Maturation, and Maintenance
  of Data (CMMD) methodology
  
• Represents a structured, repeatable and
  documented process that provides visibility into
  the status of development of the architecture for
  an enterprise.
• Enables monitoring and control of the EA
  development process.
  
• Provides the organization with a capability to
  perform continual update and maintenance of its
  architecture.
  
• Facilitates the creation of real-time
  analytical and investment decision products
  on-demand by querying the architecture database
  and generating the products as reports.

17
Case Study Examples

• DoD New Project
• Current state
• Multiple, stovepipe systems that support Command,
  Control, Intelligence, and Reconnaissance
  functions within and across services.
  
• Desired future state
• Fully integrated, SOA that provides the right
  information, to the right place, at the right
  time while maintaining security, integrity, and
  quality requirements.
• Challenge
• Develop the required analysis and transition
  planning.

18
Phased Approach

• Phase 1 (Process and Tools Development)
• Define and create data compilation templates
  (CADM database structure)
  
• Define workflow process implement and test in
  eaWorkflow
  
• Construct repository structure
• Gather, review, and analyze SOR documentation
  (CONOPS, ORD, C4ISP)

19
OV-2/3
Capturing Operational Nodes, Needlines, and Infor
mation Exchanges Defined the scope of data collec
tion required.
20
SV-6/10
Systems Engineering Views and data requirements
drive depth of data capture.
21
Phased Approach

• Phase 2 (Operational Implementation)
• Continue review and analysis of SOR
  documentation
  
• Compile data derived from documentation into
  customized CADM database (populate repository)
  
• Generate model visualizations (tool supported)
• Conduct review and validation sessions with SOR
  stakeholders
  
• Revise CADM data and regenerate model
  visualizations as necessary
  
• Complete final validation of models

22
Phase II Activities
March April May Jun Jul Aug Sept
CADM
Current Programs of Record (PORs)
Templates
Capture Top Level Data Iterative Workshops
Areas of Specific Interest
Gather Detail Information Documentation, Interv
iews, Mapping
Templates
Mature Data Consistency and Normalization
23
Measuring Progress
Scorecards provide progress reports in
completeness and consistency of data.
24
Suitability to Support Information Assurance Plan
25
Illustration of Adequacy of Interoperability
Analysis
26
Back Up Slides
27
Architecture Definitions

• The basic sources cited here for architecture
  definitions are
  
• DoDAF v1.0
• Open Management Group (OMG)
• IEEE STD 1472
• Zachman
• It is important to note that different sources
  have different understandings of the same term,
  and care must be taken to specify the various
  usages of commonly used terms.

28
What is CADM?

• CADM specifications define at both the logical
  and physical level the structure of an
  architecture data repository
  
• Reference data (missions, tasks, organizations,
  organization types, facilities, materiel
  instances, material classes) common to all
  architectures
• Architecture-specific data and their
  relationships to reference data (planned as well
  as actual capabilities architecture
  alternatives)
• Details include data types, domains, short
  physical names, null options, and XML tags, as
  well as definitions
  
• CADM conformance comprises the minimum rules to
  enable conformant databases to exchange data
  electronically
  
• Implementers choose those parts of the CADM that
  apply
  
• Implementers extend the core from the CADM as
  needed
  
• Implementers cooperate on key assignments
• Implementations can be relational, object
  oriented, or other
  
• Example data repositories based on or conformant
  to CADM
  
• DoD Data Dictionary System (data standards)
• Army Architecture Repository Management System
• GIG Architecture Database

29
Architecture Definitions
30
Architecture Definitions
31
DoDAF Views
32
DoDAF Views
33
Observations

• In DoDAF v1.0, models typically provide a flat
  (2GL) representation of a view, generally
  graphically (in a diagram) or in tabular form.
  
• Models of this type are limited, since the
  relationships that they make visible are only
  explicit within each specific view.
  
• The framework document suggests extended
  (between-view) relationships, but it is
  difficult to expose these relationships across
  the complete architecture.
• CADM enhances the analytical capability of DoDAF
  by extending visibility of relationships across
  views.
  
• Relationships are defined through application of
  the CADM schema, which makes associations
  explicit across the entire architecture.

34
CADM vs. Traditional DoDAF

• A CADM based architecture enables the development
  of user-defined viewpoints, reflecting the use
  case for each viewpoint (that is in DoDAF terms,
  for each class of user). Examples
• A Planner (such as the PEO) can evaluate the cost
  of ownership of alternative configurations of
  a planned system
  
• An Owner (such as the Functional Proponent) can
  examine whether different alternatives support
  operational requirements traced to defined
  business processes, and which configuration
  optimizes cost efficiency
• A Designer (System Engineer) can review
  alternative system, network, and communication
  configurations to determine whether all
  information and data exchange requirements are
  met in a manner to optimize interoperability and
  maintain system functionality while eliminating
  redundant interfaces
• A Builder or Contractor can review all design
  specifications to ensure that they are consistent
  with operational requirements.
  
• Meaningful responses to user questions are not
  dependent on completion of the entire
  architecture. Rather, data can be captured and
  matured as needed to respond to different
  questions at different stages in the acquisition
  life cycle.

35
CADM Key Entities Relationships (Schema)
36
Acquisition Lifecycle Documentation by Milestone
MS A
MS B
MS C
System Specifications Data Specifications
C4ISP
Planning DOC
Draft Specs
Complete SDD
CCA
CCA
CCA
CARD
AoA
CARD
AoA
ICD AoA
CDD
Traceability Performance Standards
OTE
Tech Dev Strategy
Acquis Program Base Line
Tech Dev Strategy
TE Strategy
Full Test Report
Acquis Program Base Line
J-6 Inter Support Certs.
J-6 Inter Support Certs.
ICD
CDD
TEMP
Test Report
Revised TEMP
Acquisition Strategy
Acquisition Strategy (Revised)
Acquisition Strategy (Tied to Technology Plan)
OV-7
SV-2
OV-2/3
SV-2
OV-5 (1st Draft)
SV-5
SV-11
SV-4
OV-1
AV-1
SV-6
SV-7
SV-1
SV-4
SV-10c
SV-6
SV-8
OV-6c
TV-12
Documentation Architecture Refreshed for Each
Increment or Spiral