In most application landscapes services tend to pop up like mushrooms, with little to no attention being devoted to decent service design or decent service-oriented architecture (SOA). Frankly put, this means you’re doing it wrong.
The reason for the number of services growing almost uncontrollably within your application landscape often is that a new service is built whenever an application needs some information from another one. When yet another application needs that same information, a new service must be built, because, guess what, the service the first application is using does not fully comply with the intentions of the newest one.
This smells a lot like the good old spaghetti landscape.
In this case, what you’re doing isn’t creating a service-oriented architecture, but creating an application-oriented architecture using services. This often leads to a bunch of services doing the same thing.
One of our customers was once using three versions of a single service: a small, medium and a large one. This meant that every consumer wanting to use this specific service first had to find out which version he needed to use. In case he wanted to change his service usage, it was very well possible he’d have to use another service because he needed just one additional attribute even though he still needed the exact same functionality.
This example begs the question: why do you need three services doing the exact same thing? Isn’t it enough to have only one?
When designing services, you need to start from the business needs, not from an (existing) application interface. When you need a service to register a customer, the service is defined by how business understands the concept of a customer, not by how a customer is represented in one system or another.
This implies that attributes that are considered to be mandatory by business also have to be mandatory in the service. For example, a customer cannot be registered without a name even though this is technically allowed by the CRM system.
When we start working together with a client at AE, we start by analyzing the business domains: what are they, who owns them and how do they perceive the information model? Only after this thorough analysis do we start to design services, based on the business requirements.
So if your business needs to be able to register a customer when it first applies, we’ll create a customer service with a functionality to do so. (Note that it’s not relevant at this point which applications lie underneath.)
Every application architect should have a basic understanding of SOA and services. When it comes to services, they need to be able to look beyond their application or project and look at things from an enterprise-wide perspective.
When you commit to proper service design, you’ll find that SOA is an enabler for your organization to take the next step in outside-in thinking: API management.
Interested in additional tips on how to design your services well? Contact us.
