Thoughts on Architecting. . . And How to Improve the Practice<br />Version 4.2<br />April 2, 2009<br />Brad Mercer<br />Ch...
Today’s Speaker<br />Brad Mercer is Chief Architect, Naval C4I Systems, with the MITRE Corporation in San Diego, Californi...
Overview<br />Complexity is the Enemy!!<br />Architecture Theory:  A Quick Course<br />Architecting and Engineering:Two Si...
Complexity is the Enemy!!<br />If the object you are trying to create is simple, you can see the whole thing all at once, ...
Dealing with Complexity Today<br />10 Actors / ~ 25 Activities / ~  20 Actor Relationships/ ~ 1 Shared Information Space<b...
In Reality … Dealing with Complexity Today<br />100s Actors / 100s Activities / 1000s Relationships / 10s Shared Informati...
Complexity increases as we . . .<br /><ul><li>Increase the size and scope of the systems we are attempting to specify and ...
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</li></ul>We may be hitting fundamental limits within the methods we use today for ...
Architecture TheoryA Quick Course<br />Yogi Berra said:  “In theory there is no difference between theory and practice.  I...
All Systems have an Architecture<br />Architecturen.an intrinsic quality or property of a systemconsisting of the arrangem...
All systems have an architecture, intentionally architected or not, and that architecture is a primary determinant of othe...
Architecture Descriptions and Frameworks<br />Architecturen.  an intrinsic quality or property of a system consisting of t...
Architecting and EngineeringTwo Sides of the Same Problem<br />4/02/2009 - 12<br />Copyright ©2009The MITRE Corporation.  ...
Architecting and Engineering─ Two Sides of the Same Problem<br />Architecting<br />Engineering<br />Synthesis of Form ►<br...
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”
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”</li></li></ul><li>Engineering – One Side of the Problem<br />Engineering employs analysis of functi...
Architecting – The Other Side of the Problem<br />Architecting employs synthesis of form to iteratively compose separate e...
collective vision, goals, constraints,<br />and other needs of the stakeholders<br />Architecting<br />Architecting and En...
From Capabilities to SystemsThe Role of the Architect in DoD<br />4/02/2009 - 17<br />Copyright ©2009The MITRE Corporation...
Yesterday … The Platform Enterprise Value Chain<br />Mission Need<br />Mission Need<br />Statement<br />Platform Planning<...
Upcoming SlideShare
Loading in …5
×

Thoughts On Architecting V4 2

1,371
-1

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,371
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Thoughts On Architecting V4 2

  1. 1. Thoughts on Architecting. . . And How to Improve the Practice<br />Version 4.2<br />April 2, 2009<br />Brad Mercer<br />Chief Architect<br />Maritime IT and Engineering<br />The MITRE Corporation<br />San Diego, California<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  2. 2. Today’s Speaker<br />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.<br />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.<br />
  3. 3. Overview<br />Complexity is the Enemy!!<br />Architecture Theory: A Quick Course<br />Architecting and Engineering:Two Sides of the Same Problem<br />From Capabilities to Systems:The Role of the Architect in DoD<br />Architecture-Driven Systems Development: The Role of Architecture Throughout Systems Development<br />
  4. 4. Complexity is the Enemy!!<br />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&apos;t need architecture. All you need is a tool, some raw material and some time.<br />On the other hand, if the object is complex, you can&apos;t see it in its entirety at one time and it is likely to change considerably over time, then you need Architecture.<br />If you can’t describe it … then you can’t create it!<br />Adapted From: Enterprise Design Objectives: Complexity and Change<br />© 2008 John A. Zachman, Zachman International<br />
  5. 5. Dealing with Complexity Today<br />10 Actors / ~ 25 Activities / ~ 20 Actor Relationships/ ~ 1 Shared Information Space<br />
  6. 6. In Reality … Dealing with Complexity Today<br />100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces<br />
  7. 7. Complexity increases as we . . .<br /><ul><li>Increase the size and scope of the systems we are attempting to specify and build
  8. 8. Move towards systems of systems and families of systems
  9. 9. Strive for increased systems agility in support of increased operational agility
  10. 10. Move from platform-base to capability-based planning
  11. 11. Overly complicate acquisition practices</li></ul>We may be hitting fundamental limits within the methods we use today for systems development<br />
  12. 12. Architecture TheoryA Quick Course<br />Yogi Berra said: “In theory there is no difference between theory and practice. In practice there is.” <br />4/02/2009- 8<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  13. 13. All Systems have an Architecture<br />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.<br />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.<br />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!<br />
  14. 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”<br />In architecting our goal is two-fold:<br />to understand the properties of existing systems (as-is, as built)<br />to understand and predict the properties of the systems we intend to build (to-be, as-designed)<br />Why do we Practice Architecting?<br />The Architecting Thesis<br />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.<br />If you don’t control the architecture of your system, then that architecture will control your system!<br />
  15. 15. Architecture Descriptions and Frameworks<br />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.<br />Architecture Descriptionn. a representation of an architecture; a conceptualization of the form of a system.<br />Frameworkn. a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality<br />Architecture Frameworkn. a way of conceptualizing the form of a system.<br />Architecture is reality!<br />Architecture Description is a view of reality!<br />Bad Architecting Rule #1<br />“Don’t ever let reality get in the way of your view of reality!”<br />
  16. 16. Architecting and EngineeringTwo Sides of the Same Problem<br />4/02/2009 - 12<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  17. 17. Architecting and Engineering─ Two Sides of the Same Problem<br />Architecting<br />Engineering<br />Synthesis of Form ►<br />◄ Analysis of Function<br /><ul><li>Reductionist
  18. 18. Reduces complexity
  19. 19. Optimizing - technical optimization
  20. 20. Quantitative costs
  21. 21. Deductive
  22. 22. Algorithms
  23. 23. Value in the “how”
  24. 24. Emphasis on arrangement (syntax)
  25. 25. Internal interfaces - Boundedness
  26. 26. Precision; exact
  27. 27. Produces implementation specification
  28. 28. Engineering “design”
  29. 29. Holistic
  30. 30. Manipulates complexity
  31. 31. Satisficing - client satisfaction
  32. 32. Qualitative worth
  33. 33. Abductive
  34. 34. Heuristics
  35. 35. Value in the “what”
  36. 36. Emphasis on meaning (semantics)
  37. 37. External interfaces - Openness
  38. 38. Abstraction; notional
  39. 39. Produces architectural specification
  40. 40. Architectural “design”</li></li></ul><li>Engineering – One Side of the Problem<br />Engineering employs analysis of function to iteratively decompose<br />and separate a primarily functional representation of a whole into representations of economically producible components that can be assembled to construct the functional whole.<br />Big implication here!<br />Engineering requires a<br />representation of the whole as an<br />“initial point” to be successful!<br />Engineering does not work<br />without an initial point!!<br />We call this “initial point”:<br />Engineerible Requirements<br />The set of engineering requirements necessary and sufficient to initiate<br />the successful engineering and production of a system<br />
  41. 41. Architecting – The Other Side of the Problem<br />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.<br />Architecting synthesizes this<br />“initial point” from the collective<br />vision, goals, constraints, and other<br />needs of the stakeholders — converting conflicting stake-holder demands into a conceptualized whole that maximizes the satisfaction of each stakeholder.<br />From the point of view of architecting,<br />we refer to this “engineering initial point” as an:<br />Architecture Specification<br />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.<br />
  42. 42. collective vision, goals, constraints,<br />and other needs of the stakeholders<br />Architecting<br />Architecting and Engineering─ Two Sides of the Same Problem<br />Synthesis<br />of Form<br /> iteratively compose<br /> separate elements to<br />form a coherent whole<br />architecture specification<br />engineerible requirements<br />iteratively decompose and<br /> separate a primarily functional<br /> representation of a whole<br />Analysis<br />of Function<br />Engineering<br />representations of economically<br />producible components that can be<br />assembled to construct the functional whole<br />
  43. 43. From Capabilities to SystemsThe Role of the Architect in DoD<br />4/02/2009 - 17<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  44. 44. Yesterday … The Platform Enterprise Value Chain<br />Mission Need<br />Mission Need<br />Statement<br />Platform Planning<br />Operational<br />Requirements<br />Platform Development<br />Platform<br />Platform Employment<br />Mission Achieved<br />Requirements<br />Development<br />Deployment<br />and Warfighting<br />Planner<br />Platform<br />Operational<br />Requirements<br />Builder<br />Systems Engineering<br />and<br />Development Process<br />Requirements<br />Engineering<br />System Demo<br />& Validation<br />Operator<br />Functional<br />Allocation<br />System Integ<br />& Test<br />Component<br />Development<br />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.<br />
  45. 45. Capability Development<br />Capability<br />Capability Employment<br />Achieved Effects<br />Today … The Capability Enterprise Value Chain<br />Desired Effects<br />(conflict, market, social, other)<br />Capability Expression<br />Capability<br />Concept<br />Capability Planning<br />Capability<br />Need<br />“Strategist’s<br />View”<br />Doctrine,<br />CONOPS<br />“Planner’s<br />View”<br />JCIDS<br />“Builder’s<br />View”<br />DoD 5000*<br />* 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. <br />“Operator’s<br />View”<br />Warfighting<br />
  46. 46. There is a Significant Missing Linkin DoD’s Capability Value Chain!!<br />Desired Effects<br />(conflict, market, social, other)<br />Capability Expression<br />Capability<br />Concept<br />Capability Planning<br />Capability<br />Need<br />Capability Development<br />Capability<br />Capability Employment<br />Achieved Effects<br />“Strategist’s<br />View”<br />Doctrine,<br />CONOPS<br />“Planner’s<br />View”<br />JCIDS<br />Description<br />Gap<br />Engineerible<br />Requirements<br />“Builder’s<br />View”<br />DoD 5000*<br />* 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. <br />“Operator’s<br />View”<br />Warfighting<br />
  47. 47. Architecting is the Disciplinethat Bridges the Description Gap<br />Desired Effects<br />(conflict, market, social, other)<br />Capability Expression<br />Capability<br />Concept<br />Capability Planning<br />Capability<br />Need<br />Capability Architecting<br />Capability<br />Architecture<br />Capability Development<br />Capability<br />Capability Employment<br />Achieved Effects<br />“Strategist’s<br />View”<br />Doctrine,<br />CONOPS<br />“Planner’s<br />View”<br />JCIDS<br />“Architect’s<br />View”<br />Architecture<br />Specification<br />“Builder’s<br />View”<br />DoD 5000*<br />* 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. <br />“Operator’s<br />View”<br />Warfighting<br />
  48. 48. Architecting is the Discipline that Bridges the Description Gap<br />
  49. 49. Architecting is a Multiple Domain Discipline<br />Capability Architecting<br />In capability architecting the architect applies architecting principles and practices to translate capability needs into enterprise engineering requirements<br />Enterprise Architecting<br />In enterprise architecting the architect applies architecting principles and practices to plan the alignment of IT resources with corporate strategy<br />Core Principles and Practices<br />of Architecting<br />Systems Architecting<br />In systems architecting the architect applies architecting principles and practices to allocate engineering requirements to system/product components<br />Operational Architecting<br />In operational architecting the architect applies architecting principles and practices to select and integrate operational resources into an effective mission focused structure<br />
  50. 50. DoD Architects Practice in Multiple Domains<br />Desired Effects<br />(conflict, market, social, other)<br />Capability Expression<br />Capability<br />Concept<br />Capability Planning<br />Capability<br />Need<br />Capability Architecting<br />Capability<br />Architecture<br />Capability Development<br />Capability<br />Capability Employment<br />Achieved Effects<br />“Strategist’s<br />View”<br />Enterprise<br />Architecting<br />“Planner’s<br />View”<br />“Architect’s<br />View”<br />“Builder’s<br />View”<br />System<br />Architecting<br />“Operator’s<br />View”<br />
  51. 51. Architecture-Driven Systems Development The Role of Architecture Throughout Systems Development<br />4/02/2009 - 25<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  52. 52. Why are Acquisition Programs Failing?<br />Many major government acquisition programs have failed to meet cost, schedule, and performance expectations because:<br />Requirements were unrealistic, too complex, too rigid, and unstable<br />Inadequate program planning and risk management<br />Insufficient effort on system architecture and systems engineering<br />Contractor lacked sufficient capability or/and domain experience<br />Insufficient commitment to ensure adequate and stable funding<br />Use of program award/incentive fee not tied to program outcomes<br />From: Huffman, Dr. S.D. Improving Acquisition Program Performance: The “Architect” Role. 23 January 2006<br />
  53. 53. Description Gap Leads to Requirements Failure<br />Desired Effects<br />(conflict, market, social, other)<br />Capability Expression<br />Capability<br />Concept<br />Capability Planning<br />Capability<br />Need<br />Capability Development<br />Capability<br />Capability Employment<br />Achieved Effects<br />“Strategist’s<br />View”<br />Doctrine,<br />CONOPS<br />“Planner’s<br />View”<br />JCIDS<br />Issue #1 – Inadequate translation of capability need into engineering requirements leads to requirements failure<br />Description<br />Gap<br />Engineerible<br />Requirements<br />“Builder’s<br />View”<br />DoD 5000*<br />* 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. <br />“Operator’s<br />View”<br />Warfighting<br />
  54. 54. … And Requirements Failure Cascades Through the Capabilities-to-Systems Value Chain<br />Desired Effects<br />(conflict, market, social, other)<br />Capability Expression<br />Capability<br />Concept<br />Capability Planning<br />Capability<br />Need<br />Capability Development<br />Capability<br />Capability Employment<br />Achieved Effects<br />“Strategist’s<br />View”<br />Doctrine,<br />CONOPS<br />Inadequate translation of capability need into engineering requirements results in …<br />“Planner’s<br />View”<br />JCIDS<br />Poor initial requirements baseline which cascades through systems development and ultimately results in …<br />Description<br />Gap<br />Engineerible<br />Requirements<br />Inadequate linkage of requirements to developed system which results in …<br />“Builder’s<br />View”<br />DoD 5000<br />Inability to validate resulting system against original need<br />“Operator’s<br />View”<br />Warfighting<br />
  55. 55. What is Architecture-Driven Systems Development?<br /><ul><li>The incremental specification and development of a successful system through iterative synthesis of architecture descriptions
  56. 56. … where those architecture descriptions serve as the “scaffolding” upon which to attach, organize and relate requirements.
  57. 57. An Architecture Specification serves as the initial well-formed architecture description from which all other descriptions are iteratively developed.</li></li></ul><li>Architecture Specification Establishesthe Engineering Requirements Baseline<br />Stakeholder developed capability descriptions<br />lack key engineering-level completeness and consistency<br />not expressed in the form of requirements traditionally expected as the input to system development, demonstration and production<br />Architecture Specification is rigorous enough to form a set of engineering requirements that can drive the Defense Acquisition System<br />Provides a black box specification of the system<br />Provides a performance specification of the system as a whole<br />Describes the external interfaces to the system<br />Architecture Specification translates vague stakeholder needs into specific engineering requirements from which a series of system development baselines can be iteratively developed.<br />
  58. 58. Functional Specification Establishesthe Functional Requirements Baseline<br />Derives a functional solution to the engineerible requirements provided by the architecture specification<br />Provides a white box specification of the system as a collection of functional elements<br />Provides a performance specification at the level of functional elements<br />Describes the functional interfaces within and to the system<br />System development process continues through successive engineering baselines<br />Solution space continues to narrow and spiral towards an optimal system design<br />Best implementation selected from the set of candidate implementations<br />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.<br />
  59. 59. Traditional Systems Architecting<br />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.<br />System<br />Requirements<br />The Role of Systems Architecting within Systems Engineering<br />Systems Engineering<br />and<br />Development Process<br />Requirements<br />Engineering<br />System Demo<br />& Validation<br />System Integ<br />& Test<br />Functional<br />Allocation<br />Component<br />Development<br />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?<br />
  60. 60. First Real “System Architecture” Emergesat the Allocated Requirements Baseline<br />Provides set of CI performance and interface specifications that satisfy the functional (and associated non-functional) requirements provided by the functional specification<br />Specific system design emerges in the form of configuration items [hardware/software configuration items (CIs) ] and their interface specifications<br />May be a many-to-many relationship from functions (and non-functional rqmnts) to CIs<br />Provides a structure for the “Configuration Item (CI) Tree”<br />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<br />Allocated Baseline translates an abstract functional design into producible physical components.<br />
  61. 61. Product Specification Provides the “Build-to”Architecture at the Product Requirements Baseline<br />Provides a mapping of COTS, GOTS or developmental item products to the hardware/software configuration items (CIs) described at the allocated baseline<br />Provides a set of product performance and interface specifications that satisfy the requirements provided at the allocated baseline<br />Follows the structure of the “Configuration Item (CI) Tree”<br />Product Baseline translates the configuration tree into COTS, GOTS or developmental item products.<br />
  62. 62. Thank you!!<br />Please contact me at:<br /> Brad Mercer<br /> Chief Architect<br /> Naval C4I Systems<br /> Maritime IT and Engineering<br /> The MITRE Corporation<br /> SPAWARSYSCEN SD<br /> 49185 Transmitter Road, Building 626<br /> San Diego, CA 92152-7335<br /> bmercer@mitre.org<br /> 619-758-7814<br />4/02/2009- 35<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  63. 63. Additional Slides<br />4/02/2009 - 36<br />Copyright ©2009The MITRE Corporation. All Rights Reserved.<br />
  64. 64. Architecting ≠ Designing<br />Many believe that architecting and designing are the same thing — not true!<br /><ul><li>Designing is the process of resolving conflicting constraints
  65. 65. Architecting is the process of synthesizing form</li></ul>Architects and Engineers both apply the process of design and both produce “designs” — but through the application of very different paradigms …<br />Architects design through Synthesis<br />Engineers design through Analysis<br />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.<br />Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.<br />
  66. 66. Sciencenoun<br />The observation, identification, description, experimental investigation, and theoretical explanation of natural phenomena or object of study or inquiry. <br />Methodological activity, discipline, or study: I&apos;ve got packing a suitcase down to a science.<br />An activity that appears to require study and method: the science of purchasing.<br />Knowledge, especially that gained through experience. <br />Art or Science?<br />From:  “science” The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004.<br />Artnoun<br />A system of principles and methods employed in the performance of a set of activities: the art of building.<br />A trade or craft that applies such a system of principles and methods: the art of the lexicographer.<br />Skill that is attained by study, practice, or observation: the art of the baker; the blacksmith&apos;s art.<br />Skill arising from the exercise of intuitive faculties: &quot;Self-criticism is an art not many are qualified to practice&quot;(Joyce Carol Oates).<br />From:  “art” The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004.<br />
  67. 67. A Proliferation of “architects”<br />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!<br />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.)<br />Serious implications! These new “architects” are now “architecting designs” (i.e. creating implementations) without a specification (i.e. architecture description) to guide them<br />OK, so … technicians are now “engineers”, and engineering-focused designers are now “architects”? What happened to realengineers and architects?<br />
  68. 68. Architectures within Architectures within …<br />Architecturen. (another definition) the highest level conceptual-ization of a system.<br />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.<br />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!<br />Serious implications! Lots of debate about what really constitutes THE architecture!<br />
  69. 69. DODAF and DoD ArchitectingA Case Study in “Reality”<br />The misapplication of DODAF may be the worst thing that has ever happened to the practice of architecting within the DoD.<br />“Yeah, but it’s better than nothing!” No its not! “Nothing” costs less, happens faster, and has more positive impact!<br />“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.”<br />“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.”<br />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.”<br />
  70. 70. The Architect’s View<br />Conceptual Model<br />Conceptual Data Model<br />Logical Data Model<br />Physical Data Model<br />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.”<br />Architect’s View<br />“Architect’s View” – View taken by the architect in formalizing and expressing the client’s needs as an architecture description<br />Contains only elements needed by the architect to describe an architecture and nothing more<br />Logical data models do not represent the architect’s view – they include too many non-architecture artifacts<br />The “Architect’s View” is expressed using a formal conceptual model that provides a common set of semantics for expressing that view<br />Implemented Database<br />The Model Stack<br />
  71. 71. Architecture Semantics<br />Event<br />When?<br />generates<br />selects<br />Where?<br />How?<br />Function<br />Location<br />Rule<br />groups<br />controls<br />Why?<br />consumes<br />groups<br />produces<br />accomplishes<br />Resource<br />Product<br />What?<br />Who?<br />
  72. 72. What is the structure or form of a system?<br />FUNCTION<br />BEHAVIOR<br />Architecture<br />INFORMATION<br />Functional “Structure”<br />Described using Functional Models (e.g. flow diagrams, function hierarchies, interface diagrams)<br />Behavioral “Structure”<br />Described using Behavioral Models (e.g. rule sets, state diagrams, event traces)<br />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.<br />Information “Structure”<br />Described using Information Models (e.g. data models, ontologies)<br />Architecture Descriptionn. a representation of an architecture; a conceptualization of the form of a system.<br />

×