This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: A Software Architecture Process Feed Title: Richard Demers Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml Feed Description: Richard Demers on Smalltalk Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Richard Demers Blog

A scenario: after years of ad hoc, hacker-style software development you have finally convinced management that someone needs to be the technical leader of a project, and that person gets the title of "architect." And now, you are "the architect" of a new project.

You have a combination of organizational and procedural problems. You are seen as an outsider by the rest of your IT community, as a threat to their status. Everything you ask for is seen as ammunition against them. They resent the time it takes to fulfill your requests; time they can better spend doing "real work." It is no wonder they are uncooperative; you are unwanted overhead - white space.

A few suggestions:

1. 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 the 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.
2. Consider setting up an Architecture Control Board (ACB). Do not expect the architecture team to go it alone; you cannot. You need the active buy-in and participation of the ACB members - the more the better.
3. Membership in the ACB should include representatives from as many of the stakeholder groups as possible: end users, analysts, architects, programmers, testers, documenters, maintainers, etc.
4. While all members of the architecture team are, by default, 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.
5. 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.
6. One purpose of the ACB is to review and approve new requirements and requests for changes. These are often expressed as new or modified use cases produced by business analysts. When first introduced to the ACB, perform only a general screening to weed out the more bizarre ideas that a project can attract. Log the requirements and assigned them to a software architect for analysis, design, and risk assessment.
7. A second purpose of the ACB is to review and approve the blueprints produced by an architect. Make this as easy as possible for the ACB members. Associate every change with specific requirements. That way, only the changed areas need be reviewed, and the changes can be reviewed one topic at a time.
8. 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.
9. 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.
10. The ACB is not a voting forum. Seek consensus where ever possible, but retain final authority within the architecture team. In a large architecture effort, not all parties are equal in value. 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.
11. Try to keep separate the detailed 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.
12. 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.
13. Retain control of your deliverables, the blueprints, subject to the approval rights of the ACB. 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 architecture blueprints are solely the responsibility of the architects.

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