Thursday, January 9, 2014

WTF is an architect anyway?

In full disclosure, I'm writing this as a "Chief" Architect (I can't help but picture a big headdress), and I've spent the majority of my career as an "architect" (note the air quotes).  And honestly, I've always sought out opportunities that came with this title.  I think my fixation came largely from the deification of term in the Matrix movies.

But in reality, titles can cause a lot of headaches, and when you need to scale an organization to accommodate double digit growth year over year, "architects" and "architecture" can help... or hurt that growth process.  Especially when architecture is removed/isolated from the implementation/development process, we know that ivory-tower architecture kills.

This day and age however, a company is dead if it doesn't have a platform.  And once you have a critical number of teams, especially agile teams that are hyper-focused only on their committed deliverables, how do you cultivate a platform without introducing some form of architecture (and "architects")?

I've seen this done a number of ways.  I've been part of an "Innovative Architecture Roadmap Team"' an "Enterprise Architecture Forum", and even a "Shared Core Services Team".  All of these sought to establish and promote a platform of common reusable services.  Looking back, the success of each of these was directly proportional to the extent to which the actual functional development teams were involved.

In some instances, architects sat outside the teams, hawking the development and injecting themselves when things did not conform to their vision.  (Read as: minimal team involvement).  In other cases, certain individuals on each team were anointed members of the architecture team.  This increased involvement, but was still restricted architectural influence (and consequently buy-in) to the chosen few.   Not only is this less than ideal, but it also breeds resentment.  Why are some people anointed and not others?

Consider the rock-star hotshot developer that is right out of college.  He or she may have disruptive, brilliant architectural insights because dogma hasn't found them yet.  Unfortunately, this likely also means that they don't have the clout to navigate political waters into the architectural inner circle.  Should the architecture suffer for this?  Hell no.

So, what do we do?  I suggest we change the flow of architecture.  In the scenarios I've described thus far, architecture was defined by and emanated from the architectural inner circle.  We need to invert this.  IMHO, an architectural approach that breeds innovation is one that seeks to collect and disseminate ideas from the weeds of development. 

Pave the road for people that want to influence and contribute to the architecture and make it easy for them to do so.  In this approach, everyone is an architect.  Or rather, an architect is a kind of person: a person that wants to lift their head up, look around, and contribute to the greater good.

That sounds a bit too utopian.  And it is.  In reality, architectural beauty is in the eye of the beholder, and people often disagree on approach and design.  In most cases, it is possible to come to consensus, or at least settle on a path forward that provides for course correction if the need should arise.  

But there are cases, when that doesn't happen.  In these cases, I've found it beneficial to bring a smaller crew together, to set aside the noise, leave personal passions aside, and make a final call. Following that gathering, no matter what happened in the room, it is/was the job of those people to champion the approach.

In this capacity, the role of "architects" is to collect, cultivate and champion a common architectural approach.  (pretty picture below)

To distinguish this construct from pre-conceived notions of "architecture teams" and "architects" (again, emphasis on the air quotes), I suggest we emphasize that this is a custodial function, and we start calling ourselves "custodians".

Then, we can set the expectation that everyone is an architect (no air quotes), and contributes to architecture.  Then, a few custodians -- resolve stalemates, care for, nurture, and promote the architecture to create a unified approach/platform.

I'm considering changing my title to Chief Custodian.  I think the janitorial imagery that it conjures up is a closer likeness anyway.   Maybe we can get Hollywood to come out with a Matrix prequel that deifies a Custodian. =)


Daniel R. Hanawalt said...

A definition of architect from Google: “…a person who is responsible for inventing or realizing a particular idea or project.” Emphasis here should be on the word responsible. Being responsible for something implies leadership and organization.

Great ideas and projects are almost always a collaborative effort and are usually built on previous ideas & inventions, but all require solid leadership in order to come to fruition. Leadership, in this case, is not focused so much on personnel as on information. So, to answer the question posed in your blog post title, I believe that an architect is someone who knows how to collect and organize information in order to design an optimal solution to a given problem.

This is a challenging role, and I disagree with the 'custodian' moniker. What does a custodian do, but clean and maintain something - whether that be a building or a collection of ideas? An architect is expected to do much more than that, hence the temptation to wander into 'ivory tower' territory. This is more of a side effect of human nature than anything else. We all have an inner asshole desiring to be unleashed...

My belief is that architects providing leadership to dev teams can absolutely be successful no matter how they're organized. The key is having a team of humble, empathetic, and dedicated individuals. That is the difficult part, but when it does happen it's magical.

Table Tennis said...

Nice article Brian! Your thoughts are exact reasons why I took the next step in my career out of architecture. In models that you describe, and which occur too often in my experience, architectural vision need to be recognized and accommodated by the product management teams. Otherwise, it falls along the same line - gets tangled up in many almost bureaucratic activities.

Architecture cannot be a byproduct of development. Its a committed direction. It also cannot be undermined by extreme pressure from product management to get things done asap, when teams, even with embedded architects begin to function on autopilot, losing a site of a big picture and pushing all necessary platform efforts aside.

So, my proposal to fix integration of architecture with teams is from a product management vision. If product management flushes the business out with architecture and develops a proper strategy that takes architecture as the basis of the strategic growth, then development does not have to come up with architecture on the fly. In this scenario, agile teams will truly shine.

Brian said...

I think we're going to need a couple of pictures to make sure we fully understand you: one of you making these "air quotes", and the other of you in janitorial garb.

Rangarajan Suresh said...

What is in a name? And why does it matter? If we set aside the philosophical aspects of the greater good for a moment, the name/title is relevant if you consider the number of years many of us spend in this industry. Without that distinction, the seasoned professional in the field will not make much more than the rock-star hotshot developer that is right out of college. Being human, I would resent that. It is bad enough that in this internet age there are inane ideas that have made people millions.

But that is not to say that if there are really good ideas from any source, one should not use it. In that aspect I would agree with Daniel about the architect and the responsibility.

peterjohn said...

Pretty good post. I just came across your site and wanted to say that I’ve really enjoyed reading your posts. In any case I’ll be subscribing to your feed and I hope you will keep a good work!Cheer!

sap online training
software online training
sap sd online training
hadoop online training

peterjohn said...

This is one awesome blog article. Much thanks again.
I really enjoy the blog.Much thanks again. Really Great.

oracle online training
sap fico online training
dotnet online training