What is the role of an architect in software development?

Everyone has to do architecture work to develop and maintain good software products. How do architects fit into the process? What should their responsibilities be for architecting features or products? How much responsibility do they have around product direction? What impact should they have with regards to development processes?

As with many roles, you are best served by defining clear boundaries around what architects should do. It is easy to imagine turf wars between architects and a number of other constituencies including developers, managers and product managers.

Here are the three basic areas that architects should own:

• Architectural roadmaps
• Architectural specifications
• Developer processes and best practices

The architectural roadmap is the first place architects feed into the process. These roadmaps should feed into product management just like other requirements including those from customers, sales, standards, competition, etc. The format can easily follow similar strategic documents I have proposed in the past:

• Taxonomy - what is important in a particular areas
• Report Card - how the product does in that area
• Today picture - a visual representation of what the area looks like today
• Tomorrow picture - a visual representation of what the area could look like
• Projects/Tasks - a list of what must be done to actualize the tomorrow picture

The areas might include discreet technologies like storage or networking or they may reflect attributes like quality, usability or performance. The architects should develop roadmaps for each area that constitutes a value proposition for the customer.

The second place architectural oversight is necessary is around specifications. This process should occur after requirements are available from product management but before engineers develop design specifications and schedules. The architects should have unique insight into the overall product and develop these specifications as a leg-up for engineering.

Architectural specifications should include the following:

• Refined requirements - embellishing product management requirements based on the architects broader and more detailed view of the technology and product.
• Investigation items - these should be resolved before a specification or schedule are approved
• Architectural requirements - these must be addressed in any design or development
• Excluded items - these should not be included in the project

This makes the architects the bridge between product management and engineering and provides direction and guidance instead of a blank sheet of paper for engineering. The result should be more consistent products that meet broader goals including interface integrity, performance, quality, etc.

Finally the last place the architects should play a role is in the specification and oversight of development processes. This includes:

• Developing a design/functional specification template and process
• Developing the guidelines and process for code reviews
• Specifying coding conventions and tool selection

The processes should have oversight from the architects. For example, they should get to approve who the reviewers should be for code reviews. Do not mistake this item with saying that the architects must do all the specifications or reviews. They should delegate but retain oversight and they should be accountable. If architects end up doing all of the detailed pieces, developers will resent them and you will not make efficient use of both the architect's and developer's skills.

All of the above items could be distributed throughout an organization but they are usually assigned to senior members of the team and often designated as architects. The important thing is that these tasks must get done and you should make it clear who is responsible for getting them done.

Make your architects more successful and your team will be more successful.

More later ...