Category: Software Architect

When an architect enters a project, there is an understandable desire to prove one’s worth. Being assigned the role of software architect typically indicates implicit trust on the part of the company in architect’s technical leadership, and it only follows that the architect would desire to make good on that expectation as soon as possible. Unfortunately, there are those who labor under the misapprehension that proving one’s worth consists of showmanship; bedazzling if not baffling the team with one’s technical brilliance.

Showmanship, the act of appealing to your audience, is important in marketing, but it’s counter productive to leading a software development project. Architects must win the respect of their team by providing solid leadership and by truly understanding the technical and business domain in which they are expected to operate.

Stewardship, taking responsibility and care of another‘s property, is the appropriate role of an architect. An architect must act in the best interests of their customer and not pander to the needs of their own ego.

Software architecture is about serving the needs of one’s customers, typically through direction from those with domain expertise that surpasses one’s own. Pursuing successful software development will lead one to create solutions of compromise, balancing the cost and complexity of implementation against the time and effort available to a project. That time and effort are the resources of the company, which the software architect must steward without self-serving undercurrents. Unduly complex systems that sport the latest hot framework or technology buzzword seldom do so without some sacrifice at the company’s expense. Much like an investment broker, the architect is being allowed to play with their client’s money, based on the premise that their activity will yield an acceptable return on investment.

Value stewardship over showmanship; never forget that you are playing with other peoples’ money.

Most architects begin their career as developers. An architect has new responsibilities and greater authority in determining how a system is built. You may find it difficult to let go of what you did as a developer in your new role as an architect. Worse, you may feel it’s important for you to exercise a lot of control over how developers do their work to implement the design. It will be very important to your success and your team’s success to give all of your teammates enough autonomy to exercise their own creativity and abilities.

As a developer you rarely get the time to sit back and really look at how the whole system fits together. As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces and databases, you should be making sure that all those pieces work well together. Listen for points of pain and try to improve them. Are people are having trouble writing tests? Improve the interfaces and limit dependencies. Do you understand where you actually need abstraction and where you don’t? Work for domain clarity. Do you know what order to build things in? Build your project plan. Are developers consistently making common mistakes using an API you designed? Make the design more obvious. Do people really understand the design? Communicate and make it clear. Do you really understand where you need to scale and where you don’t? Work with your customer and learn their business model.

If you’ re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers. You do need to watch closely enough to see that the design is being implemented as intended. You do not need to be standing over people’s shoulders to accomplish that goal. It’s reasonable to make suggestions when you see people struggling, but it’s even better if you create the environment where they come and ask you for suggestions. If you are good, you will deftly walk the fine line between guaranteeing a successful architecture and limiting the creative and intellectual life of your developers and teammates.