The Difference Between Enterprise and Solution Architects

I'll preface this topic by stating up front that very often Solution Architects (SA's) and Enterprise Architects (EA's) are the same people. There's no reason why EA's and SA's can't fill each other's roles and in fact this happens quite a lot. Having said that though, there are differences between the type of work you'll be asked to do as a Solution Architect from the tasks you'd be asked to perform as an Enterprise Architect. It is also important to keep in mind that both roles share common skill-sets which is why both roles can be grouped within the umbrella title of "IT Architecture."

We'll start by providing some definitions:

1. Enterprise Architect  -  An Enterprise Architect is someone who is charged with helping to define cross-domain capabilities and solutions for an organization (or in some cases just documenting them).  An EA is definitely a big picture role - one focused on how issues, projects and systems relate to one another in ways that aren't immediately obvious to those working within the context of individual projects. EA's are often also asked to establish, populate and otherwise maintain enterprise architecture / knowledge repositories.  These enterprise architecture resources are used as a Reference Framework or starting point for all other IT activities (when it's done properly, that is).

2. Solution Architect - A Solution Architect is someone who is charged with defining and usually implementing specific technology solutions.  This role is often referred to as a Project Architect, but can just as easily apply to any type of IT resource referred to as an "Architect" (e.g. Data Architect, SharePoint Architect, Security Architect etc.). The SA role is more focused on software development lifecycles (ALMs) than the EA and is often tasked with following a solution throughout that entire lifecycle (be it months or years).

If these definitions sound a bit open-ended, they are - but that's primarily because this is how they're viewed by employers.  The SA role in particular is fairly hard to pin down because almost any IT specialty these days can have an "Architect" role assigned to it. As the SA role becomes more technology-specific, it moves further away from the generic vision of an IT Architect who could conceivably move back and forth between and SA and EA roles. For those who aren't completely invested in one specific technology though, there does exist a common set of capabilities or skills that both EAs and SAs tend to share:

• Problem-solving or analytic reasoning - This is often referred to as "Critical Thinking" but unfortunately academia has never quite standardized what that means. For our purposes, "Problem-solving" refers to the ability to apply one or more problem-solving methodologies to bear in order resolve any type of technical issue (it can be a personal problem-solving approach or one associated with any number IT methodologies). 
• System Engineering Skills - Often times people lose sight that architecture is in fact an engineering as a well as design-focused discipline.  Systems Engineering helps provide the ability to think through constraints, dependencies and relationships. It also provides valuable insights into how standards are developed and deployed.
• Design Thinking - This is a bit of a buzz-word but it helps to emphasize the creative nature of architecture. Analytic and System Engineering skills will only take you so far; creativity brings you the rest of the way.

Any Architect who works or has worked across multiple technologies, either as an SA or EA will have equal application of the skills listed above. The number one skill though for any EA or SA is this - the ability to take those common skills and apply them to an entirely new technology or problem.

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc