Agile Zone is brought to you in partnership with:

Brian has 10+ years of experience as a technology leader and architect in a wide variety of settings from early startups to Fortune 500 companies. With experience delivering SaaS solutions in business intelligence, artificial intelligence and VoIP, his current focus is big data and analytics. Brian leads the Virgil project on Apache Extras, which is a services layer built on Cassandra that provides REST, Map/Reduce, Search and Distributed Processing capabilities. Brian is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

WTF is an Architect Anyway?

01.11.2014
| 4049 views |
  • submit to reddit

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. =)
Published at DZone with permission of Brian O' Neill, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)