Sunday, February 01, 2009

Why Service Orientation should start with Systems and not (always) end in systems

In publishing this I'm throwing caution to the wind (and ignoring, in part, the good advice of a respected friend!). Chris Bird, suggested that I should avoid talking about Systems Thinking, Service-oriented Architecture and other such consultantese. But I've decide I will talk about Systems Thinking and SOA as they relate to a broader world-view of services (given the focus of this blog).

To start the discussion, however, I'd like to quote Chris: “ SOA starts in the wrong place. The tools are tools and not grand strategies. I don't look at the screwdriver in my hand and say, "Cool, now what projects can I undertake?" I think about what needs fixing in my house and what tools I need (aside - the checkbook is my favorite tool)”.

Mindful of Chris's words and a client's SOA-related organisational challenges in mind, I thought it was about time I added my two-pennies-worth to the SOA-doesn't-work debate. My observation is that many SOA projects start in the wrong place - that being in the technology weeds i.e. Conversations around ESBs, WS*, Registries, EJB, XML et al. I believe the first step towards 'service orienting' a business is taken by applying Systems Thinking (that is Systems in an ecosystem sense) rather than thinking about Services per se and certainly before technology view of SOA). Most importantly, the notion that a business is comprised of multiple, interacting, 'Systems' of people, processes and technologies (agents of the system) that cannot be viewed in isolation one from another but accepts each system/sub-system works within a unique set of values.

Taking a fresh Systems Thinking (capital 'S' Systems from now on) perspective helps to breakdown the more traditional organisational and process bounded views of the business and that the complexity of the behaviour of the business is best tackled by examining the interactions between 'Systems' that often span traditional boundaries. This then helps layout the organisation as a set of 'System' behaviours that can, for example, be examined as core or context to the business operation/strategy/well-being. I've found that with this approach, its possible to evolve certain 'Systems' into 'Services' by defining the Consumers, the Policies/Contracts that apply, the Events that trigger action and the Content being exchanged (physical and/or informational). This 'Big Services' (Systems)view allows the business to see how to chunk-up aspects of the operation in new ways that helps with business problems such as: simplifying post M&A situations, executing major transitions, outsourcing. And, from an IT perspective, where/how to apply SOA, COTS packages or SaaS for that matter.

I've been accused of being too idealistic when I say Service Orientation starts in the boardroom not the IT department. I agree, it's often hard, if not impossible, to get SO on the business agenda but if your SOA is being 'sold' as a way to achieve 'business relevant' efficiencies and associated cost reductions through service reuse, then board members must be the sponsors. This becomes most obvious when organisations realise they must change the way they fund software development and/or procurement projects to realise the desired sharing and reuse.

So how can 'Systems Thinking' be introduced to the CxOs without appearing to be too academic?
The rule is to avoid talking about Systems Thinking and, for that matter, SOA. Instead, the discussion is focused on delivering business value around a topic that is front-of-mind for the board: Compliance, Profitability, Green-agenda or Strategy execution might be such topics. Then the trick is to use simple 'Systems Thinking' techniques and tools (akin to S.W.O.T. or Forcefield and Mindmaps or PowerPoint) to start to describe the emergent services.

As Chris points out, it's important to be looking at the cross-cutting concerns of the enterprise (and the extended enterprise - but extended from a business sense, not an IT sense). I believe that getting the CxOs to buy-in to SOA via Syetms Thinking - (without necessarily trying to teach them the Theory!) - is the way to make SOA work, and for that matter, improve many aspects of their business operations and strategy execution with or without SOA or with or without IT systems.

To bring to a close, I'd like to paraphrase Chris again:

“We must focus on what the enterprise wants to achieve. There are many ways of getting "it done". Goldblatt in "The Goal" makes some useful analogies. The goal in manufacturing isn't about keeping the machines busy, it is about increasing value - converting raw materials into products at the optimal rate for making profits (even if you have to underutalize resources). In the SOA world, the corporate goal is not to maximize the use of IT tools, (to suborn everything to the technical services oriented architecture), but to look for services that deal with the Events that the business has to deal with. I think we have to get the very loose coupling done first before thinking about SOA in companies. Until the businesses think in terms of hand-offs instead of commands, they won't get any of the benefits possible anyway”.

I believe subtly applied Systems Thinking will help us put controls where controls are needed, don't control what doesn't matter and help us answer the question; “How do you focus on what is important, and at the same time not miss the critical details?”

The Cynefin framework and 5D lens are both tools that can help introduce Systems Thinking to broader audiences.

As always, I welcome your comments.


Anonymous said...

Hi Nigel

Your VPEC-T methods provide a perfect counterpart to business-oriented SOA, because one of their core aims is to identify the values that do and need to pervade the layered services of the enterprise.

As I've described in my book "The Service Oriented Enterprise" (contents and sample chapters at ), the essential anchor for a service-orientation is the enterprise vision and values. From a Systems perspective, using Stafford Beer's 'Viable System Model', the values percolate through every service and every part of the enterprise via the 'pervasive services' that support enterprise values such as privacy, security, health & safety, knowledge-sharing, innovation and, in a commercial context, profit.

