How to Define Service Boundaries

It the last post I wrote about characteristics I want my services to possess. Now, I’ll talk about concrete ways of specifying service boundaries.

The difference between web sites, internet applications and enterprise software becomes vague these days. The complexity of web-based apps is getting higher, while enterprises go online, integrating with external services. Times when an web application splitting with a “site”-and-“admin panel”-approach worked out are gone. We all need a new way for identifying service boundaries. And this is crucial for business-IT alignment, hence, for whole business to thrive.

Business capability

Business capability is something that organization does to keep it running, to keep it able to operate. It is a specific contribution to whole enterprise functionality. It is a specific function or ability that organization possesses in order to achieve its goals. Purchasing manager acquires goods, a warehouse keeps it, seller sells it, financier calculates the profit. So business capabilities are almost the same for different firms involved in the same business. Their implementation is the thing that differs. Someone has more efficient implementation, someone has the less efficient one. Someone will thrive, someone will quit. So among the things that differ are business processes, staff, automation level, technologies involved. But the value that specific business-capability provides and its responsibility are the same. Business-capability doesn’t care how other capabilities are implemented. They can be manual, they can be outsourced, they can be partly automated with in-house development products operated through UI, or they can be fully automated where software is responsible for every decision. It’s just an implementation detail of some business-capability, while its contract doesn’t change, so other capabilities it interacts with won’t be aware if an implementation of this capability will change. So an implementation example of the business from the beginning of this chapter might look the other way. For example, like this: purchasing manager acquires goods, they are stored in rented warehouse, they are sold by vending machines or automated cash registers, specialized software is engaged in the finance part.

Business services

What is business-serviceBusiness service is the logical boundary where business-capability implementation resides. So what’s in there? There are business-policies, business-rules, business-processes, people involved in them and making specific decisions, applications used by these people. And all of this is a business-service’s implementation detail.

Consider a company that processes card payments. It has a business-service whose responsibility is fraud risk assessment. Assume that this assessment is made by hand. When this service is requested with an inquiry to make a fraud risk assessment, this service’s staff worker picks it, starts risk assessment process, and when done replies back somehow. At some point the company decides to automate the whole business-service, with all its processes etc. So it develops software that does everything by itself: it receives an inbound request through specific endpoint, makes all the assessments and replies back with asynchronous callback. But there is still a probability of software bug which is unacceptable in such a sensitive business. So the company decides to keep the possibility of manual assessment: for example, the software couldn’t proceed a request with absolute certainty — in this case manual interference would be needed. So the specific inquiry is completed by staff worker.The whole point in this story is that everything that takes place inside business-service is its implementation detail that none of the other services are aware of.

Some of us are more vivid visual thinkers, some are less, some are verbal thinkers. But visual thinking proved to have significant impact even on the latters. So here is an image I have in my mind when I think about business-service:

Inside the business service

Business-service and business-capabilityAny organization has a set of business-capabilities, whether it is aware of them or not. If an organizations does something, if it creates value, than it certainly has business-capabilities. If an organization hasn’t ever though about them — it’s ok, business-capabilities are not required to be identified. They just are. If you want to automate an organization or make some refactoring you definitely should define its capabilities, realize its implementation, how they communicate with each other, what business-processes take place for their operating. This activity results in a set of higher-level business-services. So business-capability is a concept from a problem space, while business-service being from a solution space. Business-services are defined in terms of corresponding business-capabilities. Moreover, there should always be bijective relation between them.

Business-service boundaries as an interfaceI think it’s very descriptive to compare business-service boundaries and interfaces. And this comparison is even closer to reality than it seems from the first glance. Service boundaries are defined by the declarative description of functionality provided by the service: it doesn’t tell how it’s going to do its job, but it tells what he can do. Say, software development department can develop some feature, but they wouldn’t tell you what classes they’d write, what libraries they’d use or what language. It doesn’t matter. But what matters is that the soft they write works correctly. QA department test the functionality, but it doesn’t really matter for anyone outside QA how exactly they do it: manual clicking, autotests or anything else. But it is the essence of interfaces — hiding the implementation and explicitly saying what it can do. A content of a business-service can be compared to a class as both of them are implementations of their contract: specific business-service implements its contract just like a class implements its contract represented as an interface. In other words, business-service boundaries and business-capabilities are very declarative concepts that rarely change. At least, more rear then anything else in any organization.

