Thoughts On Architecting V4 2
- 1. Thoughts on Architecting.. . And How to Improve the PracticeVersion 4.2April 2, 2009Brad MercerChief ArchitectMaritime IT and EngineeringThe MITRE CorporationSan Diego, CaliforniaCopyright ©2009The MITRE Corporation. All Rights Reserved.
- 2. Today’s SpeakerBrad Merceris 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.
- 3. OverviewComplexity is theEnemy!!Architecture Theory: A Quick CourseArchitecting and Engineering:Two Sides of the Same ProblemFrom Capabilities to Systems:The Role of the Architect in DoDArchitecture-Driven Systems Development: The Role of Architecture Throughout Systems Development
- 4. Complexity is theEnemy!!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
- 5. Dealing with ComplexityToday10 Actors / ~ 25 Activities / ~ 20 Actor Relationships/ ~ 1 Shared Information Space
- 6. In Reality …Dealing with Complexity Today100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces
- 7. Complexity increases aswe . . .Increase the size and scope of the systems we are attempting to specify and build
- 8. Move towards systemsof systems and families of systems
- 9. Strive for increasedsystems agility in support of increased operational agility
- 10. Move from platform-baseto capability-based planning
- 11. Overly complicate acquisitionpracticesWe may be hitting fundamental limits within the methods we use today for systems development
- 12. Architecture TheoryA QuickCourseYogi Berra said: “In theory there is no difference between theory and practice. In practice there is.” 4/02/2009- 8Copyright ©2009The MITRE Corporation. All Rights Reserved.
- 13. All Systems havean ArchitectureArchitecturen.an intrinsic quality or property of a systemconsisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.Systemn. 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!
- 14. All systems havean architecture, intentionally architected or not, and that architecture is a primary determinant of other properties of the system — e.g. behavior, “ilities”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)Why do we Practice Architecting?The Architecting ThesisIf 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.If you don’t control the architecture of your system, then that architecture will control your system!
- 15. Architecture Descriptions andFrameworksArchitecturen. 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 Descriptionn. a representation of an architecture; a conceptualization of the form of a system.Frameworkn. a set of assumptions, concepts, values, and practices that constitutes a way of viewing realityArchitecture Frameworkn. a way of conceptualizing the form of a system.Architecture is reality!Architecture Description is a view of reality!Bad Architecting Rule #1“Don’t ever let reality get in the way of your view of reality!”
- 16. Architecting and EngineeringTwoSides of the Same Problem4/02/2009 - 12Copyright ©2009The MITRE Corporation. All Rights Reserved.
- 17. Architecting and Engineering─Two Sides of the Same ProblemArchitectingEngineeringSynthesis of Form ►◄ Analysis of FunctionReductionist
- 18.
- 19. Optimizing - technicaloptimization
- 20.
- 21.
- 22.
- 23. Value in the“how”
- 24. Emphasis on arrangement(syntax)
- 25. Internal interfaces -Boundedness
- 26.
- 27.
- 28.
- 29.
- 30.
- 31. Satisficing - clientsatisfaction
- 32.
- 33.
- 34.
- 35. Value in the“what”
- 36. Emphasis on meaning(semantics)
- 37. External interfaces -Openness
- 38.
- 39.
- 40. Architectural “design”Engineering –One Side of the ProblemEngineering employs analysis of function to iteratively decomposeand 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 arepresentation of the whole as an“initial point” to be successful!Engineering does not workwithout an initial point!!We call this “initial point”:Engineerible RequirementsThe set of engineering requirements necessary and sufficient to initiatethe successful engineering and production of a system
- 41. Architecting – TheOther Side of the ProblemArchitecting 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 collectivevision, goals, constraints, and otherneeds of the stakeholders — converting conflicting stake-holder demands into a conceptualized whole that maximizes the satisfaction of each stakeholder.From the point of view of architecting,we refer to this “engineering initial point” as an:Architecture SpecificationAn 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.
- 42. collective vision, goals,constraints,and other needs of the stakeholdersArchitectingArchitecting and Engineering─ Two Sides of the Same ProblemSynthesisof Form iteratively compose separate elements toform a coherent wholearchitecture specificationengineerible requirementsiteratively decompose and separate a primarily functional representation of a wholeAnalysisof FunctionEngineeringrepresentations of economicallyproducible components that can beassembled to construct the functional whole
- 43. From Capabilities toSystemsThe Role of the Architect in DoD4/02/2009 - 17Copyright ©2009The MITRE Corporation. All Rights Reserved.
- 44. Yesterday … ThePlatform Enterprise Value ChainMission NeedMission NeedStatementPlatform PlanningOperationalRequirementsPlatform DevelopmentPlatformPlatform EmploymentMission AchievedRequirementsDevelopmentDeploymentand WarfightingPlannerPlatformOperationalRequirementsBuilderSystems EngineeringandDevelopment ProcessRequirementsEngineeringSystem Demo& ValidationOperatorFunctionalAllocationSystem Integ& TestComponentDevelopmentIn 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.
- 45. Capability DevelopmentCapabilityCapability EmploymentAchievedEffectsToday … The Capability Enterprise Value ChainDesired Effects(conflict, market, social, other)Capability ExpressionCapabilityConceptCapability PlanningCapabilityNeed“Strategist’sView”Doctrine,CONOPS“Planner’sView”JCIDS“Builder’sView”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. “Operator’sView”Warfighting
- 46. There is aSignificant Missing Linkin DoD’s Capability Value Chain!!Desired Effects(conflict, market, social, other)Capability ExpressionCapabilityConceptCapability PlanningCapabilityNeedCapability DevelopmentCapabilityCapability EmploymentAchieved Effects“Strategist’sView”Doctrine,CONOPS“Planner’sView”JCIDSDescriptionGapEngineeribleRequirements“Builder’sView”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. “Operator’sView”Warfighting
- 47. Architecting is theDisciplinethat Bridges the Description GapDesired Effects(conflict, market, social, other)Capability ExpressionCapabilityConceptCapability PlanningCapabilityNeedCapability ArchitectingCapabilityArchitectureCapability DevelopmentCapabilityCapability EmploymentAchieved Effects“Strategist’sView”Doctrine,CONOPS“Planner’sView”JCIDS“Architect’sView”ArchitectureSpecification“Builder’sView”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. “Operator’sView”Warfighting
- 48. Architecting is theDiscipline that Bridges the Description Gap
- 49. Architecting is aMultiple Domain DisciplineCapability ArchitectingIn capability architecting the architect applies architecting principles and practices to translate capability needs into enterprise engineering requirementsEnterprise ArchitectingIn enterprise architecting the architect applies architecting principles and practices to plan the alignment of IT resources with corporate strategyCore Principles and Practicesof ArchitectingSystems ArchitectingIn systems architecting the architect applies architecting principles and practices to allocate engineering requirements to system/product componentsOperational ArchitectingIn operational architecting the architect applies architecting principles and practices to select and integrate operational resources into an effective mission focused structure
- 50. DoD Architects Practicein Multiple DomainsDesired Effects(conflict, market, social, other)Capability ExpressionCapabilityConceptCapability PlanningCapabilityNeedCapability ArchitectingCapabilityArchitectureCapability DevelopmentCapabilityCapability EmploymentAchieved Effects“Strategist’sView”EnterpriseArchitecting“Planner’sView”“Architect’sView”“Builder’sView”SystemArchitecting“Operator’sView”
- 51. Architecture-Driven Systems DevelopmentThe Role of Architecture Throughout Systems Development4/02/2009 - 25Copyright ©2009The MITRE Corporation. All Rights Reserved.
- 52. Why are AcquisitionPrograms Failing?Many major government acquisition programs have failed to meet cost, schedule, and performance expectations because:Requirements were unrealistic, too complex, too rigid, and unstableInadequate program planning and risk managementInsufficient effort on system architecture and systems engineeringContractor lacked sufficient capability or/and domain experienceInsufficient commitment to ensure adequate and stable fundingUse of program award/incentive fee not tied to program outcomesFrom: Huffman, Dr. S.D. Improving Acquisition Program Performance: The “Architect” Role. 23 January 2006
- 53. Description Gap Leadsto Requirements FailureDesired Effects(conflict, market, social, other)Capability ExpressionCapabilityConceptCapability PlanningCapabilityNeedCapability DevelopmentCapabilityCapability EmploymentAchieved Effects“Strategist’sView”Doctrine,CONOPS“Planner’sView”JCIDSIssue #1 – Inadequate translation of capability need into engineering requirements leads to requirements failureDescriptionGapEngineeribleRequirements“Builder’sView”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. “Operator’sView”Warfighting
- 54. … And RequirementsFailure Cascades Through the Capabilities-to-Systems Value ChainDesired Effects(conflict, market, social, other)Capability ExpressionCapabilityConceptCapability PlanningCapabilityNeedCapability DevelopmentCapabilityCapability EmploymentAchieved Effects“Strategist’sView”Doctrine,CONOPSInadequate translation of capability need into engineering requirements results in …“Planner’sView”JCIDSPoor initial requirements baseline which cascades through systems development and ultimately results in …DescriptionGapEngineeribleRequirementsInadequate linkage of requirements to developed system which results in …“Builder’sView”DoD 5000Inability to validate resulting system against original need“Operator’sView”Warfighting
- 55. What is Architecture-DrivenSystems Development?The incremental specification and development of a successful system through iterative synthesis of architecture descriptions
- 56. … where thosearchitecture descriptions serve as the “scaffolding” upon which to attach, organize and relate requirements.
- 57. An Architecture Specificationserves as the initial well-formed architecture description from which all other descriptions are iteratively developed.Architecture Specification Establishesthe Engineering Requirements BaselineStakeholder developed capability descriptionslack key engineering-level completeness and consistencynot expressed in the form of requirements traditionally expected as the input to system development, demonstration and productionArchitecture Specification is rigorous enough to form a set of engineering requirements that can drive the Defense Acquisition SystemProvides a black box specification of the systemProvides a performance specification of the system as a wholeDescribes the external interfaces to the systemArchitecture Specification translates vague stakeholder needs into specific engineering requirements from which a series of system development baselines can be iteratively developed.
- 58. Functional Specification EstablishestheFunctional Requirements BaselineDerives a functional solution to the engineerible requirements provided by the architecture specificationProvides a white box specification of the system as a collection of functional elementsProvides a performance specification at the level of functional elementsDescribes the functional interfaces within and to the systemSystem development process continues through successive engineering baselinesSolution space continues to narrow and spiral towards an optimal system designBest implementation selected from the set of candidate implementationsFunctional Specification translates a system-level “black box” design into a first level system design consisting of functional elements that achieve system behavior and performance.
- 59. Traditional Systems ArchitectingSomedebate 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.SystemRequirementsThe Role of Systems Architecting within Systems EngineeringSystems EngineeringandDevelopment ProcessRequirementsEngineeringSystem Demo& ValidationSystem Integ& TestFunctionalAllocationComponentDevelopmentAt 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?
- 60. First Real “SystemArchitecture” Emergesat the Allocated Requirements BaselineProvides set of CI performance and interface specifications that satisfy the functional (and associated non-functional) requirements provided by the functional specificationSpecific system design emerges in the form of configuration items [hardware/software configuration items (CIs) ] and their interface specificationsMay be a many-to-many relationship from functions (and non-functional rqmnts) to CIsProvides 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 architectureAllocated Baseline translates an abstract functional design into producible physical components.
- 61. Product Specification Providesthe “Build-to”Architecture at the Product Requirements BaselineProvides a mapping of COTS, GOTS or developmental item products to the hardware/software configuration items (CIs) described at the allocated baselineProvides a set of product performance and interface specifications that satisfy the requirements provided at the allocated baselineFollows the structure of the “Configuration Item (CI) Tree”Product Baseline translates the configuration tree into COTS, GOTS or developmental item products.
- 62. Thank you!!Please contactme 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-78144/02/2009- 35Copyright ©2009The MITRE Corporation. All Rights Reserved.
- 63. Additional Slides4/02/2009 -36Copyright ©2009The MITRE Corporation. All Rights Reserved.
- 64. Architecting ≠ DesigningManybelieve that architecting and designing are the same thing — not true!Designing is the process of resolving conflicting constraints
- 65. Architecting is theprocess of synthesizing formArchitects and Engineers both apply the process of design and both produce “designs” — but through the application of very different paradigms …Architects design through SynthesisEngineers design through AnalysisArchitects 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 apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.
- 66. SciencenounThe observation, identification,description, experimental investigation, and theoretical explanation of natural phenomena or object of study or inquiry. Methodological activity, discipline, or study: I've got packing a suitcase down to a science.An activity that appears to require study and method: the science of purchasing.Knowledge, especially that gained through experience. Art or Science?From: “science” The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004.ArtnounA system of principles and methods employed in the performance of a set of activities: the art of building.A trade or craft that applies such a system of principles and methods: the art of the lexicographer.Skill that is attained by study, practice, or observation: the art of the baker; the blacksmith's art.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.
- 67. 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 themOK, so … technicians are now “engineers”, and engineering-focused designers are now “architects”? What happened to realengineers and architects?
- 68. Architectures within Architectureswithin …Architecturen. (another definition) the highest level conceptual-ization 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!
- 69. DODAF and DoDArchitectingA Case Study in “Reality”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!“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.”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.”
- 70. The Architect’s ViewConceptualModelConceptual Data ModelLogical Data ModelPhysical Data ModelThe 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“Architect’s View” – View taken by the architect in formalizing and expressing the client’s needs as an architecture descriptionContains only elements needed by the architect to describe an architecture and nothing moreLogical data models do not represent the architect’s view – they include too many non-architecture artifactsThe “Architect’s View” is expressed using a formal conceptual model that provides a common set of semantics for expressing that viewImplemented DatabaseThe Model Stack
- 71.
- 72. What is thestructure or form of a system?FUNCTIONBEHAVIORArchitectureINFORMATIONFunctional “Structure”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)Architecturen. an intrinsic quality or property of a systemconsisting of the arrangement and inter-relationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.Information “Structure”Described using Information Models (e.g. data models, ontologies)Architecture Descriptionn. a representation of an architecture; a conceptualization of the form of a system.