This paper describes the major elements of the Architecture Process Cycle (APC). The objective of the APC is to provide a principled way to understand the importance of the architecture process, rolls, relations and steps in architecture projects with respect to multiple competing architecture design methods. These methods can interact or conflict, improving one often comes at the price of worsening one or more of the others, thus it is necessary to trade off among multiple methods adopting generic process principles as the key to success. This paper illustrates the architecture experiences in a very large military architecture program, adopting the best elements of several architecture methods, models and approaches, combined in the architecture process cycle.

3 Introduction

This paper describes several combinations of architectural methods and approaches. Explained is the WinWin Spiral Model as a model to manage processes in an incremental and evolutionary way and Theory W, a management theory and approach, which says that making winners of the system’s key stakeholders is a necessary and sufficient condition for project success.

The key elements in the architecture process cycle are briefly described like the tasks and activities, the E2AF WinWin Spiral Model, the architecture process organisation, the influence and the experiences of the architects as elements during an architecture project.

4 The WinWin Spiral Model

At the University of South California (USC) the Center for Software Engineering have developed a negotiation-based approach to software system requirements engineering, architecture, development, and management. The USC approach has three primary elements:

· Theory W, a management theory and approach, which says that making winners of the system’s key stakeholders is a necessary and sufficient condition for project success.[Theory W]

· The WinWin spiral model, which extends the spiral software development model by adding Theory W activities to the front of each cycle. [WinWin 94]

· WinWin, a groupware tool that makes it easier for distributed stakeholders to negotiate mutually satisfactory (win-win) system specifications.

4.1 Theory W Management Steps

1. Identify success-critical stakeholders

2. Identify stakeholders’ win conditions

3. Identify win condition conflict issues

4. Negotiate top-level win-win agreements

· Invent options for mutual gain

· Explore option tradeoffs

· Manage expectations

5. Embody win-win agreements into specs and plans

6. Elaborate steps 1-5 until product is fully developed

· onfront, resolve new win-lose, lose-lose risk items

4.2 Elements of the WinWin Spiral Model

The original spiral model uses a cyclic approach to develop increasingly detailed elaboration’s of a software system’s definition, culminating in incremental releases of the system’s operational capability.

Each cycle involves four main activities:

· Elaborate the system or subsystem’s product and process objectives, constraints, and alternatives.

· Evaluate the alternatives with respect to the objectives and constraints. Identify and resolve major sources of product and process risk.

· Elaborate the definition of the product and process.

· Plan the next cycle, and update the life-cycle plan, including partition of the system into subsystems to be addressed in parallel cycles. This can include a plan to terminate the project if it is too risky or infeasible.

Secure the management’s commitment to proceed as planned. Since its creation, the spiral model has been extensively elaborated and successfully applied in numerous projects.

However, some common difficulties led USC-CSE and its affiliate organizations to extend the model to the WinWin spiral model.

4.3 Negotiation front end

One difficulty was determining where the elaborated objectives, constraints, and alternatives come from. The WinWin spiral model resolves this by adding three activities to the front of each spiral cycle, as the figure below shows.

· Identify the system or subsystem’s key stakeholders.

· Identify the stakeholders’ win conditions for the system or subsystem.

· Negotiate win-win reconciliation’s of the stakeholders’ win conditions.

The model includes a stakeholder WinWin negotiation approach that is similar to other team approaches for software and system definition such as gIBIS, Viewpoints, Participatory Design, and Joint Application Design. However, unlike these and other approaches, the USC use the stakeholder win-win relationship as the success criterion and organizing principle for software and system definition.

4.4 WinWin Benefits

· Gets key stakeholders involved

· Provides collaborative operational guidelines

· Provides criteria for evaluating success

· Reduces cycle time (Especially for distributed collaboration)

· Complements other key front-end methods

4.5 Summary

The E2AF with its architecture areas and different abstraction levels is addressing all the elements to create an integrated architectural design. The WinWin Spiral Model is addressing the key elements and steps to do a successful project.

