All these architects – where does the modern software architect fit in agile?
What is a software architect these days? How much value do they actually bring? Are they needed?
I have been asked all these questions in the last few years. Having been in that role or one of its various guises, it’s also made me initially question where the value is, if so many people perceive its lack thereof in agile projects?
Software architects, solution architects, agile architects, enterprise architects, chief architect, lead architect, platform architects, I’m pretty sure I have probably missed some others.
What is an architect? The agile architect!
I wanted to address this question, what is an architect these days?
With the majority of projects having migrated from a waterfall based development process to SCRUM, has the traditional software architects role significantly changed? Businesses are looking to provide value back to customers faster and have embraced agile to allow a rapid feedback cycle.
If you look at the process flow in waterfall this should not impact overall on the core responsibility here. Translate those business requirements in to a design that can be developed. The key difference is the design is smaller and perhaps only covers the next few sprints.
So in the age of delivering quality features faster to production with small amounts of incremental design, is the actual concern from developers the role of the “hands-off” architect? If the design is ready, stories are defined, the team is experienced and ready to begin. What do they do for the rest of the time?
The culture within the organisation and the product will somewhat determine this outlook.
How much value do they bring?
Microservices is the new buzz word that when taken to its far extreme, depending on interpretation, could lead to independent teams using different programming languages, different standards and different governance. All those years of recruiting Java developers, putting corporate coding standards in place and ci/cd pipelines. I’m doing microservices so now we are free to choose whatever tools we want. This may be sensible but is it the architect who has to taken on ownership for the following:
- aligning team standards to corporate and varies only where needed
- ensure tooling aligns to corporate standards and varies only when needed
- what about choice of libraries?
In experienced teams this may be ok, but far too often tooling is picked for technologies sake rather than true business value. The quest is to learn, and in technology if you don’t self learn then you will fall behind.
So far though we are still within the realms of one team. What about all teams across the organisation how do you ensure shared knowledge, understanding and a consistent delivery approach if no one is looking at what the organisations needs are. You could build the same functional components across many teams satisfying the same requirement.
Depending on the project and/or the organisation you probably need to ask yourself the question of what would I lose if this role wasn’t there.
Architecture has always suffered from synchronisation issues with the implementation. @simonbrown is trying to address this very issue with coding the architecture. Striving to align your code with your implementation is invaluable when it comes to real time documentation. Documentation is in git, mavensite etc, version controlled and alongside the code. Code reviews can be governed for doc updates, standards can be checked to ensure this is aligned to doc generation patterns. No matter how much effort is put in to manually amending high level designs it inevitably falls out of sync.
More and more frequently I’m told the code is the doc, checkout the repositories. The code is the reality, let’s not kid ourselves here but personally I learn visually so I would end up drawing this in UML.
Perhaps this Agile architect role specification is now exactly what we have always strived for.
Its a lead developer, technically competent, has knowledge across the business and can ensure technical and commercial governance inline with other teams. Can produce just in time designs, help identify areas of reuse at a low level. Drive the teams they work within and be a strong mentor and listener.
At this point though who is identifying future trends and ensuring the business has an IT strategy in place to succeed? Even in most product companies today the software architects are translating the business requirements they have today and for the next few months; what about the next 6–12 months? Or few years? Software architecture is evolving, we are trying to deliver faster, market conditions are changing. If we stick to delivering what is in front of us without this strategy in place how will we ever succeed?
Recently I started looking in to company strategy. I came across wardley maps. @swardley has blogged and presented a number of times on this subject and has some really useful information. I’m currently looking at whether or not this can help build an IT strategy.
I will follow up this post with a detailed description of how relevant the enterprise architecture role is within most organisations today. Hopefully I will be able to feedback on my attempt at understanding wardleymaps and if I can apply it to an IT strategy.
Do you need an architect?
There aren’t many formal definitions of the software architect role in agile. Small, short lived projects with a small number of teams can likely survive without the roles . Once you take this to an enterprise level and an evolving product, lack of architecture can cause significant problems within the IT strategy.
How many teams these days look at a user story and start developing without any design? Rapid prototyping may work on senior teams but without any kind of direction the project can suffer.
One key aspect is that the shift has been away from the hands off architect to the hands on. The architect will sit with the team and typically be expected to deliver code as well as design. Helping work the backlog, refine stories and align with other technical and business authorities in the organisation. This needs to be viewed as a positive step and not a negative.
Technology and tooling is changing at such a speed if your not going to be hands on at some point are you putting yourself at risk of being out of touch?
