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

 

 

DESCRIPTION OF THE PRACTICE:

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:

• Elicit Architectural Requirements
• Design the Architecture
• Document the Architecture
• Analyze the Architecture
• Realize the Architecture

·         Maintain the Architecture

DETAILED DESCRIPTION

“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:

 

SUMMARY CHARACTERISTICS

 

Enabling Practices:           Link to Architecture-First Approach Interrelationships Diagram Enabled Practices:            Link to Architecture-First Approach Interrelationships Diagram Impact Areas:                      Primary: Risk; technical performance Life Cycle Phase:               Valuable during all phases Scope/Authority:                Organization-level Applicability:                       Acquisition; development Use Indicators:                   High maintenance costs; high defect rates; high performance requirements; need for flexibility/adaptability Use Inhibitors:                    Requirements are too fluid; schedule extremely short Appropriate Programs:    Large, complex Inappropriate Programs: Stand-alone or short lifetime systems Barriers:                               Unrealistically short development times; lack of/conflicting definition/understanding of architecture; lack of good guidance for acquirers Facilitators:                          Standards-based approaches; SEI Quality Attribute Workshop; architectural patterns/frameworks; education/training

 

 

ANTICIPATED BENEFITS OF IMPLEMENTATION:

 

Successful implementation of the Architecture-First Approach can result in:

 

• Reduced Cycle Time to Deliver a Product

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.

 

• Reduced System and Product 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.

 

• Reduced Risk

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.

 

 

DETAILED CHARACTERISTICS

 

Key Characteristics of the Architecture-First Approach Gold Practice

Characteristic	Comments
Most Applicable for Long-Lived Systems or Product Lines	·      Approach is used (recommended for use) for long-lived systems or product lines where detailed requirements cannot be  known in advance ·      Architecture achieves a level of abstraction that allows for necessary variation when producing specific products ·      Variation and commonality in product line are addressed at a coarse-grain level during requirements gathering – not as part of the design phase
Aligned with an Iterative Life-Cycle Process	·      An iterative process is a modern software development process, which is similar in concept to the spiral model for software development.  It involves iterations that result in successive refinement of the effort, and includes interaction of stakeholders in the process.  Both of these characteristics are also attributes of the Architecture-First Approach. ·      In contrast, the traditional (sequential) development process (e.g., the waterfall model for software development) did not involve direct interaction of stakeholders during the process.  The acquirer specified the software requirements.  The developer built to the specs and delivered the software system. The acquirer tested it and accepted (or rejected) it at the end of the cycle. Rework often resulted.
Object-Oriented Design Methodology	·      The dominant perspective of this approach (and much of the terminology) comes from programs based on object-oriented design methodology (e.g., requirements specified as use cases)
Disciplined Design Method	·      The most fundamental design decisions are made during architecture development.  These are also the decisions that are most difficult to correct when they are in error. ·      A disciplined design method that focuses the creative process; provides a strategy for coping with the uncertainty in requirements; provides guidance in organizing the decisions made during the design process; and makes clear why the steps of the method exist ·      Architecture-based design method (synonymous with Architecture-First Approach) developed (and is evolving) as a result of experiences designing large product line architectures
Multiple Architectural Views	·      Approach architecture development from a variety of perspectives: static, dynamic, logical, process, implementation, deployment ·      Architecture must be documented (through various views) in order to communicate it to both stakeholders and developers ·      Specific views are created to communicate the architecture to stakeholders with varying backgrounds.
Requires Acquisition Support Through Evolutionary Acquisition Strategy	·      Requests for Proposals (RFPs) and contracts should accommodate an initial focus on architecture development. ·      RFPs and contracts should also accommodate requirements changes.  Contractors should be encouraged, through incentives, to challenge requirements and offer cost-effective alternative solutions. ·      RFPs should support phased approaches to software development allowing sufficient time and funding for architecture development prior to full-scale development
Skilled Architect	·      Success depends on the capability of the architect to identify, develop, and present alternate approaches for consideration in order to address risk and ensure the best solution.  This necessitates the architect having a high degree of technical knowledge in addition to good communication skills.
Requirements are Refined as Part of the Architecting Process – not Prior To It.	·      High-level requirements originate from the acquirer and are the basis for discussion and refinement, but they are not the final representation of requirements.  The architect works with the domain experts and other stakeholders to identify architectural drivers and decisions about the architecture result in refinement (and sometimes alteration) of the requirements. ·      Requirements are in a dynamic state and evolve into a “stable” state through the architecting process ·      This is in contrast to the traditional approach where the acquirer created a detailed requirements specification without input from (interaction with) an architect.  The developer was then expected to develop the system to meet the stated requirements.  Typically, the requirements specification was developed by a domain expert who did not have adequate technical knowledge and the requirements statements often reflected the perspective of that non-technical person and often constrained the architecture.
Small Project Team Initially	·      While the focus is on developing the architecture, the project team is small (<12); it consists of requirements analysts and technical people who can support development of prototypes to support architecture demonstrations. ·      A critical success factor of this approach is that decisions about resources needed for full-scale development are not made until the architecture is deemed stable
Significant Interaction Among Stakeholders During the Architecting Process	·      Architecting is the process of interacting with the stakeholders in order to ensure that the architecture truly addresses the needs and expectations of the acquirer.  This early interaction typically exposes needs and expectations not addressed in the initial requirements and reduces the risk of developing a product that will not be acceptable to the acquirer upon completion.  The cost of adjusting the architecture prior to development is far less than the cost burden incurred after the system has been built. ·      This is in contrast to a traditional development process where the developer solution, based on a specification document prepared by the acquirer, is implemented and presented to the acquirer for “acceptance” testing near the end of the development cycle instead of at the start
Prove That the Architecture Works	·      The developer must demonstrate (rather than state) that the proposed architecture, in fact, satisfies the requirements better than proposed alternatives.  The architecture must actually be executed, and assessed against performance and other quality requirements (architectural drivers) prior to adoption. ·      The architecture is evaluated by an independent organization or group (not the developer) ·      Concurrence from the stakeholders is necessary before a proposed architecture is accepted and adopted

 

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