Business-services and organizational structureOrganizational structure boundaries and business-service boundaries don’t always coincide.

Say, you have an offline shop and a web-shop. The latter accepts online card payments. You can also accept cash upon delivery or in pick-up points. The single high-level business-service is engaged in these activities — Payment acceptance service. A business-service engaged in online card payments is located inside Payment acceptance service. Let’s call it Online payment service. It is an in-house development product, not very successful one. So one day CEO decides to replace it with PayPal. This company doesn’t relate in any way to your company. But Online payment service boundaries stay the same. Other services implementation can change as well: your enterprise might cease to deliver orders or outsource it. New offline shops might pop up, pick-up points might close. But it doesn’t affect the Payment acceptance service and all its inner services. They just stay the same.

Thus, business-service boundaries and organizational structure boundaries don’t strictly depend on each other. They have different motivation for change, different evolutionary forces. And the fact that PayPal has a remote API that we integrate with doesn’t make it a competent business-service. Actually, web-services’s boundaries and business-services’s boundaries do not have to coincide. The very fact of web-service existence doesn’t make it a business-service in it own right. It’s just an integration endpoint with asynchronous request-reply communication. This communication format can change, PayPal itself can be replaced, but business-service’s contract will stay the same. None of the implementation details should affect the whole enterprise.Thus what we need is to abstract away an external system’s API behind the business-service contract.

**_How business-services interact with each other_**Business-services’ communication, or, more specifically, interaction of these business-services’ business-processes, is defined in terms of events of domain where business operates. A set of events that business-services exchange with each other forms their interface, or contract. It’s not necessary that business-service contains an IT-infrastructure providing its contract, or any IT-infrastructure at all. These events can be implemented as a telephone call, an email or as a simple conversation.Now let’s consider business-services that contain an IT-infrastructure that implements a contract of a business-service. In case you’re into EDA approach, event exchange is implemented by publishing event-message in service bus. This message is defined in business terms, so it has clear and concrete sense. If we had no service bus, no IT infrastructure at all, the same message would’ve been implemented in more old-fashioned style I already mentioned: an email, phone call or a dialogue.

Events that are exchanged between services should not contain a lot of data. The whole point of events is not getting data through it. It is a notification that something happened. Moreover, if your events contain loads of data then probably your service boundaries are wrong and these services that have heavy data exchange should in fact be a single service.From the other hand these events should have enough data, i.e. they should fully self-contained. They should not have any references as it implies shared database which introduces tight coupling.

I have an observation though. The deeper a considered business-service level is, the heavier data exchange occurs between that level’s services. It’s quite explainable: high-nested level service are inevitably more tightly coupled to each other, still engaged in different business-functions though.

As a result, everybody from both non-IT and IT management to junior developers understand how an enterprise operates, how it’s moving parts communicate. And the most important, this understanding is formed with the same concepts for everybody in a company. The whole set of this concepts forms a Ubiquitous language.

Business-services and technical servicesSubsequently business-service will be used for building technical services. The contracts, events, protocols will be defined, based on business-services that know nothing about implementation but that are easily comprehensible even without technical background. In general our technical service boundaries lie inside the business-service boundaries, because our business-services contain not only software.Business-services formed around business-capabilities are the most stable things in the whole enterprise. People come and go, changing business-processes. New directors reshape the organizational structure seams. Business-owners will be replaced, buying or selling some parts of the business, outsourcing other parts. But business-processes’ boundaries defined by business-capabilities will stay the same. So it makes perfect sense to build technical services around these boundaries, that are the most stable part of any enterprise.So that is why there should be a bijective relation between a business-service and a technical service.

It is business-service that contains a concrete set of business-processes and notifies about the results of their job is responsible for publishing an event and for the content of the event. Moreover, in technical service there should be a single logical place, more precisely — a single line of code with a publishing of a specific event. So this is what I mean when I talk about the single source of truth. Meanwhile, there can be more than one physical publishers.SOA sums it up very precisely:

A service is the technical authority for a specific business capability.Any piece of data or rule must be owned by only one service.

This is a true manifestation of business-it alignment.

Besides that, by following this approach we get a service contract stability: business services rarely change, and corresponding technical authorities implementing the contract, as a consequence, rarely change either.

