Confusing Process Stages With Bounded Contexts
Breaking a large system down into smaller pieces gives teams the autonomy to iterate quickly by decoupling them from dependencies that cause conflict, bureaucracy, and inefficiency — in theory. However, in practice, a lot of teams still report feeling a lot of those pains when they move to microservices.
One of the reasons for that is a pattern I’ve seen at multiple organisations: confusing process stages with bounded contexts.
When trying to break down a complex system into smaller pieces, simply putting team and technical boundaries around each stage of a business process is often a naive modelling approach that hinders an organisation’s ability to iterate quickly, and results in high-coordination costs between teams where none need exist.
This post is a taster of my talk for Domain-Driven Europe 2017 in January, where I’ll be talking about autonomy, bounded contexts, and building a high-speed engineering capability in much more detail.
Modeling around process stages slows your entire organisation
Engineering speed is an indicator & enabler of better products, reduced operating costs, and higher motivation. The more frequently you can deliver value, the more efficient your process is, the sooner you can iterate on customer feedback, and the more freedom workers have to enjoy the best parts of their job.
It’s autonomy that enables teams to “move fast, break nothing, and continually delight customers” — the ability to own decision making from product idea, to technical implementation, to customer delivery. But you can’t achieve these ideals if your organisational and technical boundaries constrain teams to work together on delivering almost every new idea.
These are the exact hurdles many organisations put in place when they naively just model their teams and services around apparent business process stages — they stop teams owning decisions.
Take this example of a government agency who are responsible for property taxes. They have a new business process called: Review, Resubmit, Renegotiate.
As a business you check the existing information used to calculate your taxes (Review), you supply updated information if any is outdated or incorrect (Resubmit), and you can challenge the amount of tax you pay based on the information held about you (Renegotiate).
The agency execs have a quick meeting and clarify the stages of their business process as:
- The user reviews the information stored about them
- The user resubmits updated information or accepts what is stored about them
- The user supplies the grounds for their renegotiation
- The case management team reviews the information supplied
Two sips of coffee later they’ve specced out the new project and decided they’ll require four teams to build, deliver and iterate this new system. But fast forward just a few months, and the teams are already feeling extreme pain…
The woefully inefficient organisational & technical boundaries of the gov agency
They’ve created a V1 of the system, and they’re testing it with real users, but tension is starting to build up between the teams. The Case Management team is bellowing steam at the Resubmit team who keep adding new pieces of information to their form.
Every sprint the whimsical Resubmit team adds one or two new properties and changes a few of the others — the number of car parks, previously owned buildings…
The Case Management team are going crazy: “we didn’t estimate for that”, “we’re working on something else”, “we have to keep having meetings with the stupid Resubmit team about their new ideas — we just want to get our job done”, “we don’t have time to keep up with all the changes those fickle Resubmit goons are making — we have been given impossible deadlines for other things”.
Equally, the Resubmit team are fuming. They can’t make the new fields visible to users until the case management team start accepting and storing the data. So they start complaining to the program management team: “we are getting all this feedback from users about what they want, but any time we try to add a new field the Case Management muppets resist all our changes”.
That’s not the only problem. The Review team are going nuts about all the other teams. The Review team manages the dashboard that helps businesses to keep track of all their properties, and the status of the Resubmits and Renegotiates they have submitted in the past.
The review team are going mad because the other teams keep changing their data formats. “We’ve got a meeting with Resubmit on Monday morning about their new data fields, we’ve got a meeting with Renegotiate on Monday afternoon about some modifications they want to make, and we’ve got a 2 day workshop with the Case Management team about their radical new process. We’re not going to get any work done this week!!!!!”.
I’m going to stop here, but I’ve only given you a taster of the insane amount of bickering, politics, and wasted effort that is happening on this project. And I’m going to show you why all of this politics is completely unnecessary: It’s because this organisation got their organisational and technical boundaries wrong — they set their teams up to fail.
There is no case management context
Problem number one with this organisational structure is that case management is not a thing in this domain. Cue the cries of: “Ha — you’re wrong. We have a Case Management team!”, which leads us to insight 1: don’t mindlessly reflect your existing organisational structure in your software.
So this government agency has a case management team, and they have a case management step in their business process… so they clearly need a case management development team… No they don’t.
The screeching warning siren here is that every time a change is made in the Resubmit or Renegotiate service, a corresponding change has to be made in the case management system.
Digging deeper into the domain, case management isn’t really a process step — it’s multiple process steps: processing the Resubmit submission and processing the Renegotiate submission.
But even if the case management service was split into two, why should the customer facing Resubmit service and the back office Resubmit case management service be built by different development teams? They shouldn’t. Collectively they should form a bounded context. A grouping of concepts that change together for business reasons and thus give rise to team autonomy.
Just because the front and back office teams were painful choices for this business, doesn’t mean they are for every business. There are no universal best practices.
By reorganising the teams around these key insights the politics instantly disappear. The Resubmit and Renegotiate teams now own things that change together for business reasons. Now their only excuse for not delivering value is spending too much time using the giphy plugin on slack (actually that’s my excuse).
Suddenly the friction between the case management teams and the others has disappeared. The Review and Renegotiate teams can get on with delivering value to their users. And this government agency can stop needlessly wasting taxpayer money.
An analysis of the Review team’s pains would also yield similar results. The dashboard does not belong to the Review system — it’s a composite of capabilities provided by other bounded contexts. By re-aligning the teams with this new insight, the friction between the Review team and the others also largely disappears.
I’m not advocating for one second that teams should never have to collaborate. But constant meetings, corresponding changes between one or more systems, and teams constantly being blocked by others are serious warning signs that your organisational boundaries are costing you big dollars & stressing out your people.
Composing contexts
This situation hasn’t been fully resolved, yet. Now there is the problem of creating the composite applications that pull in functionality from multiple other contexts
The backend case management system and front facing dashboard are the examples of composite applications in this post.
I’m not going to discuss them here, but there are a variety of approaches that teams take to solve this problem, and I’ll talk about them more in another post. If you want the answers now then ask some of your friends if you can borrow their copy of my book or check out some of Udi Dahan’s posts.
Designing for autonomy requires deeper insight
Autonomy enables your entire organisation to go faster, but it’s not something you can sprinkle on your teams. No organisation I’ve worked for got their boundaries right first time, and no-one I have ever worked with had a secret recipe for knowing exactly how to instantly create highly-autonomous teams.
There are, however, key heuristics to guide your exploration: applicability of language, existing organisational structures, data ownership. But none of them are a sure-fire bet. And be very careful when you hear those microservices folk splashing around the word bounded context. They make it all sound so simple, when in fact it is one of the hardest things to get right and one of the most important factors any aspiring high-performance must get right.
Every domain has nuances. Every organisation has quirks and unique characteristics. The patterns that enable autonomy in one organisation/domain can cause serious pain in others. Accordingly, there are endless reasons why organisations use the wrong heuristics, such as modelling around process stages.
If you want more insights into these challenges I’ll be sharing design strategies that lead to maximum autonomy at Domain-Driven Design Europe 2017. And I’ll be showing exactly how software developers like you can lead that change.
