Revamped Services Fabric Blog

I decided I'd spend thisn weekend tarting-up this blog and making use of the new blogger template gadets etc.I've also added more meaningful labels to make filtering on a specific topic easier (e.g. click VPEC-T below to see all VPEC-T related posts)

Other news: Richard Veryard created a Lenscraft wiki that promises to be a interesting place for developing a number of themes my Twitterati pals and I've been discussing for a while.

Photo Credit ShoZu on Flickr

A Question of Meaning

A flurry of emails, tweets and posts that took place after Richard Varyard posted a question that asked how 'meaning' is addressed in VPEC-T (the main points of which are captured in this thread).

The reaction from VPEC-T practitioners & supporters was interesting in that they were quick to defend the simplicity and ubiquitous & 'Agile' nature of VPEC-T due to that simplicity. A view I share with them.

To quote my colleague, John Schlesinger, “Meaning is a sky hook for VPEC-T” ( and by implication not a missing dimension per se) and Peter Evans-Greenwood suggested: “Light-weight, user and business centric approaches (such as VPEC-T) provide us with a way to remain relevant and a more dynamic and light weight business world”.

The table below is my interpretation of Chris Bird's email that described VPEC-T as columns and an open list of 'Cross Cutting Concerns' that shape meaning across the five VPEC-T dimensions.

Full size image here.

From my point of view, this discussion helped me with a 'writer's block' problem I was having with where and how to take VPEC-T forward. It became very clear to me that I need to start to build an 'Open' repository of VPEC-T Use Patterns. These patterns will make VPEC-T more 'real' through description of how the dimensions are applied in particular situations and to tackle the sort of 'Cross-cutting Concern' that Chris mentions.

I hope to start work on the repository soon and plan to host it at vpec-t.org (I'll post on this blog when I get something worth looking at up).

Here's the concept map I used to order my thoughts following the stream of emails, tweets and posts.

VPEC-T Google Group

I've set up a Google Group for discussions and resources related to the VPEC-T Framework, Anyone can view and post to the discussions there however, non-members' posts are moderated. 

This will effectively replace the now defunct VPEC-T wiki (since Scribblewiki went to the wall!)

n.

5D Lens (aka VPEC-T) as a Mindmap

Roy Grubb, a consultant in Hong Kong, has produced a great Mindmap of the VPEC-T framework as part of a comprehensive review of Lost In Translation and the VPEC-T approach to IS analysis.

Roy's work has reminded me to mention Mindmapping as a tool for applying VPEC-T, particularly when doing a desk exercise. The a pre-developed Mindmap or Concept Map before by a 5D Lens workshop is a great way to get the thinking started.

Thanks Roy!

n.

The Tao of Enterprise IT Episode 2

Heres the next episode in the Tao of IT webcast.

Click To Play

Tao of Enterprise IT

Here's the first episode of a webcast based on a presentation I made to CIOs and IT practitioners in Hong Kong in September.

Click To Play

I decided to break it down to 3 or 4 episodes to make it easier to consume over the web. I hope to post the other episodes over the next ten days or so.

In the meantime, if you watched this episode and are hungry for more background to the 5D Lens (aka VPEC-T) please take a look at the original blog post here and the book website. You will also find reference scattered throughout this blog - so feel free to explore!

If you have any comments about this first episode, please feel free to post them here.

Thanks

Nigel.

Business behaviour before technology

Prompted by Carl Bate's post and Andy Mulholland's post on the Capgemini CTO blog, I felt compelled to add my two-pennies-worth. Recently, I've been working on the seemingly endless challenge of describing why the VPEC-T framework helps both business and IT. To me, the points Carl and Andy make about Business and IT being fused into 'Business Technology' driven by the Web, are reasonable observations but dance around the edge of what really matters - that being behaviour. My hypothesis is that the behaviour of organisations, communities and individuals is what's really behind the 'Web' effect. And it's the examination of behaviour (including and in the context of unfolding events) that helps us understand how to make better us of information technology. Moreover, when we focus on behaviour we can look at both 'top-down', directed aspects and the bottom-up emergent aspects. So isn't a Business Architecture a simple expression of behaviour of a particular network of value (Value Network)?

Here's my attempt at explaining how VPEC-T helps uncover the behaviour of an organisation.

Generic VPEC-T

view presentation

As always, comments and builds most welcome.

Context Aware Dialogue Systems

I've been having a number of really interesting discussions with a broad range of IS architects, Systems Thinkers and other luminaries in the art of understanding the true nature of Information Systems. Part of this discussion was the feedback Carl and I got from Chris Yapp on 'Lost In Translation'. In summary, he feels that we didn't cover enough on the 'I' or IS and that while he likes the VPEC-T framework, he would like us to tackle the knotty problem of making sense of the data/information/knowledge/wisdom 'stack'. In our defence, we did think about this and decided it was too hard-a-nut-to-crack when we wrote LiT - we also felt we might go into concept overload in the first book!

Well, I guess I've decided a new idea has firmed-up enough in my mind to give it an airing – the working name of this concept is Context Aware Dialogue Systems (CADS). The idea is to provide an antidote to Six Sigma Dogma and Ever-Decreasing-Ontologies (Taxonomy-wolves dressed-up as Ontology-lambs – the IT world having grabbed and a corrupted yet another word!). The basic idea is that all social (human) information systems are better described as dialogues regardless of how or if or what type of technology is used. CADS are plastic and elastic in nature – they are often highly unpredictable but not necessarily. The thing is that the CADS concept can be applied to ordered and predictable and the more organic and adaptive systems of dialogue (see the Cynefin framework).

It's a bit like something Adrian Apthorp said to me when we were debating asynchronous versus synchronous architectures several years ago. Adrian argued that an asynchronous approach was better starting point than synchronous even if aspects of the architecture would be implemented using a synchronous design because synchronous could always be implemented over asynchronous but never the other way around. So my hypothesis is that to think of all information systems and any information technology solutions as CADS at the outset would help us better understand the nature of the 'requirement' (desired outcome) and inform the solution design. Even if the solution is a configured package or service (actually I'd argue CADS analysis is even more important in such cases).

To go back to the Data-to-Wisdom stack, my hunch is the dialogue-centric nature of CADS would help focus attention on the various types of 'protocol' (and therefore use) as we work up the stack (a bit like the old OSI Model but applied to people, software and hardware). CADS would give us a consistent way to model any type of information exchange between people. One last thought for this first CADS post, CADS and VPEC-T are sibling concepts. CADS is a Dialogue Description framework and VPEC-T is an IS Thinking framework.

This concept is a way off being fully-baked. Your early reactions, thoughts and challenges, as always, welcome.

n.

An Information Systems ‘face’ on System Thinking (x-post)

Firstly, I'm suffering from limted bandwidth for blogging, so please forgive this cross-post.

I would like to get Services Fabric reader's feedback on the relationship between IS focused techniques versus business change techniques. So can I ask you take a look here?

Nigel.

From Blog to Book

I'd like to apologise for my lack of posts here over the past few months - here's the reason:

http://www.lithandbook.com/

My co-author Carl and I have been beavering away on 'Lost In Translation' for the past eight months or so. Followers of this blog will notice that the core framework introduced in the 'LiT' book was first published on this blog

There'll be lot's of follow-on activities over the next 8-10 weeks – 'LiT' discussions and development will be reported on the LiT blogs.

Of course, I hope you'll read 'Lost In Translation' and and join in the discussion. As you can imagine, I'm pleased to see the thinking being taken forward. It just goes to show blogs can become books!

You can download a pdf of chapter one here.

Thanks goes to my fellow Services Fabric commentators, Sam and Adrian and to others from this blog community who provided practical examples for the book ( contributions are acknowledged in the book). - Thanks NG.

The Case for a Clear Distinction between Events and Content.

I should explain my terminology here. When I refer to Events I mean the information about a business-meaningful event – not the actual real-world experience of the event. Similarly, when I refer to Content, I am also talking about information - in the sense of the ‘content of a book’. So, both Events and Content are categories of information and naturally form part of an Information System, in the broadest sense.

Events:	The real-world proceedings that stimulate business activity – sometimes in a pre-defined sequence but often not. These are the triggers for action.
Content:	The documents, conversations or messages that are produced and consumed by business activities. These are the dialogues we use to share a plan, a concept, a history and/or the details of a person, place or thing.

