Backbone and business-rules

What would be the ‘backbone’ of an enterprise-architecture? And where would business-rules fit into that picture?

This is a perhaps somewhat tangled follow-on from four different threads:

• my previous ‘backbone’ posts ‘Agility needs a backbone‘ and ‘Architecting the enterprise backbone‘
• Peter Bakker‘s exploration ‘The Enterprise Backbone‘
• Carole-Ann Matignon‘s post ‘Visual Logic: A picture is worth 1,000 words!‘
• Nigel Green‘s post ‘A thinking framework for Business/IT ‘Systems’ behaviour based on Cynefin‘

(The connections between these posts may not be obvious at first, perhaps, though I hope to straighten it out a bit as we go along!)

The core idea of the ‘enterprise backbone’ is that it’s some kind of structure – or something, anyway – within the enterprise-architecture that provides a kind of stable reference for enterprise agility.

Peter’s post describes a whole swathe of different views on the backbone theme: for example, Dave Gray‘s idea that some kind of backbone is needed in order to support what he calls a ‘podular’ architecture. We also had the seemingly-inevitable return to IT-centrism, in which one of the people referenced viewed the backbone solely in terms of a carrier for the metaphoric spinal-cord for the enterprise. Go look at that post before reading any further – it’s a very good overview of the various views into this context.

You might notice, though, there’s another whole side to this that doesn’t seem to appear much, if at all, in Peter’s collation of those views: the issue of governance. To me, the complexity of governance in a context that requires high agility is actually the core reason why we need a backbone. And to see why, we need to turn to Carol-Ann’s post, and then to Nigel’s.

Carol-Ann’s field is business-rules. Some of her post will be very familiar territory to enterprise-architects, in particular the Zachman-like tendency for business-rules to gain exceptions upon exceptions upon exceptions until we end with replacing ‘spaghetti-code’ with ‘spaghetti business-rules’. She also makes a very strong point with her ‘epiphany’ about the value of visualisation and visual models. The theme that strikes me most there, though, is her focus on lifecycle – that business-rules do not exist forever, but themselves will change over time and from one context to another:

The point we have not yet discussed much is life-cycle.  I am not referring here to the traditional Governance Process but rather the fact that business rules have a life-cycle of their own and the activities involving them are quite diverse.  It only occurred to me in the past year or so that my needs for looking at business rules keep changing based on my role as a user in addition to the nature of those business rules.

Governance is itself a set of business-rules applied to business-operations and business change – hence with governance of business-rules that themselves will change over time or context, we’re clearly looking at some kind of recursion here. Which is where Nigel’s post can come to our rescue.

(Note: For various reasons I’m very wary about applying the term ‘Cynefin‘ to any part of enterprise-architecture. Cynefin is a large body of complexity-theory and practice developed by Dave Snowden and others for use in significantly different domains than EA, and it’s not a good idea to mix them up. In most cases in EA and the like  – as in Nigel’s post – the only part that’s actually used in practice is its partitioning of a context in terms of Simple, Complicated, Complex and Chaotic, for which it’s probably more polite to use the explicit term ‘Cynefin-categorisation’ rather than ‘Cynefin’ itself. But I digress…)

In his post, Nigel actually uses the Cynefin-categorisation in much the same way as I do, as a base for cross-maps, and with the ‘Chaotic domain’ not as descriptor for true chaos (as I believe Snowden usually does), but more as a context of inherent-uniqueness or inherent-uncertainty. What Nigel adds there is a cross-map of various types or business-roles of IT-applications, and another cross-map for the all-important theme of trust – which itself changes in each of the categorisation’s ‘domains’, and which we’ll need to return to later.

For the moment, though, let’s focus on the categorisation itself. In the context Nigel’s used it, and as is general in EA contexts, the categorisation in effect represent a set of quantum-like ‘state-transitions’ within a spectrum of variability or predictability:

The phase-transitions in that ‘predictability-spectrum’ do have some real analogies with the ‘states of matter’ – in particular, that they do form distinct pairs, Simple/Complicated (‘ordered’) versus Complex/Chaotic (‘unordered’).

