Image for post
Image for post

Sometimes we need to stop fighting the symptoms and recognise that there is a more fundamental problem. Commonly, the fundamental problems is a mismatches in incentives between the different individuals and groups involved in achieving an outcome.

The more I observe organizations, the more I see this pattern of people fighting the symptoms and getting frustrated that things aren’t improving or changing. And the more I see that things are always going to be a struggle because incentives are widely misaligned.

When there is an incentives mismatch, a lot of energy can be expended. Lots of back and forth, lots…


Image for post
Image for post

As a system grows, higher-order abstractions are needed for ease of understanding, communication, and management. In Geography, continents are a higher order abstraction that allow us to collectively describe a large number of countries in a single word. As businesses grow, higher order abstractions are needed to organize groups of teams working on related challenges, like products or domains.

When I worked with Salesforce, the top-level organizational abstractions were clouds. The Salesforce Marketing Cloud was a substantial business in it’s own right, employing thousands of people and generating close to a billion dollars in revenue per-year.

Part 2 of this…


Image for post
Image for post

The systems we build are composed of many pieces. From mobile apps, to domains, to user journeys. How should we slice up the system and divide responsibilities among teams in our organisation?

In Part 1 of this series, a shared language was proposed to accurately describe different elements of a business’s architecture. We can now start to slice and group those architectural pieces into team-sized chunks and analyse the trade-offs of each pattern, and explore contexts in which they might be applicable.

The third part in this series will look at multi-team ownership patterns, exploring how to distribute cohesive parts…


Image for post
Image for post

Team Topologies has significantly advanced the discussion on organisation design for technology companies. The next step is to determine what Team Topology boundaries align to…what should Stream-aligned (and other) teams own?

When organising technology teams to build digital products and services, it is necessary to determine which parts of the product, user experience, and technology each team owns.

Should teams be frontend, backend, full stack or something else? There are more than just these three patterns to choose from, each with many trade-offs to consider.

A Model For Describing The Architecture of a Business

Before defining team responsibility ownership patterns and comparing their trade-offs, it’s necessary to have common…


Image for post
Image for post

Domain-Driven Design is an approach to designing systems, usually software, that emphasises creating a common language between domain experts and system builders. Famous DDD principles include Use a Ubiquitous Language and Make The Implicit Explicit.

However, some concepts in DDD do not have a clear definition and are highly implicit. Everybody has their own definition of Domain, Subdomain, Problem Space and Solution space. In this article, I’m going to provide working definitions of those concepts and clear them up.

This post is based on a long conversation on github involving many people from the DDD community. …


Image for post
Image for post

Enterprise Architecture (EA) is hugely important for medium and large organisations. Enterprise Architects take a broad look at an organisation, and are experts in aligning technology solutions with the business objectives.

In my experience as a consultant, EAs are not having the impact they should. Very often the EAs are seen as working off to the side, creating complex models that nobody uses and extensive documentation nobody reads, and often acting as a barrier for teams who want to move quickly.

My observation is that EA has not evolved to support modern operating models. High-performing technology organisations are characterised by…


Image for post
Image for post

Back in the summer I shared some of the techniques I’d been using to reimagine my in-person architecture workshops as remote digital offerings with Miro. I’ve learned a few more tricks since then which I think are worth sharing.

My typical workshops usually range from 2 half days to 6 half days in duration spread over the course of 1–2 weeks. They’re a mixture of lectures and hands-on exercises. There’s a lot of content, both mine and generated by attendees, so it’s very easy for large boards to become a big mess.

I typically do 2 big, pre-planned workshops per-month…


Image for post
Image for post

Don’t let the tools you use overly-constrain your thinking. Use them as a starting point for design and discovery, and then bend them to your needs.

Alberto Brandolini says that EventStorming is his pizza and you can add your own topping. Every tool you use is somebody’s pizza, and you should always look for opportunities to tweak the recipe and find something that tingles your modelling tastebuds.

If you’re not familiar with the Bounded Context Canvas it is a tool for visualising the key design choices of a Bounded Context or a sub-system in your software architecture. …


Image for post
Image for post

One of the biggest time costs in software development is understanding how a system works. And the problem may be growing. Systems are getting more complex yet our ability to understand them doesn’t seem to be growing at the same rate.

As we continuously develop software systems, the complexity slowly increases and we don’t fully realise it. Nobody sets out to create a Big Ball of Mud, but many codebases end up that way due to the cumulative effect of the thousands of small changes we make.

Complex systems are harder to learn and harder for newcomers to be productive…


Image for post
Image for post

As an architect, how often are you thinking about business models? If every significant architecture decision has business consequences, then knowing the business model and which trade-offs to choose is maybe the most important skill of architects.

But what is the actual relationship between a business model and a software architecture? I’ve been thinking about this a lot because I want a deeper understanding of the implications. If I know how decisions in one space affect the other, I’m going to make better architectural decisions.

It’s not just about business models and architecture, though. There are other systems involved in…

Nick Tune

Technical Leader | Socio-Technical Architect | Continuous Delivery

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store