Talk to the user! That's what we've always been told, and that's what most of use are always doing. We know that if we don't do that, the user won't be happy with what we give them. After all, they know their jobs much better than we do. And without getting to share that knowledge, we can't make them happy with what we give them. We all know that.

Most of us are less good at talking to business stakeholders. These are either business managers, domain experts, or assistants to business managers. They know why they are investing in this system, which business problems they want it to help them solve, and what business goals they want it to help them achieve. If we don't understand all that, how can we give them a system that will help them with it?

There's another reason, less well understood but at least as important, for talking with business stakeholders!

One of the most common problems with software development today is that nothing is as stable as it used to be. Businesses change their ways more often now, because they have to. If they don't, they lose market shares to new or changing competitors, or because customers change their purchasing habits. Internet has a lot to do with that. Public authorities also press for changes by introducing new requirements such as GDPR.

Almost every such business change requires changes to software as well. The business must make other changes too, such as finding out what is required from them, as retraining employees, changing processes, and more. But more often than not, it's the software changes they have to wait for to be able to finalize the changes.

We talked about that in the Business-Driven Software Architecture highlight. In the description of that highlight we showed you this picture, and it's relevant for this topic as well:

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

It describes what's called the Big Ball of Mud syndrom, which is present in many (or even most) enterprises. For smaller enterprises there might be a Small Ball of Mud, but its effect is the same.

Today, and increasingly, business activities are served by software services. The problem is that most software services support many business activities of widely different kinds. Changing a service to support a changing business activity in such a service can badly hurt other consumers of that service. It can cause damage to other business activities, performed in other parts of the organization.

This is a terrible no-no! It can't be allowed to happen.

So the first developer activity is always to find out which software services (and other software artifacts) that must be changed. The second is to find out which other business activities these changes might affect. And this takes a lot of time, both with small and big balls of mud.

Then it's time to plan for the changes and to implement them. And, not the least, to test them, making sure that they do what they are supposed to without causing any collateral damages. And all this takes even more time. Which adds to the delay for the business to have their pressing changes implemented.

Is there a cure for all this? Yes, there is! This cure was first described in the beginning of the 2000s. That was not in a service-oriented but an object-oriented perspective. It's the first of the SOLID principles, collected by Robert C. Martin and getting their name by Michael Feathers. This is the Single Responsibility principle. It says that a class should have one single responsibility and therefore just one single reason to be changed.

This principle is just as valid for services as for objects, which takes us back to Martin Fowler's and James Lewis's pioneering article Microservices, Martin Fowler and James Lewis established that microservices should be organized around business capabilities. We've already mentioned this in the Business-Driven Software Architecture highlight, but it's just as relevant here. Still, we're not repeating the exact quote of what they said. You'll have to look at that highlight for that.

But we will give you another aspect to it. Consider this diagram:

To the left you'll find Business Artifacts. This is the most pure business-oriented view on a business you can find.

On the top-most level are high and medium-level Business Capabilities. These build a hieararchy that can be 0, 1 or several levels deep. Manage Sales Opportunities, Administer Sales Opportunities and Convert Sales Opportunities are examples of such capabilities. None of these occur at a special point in time. They are steadily going on without stops or finishes.

At the next level you'll find Leaf-Level capabilities such as Register Sales Opportunity and Route Sales Opportunity. These are short-lived. They typically occur often and last for a short while only. They tend to be completed in one single "sitting".

The bottom part is for Operations Required. These are requirements for software operations such as Get List of Customers, Get Customer and more of the same kind.

The middle column houses Backlog Artifacts. The amazing thing is that you can make these match the business view. You can create epics called Manage Sales Opportunities, Administer Sales Opportunities and Convert Sales Opportunities. You can create Features called Register Sales Opportunity and Route Sales Opportunity. You can create User Stories called Register Sales Opportunity and Route Sales Opportunity.

The beauty of this is that you can create a backlog structure that matches the business stakeholder view of the business structure. And as a result of this, you can create microservices that are organized around business capabilities, just as Fowler and James insisted that you should. Or, perhaps rather, organized around product backlog epics

A result of such an approach is that a microservice called Sales Opportunity Manager has one reason only to change. It's that the Sales Opportunity Management capability or epic needs it to change.

And when you design and implement these changes, no other consumer can suffer collateral damages, because there will be no other consumers of this service. That's why this kind of design is so sustainable. It will keep for a long time.

In the Certified Software Architect Microsoft Platform program you'll learn patterns for it. You'll also learn how best to communicate with business stakeholders to achieve these structures and these designs, and how to get the best from them.

Oh! We almost forgot to tell you. You can completely forget about the leftmost column of the diagram above. We included it just to point out how you can make your program backlog mirror the most pure view of business structure. This is the diagram you'll work with in the program and on your job in sharp projects: