This shouldn't start any spirited debate. Attempting to define software architecture. It's only been debated and discussed for as long as the title "Software Architect" has existed, but recently, it's become a curious role. As software processes compress, relying on agile iterations and continuous deployment, the boxes in the process charts that were typically where the architect reigned supreme are shrinking and disappearing. What then becomes the role of the architect? Do they disappear completely?
The real question is what is the role of the architect in the larger view of the organization. I believe that architects are responsible for ensuring both technology and processes will meet the business needs as effectively and efficiently as practical. Practicality of course is an ever present constraint because no company has infinite time and resources to apply to their platforms. They need to ship capabilities that bring value to customers or there is no business.
That is certainly simple enough to state in broad, general terms, but what does it mean in practical, actionable terms. For me, it comes down to two major jobs.
- Provide consulting and guidance on the iterations to ensure they are staying within parameters that will let the organization evolve over time.
- Be strategic and far enough out in front of the current product iterations that you can guide the teams as they evolve.
This is a shift from the way architecture used to work. Architects need to be come more agile as well, viewing themselves as a service to the engineers rather than mandating approaches. Let's explore each job a bit further.
Architects as Consultants
The role of architect in most organizations involves working on big designs, setting the top level component structure, and reviewing the work of engineers to ensure that the solution conforms to a set of company standards. The architect lives in the upper portions of the organization which places them in areas of broader authority than the engineers responsible for implementation. The architect also has more responsibility and accountability, so broader authority would seem appropriate. This works reasonably well when an organization is following a traditional waterfall methodology. But, it's become clear that waterfall doesn't serve any constituent of the business particularly well, which is why it's being abandoned in favor of agile.
With agile, you've conceded you won't think of everything up front, so solve the problems you do understand, and iterate. This changes the job of the architect drastically. Now the job changes from ensuring the perfect architecture up front to identifying the boundaries of the architecture and ensuring iterations stay within those bounds.
In the past I always viewed architecture as laying out the components and their dependencies. The result is a nice box that everything fits in neatly and allows a system to be built that lives within the box. Now I view architecture as a pair of fences that stretch on infinitely. My job is to set the fences far enough apart to let software engineers be successful during their iterations but close enough together to protect the present and future of the business. I worry less about what's between the fences because that will change frequently as the platform evolves through iteration.
Shifting to that perspective changes the role from one of governance and mandates to one of consulting. The architect works with the engineers to help guide iterations to stay between the fences, but relies on the engineers to define components based on the best knowledge they have at the time. Ideally components are relatively persistent and evolve over time, but in some cases, they may be combined or split as the product evolution dictates. What used to be considered pure architecture now iterates as well and the architect is most effective as a consultant instead of commander during these iterations.
Architects as Strategists
Carrying my visualization further, if the architect is responsible for laying the fences that engineers iterate between, they have to know where to place the fences. The only way to be successful at this job is to know where the business is heading. More than just knowing the current business strategy, it's important to follow technology trends to help the business understand how new technology might influence strategy.
It is important therefore for architects to constantly seek and assimilate knowledge. The rate at which technology changes has accelerated in the past 20 years dramatically. The evolution of technology requires refreshing solutions every 3 to 5 years or organizations run the risk of being out paced by competitors. Design patterns and processes evolve quickly to keep pace with emerging technology. Architects need to ensure they are keeping the business current and relevant in their market.