Perhaps meet up sometime to explore how we can link the two sets of methods together, to create a full business-oriented service-architecture?

Adrian Apthorp said...


This fits well with my view that SOA comes naturally as a result of good architecture, which in itself requires a systems thinking and systems engineering approach. After all most of the key tenets of SOA are well established systems engineering principles put in an information (or business) systems context.

The challenge (or at least one of them) I see is how to tear the 'business' away from the comfort blanket of talking about / managing their IT tools. Many times recently I've lamented the demise of business analysis, and techniques like VPEC-T help us in improving the situation, but there is still this desire to deal with more tangible concepts; my application. How do we make systems thinking REAL in the same way that applications are perceived?

Anonymous said...

Nigel, Adrian

What we did in AusPost to make the systems-thinking ideas real was to construct a Business Functional Model (aka Enterprise Function Model), which provided a layered view of the entire scope - it was immediately nicknamed 'Post On A Page'. This got the managers and other business folks thinking holistically as a matter of habit - they could see where their work fitted in with the whole, and so on.

We than mapped the business information onto that, and then mapped the apps onto the information-map - the opposite way round to how it's usually done. This showed us all manner of overlaps and gaps in information coverage and sourcing; and because it's linked to the holistic model, we can see straight away where the impacts would be.

So we don't talk about 'systems' as such, we talk about 'business functions' - which in effect are mid- to high-level services, described independent of implementation (IT, manual, machine or whatever).

We deliberately bypass any mention of IT-applications or the like until we really do need to talk about implementations. That way we can keep it in the abstract systems-thinking space for as long as possible. And again, the longer we can hold back on that, the more we're able to apply non-IT-centric exploratory techniques such as VPEC-T.

Nigel Green said...

Adrian (this is a repost of my earlier comment which I should've proof read!),

I think question we should ask is “How do we make information system's architecture real?” And I think the answer is to demonstrate the connectedness of the world today and point out that its not possible to look at IT as something separate from people and processes in that information system and therefore its architecture must holistic. The numerous failed implementations of packages and bespoke software should demonstrate the need for other than an 'application' perspective. The application is just part of the whole and must be consistent with the other parts – for example, as we say, it must 'respect' the business operating model.

I know you have found ways to express this connection to the operating model right up to the CEO regarding country level operating differences in DHL. But I'm sure business folk will continue to think 'applications' and we architects will continue to push for a holistic, systems thinking, approach. Much like CxOs never really see each others point of view – maybe the answer for us lies with the credibility (trust relationship) between the CIO and the others (assuming the CIO understands the need for architecture!).

Nigel Green said...


you might find this link of interest:

Seven Rules of Business Alignment

I downloaded the full .pdf and have got halfway throught it. It much reference to the value of Business Architecture and the associate absraction from 'apps'.

Adrian Apthorp said...

Tom, Nigel,

Tom's AusPost example reminds me of some similar approaches we've taken in the past, including a CBT that related process, to information, then applications and middleware etc. This type of approach definitely has the potential to make the different perspectives and their inter-relationship more transparent hence making information systems architecture more real.

However, my question (How do we make systems thinking REAL in the same way that applications are perceived?) was really about how to develop a greater appreciation of systems thinking in general. So REAL in the sense of "natural". Put it another way, should systems thinking / engineering be taught and at what stage in education should it be taught?

Chris Bird said...

Adrian, Nigel and I have some shared background, so this might be a bit too much inside to make complete sense.

It constantly frustrates me when the business teams talk in terms of applications - and because the business teams didn't have a great deal of staff turnover, they know the applications better than some of their architecture counterparts. Of course the architects that I am thinking about are really part of the business, but the business has a tendency to think of them as rather lightweight - not enough IT to be useful and not enough business to be credible.

So, somehow a way of looking at the business as a simulation of itself can become a way t get the necessary traction - somehow to get the necessary traction to have a kind of parallel Systems Thinking implementation of the business to show what is happening IN REAL BUSINESS TIME is perhaps one way to get the necessary traction. Of course that isn't terribly easy! The trick is to do enough of it to show how better to think about it - informational only using the existing transaction streams to show places for improvement.

Remember that to be disruptive (which is after all what we are talking about here), you can't use the tools of the incumbents. Also remember that in any disruptive approach the first solutions don't do the current stuff as well as the current implementations.

Cybersal said...

Really interesting discussion - so many facets of it to comment on. I agree about needing to be cautious about using the term 'Systems Thinking', because there seem to be many differing perspectives on what systems thinking is (it's not unlike Enterprise Architecture in that respect), in addition to what Nigel has described here.
Some people equate it with systems dynamics.
Peter Checkland provides a good description of his 'softer' perspective on it here. He sees it more as an ongoing 'process of enquiry'

John Seddon also calls his approach for applying Lean thinking to service design, 'Systems Thinking' yet it's quite different from Checkland's.

I've just been reading Patrick Hoverstadt's book on the Fractal Organisation which is basically 'Viable systems modelling for managers' and which tries very hard to use language that is meaningful to mere mortals. I can't really judge whether he's been successful because I had already swallowed the Systems Thinking 'red pill' before I'd read it. See the review on Amazon