Finally I’d like to mention that physical and logical architectures don’t need to be the same. If there is a web-service that we integrate with — it’s not necessarily a business-service in its own right. If there are some separate logical parts identified — they not necessarily should be deployed separately. The opposite also holds true: parts of different services can be deployed in the same physical system.Well, there are even more perspectives than aforementioned logical and physical one.So summing it up I can say that physical process is a bad indicator of service boundary.

Similarity with Role-based interfacesServices perform a specific role. Their concrete implementation doesn’t matter. Warehouse stores stuff. Payment provider processes payments. Sales service communicates with clients. But services don’t live on their own, they interact with each other. So they can be thought of as coarse-grained role-based interfaces, each of them following Single Responsibility Principle. So alongside common questions you should ask yourself while trying to identify service boundaries, like, “What does this business does?”, “What’s similar among its different parts?”, “Is it accidental coincidence or is it the heart of the problem? ”“What’s different between identified part? Isn’t this difference just an implementation detail?”, you can try to look at the problem from a little bit different perspective: what coarse-grained roles are in this business?

Not delving into much details and differences between different frameworks and work groups (and not being an expert in any of them), I think it’s safe to say that a set of business-services and their interaction with each other are part of the Business architecture.

Business-capability mapping

I use business-capability mapping technique to identify business-service boundaries and their communication with each other. It is pretty intuitive and formalizes the concepts I’ve talked about in this post. It comes down to several steps.

**Higher-level service identification**Let’s define higher-level services first. This is what the whole business is about. These are its central functions, without which business loses its identity, stops being itself. Such services can be separate business. As a consequence, such functions can be outsourced or be acquired as a separate business. It is also useful to think of these higher-level capabilities as an intermediate steps on a way to the final goal — value delivery to the client.

You should only ask what, not how kinds of questions for defining this higher-level services. How question by definition gets the answer that is an implementation detail. At the same time you should be very alert not to confuse these higher-level services with organizational structure seams. Organizational structure is inclined to changes. Companies get acquired, get sold, functionality is outsourced, cutting out again an organizational structure. But the answers to what questions stay the same.

To understand what, you need to communicate with people who are aware of how business operates and where it goes. Communicate a lot, I should say. Although if you ask them about how business operates and what it does, very likely you get the wrong answers. Answers for questions you actually haven’t asked. But these answers can give you some clues.

First question that you’ll get an answer to is “How does it operate”, i.e., business-processes. It doesn’t fit our needs because business-process is some business-capability’s implementation detail. No one’s gonna serve you on a silver plate a totally implementation-abstracted business description — this is actually the main challenge in service boundaries identification. You should abstract existing business-processes until you get an answer to the question “What does business do”, not how. It should be a set of phrases consisting of a noun and a verb, subject and predicate, telling what business does. To make sure you get the essence of things, not just an implementation, it can help to recall how this business operated one hundred years ago (or conjure up how it might have operated), in times where there was no computers. What has stayed the same? What has changed? Definitely, implementation has changed — there are technologies over here. So if you define a service with purely technical name, like “Integrate a client”, this is at least a smell, but very likely that your boundaries are wrong. There was no such thing like client integration a hundred years ago. The chances are that this an implementation detail of some more high-level and abstract process. But the basic principles, basic concepts have stayed the same. These are the most stable concepts we are looking for, the concepts that technical implementation is to be built around.

The second question that you haven’t asked, but very likely get an answer to is “What is organizational structure”. As a result we’ll get its high-level description, its main departments. Well, this is useful anyway. You get something to start with. So what do I do in this case is trying to get from three to five phrases in average in aforementioned format, noun and verb. Of course it can be some derivative format, like “<Doing> <something>”. So this phrases should tell about the roles that specific department performs. So finally you get a set of role lists, where each list reflects all the department’s roles. Now you should take a close look at them. Are the roles belonging to the same department cohesive? Are this role lists loosely coupled? Is each of list items residing in the right list? Is any of this roles just an implementation detail? Is each of these lists a competent service in its own right? So shuffle the items along these lists. Play with them, you lose nothing. When you’re done compare the services that resulted from your activities and the initial lists. The chances are they don’t coincide. There are two options here: either you are smarter than the guy in charge of the organizational structure (e.g., CEO), or not. From the one hand there is a probability that an organization was evolving disorderly or just hasn’t have time to keep up with the new business realities. From the other, especially if business exists for a couple of more years and it hasn’t suffered any radical changes (which you can ask as well by the way), you likely haven’t work through your job comprehensively and just missed something.