Combining these methods will bring you the best of both worlds.

5 The Architecture Process Cycle

Theory W and the Spiral Model, results in the Architecture Process Cycle (APC). The improved E2AF with the WinWin Spiral Model elements is successfully tested and approved in a complex architecture study at the Royal Netherlands Army (RNLA) in the domain of Command, Control, Communication & Information (C3I).

5.1 The Fundamental Success Condition

In addition to the technical factors represented by the quality attribute’s models and analysis of system design methods, business and social forces from multiple stakeholders influence ICT architecture. [ATAM 98]

Thus, design decisions are often made for non-technical reasons: strategic business concerns, meeting the constraints of cost and schedule, using available personnel, and so forth. “The message is, that the relationships among stakeholders, business goals, product requirements, practitioner’s experience, architectures, and fielded systems form a cycle with feedback loops that a business can manage” [Bass 98].

Modeling these elements delivers what I call the “architecture process cycle”

The Architecture Process Cycle

5.2 Key elements in the architecture process cycle

· The activities of the architecture process cycle

· The E2AF WinWin Spiral Model

· The Architecture Process Organisation

· The architects influence

· The architects experience

5.2.1 The activities of the architecture process cycle

There are multiple activities involved in the architecture process cycle:

· Visioning & Scoping the architecture environment

· Identifying the key stakeholders

· Creating the business case for the systems

· Understanding the requirements

· Creating or selecting the architecture

· Representing and communicating the architecture

· Analyzing or evaluating the architecture

· Implementing the systems based on the architecture

· Ensuring that the implementation conforms to the architecture

· Maintaining the architecture

These activities do not take place in a strict sequence and adapting the E2AF WinWin Spiral Model, there are many feedback loops as the multiple stakeholders negotiate among themselves, striving for some consensus.

Besides these activities, the architects influence and experience is a major factor in the architecture process cycle.

5.2.2 The E2AF WinWin Spiral Model

To visualize the process, in which the participants read and write various types of information (e.g., requirements, constraints, evaluation results), the E2AF steps are combined with the WinWin negotiation model.

So al the efforts in this model are focused on making winners of the system’s key stakeholders.

The starting point for the E2AF WinWin spiral approach is in the middle of the spiral, adapting the idea of “Think Big, Start Small” and the cycles of the spiral are continuous learning curves for the architects and the customer, it combines the benefits of the incremental and evolutionary approaches on a spiral way.

The result is an ongoing investment and maintenance of the architecture.

The E2AF WinWin spiral model also incorporates the maintenance and refinement of the architecture after the first process cycle.

The implication is that potentially any of the key stakeholders (architects, experts, developers, etc.) can make use of information developed by any other stakeholder and can introduce information that could be of interest to anyone else.

Managing all these stakeholders’ influences is one of the most important activities of the lead architect of an architect’s team, trying to get consensus over the different topics and to satisfy the critical stakeholders.

During every phase of the E2AF WinWin spiral model, iteration between activities inside the phase is a standard part of the process.

The Integrated Architecture Framework addresses quality of services as the measurable non-functional requirements in the architecture. These quality of services are interdependent, for example, performance affects modifiability, availability affects safety, security affects performance, and everything affects cost. In other words, each quality of service has interfaces to other quality of services. This is the principal difference between an architectural design analysis and other software analysis techniques that it explicitly considers the interdependencies between multiple quality of services.

5.2.3 The Architecture Process Organisation

Several roles can be identified in the architecture process organization, to achieve the goal of making winners of the critical stakeholders.

So teams with different roles and responsibilities have work together to do a successful architecture project or program.

In the study of the Royal Netherlands Army, we have created the following teams:

· The Process Team: (Experienced Architects in the E2AF WinWin spiral model, facilitating the architectural design activities)

· Client Teams: (Employees of the customer, bringing in their business knowledge)

· Design / Maintain Team: (Potential Architects of the customer, who will maintain the architecture in the future and will support several development teams in how to use the architecture. They also will control the architecture principles during development and implementation)

· Communication & Public Relations Team: (Responsible for all communications about the architecture study. Organizing events and presentations for different stakeholders. Creating Web pages, CD’s and flyers with the results of the architecture study. Responsible for all press communications. This team is the key to success in communicating in a professional way with all the critical stakeholders.)

· Expert Teams: (Internal and external experts [developers, engineers, etc.] who will bring in their specific knowledge to address specific detailed architecture items or topics. Most of the time these experts are part of the future development team and can have their contribution to the overall architectural design by participating in the expert teams. Hand-over of the architectural design results to the development organization is in this case no issue.)

· Management Team: (The Management Team is responsible for the overall result of the architecture process and exists of the Chief Architect and responsible management of the customer. All the decisions that have to be taken during the architecture process has to be validated by the management team and will be prepared by the process and design / maintain teams.)

5.2.3.1 Review Process

All critical stakeholders will do review of the architectural design results. Organizing the review process in such a way that the architectural design results will reflect the most critical remarks of the reviewers is a good way to get buy-in from these stakeholders.

5.2.4 The Architects Influence

Most of the time the effects of the architecture process and the role of the architects will influence the customer organization in several ways. Often you can see that the architecture process is at the same time used as enabler for change management in the customer’s organization. Where primary the focus is on the architecture study and the outcome of results, the site effect is most of the time a concentration of attention of the customer organization on new common goals, justifying the need for change.

So the influence is at least in two directions, the influence in technology change as result of the architecture study and the influence on the change of organization related to these results.

The role of the lead architect is to manage these influences in parallel during the whole architecture process cycle.

5.2.5 The Architects Experience

Experiences of an architect acquired during several architecture studies are one the most critical success factors in the architecture process cycle.

By the fact that every architecture process is unique to the business proposition that it supports, enables and enhances, the architect has to know how to interact to these unique business situation.

For example, if your CEO wants to lead the world in something, he will not find it in an architecture that someone else has implemented already - if he does, they are leading the world.

So addressing every unique customer situation, combined with experience in managing unique architecture processes and experience in using the required architecture methods in different situations are the key elements to success.

5.3 Summary

Understanding the role of the architect in the whole process and the importance of all the elements of the architecture process cycle is key to make winners of the critical stakeholders.

6 References

[ATAM 98] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, J. Carriere, “The Architecture Tradeoff Analysis Method”, Carnegie Mellon University, CMU/SEI-98-TR-008, 1998.

[ATCCIS] “Army Tactical Command Control Information Systems” Interoperability standard initiated by SHAPE.

[Barbacci 98] Mario R. Barbacci , “The Architect” . Volume 1 . Issue 2 . September 1998.

[Bass 98] L.; Clements, P.; & Kazman, R. “Software Architecture in Practice”. Reading, MA: Addisson-Wesley Publishing Company, 1998.

[Belcher 96] M. Clay Belcher, University of Kansas, “What is Architectural Engineering?” 1996.

[GSAW 99] J. Schekkerman, Ground Systems Architecture Workshops, march 99, El Segundo, USA.

[NSAE] National Society of Architectural Engineers, USA.

[PHIDEF 97] “Project Herinrichting Informatievoorziening Defensie”, Netherlands Ministry of Defence, 1997.

[Theory W ] B. Boehm and R. Ross, “Theory W Software Project Management: Principles and Examples,” IEEE Trans. Software Eng.,1989.

[WinWin 94] B. Boehm and P. Bose, “A Collaborative Spiral Software Process Model Based on Theory W,” Proc. Int’l Conf. Software Process, IEEE CS Press, Los Alamitos, Calif., 1994.

[WWISA 99] World Wide Institute of Software Architects, 2774 North Cobb Parkway, Suite 109-211, Kennesaw, Georgia 30152, USA.