Technical Architecture: Understanding the role of the Architect

Technology projects require many skill sets to succeed. One of the most misunderstood roles is the "architect". This isn't surprising, given the inconsistent use of the term and the ambiguity in expectations. Here are some of the comments I've heard (and even thought) about architects:

• There are many different categories of architecture. How do I know who does what?
• I barely understand them. They speak in abstract terms and confusing diagrams that are disconnected from reality.
• Who do they report to? They're outside my product team and appear to follow their own rules.
• They make a lot of noise upfront, then disappear. How do they help with delivery?

In this article, I’ll address these points without adding to the confusion (hopefully). I’ve deliberately avoided the jargon and acronyms commonly associated with popular architecture frameworks and (some) architects.

What is Architecture?

You can find many wordy definitions of architecture as it applies to business and technology. Put simply it's about designing, building, and evolving solutions in alignment with business strategy and goals.

You may see it broken down into these categories:

1. Enterprise Architecture – This focuses on why solutions are needed in the first place. It identifies the necessary solutions to achieve business objectives and the roadmap of initiatives to get there.
2. Solution Architecture – This is the design of solutions based on business requirements, making key decisions on technologies and integration approaches. It defines how different components come together to deliver a solution.
3. Technical Architecture / Technical Design – This deals with the detailed design of individual components, requiring expertise in specific technologies and domains (e.g., Java, Python, Data, Web, Cloud Infrastructure). It answers the low-level details of what the final solution will look like.

These categories of architecture represent different levels of abstraction, the method we use to simplify complex problems.

Do I really need that many architects?

Maybe. It depends on the size and complexity of your organisation and its goals. Just because there are different types of architecture doesn't mean you need dedicated roles for each. Here's a common pattern I've seen:

1. Start small – Small businesses or startups may not have anyone actually called an "architect". Instead, a lead developer or CTO handles architectural duties, focusing on the minimum required architecture for development, i.e., technical design.
2. Scale up – As teams and solutions grow, technical architects may be identified for different technology domains. A solutions architect then ensures these domains are aligned to support the overall solution success.
3. Strategic Support – Over time, as a business accumulates more solutions serving many purposes, changing business strategies can become complex. Enterprise architects can help navigate this complexity and support executive decision-making.

The most important aspect is that the "why", "how", and "what" of architecture are considered, rather than the number of architects or specific titles. Some of the best architects are those who can operate across multiple levels of architecture.

I have no idea what the architects are talking about

Effective communication is crucial for architects, who must tailor their messages for different audiences—both technical and non-technical. Organisational alignment can be just as critical as technical success, especially for enterprise architects.

A common task for an architect is to create different "views" of a solution to service different needs and audiences. This can be a difficult when trying to communicate with everyone from developers to executives. However, if your questions as a stakeholder are not being addressed, it might indicate a problem with the architecture. Keep in mind that complex terms and acronyms may be useful when architects are speaking with each other, but they shouldn’t be used with a general audience.

They create a lot of materials, but I don't see the value

Architects often produce a range of diagrams, models, and documentation. Common architecture frameworks suggest standard activities and deliverables, but these are just tools to communicate architectural direction and inform decisions.

Architects should only create what’s necessary to address the current business problem—this is sometimes called an "architecture initiative". Volumes of documentation without an immediate use are a red flag.

All they do is say no. I'm trying to innovate!

Architects should base their decisions on "architecture principles" which are unique to each organisation and aligned with business strategy. For example, many companies have principles like "prefer reuse", "buy over build" or "assess total cost of ownership (TCO)". These principles can sometimes conflict with enthusiastic product owners or innovation-focused teams, especially when principles like "maximise overall value" or "ensure ease of use" come into play.

Evaluating options should involve key stakeholders. If architects seem to be saying "no" too often, it could be time to revisit the architecture principles—especially if they don’t reflect new strategic directions. Architecture should always support business innovation and strategy.

We never see them. It must be nice in that ivory tower.

This criticism is usually directed at enterprise architects, and it may point to issues within the organisation. Architecture is not an end in itself. It exists to support business strategy and solution delivery. Architects should be open to feedback, ready to answer questions, and actively involved in ensuring that delivery aligns with strategy.