Software architecture consultancy

Software architecture that serves the people who depend on it.

Hello, I am Eoin Woods and Artechra is my consultancy company. I help software teams to make architecture a central shared activity in their work, leading to better architectural decisions, clearer direction and happier stakeholders. I have been a practicing software architect for over 20 years and more recently spent 10 years as a CTO in a software engineering firm. I am a regular conference speaker and co-wrote the books Software Systems Architecture and Continuous Architecture in Practice.

Architecture workshops Contact me

20+ years of software architecture experience, much of it on critical systems
3 books on software architecture, published by Addison-Wesley
10 years as CTO of a digital engineering firm that grew 12,000 people during my time there
PhD in software engineering. FBCS, CEng, CITP, IASA Fellow

How I work

Outside in

A lot of architecture work start with code level concerns and does not move much beyond these. The implementation is important, but ultimately it serves the people who rely on the system. So I start from there. Understand the people who depend on the system and the qualities they need from it, gather evidence on how well it meets their needs, and then work out what the right implementation should be.

Stakeholders and concerns Who depends on the system, and what each group needs from it.
Quality needs What “good enough” means for performance, scalability, security, usability, cost and other key qualities.
Evidence How well is the system really working? This can be found in your stakeholder satisfaction, operational experience and delivery metrics.
Code and structure The structures, dependencies and technical debt that help or hinder those goals.

Most engagements start with one of the focused workshops below, typically two or three days and can then continue as longer, more flexible support as required.

Working outside in, from the people who depend on the system to the code that serves them.

Software architecture

Workshops

Fixed-length workshops, each addressing a different aspect of software architecture. These are usually run onsite with a focus around a particular system or group of related systems, but other formats and options are possible, including remote delivery for distributed teams.

2–3 days + report

Architecture Checkup

Find out how well your architecture meets your stakeholder needs and where the risks are.

Reasons to Run This Workshop

You've just taken over a platform and an independent view of where you are.
Emerging problems such as increasing incidents or slowing delivery suggest something structural is wrong.
Justifying investment or readying for a major growth step.

Many architecture reviews focus too much on the implementation and don’t look far enough beyond it. To avoid this I start with the people who care about the system and the qualities they need from it, such as scalability, usability and security. Then we look for evidence from production, from end users and from key business metrics, to see how well it really serves the people who matter. This gives us the context to analyse the implementation, to work out why it behaves the way it does. This provides you with a clear view of what is working well, where your major risks are and what you need to address first.

Content and Outputs

What we cover

Stakeholders and concerns: who depends on the system, and what each group needs.
System quality needs: clear definition of what “good enough” means for your system’s qualities.
Gathering evidence: stakeholder views, operational experience and delivery metrics.
Architecture walkthrough: walking through each quality need with your team to see how the implementation supports it.
Code and structure: understanding key structures, dependencies and technical debt that may be causing problems.

What you get

A stakeholder list with their system quality needs
An assessment of how well the system is meeting each quality need
A list of risks and trade-offs in the current implementation, with the business implications of each
A prioritised list of recommended remediation items addressing the findings

Format

Short stakeholder interviews beforehand, information gathering before the workshop, two to three days with your team, then a written report and a session to present the findings.

2 days typically 8–12 people

Software Architecture for Teams

Improve architectural decision making and alignment by integrating software architecture into how your team works.

Reasons to Run This Workshop

Your architecture lives in people's heads and on slides that are out of date and largely ignored.
Decisions are made without a clear view of the trade-offs which often cause problems later.
Your tech leads want to align everyone and improve the architecture but don't know where to start.
You need some way of ensuring that AI agents work in alignment with your team, not against them.

Good software architecture doesn’t need a heavyweight framework, expensive tools or a separate architecture team. It needs a few practical, lightweight practices that fit into normal delivery. This workshop guides your tech leads in adopting them: recording decisions well, understanding stakeholders and their needs, agreeing principles to guide decisions, making trade-offs deliberately, and keeping just enough documentation to be useful. We work on one example throughout, or on your real system, so that after a few days the team is ready to bring these practices into everyday work.

Content and Outputs

What we cover

Where you are now: how you make decisions, what you write down, how you work with stakeholders, and what causes problems today.
Stakeholders: who cares about your system, and what do they care about?
Architecture decisions: making good decisions, recording them in a lightweight format people will use.
Principles: the priorities and beliefs that should inform and constrain your team’s decisions.
Trade-offs: comparing options against the qualities that matter most.
Styles and patterns: a shared vocabulary for discussing design options.
Minimal modelling: what to model and diagram for the most value at the least cost.

What you get

A draft set of architecture decision records
Some candidate architecture principles
A context view and initial component view of your system
A roadmap for bringing this way of working into your team

Format

Two days, or four half-days for your tech leads and senior engineers.

2 days + decision report

Renovate or Rebuild?

Base your biggest technology decision on evidence and logic, not optimism.

