Businesses change their ways much more often and must faster than they used to. That's because they have to! If they don't, step by step they'll become irrelevant. What's more, if they don't change fast enough they may loose a leading market position to a competitor. And such losses are difficult to regain.

Today businesses depend on software more than they ever did. Whatever they do, software is there to help them. Without software they can't, for example, register a customer order, get the merchandise out from the warehouse, ship it, or invoice it. They can't monitor the invoice to make sure the customer pays for the goods or services received. And they can't pay out salaires to their employees.

One of the most frustrating situations for a business manager is when a fast change is needed and the necessary software changes delay it. This is not an uncommon situation. So, why is it this way?

A common explanation is that the relationship between business activities at different levels of abstractions and software has become "a big ball of mud". This is what it's commonly called, and the Internet is full of references. The picture below should give you an idea of this situation.

(Picture source: https://nrkbeta.no/2017/04/29/undoing-the-harm-of-layers/)

This is a many-to-many situation, so common in large organizations with many large systems. Software consumers tend to depend on many software components. Software components tend to serve many software consumers.

A software consumer could be a business activity, residing in one part of the organization. Another software consumer could be a business activity, residing in an entirely different part of the organization.

When a consumer is about to change its way of operation, it might need a certain software component to change with it. If the other consumer uses the same component, and don't want it to change, that other consumer might wind up in trouble.

This is not so bad if there are only two consumers of the component. If there's an unknown number, and a large number, the situation is lethal. That change, done for one specific consumer, can damage a large number of other consumers.

To avoid this, the Dev Team must carefully analyze the situation. Having done that, it must just as carefully plan the changes so that no consumer gets hurt. Then it must implement the changes, and test them. And all this takes time.

This is manageable if the number of consumers and components involved are manageable. If the numbers are large, as in the ball of mud above, it can be a nightmare. In any case, the process is likely to take quite some time and quite a few iterations. And most likely, it won't come out right the first time, or perhaps even the second time, which adds to the cost in time.

So, is there a better way? Is their a remedy?

The Business-Driven Remedy

In their pioneering article Microservices, Martin Fowler and James Lewis established that microservices should be organized around business capabilities. Here's an exact quote of what they said:

"The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management."

The Certified Software Architect Microsoft Platform covers this approach in detail. You'll learn about the ideas behind it, but, more important, you'll learn how to use it in real projects. And more of this is coming on a continuous basis.

A big bonus is that this approach fits as hand in glove to the agile approach of software development. Every business-oriented work item in your product backlog is compatible with a business capability.

• Each of your business Epics requires a high-level business capability.
• Each of your Features requires a mid-level business capability.
• Each of your User Stories requires a low-level business capability.

This picture should give you an idea of how it works. You have selected one epic around which to organize a microservice. That microservice will serve your chosen epic and all its descendants, just as the picture shows.

Microservice X has one single responsibility. It's to serve Epic X and all its descendants. Epic X and all its descendants should rely on Microservice X for all their needs. This is exactly what the SOLID Single Responsibility Principle is all about.

There's no other eason for changing Microservice X than to meet new or changed requirements from Epic X or its descendants. No other consumer is involved or could be disturbed.

The trick is to find the right epic or epics around which to organize microservices. You'd be looking for high internal cohesion and loose coupling to the environment. You'll learn all about that in the program. And also to use the same approach to identify your user interfaces.

The result of this approach is user applications and services that are super flexible in their abilities to change with the business. And, therefore, have a long life. It's also to allow much faster and safer changes to vital business software. Which lets you make your customer very happy.