Events (Event Messages) do carry information. However, the information carried has only one purpose: to provide sufficient context to make the Event meaningful to a person or a software component, working on their behalf. It is important to maintain the logical[1] distinction between Event and Content.

Fuzzy and Precise Events:

Events can be regarded as both highly structured and precise and highly unstructured and imprecise messages within a common Event ‘envelope’ (general structure). For example, a movement tracking system may receive highly structured signals from RFID or GPS devices which are then converted into equally structured human-readable business events, But the same system might also receive much more unstructured Event information, possibly capture a ‘text’ message on a mobile phone that might alert of a delay caused by heavy traffic. The emphasis is placed on the value to the human consumer as opposed to, sometimes unhelpful, or misplaced, information engineering rigour. That’s not to say, however, that over time a loosely defined Event may benefit from being made more structured and precise and that some Events need to be implemented as semantically-agreed/syntax-precise data structures from day one.

To illustrate further:

• Fuzzy Events -The Event information may not be as complete or as rigorous as, for example, a structured document or data record might require. However, it might be really useful to know that an Event has taken place even if the information conveyed requires a degree of human interpretation. Maintaining separation between the Event and related Content makes it possible to get value from the Event information without confusing it with the, necessarily precise, business Content information. This is because the Event and the Content have fundamentally different business purposes (as illustrated above). Recognising this difference can be the key to avoiding lengthy data modelling and data standards work (around Identity schemes and other codified data) and thus ensures a degree of business value is delivered as early as possible. The Event may not be interpretable by an IT system – but it may be of use to a person, in the same way a scribbled jotting on Post-it-Note might provide valuable information.

• Precise Events - Paradoxically, the opposite is also true. Content, in the form of a conversation or audio/visual media might be difficult for an IT system to consume and interpret, but is fine for human consumption. In this case, the separation can have the opposite benefit – the Event is always IT ‘friendly’ in the sense it can always be processed in the general sense of routing and subscription, and the Event ‘context information’ may also be processed by rules and derive a new fact or implication.

Aggregated Events become Content over time.

Unfortunately, having said that it’s important to make a logical distinction between Events and Content, the reality is less clear-cut. This is illustrated by the ‘Wave/Particle’ nature of Event information in IT Systems. While they exist as independent, content-light, ‘Business Signals’ during minute-by-minute business operation, they are also ‘Content’ when they are retrieved in sets and aggregations from an ‘Event Log’ or Data Warehouse. Fortunately, from a business point-of-view, this seems to be easily understood. The debate around Event and Content, however, is more prevalent in the IT community and stems from years of building IT applications and databases without a clear distinction between the two.

---

[1] In some circumstances the physical implementation of an Event-based system may include ‘Payload Data’ (Content) bound to the Event. The same logical separation rules, however, apply. The value of this separation identified in MIT’s/AutoID Inc’s original work on the X-internet and EPC standards.

The Problem with Processes

Businesses, in their planning and design activities, have a tendency to envisage the world as a set of neatly ordered, well-planned, pre-determined and sequenced set of activities. This approach sets out to ‘decompose’ these models into highly detailed descriptions of all the interacting parts within an ‘end-to-end’ process. This process-centric approach often falters when it spans departmental or external boundaries .Why? Because it is hard to capture and represent the softer, but often, more knotty problems associated with differing business values, politics et al. This appears to be at the root of the problem business face as there operations become increasingly diverse, dispersed and generally, more complex.

Such an approach promotes a high degree of engineering rigour and, by necessity, complexity that is, by nature, hard to consume (particularly by the business decision makers and the end users). The sheer volume of information produced means that the overall business context gets lost in the production of engineering wiring-diagrams. This approach is often blind to the real-world behaviour and human interaction ‘on-the-ground’. Often the focus is slanted towards process and organisational How than the business What.

Business are a tangle of Behavioural Threads

The reality is that most businesses are more organic and random than pre-determinable and mechanistic. Many of these Threads of behaviour work very well without top-down design – the folk on-the-ground are just simply good at getting-the-job-done and they often make things work despite unhelpful top-down processes, procedures and systems. This is the world of Post-It-Notes, spreadsheets and personal networks. This thought might lead us to believe that businesses must simply throw our hands up and just accept a more fatalistic and unplanned approach to running the business – a cross-our-fingers-and-hope model! Perhaps, however, there’s another way to grab back control by taking a slightly more abstracted but at the same time, real-world aligned approach.

