Interview with Steve Read
Dive into the mind of Steve Read, the "accidental" architect who stumbled into his role and then intentionally redefined it. Forget rigid blueprints; Steve champions a team-centric approach, using analogies and real talk to break down complex systems. Discover his ACED model, his take on AI in architecture, and why knowledge management is your secret weapon. Whether you're a seasoned architect or just starting out, Steve's journey and insights will challenge your perspectives and ignite your architectural spirit.
Where to find Steve:
What inspired you to become an architect?
I became an architect by classification rather than job application. I took on a team leadership role and at a similar time became a line manager. In both roles I ended up applying many skills needed by an architect. It was only when in retrospect I realised how many technical decisions outside of my direct team I was not only influencing but driving that I started to recognise that I had become an architect.
Was there a defining moment or project early in your career that shaped your approach?
The defining moment for me was probably reading the agile manifesto, in that it set the scene for how I would work with people, and eventually end up working across teams. To be able to solve complex problems we need to work together, and that becomes even more critical when working in architecture.
How would you describe your architectural philosophy in a sentence?
Make architecture a team sport: cut down the jargon, use analogies, examples, and talk to people.
Can you walk us through how you approach a new design project, from concept to completion?
The most important part is getting access to the stakeholders, to understand the domain, and the intent. Keep asking why. Discover surrounding architecture - teams and systems, both in development and operation. Discover constraints and standards. You now have your context.
That opens the door to creating high level user journeys and process flows. Do these collaboratively with your stakeholders. Think about scenarios, personas, and about the diversity of what is needed to solve the intent. Draft your design and start running through it with your scenarios and personas. Keep redrafting. Focus on speed of feedback. Think about responsibilities, dependencies and how existing processes and systems fit in. You now have your design.
Your design lets you assess opportunities to bring technical strategy to your solution. Determine your priorities in decision-making, and consider those alongside your constraints. Think about non-functional requirements and how these impact parts of your design. Keep redrafting your design to improve how you handle the non-functional requirements. Consider how this maps to components - what libraries and frameworks will you use? Why? How will you split your implementation into modules and services? This is your architecture.
Finally we have engineering, how the system is realised. This isn’t a block of time but will develop after and alongside various architecture decisions. Prioritise your attention on the most risky or least understood aspects of the system, and get end to end with a high value scenario.
Revisit these activities multiple times, adding granularity, scenarios and feedback as you go. This is the ACED model. It describes the modern processes we go through creating software. Can developers and architects cover all the ACED activities within their role? If they can, it is a good indicator that we are creating a modularised system. If you cannot, you have to work harder on aligning across the activities.
What’s the biggest challenge you’ve faced in a project, and how did you overcome it?
I’m still only part way through it! I am helping within a multi-year IT transformation. I am operating two or three levels removed from the people who I am trying to influence. I am working across reporting lines, departments, business processes and suppliers. There are tens of teams, incorporating hundreds of people.
Overcoming the challenge has been through establishing regular touch points with the teams - creating collaboration opportunities, not reporting gates. We all come away better understanding constraints, options, and business intent. We make better decisions as a result, and discover new problems, too.
How do you balance creativity with practicality in large-scale projects?
Team structure - your organisational architecture - has a huge impact on your opportunity to be creative and to feel engaged in the creation of your solutions.
Cohesion and coupling apply to teams as well as software, so beware of how hierarchies of leadership inside and across teams can impact both autonomy and agency to investigate those creative opportunities.
Make collaboration easy. Set constraints and define processes instead. Foster transparency. Ensure teams are working on cohesive outcomes and think about team power imbalances and the artificial constraints they can introduce to your systems.
What inspires you most in your work as an architect?
When we make progress in architecture it feels like you have done a charitable deed - like you earned somebody a free meal, or you helped somebody find a bargain. Architecture lets your organisation and coworkers do more for less, boost business outcomes, and reduces risk. That’s the payout for your effort, and is much more valuable than the simple analogies I provided.
The opposite feelings also apply, where you aren’t able to make that difference: when you’re too late, or forced by constraints down a certain path.
Who or what has had the biggest influence on your thinking and approach to architecture?
Jacqui Read. We have done a lot of sparring over the years, and often we are both right in our own ways. Sometimes it isn’t about reading something to learn - it is about going through experiences and processes to learn instead.
What trends do you think will define the next decade in architecture?
The accelerating pace of change in technology is universally understood, but if you have been following the domain-driven design community, you will have seen significant evolution over the last 20 years. I expect that to continue, but as a business-friendly DDD, with more accessible language and highly tailorable techniques. What I don’t expect to happen though is for it to get widespread adoption, as people aren’t motivated to learn those sorts of skills, and therefore don’t prioritise them. Traditional architect traits aren’t mainstream either, so I don’t regard lack of widespread adoption as failure, just as being part of the world we live in.
How AI is shaping modern architectural design?
In the places I have seen LLMs being used in the architecture process (generating decision records and other documents) it has caused more damage than good, completely losing the intent and architectural process.
On the other hand, in places where machine learning and LLMs are being used as components in architecture, we have to rethink what is possible, but we also need to make decisions with our eyes open - what are the tradeoffs with each approach? Do you need an unbiased deterministic process? We should start defining an architecture from our intent and context, not from the technology.
What advice would you give to young architects just starting their careers?
Don’t get hung up on certifications. Consider them if you’re after a specific role, but work backwards from the role you want to the certification you’re going to get. Not the other way around. Start journaling to release your superpowers - architecture decisions are enabled through knowledge, so you need to become an expert at knowledge management. Eventually you move from personal knowledge management to team or organisational knowledge management.
If you could go back and give your younger self one piece of advice, what would it be?
Nobody else has defined who you are going to be. You will find that you’ve been setting your own constraints, so challenge yourself, repeatedly.
What do you think about Dear Architects?
Dear Architects extends great architecture content to new audiences via social media. I enjoy the variety, and the breadth of the content.
Steve works with clients modernising and transforming their IT estate, helping teams on enterprise, solution and technical architecture topics. He started his career in devops probably 10 years before it got the name, and then as a developer moved through team leadership into being an "accidental architect" (this is a real role, but an imaginary title). Now an intentional architect, Steve is an active blogger and organiser of Domain-Driven Design London, a socio-technical & systems architecture community.