Domain Intelligence – Part 1: Buy A Bugatti For Uber?

Read Time: <5 min.

What Ridiculous Fun!

If a Bugatti turned the corner for your next Uber ride, what would be going through your mind?  I mean, after you picked up your bottom jaw from the sidewalk?

This would be memorable.

What would you choose to drive if you were picking up strangers and transporting them around town for a fee?

You would likely not ignore some intellectually honest thoughts about how much to spend, but that may not be enough to make a highly profitable choice.

If you have read Eric Evans’ Book “Domain-Driven Design: Tackling Complexity in the Heart of Software”, then you you have most likely run across the terms Domain Knowledge and Knowledge Crunching.  Domain Intelligence (DIN) is that highly important information that flows out of that process.  We mine for DIN so that we conserve energy on the other side and do things that make intellectual sense.  It is prize information in many cases.

When it comes to being an Uber Driver, that business owner knows a lot of things about their opportunity.  The knowledge list could be extensive, but buried in that list (and maybe missing from that list) is a subset of pertinent information with unique relationships that helps them buy a far better car for their business than a Bugatti or worse.  Domain Intelligence is what they surface as they consider all of the variables that may or may not be important to that decision.  If their knowledge cruncher is really good, then they will have “done their homework” and landed on extremely valuable DIN that drives their next actions – profitably.

This is far better than “thinking they have DIN” and running out and buying the first car they “think” might work.  Often times the way we write user stories or develop code.  More on that later.

Domain Intelligence assists, therefore, with wisely designing a desirable economic outcome (Profitability) as it relates to providing solutions for the organization.

Sure there is a law of diminishing returns, but in some domains, especially in custom software, few of us, especially in the American market, could easily be accused of breaking that law. It is more often the case that we start developing software solutions before we have wisdom inducing Domain Intelligence, much less quality designs.

DIN Helps Save Large Sums of Money

Though the Bugatti Uber example is extreme and obvious, in software we are just as extreme and not quite so obvious.

I believe the DIN focus is on the rise due to the intolerable nature of poor software economic outcomes.  CFO’s want to know where that money went.  Unfortunately the answers get hard to find when planning is so poor. This centers directly on lack of DI mining and the lack of good design.  Money is pouring into wasted code all day long.  I am for experimentation, but that can be done for far less with DIN and design.

Accidentally buying the Bugatti is becoming far more intolerable since billions of dollars have been burned on The Code To Nowhere (tCtN) and those who manage these budgets have grown weary.  If the code did go somewhere, then it often ends up as a Big Ball of Mud (BBoM) and that has a financial drain all its own.  If you are in software today, unless you are in a rare shop that knows Domain-Driven Design (DDD), you probably feel this drain daily.

In addition to the financial pressure, I believe this increase in focus on DIN is also based on my observations like the growth of the DDD practitioner community and the amount of content cropping up even on Microsoft’s website with regard to DDD.  DDD has been available as a resource for over 15 years and used by very few to profitably plan quality software outcomes.

Domain Intelligence? But we are Agile!

DIN, and specifically the designs it empowers, is a mindset that I believe was intended in the Agile Principles all along (See Principle # 9). When the IT world was more Waterfall, there was an intentional emphasis on software design and the better the plans the better the outcome.  The shift to Agile was a powerful move to make life better for everyone.  But, it was not intended to rid us of quality process steps like software design.  Rather, it was, as we know, designed to reduce the cycle time and get stuff to market faster.

The Manifesto does highlight an emphasis on some things over others, but it does not recommend dropping key quality activities like iterative software design.  In fact. I would say, without a healthy balance of those concerns, teams are not going to deliver profitable working software on a normative basis.

As an example, My team had a logistics API project that needed some unique logic. We gathered Domain Intelligence on the primary shipping piece very well, but not so well on the purchase order aspect.  After several sprints the shipping bit was stellar and the purchase order code missed the mark altogether, requiring a rewrite of that module.  Profitable like a Bugatti Uber!  I know for a fact it was because we did not take the time to add DIN enabled design iterations. That missing DIN and design did not have to take long to gather, maybe a day or two, and we would have nailed the software down accurately.

The only difference between the successful bits and the unsuccessful bits was attention to Domain Intel and the design that flowed from it.

I have learned from that lesson that if you take the time you think you don’t have to mine the Domain Intelligence and craft a design based on it, you will save time you never thought you could. And even your internal customers will love you for it.

I could cite more experiences, but suffice it to say, I choose to surface DIN as a habit now.

What Now?

This begs several questions.  Aren’t user stories DIN enough to find that Toyota Camry or Prius?  How do you gain DIN more efficiently?  When do you choose to actively go after it?  When is it overkill?  What happens when it changes? How does Agile support iterative DIN and DDD in practice.

If you struggle with inefficient Requirements Gathering or User Story creation or mis-applied code, you will want to follow this series.  Having worked on public and private sector projects that actually serve their purposes, some for a decade, I know all too well that solutions exist, but it just does not come naturally as if we don’t have to put some energy into the process of DIN.  It is very worth it on the other side when the “buyers” of these products actually rave about your work.  I love that “all is right with the world” feeling when it crops up especially as the product is in development and it remains to the end.

There are several tools cropping up in the last few years to help our teams activate the knowledge that fuels profitable software decisions.  Tools alone don’t solve this. I will reserve those ideas for future posts as I just wanted to draw attention to Domain Intelligence, Domain Driven Design and the profitability they can provide.

Post Bottom Line

Domain Intelligence is on the rise.  Your teams will give your business a competitive advantage when building more profitable solutions by design based on Domain Intelligence.  DIN is Software Economics and it is not just for academia.  Agile was never meant to leave domain information and software design at the implementation doorstep.

And as for the Bugatti Uber, it could actually make some sense on Rodeo Drive, Miami Beach, Riviera or some other “lifestyles of the rich and famous” setting if Uber had some channel on their app that was for “Outrageously Expensive Rides!”.

Coming up, we will look at how Domain Intelligence creates a liberty that speeds up the flow and how to obtain and use Domain Intelligence to our benefit in a way that helps the CFO/CEO breath far more easily in the long run.