Enable JavaScript.

Software Architecture Control

The design of

(DDM) and the implementation of numerous DDM client and server programs on a variety of IBM computer systems was complex. It was the work of many people in IBM software development laboratories in the United States, Canada, Great Britain and Germany. The DDM architecture team was located in Rochester, MN and had overall responsibility for its design, but many stakeholders had to be satisfied over a period of more than ten years. In this article, I want to summarize the organizational and procedural techniques we used. I believe the following heuristics are applicable to a wide variety of complex software projects and more generally, to the development of standards in other fields.

  1. There are many stakeholders of any large project: planners, analysts, architects, programmers, testers, documenters, maintainers, and end users. Who are they and what do they want from the project? You need their active buy-in and participation, the more the better. [Bass, 1998] discusses the importance of product-line architectures, in which multiple products are constructed from a common architectural specification. However, the concept of stakeholders is more general than products in that a single product can have multiple stakeholders with varying requirements to be met by the product's architecture.
  2. Focus your initial efforts as narrowly as possible. Try to meet the specific needs of one group of stakeholders. If you succeed, other groups will clamor to get on board. You may have to make some changes to accommodate the needs of new comers, but that's OK. Grow the architecture over time. It does not have to be complete and perfect right out of the starting gate [Gabriel, 1996].
  3. Set up an Architecture Control Board (ACB). Do not expect your architecture team to go it alone; you cannot. Membership in the ACB should include representatives from as many of the stakeholder groups as possible. While all members of the architecture team are members of the ACB, not all ACB members are part of the architecture team. It is important to maintain the view that the architects are specialists working on behalf of the stakeholders. In conjunction with this, ACB meetings should not be used to assign issues to stakeholders for additional work, except to clarify issues they raise themselves.
  4. Hold ACB meetings periodically. For a large effort, ACB meetings every four to eight weeks are sufficient. Any more often and people look for excuses to not attend. They have other work to do.
  5. One purpose of the ACB is to review and approve new requirements and requests for changes. These will often be expressed as new or modified use cases produced by business analysts. When first introduced to the ACB, perform a general screening to weed out the more bizarre ideas that a project can attract. Log the requirements and assign them to a software architect for analysis, risk assessment, and design.
  6. A second purpose of the ACB is to review and approve the (i.e., the architectural specifications and models) produced by an architect. Make this as easy as possible for the ACB members. Associate every change with the issue for which the change was made. That way, only the changed areas need be reviewed, and the changes can be reviewed an issue at a time. In some cases, you may want to generate subsets of the blueprints to keep particular ACB members focused on their specific issues.
  7. The ACB is not for doing "design by committee." That never works. Great designs come from individuals, namely the architects, followed by thorough review and critique. Normally, the architecture team does pre-ACB reviews to ensure that the architecture team is all in agreement.
  8. Conduct each ACB meeting with appropriate formality. This increases everyone's respect for the ACB and the architecture team.
    • Publish an agenda before each meeting.
    • Stick to the agenda; allow no one to subvert it; suppress private agendas.
    • Run the meeting according to a loose set of parliamentary rules.
    • Do not let it become a debating forum. Contentious issues should be recorded and handled off-line.
    • Record and publish the minutes of the meeting. Be complete and honest in this reporting, but retain editorial control.
  9. The ACB is not a voting forum. Seek consensus wherever possible, but retain final authority within the architecture team. In a large architecture effort, not all parties have equal clout. Deciding who gets what priority is part of your responsibility. It is also helpful to set up an escalation path to higher levels of management so that stakeholders can appeal your decisions. The escalation path is seldom used, but important to have.
  10. Try to keep separate the concerns of the various ACB members regarding low-level details: design, programming, testing, etc. These details can overwhelm the central vision of the architecture and make it too implementation specific.
  11. The blueprints (specifications and models) produced by the architects and approved by the ACB are the ultimate deliverable of the architecture process. Focus all efforts by the architects and by ACB members on them. If possible, use a version and configuration management tool.
  12. Retain control of your deliverables, the architectural blueprints. Allow no one but members of the architecture team to create or change any aspect of the blueprints. While other people may be consulted by the architects, the creation and maintenance of the blueprints are solely the responsibility of the architects.
  13. Even when the project is finished, ensure that the architectural blueprints are properly archived for the future. Projects evolve over time and changes will be required. Keeping the blueprints up to date helps to control project drift into chaos.

The bottom line is that you will gain the respect and cooperation of your stakeholders only if you actively engage them, and deliver the high-quality blueprints they need to do their jobs.

Summary

All of the ideas expressed in this paper have a long history of successful use. I learned them from the architects of IBM's System Network Architecture (SNA), and I used them for IBM's Distributed Data Management Architecture [Demers, 1992]. For a smaller scale project, I would also use this approach, but my focus would change from providing services to multiple products to providing services to the many stakeholders of the project. I believe these ideas apply to most software architecture efforts.

References

[Bass, 1998]
Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison-Wesley, 1998.
[Demers, 1992]
Demers, R. A., Fisher, J. D., Gaitonde, S. S., Sanders, R. R., Inside IBM's Distributed Data Management Architecture, IBM Systems Journal, Vol. 31, No. 3, 1992, pages 459-487.
[Gabriel, 1996]
Gabriel, Richard P., Patterns of Software: Tales from the Software Community, Oxford University Press, 1996.

Le contrôle de l'architecture de logiciel

 

Cet essai porte sur l'organisation et les techniques utiliser pour developer l'architecture d'un grand et complex système de logiciels.


Désolé, pas encore traduit.