Object Oriented Business Models

Increasingly, in our consultancy practice, I am seeing business models which remind me of the ‘object oriented’ (OO) style of computer programming. The idea of OO is that each part of the programme is cut up into self-contained ‘black boxes’ or objects, which handle parts of the overall work. Each object has a set of methods (ie things it can do) and an interface (ie how you ask it to do these things, how you get the results back.) Provided you know the interface, you don’t need to know how the object achieves its results. Every well-written object should include self-tests, so that you can be confident that it will deliver the result you want. Well written objects should also be ‘loosely coupled’: for example, a database management object should be able to work with different types of data and different databases, so that you can use it almost anywhere you have to deal with a database. It should be as self-contained as possible: containing any basic data it needs in order to operate, and with its methods hidden or ‘private’; external programmes never see them or use them directly. Everything should go through the defined interface: this way, if the object finds a better way of doing something, you still see the same interface and the same results.

There are a lot of business models like this today. For example, many oil companies used to own shipping fleets, or road tankers. Now, the trend is to outsource these functions. Some businesses work largely as franchises: for example soft drink companies may only own the brand and the formula; all the production and marketing is done by bottlers, who buy the concentrate and the right to use the brand, and are obliged to adhere to a set of rules about how it must be used.

There are several advantages to this:
1. Companies can specialise in what they do best. If your core skill is finding, producing and refining crude oil, why should you operate tanker fleets? It ought to be more efficient, economically, to find a partner whose speciality this is. If this partner is loosely coupled, he can (for example) move any sort of crude oil from anywhere to anywhere else.
2. There is less managerial overhead. You hand the function over to someone else and let them worry about it.
3. You can agree terms in advance, so part of the economic risk is taken by the partner.
4. It creates a degree of legal separation. If something goes badly wrong, it may not be your fault and you may not be held liable. If they are ‘loosely coupled’, they are probably also working for your rivals
anyway.

However, there are some problems:
1. In times of scarcity, it may cost more to get a good partner than to do it yourself. (For instance, when shipping rates are high.)
2. You cannot guarantee the loyalty of a partner: someone else may make him a better offer, for example, or he may go out of business. If you lose an important partner suddenly, this can have a dramatic impact on your bottom line.
3. The partner has different priorities to you. If it comes to the survival of his business, he may cut corners on yours.
4. Your partner may not have the same high standards as you; and if you start to audit him for safety etc then you are taking back a lot of the managerial load (and possibly legal liability) that you tried to get rid of. You may still be held fully or partly liable, even if the mistake was made by your partner. And even if there is no legal liability, there may be serious damage to your brand name.

For example, petrol is effectively a commodity product. The cost of moving petrol from terminals to filling stations is high, so typically it is picked up from the nearest depot, whoever this belongs to, and has come from a refinery linked to that depot by pipeline. Petrol sold by a filling station under the brand name of Company A may in fact have been manufactured by company B. If company A uses a proprietary additive, this has been mixed in by Company B at its terminal.

Franchise food chains are another example. They may have a well-known brand name over the door, but they are owned and operated by smaller companies. The brand owner may work hard to enforce standards (of brand
usage, hygiene, food safety, etc.) but ultimately that brand in that area is in a ‘black box’ owned by someone else and subject to his problems.

When you write an object, as a programmer, you need to anticipate all the things it will be asked to do, so you can prepare methods to do them, and you also have to include interfaces to these methods. Then you need to write exception handlers – ie, what does the object do if something does not work as expected? Does it perform a default function instead? Does it simply fail and send an unhelpful error message? (My favourite is the possibly apocryphal message from a complex piece of corporate software which read: “Error 1234: Harry used to know how to fix this, but he quit.”)

If your object is properly designed, it will have interfaces to handle any possible system failure, and all its exception handlers will act ‘gracefully’ – ie they do something sensible, and don’t just return a meaningless message. As a fairly frequent programmer I have to confess that I’ve never written any object that was quite that good.

In business relationships the same principle holds. If something goes wrong, you want to feel that the partner has a ‘method’ for handling the incident, and an interface that will allow you to tell him what has gone wrong, and allow him to reassure you that he is handling it. And, since humans are so much slower than machines, you also want to have an assurance that the problem will be solved to a given extent in a given time – in other words, a Service level Agreement (SLA). In some cases you may need a 24/7 contact point, and an assurance that a full incident response can be mounted at any time.

Alas I have come across a lot of cases where I do not believe that these assurances either exist, or are realistic. Not many companies have proper incident response or business continuity plans, nor do they self test these plans often enough. Where plans exist they are often inadequate. They may, for example, cover some problems in providing a service, eg finding alternative road tankers if one is unable to function. But they don’t fully cover wider incidents, eg dealing with a serious spill from a tanker.

Testing is easy with a computer programme. You build ‘unit tests’ into each module. It takes next to no time to run them, and this can be done automatically, for instance very time you load the object, or every time you alter it in any way. (Despite this I doubt if many modules have enough tests, or that these are run often enough.) Tests usually return a simple ‘pass or fail’ result. Whereas testing a company’s incident response plans is time consuming, and requires management effort, so it is often not done at all. Interpreting the result may not be straightforward. (The other problem is that ‘unit tests’ only rest parts of a system. It is far more difficult to write ‘end to end’ tests that show how the parts work together as a whole.)

The result is that a business model which relies on outsourcing may function well in normal situations, But in a serious incident, you discover that the interface to address the issue is not there, and the partner does not have adequate response functions. These things then have to be improvised under the stress of the incident.

Of course, writing a module, or running a company, to take care of every possible exception, would be enormously expensive. In most cases it would simply be a waste of time and effort. However, it’s all too easy to take a short term view and design a system which looks good and works well, most of the time, but is not properly equipped to handle the sort of major incidents that do undoubtedly occur, even if they don’t occur very often. Perhaps businesses should learn from OO programming and ensure that
1. all interfaces with partners are clearly stated and understood by both sides, and that these interfaces cover unexpected situations.
2. the partner has methods to deal with the most likely incidents, and at least some method for starting to handle unlikely ones.
3. these methods are tested, at least in a simple fashion, at meaningful intervals – for instance, when a service provider takes on a new client, or when it makes a major change to its own internal systems. Reports of these tests should be shared with clients, even if only the fact that they have taken place and )hopefully) were successful.

Leave a Reply

Your email address will not be published. Required fields are marked *