Sunday, February 28, 2010

Segmenting Architects

Continuing my examination of the architect role I think we need to point out there is not one architect role my several. There is no such thing as an “Architect”, only an “Architect of something.”

Rather than talk about an “Architect” with one word we really should use two words. The first word describes what they are an Architect of, and the second, well thats the word “Architect”.

Some examples should help:

An Enterprise Architect: One who is concerned with the systems of the enterprise as a whole and how those systems fit together. By definition this architecture in the big and it means making architects at the grand level and not being concerned about details.

So: the Architect might rule that all new systems should be in Java, and not C# but they should not concern themselves with Java coding standards or which design patterns the Java developers are using.

A Solution Architect: these architects get involved in the early discussion about what the solution will look like. They may be responsible for sketching it, they may devise a prototype, they may be involved in customer conversations around requirements because you don’t know what you want until you see the solution; and this means they have some business acumen.

You might say these are the guys who have the initial vision for the final product. Importantly though: they need to stay with the development from start to finish. They can’t walk away once they have sketched out the initial vision. They can hand over to someone else with time but they need to keep skin in the game to have legitimacy and so they learn how effective their solutions were.

Ideally, when you start working on a product/project you want one of these guys involved but you want them to change hats as the work increases and become: a software architect.

A Software Architect: This is were my interest really lies, these are the guys who are custodian of the design vision for a piece of software, or application if you prefer. They are responsible for ensuring the whole team shares the same idea of how the software is designed. As such they are more responsible than most for how the software looks (inside) now and in the future but they are not solely responsible. Software Architects should have more experience than other team members but their responsibility is to lead through teaching.

Software Architects must implement, they need code under their finger nails if they are to retain their knowledge and legitimacy.

Their work includes:
  • Being a Senior Developer, hands on, they should have code under their finger nails
  • Educating junior developers, sharing their knowledge, mentoring, teaching and training
  • Guiding development towards a consistent and sustainable architecture
  • Holding responsible for the shared technical vision and ensure it is shared
  • Dealing with Conway’s Law: interfacing with non-technical manager types to ensure the technical and organisational architecture are compatible
You might like to note I’m not saying they create the design, they do not. Their responsibility is to help the team create a shared understanding which is the design, and then become custodian of that vision.

I’ve avoided mention of roles like Network Architect, these might well exist but not always. Maybe you can think of some more architects in your organization.

I’m also avoiding the term System Architect because you have to define what you mean by “system” - where does it start and where does it end? Potentially System Architect is “Architect of Everything”.

These roles will also vary by organisation size. In a large organisation you might find these roles exist as distinct roles, in small organisations they are likely to overlap. So an Enterprise Architect also needs to do some Network Architect.

This is understandable but problems come when one individual is so busy wearing many hats that they neglect some aspect of one of the roles. They try and do two or more roles and end up doing one (or all) badly. Consider an Enterprise Architect who combines his role with being a Software Architect at the same time. If the Enterprise aspect dominates they may neglect involvement with coding the application so they cannot speak with experience about the application. Or, the other way round: they are so busy being a Software Architect that they don’t keep up to date with emerging trends and neglect the Enterprise side.