Understanding Business Services

A business service represents an agreed delivery of some parcel of capability from one agent to another agent.

Understanding services properly requires a combination of all six of the viewpoints I have defined for business architecture.

• The capability viewpoint describes the parcel of capability
• The activity viewpoint captures the delivery protocol
• The responsibility viewpoint captures the agreement aspect
• The motivation viewpoint covers the outcomes and performance measurement (especially relevant for outcome-based pricing) 
• The knowledge viewpoint covers service semantics
• The cybernetic viewpoint covers service governance

For more on these viewpoints, see my post Towards a Metamodel of Business Architecture.

There are many different types of service. In Services Like Laundry, I explored the laundry metaphor, suggesting that many services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry. In Services Not All Like Laundry, I list some other types of service. Other useful classifications of service include Philip Boxer's characterization of rcKP - services at the edge.

Services may be active or latent. An active service is one that is regularly or continuously used, so we can observe it in operation at any time. An active service is expected to provide value to the receiving agent whenever it is used. A latent service may be rarely needed, but its existence may be necessary for business continuity and risk management, and therefore provides value even when it is not used. Latent services may only be observed at exceptional times, such as in a crisis. Some businesses therefore run crisis simulations from time to time in order to exercise the latent services and check they are working.

See also Tangential Service (September 2008)

Related topics: Business-as-a-Platform, Mashup, Pricing
An archive of Twitter debate on this blogpost was captured by Storify 

Laundry as Intelligence

During the "troubles" in Northern Ireland, the British Army operated a laundry - an apparently innocent laundry with some additional hidden functionality - checking dirty clothes for traces of explosive. [Washington Post via Bruce Schneier]

In my earlier post Services Like Laundry I said "I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to anyone". Clearly the actions of the British Army would count as a breach of this kind of expectation, but this would be justified by its effectiveness as a clever counter-terrorism measure. However, laundries might well test for various other substances, or test the DNA of any stains on the clothing, for a broad range of purposes other than counter-terrorism.

So what's the lesson from this? Basically, if you have any illicit substances or just embarrassing stains on your clothing, you can't trust the laundry service not to notice. And you certainly can't specify this not-noticing as part of the service contract - what are you going to do, draw the laundryman's attention to the thing he isn't supposed to notice?

And what if the laundryman noticed your shirts were getting a little frayed about the collar, and sold your address, together with details of your designer-label preferences, to a mail order shirt supplier? You might think this was unreasonable if you knew about it, but you would probably never find out. You might receive a mailshot from the shirt supplier, but you probably wouldn't connect it with the laundryman. (One possible mechanism for tracing abuse of your name and address is to give slightly variant names and addresses to every supplier, but lots of organizations nowadays have clever data cleansing software that wipes out these variations.)

How does this apply to other kinds of service? If I use CRM-as-a-service, how can I prevent my service provider picking up information about my customers? If I use a third-party delivery service, how can I prevent the service provider selling details of my customers and their purchasing habits to my competitors? How can I even specify this as part of the service level agreement?

WS Security standards cover some aspects of confidentiality and trust, but this merely relates to the security of a message in transit (at the technology level), and not to the broader questions of confidentiality and trust between two parties (at the enterprise level).

According to legend, the automatic telephone exchange was invented by an undertaker (Almon Strowger) who believed his business was being redirected to his competitors by corrupt telephone operators. (See Call Forwarding.) So this suggests a possible answer to this difficulty is to redesign the service architecture to reduce the enterprise vulnerability, supported by more sophisticated technology. For example, does your CRM provider really need unencrypted names and addresses, or can you pass your customer data through an encryption module?

So what's the lesson from this? You need an enterprise view of trust and security that is supported by (aligned with) a technology view of trust and security. The relationship between these two views is tough.

Services Not All Like Laundry

In my post on the Laundry Metaphor of Services, I said that all services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

We need a notion of business services that covers at least five types of service (plus composites, hybrids and cross-overs).

Product Service: "I give/get you something"
Examples: Catering, Information, Certificate

Typically the service is fulfilled in the form of one or more deliveries (events). A product service is typically triggered by a specific request by the service user, and fulfilled by a response by the service provider. The right to trigger product services may sometimes be delegated to the service provider - either by defining some business rules, or by delegating authority as part of a challenge-based service (see below). Charging is typically per product or per delivery. Or it may be governed by a prior access service (such as subscription).

Transformation Service: "I do something to your something"
Examples: Car Repair, Laundry, Haircut,

The service provider takes temporary charge of something that belongs to the service user, and returns it in an improved state (e.g. mended, cleaner, tidier, more fashionable).

Responsibility Service: "I take care of something for you"
Examples: Office Cleaning, Track Inspection & Maintenance