Reasons to Run This Workshop

Your core system is starting to cause problems and someone is proposing a rewrite.
You need confidence in your evolution approach so that you can secure funding for modernisation.
There are many options for rebuilding or improving, but the implications of each aren't clear.

Replacing a key application is one of the most expensive and disruptive things a technology organisation does. Yet the decision is often driven by frustration and optimism rather than logic based on evidence. This workshop takes a structured approach to this decision to allow you to make a better decision. We establish how the system is really performing today, identify and compare the options you have, from gradual replacement to a full rebuild, and analyse the trade-offs, risks and constraints. Then we take your stakeholders through the evidence and help them reach the decision that is right for your organisation.

Content and Outputs

What we cover

Where you are: the real problems and concerns with the system today.
The opportunity: the benefits you could unlock by addressing them.
Options: improve what you have, rebuild incrementally, or rebuild in parallel? The technical options and benefits of each.
Implications: the risks, constraints and trade-offs of each option.
Stakeholder decision: setting out the facts, options and trade-offs so the key stakeholders reach a balanced decision.

What you get

A clear understanding of your current system, and whether it makes sense to replace it or evolve it
A set of well-understood options and their trade-offs
An agreed decision, made by the people who it most affects

Format

Two days with technology and business leaders, plus a short report explaining the options and the rationale for the option chosen.

1-2 days typically 8-12 people

Architectural Alignment for Human and AI Teams

Aligning people could often be difficult, now we have AI agents to include too.

Reasons to Run This Workshop

AI agents produce working code, but often code in conflict with your decisions and conventions.
You're seeing inconsistencies and surprises emerge across your codebase.
New (human) team members and AI agents produce a lot of change that needs reworking.

AI coding agents now write a growing share of your code, but they lack the team context that your people have. This workshop shows how to make and capture your current architectural decisions, and identify the principles you want to act as guide rails for future ones. We then explore how to turn that human-oriented guidance into guidance for your AI tools, and the importance of automated validation to automate a set of checks to make sure they it is followed.

Content and Outputs

What we cover

Architecture decisions: making good architectural decisions and recording them in a lightweight format people will use (ADRs).
Principles: the priorities and beliefs that should inform and constrain your team’s architectural decisions.
Agent guidance: turning principles and decisions into guidance usable with for tools such as Claude Code and OpenAI Codex.
Validating implementation: implementing automated architecture tests, CI checks and review prompts that spot violations.
Keeping it current: updating the guidance as your system evolves.

What you get

A draft or example set of architecture principles
An initial or example set of architecture decision records
AI agent guidance for one of your repositories, or for the example application
Examples of automated conformance checks

Format

One to two days (depending on agreed content) for tech leads and senior engineers.

Independent technical leadership

Fractional CTO

As well as software architecture expertise, I can offer senior technology leadership for organisations that need a CTO’s judgement but not a full-time CTO.

This work tends to be part time (typically 8 to 16 days per month) for a fixed period, either due to challenges or changes in the organisation, or specific projects that need to be completed, perhaps to prepare for growth or a change in direction.

My work as a fractional CTO typically includes technology strategy, assessing and improving architecture and software engineering practice, growing or developing the technical team or providing investors or the board with assessments, advice and guidance.

A lot of my work as a fractional CTO is through my role as a CTO Partner at Rational Partners.

I spent ten years as CTO of a digital engineering firm that grew from 1,800 to 12,000 people during my time there, responsible for capability development, innovation and technical strategy. Before that I spent ten years in technical leadership in capital markets, at UBS and BGI (later BlackRock), and earlier built software products for Bull, Sybase and InterTrust.

Discuss a fractional CTO role

Who am I?

Eoin Woods

I am an independent consultant in software architecture and software engineering effectiveness, and an experienced fractional CTO.

Before going independent I was CTO of a digital engineering firm for ten years, and before that spent a decade as an architect and development manager at UBS and BGI (later BlackRock), working on technical transformation for agile delivery and the practices that came to be known as DevOps. Earlier in my career I developed worked for software product companies creating databases, security software and middleware.

I hold BSc, MSc and PhD degrees in software engineering, I am an academic visitor at Imperial College London, and a regular conference speaker. My main interests are software architecture, software security, DevOps, software energy efficiency, and applying AI in software delivery.

Software Architecture Books

Software Systems Architecture with Nick Rozanski · Addison-Wesley
Continuous Architecture in Practice with Murat Erder and Pierre Purer · Addison-Wesley
Software Architecture Metrics With Christian Ciceri, Dave Farley, Neal Ford et al · O'Reilly

Full biography, books, talks and writing eoinwoods.info →

Making Contact

Explain what you need help with, be that a system, your team, or a decision. I will reply personally, and we can work out together whether a workshop, some training, a review of some sort, or something else entirely is needed.

Get in touch LinkedIn

contact@artechra.com