The architect's job: 1996 version


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The architect's job: 1996 version

  1. 1. 1DII-AF Chief Architects’ OfficeThe Architect’s Job 6 June 1997 Rich Hilliard (v 2.0) current email:
  2. 2. 2Acknowledgements DII-AF Chief Architects’ Office • This briefing has been evolving since 1995. The original version was called “Dick & Jane” and was created by Jeff Hustad, David Emery for Army SBIS. Tim Rice and Kevin Heideman contributed to “DISA Dick & Jane” in 1996 which added the results on the SBIS Architecture. Subsequent versions added details on MITRE’s work on Architecture Quality Assessment, and the Architecture Description Framework. • The latest versions start to define the major activities that the Architect engages in and the activities needed to support that. • Jim Moore, Eric Skoog, Jerry Friedman, David Emery all offered comments on this version.
  3. 3. 3Outline DII-AF Chief Architects’ Office • What is architecture? • Why have architects? • What does the architect do? • What does the architect need to do his job? • MITRE’s work in architecture
  4. 4. 4Why Architecture? DII-AF Chief Architects’ Office • Explicitly “architected” systems seem to turn out faster, better and cheaper • Separation of concerns: - Essential system characteristics - Multiple system stakeholders - Separate long-term goals, and evolution from immediate construction concerns - Current systems are “contractor-architected” ! Not incentivized for the long-term ! Limited client (buyer) flexibility ! Narrows marketplace for mission functionality • “Architecture” as response to failure of the waterfall to address non-user, non-functional requirements of other stakeholders
  5. 5. 5What is “Architecture”? DII-AF Chief Architects’ Office • An architecture is the highest-level concept of a system in its environment - IEEE Architecture Working Group • An architectural description is a model of the structure and behavior of the whole system - It shows how the system fulfills the needs in the context of its environment - It identifies major system components, their interconnections and dependencies, and the limits within which they must operate
  6. 6. 6The Architect’s Domain (I): Roles DII-AF Chief Architects’ Office Users Testers Client Program Architect Manager Maintainers Chief Developers Operators Engineer Installers reporting-to and influences relations
  7. 7. 7The Architect’s Domain (II): Products DII-AF Chief Architects’ Office Policies Available Vision Funding Technology Trends Architecture ...n Goals Design 3 Legacy Design 2 Systems Design1 Needs Design Emerging Detailed Open Stds System Requirements Requirements Operational Requirements Life cycle Phases Requirements & Concepts Architecture Design & Implementation • • •
  8. 8. 8Characteristics of Architect’s Job DII-AF Chief Architects’ Office The ideal architect should be a man of letters, a skillful draftsman, a mathematician, familiar with historical studies, a diligent student of philosophy, aquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. — Vitruvius, De Architectura (25 BC) • Client-centered - Architect works for the client • Systems orientation: bridging problem definition and solution conceptualization - Architect’s job is to understand client’s needs to produce one or more models (potential solutions)
  9. 9. 9Characteristics of Architect’s Job (continued) DII-AF Chief Architects’ Office • Model-based - Architect then works with engineer - Engineer’s job is to design and implement architect’s model • Certification of construction - Architect oversees construction, ensuring actual implementation meets design • Determines acceptance of built system
  10. 10. 10Characteristics of Architect’s Job (concluded) DII-AF Chief Architects’ Office • Multidisciplinary Synthesis: technical, programmatic, managerial - Artistic, Heuristic No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder. — John Ruskin, Lectures on Architecture and Painting (1853)
  11. 11. 11Activities and Definitions:Architect a System (context) DII-AF Chief Architects’ Office client and other system stakeholder priorities architectural standards known requirements Architect architectural specifications a System* building permits and certificates A0 * Where “system” ranges over: individual applications, usual programs, product families, product lines, systems of systems or the whole enterprise.
  12. 12. 12Activities and Definitions:Architect a System DII-AF Chief Architects’ Office I1 C1 formal client and stakeholder priorities reqts Understand needs, goals community standards: Needs and and vision JTA, DII COE, etc. Environment A1 architectural Devise rules O1 Architectural Concepts A2 appropriate Produce architectural specifications technologies O2 Engineering Views A3 Oversee Construction O3 design artifacts A4 approvals and built system to proceed, system acceptance
  13. 13. 13Architectural Description DII-AF Chief Architects’ Office • An architecture is documented as a model • A model is comprised of one or more views - A view represents the whole system to focus on one or more critical concerns - Support multiple audiences each with their own concerns - Reduce perceived complexity through separation of concerns
  14. 14. 14Activities and Definitions:Produce Engineering Views DII-AF Chief Architects’ Office C1 C2 critical stakeholder architectural architectural concerns, programmatic standards and rules and technical issues constraints predefined views Define Views 1 Analyze architectural concepts documented engineering views Each I1 View O1 2 inconsistencies Check View inter-view links Consistency 3 open issues Verify Satisfaction of Needs & Constraints needs, goals 4 vision traceability matrix
  15. 15. 15Some Typical Views DII-AF Chief Architects’ Office • functional, activity views [ICAM, Sowa] • data, data flow, information views [Druffel94, Gacek95] • static views [Kruchten95, Gacek95] • logical views [Kruchten95, Moriconi] • behavioral, dynamic, “operational” views [Luckham95a, Kruchten95, TAFIM] • development, maintenance views [Boehm, MITRE96] • distributed, network views [Sowa, MITRE95] • physical views [Kruchten95, TAFIM]
  16. 16. 16Principles of Views DII-AF Chief Architects’ Office • Each view presents the whole system from a chosen viewpoint - Complete relative to that viewpoint - Consistent with respect to other views • Each view is modeled in terms of components, connections and constraints (governed by a “meta model”) • Views are linked to increase understanding, consistency and completeness
  17. 17. 17Example: Application View DII-AF Chief Architects’ Office Presentation Presents Information Motif or MS Windows XVT User Interface Prepares Information API, Style Guide Ada Application Transforms Information API, Logical Data Model Ada, XDR, IDL Data Access Stores/Retrieves Information SQL, Physical Data Model, RDA RDBMS, File System, OLTP Data Storage Maintains Information legend Connection Component Connection Component Function Technology
  18. 18. 18Example: Data View DII-AF Chief Architects’ Office DOD Data IRDS DOD Enterprise Dictionary Unified Repository Data Model Data Model ERA Diagrams (IDEF1X format) <- ERA Diagrams (IDEF1X format) -> Logical Legacy Common Application COTS/GOTS Data Models Data Reference Data Models Data Models Models Data Model SQL ICD Interface Data Stores Integrated Database Legacy
  19. 19. 19Example: Distribution View DII-AF Chief Architects’ Office Force XXI In Garrison Server Database ... ... Intelligent PCs • Application distribution via Remote Remote Procedure Call •Data distribution via OLTP accessing split data Database Server ... Deployed Split Base
  20. 20. 20Example: Security View DII-AF Chief Architects’ Office Operational Security Security Procedures Network Security I&A Encryption Fortezza Least Switch Routers Privilege LAN Apps Hubs Secure RPC Data Stores
  21. 21. 21Example: Developer-Maintainer View (partial) DII-AF Chief Architects’ Office from system requirements Distributed source View documents system requirements legacy system capture and edit considerations system system requirements threads legacy systems from traces to Data system component View requirements ID and allocation software HW, SW threads legacy software software and DBMS components threads components components behaviors system software requirements considerations system performance requirements definition software legacy S/W modeling software threads SW requirements components software top-level software performance threads design modeling behaviors to Detailed Design to Testing
  22. 22. 22Supporting Activities (Mechanisms) DII-AF Chief Architects’ Office • Operational modeling • Doctrine and strategic studies • Financial planning and analysis, ROI • Requirements analysis • Simulation • Ergonomics, time-motion studies • Prototyping • Enabling technology studies: e.g., messaging, image processing, information retrieval, multimedia • Formal Specification • Design and implementation techniques and methods
  23. 23. 23Supporting Activities (Mechanisms) DII-AF Chief Architects’ Office • Collaboration • Self-criticism and architectural assessment • Project development and management • Planning and scheduling • “Process” • Contracting • Design reviews, inspections and audits • Compliance, conformance testing and analysis • Quality assurance
  24. 24. 24Organizing Architects DII-AF Chief Architects’ Office Where do architects and designers get their ideas? The answer, of course, is mainly from other architects and designers, so is it mere casuistry to distinguish between tradition and plagiarism? — Stephen Bayley, Commerce and Culture (1989) • Participative/collaborative: the critique is an essential ingredient in “real” firms • The architecture firm • Methods: heuristic, patterns, reuse of solutions, experience base • Tools: Creating, Assessment, Delivery, Certification • Not a consulting firm
  25. 25. 25Community Support DII-AF Chief Architects’ Office • What help can we get from outside organizations? - DII-AF - DII COE - Product Lines • Architectural Standards - DISA, CISA, JTA, ISO, IEEE - Standards are a support and also a constraint
  26. 26. 26If Architecture were Software ...Architectural Maturity Model DII-AF Chief Architects’ Office • Level 0: Briefware (Total Chaos) - “adjective architecture” - cartoons and clip art • Level 1: Developer-centric (Initial) - Yesterday’s CASE techniques (IDEF, RDD-100, Teamwork) now with “architecture”in the model names - Ad hoc coordination between programs - Overemphasis on structural aspects: ! CSCIs, modules, classes, ... ! e.g., Garlan and Shaw on software architecture
  27. 27. 27If Architecture were Software ...Architectural Maturity Model DII-AF Chief Architects’ Office • Level 2: Master Builder (Repeatable) - Distinct Architect / Developer roles - Recognition of multiple stakeholders of a system ! and techniques for addressing their diverse needs • Level 3: Self-Awareness (Defined) - Recognition of architectural discipline ! Distinct from systems and software engineering ! Means to create and contract for architectural specifications - e.g., Rechtin and Maier
  28. 28. 28If Architecture were Software ...Architectural Maturity Model DII-AF Chief Architects’ Office • Level 4: Architect Firms (Managed) - Architects organized to support their discipline - Tools to support that discipline - Independent analysis of delivered architectural specifications • Level 5: “Pre-fab” construction (Optimizing) - Architectures as real engineering objects - True separation of architectural specification from system implementation - Architectural evolution to support technology insertion
  29. 29. 29The Architectural Metaphor:Implications for Systems Engineering DII-AF Chief Architects’ Office • Systems are situated in their environments • Inherently “multi-viewpointed” - no essential or ‘correct’ single view • The architect is one actor mediating among - client, users and other stakeholders - developers, vendors, maintainers • What’s important are the descriptions • Descriptions can be unified with appropriate meta model - One set of “rendering primitives” with open semantics dependent on the view
  30. 30. 30Our Work DII-AF Chief Architects’ Office • Technical foundations of software systems architecture - DARPA Domain-Specific Software Architecture C2 Reference Model (1990) • Practical Architecture Method - WCCS Force-level study (1992) - Sustaining Base Information Services (1994) - Army Reserve Component Automation System (1995) - Missile Warning Laptop (1996) - Theater Battle Management Core Systems (ongoing) • Architecture Quality Assessment (AQA) (1996 - ) • Architecture Description Framework (1997- ) • Standardization: IEEE Architecture Working Group (1995 - )
  31. 31. 31Architecture Quality Assessment:Goals DII-AF Chief Architects’ Office • Repeatable method yielding objective results - Evaluation based on documentation, not “hearsay” • Based on “open sources” - Architects will know the criteria on which architectures will be judged - Availability of the criteria may improve overall quality • Independent from life cycle, documentation, methodology - Cannot assume traditional deliverables and milestones - No widely accepted architectural methods - Don’t assume a Contractor is the Architect
  32. 32. 32Architecture Quality Assessment:Uses of an AQA DII-AF Chief Architects’ Office • Evaluate a candidate (proposed) architecture • Review technical progress during ongoing architecture development • Assess a complete, delivered architecture prior to acceptance/implementation • Compare two or more architectures in a consistent fashion
  33. 33. 33Status: Architecture Quality Assessment (AQA) DII-AF Chief Architects’ Office • Several “partial” uses - FAA STARS acquisition - National Missile Defense - C2IPS • Transition to TBMCS • Identified by C2 Chief Architects Council for use in Architect’s Toolkit • Paper in MITRE’s Software Engineering & Economics Conference (April 1997)
  34. 34. 34Architecture Description Framework (ADF) DII-AF Chief Architects’ Office • Premise: To move “architecture” from buzzword to engineering practice, we need techniques for architectural description • Develop automation base for representing, manipulating, and analyzing architectural models - Allow information sharing between tools - Provide a semantically rich delivery format (e.g., between Contractors and Government) • Demonstrate industrial-strength basis for architectural description • Status: Phase 1 (6 months) funded as MSR
  35. 35. 35The Challenge DII-AF Chief Architects’ Office • Despite current interest in “architecture” - No solid foundations for architectural description and specification • Our Contractors use off-the-shelf tools to produce “architectural” deliverables - IDEF, RDD-100, UML, OMT, ... • Meanwhile, research community is developing next-generation “architecture description languages” - Rapide, Wright, Dicam, UniCon, ArTek, ACME, FR, MetaH, Gestalt, Resolve, ...
  36. 36. 36ADF Concept of Operations DII-AF Chief Architects’ Office ADF Services • Core Semantics • Working Info • Traceability • Analysis • Presentation/Layout • Import/Export Adapters Rapide Excel Browser ManSART AQAtool IMPS RDD-100 Doors Architecture Description Framework HTML, IDEF0,1 VRML Catalyst Object Request Broker
  37. 37. 37ADF Schedule DII-AF Chief Architects’ Office Phase 1: Phase 2: Phase 3: • Design ADF • TBMCS trial use • Integrate with • Small Experiments • IDL Implementation Architecture • Host to Catalyst Quality Assessment • Provide to IEEE 6 (months) 12 18
  38. 38. 38“Community Outreach” DII-AF Chief Architects’ Office • IEEE Architecture Working Group - “Design phase” leading to ! Recommended Practice for Architectural Description • - Internet discussion list for architecture issues
  39. 39. 39References DII-AF Chief Architects’ Office • R. Hilliard, Representing Software Systems Architectures or, Components, Connections, and (why not?), first-class Constraints and Views. Proceedings of the SIGSOFT’96 2nd International Workshop on the Architecture of Software Systems, October 15-16, 1996, San Francisco. • D. Emery, R. Hilliard, T. Rice, Experiences Applying a Practical Architectural Method. In Reliable Software Technologies - Ada Europe ’96, Alfred Strohmeier (editor), Springer-Verlag, Lecture Notes in Computer Science, volume 1088. • R. Hilliard, Architectural View Selection, ESC Second Architecture Technical Interchange Meeting, Gunter AFB, 5 December 1995. • S. Schwarm, T. Rice, R. Hilliard, The Architectural Metaphor as a Foundation for Systems Engineering. Proceedings INCOSE ’96 Symposium. • D. Emery and R. Hilliard, “Architecture,” methods and open issues. Proceedings First International Workshop on Software Architectures, Seattle, WA, April 24-25 1995.
  40. 40. 40References (Concluded) DII-AF Chief Architects’ Office • R. Hilliard, On The Notion of ‘Architecture’ in Model-Based Software Engineering. Proceedings DARPA Workshop on Domain-Specific Software Architectures, Hidden Valley, PA, 1990. • W. Ellis, R. Hilliard, P. Poon, D. Rayford, T. Saunders, B. Sherlund and R. Wade, Toward a Recommended Practice for Architectural Description. Proceedings of 2nd IEEE International Conference on Engineering of Complex Computer Systems, Montreal, 1996.