At work today I was asked to interview a candidate for an enterprise architecture role. I had to fill in for someone else, so barely had time to read the candidate’s CV before the interview began. My first surprise was that the candidate was being quizzed on his knowledge of adaptive case management software. The second, that he had fewer years’ experience than I do (I’m a solution architect).
I come across this phenomenon often (non-technical managers hiring for a technical role). Similarly, I've met many technical people who either don’t understand architecture, or just like the sound of a cool job title. My favourite though, is the recruitment agent that breathlessly describes an enterprise architect role to me and consists of no more than managing a team of servers and developers (with emphasis on the servers).
In this post I explain what architecture is, and describe the most common architecture roles.
Architecture in the computing world consists of a system’s elements; the relationships between those elements; the attributes of the elements; and the attributes of the relationships. Simplistically, the architect's job is to identify, design and document these elements, relationships and attributes.
Now that we know what architecture is, let’s look at types of architecture, often called roles:
Going from the inside outwards, you could view this as a (possible) career path for architects. Going inwards from the outside, you might consider this a sphere of influence. It follows that an enterprise architect is more experienced than an application architect.
Now, bearing in mind that the definition of architecture doesn’t change – regardless of the role – let’s look at what the roles shown above actually do. Note that I use arbitrary examples. They serve only to illustrate the point.
Computer programmer or Systems Administrator
This is what architects do before they become architects, which is why these two roles are shown with dotted lines. Many programmers dislike the term, and might call themselves developers or hackers. Similarly, the term Systems Administrator is used loosely. It refers to any entry-level infrastructure role, be it networking, application administration, security, and so on.
Product architects, regardless of the stream (programming or infrastructure), are people that know a single product (for example .NET, or Active Directory) really well.
In the .NET example, the product architect will know Windows Forms, ASP.NET, WCF, Workflow Foundation, WPF, and the .NET Framework really well; design secure, robust distributed systems that scale, using these technologies.
The Active Directory example might apply to someone who knows how to install and configure Active Directory, design and implement a forest and domain structure, design an organisational unit (OU) structure, determine domain controller placement, the number of domain controllers, global catalogue placement, and be able to design and implement cross-domain trusts.
Product architects have narrow, focused and deep technical knowledge of their field, and are what many refer to as subject matter experts, or SMEs.
Application or Infrastructure Architect
The application or infrastructure architect knows multiple, but related products within the programming or infrastructure stream, respectively.
For the infrastructure stream this might range from IP networking and Active Directory to LDAP integration using identity federation, SendMail, Exchange, F5 BIG-IP Local Traffic Manager, Unified Access Gateway, and Juniper Networks’ Pulse Application Accelerator.
Application and infrastructure architects are a logical evolution of the product architect – they’ve added technical breadth to their technical depth. Such architects are often called technical architects.
Solution architects represent the architectural convergence of the programming and infrastructure streams. Solution architects are as comfortable designing a virtual network for a DMZ as they are designing static structures and sequence diagrams for an insurance claims management system.
The solution architect has many years of experience to draw on, and has also mastered the soft skills required for the role. In addition to their technical abilities, solution architects are leaders, domain experts, politicians, and strategists.
When talking about architects, solution architects are the type that most organisations want, even though they often call them technical architects or enterprise architects.
The modern enterprise architect is an interesting animal. He no longer needs to possess technical depth in any area, let alone breadth. Indeed, the enterprise architect may have a highly technical background, or may never have held a technical role at all. This is because enterprise architects create, document or manage a description of the structure of an enterprise.
They describe the domain language (the terminology), the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement, design, and evolution of an enterprise. They are interested in strategy, of which the tactical nature of a solution architect’s project is but a small part.
A trend I've seen in the last decade or so is for enterprise architects to also define and assist in assurance and governance functions, and increasingly to contribute to business process engineering.
As you can tell, the enterprise architecture role is just as suited to an MBA as it is to a BCompSc. Progression from this role usually leads to chief technology - or chief information officer roles.
Using the definition of architecture as a point of departure, I described some of the more common architecture roles, from product– to enterprise architects. There are others, though.
A DBA, for example, might become a data architect. A user experience designer might aspire to information architecture. Similarly, a business capability architect might become a strategy architect, which leads to enterprise architecture.