Jelle Druyts

I've been doing quite some thinking about my role in the IT business lately, and a few recent posts have accelerated this even more... First, we have Joris Poelmans sharing and aggregating some thoughts about architects, architecture and the different types of architects (architect personas, if you will). And then we have Hans Verbeeck pointing us all to the Skyscrapr site, which is a site that serves as "your window on the architectural perspective".

All of these categorize architects in different roles in the business. Generally speaking, there are three personas most people seem to agree on (with my highly summarized descriptions that don't do the original posts any justice):

• Enterprise Architect: responsible for the long-term strategic vision, thinking about the big picture together with the business and technical people; sets the direction for methodologies, frameworks and tools.
• Solutions Architect: responsible for the design of applications and services within (part of) an organisation; works closely with the developers to make sure the goals of the business are achieved.
• Infrastructure Architect: responsible for the data center, deployments and maintenance; makes sure the infrastructure on which the business applications run is reliable, manageable, scalable, performant and secure.

Since you're never only one of these profiles, Simon Guest adds to this idea by positioning yourself somewhere in the triangle formed by these personas, to indicate your relative strength in one particular area. If I were to call myself an architect (and sometimes - not only in my sleep - I do), I think I'd put myself somewhere here:

So I believe I'm mainly the Solutions Architect: driving the technical solutions to meet the business' needs. The problem for people that are in the consultancy business - like me - is that all these roles are defined within the boundaries of the enterprise. All of them assume that you are effectively part of the business. Since my role is typically shorter-term for each individual client (providing guidance and experience in the technology field rather than in the actual business domain), I often don't need (or want) to know too much about the actual business. The benefits of me having intimate knowledge about it are negligible most of the time, both for myself as for the customer.

So in that regard, I'd like to propose the term Technical Solutions Architect to describe what people like me do: this role involves setting up technical architecture, guidance, frameworks and documentation, performing code reviews, coaching, deciding on programming languages and technology stacks - all within a certain horizontal technical scope that may or may not be aligned with any vertical business structure.

What do you think? Would you agree? What role do you think you are?