Why Do I Find Twitter So Useful?

Maybe its my background in Tracking & Tracing systems that leads me to see event-centric patterns in almost everything - and Twitter is no exception. But what's intriguing to me, is how Twitter seems to be the result of the coming together of a number of design patterns. I find this makes Twitter a usefully addictive, relationship-building and idea-stimulation tool.


But the thing that I find really intriguing, is how it seems to illustrate the value of separation of 'content' from 'event'. That is, a tangible value from broadcasting and receiving short/short-lived messages (signals) that describe what you're doing or perhaps, more importantly, what your thinking independently of, but with reference to, the full text, dialogue, or any other expression of an idea or perspective (the content). This combined with the ability to choose who you follow and who follows you, creates trust-building relationships across a network of like-minded brains. These snippets of information shared, referenced and re-referenced (Re-Tweeted), by those I follow and those who follow me, have become a great reference source and provide regular source of thought-provoking ideas.

Twitter illustrates how much can be achieved with some very simple patterns, without top-down control or grand-design. IMO its success is due to its ease-of-adoption and the simplicity of its policies and protocol. In some ways its similar to internal email groups I subscribe to, but the big difference is the ability to explore the endless chain of Follower/Followee synapses, find like-minds and then follow urls to content that I wouldn't normally discover.

What does strike me as I write this, is that I suspect people have very different experiences with Twitter depending on what interests you and therefore who you connect to and what you talk about.

I know a number of my colleagues are not convinced of the value and will probably remain unconvinced after reading this post. I wonder how much our, life circumstances, personalities and philosophies affect the value we get from Twitter?

http://twitter.com/taoofit

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.

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.

X&Y and Enterprise 2.0

sHere are the full proceedings of the MashUp* Enterprise 2.0 event. I was prompted to post them here now following  a couple posts on the Capemini CTO blog - X&Y   and Ent 2.0 and Simplicity.

The hook for the latter is "I believe this is to be important because, this is the first t time, a strong relationship can be made between emerging business leadership practices, Web 2.0 phenomena and the practice of IS architecture".

The video's below are worth a look if you want to hear the debate about Web 2.0 applied to the Enterprise and , in my case, why I think we need to develop new thinking to get to the value.

The seems low at the start of this next video - but don't be fooled, the first speaker isn't using the mic for the first moments!

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.

Thinking Adaptive and Adoptive over Fish & Chips

My home village has two problems: a local bye-law prevents us form having a Fish & Chip Takeaway and, like so many other country pubs, one of the villages most important watering holes,The Cricketers is struggling to keep its business going on wet-trade alone.

Around eight weeks ago, The Cricks was taken- over by new licensee's; Andy, Colin and Debbie. Since arriving, the new management have been keen to share their ideas for revamping the pub with 'The Regulars' and very attentive to their needs and suggestions. It was their adoption of one such suggestion a couple of days ago that prompted this post.

A few of the regulars were having a moan about the lack of a Fish Chip Shop in the village, when someone suggested the pub should do take-away fish and chips. The new landlords had already decided they were going to focus more on food and said they wanted to avoid going too far down the 'Gastro-pub' route (i.e. wobbly towers of fiddled-around-with food the jus of-something-pretentious dribbled all over it), so the idea of old-fashioned fish and chip suppers wrapped in newspaper seemed to be a good fit. So a word was had with Andy and sure enough, six fish and chip suppers were sold on the first night the new kitchen opened and many more since.

Then it struck me, my new landlords were demonstrating a number of the qualities described in Dave Snowden's Havard Business Review article - 'A Leader’s Framework for Decision Making' (HBR November 2007). They were showing a willingness to experiment and the were thinking 'Complex Adaptive System' (without knowing they were!). They had come up with a set of 'light-constraints' for the new vision of the Cricks; they would focus on food but they'd keep the pub atmosphere and help the locals to adopt the new version of their pub. They listened carefully to the regulars comments, even when made in jest, and acted to try to keep the locals happy and give them a sense that 'their' pub was still theirs. In other words, they were doing 'weak-signal' detection and amplifying signals that worked within their 'light-constraints'; they were allowing the agents of the system (regular customers) affect the system operation. Andy, Colin and Debbie, also recognise that a bit of experimentation makes sense – the 'safe-fail' ( as opposed to fail-safe) trial of fish and chip take-ways seems to be a winner in just a few days. Is it reasonable to suppose that a dose of similar agility, adaptiveness, and adoption could be injected into the veins of corporate and public sector behemoths?

Visit Dave Snowden's site for podcasts that describe Complex Adaptive Systems and sense-making techniques (sorry for the indirect link via Google - got a 406 Error if I tried linking directly to www.cognitive-edge.com).

P.S. A good discussion thread based on this post is taking place at:

http://www.cognitive-edge.com/blogs/dave/2008/07/interesting_uses_of_cynefin.php

(cut and paste the above if clicking doesn't work)

What is an Enterprise Architect?

Ask ten IT folk and you'll get ten different job descriptions. The simplest illustration of the problem is made by Charles Edwards on his AEA site: Two EA definitions:-

1. Enterprise Architecture (Software Developers or Project Managers (segment) (view)) = The development of a coherent set of Application Architectures for an Enterprise level system or set of Application systems. In some cases this might also involve the definition of Business processes and other business domain modeling specifically for the Application. Typically carried out by a Solutions Architect (and those) who know about Databases, Messaging, Portals, Application and Web servers, etc. This would also typically be implemented in a Programme, a Project of work or even as a Business as usual process.

2. Enterprise Architecture (CEO, CIO (enterprise or holistic view)) = the management and definition of the Architecture of the Enterprise (set of organisations) that includes everything from the Business Strategy, to the Business Operation Architecture (static and dynamic) for the purposes of optimizing the enterprise; the Information systems (made up of Applications, Services and Data) and the Technology and Infrastructure that this runs on. EA also includes aspects such as Security, Data, People and Performance. The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. Enterprise architecture models allow traceability from the business strategy down to the underlying technology, in order to do impact analysis and have the ability to react to changes quickly, govern the Architecture and guide the business. To contain the Knowledge and the memory of the Enterprise (Architecture) in a single point of truth.

I definitely see EA as the latter (with the exception of the last sentence that I fundamentally disagree with - I think we EAs are the guardians of multi-POVs and therefore sense-makers of the multiple 'Truths' that exist in all organisations/communities) and from, recent conversations with Charles Edwards and Sally Bean, I seem to be in good company.

Sally and I were discussing this yesterday and agreed that the former was much closer to an Engineer's view (we decided engineers probably don't make the best EAs – although there are always exceptions – I used to write PLAN code!). I mentioned that I'd just started to qualify my 'Enterprise Architect' moniker with 'Demand-side' which seemed to resonate with Sally. I often thought of EAs as sort of 'Super-Business Analysts' (I held the BA title longer than that of SE (PLAN progemmer)- which was my saving grace!) . So maybe my BA roots help explain why this is why the 'Demand-side Enterprise Architect' label works for me. Sally simply describes herself (with appropriate Dilbert-like irreverence as “Some one who talks to people and draws pictures” which I interpret as just the same as me (what I've been known to call a 'Super-Business Analyst with a satchel full of crayons').

I suppose many would argue one or other or both or another of the above EA descriptions is THE correct definition of EA. Meanwhile, the rest-of-the-world continues to be confused about what we do and why.

So rather than search for a single version of the Truth about EA, I'm hoping that adding 'Demand-side' to my job title might just avoid some of the confusion about what I do and what I don't do within the apparently highly ambiguous label of Enterprise Architect.

A footnote: Sally and I also identified another perhaps more sinister type of EA – which I'll call the 'Religious Fundamentalist Enterprise Architect'. These EAs seemed to be more bothered about their chosen methodology (EA frameworks & processes) than the business outcomes and the underlying philosophical and abstract reasons for EA that simply resolve to qualitatively better information systems and more useful and cost effective IT.

CADS part II

I just finished writing an email to to my friend Roy Grubb in Hong Kong. I've inclued an excerpt from this email as I think it adds a bit more about where I'm coming from on CADS (Context Aware Dialogue Systems - see earlier post):

"The seed of a follow-on idea to VPEC-T is germinating here this might resonate more with KM discussions. My hypothesis is to take some of the great work of folk like Brenda Dervin and others (perhaps Martin and Dobson - cited in the comments) and combined with VPEC-T come up with a practical (easy-to-grasp) way to describe information systems behavior and therefore help promote simplicity, agility, adoption and usefulness in IT projects (of any type) and, indeed, the efficacy of non-IT information systems. All this in the context of the Web Science thinking (best summed up for me in The Machine is Us )"

I've only glanced at the and the Mike Martin and John Dobson paper referenced, but it does seem to align well. Does anyone know where their research took them and if there is any practical (non-academic) outcome I could learn about?

I mention Brenda Dervin (her work introduced to me by Dave Snowden) not because I've been a long time devotee of her work (although I suspect I will be now!), but because I've just listened to a podcast of one of her lectures and realise we seem to be stumbling into a world that has some fascinating concepts that fit hand-in-glove with where Carl and I had come to with the range 'communication' problems within IT.

Here's a link to some earlier and ongoing brainstorming around CADS.

n.

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.

Systems Thinking and the Web

