Posted: 12th Feb 2021
Author: Eden Yorke

When you wish to extend your house, you will generally engage a builder to look at the job. They will then ask for the skills of an architect to draw up a plan so the builder knows where to put the doors, windows, and electrical services. Do a quick search for the definition of an architect, and you’ll get something like this: “a person who designs buildings, and in many cases also supervises their construction“. It will also have the definition of an architect in the computing realm: “a person who designs hardware, software, or networking applications and services of a specified type for a business or other organisation“. Over the last few years, the term architect has been, in my opinion, misused.

This article goes some way to try and address this and to correct misconceptions.

This diagram is the simplified view of the context of each type of architect. I don’t have a hierarchy, because this is disingenuous to the effort needed for each – there is no such thing as one being higher than the other. Nor is this diagram a complete list of every type of architect, as some organisations tend to create their own. This is my personal representation and can be expanded and reduced as required.

At the top of the diagram is a sliding scale to indicate the two main concerns to all architects: technology and business. On the left, the technical architects will quite rightly have less to do with the business and more to do with the technology. As moving to the right, the architects will move away from the technology and drive closer to the business.

Any solution will comprise many technical elements, such as data, infrastructure, security, and processes. It is tough to believe that a single technical architect will fully design every part of a complex solution. Therefore, the solution architect will populate the technical architecture space with the knowledge required in each technology the solution will comprise. You might be lucky and find someone with all the skills you need, but unlikely. Technical architects who are passionate about their subjects will tend to have qualifications in specific technologies. For example, infrastructure architects will now look to having cloud-type qualifications, such as those offered by AWS and Azure.

Technical architects will have in-depth knowledge of one or two subjects and a broad expertise across many technical stacks. For example, an Oracle technical architect will be very knowledgeable about the Oracle stack and understand some aspects of Mongo. However, you would not take on an Oracle architect to design a Microsoft SQL Server instance, as they won’t have the skills.

That’s a good question. Many of the technical architects I have had the pleasure of working with have a passion for technology. They invested in training and ended up working with businesses to help design and build these technologies.

We have included the security architect with the technical architects as they are the security experts. They would be responsible for designing the security for the solution. They too can gain qualifications in security to become the subject matter experts in the security field.

In many respects, technical architects are the go-to place for the experts in the field you need.

The solution architect is responsible for the vision of the solution, what it looks like, and its features. You can look at the solution architect in the same way as you would look at Renzo Piano. For those who don’t know him, he is the architect of the Shard in London. He came up with the overall design, the way it looks, and what it will do. Technical architects would have taken his vision and created plans for rooms, offices, electrical systems, heating, and air conditioning. His vision would have changed as the technical designs evolved, compromising where possible to accommodate changes due to constraints, such as fire suppression requirements and local planning regulations.

And so it is the same with the solution architect. They will have the vision about what shape the solution will be, what it does, and how it will perform, but willing to compromise as constraints come to light, or regulation demands. A solution architect will have a broad knowledge of many technologies, but there is another perspective the solution architect will need to understand: that of the delivery framework.

Solution architects not only have to wrestle with the technology and ensuring it all fits together, but they also need to be concerned with how the business delivers solutions. SAFe, TOGAF, and many others all have their good and bad points, but they achieve the goal of bringing a solution to life. None of them are perfect, and it is possible to use the relevant parts from many frameworks and come up with your own. It is entirely up to how the business works.

As parts of the solution come together, the solution architect will ensure they meet the solution’s vision as it is delivered using the organisation’s various capabilities. Other interested parties such as security, compliance, safety, and accessibility, will come together either at gates (for a waterfall delivery) or continually when needed (if agile). Any difficulty discovered can be overcome early of go-live.

The solution architect has much responsibility not just to the business to make sure it is safe, adds value, but also to the users expecting the solution to meet all their expectations. Engagement through Product Owners is the right place, but nothing beats face to face meetings with user groups and demonstrating the solution at essential points.

While on the subject of interacting with the users, solution architects will also need to explain the solution to senior management. For this reason, the solution architect will be at the halfway point between the business and the technology. They need to have a grasp of both and be involved with conversations at both the technology and business levels.

Solution architects tend to have degrees in IT, software engineering, or computer science, if you want to jump in at that level. However, it is more usual for someone to have five to ten year’s experience developing multiple technologies, then working alongside experienced solution architects for a few years before being let out on your own. An ability to instantly visualise how components will fit together is an essential trait to have. Knowing what elements are to hand to meet the needs, then quickly switch context and explain the solution to the CFO in an understandable language. Many solution architects struggle to do this. One way is to ask yourself “if I explain this to my granny, will she understand it?” If the answer is yes, and she does understand it, maybe you have the makings of a solution architect.

