Let’s hear it for service centricity
Do all roads lead to services?
Lab An elderly lady attended a public lecture given by an astrophysicist on how the Earth goes around the Sun and how the Sun circles about with countless other stars in the Milky Way. During the question and answer session, the woman stood up and told the distinguished scientist that his lecture was nonsense, that the Earth is a flat disk supported on the back of an enormous tortoise.
The scientist tried to outwit the lady by asking, “Well, my dear, what supports the tortoise?” To which she replied, “You’re a very clever young man, but not clever enough. It's turtles all the way down!”
A Brief History of Time, Stephen W. Hawking
For decades, modularity has been a familiar best practice in programming terms. When Ed Yourdon and Larry Constantine wrote their seminal paper on structured design in 1975, they were building on themes already considered for languages such as Algol 68. At the core of structured design was the idea that software modules should maximise cohesiveness within themselves, whilst minimising coupling (aka dependencies) between modules.
This principle was built upon by luminaries such as Grady Booch, when he put his own spin on what made a good software ‘object’ back in the early days of object-orientation. The principle was to choose artefacts that were least likely to change. In business these tend to be the entities around which the organisation is constructed – policies and claims in insurance for example, or patients and prescriptions in healthcare. Brad Cox, another early thinker who devised the Objective C programming language, suggested that software should work in a similar way to hardware. By talking about software IC’s, he abstracted the details of the internal workings, instead placing the emphasis on the interactions enabled by the interfaces that communicate with the external world.
These ideas formed the backbone of best practice in Object-Oriented programming, which begat component-based development, which begat service-oriented architecture (SOA), web services and so on. Throughout the evolution of application development, design and architecture, the core principle of focusing on the service being delivered, as opposed to the technical gubbins required to deliver it, has remained key.
A similar process has taken place throughout the history of IT operations. Right from the beginning of commercially available IT, for example, many organisations were unable to afford computer facilities of their own, and relied on ‘service bureaus’ for their payroll and so on. Meanwhile, as IT has evolved to be considered in terms of the services being delivered, rather than the facilities provided, disciplines such as IT Service Management (ITSM) have emerged to enable their end-to-end management. From both a development and an operational standpoint, good IT practice has always been, and probably always will be, based around understanding the services it provides. It’s important to recognise that the services are the same, whether they are being discussed in terms of how they are developed, or how they are managed. Without getting into motherhood, the principle behind a service lifecycle, which considers a service from its inception right the way through to its ultimate removal, is sound.
There’s a couple of clever twists on the service theme, first of all that many IT departments today are as much about sourcing things in from the outside, as they are doing things in-house. As we have seen from our research, it is the smarter organisations that know how to source services. We have corroborated this message through numerous conversations with IT decision makers. Supplier management is not just about contracts, but also knowing what you want in the first place.
This principle extends into the Software-as-a-Service (SaaS) and cloud-based (hosted) IT delivery models. There’s nothing fundamentally wrong with these approaches to IT delivery, but getting the best out of them requires thinking about the service required, and then identifying providers that can deliver on the need.
Aww, and there I was saying I wouldn’t go into motherhood – but it is fascinating to watch some providers suggesting that such models are good just because they are ‘cloud-based’.
A second twist is that the theme plays very well outside of the IT department – to the extent that, looking at how departments such as Finance, HR, Customer Services and so on deliver services, it rather looks as if IT needs to catch up a bit. Going up a level, business itself is all about providing attractive and useful products and services to customers at the right cost, by adding value to raw materials and services from suppliers.
It really is services all the way down – a service an organisation wants to provide to its customers will be dependent on a hierarchy of internal services, some of which can be automated or supported by automation. The trick is to recognise that every time the word ‘service’ is being used it means (or it should mean) the same thing. If IT success is dependent on having the right conversations, a shared core principle that extends across all domains offers a good starting point. ®
It's not just a turtle
The scientist was right. Obviously a flat disc would topple off the tortoise/turtle (some ambiguity there) so you need some kind of filler between the chelonian and the disc.
I know - let's use four elephants. Scaled up to be in proportion to the turtle, they will be big enough and they will absorb the motion of the turtle manoeuvring around the hazards of space etc.
Er.. hang on, hasn't this been thought of before? And more than once?
Service consumption (not delivery) as a core capability
There may be a distinct danger that the only people who understand recursion (all the way down) will have to be born before ’58 (Algol’s bird year) or at least before ‘68 (the Algol refresh). During computer science class my kids today learn how to type in word or powerpoint (I am not kidding).
Now the Achilles heel of OO always was that everyone wanted to build and nobody wanted to consume. The good news is that the core capability of today’s youngsters is consumption (as we just saw, an essential skill for successful IT going forward , see also http://bit.ly/consumerisation).
Too bad today’s standard for IT Service Management (ITIL V3.0) has taken the eye of the consumption ball somewhat and is unlike 1.0 and 2.0 focused almost exclusively on service providers nor service consumers. While the cloud will mean that for the average organization the management of service consumption will be way more important than managing service delivery.
The SMI (Service Measurement Index) as initiated by CA technologies and endorsed by Carnegie Mellon looks like a good first step (just like consumers/buyers of a new TV set , first look up what other consumers found, so should organizations about to consume a new service check out what other organization found of this service. Guess for cloud “reuse” is just as important as it was for OO and thus SOA. So we better hope “reuse” does better this time?