Too often clients, recruiters and agencies search for an architect without understanding the role.
A really good article called On Thinking Architecturally from 2010 by renowned architect Peter Cripps illustrates the architect’s focus:
An architect keeps sight of the Why, What and How from the beginning of any endeavor until it’s successfully implemented and thoroughly documented, while everyone else has a narrower focus.
The Why is the responsibility of the organization’s leadership, and is usually grounded in the recognition of a risk, a problem or an opportunity.
Business analysts can help the leadership figure out What to do to mitigate the risk, solve the problem or pursue the opportunity.
Architects can help the leadership with How to do it by outlining one or more solutions. However, architects rarely do everything themselves, but rather lead teams of specialists who contribute to specifying, building, testing and implementing solutions.
Types of architects
Looking at job postings or talking to recruiters and agencies I find that the architect role is thoroughly misunderstood. Just because I have the word architect in my LinkedIn profile and on my website, I get contacted about every opening that has the word architect in it.
However, when someone is asking for a ‘Microservice architect’ or an ‘Infrastructure architect’ they are actually looking for someone who will work only on the How and not also keep sight of the Why and What, which means they aren’t looking for someone to actually think architecturally – they are not looking for an architect at all, but a tool- or technology specialist.
It feels as if companies are trying to attract more applicants by inflating the position’s importance by adding the word architect to the title. But in fact they are more likely to waste everyone’s time on conducting fruitless interviews with ill-matching applicants. There also seems to be a little snobbery involved when defining job titles – ‘Microservice architect’ looks better on the CV than ‘Developer’.
I find it practical to distinguish between two types of architects:
- Enterprise architect
- Solution architect
Neither role is more important than the other, only their scope differ. The different scopes are best explained by looking at the universal business model:
The enterprise architect role
An enterprise architect helps determine which solutions the business needs for establishing and maintaining all necessary capabilities. This often involves working on general infrastructure as well, since it supports the complete range of specific solutions.
Enterprise architects also define principles and draw up guidelines for solution architectures, and help prioritize and coordinate across multiple departments and projects. For this reason it’s very helpful if the enterprise architect also masters the solution architect role.
A common mistake is to think that enterprise architects only work with infrastructure or integrations. I feel that enterprise architecture must first and foremost focus on understanding the business model, identifying and shaping necessary business capabilities and defining which solutions would provide the best enablement for effective and efficient execution of the business model, which is fundamentally what will ensure business continuity and realization of new business strategies.
The solution architect role
A solution architect shapes a specific solution that enables or optimizes a subset of the capabilities required to maintain business continuity or realize a new business strategy.
So what does that mean? Well, seeing as a solution is a combination of processes that utilize certain resources, some of which can be applications with functionality used in individual process steps, it follows that a solution architect defines business processes and develops requirements for the applications that will support them.
A solution architect leads a team of specialists that develop user experiences, integrations, databases, functionality and detailed documentation.
Throughout this process the solution architect develops a solution architecture document that captures key decisions, including principles and guidelines, outlines processes, overall information structure, application designs and many other important aspects of the solution.
Most solutions require multiple specialized applications, some of which are built from scratch and others bought and used as-is or customized.
Many organizations misuse the title ‘Solution architect’ as a means of entitlement and acknowledgement of more senior employees who aren’t really doing solution architecture work. Very often they are much more lead developers that oversee a team less senior developers and testers building an application, with little or no involvement in shaping the business capabilities their application will be enabling or optimizing. People working with technical pre-sales activities are also sometimes called solution architects.
What makes a good architect?
Contrary to what recruiters and agencies believe you don’t need prior experience from the business domain in question, nor do you need to be fluent in any of the technologies involved.
Good architects follow a robust method that ensures that business needs are systematically identified regardless of the domain, be it retail, government, heavy industry, biotech, finance or any other field the company operates in. This same method ensures that whatever the business needs, the appropriate requirements for a suitable solution get specified, and a viable design is outlined for the specialists to build, test and deliver.
Architecting is much more about analyzing and outlining designs, planning and facilitating workshops with busy subject matter experts, inspiring, leading and coaching teams of specialists, understanding and addressing all stakeholders’ various concerns, and documenting the architecture to enable long-term maintenance of the implemented solution or enterprise architecture.
Does this mean that an architect doesn’t need to know the relevant technologies? Of course not, but good architects pick up and familiarize themselves with new business domains and technologies quickly.
You don’t always need a full-time architect
Whenever I’m contacted about a possible freelance contract for an architect role, clients always ask for a full-time allocation.
However, architecting a solution or an enterprise doesn’t always require a full-time effort. Consider the development process. There’s a lot of work for business analysts in the outline, detail and build phases. Much work is also done by developers in the detail and build phases.
Depending on the complexity of the problem and the experience of the project team it might be fine with a part-time architect. In my experience, whenever I work full-time in a project, I spend less time architecting and more time in other roles:
- Technical project manager – supporting the project manager.
- Business analyst – designing processes and specifying requirements and use cases.
- Lead developer – more specifically, leading a team of developers.
- Technical writer – writing manuals, guidelines, process specifications etc.