So, you’re a corporation made up of large, complex businesses. They, in turn, have complex applications. Any small change might be in itself problematic, and this is where the systems architect is useful. They will have the same sort of concerns as a solutions architect on the surface, but there the similarities end. While a solution architect will have a set of requirements and a pool of technologies to choose from, the systems architect takes complexity and breaks it down into discreet solutions. The correct title should be a solution of solutions architect, but that’s a mouthful. Systems architect is a much more succinct title.

When there is enormous complexity, and the solution needs breaking down, you would use a systems architect. They would often lead solution architects in extensive work programs and manage each solution’s interactions to come up with a working system. Systems architects shouldn’t be confused with systems engineers. System engineering is a separate discipline involving the negotiation of interfaces between different systems. NASA couldn’t have got near the moon without it. They used systems engineering to its full to ensure the interfaces between the different parts being manufactured by separate companies all fit together. It’s a helicopter view of a complex subject, but there are other sources for a more in-depth view of a systems engineer.

By breaking down a complex solution, the systems architect will take senior communication responsibilities from the solution architect. It leaves the solution architect to concentrate on delivering the solution. During the development stages, the systems architect will have a hand in the design of each solution, and will need good overall knowledge of the technologies and the constraints placed on projects by the company.

Many companies want systems architects to have degrees or masters in computer science. It is a good foot in the door, and it’s not unusual to see good systems architects with these qualifications. However, it is more usual to see a progression from solutions architect to systems architect, from managing a single solution to managing multiple solutions moving towards a single system.

Now we move to the most misused architect title. The enterprise architect has the least focus on technology being delivered and more with the business. To clear up any confusion over an enterprise architect, they cannot (or at least shouldn’t be concerned with) enterprise-wide systems. They should know about them as part of the business’s overall technology knowledge, but not down to the nuts and bolts that make it up. The term enterprise references areas such as the business, government department, and partnership between a government department and a private company.

The main misconception over the title comes about from vendors offering “enterprise” licences, and business misinterpreting this. When a company sees a box with “Oracle Enterprise Edition” in large friendly letters, immediately they think they need an enterprise architect to design it. This misconception is far from the truth. Just because something is “enterprise-wide” or “enterprise-class”, doesn’t need an enterprise architect to design it. Just set up a project with a solution architect and technical architects, and you’ll get a better outcome.

It might be possible for an enterprise architect to design an enterprise-wide service. After all, I have done this sort of thing in the past. But it is not a fair use of an enterprise architect’s skills.

The fundamental role of an enterprise architect is to architect the enterprise. They will know what technology the business has, the state it is in, and will use tools to help them discover hot-spots that might start to impact the core business capabilities and help seniors develop strategies to deal with gaps. However, understanding what has already been delivered is only part of it. With one hand on the past, the enterprise architect will need the other hand on the future to help define strategy with the business leaders. When a board wants to change direction and enter markets previously uncharted, the enterprise architect will use their knowledge of what is already in use and what new technologies are coming along which might help with the change. For example, when cloud services became truly commoditised, business were keen to adopt it to give them the agility to fail fast, change tack, and scale on demand. Enterprise architects would understand what the cloud would deliver them from a technology perspective. Their business knowledge will help work out if the cloud will genuinely bring the much-needed changes the business needs.

It’s the same for any technology. The enterprise architect will help guide seniors develop strategies and match existing or future technologies to meet the strategies’ needs. Moving into new markets is always an exciting proposition. However, if the company has neither the business capabilities nor the technologies, the enterprise architect can make the recommendations needed to plug those gaps.

In the world of enterprise architecture, there are many challenges. The first is not fully understanding what the business offers in the way of capabilities. Second, how the enablers (such as the technology, people, data, and locations) all come together to provide those capabilities. You cannot underestimate the importance of what I call corporate knowledge. If the company wants to switch from making gearboxes to making chocolate, the enterprise architect can confirm it could make chocolate. Or not, if the case may be.

As with many other architect roles, enterprise architects need bachelor degrees in computer science, coupled with degree-level in business studies. It will give a reasonable basis to move into the domain of enterprise architecture, certainly. Knowing how the business works will vary from organisation to organisation, and a functional enterprise architecture practice (EAP) will have access to this data. It’s not unusual for business to not have good data on the technology or the business capabilities. Therefore, the enterprise architect will need above all the ability to be able to visualise this. Understanding most business have the same supporting and strategic business capabilities, but unique core, is one way of starting this understanding.

This article has looked at the many architect types that one would encounter on a typical technology-based project. There are other architects, such as the business architect. They have no affiliation with technology and will concentrate on designing new business capabilities and business processes. They will call on an enterprise architect’s skills to help them join their work up with the technology needed to support the capability or process.

I hope you found this article useful and has got you thinking of the sort of architect you need.