sedc 2014 chantilly, va 3-5 april 2014 a hybrid approach to developing enterprise architecture dr....
TRANSCRIPT
SEDC 2014Chantilly, VA
3-5 April 2014
A Hybrid Approach to Developing Enterprise Architecture
Dr. Warren K. VanemanDepartment of Systems Engineering
Naval Postgraduate SchoolMonterey, CA
Mr. Bruce Fenchel URS Federal Services
Systems Engineering &
Information Solutions Group
Chantilly, VA
Mr. Barry MascialeSpace Systems Sector
TASC, Inc. Chantilly, VA
2
Enterprise Architecture Overview• 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
3
• 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
Enterprise Architecture Overview
A hybrid approach capitalizes on the strengths of both SADT and OOA&D
4
SADT & OOA&D
• 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
Characteristics of EA Development Approaches
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
6
Why a Hybrid Approach?• 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
+ =
Partial Metamodel
Activity Diagram
Class/Block Diagram
Use Cases
Sequence Diagram
Functional Requirements
Enterprise-Level Data
SADT Functional
Model
State Transition Diagram
ScenarioDerived
Data
Provides basis for operations
Provides Basis for Info Exchanges
ProvidesClasses and Class
Behavior
Provides Data
Validates
Provide Scenario Derived FunctionsProvides Activities
Provides Lower Level Data
Provides Data
Provides Enterprise-Level Functions
Provides Data
Provides Basis For Classes and Attributes
Generalizes
Provides Classes
Provides Data
Executable Model
Rules Model
Provides Operations
Provides Class Exchanges
Provides Data & Rules
Provides Functional Behavior
Provides Functional Behavior
Provides States
Hybrid Approach Steps
• Program Overview• Fundamental Objective to
Capability Trace• Concept of Operation • Capability to Requirement Trace • Integrated Dictionary
• Black Box Use Case Analysis
SADT
• Architecturally Derived Requirements
OOA&D
• Sequence Diagram• Activity Diagram• Class/Block Definition (with
stereotypes)• Rules Model• Data Model• Deployment Diagram
• State Transition Diagram• Executable Model
• Black Box Functional Boundary Definition
Step 1
Step 3
Step 2
Step 4
Step 5
• White Box Functional Decomposition / Modeling
• Functional Allocation
Step 2
Step 3• White Box Use Case Analysis• Class Identification• Package Definition
9
Hybrid Approach StepsStep 1: Planning the Architecture
• Define scope, purpose, and viewpoint to influence functional decomposition (described in Step 3) – 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 EA development
• 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
• Identify high-level program risks and mitigation strategy
• Program Overview• Fundamental Objective to
Capability Trace• Concept of Operation • Capability to Requirement Trace • Integrated Dictionary
• Black Box Use Case Analysis
SADT
• Architecturally Derived Requirements
OOA&D
• Sequence Diagram• Activity Diagram• Class/Block Definition (with
stereotypes)• Rules Model• Data Model• Deployment Diagram
• State Transition Diagram• Executable Model
• Black Box Functional Boundary Definition
Step 1
Step 3
Step 2
Step 4
Step 5
• White Box Functional Decomposition / Modeling
• Functional Allocation
Step 2
Step 3• White Box Use Case Analysis• Class Identification• Package Definition
10
• Define the enterprise boundary• Understand the interactions of the
enterprise with the external environment– Define what the enterprise provides – Define what the enterprise needs
Hybrid Approach StepsStep 2: Develop Architecture Artifacts
• Program Overview• Fundamental Objective to
Capability Trace• Concept of Operation • Capability to Requirement Trace • Integrated Dictionary
• Black Box Use Case Analysis
SADT
• Architecturally Derived Requirements
OOA&D
• Sequence Diagram• Activity Diagram• Class/Block Definition (with
stereotypes)• Rules Model• Data Model• Deployment Diagram
• State Transition Diagram• Executable Model
• Black Box Functional Boundary Definition
Step 1
Step 3
Step 2
Step 4
Step 5
• White Box Functional Decomposition / Modeling
• Functional Allocation
Step 2
Step 3• White Box Use Case Analysis• Class Identification• Package Definition
• 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
11
• Decompose data consumed and produced by functions (or activities)
• Decompose functions to a level that supports allocation (e.g., system, component, service, human)
Hybrid Approach StepsStep 3: Model Internal EA
• Program Overview• Fundamental Objective to
Capability Trace• Concept of Operation • Capability to Requirement Trace • Integrated Dictionary
• Black Box Use Case Analysis
SADT
• Architecturally Derived Requirements
OOA&D
• Sequence Diagram• Activity Diagram• Class/Block Definition (with
stereotypes)• Rules Model• Data Model• Deployment Diagram
• State Transition Diagram• Executable Model
• Black Box Functional Boundary Definition
Step 1
Step 3
Step 2
Step 4
Step 5
• White Box Functional Decomposition / Modeling
• Functional Allocation
Step 2
Step 3• White Box Use Case Analysis• Class Identification• Package Definition
• 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
12
• 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
Hybrid Approach StepsStep 4: Derive Behavioral Models and Sequence Diagrams
• Program Overview• Fundamental Objective to
Capability Trace• Concept of Operation • Capability to Requirement Trace • Integrated Dictionary
• Black Box Use Case Analysis
SADT
• Architecturally Derived Requirements
OOA&D
• Sequence Diagram• Activity Diagram• Class/Block Definition (with
stereotypes)• Rules Model• Data Model• Deployment Diagram
• State Transition Diagram• Executable Model
• Black Box Functional Boundary Definition
Step 1
Step 3
Step 2
Step 4
Step 5
• White Box Functional Decomposition / Modeling
• Functional Allocation
Step 2
Step 3• White Box Use Case Analysis• Class Identification• Package Definition
• Create behavioral models – Reflect constraints
• Derive requirements from the functional decomposition
13
• 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
Hybrid Approach StepsStep 5: Analyze EA Using Executable Models• Program Overview• Fundamental Objective to
Capability Trace• Concept of Operation • Capability to Requirement Trace • Integrated Dictionary
• Black Box Use Case Analysis
SADT
• Architecturally Derived Requirements
OOA&D
• Sequence Diagram• Activity Diagram• Class/Block Definition (with
stereotypes)• Rules Model• Data Model• Deployment Diagram
• State Transition Diagram• Executable Model
• Black Box Functional Boundary Definition
Step 1
Step 3
Step 2
Step 4
Step 5
• White Box Functional Decomposition / Modeling
• Functional Allocation
Step 2
Step 3• White Box Use Case Analysis• Class Identification• Package Definition
• Use the operational deployment provide insight into the transition strategy/roadmap– Shows transition of target EA from the “As-Is” to the planned “To-Be” to
the desired “Should-be”
14
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
OOA&D Artifacts• 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
Hybrid Artifacts
Summary
• 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
Questions
17
References• 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).