Transcript Slide 1

A Hybrid Approach to Developing
Enterprise Architecture
SEDC 2014
Chantilly, VA
3-5 April 2014
Mr. Bruce Fenchel
Mr. Barry Masciale
Dr. Warren K. Vaneman
URS Federal Services
Systems Engineering &
Information Solutions Group
Chantilly, VA
Space Systems Sector
TASC, Inc.
Chantilly, VA
Department of Systems Engineering
Naval Postgraduate School
Monterey, CA
• A well-defined Enterprise Architecture (EA) represents
the perspectives of the different stakeholders necessary
to gain advocacy. It provides end-to-end traceability
from stakeholder objectives, and desired capabilities, to
the solution architecture.
– Provides end-to-end traceability from stakeholder objectives, and
desired capabilities, to the solution architecture
• EAs artifacts reflect different levels of abstraction that
logically progress from conceptual, to logical, to
implementation, while maintaining concordance across
the artifacts
– Levels of abstraction are required to communicate to the diverse
consumers of EA
2
• EAs are predominantly constructed using either
Structured Analysis and Design Technique (SADT) or
Object Oriented Analysis and Design (OOA&D)
• While each technique has its own strengths and
weaknesses, system and enterprise architects typically
prefer to use only one of these analysis techniques,
thereby not realizing the potential benefits of the other
A hybrid approach capitalizes on the strengths of
both SADT and OOA&D
3
• Structured Analysis and Design Technique (SADT)
provides a top-down, holistic, technique that focuses on
the totality of the Enterprise where functionality is
“mutually exclusive”, non-overlapping, functionality, and
can be “totally exhaustive,” encompasses the entire
scope
• Object Oriented Analysis and Design (OOA&D) relies
predominantly on a goal-oriented threads-based
technique that is well-suited to identify the perspective of
individual stakeholders and express how each thread
relates to the enterprise
4
SADT Characteristics
OOA&D Characteristics
Tightly coupled views for
concordance
Loosely coupled for agility
Functional decomposition is
developed top-down with
common data across functions
Use Cases reflect the
perspective of the individual
stakeholders.
Changes to a single view may
propagate changes within the
view and across views
Changes to a single view have
limited changes to other views
Holistic process model
integrates functions and data
across the enterprise
Data is derived from specific
threads and is associated with
an activity relating
operation/method to data
• A hybrid methodology leverages top-down, holistic,
systematic, development techniques of SADT with the
adaptability of OOA&D to create an architecture that offers the
best of both worlds
• Provides meaningful artifacts that represent stakeholder’s
perspectives necessary to support decisions in the context of
the enterprise
• Incorporate changes by modifying the most effective points in
the models, and then verify against the other models
– Modify holistic model with new functionality and update threads
– Modify a thread and integrate into the holistic model
6
Provides Functional Behavior
Activity
Diagram
Provides Activities
Provide Scenario Derived Functions
Provides EnterpriseLevel Functions
SADT
Functional
Model
Validates
Provides
Data
Functional
Requirements
Provides
Data
EnterpriseLevel Data
Use
Cases
Provides
Data
Generalizes
Provides Lower Level Data
Scenario
Derived
Data
Provides
Basis for Info
Exchanges
Sequence
Diagram
Provides
Data
Provides
Classes and Class
Behavior
Provides
Class
Exchanges
Rules
Model
State
Transition
Diagram
Provides basis for operations
Provides
Classes
Class/Block
Diagram
Provides
Operations
Provides
Data &
Rules
Provides
Functional
Behavior
Executable
Model
Provides States
Provides Basis For Classes and Attributes
• Program Overview
• Fundamental Objective to
Capability Trace
• Concept of Operation
• Capability to Requirement Trace
• Integrated Dictionary
Step 2
Step 1
SADT
OOA&D
• Black Box Functional
Boundary Definition
• Black Box Use Case Analysis
Step 2
Step 3
• White Box Functional
Decomposition /
Modeling
• Functional Allocation
• White Box Use Case Analysis
• Class Identification
• Package Definition
Step 3
• Sequence Diagram
• Activity Diagram
• Class/Block Definition (with
stereotypes)
• Rules Model
• Data Model
• Deployment Diagram
Step 4
• State Transition Diagram
• Executable Model
Step 5
• Architecturally Derived
Requirements
• Program Overview
• Fundamental Objective to
Capability Trace
• Concept of Operation
• Capability to Requirement Trace
• Integrated Dictionary
Step 2
Step 1
SADT
OOA&D
• Black Box Functional
Boundary Definition
• Black Box Use Case Analysis
Step 2
Step 3
• White Box Functional
Decomposition /
Modeling
• Functional Allocation
• White Box Use Case Analysis
• Class Identification
• Package Definition
Step 3
• Sequence Diagram
• Activity Diagram
• Class/Block Definition (with
stereotypes)
• Rules Model
• Data Model
• Deployment Diagram
Step 4
• Identify the stakeholders and their business
needs (objectives) using their terminology
• Interpret business needs in terms of high level
functions (capabilities)
– Develop key Use Cases to describe how
capabilities interact to satisfy business needs
• Architecturally Derived
Requirements
• Identify high-level program risks and
mitigation strategy
• Define scope, purpose, and viewpoint to influence functional
decomposition (described in Step 3)
• State Transition Diagram
• Executable Model
Step 5
– Important discriminator between a reference model and an
architecture
• Select Architecture Framework (e.g., DoDAF, FEAF, TOGAF,
MODAF, Zachman) and methodology
• Begin integrated dictionary and continue to update throughout the
9
EA development
• Program Overview
• Fundamental Objective to
Capability Trace
• Concept of Operation
• Capability to Requirement Trace
• Integrated Dictionary
Step 2
Step 1
SADT
OOA&D
• Black Box Functional
Boundary Definition
• Black Box Use Case Analysis
Step 2
Step 3
• White Box Functional
Decomposition /
Modeling
• Functional Allocation
• White Box Use Case Analysis
• Class Identification
• Package Definition
Step 3
• Sequence Diagram
• Activity Diagram
• Class/Block Definition (with
stereotypes)
• Rules Model
• Data Model
• Deployment Diagram
Step 4
• State Transition Diagram
• Executable Model
Step 5
• Architecturally Derived
Requirements
•
•
•
Define the enterprise boundary
Understand the interactions of the
enterprise with the external environment
– Define what the enterprise provides
– Define what the enterprise needs
Define the enterprise level transactions
– Provides an executive-level product of boundary architecture
information to ensure that the enterprise “customers” and
stakeholders have their needs satisfied
10
• Program Overview
• Fundamental Objective to
Capability Trace
• Concept of Operation
• Capability to Requirement Trace
• Integrated Dictionary
Step 2
Step 1
SADT
OOA&D
• Black Box Functional
Boundary Definition
• Black Box Use Case Analysis
Step 2
Step 3
• White Box Functional
Decomposition /
Modeling
• Functional Allocation
• White Box Use Case Analysis
• Class Identification
• Package Definition
Step 3
• Sequence Diagram
• Activity Diagram
• Class/Block Definition (with
stereotypes)
• Rules Model
• Data Model
• Deployment Diagram
Step 4
• State Transition Diagram
• Executable Model
Step 5
• Architecturally Derived
Requirements
• Decompose data consumed and produced
by functions (or activities)
• Decompose functions to a level that
supports allocation (e.g., system,
component, service, human)
• Approach leverages perspectives of SADT functional
decomposition and Use Case analysis
– Technique informs each other
• Allocate functions to services, systems and people
• Identify classes from the Use Cases and are organize into
logically groupings
• Derive classes from architecture data and other elements
11
• Program Overview
• Fundamental Objective to
Capability Trace
• Concept of Operation
• Capability to Requirement Trace
• Integrated Dictionary
Step 2
Step 1
SADT
OOA&D
• Black Box Functional
Boundary Definition
• Black Box Use Case Analysis
Step 2
Step 3
• White Box Functional
Decomposition /
Modeling
• Functional Allocation
• White Box Use Case Analysis
• Class Identification
• Package Definition
Step 3
• Sequence Diagram
• Activity Diagram
• Class/Block Definition (with
stereotypes)
• Rules Model
• Data Model
• Deployment Diagram
Step 4
• State Transition Diagram
• Executable Model
Step 5
• Architecturally Derived
Requirements
• Construct activity diagrams from Use
Cases or mission threads
• Refine classes using derived activities
as operations
– Deployment diagram will show how classes
and services will be realized
• Develop sequence diagrams to depict
how services will interact
• Create behavioral models
– Reflect constraints
• Derive requirements from the functional decomposition
12
• Convert static architectural data to
dynamic architectural data by adding
timing or performance parameters
• Run executable model to verify the
logic of the architecture, and determine
a coarse level of architectural
performance
• Use the operational deployment provide insight into the
transition strategy/roadmap
• Program Overview
• Fundamental Objective to
Capability Trace
• Concept of Operation
• Capability to Requirement Trace
• Integrated Dictionary
Step 2
Step 1
SADT
OOA&D
• Black Box Functional
Boundary Definition
• Black Box Use Case Analysis
Step 2
Step 3
• White Box Functional
Decomposition /
Modeling
• Functional Allocation
• White Box Use Case Analysis
• Class Identification
• Package Definition
Step 3
• Sequence Diagram
• Activity Diagram
• Class/Block Definition (with
stereotypes)
• Rules Model
• Data Model
• Deployment Diagram
Step 4
• State Transition Diagram
• Executable Model
Step 5
• Architecturally Derived
Requirements
– Shows transition of target EA from the “As-Is” to the planned “To-Be” to
the desired “Should-be”
13
OOA&D Artifacts
SADT Artifacts
• Concept of Operations
• Integrated Dictionary
• External Functional
Decomposition
• Internal Functional
Decomposition
• Architecturally Derived
Requirements
• Service Identification
• Rules Models
• Enhanced Functional Flow
Block Diagrams
•
•
•
•
•
•
•
•
•
•
•
•
•
Concept of Operations
Integrated Dictionary
Service Component Model
Class Diagram
Data Model
Resource Flow Matrix
Use Cases
Inventory Diagram
Rules Models
Deployment Diagram
Activity Diagrams
State Transition Diagram
Executable Model
14
• A hybrid methodology leverages top-down, holistic,
systematic, development techniques of SADT with the
adaptability of OOA&D to create an architecture that
offers the best of both worlds
• A bridge is formed among stakeholders, system
architects, system engineers, developers, and system
integrators
• The hybrid enterprise architecture approach presented
today is extensible and must be tailored to meet unique
project needs
16
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Bienvenu, M.P. , I. Shin, and A.H. Levis, “C4ISR Architectures III: An Object-Oriented Approach for Architecture
Design”, Systems Engineering 3(4) (2000) 288-312.
Booch ,Grady, Object-Oriented Analysis and Design with Applications, 3rd edition Addison-Wesley (2007).
Buede, D. The Engineering Design of Systems: 2nd Ed. John Wiley and Sons, Inc., Hobeken, NJ., (2009).
“Federal Enterprise Architecture Consolidated Reference Model,” Version 2.3. October (2007)
Estefan, J. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, B, Seattle, WA, USA:
International Council on Systems Engineering. INCOSE-TD-2007-003-02 (2008).
Grady, J., Universal Architecture Description Framework, Systems Engineering 12(2) (2009) 91-116.
Katic, N., B. Nevstrujev,and D. Vogel, Bridging the Gap Between Structured Requirements and Object-Oriented
Analysis and Design: Proceedings of the 29th Annual Conference on System Science (1996).
Keeney, R.L, Value-Focused Thinking: A Path to Creative Decision Making, Massachusetts, Harvard University
Press (1992).
Levis, A. H. and L. Wagenhals, L., C4ISR Architectures I: Developing a Process for C4ISR Architecture Design,
Journal of Systems Engineering: 3(4) (2000) 225-247 .
Long, D, and Z. Scott, A primer for Model-based Systems Engineering, 2nd Ed., Vitech, Blacksburg, VA, (2011).
Parnell, G. S., P.J.Driscoll, and D.L. Henderson; Decision Making in Systems Engineering and Management:
2nd Ed. John Wiley and Sons, Inc., Hoboken, NJ. (2010).
Tom DeMarco, Structured Analysis and System Specification, New York: Yourdon Press, (1978)
Wagenhals L.W; Haider S.; and Levis A. H.: Synthesizing Executable Models of Object Oriented Architectures:
(6), 4 (2003) 266-300.
Wagenhals,L I. Shin, D. Kim, and A.H. Levis, C4ISR Architectures II: A Structured Analysis Approach for
Architecture Design, Journal of Systems Engineering, 3(4) (2000) 248-287.
Wymore, W. Model-Based Systems Engineering: Boca Raton, FL: CRC Press. (1993).
17