The Agility Series — 8 — Technology Tail, Not Head
No matter how much the world of technology grows, it is always in response to an idea or a need or both to a real-world opportunity. This is the main reason Agile became extremely popular. The hope of alignment to the pace of real-world change became nearly a promise. Experience has taught most practitioners, however, that agile programs and processes are not enough to meet that demand we call change.
Since formulas do not really work as there are no silver bullets, how do we remedy this and get the head engaged? The more successful teams are accomplishing Domain Alignment through a variety of means. This makes a world of sense. The Domain, in Domain-Driven Design (DDD) is the real world. It is the thing that could benefit from solutions.
How though? How in the world do they make systems that can adapt to change? What do those DDD enabled teams know that non-DDD teams are missing? Let’s answer that here.
Honor.
Bear with me.
Honoring the Domain is the missing ingredient in organizations where IT is leading without Subject Matter Experts positioned on the team. DDD enabled teams have that one well developed strategy as their anticlimactic secret. They call them Domain Experts. If it is confusing, then call them Subject Matter Experts. If that is confusing, call them Business Experts. Whatever you call them, don’t stop calling them. They need to be called to be on the team.
“What do they provide?” you may wonder.
Domain Experts are the people that know how the users, rules, events and more should interact with the system. They know what is right and wrong about the business concepts going into the code. If they can prevent bad code from being written, then they prevent a refactor. Refactors are expensive. This is the benefit of this collaboration.
How does this work? It’s simple. Stop viewing services as a technological concept as a main focus and start viewing them as a social construct of a collaboration between the Domain and IT.
Big Picture
To make that happen, in DDD, you would separate concerns at the root level by natural Domain Language barriers. Those are the first work breakdown structures called Bounded Contexts. Technically they are Bounded Context Candidates (BCC) until they are validated and adjusted. Big Picture Eventstorming, with Domain Experts no-less, is an amazing process that lasts hours not weeks to get to that knowledge.
Process Model
For each BCC that is the first to develop, teams would use Process Model Eventstorming to lay out all the steps the system takes. Again, hours and days not weeks and months is sufficient to accomplish this.
Software Design
For the Process Models that are first to develop, teams would collaborate between Domain Experts and Logical Designers (DDD folks), Developers, Engineers, and Architects, to craft the functionality using Software Design Eventstorming. Follow that up with a set of Aggregate Models and you generally have some great models to choose from to make your technology align with the Domain.
All of this is done in an iterative way that can meld into the Agile process you may already be accustomed to, but you will want to modify the process to do less of the effort that is not providing enough value and more of these principled work breakdown efforts that make systems adaptive to change.
The head (Domain) is the leader. The smarter the head, the smarter the path. The more the tail follows that head, the more success the tail (Technology) experiences.
If you are working in a world where technology is leading from a position of misalignment with the real world, almost certainly, your technology is underperforming at best, maybe useless, and at worse burning refactoring money you cannot afford to spend.
When you think about your technology, where do you really want it to go? Are you honoring your Domain?
Need help? Articulate Domain recommends just doing Big Picture Eventstorming to understand the first work breakdown structure layer. We can help. You can reach me at Linkedin.