Asking about how does the business make money is a good start as well. The following simple and short dialogue can give a lot of insight at the first:

— How do you make money? — We sell furniture. — Where do you get it from? Do you buy it somewhere or manufacture? — We manufacture it. We have a factory in Milan. — Where do you get raw materials from? — Our furniture is made of wood that we grow ourselves, and fasteners are purchased. — Do you deliver your furniture to customers? — No.

In this dialogue we started from the final step — customer value delivery, furniture selling. And step by step we went to where it starts — fasteners purchase and growing trees. I’ve omitted “Store furniture”, “Marketing”, but the main capabilities are already identified. They can be something like: “Grow trees”, “Buy fasteners and other raw materials”, “Manufacture furniture”, “Sell furniture”. If this factory delivered their furniture it would be a standalone capability — “Deliver furniture”.

Also trying to identify what parts can be outsourced or can be replaced with computers helps me in finding service boundaries. It helps me to stay away from concrete business-process and look for abstractions — something higher-level concept that aggregates all the ways of performing the same job.

Once again I’d like to mention that the laws on this, speaking the physics language, macro level hold true on micro level as well. One of the basic principles of any class is Single Responsibility principle. The same applies to a service — it should be cohesive. Any object should be properly encapsulated, checking its own invariants, combining data and behavior, preventing other objects from arbitrarily changing its data. And the same principle still applies to services, which is better known as service autonomy.

Higher-level service interactionAfter higher-level service boundaries are identified I look for ways they communicate with each other. Actually it’s hard to fully separate these activities and that’s normal. I can hardly imagine service identification without considering their communication paths. So, all of the ways count: phone, email, messenger, ordinary conversation, including informal ones. If the service boundaries coincide with organizational structure it’s not hard to determine their communication.

Immersing deeperFurther I repeat this process recursively, getting deeper in every business-service. You should stop when there is nothing to split. Well, it’s not as simple as it seems. “Nothing to split” is quite a vague concept. You often should just follow your intuition. But there are couple of beacons I use.

There is no sense in splitting a bounded context. But there is a kicker as well: there are times when you can’t tell definitely if it really is holistic bounded context. You can assume it roughly. For example further splitting leads to services that are an implementation detail of some cohesive business-process where each of its steps is temporally coupled with its neighbors. Or these services end up too fine-grained. Yeah, this “too” thing is ambiguous as well. But I don’t have more concrete criterias. For example, “to perform a payment” is a declarative, descriptional concept. You can perform a payment taking your money and having a walk to the bank. You can perform an electronic payment that can be processed with some payment system. Both of these ways are an implementation detail of cohesive business process — payment performing. We can exchange an events inside the service that this business process is part of, and these are its internal events that don’t make any sense for another more high-level services. These events are intended only for internal use, and they are an implementation detail of “Process payments” service.

Getting the big pictureSo the high-level image that I keep in my mind, that I use both as a mental model and a template for business-service identification, looks approximately like this (click to enlarge it):

Business-capability mapping for defining service boundaries

Firstly I tried to visually designate that any implementation can reside behind business-service boundaries, but its work results in the same events. And these are the events that define the notion of service boundaries, or service contract.Secondly, there are internal events that are an implementation detail of a service. And there are external events, ones that identify service contract.

Value chain analysis

There are some more ways for service boundaries identification that complement Business-capability mapping. I find them helpful as well.

Value chain analysis comes down to two points. The first point is the one I’m talking about for the most part of this post — treat your organization as a set of business-functions abstracted away from “how”s. The second point is that you should treat this functions as steps that your enterprise walks through to create demand and deliver customer value, like in furniture example above. It’s just a natural sequence of business-functions in your business. One part of it is Supply chain: materials you purchase, things you produce and the ways you distribute them. And the other part is Demand Chain, starting from Marketing, followed by Sales, followed by Services. It is really intuitive, and it’s likely that if you have already used Business-capability mapping then you already came up with Value chain analysis.

Capability chain basically means that you identify lower level services — just like I did with Business-capability mapping — but with higher-level services formed around activities defined during Value chain analysis. Nothing special at all, and here is a great example.

Once again: make sure your services are not an implementation detail — oppositely, they should represent the essence of business-functions. With this in mind it doesn’t really matter what formal technique you use. This simple declarative approach is very powerful.

In the next post I’ll give an example of identifying a service boundaries. Stay tuned!