INPUTS TO THE PRACTICE
Align the acquisition process with spiral/evolutionary/iterative development	The success of this approach depends on the ability of the developer to interact with stakeholders evolving the architecture to address requirements and make requirements tradeoffs where necessary. The acquisition process must allow for these iterative activities to occur. This is in contrast to more traditional scenarios where the acquirer specified all the requirements in a document which was then handed over to the developer without further interaction occurring.
Maintain an architecture focus through requirements and planning	The user interface specifies how users will interact with the system.  Therefore, it must be an integral part of the system specification.  The Architecture-First Approach seeks to demonstrate the interface (at a level of abstraction) in order to verify requirements and achieve agreement of stakeholders prior to actually developing the interface component.  This activity typically involves Requirements Trade-Offs Negotiation as the interface is refined.  If interoperability is an issue (requirement), it needs to be addressed at the architecture level because it influences the resulting architecture. Assessing reuse risks and cost, leveraging COTS/NDI, and planning for technology insertion are all considered as part of architecting, and thus influence the decisions made and the resulting architecture.  The purpose of technology insertion is not to achieve a new level of capability, but to keep the technology employed in a system sufficiently up-to-date to avoid obsolescence and associated sustainment problems, and to take advantage of greater efficiencies, lower costs, and other benefits provided by newer technology.  Thus, addressing technology insertion at the architectural stage should result in an architecture that can accommodate technology insertion later in it the project life cycle.
Business goals and requirements drive architecture decisions	A business case is concerned with providing justification from a cost, schedule, performance, and supportability perspective over the life of the system.  Architectural drivers may originate from the business case.  Maintaining the business case over the cycle of the product(system) keeps the product aligned with the business needs.  The business case establishes the focus and priority of requirements and influences the architecture over time.
Provide a basis for decisions	The existence of, or plan for, common (facility-wide) management and/or manufacturing systems within an organization necessitates consideration relative to the subject program during architecting. Interoperability issues need to be identified and addressed to ensure that the appropriate level of interoperability will in fact occur.  The architecture of the common management system may in fact drive the architectural decisions of the subject application.
Identify risks that will drive decisions	Risks are present whether or not they are acknowledged.  Formal Risk Management is concerned with identifying, addressing, and mitigating risk items before they negatively impact program quality, schedule and cost.  Formal Risk Management, implemented very early in the program, can establish the focus for the architectural strategy by identifying the most critical issues to be resolved by the architecture.
OUTPUTS FROM THE PRACTICE
Document/communicate the architecture	The architecture representation is a design artifact; capturing it in rigorous model-based notation enables complexity control, objective assessment, and automated analyses.
Evaluate architecture using independent resources	Particularly on large systems the architecture must be evaluated relative to the requirements by independent expert reviewers, prior to committing resources to full-scale production.
Consider use of commercial specifications and standards	The architect assesses the value of adopting commercial specifications and standards, or, implementing an open systems approach as part of the “architecting” activity which considers alternative designs and approaches prior to finalizing the architecture.  Thus the resulting architecture may encompass this practice as well.
Promote effectiveness of integrated teams	The combination of iterative approach to design, and the involvement of stakeholders in refining the requirements and subsequent architecture contribute to the success of IPPD. An important element of architecting is to produce several distinct views to accommodate the varying perspectives of the stakeholders and thus promote better communication and understanding among integrated product teams responsible for both product and process.

 

 

RESOURCES:        

 

§        Websites

·         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

§        Tools and Methods

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

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.

 

• Architecture Tradeoff Analysis Method (ATAM)

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.

-     [CMU/SEI-2000-TR-004]

 

• Cost-Benefit Analysis Method (CBAM)

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.

-     [CMU/SEI-2001-TR-035, 2001]

 

• Prototyping

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

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.

 

• Formal Methods

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/

 

§        Experts/Contact Points

