agilearchitect.gifInstead of putting them up against each other, why don’t we think of them combined? In fact, combining the two words I like the best within software, Agile and Architecture, (oh, the phrase “it works!” is still my favourite though), an Agile Architect seems like a pretty good role to have on board! But what are the characteristics of an Agile Architect?

The Agile Architect website tries to define this role and does a pretty good job with it too (http://www.agilearchitect.org/agile/role.htm).

My best way of explaining an agile architect would be to compare the role to the traditional software architect: instead of being the guy with all the answers up front, you’re the guy that find the best solution together with your team. You simply “architect” the best outcome by utilizing the people you work with. And isn’t this one of the principles of agile, people over process?

By combinging the traditional perception of an architect (drawing and designing a software system based on domain and technical knowledge) with the principles of agile devleopment (communication, working software over documentation, people over processes, customer feedback through iterations…) we get a person who:

  • Identifies the decision makers and stakeholders
  • Walks through the domain with the customer in order to understand the meaning of the system
  • Tries to identify the simplest solution that supports the user stories established TOGETHER with his team
  • Keeps the non-functional requirements in mind and makes sure they are all ready before the development commences.
  • Communicates with the development team, stakeholders and managers
  • Identifies features that can bring value to the customer
  • Enforce quality through forced tests
  • Frequent use of spikes and proof-of-concept solutions to find a working solution
  • Communicate the solution orally, written through documents and through models
  • Be a technical advisor to business solutions

So, we see the role is quite large. What’s not the agile architects job?

  • Implement the solutions himself but rather communicate or act as a peer where this is possible
  • Handle the mercantile side of the project: bill the customer, establish incentives or deal punishment in the team, or work with non-technical impediments (but rather communicate these to a project manager/coach/scrum master)
  • To know all the details of the system but rather know where and how to find them.

What differs from the “original” architect (original VS agile)?

  • Technical expert vs Know where to find the answers
  • Draw class diagrams and flow charts of the system up front VS. being able to communicate, understand the best way of communication given the current situation
  • Rely on a requirements document VS know the customer and ask the right questions
  • Make blueprints on what should be implemented VS. use spikes and proof of concepts, talk to developers through iterations to guide them to get the best possible results
  • Independent work VS the collaborative glue

So it seems an agile architect is a pretty good role to have on board. He’s the “glue” in the project that makes the development lifecycle move smoothly. But some carachteristics are needed to be a succesfull agile architect:

  • Communicate well
  • Above normal knowledge about patterns and best practice, system architecture and techical tools
  • A pragmatic approach
  • A healthy portion of realism
  • Always interested to learn and expand the horizon
  • Think outside the box as well as know what’s in the box (if you take my saying)

As a conclusion:

The agile architect in it’s simplest form is a person who understands the tasks at hand, sees the big picture and is able to communicate this to his peers and ensures a succesfull solution through team collaboration.