As a consulting solution and enterprise architect, I frequently need to explain what I do – and don’t do. Too often recruiters and agencies ask for an architect without understanding the role.
An architect keeps sight of the Why, What and How from the beginning of any endeavor until it’s successfully implemented and adequately documented.
The Why is responsibility of the organization’s leadership, and is usually grounded in the recognition of a risk, problem of possibility.
Business analysts can help the leadership figure our What to do to mitigate the risk, solve the problem of pursue the possibility.
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 pratical to define two types of architects:
- Solution architects
- Enterprise architects
Neither role is more important than the other, only their scope is different. The different scopes are best explained by looking at the universal business model:
The solution architect role
A solution architect shapes a specific solution that enables a subset of the capabilities required to continue the business.
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 the process the solution architect develops a solution architecture document that captures the 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, being completely decoupled from the business context in which the functionality will eventually be utilized. And sometimes the title is used by people working with technical pre-sales activities.
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 architecture, 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 and shaping the business model, identifying necessary 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.
Incidentally, this means that there aren’t many people in the world with the title ‘Enterprise Architect’ who actually architect enterprises. Primarily because they aren’t really included in the executive management circle where these things are being discussed.
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 area the customer may be active 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 the team of specialists, understanding and addressing all stakeholders’ various concerns, and documenting the architecture to enable long-term maintenance of the implemented solution.
Does this mean that an architect doesn’t need to know the relevant technologies? Of course not – quite the opposite, in fact. The architect will certainly benefit from having a broad knowledge of all the other disciplines involved in the entire development project, from project management, business analysis, requirements specification, process and software design, user experience design, programming, technical writing and illustration, platforms, frameworks, technologies and organizational implementation.