When I first started my career as a fresh-faced graduate developer over 20 years ago, the position of architect was usually given to developers who were considered ‘too senior’ to continue writing code. I have, however, met many a developer throughout my career who didn’t want to be an architect and were quite happy to continue coding. In any case, most architects came from a development or technology background and were ex-coders. They knew how to build solutions properly and review what others had built, they had been there and worn the t-shirt.
Much has been written and said on the role of the architect since then. We’ve had emergence and maturity of frameworks, methods and patterns. We’ve had game-changing technology milestones, a fundamental shift to understand technology-driven business and functional enablement and a move to new data modelling techniques and non-relational structures. I’ve watched and, in my own small part, been part of this journey as the architect adapted in thinking, in organisational position and in skillset.
Architecture became a true discipline and career, not only for techies looking for their next gig, but for people from lines of business too. Architects still wore the t-shirt most of the time, but sometimes had to wear a suit too. Spoiler alert, the architect’s wardrobe is changing again.
Ways of working is an area that has changed significantly too. Waterfall, iterative development, Agile, Scrum, Continuous Delivery, Product-driven… the list goes on and is a blog in itself, but in line with some significant advances in technology, organisations are now more and more shifting towards continuously delivered, iterative solutions. In financial services this is fairly new. So, what does this mean for the architect now? Are they even needed anymore? The answer to that, in my opinion, is one of organisational position and of perceived role.
In many large organisations architects often sit in a design function, their role to build designs and write documentation required for a project to deliver against a set of requirements. For large projects this can (rightly) take a while to do, to make sure all requirements both functional and non-functional are met, that all the nuances of a complex architecture are understood, that standard patterns are followed, that principles are adhered to. These designs will be scrutinised, debated and approved by peers, in a formal, audited forum. After which, the design is passed to engineering to deliver against the design, QA to test the end-to-end solution and production support to monitor and operate. This Waterfall style approach works fine for some types of delivery and there is nothing wrong with that. When you start to shift towards something that is more iterative in nature, accepting evolving requirements and continuously delivered solutions, the way the architect approaches a problem must change.
Firstly, it must change in regards to organisation. In a world where teams work together on problems, living them day in and day out, often in production, the architect needs to be able to do that too. Organisational structures and reporting lines that don’t allow for this mean that architects are not close to the decisions being made, why they’re being made and how they affect the overall architecture. It is important to recognise that architects can only be effective in these situations if they are able to adapt designs and thinking as the product evolves and that the team will accept and trust such decisions if the architect has been along for the ride. Everyone wears the same t-shirt.
The role changes subtly too. Long periods working on designs, recording everything in detail, debated with your fellow architects just doesn’t work in this fast-paced, constantly evolving world. Yes, there is still need for audit of course, and never fear, there is still room for debate but an acceptance that not everything is known in advance and that teams may need to adapt a design as they learn is important. Providing those teams freedom to deliver the product is important but the architect has a remit which is wider than one team, so as a consequence has the ability to spot overlap, to know where a problem has been solved before, to introduce teams to initiatives happening elsewhere in the enterprise. This is a valuable commodity.
It isn’t that the teams are delivering without any architectural coverage either; there is a strategic direction, a roadmap for the product, non-functional requirements are established, and standards produced. I also don’t agree with the view that all architects must now be engineers. It is true though, that new technology advancements have helped enable this change, particularly that of Cloud native architecture and methodology such as DevSecOps, the architect should understand and adapt to these too. Time to don the Silicon Valley branded hoodie, then.
In summary, the role of the architect is, and always has been, one that is constantly evolving and adapting to achieve the right outcomes, in the right way. I for one continue to really enjoy that part of my job and I’d like to think in another 20 years I will come back to this blog and the role will have changed once again. I look forward to that very much. Hopefully though, I will have a new wardrobe by then.