Service Based Design - a phrase with the words ‘master’ and ‘data’ nowhere to be seen. Ah, so that’s it, build a few services, knock out a few corporate schemas, forget about data (storage is cheap after all) and the savings will just accrue. Some savings will accrue but the full potential won’t be realised if the importance of managing the underlying data isn’t recognised – or for that matter the underlying business. A service is sandwiched between business and data.
Service Based Design is essentially about ‘chunking down’ what would otherwise be huge blocks of code into more manageable chunks - ‘manageable’ in the sense that one can tweak a ‘chunked down’ piece of code with much reduced demands on testing. It is also about aligning the code (or ‘services’) with the business so that business functionality is represented by services. The reader will have spotted that in this paradigm the services can, to a degree, be only as good as the business processes, so ludicrous non re-engineered business processes are not a sound basis on which to build a Service Based Design.
What activities are of value to the customer?
Well engineered business processes are lean – they aspire to deliver to the customer a service (or product) that gets ever closer to that desired by the customer whilst consuming less resources (time, money, equipment, space, inventory etc) – yes I know I’ve nicked this paragraph from the classic book ‘The Machine That Changed The World’ (Womack, Jones, Ross 1990). Lean analyses a process through the eyes of the customer, establishing what activities are of value to the customer. For this purpose activities can be divided into three types:
- steps that create value to the customer
- steps that don’t create value to the customer but are none the less considered essential
- steps that don’t create value to the customer and are removable
The aim is to identify and remove the third case.
A service is only as good as the data that underpins it
So we have these really lean business processes and we are going to build a set of services to support them. Now, what gets passed into a service and what gets passed out… that would be data wouldn’t it? Yes, business data in fact.
We use services all the time even if we don’t know it. Register an account on more or less any website and you’ll be plonking a postcode and maybe a house number into a service which then searches an address file and sends back a list of possible matches. Sounds easy enough but even this simple example illustrates some of the data challenges. The service is only as good as the data that underpins it and the service will rather dumbly surface inaccurate data if the underlying data is inaccurate. If the address file is out of date or inaccurate, then the data surfaced by the service will be too. Imagine the level of customer frustration if the service refuses to surface the address that the customer lives at. The only slight silver lining in this example is that the error is obvious. It’s not difficult to imagine services that surface inaccurate data and the consumer of it has no idea it is wrong.
Another data quality aspect in the above example is the need for a common single view of the truth. Two address location services using two difference address files could potentially answer the same request with different answers. How do you know which is correct ? Sometimes such differences don’t matter, often they do. Where services can really provide, well a service, is when they are capable of mediating across multiple sources of data, determine the correct data and surface it.
How good does a data schema have to be?
Each service surfaces its data via a schema (which really just mean a data specification). This means it has declared to the world how it will present its data. Any user of the service knows what data it will receive – or does it ? Just how good does a schema have to be for a user to really know what data it will receive ? Reading a schema with a Provider Name element might lead the user to assume this element contains the name of the provider. Great but this still leaves scope for misunderstandings. How many names can a provider have – more than one and, if so, which one is this ? If Provider Name appeared within, say, a Contract schema, is it the legal name, trading name or some other name? It is often as useful in defining data to explicitly state what an item is not as much as it is to well define precisely what it is.
Data schemas for services have to achieve two almost contradictory requirements. They have to be both very precise about what data is being surfaced whilst being abstract enough to withstand change (and most certainly agnostic to any consideration of how a given application actually holds the data). This latter requirement is necessary so that any change to the ‘back end’ plumbing behind a service is isolated from the consumers of the service who, despite re-engineering behind the service, will still receive their data in the same format. The consumer simply doesn’t have to worry about all the ‘back-end’ re-engineering behind the service.
“So we have these really lean business processes and we are going to build a set of services to support them” and the services are going to encapsulate the various data related goodies articulated above. So we will have data supporting Service Based Design but we won’t de facto have Lean data. ‘Lean data’ … sounds like a subject deserving of a separate blog.