Typically the service provider takes ongoing responsibility for a defined entity or outcome over a defined time period. Beside the core service, the service provider may provide regular or adhoc reports about the state of the entity to the service user. Charging will often be based on a flat fee. An alternative form of charging may be based on time and materials, but this demands a higher degree of trust between the service provider and the service user.

Access Service: "I allow you to do something" Permit/Enable/Empower
Examples: Subscription, Licence, Fishing Permit, Rail Use / Landing Slot

The service is typically delivered in the form of a message that contains a key and/or allocates a resource. Access rights and allocations typically expire if not used. Access is typically tied to a specific identity (e.g. user, machine) and is not normally tradeable or transferable. May also include traded options and the like, which confer a defined right to some other service or trade.

Challenge Service: "I solve a problem for you."
Example: Diagnostics, Develop Software, Adapt Business On-Demand.

The service provider often (but not always) specifies the solution. The service provider may also specify the problem. This entails a high degree of trust. This may also involve some shared risk and professional indemnity. Charging is typically problematic, unless it can be done within an arbitrary “professional” fee structure.

Each type of service requires different kinds of charging and service level agreement, and relies on different forms of quality assurance and trust. In my post on the Business Service Architecture (Railway Edition), I mentioned the difficulty faced by the company in the UK with primary responsibility for the railway network (originally Railtrack, now Network Rail). Railtrack was delegating maintenance work (Responsibility Services) to engineering companies and subcontractors, while selling rail availability (Access Services) to train operating companies. Railtrack seriously miscalculated the complex algebraic relationship between two different kinds of service level agreement, resulting in a serious rail accident in Hatfield.

Not all like laundry then.

Does Multi-Tenancy Matter?

Multi-tenancy basically means that the service provider is supporting several customers with the same resources. (There is some ambiguity about exactly which resources we are talking about - hence the embarrassingly public disagreement between Oracle and one of its reference SaaS users described by Phil Wainewright in Many degrees of multi-tenancy.)

Gianpaolo Carraro previously made the point that if I'm a service consumer, I shouldn't care about multi-tenancy - The multi-tenant emperor has not clothes (August 2006), and now adds I can't believe we're still talking about this (June 2008).

With services like laundry, I really shouldn't care if my dirty clothes are put into the same load as everyone else's, as long as the service provider can reliably sort them all out and return them correctly. Some providers may think that the cost savings from multi-tenancy of the washing machine doesn't justify the hassle of labelling and sorting the clothes, but that's surely their problem not mine.

But if I have doubts about their competence and reliability, and if I have to double-check everything (= increased transaction cost) because I feel there is an increased risk of error on his part, then it becomes my problem as well.

Gianpaolo uses the example of a restaurant kitchen. If someone on the next table orders the same dish at the same time, surely I don't care if the chef puts two slices of meat together into the same pan. Well I do care if it means that the chef is tempted to compromise, or pays insufficient attention to my special requirements. As a service consumer, I may have some theory about the likely behaviour and incentives of the service provider (Gianpaolo talks about people wanting to show off their architectural capacities). But this only matters to the extent that it affects what I end up with, or when.

SaaS inherits from SOA the principle of encapsulation - the idea of separating the specification (WHAT) from the implementation (HOW). But a lack of trust between service consumer and service provider, as well as possible incentive incompatibility, leads to a breach in encapsulation. For SOA and SaaS to work properly, you need a good line on managing quality and risk. But that's a story for another post.

Services Like Laundry

Just over a year ago, fed up with the over-use of the Lego brick metaphor, my colleague David Sprott proposed the laundry model of SOA (Explaining SOA to the Business). Antony Reynolds of Oracle quoted this in his blog today (The Laundry Model of SOA), which is what reminded me.

Both David and Antony talk about the contract basis of the laundry model.

• I delegate something (in this case cleaning) to the laundry service.
• Officially I don't care how it's done (although the term "dry cleaning" seems to indicate a preferred implementation).
• The laundry service accepts some (limited) liability for any failure.

These are typical characteristics of pretty much any kind of service, more or less. But there is a particular characteristic of the laundry service I want to talk about.

