17
SEDC 2014 Chantilly, VA 3-5 April 2014 A Hybrid Approach to Developing Enterprise Architecture Dr. Warren K. Vaneman Department of Systems Engineering Naval Postgraduate School Monterey, CA Mr. Bruce Fenchel URS Federal Services Systems Engineering & Information Solutions Group Chantilly, VA Mr. Barry Masciale Space Systems Sector TASC, Inc. Chantilly, VA

SEDC 2014 Chantilly, VA 3-5 April 2014

  • Upload
    vesta

  • View
    51

  • Download
    1

Embed Size (px)

DESCRIPTION

SEDC 2014 Chantilly, VA 3-5 April 2014. A Hybrid Approach to Developing Enterprise Architecture. Mr. Barry Masciale Space Systems Sector TASC, Inc. Chantilly, VA. Dr. Warren K. Vaneman Department of Systems Engineering Naval Postgraduate School Monterey, CA. Mr. Bruce Fenchel - PowerPoint PPT Presentation

Citation preview

Page 1: SEDC 2014 Chantilly, VA 3-5 April 2014

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 ServicesSystems Engineering &

Information Solutions Group Chantilly, VA

Mr. Barry MascialeSpace Systems Sector

TASC, Inc. Chantilly, VA

Page 2: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 3: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 4: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 5: SEDC 2014 Chantilly, VA 3-5 April 2014

Characteristics of EA Development Approaches

SADT Characteristics OOA&D CharacteristicsTightly 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

Page 6: SEDC 2014 Chantilly, VA 3-5 April 2014

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

+ =

Page 7: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 8: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 9: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 10: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 11: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 12: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 13: SEDC 2014 Chantilly, VA 3-5 April 2014

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”

Page 14: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 15: SEDC 2014 Chantilly, VA 3-5 April 2014

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

Page 16: SEDC 2014 Chantilly, VA 3-5 April 2014

16

Questions

Page 17: SEDC 2014 Chantilly, VA 3-5 April 2014

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).