Within the Simple/Complicated pair, causal relationships can be assumed, either only-direct (Simple) or possibly also indirect (Complicated) – in other words, the realm of rules or algorithms. Straightforward business-rules and straightforward true/false logic will work well here: the same action should always lead to the same result, and – to paraphrase Einstein – it would be crazy to think otherwise.

But in the other Complex/Chaotic pair, simple rules don’t work reliably, or at all. Causality either becomes non-linear (Complex) or makes no sense because there are non-repeatable relationships (Chaotic). We actually end up inverting Einstein’s phrase: here it can be crazy to think that doing the same thing would not lead to different results. This leads us to something that does look much like the classic Cynefin frame – but note that we’ve actually arrived there from a different direction, via a focus on repeatability and business-rules:

The point here is that these Complex/Chaotic domains are qualitatively different to those in which we can use a simple true/false logic: any attempt to use a conventional ‘business-rules engine’ to manage a process with any Complex/Chaotic elements will soon drown in an impossible maze of ‘spaghetti business-rules’, as in Carole-Ann’s post – and it still won’t work anyway. We actually need to accept Complex/Chaotic elements for what they are, and not try to force-fit them into the Simple/Complicated mould – not matter how much IT-folks and business-folks would prefer them to do so.

Which in turns brings to the business need to balance the desire for control and repeatability on one side, and on the other the need for agility and resilience and ability to cope with real-world complexity. We see much the same kind of problems with reference-frameworks in enterprise-architecture and the like. And that, in turn, leads us on to the question of governance – which, in most people’s eyes, seems mainly to consist of applying someone’s rules or reference-frameworks – in relation to Agile – where it often seems that ‘the rules’ either don’t make sense, or by definition can’t make sense. Which can be t-r-i-c-k-y… especially when the business-politics are problematic too…

What we end up with here are several distinct themes that we need to unravel:

• the limitations of conventional true/false ‘business-rules’, and the need for a contextual modal-logic in Complex/Chaotic contexts
• the need to balance certainty versus agility in business-operations and business-process
• the need for governance that can be applied consistently across the whole control-vs-agile spectrum
• the need for governance that can adapt with life-cycles and business-change

Which is where we come back to what I’ve saying about the ‘backbone’ concept, especially in the ‘Architecting the enterprise backbone‘ post – because to me that concept, and implementation of that concept, can resolve all of those threads within one architectural approach or pattern. The simplest guideline here is this:

The backbone is everything that must be the same across any shared part of the organisation or broader-enterprise.

Anything else that isn’t shared can be pretty much as ‘agile’ or locally-specific as it likes.

And this principle applies to anything – information, process, facilities, business-rules, whatever – that is used within the enterprise, and might or might not be shared. To identify the options for the ‘anything’, I typically apply the taxonomy from the ‘single-row extended-Zachman’ – otherwise known as the ‘service-content map’ – that’s used in conjunction with Enterprise Canvas:

So the ‘anything’ that might need to be in the backbone could include not just information and other virtual-assets’ – as in the IT-centric view of ‘enterprise’-architecture – but physical ‘things’, brands (aspirational-assets), consistent business-functions and services (combinations of function and capability) that act on business-relations, common understandings about business-critical-events, and so on. Note that the categories of decisions also align with a Cynefin-style categorisation: Rules for Simple-domain, Principles for Chaotic-domain, and others in between – and some of these too might belong in a shared-backbone, maintained within formal standards, procedure-documents, training-processes or a ‘business-rules engine’.

For each of these items we would have standard references, standard sources, Standard Operating Procedures and so on. Information would typically be maintained under Master Data Management, a ‘single source of truth’ or the like. That’s the ‘backbone’: there’s a lot of information in it, but it’s a lot more than just information.

We would typically identify these items through the process described in the post on ‘Architecting the enterprise backbone’: establish the focus of the overall shared-enterprise, identify the items that are needed across that shared-enterprise, then identify the subset of those items that are core for our own organisation. A particular focus should be on anything that our organisation manages on behalf of the enterprise as a whole – for example, the national mail-service (such as Royal Mail or Australia Post) usually maintains the national information-base on addresses, post-codes, the link between people and address – because those items definitely need to be in the backbone.