• I entrust the service with something (an asset) that belongs to me.
• I expect the laundryman to be discrete. I do not want my dirty linen washed in public - in other words, I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to inquisitive journalists.
• If something goes wrong with the service, then my asset is damaged. The potential liability is linked to the value of the asset, not to the value of the service. (If my dress suit is ruined, I am not going to be happy if I just get the cost of the cleaning reimbursed.)
• I do not authorize the service provider to use the asset for his own purposes. (I do not expect the laundryman to borrow my suit for his daughter's wedding.)

These characteristics are common to many services. I do not expect my CRM provider to try and sell things to my customers, nor to allow identity thieves to access their information. (Indeed, the customer information may not belong to me either; it arguably belongs to the customers themselves, who have entrusted me with their information according to the same pattern.) I do not expect my ISP to read my email, or interpret my search history. (Perhaps I'm being naive about that.)

However, there are many services where this is not clearly agreed. Perhaps I get some cut-price service, and this is only economically viable because the service provider expects to be able to broadcast some advertising to me or my customers. But if I am careless with the small print on the contract, I may not have understood this aspect of the deal.

And there are many services where this simply doesn't apply. For example, information services often simply involve transferring information from the service provider to the consumer, while Software-as-a-Service may simply involve transferring functionality. Obviously there are trust issues here as well - I trust the BBC to provide accurate and balanced news, I trust my internet security provider to protect me from viruses, I trust Microsoft Excel to calculate my profits correctly - but these are not linked in quite the same way to specific assets.

So I think the laundry metaphor is a very useful one, but like any metaphor we must be careful not to push it too far. All services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

---

See also

Services Not All Like Laundry (July 2008)
Laundry as Intelligence (Oct 2008)
Understanding Business Services (November 2012)

Service-Oriented Business Strategy

A service-oriented modelling approach helps us to identify alternative business strategies, involving the creation and deployment of added-value services.

• Identify value-added business services that can be seen (by customers) as more relevant to the context of use. 
• Identify value-added business services that are flexible / reusable (by customers) in multiple use-contexts. 
• Compose value-added business services in an efficient and reliable manner from internal and external capabilities. 
• Provide a service platform to support customers in composing our business services to solve their problems. 

I am in the process of defining an extended example from the pharmaceutical sector. The first part will now be published by CBDI in May 2005.

Why Pharma?

We selected the pharmaceutical industry for a worked example because it provides a good example of a complex information supply chain. A drug company (in collaboration with a distributed network of research and test) produces a drug, together with lots of information relating to the drug. There are several different categories of information user: the patient who takes the drug, the medical practitioner who prescribes and/or dispenses the drug, the health service or insurer that pays for the drug, and the regulator who monitors the safety of the drug.

Pharma appears to illustrate some general characteristics of complex service networks, so this example should be of relevance to other industry sectors.

Above all, for SOA illustration purposes, pharma has two advantages. Firstly, it isn't the same old boring examples everyone else is using (finance, travel, retail). And secondly, it isn't military.

In the past, drug companies have been able to make substantial profits from an essentially drug-centric process, getting high sales volumes for its blockbuster drugs from a largely undifferentiated mass of patients with a given condition. This business model treated the physician or clinic as pretty much equivalent to a retail outlet, and did not involve any relationship with the end-customer (the drug consumer). But this business model is subject to major challenge from several directions.

Approach

We model a business as an open system, whose viability depends on robust and appropriate interactions with a dynamic environment. (This contrasts with the closed system approach adopted by many traditional business modeling methods, whose focus is on producing a complete and coherent account of some internal configuration of processes and services, against a fixed view of the environment.)

We model a service-oriented business as a system of systems. Services here may include tasks automated in software (typically but not necessarily rendered as web services) as well as human tasks.

SOA is not just about decomposition – producing fine-grained services with maximum decoupling. Equally important is to think about composition – how these services can be integrated in many different ways to support a wide variety of demand.

In general terms, there are a number of distinct categories of stakeholder, each performing fairly complex functions in relation to the pharma value chain. A key SOA challenge for a drug company is to provide services to all these different stakeholders in a consistent and coordinated yet flexible way. In order to meet this challenge, we need to produce a series of models, from different stakeholder perspectives, showing how the services can be composed in various contexts of use.

In our view, the essential shift for service-oriented modeling is to view the services, not from the provider's perspective, but from the customer's perspective, and in the customer's context of use.
 

Strategic Reframe

From the perspective of business strategy, what we are looking at here is a strategic reframe of the pharma business. What is the drug company actually selling, and to whom? How does information and services become an integral component of the overall product offering?

The ultimate source of value for the patient is defined in terms of health. The provision of health to patients is based on the deployment of complex medical knowledge by a physician, and this in turn relies on information about particular drugs and combinations of drugs from the drug company and elsewhere. This essentially defines a value ladder, in which the value of the drugs contributes to the value of the heathcare.

While this kind of strategic reframing is widely discussed, what service-oriented modeling provides is a systematic way of determining and analyzing the strategic options, in terms of the value ladders that can be supported.

Can the drug company solve all the problems of healthcare? Can the physician solve all the problems of healthcare? The answer in both cases is of course NO. There is huge complexity involved, and the design goal for SOA is to define a reasonable separation of concerns between the physician and the drug company, that allows each of them to manage an appropriate part of the complexity.

---

Previous Post: SOA Pharma