Over a million developers have joined DZone.

Three Things I Expect From a Software Architect

The architect is personally responsible for the technical quality of the product we're developing. No matter how good the development team is.

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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 noone 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 Teamed.io, 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.


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.


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

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

devops,architecture,project management

Published at DZone with permission of Yegor Bugayenko, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}