As the delivery cycle quickens, what does the future hold for our box and line drawing skills as Solution Architects?
Demands on delivery teams to get stuff done are increasing every day. No longer do we have long lead times between identifying the opportunity and needing to realise this vision in front of our customers.
But as things have quickened, what has happened to our systems design – and how do we know that what we are doing is not only going to be achievable, but will actually even work?
We have classically looked to Solution Architects to wade through the possible ways to achieve the outcome – balancing all of the aspects to try and find one that works the best for everyone. This role is not quite the customer, explaining the what it is they need; not quite the analysts, looking to explore what the customers will actually need, and not quite the developers who will make that vision a reality.
So what is a Solution Architect? What do they do? And more importantly, as times are changing – what is their role in the future?
CURRENT STATE
Wikipedia defines Solution architecture as:
a practice of defining and describing an architecture of a system delivered in context of a specific solution and as such it may encompass description of an entire system or only its specific parts. Definition of a solution architecture is typically led by a solution architect.
So the role of a Solution Architect is to describe the architecture – what does that mean? To what level does the architecture need to be described?
Classic solution architectures are focused on exploring the solution, in a way that is abstracted away from the development. This work is often done well before the people who will actually implement the solution are aware (or even hired).
Simply a Solution Architect is tasked with:
- Finding the best solution among all possible to solve the business problems
- Describing the structure, characteristics, behaviour, and other aspects of software to project stakeholders
-
Defining features, stages, and solution requirements
-
Providing specifications according to which the solution is defined, managed, and delivered.
Solution Architects work to consider the above aspects, and then look to encode their designs with tools like UML diagrams, flowcharts, sequence diagrams, and many other box and line tools.
Their role was to straddle that fuzzy line between requirements and implementation and work out how we need to get to the solution – without actually actioning the journey.
Solution designs and System Requirement Specifications were the output, and regularly resulted in 100+ page documents that then needed to be understood and then further translated into working software.
While Solution Architects would like to think that these documents created clarity for development teams – more often than not they were quickly looked at by developers and then silently filed in a drawer never to be looked at again.
THE CHANGING ROLE
There is a growing trend in software development that sees the dedicated Solution Architect as a dated role, one that comes from a time where requirements were valued more than working software – where too much time was spent thinking about the solution, and not enough time working on the solution.
But times have changed, feedback cycles have increased, we can now try things rapidly – removing any ambiguity of if something works or not to validate actual impact.
It’s not to say that we should not be considering good design – but we have started to notice that encoding system behaviour in Word documents does not create a good interface between the systems requirements and actual working code.
Software development has been moving towards smaller batch sizes, written ‘as code’ – but also described ‘as code’, and verified ‘as code’.
Software development uses practices such as Test Driven Development, Contract Testing, even Behaviour Driven Development as ways to describe requirements and expected behaviour as code.
These tools go a long way towards reducing the need for detailed and exhaustive requirement specifications.
As we start to decompose our systems into smaller functions of work, and teams are challenged to reduce their batch sizes and work in progress, the time available to consider deep architectural principles just doesn’t seem to be there any more – any architectural consideration needs to generate workable, constantly validate-able and consumable code.
With teams now moving from Word documents towards code for our requirements – what does the future hold for the Solution Architect role?
THE FUTURE?
Like all modern development practices, the role of Solution Architect is undergoing some radical changes; our responsibility here is to not throw the baby out with the bath water.
By no means should we be ignoring good design – but we should not be spending weeks considering a solution just to encode it in a set of diagrams and Word documents.
The time of having dedicated Solution Architects in teams is ending – but the need for good solution architecture does not go away. High performing teams recognise that they need to be able to respond to rapid changes from customers, the ability to innovate and validate their assumptions, all while still maintaining a high standard of quality. All of these factors require a good solution design, that understands modern practices and delivery patterns.
Good design, good practice and good process are even more critical if the teams are working in a DevOps way – having operational responsibility for production requires a mature team that can quickly respond to production incidents.
The dedicated Solution Architect role is being filled by more hands on team members, be those Delivery or Technical lead roles, or even just simply a set of experienced Developers.
By recognising that requirements can be code too, our teams become even more cross-functional, no longer is the divide between requirements and solution one of document to code – but all now have the ability to define our system requirements as code.
We live in an ascode age, where the value of code:
- Is easily repeatable – reduces human error rate
- Clearly defines what needs to be done – removes ambiguity through clear definition
- Becomes a living part of the system – not a requirements document stored away and never read
- Built to be constantly validated – easily integrated with the same tooling as we use for development
- Can easily be version controlled – allows us to see when and why things changed over time.
With any transformation, the structure of the work changes – but the work itself still remains, just in a different form. This is exactly the same for solution architecture – we still need to design and plan for effective delivery, it’s just that this skill needs to work in compliment with the actual delivery and execution of the plan.
For box and line Solution Architects, now is the time to evaluate the required complimentary skills and get learning. We live in a time where anything and everything you could want to learn is available – you only need to look.
More and more dedicated Solution Architects will be replaced with polyglot team members – those who have good experience developing the solution the right way, but will also need to know if it is the right thing – and most importantly be able to roll their sleeves up and make it happen.