Threaded Beads - Perhaps then it would be useful to think about “Processes” as a series of more abstract themes or “Threads” of business behaviour that run in all directions across the business enterprise. Each Thread is made up of ‘Beads’ of Capability or Service that are triggered by real-world events that undertake specific tasks and deliver interim of final outcomes.

Threads & Beads operates under differing sets of Values (Business Principles, Desired Outcomes, Drivers & Goals)

Each Thread has a set of guiding values around a specific business mission. Each Bead along the Thread also operates under a set of specific values. For example, a particular Bead might be implemented as service from a 3rd Party and will therefore inherit a set of values from outside the enterprise.
Sometimes one set of overall Thread values may conflict with another set. For example, the ‘Retail Distribution’ Thread and the ‘Oil Exploration’ Thread of a multi-national Oil comapany may be shaped by very different and, in some areas, conflicting values.
Values drive behaviour and motivate people and systems towards desired outcomes. Changes in the priority of values in combined sets can have a dramatic affect on the results. Perhaps a technique for capturing, analysing and managing multiple interacting Value Systems is needed?


Threads can cross paths and share or otherwise interact with Beads.. So a single Bead may need to function within the context of multiple, and some time conflicting, overall Thread values. Many business are focused on removing duplication and improving agility which is leading them to initiate efforts to discover candidates for, and embark on the design/implementation of, shared-services (both human-based and/or technology-based). Understanding the nature of these joins and unions is at the heart of this work.

Beads aren’t evenly spaced along the Thread

The relative degree of binding (joined-ness) between one Bead is often implicit inthe enterprise’s functional (Org Chart) or Operating Model. However, making this degree of linkage between one Bead and the next more explicit seems to be an important input to business decision making. Put this in the context of a world where third-party services play a more active part in overall business operations.

This thinking comes, in part, from looking at the pros and cons of Service Orientation. That is, the degree to which it may make sense to truly Service-Orient aspects of business operations, thus avoiding the “Lets-Service-Orient-Everything” pitfall.

Policies (The broad range of mandates and agreements such as Internal Policies, Law and external Contracts) apply across varies parts of the Thread – sometimes along the entire Thread and sometimes to a specific Bead or sub-set of Beads.

Events stimulate activity along the thread - sometimes in a predefined sequence but often not. Records of events can create an audit trail of the Thread and maintain the state of long-running business processes.

Content (e.g. Documents, conversations or messages) is produced and consumed along the length of the Thread. The ownership and rules that determine use of Content change during execution which, if not made explicit under Policies, can compromise information privacy and protection requirements.

Make Trust Levels Explicit

The amount of Trust along a Thread varies – this is influenced by many and varied soft factors such as: experience, relationship maturity, relative value of the service or competency.





Trust-based relationships are vital to implementing relied-upon services from external providers. And the measure of Trust/Risk ever more pertinent in a world of regulatory control where accountability doesn’t necessarily reside with the service provider.

Is it not reasonable to believe that the measurement of the degree of Trust should be an key indicator on the CEO’s Dashboard?

And with the ever increasing information sources (fuelled by the Web) and the risk of misalignment of semantic meaning in a federated world, is it not also necessary to capture and manage the degree of Trust associated with such sources balanced against the degree of business risk?

So What? – Making Sense of The Tangle

The multiple Value-based contexts in combination with the dimensions of multiple policies, events, content & trust profiles are not sufficiently covered in process-based thinking or, the intrinsically hierarchic, enterprise-based business models (e.g. Org Charts and Operating Models).

Perhaps, with a perspective that puts these aspects front of mind, it would be possible create more realistic (actual-behaviour-aligned) models of historical, desired and run-time operational behaviour. Might, this in turn, provide the insights necessary to make more informed decisions around the alignment People-Process-Technology in the mission to deliver more agile, effective and efficient (and therefore competitive) business operations?

In a world where more activities are undertaken outside of the ‘four-walls’ of the enterprise and the need for ever tightening regulatory controls… Wouldn’t such an approach be necessary to manage business risk?