This recent post on Sam Lowe's EA blog reminded me of some of the more significant books I've read over the past twenty years or so and how relevant much of the thinking is today. In particular, I've found a recurring resonance between the world of System Thinking, as described by Pirsig and Capra, with the world of the Web. Interestingly, I've found abstracting up to System Thinking (Chunking Up) has been extremely useful when assessing impact and potential of Web 2.0/3.0 technologies on the future direction of corporate IT and looking at both the softer interaction and harder transaction aspects of an overall information system.

When I reflect on it, however, the theme that I find most compelling, is the importance of human behaviour, social norms and planned and unplanned events to information systems. Moreover, how these aspects, if left unexplored, often become the barriers to adoption of IT-enabled change. What I find most interesting is the search for the sweet-spot between classical engineering approaches and the early examination of adoption barriers. It seems to me that some of the most successful Web-enabled businesses (the likes of Google, Amazon and eBay) have used an adoption-led approach to the development of products and services. Corporate IT, in contrast, often continues to take a more traditional approach to 'engineering' their way to a solution. Is this difference in approach where we might find the long-sought value within the enterprise from the world of the Web?

Here's a few of the most thought provoking 'Systems Thinking' books on my read list:

Lila: An Inquiry Into Morals by R.Pirsig

The Tao of Physics by F.Capra

The Web of Life: A New Scientific Understanding of Living Systems by F. Capra

The Labyrinths of Information: Challenging the Wisdom of Systems by C. Ciborra

Freakonomics: A Rogue Economist Explores the Hidden Side of Everything by S. Levitt and S. Dubner

Chaos by James Gleick

The Tipping Point: How Little Things Can Make a Big Difference by M. Gladwell

Digital Capital by D. Tapscott, D. Ticoll, and A. Lowry

The Self-Aware Universe by A. Goswami

Systems Methodology in Action by Peter Checkland

Systems: Concepts, Methodologies and Applications by Brian Wilson

Services Fabric and Data Management

Reflecting on the previous posts referring to events, content and semantics it's apparent to me that data management is ever more important in a world of services. Just because a database is buried deep behind a service interface doesn't mean we can ignore the basic principles of data management.

As we know semantics are critical at the service interface or the definition of an event, but how do we know that data passed through an interface is handled correctly? Given that we're moving to a service world in many cases by service enabling legacy applications we need to establish a framework for managing data across the service enabled landscape. We can not rely on a sea of services that are going to perform every validation for us - much of this will still be left embedded in applications. After all how would our services perform if every valdiation required a service invocation?

The framework needs to deal with:

Synchronisation (including translation) of content - ensuring that reference data or master data (not my favourite terms - see below) are up to date and distributed to where it's required when it's required. As above real time look up of content will not be performant in many situations. Therefore data needs to be 'cached' as part of the service implementation.

Synchronisation (including translation) of definition - as with any language, establishing a single dialect for the business and implementing it in its information systems is probably not a reality, especially when many system components are sourced from outside the enterprise and/or need to interoperate with customer and supplier services. Is Oracle's semantic model the same as SAP's?

Data (and service) ownership - as those that have tried will know, until this fundamental principle of data management is established many of the advertised benefits of service orientation will remain elusive. Unless ownership of data and associated rules are established multiple definitions and implementations will remain along with multiple service implementations performing similar functions.


As mentioned above these are the basic principles or needs of enterprise data management. However, apart from a few execution tools aimed at areas such as master data manaagement and canonicals I see very little discussion on this aspect of the services fabric. Of course this may be limited to whether SOA is treated as an IT or Business issue. The development and management of business ontologies has to be a cornerstone for establishing true SOA.

In this vein, what is the collective for the 'things' the business cares about (e.g. orders, customers, accounts)? Objects? Entities? Types?

(Note: Reference data or master data are not my favourite terms as these terms appear to lump in to one bucket what are probably a number of critical subject areas that define the enterprise. Indeed, MDM appears to be an IT persons response to the problem when of course managing information about the basic assets of the organisation is a business problem, requiring ownership and process.)

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.

One Registry to Bind Them All

I’ve been wrestling with what seems to be a common problem – finding the right language to describe, arrange and catalogue services/sub-services.

I need to describe everything my client organisation offers its customers in a common easy-to-consume ‘Service’ language, regardless of how the service is delivered – some services are technology-based (e.g.. SaaS or Data Centre related) and some are competency-based (e.g. software lifecycle expertise or SME advisory). I want to be able to describe all the services offered in a consistent, non-technical, language that is readily understood by both service consumers and service governors alike. And just to make life more interesting, services are described at varying levels of granularity which requires a degree of consolidation of some of the finer-grained services into ‘Service-Bundles’ – if only for ease-of-consumption. When I look at the prevailing services registry technology, it seems the current SOA-based registry offerings are too limited in their scope. Interestingly, although my client is building to an SOA, the usefulness WSDL/UDDI-focused registry is unclear today.

