I have worked in software development in several companies over the course of my career. In those companies, I’ve seen wide ranging choices on the topic of software architecture. I’ve been in places where they’ve been critically important to the success of the organization, places where they exist but don’t really do their jobs, and other places where they are non existant. Having seen the range, I am an advocate for strong software architects for a number of reasons.
A strong software architect makes high level design choices and sets standards for the organization. Even though most software developers try to make good design decisions, those decisions have a wide range that is based generally on their level of experience. Most well staffed organizations have seasoned developers of varying levels along with newer developers set to take their place later on. If you consider high level design choices like pouring a foundation for a house or a building, try to imagine everyone working on the project creating a little bit of cement with their own recipe and mixing it all together. The resulting mixture would be insufficient to bear the weight of the building. Having one good architect making design decisions ensures a strong foundation for the rest of the software built upon it. It also ensures that, when followed, the level of technical debt your organization occurs is minimized.
A strong software architect is able to lead other developers to become better. Their years of experience have made them experts at breaking down a large problem into smaller pieces. They lead building out new apps that developers can use as an example as well as providing documentation and diagrams that help other developers understand the high level design. They mentor newer developers and suggest experience appropriate tasks that will help the newer developers grow and gain new skills in the correct order. They are a technical example others can aspire to as well as a leader others want to follow.
A strong software architect is an advocate for IT when interfacing with other groups within IT and in the rest of your business. They can take complex subjects and explain them in a way those with other skills will be able to understand without feeling put down. They present a capable and confident front. They explain why certain tasks take the time they do in a way others understand.
I’ve mentioned a few benefits of a strong software architect. Here is a list of ways you can identify a strong software architect. You’ll notice that this second list has a few items that could go in the first, but I’ve only listed them once for brevity.
- They are recognized by their peers and people in outside organizations as thought leaders. Other developers within the organization believe that the high level design and standards are sound. They regularly publish new ideas to share their knowledge. They attend and speak at industry conferences. Unless you were/are an architect yourself, this is really the only way you’ll be able to evaluate their technical skills.
- They keep up on changing industry standards and regularly bring up new ideas. This doesn’t necessarily mean that they update your company standards based on new information every time someone else comes up with a good idea. In fact, that would be problematic. However, it does mean that they know what is currently happening with your technology stack and evaluate whether new ideas would be of use to your organization.
- They’re not afraid to get their hands dirty or far reaching changes when necessary. A good architect should never be afraid to jump in and help implement when it’s determined that high level design should change significantly. They may build a framework or way of implementing a new idea that other developers can then follow. Or, they may do an entire implementation themselves.
- Their mentees enjoy working with them. All too frequently, an otherwise very good technical resource makes themselves useless as a mentor due to an abrasive personality. Those they are working with should respect the architect and feel respected in return.
- They advocate doing things “the right way” instead of “the easy way.” Again, architects should have the long view when deciding on how something should be done. They should be able to explain the implications of whatever brand of technical debt your organization decides to take on. This doesn’t mean that they don’t accept a best fit solution when one is decided upon. However, you should be concerned if they aren’t always advocating to do a particular task or project in the way that minimizes technical debt.
- They have soft skills in addition to deep technical skills. This is related to number 4 above. Often an architect will be brought in during a concepting or design phase of a project. They are there to determine the feasibility of the project as well as the resource commitment. They have the people skills to interface with different business groups. They have the ability to understand what the other groups need even if the other group may not communicate it clearly. They also need to be able to see the real problem behind the solutions that other groups bring. You can evaluate this by simply asking other groups how they feel about working with an architect.
This scratches the surface of the value a good software architect brings to your organization and how to evaluate a current or prospective architect. If your organization is large enough and you don’t have one, I encourage you to do additional research on the role of an architect and evaluate carefully whether you should bring one into your organization or promote someone that is already there.