Evolutionary architecture
Domain Driven Design for Services Architecture
This article is the first in a three-part series examining how we can achieve ROI from our service-oriented architecture initiatives and deliver on the promise of building business capabilities quickly. We believe the key to success is well-factored service architecture. These articles will provide high-level guidance on building a well-factored service architecture. A lot of our thinking has been influenced by Domain Driven Design (DDD) and our experience applying DDD at large, enterprise clients.
One particular area of investment has been around building a service-oriented architecture (SOA) that promises to connect various information silos in the company to create new business capabilities.
But there are a couple of reasons why this hasn’t succeeded. Often, the services are built to serve one-off business cases, which makes them hard to reuse and bloats the service portfolio. In some cases, service interfaces are overly generic—disconnected from the realities of the business—so fail to deliver business value effectively. Essentially, organizations lack a coherent service strategy that delivers business value incrementally, while building a strong platform of business capabilities.
Typical issues due to lack of a coherent service strategy include:
We recently built Reserve in Store capability for a client’s eCommerce application. The capability was dependent on core services such as catalog, inventory and store services. But the business capability was deeply entangled with the online channel’s presentation logic and the dependent core services. What’s more, because the boundaries of the core services were not well understood the logic for those core services lacked cohesion.
As a result, the business found it hard and expensive to make simple changes because of the number of touchpoints involved. Offering the same business capability over new channels like mobile would mean rebuilding the capability. From a development standpoint, this complexity resulted in bugs in production—and it was hard to pinpoint their origin. It made the developers lives difficult because of the cognitive load and having to maintain code that was not core to their domain. In a later section, we will revisit the Reserve in Store capability to see what a well factored service architecture looks like.
In our work with clients, we’ve encountered many instances where organizations have experienced difficulties in creating service abstractions. These can be summarized as:
Let's take an example. For the inventory service, we had been providing inventory to our clients in two parts. The first part would be the base number of units available and then the ‘offset’, the number that represents the units that could be potentially unavailable due to theft, misplacement or damage. If the client application wants to be absolutely sure about the inventory availability, they would use the base units minus the offset to get the inventory number. But if they were about to lose a sale and do not mind taking a chance, then they would use just the base inventory number.
This approach exposes too much of the mechanics, rather than the higher order business intention of expressing inventory ‘reliability’ as a first-class concept. If the service were to be modeled in a business-truthful fashion, it would expose inventory number along with its reliability. So a sample response would be 10 units available with 100% reliability, with an additional five units at 50% reliability. This approach hides the complexity of the inventory management in the service, including the ability to further improve the reliability of the inventory. Each existing client of the service would then instantly benefit from any improvement in the reliability calculation.
This clearly needs to support the web and mobile channels. For a well-factored service architecture, we start with foundational capability services that represent core organizational assets like catalog, inventory and store. These serve as a single source of identity, lifecycle and related logic for those assets.
Then we build business capability services, such as Reserve in Store, that encapsulate the business rules for those capabilities and provide a seamless experience across all the channels.
Finally, we build client experience services that are responsible for tailoring the business capabilities to the channels—thereby providing the best possible customer experience.
In the above example, it would be quite straight forward to expose the Reserve in Store capability over a voice-operated agent such as Siri. Simply write a new service to manage the conversational experience for Siri and hook it up to the business capability.
It’s also quite easy to build new business offerings, such as sending the Reserve in Store customer promotions that are available in-store.
We believe that well-factored services enable your organization to hide complexity, deliver business capabilities quickly and enable independent evolution of individual services.
In Part Two, we’ll provide high level guidance on building a well-factored service architecture. In Part Three we'll provide general guidelines for defining service boundaries — whether it’s decomposing an existing monolith or building a brand new set of services.
We would like to thank Bill Codding, Brandon Byars, Damian Knoop, Evan Bottcher, James Lewis, Jeroen Soeters, Joel Parker Henderson, Kyle Hodgson, Martin Fowler, Patrick Turley, Scott Davis, Steven Lowe, Zhamak Dehghani for providing feedback on the article.Visit our Digital Platform Strategy homepage for more.
Service-oriented architectures haven’t delivered quick results
Today’s businesses face a challenge. They are not able to deliver customer-focused capabilities quickly to a market that is globally distributed and changing fast. Customers expect these capabilities to be delivered via their channel of choice, be it physical store, call center, website, mobile or voice-activated device. Many businesses have made significant investment in IT. Few are getting the returns they expect.One particular area of investment has been around building a service-oriented architecture (SOA) that promises to connect various information silos in the company to create new business capabilities.
But there are a couple of reasons why this hasn’t succeeded. Often, the services are built to serve one-off business cases, which makes them hard to reuse and bloats the service portfolio. In some cases, service interfaces are overly generic—disconnected from the realities of the business—so fail to deliver business value effectively. Essentially, organizations lack a coherent service strategy that delivers business value incrementally, while building a strong platform of business capabilities.
Typical issues due to lack of a coherent service strategy include:
- No strategy to support the delivery of existing business capabilities over new channels, such as mobile, TV, voice activated devices. This stymies attempts to reach new customers or enhance the experience for existing ones.
- Business capabilities are duplicated across the organization, introducing inefficiencies. For example, at one of our previous clients, the purchase order creation process was duplicated across multiple locations, making it harder to optimize the global supply chain.
- Key assets like customer information, purchase history and inventory information are spread throughout the organization. This makes it very difficult to get a single view of these assets, which is needed to create new offerings and drive cross-sales and up-sales to existing customers.
Well-factored service architecture is the missing ingredient in realizing the ROI on service investment
We believe well-factored services is the key to securing ROI on service investment. Let’s take an example to see how services are built in practice.We recently built Reserve in Store capability for a client’s eCommerce application. The capability was dependent on core services such as catalog, inventory and store services. But the business capability was deeply entangled with the online channel’s presentation logic and the dependent core services. What’s more, because the boundaries of the core services were not well understood the logic for those core services lacked cohesion.
As a result, the business found it hard and expensive to make simple changes because of the number of touchpoints involved. Offering the same business capability over new channels like mobile would mean rebuilding the capability. From a development standpoint, this complexity resulted in bugs in production—and it was hard to pinpoint their origin. It made the developers lives difficult because of the cognitive load and having to maintain code that was not core to their domain. In a later section, we will revisit the Reserve in Store capability to see what a well factored service architecture looks like.
In our work with clients, we’ve encountered many instances where organizations have experienced difficulties in creating service abstractions. These can be summarized as:
- Missing abstractions. For instance, a business capability that lacks a clear definition of where the business capability logic belongs. The Reserve in Store capability mentioned earlier would be an example of this.
- Leaky abstractions. This is where service logic leaks out to consumers. An example is where the internals of a legacy system such as legacy system identifiers leaks into the consuming services.
- Wrong abstractions. Here, a service is either too fine grained or too coarse grained. So services built to satisfy one-off business cases end up being too fine grained, that leads to chatty interactions between services. As a result, unrelated services get clubbed together to improve performance.
Business-truthful abstractions are the key to well-factored service architecture
A well-factored service architecture breaks services into ‘business-truthful’ abstractions. Business-truthful abstractions model the business as close to reality as possible. They hide complexity and model the business intentions rather than the mechanics of the solution. They reduce cognitive load for teams consuming the services. They also allow teams building the service to evolve them independently.Let's take an example. For the inventory service, we had been providing inventory to our clients in two parts. The first part would be the base number of units available and then the ‘offset’, the number that represents the units that could be potentially unavailable due to theft, misplacement or damage. If the client application wants to be absolutely sure about the inventory availability, they would use the base units minus the offset to get the inventory number. But if they were about to lose a sale and do not mind taking a chance, then they would use just the base inventory number.
This approach exposes too much of the mechanics, rather than the higher order business intention of expressing inventory ‘reliability’ as a first-class concept. If the service were to be modeled in a business-truthful fashion, it would expose inventory number along with its reliability. So a sample response would be 10 units available with 100% reliability, with an additional five units at 50% reliability. This approach hides the complexity of the inventory management in the service, including the ability to further improve the reliability of the inventory. Each existing client of the service would then instantly benefit from any improvement in the reliability calculation.
Well-factored service architecture in action
Let us take a concrete example of a well-factored service architecture. We are part of a eCommerce company tasked with creating a service architecture to support omnichannel capabilities, such as Reserve in Store which should be familiar from our earlier example.This clearly needs to support the web and mobile channels. For a well-factored service architecture, we start with foundational capability services that represent core organizational assets like catalog, inventory and store. These serve as a single source of identity, lifecycle and related logic for those assets.
Then we build business capability services, such as Reserve in Store, that encapsulate the business rules for those capabilities and provide a seamless experience across all the channels.
Finally, we build client experience services that are responsible for tailoring the business capabilities to the channels—thereby providing the best possible customer experience.
Figure 1: A well-factored Reserve in Store service.
Having a well-factored service architecture is a key to rapidly enabling new and innovative customer experiences. It allows you to compose or stack various organizational assets—technical or business—enhancing your ability to deliver business capabilities. In this example, the Reserve in Store capability builds upon the Find in Store business capability which hides the complexity of dealing with unreliable store inventory. The key is in recognizing capabilities such as Find in Store as a first class business capability and not having it built inside the Reserve in Store capability. This makes the Find in Store capability easily available to other capabilities as well such as Order in Store and hence avoid having to solve the problem of dealing with unreliable store inventory again.In the above example, it would be quite straight forward to expose the Reserve in Store capability over a voice-operated agent such as Siri. Simply write a new service to manage the conversational experience for Siri and hook it up to the business capability.
It’s also quite easy to build new business offerings, such as sending the Reserve in Store customer promotions that are available in-store.
We believe that well-factored services enable your organization to hide complexity, deliver business capabilities quickly and enable independent evolution of individual services.
In Part Two, we’ll provide high level guidance on building a well-factored service architecture. In Part Three we'll provide general guidelines for defining service boundaries — whether it’s decomposing an existing monolith or building a brand new set of services.
We would like to thank Bill Codding, Brandon Byars, Damian Knoop, Evan Bottcher, James Lewis, Jeroen Soeters, Joel Parker Henderson, Kyle Hodgson, Martin Fowler, Patrick Turley, Scott Davis, Steven Lowe, Zhamak Dehghani for providing feedback on the article.Visit our Digital Platform Strategy homepage for more.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