What is needed is a more expansive set of tools that deal with full service lifecycle management. This includes the classification, marketing and consumption of all the services involved in business transactions beyond the narrower world of SOA. So it seems there is a need to support a broader landscape of all the services both provisioned and consumed by a given business domain. Features might include:

• Service Taxonomy (relationships between services – across levels of granularity)
• Delivery Medium
• Lifecycle Management
• Proto-Services (candidate services not yet exposed)
• Version Management
• Service Withdrawal
• Event Definitions (real-world or technology-based triggers and exceptions)
• Content Definitions (any human-based or technology-based information exchanges)
• Policies and Policy Management (any rule, law or binding contract that constrains the service)
• Value and Trust calibration (inter-dependency and degree of desired or necessary binding).

I’m sure there are many other dimensions that might be included, but you get the general idea. It seems that even within the die-hard SOA camp, the once prevailing UDDI/Service-Broker-view of the world is giving way to a slightly more traditional perspective on how we provide and consume services (i.e. how business was transacted way before anyone uttered S-O-A). SOA thinking, however, is forcing a much needed degree of rigour on the definition, management and operation of services. Might a combination of these two perspectives (traditional services and SOA) drive out some interesting thoughts around what it really takes to operate in a marketplace of interacting services and therefore what a comprehensive Services Registry might look like?

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?

Capability vs Service: What's the difference? Does it matter?

So what exactly is a Service? If we are seeking a common definition of what SOA is (and much is made of the lack of this on the web), then we could at least start by defining the 'S' (in SOA).

There is some emerging consensus in some SOA communities that 'services are a way to gain access to, or make use, of a capability'.

The uninitiated might propose that this sounds rather cryptic, but it is actually important because defining the difference between a service and a capability is one of the key concepts to get to grips with, in order to design an SOA that actually is workable.

To illustrate this we need to look at a business example, as making IT architectures more business-meaningful what SOA is about. (I've written before on my Enterprise IT blog about how the implicit goal of SOA is to create IT architectures that are structured explicitly like the business they support, rather than being structured explicitly in IT construction terms I.e. systems I build, data I store, software I deploy, hardware I install, etc). So let's look at a business example.

Imagine I run a practice in a consulting business. I offer services externally to my clients (defining supply-chain strategies, say). I also offer services internally to other parts of my consulting business (maybe sales-support to the sales team, solution audits to the delivery management team, etc etc). Against all of those services I need to know what my value proposition is to those who consume my services. I need to carefully define the quality of service (or service levels) that I can offer. And I need to know how I’m going to generate 'value' for me (directly as revenue, or indirectly) and what my 'costs' are going to be for those services (again directly or indirectly).

Of course I will require some capabilities that I don't have, or don't want to carry myself, which I can obtain through consuming services from others (maybe HR and Finance services from the common back-office for example).

But the services that I offer to others, and the ones that I consume from others, cover a fraction of the capabilities that I or they need to have in order to operate. For example, I need to have a management capability for a start, but it’s not some thing I'm ever going to be to offer as a service to anyone, externally or internally. But it's still a capability I need to operate. In particular I need it in order to deploy my resources optimally, to grow my practice's capabilities appropriately, and generally run efficiently.

So I define the services that I offer, and I define the capabilities I need to support them. They are not the same thing, and it is important to differentiate. The services that I offer define my value proposition to my customers, partners, or other consumers. The capabilities I have define my operating model, internal mechanisms, ways-of-working, and even technologies. Of course, of the capabilities that I need, I may have them in-house or I might source from somewhere else via a service that they provide to me (at a service level that I find acceptable for my needs).

The key point is here that if you treat everything as services (as some SOA dogma would either have you do), then there’s a strong argument to say that you’re devaluing the concept of service to the point where it becomes meaningless.

If you were to do so, you'd be treating your capabilities as services, which they are not. The two have very different characteristics, and need to be defined in different ways. Furthermore you'd be massively increasing the number of services you need to manage, which is just asking for trouble as services are complicated things, with overheads that you need to manage around the service levels, policies, contracted interoperability etc. I would advocate that you only want as many as it is valuable to offer. The rest are better served as capabilities.

So if you're having trouble defining your services with sufficient clarity and rigour, take a minute to check whether that's actually because the service you're looking at is not meaningful to the outside world. Maybe you're actually over-reducing the service being offered to the level of the process it uses internally - maybe it would be better treated as a capability?

I should mention that Steve Jones has also recently put down some of his thoughts on a similar subject in his blog. He has some interesting thoughts on how you draw the boundaries.

Technorati Tags: SOA Service Oriented Enterprise IT Enterprise Architecture EA