What type of Architect are you?

Everyone these days speaks of digital transformation, the evolution of traditional business and processes to the next level – to the public cloud. Moving entire systems or even a whole company to the cloud requires some efforts and often also a specialized skill set. Not only inspiring with innovation, but customers also want to be taken care of and follow an experienced person or team. There is a trend that companies and/or customers are starting those cloud or innovation teams with an architect. But, which type of architect is the right one, and who would be the right candidate for the identified position?

First a few steps back. You may wonder how does an IT Architect differ from a traditional Architect, those guys who design real houses and buildings? Architects are “designer” and lead with “innovation” to “inspire” customers, which both have in common. Perhaps the most interesting difference is that there is often an expectation from the customer, that the IT Architect is also bringing hands-on experience. In the world of woods and bricks architecture, this is probably not the most common career path. Architects who design entire buildings bring unusually a university background rather than hands-on experience. In IT, most of the Architects I know started as an Engineer or Consultant (some years ago), and becoming an Architect is a natural career path by taking more and more responsibility and leadership.

In this article, I try to explain the three primary architect profiles:

• Enterprise Architect
• Solutions Architect
• Technical Architect

Every of those Architect profiles will address different requirements, needs, and types of insight that may span business to technology. That’s why these aren’t just different roles; these architects are different job profiles. There is a misconception that these are different levels of an architect. Well, a person can become a Senior Technical Architect from an Associate Technical Architect over time, but that does not make him/her an Enterprise Architect.

That’s why these jobs are not competing; they need each other to be successful and drive impact for our customers. The graphic below visualizes nicely how every one of these Architects would play an essential role on the soccer field:

The Solutions Architect

The Solutions Architect (SA) is assigned to an engagement or program to ensure technical integrity and consistency of the solution at every stage of its life cycle (in the project). Typical part of this role is to moderate between business and technology teams and various other groups or even companies. This makes the SA as the “go-to” person for any technology ask, conflicts, implementation issues, or decisions.

Solutions Architect are not doing any hands-on as coordination of technical and project related activities takes most of their time. Instead, the SA gets involved through concept definition and requirement engineering, design and design documentation, implementation oversight and even hand-over to customers IT. Consequently, the Solutions Architect must have a balanced mix from technical depth to breath and even must have some business skills to contribute sensibly to all these activities. I also would add, SA have to be kind of extroverted and very strong in communication. When in agreement with the customer and project team, this role can work easily part-time from remote.

Good Solutions Architect looks after technical soundness and integrity of the project the same way as good Project Manager looks after schedule and budget constraints. Of course, having a Solutions Architect for every engagement is an overkill. If the project is limited to a single implementation technology that has been proven in a similar context, it is usually enough to assign a Technical Architect or Senior Consultant. However, when technology or customer related risks are perceived as being significant, having a Solutions Architect in a project is advisable. Classified as riskier would be multiple implementation technologies, e.g. Azure IaaS and PaaS, or various parties involved e.g. an out-sourcer or other system integrators (SI’s), or unproven / innovative technology, e.g. for services still in preview or just released.

The Enterprise Architect

The Enterprise Architect (EA) looks after the whole enterprise, as the name of the role suggests, and is responsible for implementing the customers vision. Enterprise Architects are also working closely with the innovation teams to enable the transformation strategy. It includes strategic programs, which could even run multiple years, or some innovative proof-of-concepts to prepare a new technology platform like the public cloud and provide guidance for implementations. The Enterprise Architect works closely with the Solutions Architect for technical direction.

The EA is the go to person for the customers CIO making sure, the IT investments are aligned to the business strategy and speaks fluently business and business lingo. The EA is also responsible for defining standards, guidelines, and puts together the cloud governance which is required to align the implementation to meet the defined standards and guidelines. This role is a relationship role, which means it has to be on-site most of the time, also as this role could be the lead architect. Especially as the level of detail an EA can possibly take into account is quite low and superficial, so the EA has to delegate all but policy-level decisions to specialists like a Solutions Architect. The level of delegation depends on the team EA/SA and type of project, but the EA always should be included for the project governance to keep them informed.

The Technical Architect

Last but not least, the Technical Architect (TA). The Technical or Delivery Architect is usually a technology specialist in a particular solution. This person leads the implementation of technology and aims to define the best possible architecture for using that appropriate technology and has some hands-on involvement in the delivery. The TA provides technical leadership for the project team and sets standards and practices to stick to and brings expert knowledge as well as the expertise of the underlying technology and understand the strengths, weaknesses, and limitations of a solution. Generally, the Technology Architect is expected to know the various tools, the latest trends in the market, and various architectural alternatives for implementing the solution. Therefore, you can rarely find a TA doing more than one technology at once, e.g. an Azure Architect will barely lead a Windows 10 project. Also, a TA should be well connected with other delivery persons, which could act as a sparring partner to exchange ideas and scenarios.

There could be different flavors or names of this role, e.g. Cloud Architect, Infrastructure Architect, or sometimes even a Senior or Principal Consultant. Depending on the customer, this work can be delivered on-site or from remote but most of the time this is preferably an on-site job.

To conclude

In IT, the architect needs to have a bird’s-eye view of one scenario, while in the other situation the architect already needs to dive deep into the problem area. Sometimes being an architect in IT can be tough! What architects do is a mystery to many, as the work is intangible – not always directly measurable as a lot happens in the background.

Becoming an Architect isn’t just a natural career progression. That’s just about it. The important thing that one shouldn’t expect a ‘natural’ career progression through these architectural roles. A programmer with excellent skills can assume the role of Technical Architect in a project, but to become a Solutions Architect, this person would have to give up some of the control over implementation decisions. Similarly, Enterprise Architect’s control over implementation decisions is even more indirect and takes the form of policymaking and governance.

When you’re applying for an Architect position, make sure that you ask your interviews not only what kind of Architect role it is – that should part of the job title and job posting – but also what the responsibilities are and how other Architects in that same role live their role. Often, there’s a span of responsibilities and differences in how organizations have their Architects engage in projects or how they name them. Enterprise Architects are not always non-technical EA’s that speak business fluently. Sometimes, organizations live hybrids between TA’s and SA’s. So – you want to make sure that they can verbally explain to you how the ideal candidate in that role interacts with various stakeholders.

As a summary, a compact form of what has been said above looks as follows. Technical Architect works within a solution, Solutions Architect translates a problem to a solution, and finally, Enterprise Architect defines which problem needs a solution. Want to know more about architects? Have a look at iasaglobal.org, a community for all IT Architects.

There’s just one more thing…

There is an ongoing debate if the role is called Solution or Solutions Architect – with or without the S for solutions. In my opinion, the Solutions Architect is designing multiple solutions, combining various technologies and probably is engaged in various projects at the same time which sounds to me as numerous / solutions. That said, if you design solutions, run operations, or manage sales, all these roles do not drop the S. But there is no hard-and-fast rule for this. It’s an “earthing”, some sound right and others do not…