I recently had the pleasure of moderating a panel at the Mass Technology Leadership Council’s Building Better Products – Software Development Summit. The topic for the panel was "How to leverage Scrum, XP, and Kanban within your organization." The panel consisted of:
- Bill Buckley, VP of Engineering at Unidesk
- JP Beaudry, Director of Technology at Vistaprint
- Robert Desmarais, Transformation Consultant, Rally
It was a great panel and discussion, with a very engaged audience full of great questions. One audience member, very politely I might add, asked "with agile and self-directed teams, do we really still need architects, no offense to the moderator " (as I was introduced as a Senior Enterprise Architect). I immediately thought of one of my early blogs I wrote several years ago on this very topic, much of which I still thinks hold true, and was part of my response to the question. Below is the original blog. I think the topic and question are both valid ones. I will grant, these are my own (admittedly) biased views on the subject.
Image Source: http://en.wikipedia.org/wiki/File:Aerial_house3.jpg
Why Do I Need an Architect?
This is a question that seems to come and go over time, like the ebb and flow of the tides. Everything is cyclical, and lately the cycle seems to be rising again. How many times have you heard or been asked this question? How would you answer it? What follows is not meant to be the over arching answer, just some food for thought based on a conversation with a client and my own (admittedly) biased viewpoints.
I had the question posed directly to me recently by a client. We were charged with helping the client rebuild their IT organization in order to support continued development and expansion of their core business application. The application was over 2 million plus lines of java code that had grown organically over the past 7 year and contained a variety of different technology frameworks and architectures glued together. One of the key roles we recommended they fill was that of an architect, to which the immediate response was “We have never had one before, why do we need one now?” After resisting the urge to say “And that’s why you needed to bring us in,” I laid out my line of reasoning to him.
10,000 Foot Level, the Vision
From the 10,000 foot level, the architect has ultimate ownership of the technology vision, definition, leadership, and responsibility for the successful delivery of the system. They must be involved throughout the entire software development life cycle, not just at design and definition time. Good software development is not a bucket brigade, where the architect stands at their place in line, takes the requirement, does the architecture definition, hands it off to the development team, wipes their hand and says “good luck.”
An architect is involved from the beginning, during requirements gathering, helping to extract, define and own the non-functional requirements of a project that so easily get overlooked or are ill-defined (how often have we heard “I need it to run fast,” or “It has to be secure,” as the only non-functional requirements). Determining these early on is a critical success factor in identifying impacts on architectural decisions that directly affect performance, scalability, security, availability, and ultimately the successful delivery of the system. These are usually technical in nature, and need to be understood early on.
More Than Just Technology Decisions
The architect’s role in defining the architecture is more than just making technology decisions. The architect is responsible to provide the defining principles, overall structure, and technology leadership to the team. This is not to put process and structure in place just for the sake of it, nor is it structure that is rigid and unchanging. It is to provide the technology leadership and view of the big picture to ensure that while the individual teams are not only succeeding with delivering on their area of focus, that all the individual stories, components and modules, will come together successfully in meeting all of the functional and non-functional requirements.
As well as working with the development team, the architect is responsible for collaborating with all the stakeholders in the process, the business, quality assurance, database, support and security. The architect is responsible for communicating the vision, the impacts, and the trade-offs that result from any changes or modifications to the architecture during the development process (architectures evolve, even during the development process. The architect ‘s job is not to enforce a rigid architecture no matter what, rather they need to maintain the big picture view and determine the trade-offs required in the changes, and own the responsibility for the decision and communicating the impact to the stakeholders).
So That’s How I Got Here
While there was more to our discussion, (there was a deep discussion on what Agile development was and was not, but that’s a story for another day), the client stated “So since I didn’t have someone doing all that, that’s the reason my system is having the problems I brought you folks in to help with, is that a fair statement?” Maybe I should have gone with my original urge to just say that.