The Software Architect

What is an architect? An architect is a developer. It is not someone who has "retired their keyboard" and sits in long boring meetings with flow diagrams to decide who is on the hook for delivery.

An architect is a developer. It's me and you. I say this because any of us can define a vision and turn it into reality. There are no barriers in doing this and you can accomplish something incredible. An architect can only do a good job by being hands-on and working within the development team or community and having good communication. In doing so, they intimately understands the problems and concerns of the team and should be working to solve them. An architect also steers and leads the team in matters of architecture and planning.

Usually, an architect is more focused on the structure of the system than on its features and functions. Architects create an architecture that allows those features and functions to be easily developed, easily modified, and easily extended.

With this you have to see opportunities and options for how an idea might turn into a business advantage. Sometimes this requires a healthy dose of optimism but always backed up by data and proving value. For this to become a reality, you often can't make the decision alone, you have to bring others with you and convince business of its value and motivate team members about the journey. So communicating that vision is important and making it a shared vision from top to bottom.

Often when a vision is created it can take a life of its own, so it is important to keep everyone grounded in what the possibilities are for a given time period. Often the act of conducting architecture shifts or new processes do not bring all the immediate benefits at once, there has to be some short term benefits for it to be viable but often there are long term benefits which need time to be realized and understood or expectations can become unclear and ultimately disappointment down the road.

Architecture needs to come first and so an architect should take part in bigger picture discussions with the business allowing them to give input into business changes impacting technology direction. You don't implement an architecture without considering the team size and capabilities!

The architecture of your system should reflect your team, thus everyone in the team is a stakeholder in the architecture, from developers to testers and the business.

Many view the job role of an architect to be an aspirational goal and only achieved through promotion. But every developer is an architect even if it's not your role or title. You have the same concerns and work together in the same team so your experience still matters even if it isn't in your job title. For these reasons we should not assume that it is the responsibility of others on matters affecting the workplace.

Architects will likely spend less time actively writing code, but it should benefit the team. The aim is to help the team become more efficient, fast or improve their process and that also means listening to the team.

To be able to do this, an architect needs to be close to the code and team. It is also important to have input into code principles, best practices and metrics, but so should you. These are all tools a developer can use regardless of role or seniority. Ultimately, in my experience as an architect you need to listen to your team and build around them and include them to build trust and and openness which leads to better solutions.