|
SOFTWARE ACQUISITION GOLD PRACTICE ARCHITECTURE-FIRST APPROACH FOCUS AREA: PROCESSES – Systems Engineering Definition and Summary: The achievement of a demonstrable balance among driving requirements, architecturally significant design decisions, and the life-cycle plans before resources are committed for full-scale development
Every software system has an architecture because every system has one or more components that are interrelated in various ways. The architecture is an outcome of “architecting”, or some process by which decisions are made about the structure of the system. The architecture itself is intangible; architecture documentation (description) is the tangible asset created to capture and preserve the understanding of the architecture. “Architecting” is the process of creating or establishing the architecture for a system. This practice is concerned with how the architecting is accomplished and when it occurs in relation to other activities of the software product life cycle.
Successful implementation of the Architecture-First Approach can result in:
· Reduced Cycle Time to Deliver a Product · Reduced System and Product Costs · Reduced Risk
SUMMARY DESCRIPTION The figure below is an embellishment of a diagram presented in “Architecture-Based Development”, [CMU/SEI-99-TR-007], April 1999], which depicts (at a very high level) the activities that are embodied in the Architecture-First Approach.
The key elements of the Architecture-First Approach are:
· Maintain the Architecture “The software architecture of a program (or system) is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them [Bass, 1998]”.
Every software system has an architecture because every system has one or more components that are interrelated in various ways. The architecture is an outcome of “architecting”, or some process by which decisions are made about the structure of the system. The architecture itself is intangible; architecture documentation (description) is the tangible asset created to capture and preserve the understanding of the architecture. “Architecting” is the process of creating or establishing the architecture for a system. This practice is concerned with how the architecting is accomplished and when it occurs in relation to other activities of the software product life cycle. Further discussion about software architecture itself is beyond the scope of this document. However, it is important for the reader to be comfortable with the subject of software architecture in order to fully understand this practice. This section addresses the activities inherent in architecting that make it a Gold Practice, and perhaps distinguish it from processes that result in an architecture, but do not necessarily have the same impact on the software life cycle.
Royce’s definition of the Architecture-First Approach practice is repeated here for context, with emphasis on the key words that distinguish the practice from the outcome, the architecture itself, and provide the key characteristics of the practice.
“Achieving a demonstrable balance among driving requirements, architecturally significant design decisions, and the life-cycle plans BEFORE resources are committed for full-scale development.”
Figure 1 is an embellishment of a diagram presented in “Architecture-Based Development”, [CMU/SEI-99-TR-007], April 1999], which depicts (at a very high level) the activities that are embodied in the Architecture-First Approach.
Figure 1: Activities of the "Architecture-First Approach " Gold Practice
Elicit Architectural Requirements: Key elements of this activity are: · Architect and stakeholders work together to evolve architectural requirements (in contrast to a traditional approach where the acquiring organization would develop a specification without interaction with an architect).
Design the Architecture: Technical expertise is a critical success factor for designing the architecture. The architect must be: · Familiar with existing architecture styles · Knowledgeable about emerging technologies to consider as alternative design strategies · Competent in mapping decisions about technology to the requirements The architect must communicate with domain experts or subject matter experts in order to ensure that the business, quality, and functional requirements are being addressed by the candidate technologies.
This activity is the first step of an iterative process and is followed by documenting and analyzing the architecture as part of each iteration. Architecture design may encompass combinations of other practices, such as those listed below, depending on the domain, scope, desired functionality, and complexity of the solution.
· Agreement on Interfaces · Ensure Interoperability · Leverage COTS/NDI · Plan for Technology Insertion · Formal Risk Management · Assess Reuse Risks and Costs
Document the Architecture: This is the second step in the iterative process that is part of the Architecture-First Approach. The architecture itself is intangible; it is a concept, or collection of concepts, in the mind of the architect. The concept must be documented (or demonstrated through prototyping) in order to communicate the concept to all the stakeholders to ensure a common understanding of the system structure and behavior.
Documenting the architecture raises questions and forces clarification of issues not yet addressed.
Present multiple views. Each description (view) should allow a stakeholder to easily distinguish among the various design considerations presented. For a small standalone application, an architecture description can be as simple as a one-page drawing that illustrates the software components by name, and their connectors (how they relate to each other). Typically, architecture descriptions are collections of views of a system from several different perspectives (e.g. logical or functional, hardware, software, behavioral views, etc.). There should be a view to accommodate each type of stakeholder.
The larger the system the greater the need for focusing on architecture.
Use tools and “Architecture Description Languages (ADL)” when appropriate to facilitate and support use of the architecture for decision making. A new technology, ADL, is emerging that addresses languages for representing and analyzing architectures. ADLs can be used to document architectures in a way that allows analysis and exchange through other software tools.
Document each iteration of the architecture. There are no strict rules or sequence that must be followed with successive iterations. Some architects may choose to address the several architectural views concurrently but at a very high view. Then, with each successive iteration, the views would be refined. Others may elect to focus on a particular view until it is deemed sufficient and then, in successive iterations, focus on other views.
The most important aspect of this activity is that the architecture description is the basis for evaluating the architecture – and therefore, comes first and is refined with each iteration. Documenting the architecture AFTER assessing it through verbal discussion is not acceptable in the Architecture-First Approach. The description drives the analysis activity and therefore must precede it. Documenting an architecture to sit on a shelf as part of a project history is not the purpose of this activity.
Analyze the Architecture: Step 3, analyzing the architecture, encompasses the following areas: · Ensure that stakeholders participate in the analysis: For each architectural view presented, the appropriate stakeholders need to be involved. The architect bears the burden of presenting the candidate architectures in a way that is meaningful to the “non-technical” stakeholder, as well as the “teckies”. The domain expert (or user representative) may address usage scenarios and issues that were not previously considered during requirements elicitation. Substantial savings in time and costs are realized when problems are discovered and resolved during this “elaboration” phase, rather than waiting to be discovered during testing.
· Assess the architecture with respect to functional goals, business goals, and quality goals: Does the proposed architecture address the goals that were originally identified as architectural drivers? Typically the act of asking the question reveals gaps, or identifies areas of conflict between the proposed architecture and business or quality goals. This provides the thrust for the next iteration. Eventually the architecture will be deemed to be responsive to all the goals, or the stakeholders will have negotiated trade-offs during the process. The architecture documentation includes capturing the rationale for choosing a particular architecture collection.
· Identify decisions/action items that will drive the next iteration: Analysis and evaluation typically result in some discoveries that become the focus for refinement during the next iteration.
· Conduct independent expert reviews by technically competent people: On large projects independent expertise is brought in to verify that the proposed architecture does, in fact, address the stated requirements and quality goals. Under a traditional development scenario, the architecture would not be scrutinized to this extent prior to approval.
· Prove, through demonstration, that the proposed architecture will meet the stated requirements: This often involves creating prototypes for the proposed architecture in order to demonstrate that quality and performance goals can be met. Using independent technical experts helps to ensure the validity of the architecture prior to moving on to full-scale development.
Realize the Architecture: This activity is about getting the most value from the time and effort expended on the architecture.
Use the architecture to drive decision-making and acquisition strategy for committing resources and structure for full-scale development. Decisions about software, operating systems, development languages, and tools, are made during architecting. Structuring and tasking development teams before the architecture is stabilized can adversely impact project schedule and cost. The teams may not be working on the right components. Team members may not have the expertise to implement the architecture that is ultimately selected. The team structure (from an organizational perspective) may not be well aligned for developing the components identified by the architecture.
The organizational structure of the development team must be easily mapped onto the software architecture and vice versa. Once the architecture has been agreed upon teams are allocated to work on the major components and the work breakdown structures that are created reflect those teams. For large systems, teams may belong to different subcontractors. Each group will need to establish liaisons and coordinate with the other groups. Team structure and controlling team interaction often turns out to be the largest single factor affecting a large project’s success. [CMU/SEI-99-TR-007]
Maintain the Architecture: “Architecture-First” carries two meanings: · Develop the architecture before committing resources for full scale development, and · Focus on the architecture when making changes to a system in a maintenance environment.
There is a risk that the architecture may drift from its original precepts if a maintenance process is not addressed. If this happens, the original system (that was so carefully designed and analyzed) will be compromised and much of the value derived from the original “architecting” will be lost. Drifting may occur when changes are made by multiple developers that are not mutually consistent, or do not follow the original rationale for design decisions. The challenge is to ensure that the architecture of the “as-designed” and “as-built” systems remain congruent with the “as-maintained” system over time.
The architecture documentation should capture that rationale for the architecture. Both the acquiring organization and the developing organization(s) need to ensure that the architecture description is well disseminated for use as a development reference, and both need to ensure that proposed changes to the system are reviewed for conformance to the architecture prior to implementation.
If architectural changes are necessary, then both organizations, (acquirer and developer), need to ensure that the architecture description is modified to reflect the new rationale. Many architectural constructs have no realization in the development artifacts that programmers actually create and maintain. Without an architecture description, the maintainer (who may be a different organization from the developer) tries to “interpret” from the existing code what the architecture may have been, influenced by their own individual development experiences, which may be significantly different from what was in the mind of the architect. This is how the inconsistencies surface.
This sounds like a “simple” obvious thing to do – but very few organizations have actually done it. Consequently, over time, system designs are compromised because developers lose sight of the design rationale. Maintaining the architecture is really about maintaining a focus on “architecting” through the evolution of the system life cycle. It depends upon having a well-documented, well-disseminated architecture to start with, and having management support to maintain the architecture over the life of the system.
Many organizations may be maintaining systems that have no architecture descriptions. It is possible to initiate “architectural reconstruction” where an architect examines the code and associates naming conventions, file structures, and functions with architectural constructs, deriving useful abstractions that are relevant to the continued life cycle of the system. Architectural reconstruction may be useful to organizations wanting to reengineer an existing system, or mine its existing software assets for reuse and product line development. Some tools are now being developed to aid analysts in extracting information from systems in order to analyze and define patterns that ultimately define the architecture. See [Kasman, 1999] for further details on architectural reverse engineering and conformance testing.
CHARACTERISTICS OF IMPLEMENTATION:
ANTICIPATED BENEFITS OF IMPLEMENTATION:
Successful implementation of the Architecture-First Approach can result in:
What were formerly sequential decisions can now be made concurrently from an integrated perspective, with all stakeholders accounted for. All decisions should be based on a system software life cycle perspective that minimizes the number and magnitude of changes during development and deployment of the software. A subsequent reduction in extended and expensive rework cycles has a positive impact on schedules and overall software life cycle costs.
Proper emphasis on “architecting” at the beginning of the software development process helps to optimize the product and process funding profile. Funding profiles based on historical data (prior to the use of modern software development practices) may no longer be relevant. Early software project phases may require additional investment, but unit costs, and overall life cycle costs, may be reduced due to fewer design or engineering changes, better capability to meet schedule objectives, and extensive use of trade-off analyses to reach cost-effective solutions.
Planning at the earliest stages of software development promotes better understanding of available technologies and processes. This, in turn, yields a better understanding of risk and its impacts on cost, schedule and performance. Effective risk assessment early in the life cycle (before commitments to full scale development) can result in architecture decisions that mitigate potential risks and establish more realistic cost, performance and schedule objectives.
Key Characteristics of the Architecture-First Approach Gold Practice
RELATIONSHIPS TO OTHER PRACTICES: The Figure below represents a high-level process architecture for the subject practice, depicting relationships among this practice and the nature of the influences on the practice (describing how other practices might relate to this practice). These relationship statements are based on definitions of specific “best practices” found in the literature and the notion that the successful implementation of practices may “influence” (or are influenced by) the ability to successfully implement other practices. A brief description of these influences is included in the table below.
Process Architecture for the “Architecture-First Approach" Gold Practice
Summary of Relationship Factors for the Architecture-First Approach Gold Practice
RESOURCES:
· Software Program Managers Network web site for 16 Critical Software Practices for Performance-based Management. This link refers specifically to the practice of using system-based software design. http://www.spmn.com/16CSP.html#system · Worldwide Institute of Software Architects – a site that provides a provocative and refreshing perspective on the philosophy of architecting, http://www.wwisa.org/wwisamain/phil.htm and the role of the software architect. http://www.wwisa.org/wwisamain/role.htm State-of-the-art methods and tools that may be useful in implementing and improving the effectiveness of an Architecture-First Approach to development include:
Quality Function Deployment (QFD) is one technique for evaluating trade-off scenarios. It is predicated on gaining an understanding of what the end user really needs and expects. The QFD methodology allows for tracking/tracing trade-offs through various levels of the project hierarchy, from requirements analysis, through the software development process, to operational and maintenance support.
The goal of the ATAM is to understand the consequences of architectural decisions with respect to the quality attribute requirements of the system. The ATAM is a means of determining whether the quality goals of a system are achievable by the architecture as it has been conceived, before enormous organizational resources have been committed to it. It is a structured method that makes analysis repeatable and helps ensure that the right questions regarding an architecture will be asked early, during the requirements and design stages when discovered problems can be solved relatively cheaply. It guides users of the method—the stakeholders—to look for conflicts and for resolutions to these conflicts in the software architecture. The ATAM is meant to be a risk identification method, a means of detecting areas of potential risk within the architecture of a complex software-intensive system.
CBAM is a method for performing economic modeling of software systems, centered on an analysis of their architecture, to address the need for better decision-making with a process that helps the designer (architect) choose among architectural options during both initial design and subsequent periods of upgrades, while being constrained to finite resources. The CBAM provides a structured integrated assessment of the technical and economic issues and architectural decisions. It utilizes techniques in decision analysis, optimization and statistics to help software architects characterize their uncertainty and choose a subset of changes that should be implemented from a larger set of alternatives. There is a presumption that this method would follow the ATAM method and, therefore, that stakeholders and experts already have a common level of understanding about the system goals and the attributes of importance.
Prototypes provide a representation of a product/system under development. They facilitate communications between software designers and product/system users by allowing users to better describe or gauge actual needs. Prototypes are used to demonstrate that the subject architecture is sound – that it can in fact work in a real scenario. Customer manipulation helps clarify requirements and correct misconceptions about what the product should or should not do, thereby reducing the time to complete a fully functional design, and reducing the risk of delivering an unacceptable product. In the context of Architecture-First Approach, a prototype could be the tool for verifying an “executable” architecture.
Software prototyping must be controlled to eliminate unnecessary prototyping cycles that cause cost and schedule overruns. It is also necessary to guard against scope creep, in that users may want to add features/enhancements that go beyond the scope of contracted requirements.
Modeling and simulation (M&S) techniques are a cost-effective approach to reduce the time, resources and risks, and to improve the quality, of acquired systems. Validated M&S should be appropriately applied throughout the software life cycle for requirements definition; program management; design and engineering; test and evaluation; and field operation and maintenance.
Establishing requirements and negotiating trade-offs is a part of “architecting”. “Formal Methods” is a mathematics-based technique that is used to ensure a complete specification of the requirements. This technique is especially valuable in developing “safety-critical” systems. Since Architecture-First Approach encompasses the refinement of requirements, the architect may determine the necessity to employ this technique prior to baselining the architecture.
Rational provides a suite of tools that can be used for many of the activities that comprise “architecting” including tools for requirements development and management, and visual modeling tools that can be used to represent an architecture. See the Rational web site: http://rational.com/
[Note: There are a multitude of experts on “architecture”, but few experts on the Architecture-First Approach practice.] Walker Royce, Vice President and General Manager at Rational Software Corporation See http://rational.com/
· Courses related to “architecting”. http://www.rational.com/university/paths/arch.jsp?SMSESSION=NO · Software Productivity Consortium, “Introduction to Architectural Frameworks” Note: you need to register as a member or guest of the Software Productivity Consortium in order to access the following page. https://www.software.org/catalog/products/product.asp?pfid=45 · Enterprise Architecture Seminar
APPENDICES
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A group of experts convened by the Navy’s Software Program Manager’s Network (SPMN) in 1995 that established/identified nine best practices. These practices have been augmented with other practices since 1995, and in current literature are referenced as the original Airlie best practices. |
|
Architecture |
The configuration of components that make up a system The structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. [There is no universally accepted definition for this term in the Information Technology community. It seems to take on different meanings, depending on the perspective and experience of the author/presenter. What is important is that the author/presenter always provide his/her definition in the context of its use.] |
Architecture-Based Design (ABD) |
A method which identifies a series of steps for designing the conceptual software architecture. This method is the basis of the AFA practice. Refer to CMU/SEI-2000-TR-001 titled “The Architecture-Based Design Method “ for a detailed description of this method. |
Architecture Style |
A collection of significant architecture pieces representing a coherent package of design decisions found repeatedly in practice, and having known properties that permit reuse.
A collection of component types together with a description of the pattern of interaction among them. (e.g., client-server: Client and server are two component types and their coordination is described in terms of the protocol that the server uses to communicate with the clients) - |
Architectural Drivers |
The combination of business, quality and functional requirements that “shape” the architecture.
|
Best Practice |
A documented practice aimed at lowering an identified risk in a system acquisition and is required or recommended by a bona fide DoD, industry, or academic source.
Methodologies and tools that consistently yield productivity and quality results when implemented in a minimum of 10 organizations and 50 software projects, and is asserted by those who use it to have been beneficial in all or most of the projects.
|
Conceptual Architecture |
“identified by Hofmeister, Nord, and Soni [Hofmeister 00]. It describes the system(s) being designed in terms of the major design elements and the relationships among them. The conceptual architecture represents the first design choices made during a development process. Consequently, it is pivotal to achieving the quality and business goals for the system(s) and in providing a basis for the achievement of the desired functionality.”
|
Concurrency View |
Viewing a design element (system, subsystem, or component) from a perspective that addresses concurrent events (concurrency requirements and/or constraints) such as multiple users, resource contention, start up, and other parallel activities. A concurrency view will evolve into a process view once commitments have been made. |
Deployment View |
Viewing the physical structure of a system; displaying processors and the networks used to communicate among them |
Model |
A simplification of reality that provides a complete description of a system. |
Responsibilities |
This term describes the role(s) of a design element within the system. It includes functional and quality-oriented items. |
Quality Scenarios |
Quality scenarios are descriptions that embody quality requirements and make them concrete. (e.g., ”Estimate the impact of a 10% increase in users per year” is a performance scenario) |
Software Template |
In the context of design, a software template defines what it means to be a software element of a particular type. This includes patterns that describe how all elements of this type must interact with shared services and the infrastructure. It also includes “citizenship” responsibilities that pertain to all elements of that type.
|
SPMN |
Software Program Managers Network |
Use Case |
A piece of functionality in the system that gives a user a result of value.
A technique for reasoning about/describing the behavior of a system in a concrete setting - a technique for capturing functional requirements and making them concrete instead of conceptual. |
CASE STUDIES FROM THE LITERATURE:
CCPDS-R Case Study
This is the study of a successful (on budget, on schedule, and satisfactory to the customer) project, performed for the U.S. Air Force by TRW Space and Defense in California in the time frame from 1987-1994. The project was a large effort that included developing three distinct software systems totaling more than one million source lines of code. The study focuses on the initial development. The study does not coincide exactly with Royce’s ten principles of modern software development, but it used most of the techniques (including a dedication to the Architecture-First Approach) and was managed to the same spirit. Since Royce worked full time on the project for 6 years the study represents first-hand experience. The project achieved twofold increases in productivity and quality due, in large part, to the balanced use of modern technologies, modern tools, and an iterative development process. The efficiencies were largely due attributable to a major reduction in the software scrap and rework enabled by an architecture-first focus. Another notable improvement was the teamwork between the customer, user, and contractor.
Applying the CBAM to the ECS (a large-scale project)
ECS is the abbreviated name for the Earth Observing System Data Information System (EOSDIS) Core System, which collects data from various NASA satellite downlink stations, processes it into higher-form information, and makes it available in searchable form to scientist around the world. The system processes hundreds of gigabytes of raw data daily and archives hundreds of gigabytes of information at 8 data centers around the U.S. The CBAM followed an ATAM exercise that identified 72 architectural strategies (ASs) for system improvement. The quantification assisted them in objectively assessing the various ASs and implementing those that would give them the greatest return. The method aided the stakeholders in determining how to allocate limited resources to their software evolution effort and they participated enthusiastically.
- [CMU/SEI-2001-TR-035, 2001,Chapter 5]
Architectural Refinement Applied to Designing E-Commerce for Survivability
[Author’s note: Although not an actual case study the following reference provides a concrete example of an architecture refinement process applied to address survivability with respect to e-commerce applications. It provides concrete examples of the results of an iterative approach that is inherent in the Architecture-First Approach].
This paper describes a process for systematically refining an enterprise system architecture for e-commerce (a system that is essentially unbounded) to resist, recognize, and recover from deliberate, malicious attacks by applying reusable design primitives that help to ensure the survival of the enterprise system. The refinement is an iterative risk-driven process which adopts the structure of Boehm’s spiral model [Boehm 88] where the spirals represent different types of attack that need to be considered. The paper presents diagrams that represent the successive architectural refinements resulting from each iteration of the spiral.
