A software architect is a key person in a software project, which I explained in my What Does a Software Architect Do? post a few months ago. The architect is personally responsible for the technical quality of the product we’re developing. No matter how good the team is, how complex the technology is, how messy the requirements are, or how chaotic the project sponsor is, we blame the architect and no one else. Of course, we also reward the architect if we succeed. Here is what I, as project manager, expect from a good architect.
In all projects we run at Zerocracy, I expect regular reports from software architects a few times a week. Each report includes three mandatory parts: 1) scope status, 2) issues, and 3) risks.
Scope Status
The first and most important type of information I’m looking for is the scope status, which should be presented in Product Breakdown Structure (PBS) format. No matter how complex or how small the product is, a good architect should be able to create a PBS of four to eight items. For example:
1. MySQL persistence [done]
2. OAuth login [done]
3. Input parsing in XML [75%]
4. S3 data storage [none]
5. UI cross-platform testing [none]
That’s the size of the report I’m expecting to receive from a good architect every few days. The main goal for the architect here is to make sure that nothing is missed. No matter how big the project is, all its technical components must fit into this PBS.
The architect is personally responsible for not missing the information in the PBS and making it as accurate as possible. If something is missed or the report is delayed, that becomes a good reason to change the architect.
The percentages of progress are also important here. Even though individual tasks are managed with the “0/100 completion principle” in mind, the architect must compile those percentages and make sure that compilation is accurate. Again, a mistake here is unforgivable.
Issues
The second important part of a regular report from an architect is a list of current issues the development team is facing. An issue is something that has already happened and we’re suffering from it. Here are a few practical examples:
1. MySQL is too slow for our performance requirements
2. Java 1.6 doesn't allow us to use library X
3. We don't have a replacement for a Ruby guy who left us
4. Integration tests are not predictable
Again, the list must include four to eight items (no more and no less), and the architect should mention the most critical issues there.
Risks
Now, the risks. A risk is something that hasn’t happened yet but may happen soon, and if it happens, we’ll be in trouble. The architect is responsible for keeping an eye on all potential risks and regularly reporting the most critical ones to the project manager. Here is an example of a brief risk report:
1. Deployment platform may not support Java 8 [3/8]
2. Library X may take more than the two weeks planned [7/3]
3. We may lose a good Ruby developer soon [5/6]
4. Integration tests may not be safe enough [7/2]
5. We may fail to find an open source library [3/8]
A project manager may require additional information about each risk, but that’s another story. What is most important is to keep the project manager informed about the top of the list. Each risk has two numbers associated with it: probability and impact, from 0 to 9. In the list above, the first risk has a probability of 3 and impact of 8. This means the architect believes that most likely this won’t happen, but if it does happen, we’ll be in big trouble.
Pay attention, as the key word in each risk description is may. A risk is something that hasn’t happened yet. That’s the biggest difference between a risk and an issue. An issue is a risk that has already occurred.
PS. Here is how an architect can enforce the principles of design and architecture: Two Instruments of a Software Architect