At the same time, there are many things that don’t need to be in the backbone – and hence the legitimate role of shadow-IT, of context-local business-processes and so on. The basic guideline is that the more it needs to be shared, and the more consistent it needs to be, the more it will need to be in the backbone, and the tighter the governance will need to be. Conversely, the less it needs to be shared, the less it needs to be in the backbone, and the looser – more ‘Agile’ – the governance can be.

The complication is that in almost anything, even right out on the most agile edge, there will usually be some parts that belong in or will need to come from the backbone. Addresses, for example. Core information about customers. Standards, protocols, interfaces. Some of these will be mandated from outside, such as methods to process credit-cards or tax-record transactions, or health-and-safety regulations. So we need to be able to use those backbone-items, yet still support whatever agility and freeform-governance that may be needed. And that’s where a service-oriented whole-enterprise architecture will pay real dividends, because a service-oriented structure for the backbone should allow us to do any required mashups between ‘controlled’ and ‘uncontrolled’ items.

Hence, again, the need for a very clear understanding of how to use a multi-mode governance-structure that can work across the range of the Cynefin-style ‘domains’. And also the need for clear architectural-governance that can identify items developed out on the edge that need to be shared, and hence need to be migrated towards the backbone. This again leads to another type of lifecycle – which likewise will need its own business-rules and the like – about how items migrate into or out of the backbone over time.

The real role of governance for the backbone is about making sure that things don’t break unless it’s safe for them to do so. Anything in the backbone tends to be business-critical for a lot of people – sometimes far beyond our own organisation. We must handle those kinds of items in a responsible manner: usually a ‘fail-safe’ manner, and certainly with respect to those people who would be affected if it changes or fails. Hence the need, usually, for formal ‘Waterfall’-style governance, so that everyone affected can have their say, or at least be informed with sufficient forewarning to be able to do something in time to adapt to the change. Away from the backbone, we don’t need that level of control – in fact we often want it to ‘fail’, otherwise we can’t experiment with anything new, or adapt to internal or external change.

This would give us a spectrum from front-line context to domain-specific to core backbone, with changing forms of governance, which we could summarise as follows:

The crucial concern is the combination of sharing – or interdependency, rather – and business-criticality. Even right out on the most experimental edge, items are often shared with others. But if that sharing, or the structure of that sharing, isn’t itself business-critical, it actually doesn’t matter if it breaks – hence the governance can be a lot looser, hence more oriented towards Agile and the like. If it is business-critical, and if it does matter to others if it fails or changes, then it needs tighter governance – and that requirement for tighter governance in that specific aspect or context should not be in question, because it matters there.

The complications tend to arise when someone foolishly believes that a ‘one-style-fits-all’ approach should be applied everywhere, to every governance context… Sometimes it comes from the ‘control-freaks’; sometimes it’s from the over-rebellious Agile folks; either way, it misses the point that we will always need different governance for different contexts. A ‘one-size-fits-all’ approach cannot and will not work: hence we will always need something that will help us choose what style of governance should apply in different contexts. To me, the architectural pattern of backbone-versus-agile provides one of the best means to do so, because it provides defined, consistent alignment and balance between:

• a spectrum of governance from tight-control (rules) to open-choice (principles);
• a Cynefin-like categorisation of repeatability from Simple (SixSigma-type very high repeatability) to Chaotic (inherently-unique)
• a spectrum of low context-change (low required-agility) to high-change (high required-agility)
• defined governance-mechanisms to handle churn into and out the backbone.

One last point comes up in Nigel’s post: the centrality of trust. In some ways rules represent an absence of trust; one of the roles of trust is as a counterbalance to excessive rule-based governance. Ultimately we do have to trust that ‘the rules’ or whatever will be followed in some sense, otherwise all connection with the aims of the organisation and shared-enterprise will be lost. Yet Nigel also suggests that perhaps even the relationship with trust – and hence with governance – will change with the Cynefin-style domain: trust is expected (Simple), mandated (Complicated), developed (Complex) and explored (Chaotic). Some themes there, then then would be well worth exploring further as we go deeper into the deign and development of a backbone-architecture.

Comments, anyone?