Domain Driven | Design | Thinking
Where enterprise architecture and agile development meet
Size matters, when it comes to your companies’ digital presence. The bigger you become, the more you’ll have to split your solutions up into individual pieces you can allocate ownership for. Not the first time I reference Conway’s law ;-).
This big team / solution of individual pieces introduces new complexities that you won’t have when the scale is limited.
Complexity as an inhibitor for innovation
The bigger your application is, the more bombastic RFC’s might seem. Each change seems to make a tremendous impact.
- Because a new subject easily touches a lot of the solution you already have.
- Because everything seems relevant.
- Because as soon as a project hits more than one team the communication overhead blows up and the time invested in alignment appears to be a hard to slay hydra.
- But also because you might be stuck in a mindset, with tools, that worked in the past but perhaps not in this situation.
You need help to make things small, discover all aspects of the problem and apply validated learning over the most valuable parts of the hypothesis. You need to know which are the right things to build to get the biggest bang for your buck.
Lean methodology rightfully hovers around the place where the user interacts with the solution. Investing a truckload of time in solid architecture just doesn’t make sense if you didn’t validate if the user actually needed it.
Simplicity as an inhibitor for quality
The smaller you validate what works and what doesn’t, the more you risk becoming blind for the bigger picture. You can start implementing fixes on so many levels, not addressing the real issue behind it. I hope you will find a hobby in creating band-aid solutions, because that’s what you’ll end up doing if you don’t address the cause underneath.
We tend to skip this step. Thinking about the problem behind the problem. Why?
It’s hard to remember you’re draining the swamp when you’re up to your neck in alligators.
Fixing the issue, simply seems good enough since we have so many more issues. What’s often forgotten is that the stream of issues is endless unless you address the real causes. Simply put, the amount of issues will go down if you invest a bit deeper to fix what lies underneath. When the swamp is drained, there will be no more alligators.
The conundrum
So on the one hand you need to see an issue for what it is, and validate it as small as possible to progress into the most valuable direction, and on the other hand you have the urge to solve things structurally.
Those are two seemingly contradictory statements. Seemingly, because they are actually not mutually exclusive. It’s really simple. Let me explain why.
Thinking about where a business logic belongs, doesn’t say a thing about which logic you will develop first.
The equilibrium
This is a problem for bigger online solutions with more teams. So I take the liberty to assume that there is budget and manpower behind the solution. Bigger companies simply can afford the ‘luxury’ of splitting one-man-armies into very specific roles. There’s less need for jack-of-all-trades kind of people, than there is a requirement for deep knowledge of one specific field.
In order to establish an equilibrium you will need to have at least the following complementary skills on board.
- UX Designer Leads
- Solution Architects
- Product Managers
- Product Owners
Why complementary? Well, they aren’t the folks that actually build the end solution, but they are required to steer the solution into the right direction. Let me explain how.
The UX design Lead
The UX design lead guides the design process. Together with the UX designers, testers, some front-enders and even clients they can — by leveraging design thinking during a design spike — formulate
- if there should be a solution at all
- where we should start building
- what the problem actually looks like
- what probable future steps of implementation might be
The Solution Architect
The solution architect also guides a design process, but it’s an abstract one. He will assess which business areas the digital solution will touch and formulates a landscape in which these area’s can be recognised.
By leveraging Domain Driven Development practices, he makes sure that each problem and request can be solved in terms that business understands and can take ownership in. Each solution that teams come up with, can — and should — be mapped against this landscape.
This ensures that no matter the angle the end-user interacts with the system, the solution will always behave the same. Because business logic is encapsulated in the service architecture, rather than a fix on the frontend.
The Product Manager
The product manager should feel completely comfortable with the technical roadmap the solution architect drew. From his perspective this is a drawing which frogs he has, so he can understand how to keep them in the bucket and how to distribute the load on his team evenly.
Keep in mind that the drawing is nothing more than an abstract view on the capabilities the organisation already has. In that sense they should always feel familiar.
The input of the solution architect helps him to understand which team (which PO) should work on the subject, and how the domain interacts with other domains.
The Product Owner
In order to be able to do this, it’s crucial to understand the difference between the functional domain and the feature. The feature resembles the ticket or epic the team of the PO is working on. The domain is the area the PO is responsible for.
The domain outweighs the feature.
- Whenever a feature harms the domain, it should be rejected. We own products, not problems. So the product is where the heart should be.
- Domains deteriorate in time. The software gets outdated or the world around us changes. It’s the responsibility of the Product Owner to make sure his domains needs are catered for. Not only for at this moment but also for the future. In that sense, it’s the PO’s responsibility to invest in ironing out any short term solutions that where implemented as well as setting the domain up for future potential.
Opposite ends attract
Where we started out with two seemingly opposing ways of thinking, we ended up understanding that they are actually two sides of the exact same coin.
The one should not go without the other, and they both serve the same goal of structurally doing the right things at the right time.
So whenever you start your new project, please consider both ends.
- Don’t build anything that you aren’t certain of it should be built to begin with (Certainty comes from validated learning, not your gut). Take a design thinking approach.
- Don’t implement features, but build capabilities for domains. Build an architecture that resonates with your business, and practice Domain Driven Development.
This story is a combined effort between me and Jelmar van Voorst.
