1. Thoughts on Architecting. . . And How to Improve the Practice Version 4.2 April 2, 2009 Brad Mercer Chief Architect Maritime IT and Engineering The MITRE Corporation San Diego, California Copyright ©2009The 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.

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

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

5. Dealing with Complexity Today 10 Actors / ~ 25 Activities / ~ 20 Actor Relationships/ ~ 1 Shared Information Space

6. In Reality … Dealing with Complexity Today 100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces

8. Move towards systems of systems and families of systems

9. Strive for increased systems agility in support of increased operational agility

10. Move from platform-base to capability-based planning

11. Overly complicate acquisition practicesWe may be hitting fundamental limits within the methods we use today for systems development

12. Architecture TheoryA Quick Course Yogi Berra said: “In theory there is no difference between theory and practice. In practice there is.” 4/02/2009- 8 Copyright ©2009The MITRE Corporation. All Rights Reserved.

13. All Systems have an Architecture Architecturen.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 have an 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 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. If you don’t control the architecture of your system, then that architecture will control your system!

15. Architecture Descriptions and Frameworks Architecturen. 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 reality Architecture 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 EngineeringTwo Sides of the Same Problem 4/02/2009 - 12 Copyright ©2009The MITRE Corporation. All Rights Reserved.

18. Reduces complexity

19. Optimizing - technical optimization

20. Quantitative costs

21. Deductive

22. Algorithms

23. Value in the “how”

24. Emphasis on arrangement (syntax)

25. Internal interfaces - Boundedness

26. Precision; exact

27. Produces implementation specification

28. Engineering “design”

29. Holistic

30. Manipulates complexity

31. Satisficing - client satisfaction

32. Qualitative worth

33. Abductive

34. Heuristics

35. Value in the “what”

36. Emphasis on meaning (semantics)

37. External interfaces - Openness

38. Abstraction; notional

39. Produces architectural specification

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

42. collective vision, goals, constraints, and other needs of the stakeholders Architecting Architecting and Engineering─ Two Sides of the Same Problem Synthesis of Form iteratively compose separate elements to form a coherent whole architecture specification engineerible requirements iteratively decompose and separate a primarily functional representation of a whole Analysis of Function Engineering representations of economically producible components that can be assembled to construct the functional whole

43. From Capabilities to SystemsThe Role of the Architect in DoD 4/02/2009 - 17 Copyright ©2009The MITRE Corporation. All Rights Reserved.

44. Yesterday … The Platform Enterprise Value Chain Mission Need Mission Need Statement Platform Planning Operational Requirements Platform Development Platform Platform Employment Mission Achieved Requirements Development Deployment and Warfighting Planner Platform Operational Requirements Builder Systems Engineering and Development Process Requirements Engineering System Demo & Validation Operator Functional Allocation System Integ & Test Component Development 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.

45. Capability Development Capability Capability Employment Achieved Effects Today … The Capability Enterprise Value Chain Desired Effects (conflict, market, social, other) Capability Expression Capability Concept Capability Planning Capability Need “Strategist’s View” Doctrine, CONOPS “Planner’s View” JCIDS “Builder’s View” 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’s View” Warfighting

46. There is a Significant Missing Linkin DoD’s Capability Value Chain!! Desired Effects (conflict, market, social, other) Capability Expression Capability Concept Capability Planning Capability Need Capability Development Capability Capability Employment Achieved Effects “Strategist’s View” Doctrine, CONOPS “Planner’s View” JCIDS Description Gap Engineerible Requirements “Builder’s View” 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’s View” Warfighting

47. Architecting is the Disciplinethat Bridges the Description Gap Desired Effects (conflict, market, social, other) Capability Expression Capability Concept Capability Planning Capability Need Capability Architecting Capability Architecture Capability Development Capability Capability Employment Achieved Effects “Strategist’s View” Doctrine, CONOPS “Planner’s View” JCIDS “Architect’s View” Architecture Specification “Builder’s View” 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’s View” Warfighting

