Thoughts on Architecting v4.3

  • 139 views
Uploaded on

Between 2006 and 2009 I developed and presented a number of versions of this presentation. It was intended as an exercise to develop my thinking about the practice of architecting. And, my thinking …

Between 2006 and 2009 I developed and presented a number of versions of this presentation. It was intended as an exercise to develop my thinking about the practice of architecting. And, my thinking certainly did evolve during that period. This version is the last developed. Yet, my thinking on the subject has not remained static in the intervening 4+ years.

Unfortunately I have encountered many differing versions of this presentation across the web. As a result, I thought it necessary to post this last version in hopes of normalizing the use of this presentation by others. I am flattered that so many have found this presentation useful. I urge all who appreciate this work to extend and modify the thinking in your own form in hopes of improving the state of architecting practice. My only request is that you comply with the requirement of the associated creative commons license.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
139
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Thoughts on Architecting . . . And How to Improve the Practice Version 4.3 May 1, 2009 Brad Mercer Chief Architect/Department Head Naval C3 Systems Department The MITRE Corporation San Diego, California Copyright ©2009 The MITRE Corporation. All Rights Reserved.
  • 2. Today’s Speaker Brad Mercer is Chief Architect, Naval C4I Systems, with the MITRE Corporation in San Diego, California. The MITRE Corporation is a Federally Funded Research and Development Corporation (FFRDC). In this capacity Mr. Mercer serves as primary or consulting architect on multiple U.S. Navy system developments and net-centricity initiatives. Mr. Mercer has served in a variety of roles assisting Navy programs and initiatives, including Chief Architect of the National Maritime Domain Awareness (MDA) Initiative; Chief Architect of the Consolidated Afloat Networks and Enterprise Services (CANES) Program; Chair of the DoD Multiservice SOA Consortium’s (MSC) Architecture Working Group; DON CIO Technical Director for SOA Transformation; and architecture advisor to the Office of the Chief Engineer of the U.S. Navy’s Space and Naval Warfare Systems Command (SPAWAR) in San Diego. Mr. Mercer has assisted with both FORCEnet architecture development and the development of SOA concepts for SPAWAR and it’s associated PEOs. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 2
  • 3. Overview ► Complexity is the Enemy!! ► Architecture Theory: A Quick Course ► Architecting and Engineering: Two Sides of the Same Problem ► From Capabilities to Systems: The Role of the Architect in DoD ► Architecture-Driven Systems Development: The Role of Architecture Throughout Systems Development Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 3
  • 4. Complexity is the Enemy!! If the object you are trying to create is simple, you can see the whole thing all at once, and it is not likely to change, then you don't need architecture. All you need is a tool, some raw material and some time. On the other hand, if the object is complex, you can't see it in its entirety at one time and it is likely to change considerably over time, then you need Architecture. If you can’t describe it … then you can’t create it! Adapted From: Enterprise Design Objectives: Complexity and Change © 2008 John A. Zachman, Zachman International Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 4
  • 5. Dealing with Complexity Today Ex terna l M OC Organiz ati USCG, DoS, DHS, CBP, Coa litio n, De fe ns e Ag e nc ie s , ons Pro v ide /Pub lis h Oth e r M ilita ry Se rv ic e s , I nte r-Age n c ie s , NGOs , Co m m e rc ia l Shi ppin g Co m pa nie s , e tc .Da ta /In form a tion to Ne tCe ntric Env rionm e nt (Othe r As s e ts ) 5 Co lle c t Da ta /In form a tion (Hi ghe r HQ) 5 Co lle c t Da ta /In form a tion (Othe rs ) 5 Pro v ide /Pub lis h Da ta /In form a tion to Ne t-Ce ntric En v rion m e n t (Hi ghe r HQ) 5 Ap prov e d Orde rs (Oth e rs ) Cro s s wa lk e d Ord e rs (Othe rs ) Ap prov e d Orde rs /Sc h e du ling M e s s a ge s Su pple m e n ta l ROE S ement al R R uppl OE equest Oth e r As s e t Pla n s Subordina te Forc es M SCP-Othe rs Co lle c t Da ta /In form a tion (Su bs ) 5 Ap prov e d Orde rs (Su bs ) M SCP-Subs M OC C l aborati ve I nformati on E r onment (C E ol nvi I ) All oc a te d F orc e s /Re s ourc e s -COPS Re fine d IPB Ap prov e d M SCP-COPS Ap prov e d M SCP-FOPS All oc a te d F orc e s /Re s ourc e s -FOPS Co lla bo ra tiv e In fo En v iro n (CI E) (Gl oba l Info rm a tion Grid) Oth e r As s e t Pla ns Re fine d IPE- Pla n De v e lo p Sy nc hroniz a tio n M a tri x All oc a te d Fo rc e s / Re s ourc e s Su pple m e n ta l ROE Re que s t CONOP S Dra ft M SCP M SCP Ris k As s e s s m e n t Ris k M i tiga tion Pla n Su pple m e n ta l ROE TSCP Ap prov e d OPORD/ Orde rs / Sc he du ling M e s s a ge s Cro s s wa lk e d Ord e rs Ap prov e d M SCP Ris k As s e s s m e n t (On Ord e rs ) Ord e rs Ris k As s e s s m e nt C ommand El ement Co m m a nd Ele m e nt COPS/F OPS Orde rs Ap prov e M SCP 5 Ord e rs Ap prov e d M SCP Ap prov e Ord e r 5 Ap prov e d Orde rs Ap prov e d Orde rs Type CONOPS Oth e r As s e t Pla n s All oc a te d F orc e s /Re s ourc e s TSCP As s e s s m e n t A ssessment R econci d MS P e l C Su pp ROE-F OPS Sy nc hroniz a tion M a trix Dra ft M SCP-FOPS M SCP-F OPS Future P ans l Oth e r Age nc ie s / Orgs Pla n s Oth e r As s e t Pla n s Fu ture Pla n s CONOPS CONOPS De v e lop e d Un de rs ta nd Pla ns Be ing De v e lo pe d By Oth e r As s e ts 5 Type All oc a te d F orc e s /Re s ourc e s Pre pa re M SCP Ide ntify Allo c a te d 5 Fo rc e s / Re s ourc e s Type 5 Sin gle Type IPB-Pla n (In te l) IPB/As s e t Pla ns Dra ft M SCP Co nduc t M SCP Ris k As s e s s m e nt (Fu ture Pla n s ) 5 FOPS Orde rs M SCP Ris k Re c onc ile M SCP 5 Type Sin gle Future Ops Fu ture Ops Cro s s wa lk e d Ord e rs (FOPS) Re c onc ile d Orde rs (F OPS) Pre pa re Ord e rs (FOPS) 5 Ord e rs (FOPS) FOPS-Orde rs Ris k Type As s e s s Ris k on Orde rs (FOPS) 5 FOPS Orde rs Ris k Ris k As s e s s m e nt FOPS Ba c k Brie f & Cro s s wa lk Ord e rs (FOPS) 5 Re c onc ile Orde rs (FOPS) 5 Co ordin a te Pla n s & Ta s k in g w/Othe r Co m po ne nts & Su pporting Org a niz a tio ns (F OPS) 5 Ord e r Pre pa ra tio n FOPS Orde r Re qm ts IPB Uod a te -Pla n De v e lop m e n t C ent Ops urr Cu rre nt Ops Su pp ROE COPS I ntel l i gence Inte l Re fine IPB to Su pport Pla n De v e lo pm e nt (In te l) 5 Re a c hb a c k Ris k As s e s s m e n t COPS Orde rs Re q m ts M SCP-COPS Logi sti cs Lo gis ti c s W o rk in g Gro ups , Boa rds , & Ce lls W o rk in g Gro ups , Boa rds , & Ce lls COPS-Orde rs Ris k IPB Upd a te (Re a c h) Pre pa re Ord e rs (COPS) 5 Type Ord e rs (COPS) As s e s s Ris k on Ord e rs (COPS) 5 Ris k As s e s s m e nt COPS Type Re c onc ile d Orde rs (COPS) COPS Orde rs Ris k Re c onc ile Orde rs (COPS) 5 Type As s e s s Ris k -Ord e rs Ord e rs Ris k As s e s s m e nts Ba c k Brie f & Cro s s W a lk Ord e rs (COPS) Co ordin a te Pla n s & Ta s k in g w/Othe r Co m po ne nts & Su pporting Org a niz a tio ns (COPS) COPs Orde rs Cro s s wa lk e d Ord e rs (COPS) Ord e rs Ris k As s e s s m e nt-Re a c hba c k Re achbac k Co nduc t M SCP Ris k As s e s s m e nt (Re a c h ) 5 Re fine IPB to Su pport Pla n De v e lo pm e nt (Re a c h ) M HQ w/ M OC_ Pla nnin g_ (Prov id e _ Pla ns _ &_ Orde rs )_ v 1 .0 _ VB_ Appro v e d_ 2 4 _ J a n_ 0 7 (Bus i ne s s Pro c e s s ) Sy s te m Arc hite c t Version 1.0 Dated 24 Tu e Fe b 0 6 , 2 0 0 7 0 5 :5 2 C omment JAN 07 Th is di a gra m de s c ri be s the M SCP de v e lop m e n t a n d foll ow o n ord e rs tha t a re g e ne ra te d ba s e d o n th a t pla n. I t inc orpo ra te s c ha nge s dire c te d a s re s u lt of the M HQ with M OC wa rg a rm e . Proc e s s c olor c o ding m a tc he s tha t of the th e OV-5 Ac tiv i ty M ode l . As s e s s Ris k on Ord e rs (Re a c hba c k ) 5 MHQ Plan (Provide Plans & Orders) Process Diagram (Post MHQ w/MOC Wargame Draft) 10 Actors / ~ 25 Activities / ~ 20 Actor Relationships/ ~ 1 Shared Information Space Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 5
  • 6. In Reality … Dealing with Complexity Today 100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 6
  • 7. Complexity increases as we . . . ► Increase the size and scope of the systems we are attempting to specify and build ► Move towards systems of systems and families of systems ► Strive for increased systems agility in support of increased operational agility ► Move from platform-base to capability-based planning ► Overly complicate acquisition practices We may be hitting fundamental limits within the methods we use today for systems development Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 7
  • 8. Architecture Theory A Quick Course Yogi Berra said: “In theory there is no difference between theory and practice. In practice there is.‖ Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 8
  • 9. All Systems have an Architecture Architecture n. an intrinsic quality or property of a system consisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system. System n. a set of components and an associated mechanism, apparent or not, for integrating them as a cohesive whole. The whole is sufficiently cohesive to have an identity distinct from its environment. System components might include people, cultures, organizations, policies, services, techniques, technologies, information/data, facilities, products, procedures, processes, other systems, and/or any other natural or artificial (i.e. man-made) things – much more than just information or communications system components! Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 9
  • 10. Why do we Practice Architecting? All systems have an architecture, intentionally architected or not, and that architecture is a primary determinant of other properties of the system — e.g. behavior, ―ilities‖ The Architecting Thesis If we can make apparent the architecture of a system, then we can understand, effect, and manage that architecture in order to affect other properties of the system. In architecting our goal is two-fold: – to understand the properties of existing systems (as-is, as built) – to understand and predict the properties of the systems we intend to build (to-be, as-designed) If you don’t control the architecture of your system, then that architecture will control your system! Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 10
  • 11. Architecture Descriptions and Frameworks Architecture n. an intrinsic quality or property of a system consisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system. Architecture Description n. a representation of an architecture; a conceptualization of the form of a system. Framework n. a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality Architecture Framework n. a way of conceptualizing the form of a system. Architecture is reality! Architecture Description is a view of reality! Copyright ©2009 The MITRE Corporation. All Rights Reserved. Bad Architecting Rule #1 ―Don‘t ever let reality get in the way of your view of reality!‖ 5/1/2009 - 11
  • 12. Architecting and Engineering Two Sides of the Same Problem Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 12
  • 13. Architecting and Engineering ─ Two Sides of the Same Problem Architecting Engineering Synthesis of Form • • • • • • • • • • • • Holistic Manipulates complexity Satisficing - client satisfaction Qualitative worth Abductive Heuristics Value in the ―what‖ Emphasis on meaning (semantics) External interfaces - Openness Abstraction; notional Produces architectural specification Architectural ―design‖ Copyright ©2009 The MITRE Corporation. All Rights Reserved. Analysis of Function • • • • • • • • • • • • Reductionist Reduces complexity Optimizing - technical optimization Quantitative costs Deductive Algorithms Value in the ―how‖ Emphasis on arrangement (syntax) Internal interfaces - Boundedness Precision; exact Produces implementation specification Engineering ―design‖ 5/1/2009 - 13
  • 14. Engineering – One Side of the Problem Engineering employs analysis of function to iteratively decompose and separate a primarily functional representation of a whole into representations of economically producible components that can be assembled to construct the functional whole. Big implication here! Engineering requires a representation of the whole as an ―initial point‖ to be successful! Engineering does not work without an initial point!! We call this ―initial point‖: ―initial point‖ engineerible requirements iteratively decompose and separate a primarily functional Analysis representation of a whole of Function Engineering representations of economically producible components that can be assembled to construct the functional whole Engineerible Requirements The set of engineering requirements necessary and sufficient to initiate the successful engineering and production of a system Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 14
  • 15. Architecting – The Other Side of the Problem Architecting employs synthesis of form to iteratively compose separate elements to form a coherent whole, or a representation of a coherent whole, that can serve as an ―initial point‖ for system development. Architecting synthesizes this ―initial point‖ from the collective vision, goals, constraints, and other needs of the stakeholders — converting conflicting stake-holder demands into a conceptualized whole that maximizes the satisfaction of each stakeholder. collective vision, goals, constraints, and other needs of the stakeholders Architecting Synthesis of Form iteratively compose separate elements to form a coherent whole architecture specification From the point of view of architecting, we refer to this ―engineering initial point‖ as an: Architecture Specification An architecture description to which all system implementations must adhere; and a set of principles, practices, and constraints guiding implementation, operation, and evolution of the developed system. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 15
  • 16. Architecting and Engineering ─ Two Sides of the Same Problem collective vision, goals, constraints, and other needs of the stakeholders Architecting Synthesis of Form iteratively compose separate elements to form a coherent whole architecture specification engineerible requirements iteratively decompose and separate a primarily functional Analysis representation of a whole of Function Engineering representations of economically producible components that can be assembled to construct the functional whole Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 16
  • 17. From Capabilities to Systems The Role of the Architect in DoD Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 17
  • 18. Yesterday … The Platform Enterprise Value Chain Mission Need Planner Operational Requirements Platform Operational Requirements Platform Development Operator Deployment and Warfighting Mission Need Statement Platform Planning Builder Requirements Development Platform Requirements Engineering Systems Engineering and Development Process Functional Allocation System Demo & Validation System Integ & Test Platform Employment Component Development Mission Achieved In the ―platform world‖ operational requirements were expressed much like engineering requirements. It was possible for systems development to produce systems that usually could be easily validated against their operational requirements. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 18
  • 19. Today … The Capability Enterprise Value Chain Desired Effects (conflict, market, social, other) “Strategist’s View” Capability Expression Doctrine, CONOPS Capability Concept “Planner’s View” Capability Planning JCIDS Capability Need “Builder’s View” Capability Development Capability “Operator’s View” Capability Employment DoD 5000* * DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components. Warfighting Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 19
  • 20. There is a Significant Missing Link in DoD’s Capability Value Chain!! Desired Effects (conflict, market, social, other) “Strategist’s View” Capability Expression Doctrine, CONOPS Capability Concept “Planner’s View” Capability Planning Capability Need JCIDS Description Gap Engineerible Requirements “Builder’s View” Capability Development Capability “Operator’s View” Capability Employment DoD 5000* * DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components. Warfighting Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 20
  • 21. Architecting is the Discipline that Bridges the Description Gap Desired Effects (conflict, market, social, other) “Strategist’s View” Capability Expression Doctrine, CONOPS Capability Concept “Planner’s View” Capability Planning JCIDS Capability Need “Architect’s View” Capability Architecting Architecture Specification Capability Architecture “Builder’s View” Capability Development Capability “Operator’s View” Capability Employment DoD 5000* * DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components. Warfighting Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 21
  • 22. Architecting is the Discipline that Bridges the Description Gap Desired Effects (conflict, market, social, other) collective vision, goals, constraints, and other needs of the stakeholders Capability Expression Capability Expression Capability Capability Concept Concept Architecting Capability Planning Capability Planning Synthesis of Form Capability Capability Need Need Capability Architecting Capability Architecting architecture specification engineerible requirements Capability Capability Architecture Architecture Capability Development Capability Development Analysis of Function Capability Capability Engineering Capability Employment Capability Employment representations of economically producible components that can be assembled to construct the functional whole Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 22
  • 23. Architecting is a Multiple Domain Discipline Capability Architecting Enterprise Architecting In capability architecting the architect applies architecting principles and practices to translate capability needs into enterprise engineering requirements In enterprise architecting the architect applies architecting principles and practices to plan the alignment of IT resources with corporate strategy Core Principles and Practices of Architecting Operational Architecting Systems Architecting In operational architecting the architect applies architecting principles and practices to select and integrate operational resources into an effective mission focused structure In systems architecting the architect applies architecting principles and practices to allocate engineering requirements to system/product components Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 23
  • 24. DoD Architects Practice in Multiple Domains Desired Effects (conflict, market, social, other) Capability Concept “Planner’s View” Capability Planning Capability Need “Architect’s View” Capability Architecting Capability Architecture “Builder’s View” Capability Development Capability “Operator’s View” Enterprise Architecting Capability Expression System Architecting “Strategist’s View” Capability Employment Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 24
  • 25. Architecture-Driven Systems Development The Role of Architecture Throughout Systems Development Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 25
  • 26. Why are Acquisition Programs Failing? Many major government acquisition programs have failed to meet cost, schedule, and performance expectations because: – Requirements were unrealistic, too complex, too rigid, and unstable – Inadequate program planning and risk management – Insufficient effort on system architecture and systems engineering – Contractor lacked sufficient capability or/and domain experience – Insufficient commitment to ensure adequate and stable funding – Use of program award/incentive fee not tied to program outcomes From: Huffman, Dr. S.D. Improving Acquisition Program Performance: The “Architect” Role. 23 January 2006 Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 26
  • 27. Description Gap Leads to Requirements Failure Desired Effects (conflict, market, social, other) “Strategist’s View” Capability Expression Doctrine, CONOPS Capability Concept “Planner’s View” Capability Planning Capability Need JCIDS Description Gap Engineerible Requirements “Builder’s View” Capability Development Capability “Operator’s View” Capability Employment DoD 5000* * DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components. Warfighting Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 27
  • 28. … And Requirements Failure Cascades Through the Capabilities-to-Systems Value Chain Desired Effects (conflict, market, social, other) “Strategist’s Capability Expression View” Inadequate translation of capability need Doctrine, CONOPS Capability into engineering requirements results in … Concept “Planner’s Capability Planning View” Poor initial requirements baseline which Capability cascades through systems development Need and ultimately results in … “Builder’s View” JCIDS Description Gap Engineerible Inadequate linkage of requirements to Requirements developed system which results in … DoD 5000 Capability Development “Operator’s View” Inability to validate resulting system against Capability original need Capability Employment Warfighting Achieved Effects Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 28
  • 29. What is Architecture-Driven Systems Development? ► The incremental specification and development of a successful system through iterative synthesis of architecture descriptions ► … where those architecture descriptions serve as the ―scaffolding‖ upon which to attach, organize and relate requirements. ► An Architecture Specification serves as the initial wellformed architecture description from which all other descriptions are iteratively developed. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 29
  • 30. Architecture Specification Establishes the Engineering Requirements Baseline Stakeholder developed capability descriptions – lack key engineering-level completeness and consistency – not expressed in the form of requirements traditionally expected as the input to system development, demonstration and production ► Architecture Specification is rigorous enough to form a set of engineering requirements that can drive the Defense Acquisition System – Provides a black box specification of the system – Provides a performance specification of the system as a whole – Describes the external interfaces to the system Architecture Specification translates vague stakeholder needs into specific engineering requirements from which a series of system development baselines can be iteratively developed. Copyright ©2009 The MITRE Corporation. All Rights Reserved. Capability Development Document Architecture Specification Engineering Baseline System Requirements Review (SRR) MS B Functional Specification Functional Baseline System Functional Review (SFR) Item Specifications Allocated Baseline Preliminary (PDR) and Critical Design (CDR) Reviews Product Specifications System Development and Demonstration Phase ► Product Baseline MS C 5/1/2009 - 30
  • 31. Functional Specification Establishes the Functional Requirements Baseline Derives a functional solution to the engineerible requirements provided by the architecture specification – Provides a white box specification of the system as a collection of functional elements – Provides a performance specification at the level of functional elements – Describes the functional interfaces within and to the system ► System development process continues through successive engineering baselines – Solution space continues to narrow and spiral towards an optimal system design – Best implementation selected from the set of candidate implementations Functional Specification translates a systemlevel ―black box‖ design into a first level system design consisting of functional elements that achieve system behavior and performance. Copyright ©2009 The MITRE Corporation. All Rights Reserved. Capability Development Document Architecture Specification Engineering Baseline System Requirements Review (SRR) MS B Functional Specification Functional Baseline System Functional Review (SFR) Item Specifications Allocated Baseline Preliminary (PDR) and Critical Design (CDR) Reviews Product Specifications System Development and Demonstration Phase ► Product Baseline MS C 5/1/2009 - 31
  • 32. Traditional Systems Architecting Some debate whether architecting is part of or separate from systems engineering. However, both views are correct! Traditional systems architecting is generally applied in the context of developing a series of engineering baselines—most notably a functional baseline which includes a functional architecture. Requirements The Role of Systems Architecting within Systems Engineering Requirements Engineering Functional Allocation System Systems Engineering and Development Process System Demo & Validation System Integ & Test Component Development At the functional baseline the architecting paradigm is employed to synthesize a functional model from discrete requirements. But … again this begs the question of where did the requirements come from? Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 32
  • 33. First Real “System Architecture” Emerges at the Allocated Requirements Baseline Provides set of CI performance and interface specifications that satisfy the functional (and associated non-functional) requirements provided by the functional specification ► Specific system design emerges in the form of configuration items [hardware/software configuration items (CIs) ] and their interface specifications – May be a many-to-many relationship from functions (and non-functional rqmnts) to CIs – Provides a structure for the ―Configuration Item (CI) Tree‖ ► In systems engineering the allocated baseline constitutes the first real system architecture and design — very different in concept from DoDAF’s system view which is commonly referred to as a system architecture Capability Development Document Architecture Specification Engineering Baseline System Requirements Review (SRR) MS B Functional Specification Functional Baseline System Functional Review (SFR) Item Specifications Allocated Baseline Preliminary (PDR) and Critical Design (CDR) Reviews Product Specifications System Development and Demonstration Phase ► Product Baseline MS C Allocated Baseline translates an abstract functional design into producible physical components. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 33
  • 34. Product Specification Provides the “Build-to” Architecture at the Product Requirements Baseline ► ► Provides a mapping of COTS, GOTS or developmental item products to the hardware/software configuration items (CIs) described at the allocated baseline Provides a set of product performance and interface specifications that satisfy the requirements provided at the allocated baseline Follows the structure of the ―Configuration Item (CI) Tree‖ Capability Development Document Architecture Specification Engineering Baseline System Requirements Review (SRR) MS B Functional Specification Functional Baseline System Functional Review (SFR) Product Baseline translates the configuration tree into COTS, GOTS or developmental item products. Item Specifications Allocated Baseline Preliminary (PDR) and Critical Design (CDR) Reviews Product Specifications System Development and Demonstration Phase ► Product Baseline MS C Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 34
  • 35. Thank you!! Please contact me at: Brad Mercer Chief Architect Naval C4I Systems Maritime IT and Engineering The MITRE Corporation SPAWARSYSCEN SD 49185 Transmitter Road, Building 626 San Diego, CA 92152-7335 bmercer@mitre.org 619-758-7814 Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 35
  • 36. Additional Slides Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 36
  • 37. Architecting ≠ Designing ► Many believe that architecting and designing are the same thing — not true! – Designing is the process of resolving conflicting constraints – Architecting is the process of synthesizing form ► Architects and Engineers both apply the process of design and both produce ―designs‖ — but through the application of very different paradigms … – Architects design through Synthesis Architects apply the process of design to synthesize a form through trials guided by heuristics in order to compare forms until a qualitative best-fit emerges that satisfices conflicting needs. – Engineers design through Analysis Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 37
  • 38. A Proliferation of “architects” ► One result of confusing architecting and designing is that people who previously were designers now refer to themselves as architects — without any change in skill or objective! ► Anyone who previously did design (network designer, system designer, application designer, solution designer, data designer, business designer, security designer, process designer, etc.) is now an ―architect‖ (network architect, system architect, application architect, solution architect, data architect, business architect, security architect, process architect, etc.) ► Serious implications! These new ―architects‖ are now ―architecting designs‖ (i.e. creating implementations) without a specification (i.e. architecture description) to guide them OK, so … technicians are now ―engineers‖, and engineeringfocused designers are now ―architects‖? What happened to real engineers and architects? Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 38
  • 39. Architect n. a person who practices ―architecting‖ The Practice of Architecting From the simplest point of view, the practice of architecting is the application of the architecting paradigm to the creation of architecture specifications that can be employed as engineerible requirements for engineering and producing systems. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 39
  • 40. Architecture Specification as a Solution Space An Architecture Specification is an architecture description to which all system implementations must adhere; and a set of principles, practices, and constraints guiding implementation, operation, and evolution of the developed system. boundary defined by the architecture specification one potential implementation a set of potential implementations ―a solution space‖ Architects apply the process of design to synthesize a form through trials guided by heuristics in order to compare forms until a qualitative best-fit emerges that satisfices conflicting needs. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 40
  • 41. Engineerible Requirements as a Solution Space Engineerible Requirements are the set of engineering requirements necessary and sufficient to initiate the successful engineering and production of a system boundary defined by engineerible requirements one candidate implementation a set of candidate implementations ―a solution space‖ Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 41
  • 42. What does an Architecture Specification Include? Part I - Architectural Context An expression or representation of the larger scope outside the boundary of the solution space to be established by this architecture specification. Includes expression of the key relationship between this architecture specification and others within the context. Part II - Architectural Qualities Since we are describing a ―solution space‖ rather than a ―point solution‖ architectural qualities are more generalized than requirements as commonly understood to allow for satisfaction by multiple potential implementations. Part III - Architectural Description Most likely expressed as a set of patterns – Standard Patterns – Solution Specific Patterns A Pattern is a general repeatable solution to a commonly occurring problem; combination of implicit and explicit knowledge repeatedly applied with success in the past and commonly captured as best practices and models Part IV - Architectural Guidance A set of principles, practices, and constraints guiding implementation, operation, and evolution of the developed system Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 42
  • 43. Some Principles of Architecture Specification An architecture specification should be well-formed, complete, and consistent enough to allow an engineer to select and describe an underlying implementation and to create a specification for production of the system. ► Well-Formedness – A well-formed outcome is a consequence that meets certain conditions designed to avoid classic self-defeating intentions. It has been clearly and well enough defined to be prima facie free of common "muddy thinking.― ► Semantic Completeness – The condition of a formal system in which (1) the formal language has the power to express as well-formed formulas all of the propositions intended by the maker to be meaningful (expressive completeness), and (2) the deductive apparatus has the power to prove as theorems all the propositions intended by the maker to be true (deductive completeness). Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 43
  • 44. Art or Science? Science noun 1. The observation, identification, description, experimental investigation, and theoretical explanation of natural phenomena or object of study or inquiry. 2. Methodological activity, discipline, or study: I've got packing a suitcase down to a science. 3. An activity that appears to require study and method: the science of purchasing. 4. Knowledge, especially that gained through experience. Art noun From: ―science‖ The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004. 1. A system of principles and methods employed in the performance of a set of activities: the art of building. 2. A trade or craft that applies such a system of principles and methods: the art of the lexicographer. 3. Skill that is attained by study, practice, or observation: the art of the baker; the blacksmith's art. 4. Skill arising from the exercise of intuitive faculties: "Self-criticism is an art not many are qualified to practice" (Joyce Carol Oates). From: ―art‖ The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004. Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 44
  • 45. Architectures within Architectures within … ► Architecture n. (another definition) the highest level conceptualization of a system. ► In defining a System as a ―set of components and an associated mechanism, apparent or not, for integrating them as a cohesive whole‖ we allowed the components of a system to be other systems — and thus we have defined a system as a recursively hierarchical entity. ► As ―architecture‖ is an intrinsic quality of each system in such a recursive hierarchy of systems, there will exist a recursive hierarchy of architectures as well — and each of the levels in this hierarchy will likely have a different conceptualization! ► Serious implications! Lots of debate about what really constitutes THE architecture! Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 45
  • 46. DODAF and DoD Architecting A Case Study in “Reality” ―I once saw an episode of the original ‗Star Trek‘ television series where a century earlier a space traveler from Earth had visited a primitive, but industrious humanoid culture on a far away planet — leaving behind an Earth novel about the conflict in the 1920‘s and 30‘s between Al Capone, the gangster, and Elliott Ness, the FBI G-man.‖ ―By the time Capt Kirk and his starship Enterprise arrived the culture of the entire planet had been modeled on the culture portrayed in the novel – right down to raging gun battles in the streets between gangsters and G-men.‖ The misapplication of DODAF may be the worst thing that has ever happened to the practice of architecting within the DoD. ―Yeah, but it’s better than nothing!” No its not! ―Nothing‖ costs less, happens faster, and has more positive impact! Although it was a good intentioned effort to codify the practice of architecting within DoD, DODAF led to the emergence of an entire generation of DoD architects that viewed architecting as focused on the creation of 26 artifacts or ―architecture products.‖ An entire language of ―SV-this‖ and ―OV-that‖ emerged that soon forgot what architecting was really about — becoming an entire subculture ―lost on a far away planet.‖ Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 46
  • 47. What is the structure or form of a system? Functional ―Structure‖ Architecture INFORMATION Described using Functional Models (e.g. flow diagrams, function hierarchies, interface diagrams) Behavioral ―Structure‖ Described using Behavioral Models (e.g. rule sets, state diagrams, event traces) Architecture n. an intrinsic quality or property of a system consisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system. Information ―Structure‖ Architecture Description n. a representation of an architecture; a conceptualization of the form of a system. Described using Information Models (e.g. data models, ontologies) Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 47
  • 48. The Architect’s View The architect’s role is to formalize and represent the needs of his client – the warfighter. This role motivates a unique view of the architecture – ―the architect’s view.‖ Architect’s View Conceptual Model Conceptual Data Model Logical Data Model Physical Data Model Implemented Database The Model Stack Copyright ©2009 The MITRE Corporation. All Rights Reserved. ► ―Architect’s View‖ – View taken by the architect in formalizing and expressing the client’s needs as an architecture description ► Contains only elements needed by the architect to describe an architecture and nothing more data models do not represent the architect’s view – they include too many non-architecture artifacts ► Logical ► The ―Architect’s View‖ is expressed using a formal conceptual model that provides a common set of semantics for expressing that view 5/1/2009 - 48
  • 49. Architecture Semantics When? Event selects Where? How? groups Function Location controls Rule Why? Resource Who? Copyright ©2009 The MITRE Corporation. All Rights Reserved. Product What? 5/1/2009 - 49
  • 50. Capability and Effects Capability n. The ability to achieve a desired effect under specified standards and conditions through combination of means and ways to perform a set of tasks. ─ From CJCSI 3170.01E, Joint Capabilities Integration and Development System, 11 May 2005 selects Event1 Event11 Event (Time) controls Conditions groups pli s es es t r ra e es om e ne ge s m sum ac c Ways c n c on Copyright ©2009 The MITRE Corporation. All Rights Reserved. s p ps ou ou Means e ro c e produc g gr Resource Resource Effect n. a change to a condition, behavior, or degree of freedom ─ From CJCSM 3500.04D, Universal Joint Task List, 1 August 2005 Function Function he s Location Node Node Standards Rule Rule Product Product Products and Events are not the actual effects achieved by a capability. The effect is achieved indirectly as a change in state in response Event to the products and events. Event2 Event 2 (Time) 2 ―Effect‖ 5/1/2009 - 50
  • 51. A Few Simple Principles Words Mean Things!! One Aspect at a Time!! Copyright ©2009 The MITRE Corporation. All Rights Reserved. Foundation Before Structure!! 5/1/2009 - 51
  • 52. Words Mean Things!! A community of discussion must include all of the concepts necessary to describe its domain and there must be no inconsistencies between the concepts. Principle of Semantic Completeness The condition of a formal system in which (1) the formal language has the power to express as well-formed formulas all of the propositions intended by the maker to be meaningful (expressive completeness), and (2) the deductive apparatus has the power to prove as theorems all the propositions intended by the maker to be true (deductive completeness). Copyright ©2009 The MITRE Corporation. All Rights Reserved. Tower of Babel 5/1/2009 - 52
  • 53. One Aspect at a Time!! A system should be described such that its functions can be examined independently of one another in order to make the system easier to understand, design and manage. Self-Operating Napkin by Rube Goldberg Principle of Separation of Concerns ―… to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency.‖ ―… focusing one's attention upon some aspect: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.‖ – Edsger W. Dijkstra, On the role of scientific thought Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 53
  • 54. Foundation Before Structure!! Structure is not a substitute for a good foundation. Adding more structure will not remedy a bad foundation. Principle of Well-Formedness A well-formed outcome is a consequence that meets certain conditions designed to avoid classic self-defeating intentions. It has been clearly and well enough defined to be prima facie free of common "muddy thinking." Tower of Pisa Copyright ©2009 The MITRE Corporation. All Rights Reserved. 5/1/2009 - 54