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 series looked at the lowest organzational abstraction level — individual teams. This part moves one level higher, looking at patterns for grouping small numbers of teams. I prefer the term Group although you may be familiar with the phrase Tribe emanating from the Spotify Model. …


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 of an architecture among groups of collaborating teams. …


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 ground on the language used to define responsibilities a team may own. …


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 decentralisation: autonomous teams, masters of the problem space, who own products or features. These teams work closely with their customers and they are continuously deploying improvements to their production environments every day. …


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 run either publicly or privately. So I’ve had a good run of experimenting with ideas and iterating on techniques for managing the mess. …


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 in. I’ve heard the opinion from many technical leaders that it is reasonable to expect a new hire to take upto 6 months to learn about the code, the domain, and the architecture before they become fully 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 this tangled relationship. A software system is a model of a domain. Is the business domain the same as the business model? What about the organisation? …


Image for post
Image for post

Most organisations go through an architecture modernisation effort at some point as their systems drift into a state of intolerable maintenance costs and they diverge too far from modern technological advances.

I’ve seen some organisations deliver hugely impressive modernisation programmes. A lot of modernisation efforts, though, are shallow and buzz-word driven or carried out by expensive consultancies with flashy Powerpoint decks.

Before jumping into either of those scenarios, have a look at what Strategic Domain-Driven Design can offer you. …

About

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