48. Architecting is the Discipline that Bridges the Description Gap

49. Architecting is a Multiple Domain Discipline Capability Architecting In capability architecting the architect applies architecting principles and practices to translate capability needs into enterprise engineering requirements Enterprise Architecting 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 Systems Architecting In systems architecting the architect applies architecting principles and practices to allocate engineering requirements to system/product components Operational Architecting In operational architecting the architect applies architecting principles and practices to select and integrate operational resources into an effective mission focused structure

50. DoD Architects Practice in Multiple Domains Desired Effects (conflict, market, social, other) Capability Expression Capability Concept Capability Planning Capability Need Capability Architecting Capability Architecture Capability Development Capability Capability Employment Achieved Effects “Strategist’s View” Enterprise Architecting “Planner’s View” “Architect’s View” “Builder’s View” System Architecting “Operator’s View”

51. Architecture-Driven Systems Development The Role of Architecture Throughout Systems Development 4/02/2009 - 25 Copyright ©2009The MITRE Corporation. All Rights Reserved.

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

53. Description Gap Leads to Requirements Failure Desired Effects (conflict, market, social, other) Capability Expression Capability Concept Capability Planning Capability Need Capability Development Capability Capability Employment Achieved Effects “Strategist’s View” Doctrine, CONOPS “Planner’s View” JCIDS Issue #1 – Inadequate translation of capability need into engineering requirements leads to requirements failure Description Gap Engineerible Requirements “Builder’s View” 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’s View” Warfighting

54. … And Requirements Failure Cascades Through the Capabilities-to-Systems Value Chain Desired Effects (conflict, market, social, other) Capability Expression Capability Concept Capability Planning Capability Need Capability Development Capability Capability Employment Achieved Effects “Strategist’s View” Doctrine, CONOPS Inadequate translation of capability need into engineering requirements results in … “Planner’s View” JCIDS Poor initial requirements baseline which cascades through systems development and ultimately results in … Description Gap Engineerible Requirements Inadequate linkage of requirements to developed system which results in … “Builder’s View” DoD 5000 Inability to validate resulting system against original need “Operator’s View” Warfighting

56. … where those architecture descriptions serve as the “scaffolding” upon which to attach, organize and relate requirements.

58. Functional Specification Establishesthe 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 system-level “black box” design into a first level system design consisting of functional elements that achieve system behavior and performance.

59. 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. System Requirements The Role of Systems Architecting within Systems Engineering Systems Engineering and Development Process Requirements Engineering System Demo & Validation System Integ & Test Functional Allocation 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?

60. First Real “System Architecture” Emergesat 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 Allocated Baseline translates an abstract functional design into producible physical components.

61. 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” Product Baseline translates the configuration tree into COTS, GOTS or developmental item products.

62. 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 4/02/2009- 35 Copyright ©2009The MITRE Corporation. All Rights Reserved.

63. Additional Slides 4/02/2009 - 36 Copyright ©2009The MITRE Corporation. All Rights Reserved.

65. Architecting is the process 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 Synthesis Engineers design through Analysis 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 apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.

66. Sciencenoun The 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. Artnoun A 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 them OK, so … technicians are now “engineers”, and engineering-focused designers are now “architects”? What happened to realengineers and architects?

68. Architectures within Architectures within … 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 DoD ArchitectingA 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 View Conceptual Model Conceptual Data Model Logical Data Model Physical Data Model 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 “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 Logical data models do not represent the architect’s view – they include too many non-architecture artifacts The “Architect’s View” is expressed using a formal conceptual model that provides a common set of semantics for expressing that view Implemented Database The Model Stack

71. Architecture Semantics Event When? generates selects Where? How? Function Location Rule groups controls Why? consumes groups produces accomplishes Resource Product What? Who?

72. What is the structure or form of a system? FUNCTION BEHAVIOR Architecture INFORMATION Functional “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.