Upload
rajessssh
View
215
Download
0
Embed Size (px)
Citation preview
8/22/2019 2003-1118 REAP Overview - UT Dallas
1/25
Custom er Success Is Our Mission
Integrating TOGAF, Zachman andDoDAF Into A Common Process
Rolf Siegers
Senior Principal Software Systems Engineer
November 2003
8/22/2019 2003-1118 REAP Overview - UT Dallas
2/25
Topics
Definitions
Why Architecture?
Building Blocks of an Architecture Process
Unifying the Standards
Summary
8/22/2019 2003-1118 REAP Overview - UT Dallas
3/25
Definitions
Architecture The fundamental organization of a system embodied in its components, their relationships to
each other and to the environment, and the principles guiding its design and evolution.(IEEE 1471-2000)
Architecture Framework A resou rce that guides the development or descr ipt ion of an architecture
Business Architecture A perspect ive of the o veral l architecture ref lect ing enterpr ise m ission, strategies, goals,
busin ess drivers, business proc esses, inform at ion f lows, and the sup port ing org anizat ional
st ructure
Technical Architecture Perspectives of the overall architecture reflecting the enterprises data, applications and
technical com ponents
Enterprise Architecture A blu epr int (set of models) that depicts how v arious busin ess and technic al elements wo rk
together as a who le
Enterprise e : the highest level of a sys tem or sys tem of systems
E : a Department or Agency o f the government
8/22/2019 2003-1118 REAP Overview - UT Dallas
4/25
Custom er Success Is Our Mission
Why Architecture?
8/22/2019 2003-1118 REAP Overview - UT Dallas
5/25
Why Architecture?
Government
Customer Expectations
Industry
Competition
Academia
Our Future
8/22/2019 2003-1118 REAP Overview - UT Dallas
6/25
Why Architecture?Government: Background
The US Government has clearly established their direction and expectationfor how complex systems of the future will be developed and integratedthrough architecture.
Spans all Departments and Agencies
Not the tech or process trend du jour this is traceable back over a decade
Department of Defense Architecture Framework 2003
Federal Enterprise Architecture Service Component & 2003Technical Reference Models
Federal Enterprise Architecture Business Reference Model 2002
Federal/DoD Enterprise Architecture Certification Institute 2002
Federal Enterprise Architecture Program Management Office 2001 Treasury Enterprise Architecture Framework 2000
Federal Enterprise Architecture Framework 1999
C4ISR Architecture Framework 1996, 1997
Establishment of CIO Council by Executive Order 13011 1996
Congressional acts (GPRA 1993; FASA 1994; ITMRA 1996)
Defense Science studies of early 1990s
8/22/2019 2003-1118 REAP Overview - UT Dallas
7/25
Why Architecture?Government: Sound Bites
OMB: Business cases must relate to enterprise architectures for 2005;Government Computer News; 5/22/03
Agencies should include with their business case submissions a copy of theirarchitecture framework and an explanation of how it relates to the federal blueprintmorethan 2,000 agency officials have attended seminars the office conducts on how to preparebusiness cases.
Get down to business with an architecture; Government Computer News; 4/7/03
The message from the Office of Management and Budget to agency managers is loud and
clear: No enterprise architecture, no funding.
DoD lays out enterprise architecture plans; Government Computer News; 4/4/03
the grid will be a globally connected, single information system with an enterprisearchitecture called the Net-Centric Enterprise Service[SAIC] last month received a $50million, five-year contract from the Office of the Joint Chiefs of Staff to plan and developthe grid.
Architecture due diligence; Federal Computer Week; 3/31/03
Agency spending on enterprise architectures is expected to increase to more than $1billion this year according to OMB
Feds work on melding architectures; Federal Computer Week; 2/10/03
The Defense framework is probably the farthest removed from the FEA, but developers ofthe framework have checked, and if components are collecting the data needed to meetDOD architecture requirements, the data should also qualify for the FEA reference models,[Mitre] said.
[Note: Article titles above are hyperlinks]
http://www.gcn.com/vol1_no1/enterprise-architecture/22172-1.htmlhttp://www.gcn.com/22_7/enterprise-architecture/21535-1.htmlhttp://www.gcn.com/vol1_no1/enterprise-architecture/21630-1.htmlhttp://www.fcw.com/fcw/articles/2003/0331/tec-arch-03-31-03.asphttp://www.fcw.com/fcw/articles/2003/0210/web-fea-02-10-03.asphttp://www.fcw.com/fcw/articles/2003/0210/web-fea-02-10-03.asphttp://www.fcw.com/fcw/articles/2003/0331/tec-arch-03-31-03.asphttp://www.gcn.com/vol1_no1/enterprise-architecture/21630-1.htmlhttp://www.gcn.com/22_7/enterprise-architecture/21535-1.htmlhttp://www.gcn.com/vol1_no1/enterprise-architecture/22172-1.html8/22/2019 2003-1118 REAP Overview - UT Dallas
8/25
Why Architecture?Government: Sound Bites
OMB looks to extend architecture to DOD, intelligence;Government Computer News; 9/13/02
The Office of Management and Budget is beginning to figure out how to integrate thefederal enterprise architecture with the Defense Department and intelligence agencies
systems.
If you only read one article on the importance of this
topic, please read Information Week, Nov 11 2002
One Nation , Under I.T.
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=6504197
http://www.gcn.com/vol1_no1/daily-updates/20023-1.htmlhttp://www.informationweek.com/shared/printableArticle.jhtml?articleID=6504197http://www.informationweek.com/shared/printableArticle.jhtml?articleID=6504197http://www.gcn.com/vol1_no1/daily-updates/20023-1.html8/22/2019 2003-1118 REAP Overview - UT Dallas
9/25
Architecture Validation
Product Formats
Collaboration
Architectural Products
Architecting Method
Piecing The Puzzle Together:Whats Needed In An Architecting Process?
METHOD
PRODUCTS
FORMATS
VALIDATION
C
O
L
L
A
B
O
R
AT
I
O
N
8/22/2019 2003-1118 REAP Overview - UT Dallas
10/25
Architecting Method
Architectural Products
Product Formats
Architecture Validation
Collaboration
Building Blocks
The Open Group Architecture Framework(TOGAF)
Version 8.0
Enterprise Edition
Architecture Development Method (ADM)
8/22/2019 2003-1118 REAP Overview - UT Dallas
11/25
Architecting Method
Architectural Products
Product Formats
Architecture Validation
Collaboration
Building Blocks (contd)
The Department of DefenseArchitecture Framework (DoDAF)
Final Draft Version 1.0
ApplicableView
FrameworkProduct
FrameworkProduct Name
GeneralDescription
AllViews A V- 1 Ov er vi ew a nd S um ma ryInformation
Scope, purpose, intended users,environment depicted,analyticalfindings
AllViews AV-2 IntegratedDictionary Datarepository w ith definit ionsofalltermsusedinallproducts
Operational O V- 1 H ig h- L ev el O pe r at io na lConcept Graphic
High-level graphical/textual descriptionof operationalconcept
Operational OV -2 Op er at ion al N od eConnectivity Description
Operationalnodes,operationalactivitiesperformedateachnode,connectivity andinformation exchangeneedlinesbetween nodes
Operational O V- 3 O pe ra t io na l I nf o rm at io nExchange Matrix
Information exchangedbetween nodesandthe relevantattributesofthatexchange
Operational OV -4 Or gan iz at io nalRelationshipsChart
Organizational,role, or other relationshipsamongorganizations
Operational OV-5 OperationalActivity Model OperationalActivities,relationshipsamongactivities, inputsand outputs. Overlays canshow cost, performingnodes, orother pertinentinformation
Operational OV-6a OperationalRulesModel Oneofthethreeproducts used todescribe operational activitysequenceand timing -identifies businessrul esthat constrainoperation
Operational O V- 6b Op er at io na l St at eTransitionDescription
Oneofthree productsusedto describeoperationalactivitysequenceand timing -identifies businessprocess responsestoevents
Operational O V- 6c O pe ra t io na l Eve nt -T r ac eDescription
Oneofthree productsusedto describeoperationalactivitysequenceand timing - tracesactionsin a scenarioorsequenceof events andspecifiestimingofevents
Operational O V- 7 L og i ca l Dat a M od el Doc um en ta ti on o f t he d a ta r eq ui re me nt s a nd s t ru ct ur albusiness processrules ofthe OperationalView.
Systems SV-1 Systems Int erfaceDescription
Identification ofsystems and system componentsand theirinterconnections,within andbetween nodes
S ys te ms S V- 2 S ys te ms C ommu ni cat io nsDescription
Systemsnodes andtheir relatedcommunications lay-downs
Sys te ms SV- 3 Sys te ms -Sy st em s M at ri x Rel at i on s hi ps a m on g s ys te ms i n a g iv en a r ch it ec tu re ; c an b edesigned toshow relationshipsof interest,e.g., system-typeinterfaces,planned vs. existinginterfaces, etc.
S ys te ms S V- 4 S ys te ms F un ct io na lit yDescription
Functionsperformed by systemsand theinformation flowamong system functions
Systems S V- 5 Op er at io na l Ac ti vi ty t oSystemsFunctionTraceability Matrix
Mappingof systems backto operationalcapabilities or ofsystemfunctions back tooperational activities
S ys te ms S V- 6 Sy st ems D at a Exc han geMatrix
Providesdetails of systemsdata beingexchanged betweensystems
S ys te ms S V- 7 Sy st ems P er for man ceParametersMatrix
Performancecharacteristics of each system(s)hardware andsoftwareelements, for theappropriate timeframe(s)
Systems SV-8 Sy ste ms Ev oluti onDescription
Plannedincrementalsteps towardmigratingasuiteof systemstoa moreefficientsuite, or toward evolvinga currentsystemtoafuture implementation
S ys te ms S V- 9 Sy st ems T ech no lo gyForecast
Emergingtechnologies andsoftware/hardware productsthatareexpectedtobeavailableina givenset oftimeframes,andthatwillaffectfuturedevelopmentof thearchitecture
Sys te ms SV- 10 a Sys te ms Ru le s M od el O ne o f t hr ee pr o du ct s u se d t o d es cr i be s y st em s a ct iv it ysequenceand timingConstraintsthat areimposedonsystems functionality due tosome aspectof systemsdesign orimplementation
S ys te ms S V- 10 b S ys te ms S ta te T ra ns it io nDescription
Oneofthree productsusedto describesystemsactivitysequenceand timingResponsesof asystem to events
S ys te ms S V- 10 c S ys te ms E ve nt -T ra ceDescription
Oneofthree productsusedto describesystemsactivitysequenceand timing -- System-specific refinements ofcriticalsequences of eventsand thetimingoftheseevents
Sys te ms SV- 11 Phy si ca l Sc he ma Phy si c al i mp le me nt a ti on o f t h e in fo rm at io n o f t he L og ic al Da taModel,e.g., message formats,file structures,physical schema
Technical T V- 1 T ec hn ic al S ta nd ar dsProfile
Extractionofstandardsthatapply tothegiven architecture
Technical T V- 2 T ec hn ic al S ta nd ar dsForecast
Description ofemerging standardsthat areexpected toapplytothegivenarchitecture, withinan appropriatesetoftimeframes
8/22/2019 2003-1118 REAP Overview - UT Dallas
12/25
Architecting Method
Architectural Products
Supplementing the DoDAF
Product Formats
Architecture Validation
Collaboration
Building Blocks (contd)
The Zachman Framework ForEnterprise Architecture
8/22/2019 2003-1118 REAP Overview - UT Dallas
13/25
Architecting Method
Architectural Products
Product Formats
Architecture Validation
Collaboration
Building Blocks (contd)
DoDAF Templates Unified Modeling Language (UML)
Integrated Computer-Aided
Manufacturing (ICAM) DEFinition (IDEF)
DoDAF, Final Draft Version 1.0
8/22/2019 2003-1118 REAP Overview - UT Dallas
14/25
Architecting Method
Architectural Products
Product Formats
Architecture Validation
Collaboration
Software Engineering InstitutesArchitecture Tradeoff AnalysisMethod
SM
Quality Attribute Assessment
Techniques (e.g., Colored Petri Nets)
Building Blocks (contd)
Software Engineering Institute
University of Aarhus CS Department
8/22/2019 2003-1118 REAP Overview - UT Dallas
15/25
Building Blocks (contd)
Architecting Method
Architectural Products
Product Formats
Architecture Validation
Collaboration
8/22/2019 2003-1118 REAP Overview - UT Dallas
16/25
REAP: A Unification of Standards
ApplicableView
FrameworkProduct Framework Product Name General Description
All Views AV-1 Overview and SummaryInformation
Scope, purpose, intended users, environment depicted,analytical findings
All Views AV-2 Integrated Dictionary Data repository with definitions of all terms used in allproducts
Operational OV-1 High-Level OperationalConcept Graphic
High-level graphical/ textual description of operational concept
Operational OV-2 Operational NodeConnectivity Description
Operational nodes, operational activities performed at eachnode, connectivity and information exchange needlinesbetween nodes
Operational OV-3 Operational InformationExchange Matrix
Information exchanged between nodes and the relevantattributes of that exchange
Operational OV-4 OrganizationalRelationships Chart
Organizational, role, or other relationships amongorganizations
Operational OV-5 Operational Activity Model Operational Activities, relationsh ips among activities, inputsand outputs. Ov erlays can show cost, performing nodes, orother pertinent information
Operational OV-6a Operational Rules Model One of the three products used to describe operational activitysequence and timing - identifies business rules that constrainoperation
Operational OV-6b Operational StateTransition Description
One of three products used to describe operational activitysequence and timing - identifies business process responsesto events
Operational OV-6c Operational Event-TraceDescription
One of three products used to describe operational activitysequence and timing - tr aces actions in a scenario orsequence of events and specifies timing of events
Operational OV-7 Logical Data Model Documentation of the data requirement s and structuralbusiness process rules of the Operational View.
Systems SV-1 Systems InterfaceDescription
Identificati on of systems and system c omponents and theirinterconnections, within and between nodes
Systems SV-2 Systems CommunicationsDescription
Systems nodes and their related communications lay-downs
Systems SV-3 Systems-Syste ms Matrix Relationship s among systems in a given architectur e; can bedesigned to show relationships of interest, e.g., system-typeinterfaces, planned vs. existing interfaces, etc.
Systems SV-4 Systems FunctionalityDescription
Functions performed by systems and the information flowamong system functions
Systems SV-5 Operational Activity toSystems FunctionTraceability Matrix
Mapping of systems back to operational capabilities or ofsystem functions back to operational activities
Systems SV-6 Systems Data ExchangeMatrix
Provides details of systems data being exchanged betweensystems
Systems SV-7 Systems PerformanceParameters Matrix
Performance characteristics of each system(s) hardware andsoftware elements, for the appropriate timeframe(s)
Systems SV-8 Systems EvolutionDescription
Planned incremental steps toward migrating a suite of systemsto a more efficient suite, or toward evolving a current system toa future implementation
Systems SV-9 Systems TechnologyForecast
Emerging technologies and software/hardware products thatare expected to be available in a given set of timeframes, andthat will affect future development of the architecture
Systems SV-10a Systems Rules Model One of three products used to describe systems activity
sequence and timing
Constraints that are imposed onsystems functionality due to some aspect of systems design orimplementation
Systems SV-10b Systems State TransitionDescription
One of three products used to describe systems activitysequence and timingResponses of a system to events
Systems SV-10c Systems Event-TraceDescription
One of three products used to describe systems activitysequence and timing -- Sy stem-specific refinements of criticalsequences of events and the timing of these events
Systems SV-11 Physical Schema Physical implementation of the information of the Logical DataModel, e.g., message formats, file structures, physical schema
Technical TV-1 Technical StandardsProfile
Extraction of standards that apply to the given architecture
Technical TV-2 Technical StandardsForecast
Description of emerging standards that are expected to applyto the given architecture, within an appropriate set oftimeframes
Software Engineering
Institute
Raytheon Enterprise Architecture Process (REAP) I Enterprise Understanding
II Architecture Planning
III Business Architecting
IV Technical Architecting
V Architecture Validation
Five Activities of
Architecture Process
Inter-Activity Iteration
Intra-Activity Iteration
Activity VArchitecture
Validation
Activity IVTechnical
Architecting
Activity IEnterprise
Understanding
Activity IIArchitecture
Planning
Activity IIIBusiness
Architecting
8/22/2019 2003-1118 REAP Overview - UT Dallas
17/25
Activity I: Enterprise Understanding
Goals Set context for architecture and
architecting activities
Common understanding with customer
on the [E/e]nterprise, the architecting
initiative, and the problem space
TOGAF Relationship
ADM: Phase A
Outputs
DoDAF AV-1, Overview & Summary
Informat ion DoDAF AV-2, Integrated Data Dict ion ary
DoDAF OV-1, High Level Operational
Concept Graphic
DoDAF TV-1, Techn ical Standard s
Prof i le
Subprocesses
Customer-focused architecting
Requirements analysis
Operational/Business analysis
Quality attribute analysis
Inputs
Customer vision, needs, &
requirements documents Domain expertise
Industry & government standards
Activity IEnterprise
Understanding
8/22/2019 2003-1118 REAP Overview - UT Dallas
18/25
Activity II: Architecture Planning
Goal
Establish a plan for the upcomingarchitecting activities, the goals of
the architecture and the architectural
outputs
TOGAF Relationship ADM: Preliminary Phase, Phase A
Outputs Architecture principles
Architecture schedule
Enhanced DoDAF AV-1, Overview &Summary Inform at ion
Architecture engineering environment
Subprocesses
Identify stakeholders Define architecture principles
Identify architectural products, formats andthe supporting Zachman cells
Define product relationships / dependencies
Define schedule
Select tool(s)
Plan concordance, configuration &
consolidation of architectural products Form/train Architecture Team
Inputs
Customer vision, needs, &
requirements documents DoDAF AV-1, AV-2, OV-1,
TV-1
Quality attribute-based requirements
Activity IIArchitecture
Planning
8/22/2019 2003-1118 REAP Overview - UT Dallas
19/25
Activity III: Business Architecting
Goal
Model the customers view
TOGAF Relationship
ADM: Phase B
Outputs
Business/Mission Scenarios within
DoDAF OV-5, Operational Act iv i ty Model Catalogued information from Zachman
Framework Row 2 Cells
Subprocesses
Collect Zachman Framework primitivesfor Row 2
Produce mapping matrices as needed
Model Business/Mission Scenarios
Inputs
Customer vision, needs, &
requirements documents Domain expertise
Architecture principles
DoDAF AV-1, AV-2, OV-1
Architecture engineering
environment
Activity IIIBusiness
Architecting
8/22/2019 2003-1118 REAP Overview - UT Dallas
20/25
Activity IV: Technical Architecting
Goal
Produce the remaining architecturaldescriptions of the enterprise from a
variety of views
TOGAF Relationship
ADM: Phases C, D
Outputs
Architecture Baseline Package
Executable model
Subprocesses
Develop/mature the defined DoDAF viewproducts
Develop the defined additional
architectural products
Ensure concordance between
architectural products
Iteratively evolve an executable model
Inputs
Business Architecture
Customer vision, needs, &requirements documents
Domain expertise
Architecture principles
DoDAF AV-1, AV-2, OV-1,
OV-5, TV-1 (and its referenced
standards)
Activity IVTechnical
Architecting
8/22/2019 2003-1118 REAP Overview - UT Dallas
21/25
Activity V: Architecture Validation
Goal Ensure the architecture is ready
to be implemented
Outputs
Completed architecture checklist
Simulation results
SEIs Architecture TradeoffAnalysis Method
SMresults
Validated architecture
Subprocesses
Architecture checklist
ATAMSM
Quality attribute assessments
Inputs
Architecture Baseline Package
Executable model
Activity VArchitecture
Validation
8/22/2019 2003-1118 REAP Overview - UT Dallas
22/25
Other Analysis Efforts
Enterprise Architecting Tools Object Management Groups Model-Driven Architecture
UML 2.0 for Systems Engineering
OMBs Federal Enterprise Architecture Reference Models
CMMI and IEEE-1471 Mappings
Standardized supplemental views
Agile Modeling
Open Systems Architectures
Certification Programs
8/22/2019 2003-1118 REAP Overview - UT Dallas
23/25
Summary
There are established industry and government standards to helpus address enterprise-wide architectural alignment between
customer mission, strategic goals, business rules, data, application
systems, organization, and technology.
No one standard or framework addresses all the aspects of thearchitecting process. Unification is necessary to complete the
picture.
8/22/2019 2003-1118 REAP Overview - UT Dallas
24/25
Custom er Success Is Our Mission
Questions?
Rolf Siegers
Raytheon Intelligence and Information SystemsGarland, Texas
972.205.5169
mailto:[email protected]:[email protected]8/22/2019 2003-1118 REAP Overview - UT Dallas
25/25
Reference Links
The Open Group Architecture Framework, Version 8.0 http://www.opengroup.org/architecture/togaf8/index8.htm
C4ISR Architecture Framework, Version 2.0
http://www.defenselink.mil/nii/org/cio/i3/AWG_Digital_Library/index.htm
Department of Defense Architecture Framework, Version 1.0
(intermittent drafts appears on Mitres web site; final draft is currentlyout, but no formal release statement has been issued yet)
Zachman Framework for Enterprise Architecture
http://www.zifa.com
http://www.zachmaninternational.com
Software Engineering Institutes Architecture Evaluations
http://www.sei.cmu.edu/ata/ata_eval.html
http://www.opengroup.org/architecture/togaf8/index8.htmhttp://www.defenselink.mil/nii/org/cio/i3/AWG_Digital_Library/index.htmhttp://www.zifa.com/http://www.zachmaninternational.com/http://www.sei.cmu.edu/ata/ata_eval.htmlhttp://www.sei.cmu.edu/ata/ata_eval.htmlhttp://www.zachmaninternational.com/http://www.zifa.com/http://www.defenselink.mil/nii/org/cio/i3/AWG_Digital_Library/index.htmhttp://www.opengroup.org/architecture/togaf8/index8.htm