Inside Out

Notes on seeking wisdom and crafting software

Architect's dilemma

Let’s talk about three insights on an architect’s role: vision, alignment and stakeholders. We believe these may help on the journey transitioning from a developer to an architect.

architects dilemma

Vision. Which comes first? Vision or the Architecture. The answer may seem obvious - without a vision do we even understand what we’re building? A what may be a necessary step towards how. But without a framing of the key problems and their feasibility, can we assess if the vision is realistic? Vision and Architecture must evolve together. Vision ensures Architecture is on course to build something useful for the customer. Architecture keeps the vision honest by continuously apprasing feasibility and non functional aspects of the solution. Guess what’s the right time to involve an architect for a product? Hire an architect the day you start working on the vision.

Alignment. Architects are not only in the business of building a product based on specification. They are in the business of building a business. It is crucial for the architect to get a deep understanding of business goals and align the architecture, tools and processes to meet the ends effectively. For example, there may be a phase in product cycle where business wants the product to be maintained in current state; the architect’s role could be to map this goal to processes around introducing changes, keeping the technical debt in control and ensuring the critical issues are visibile to leadership. It is an imperative for the architect to ask hard business questions and understand the objectives. She must feel empowered to chime in business decisions and weigh in reality.

Stakeholder. The role of an architect doesn’t come with positional benefits. Typically you’d not have engineering resources at your disposal. You have to ask for them. You will not have the positional influence, you have to carve out the support from stakeholders. There are two sides to this. At one end, you have to work closely with the engineering teams, help them with your technical expertise and win them over. On the other side, you have to build enough trust with stakeholders that your opinions are credible. You must be visible to stakeholders. How do we do that? Practice the ancient arts of influence - talk and write sensible.

These thoughts are incomplete without a note of caution.

  • Not enough vision, or getting involved at wrong time limits the architectural choices significantly. I’ve seen this leading to skipping the architectural thinking. One school of thought calls this extreme agility; another school considers this immaturity leading to fragile product.
  • Improper alignment leads to frustration and architects may feel marginalized. In a product going through maintainence cycle, aspirations to spend effort on a beautiful and scalable architecture is futile. Please be objective and assess the business goals.
  • Not enough stakeholder visibility also leads to marginalization. Theoretically the importance of architecture is well established. In practice, architecture fights for priority/resources with functionality and shipping dates. It requires stakeholder’s maturity to appreciate the role of an architect.