[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/

 

§        Training Opportunities:

·         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

http://www.zifa.com/

 

§        Bibliography:

 

 

APPENDICES

DEFINITIONS:

A practice that achieves a demonstrable balance among driving requirements, architecturally significant design decisions, and the life-cycle plans to develop an architecture before resources are committed for full-scale development.

-    [Royce, 1998]

 

Royce equates his “Architecture-First” principle to the practice that the Airlie Council called “Agreement on Interfaces”.  The definition of Agreement on Interfaces is as follows:

Establishing a baseline interface specification that is agreed to by all stakeholders before implementation activities begin.  A separate software specification must be developed with explicit and complete interface information.  This is particularly critical with human-machine interfaces and where system interoperability is a requirement.

-    [SPMN,1998]

 

SOURCES (Origins of the Practice):

§         Royce, Walker, Software Project Management: A Unified Framework, Addison-Wesley, 1998. ISBN 0-201-30958-0

 

Page 63 Royce identifies the Architecture-First Approach as the first (highest priority) of his top ten principles of modern software management.

PAGE 68 Architecture-First development is a crucial theme underlying a successful iterative development process.  A project team develops and stabilizes an architecture before developing all the components that make up the entire suite of applications.  When combined with component-based development, it forces the infrastructure, common mechanisms, and control mechanisms to be elaborated early in the life cycle and drives all component make/buy decisions into the architecture process.  The approach initiates integration activity early in the life cycle to verify the design process and products.  It also forces the development environment for life-cycle software engineering to be configured early in the life cycle, thereby ensuring early attention to testability and a foundation for demonstration-based assessment.

 

PAGE 118 Under the Architect-First Approach, requirements analysis, design, implementation, and assessment activities are performed before the construction phase, when full-scale implementation is the focus.

 

PAGE 231 An early focus on the architecture results in a solid foundation for the 20% of the stuff (requirements, components, use cases, risks, errors) that drives the overall success of the project.  Getting the architecturally important components to be well understood and stable before worrying about the complete breadth and depth of the artifacts should result in scrap and rework rates that decrease or remain stable over the project life cycle.

 

PAGE 233 Royce presents a balanced application of modern principles to achieve economic results, where Cost is a function of Personnel, Environment, Quality, and Size.  He notes that tackling the architecture first and change management early improves the achievable quality of the product.  He also indicates that his “Architecture-First “principle is essentially the same as the practice called “Agreement on interfaces” in the list of nine practices originally identified by the Airlie Council in 1995 [Software Program Managers Network,1999].

RECOMMENDING SOURCES:

 

§         DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs”, 5 April 2002 [CANCELLED 30 October 2002]

§         Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]

 

C5.2.1  The PM shall implement a sound systems engineering approach to translate approved operational needs and requirements into operationally suitable blocks of systems.  The approach shall consist of a top-down, iterative process of requirements analysis, functional analysis and allocation, design synthesis and verification, and system analysis and control.  Systems engineering shall permeate design, manufacturing, T&E, and support of the product.  Systems engineering principles shall influence the balance between performance, risk, cost, and schedule.

C5.2.3.5.6.1  General.  The PM shall base software systems design and development on systems engineering principles, to include the following:

C5.2.3.5.6.1.1  Develop architectural-based software systems that support open system concepts; exploit COTS computer systems products; and allow incremental improvements based on modular, reusable, extensible software.

 

§         Capability Maturity Model Integration (CMMI), Version 1.1, Software Engineering Institute, CMU/SEI-2002-TR-011, TR-012, March 2002

 

While not specifically addressing the “Architecture-First Approach” by name, the CMMI specifies key process areas (KPA) describing practices that are essentially the same as activities comprising the Architecture-First Approach.

Pages 389-402  “Requirements Development” KPA.  Relating to SG 1- Develop Customer Requirements:  “The needs of stakeholders (e.g., customers, end users, suppliers, builders, and testers) are the basis for determining customer requirements.  The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.  Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting.  Since stakeholder needs, expectations, constraints, and limitations should be clearly identified and understood, an iterative process is used throughout the life of the project to accomplish this objective.”

 

PP 411-413  In the presentation of the “Technical Solutions” KPA, Relating to SG 1- Develop Alternative Solutions the CMMI states: “Alternative solutions and their relative merits are considered in advance of selecting a solution.  Key requirements, design issues, and constraints are established for use in alternative solution analysis.  Architectural features that provide a foundation for product improvement and evolution are considered.  …One indicator of a good design process is that the design was chosen after comparing and evaluating it against alternative solutions.  Decisions on architecture, custom development versus off the shelf, and product-component modularization are typical of the design choices that are addressed.  …As selections are made, the design space may be constricted and other alternatives examined until the most promising (i.e., optimal) solutions that meet requirements and criteria are identified.  The selection criteria identify the key factors that provide a basis for the selection of the solution.  These criteria should provide clear discrimination and an indication of success in arriving at a balanced solution across the life of the product.  They typically include measures of cost, schedule, performance, and risk.”

 

GLOSSARY

 

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.

-    [Royce, 1998, Appendix D]

 

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.

-    [CMU/SEI-2001-TN-008, 2001]