As an architect, it’s important to ensure you are driving the architecture while working, soliciting feedback, and revising the approach with the team. It’s important to have consistent buy in and ensure that you are not inadvertently leading to project problems and delays by introducing architectural components which lead to buggy code, high lead times, and technical debt.
The Team
Having a great team in place that communicates well and possess important technical and domain knowledge is important to ensuring the team is able to constructively contribute to good decision making. It’s important to ensure that the team is working well together and that there is solid trust and team dynamics in place. If team member’s are more focused on individual wins rather than team wins then they may, perhaps inadvertently, not be taking the collective goals of the organization and long term mission of the software into consideration when contributing to decisions or they may not be willing at all to funnel their best ideas up the chain.
There are often deadlines and timelines where architecture’s need to be established in order to get the development team on track. You may have a new or development team lacking some of the domain knowledge, or there may be some other team problems that still need to be addressed. Although having a solid team is important, and if there are team issues, they need to be worked on, together, however the architecture still has to continue on. It’s important that you assemble a team the best you can from the best team members you can find in the organization who have the domain knowledge and technical expertise to be involved in the decision making. This is the team that will help ensure your architecture is on track.
If there are team problems, it’s quite often a corporate or organizational problem rather than individual problems with any specific team members. Meeting regularly to discuss and resolve any issues from the prior week (in agile environments, this would be done at the retrospective at the end of each sprint/iteration.) is helpful. Get the team working together, setting goals together, and build a culture where the team is working together all the time. In this state, people aren’t afraid to speak up and everybody is working together to improve because the only goals that are important are the team goals. If the team wins, everybody wins, if the team loses everybody loses.
As is the same as sports teams, software teams that are the most successful are the teams that work well together. This creates a much bigger win than individuals working in silos would be able to do. The result in software is much much improved communication, less risk, and subsequently less technical debt .
Although, we must expect that an Architect should lead and take responsibility, the most effective architecture and standards will come from a combination of good leadership, high technical and domain knowledge, and team input. Once a solid team has been established and is working together, better communication will take place, including constructive challenges, and ensuring that the architecture will be effective.
Strategizing the Creation of the Architecture
The best architects will work alongside the team and they will require that the team gives much needed input into the future state of the system. Having a highly experienced architect come up with the initial draft architecture can definitely valuable, and this is what happens in many organizations where the architect is ultimately responsible for the architecture. However, it’s important to meet with the team, the developers, and other team members who will be working within this architecture to get consensus, to have it challenged, and to ultimately get buy in. If the team does not buy into your architecture and it becomes a forced state (“because I say so”), the project as a whole will be significantly less successful.
An approach is to have the architect(s) create a vision and strategy and then discuss it with the entire team to come up with something even better. Implement it and continually review and adapt it as necessary. It’s important not to just have the architect make an individual decision about an architecture or pattern and then leave it to the other developers to have to deal with it and the technical debt it could create. Always get team buy in for technical strategy.
One thing I’ve always done when thinking about what to include in an architecture is to come up with a scenario where the said architecture or pattern will help solve a problem (problems could be barriers to implementation, complexity concerns, business use cases, etc) and think about how the architecture lends itself to that. Look at the cost of implementing and maintaining the architecture and also the learning curve required versus the added value you are providing. Sometimes, I’ll only partly implement a pattern or architecture just so it’s there and if I really need to fully implement it in the future, the refactoring is simplified to make it so. This is to have a minimal affect on maintainability and over architecture as it creates a scenario where you can do the architecture up later when needed without majour refactoring.
Ask Yourselves if you are Architecting Too Much
Over-architecting is one of the biggest mistakes I’ve seen software architects do, and the cost to the team and product delivery in the long run is huge. This is something that is often transparent to the management team and business stake holders because they fail to see how the initial decisions of the architecture lead to more complex code, buggy code, deviated code (developer code that for simplicity sakes has deviated from the original intention of the architecture), and lead time due to the understanding and technical skills required to implement and maintain the system.
Just as great architecture can make code much better, easier, and simpler, over-architecture can have the opposite problem. Ask yourselves if there is a simpler approach to achieve the same benefit. Is there something else on the market to reduce the amount of code complexity? Do we need this much abstraction when a simpler concept will do? Will the simpler approach lead to less technical debt because it’s easier for developers developing the product to understand and use? Normally if there is an easier approach that will fulfill your needs, then there is a significantly less chance for bugs or release delays due to complexity and technical debt.
Highly technical people, create highly technical designs. Highly technical people with business acumen, a solid understanding of domain knowledge, business stake holder goals, and a focus on product delivery as a goal, create architecture that is as highly technical as it needs to be at the benefit of product delivery.
Understand the business requirements as best as you can up front, ask the right questions, and get everyone on board with where the software is going.
At the experience level of an Architect or Senior Architect, someone, by my standard, should have the experience to not over-architect or over-complicate the system, and surely know how to listen and communicate with other team members and developers on these types of decisions in order to get the best possible outcome.