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

Enterprise Architecture v Services Federation Architecture

This post is based on a number of recent discussions (many of you will recognise some of the thoughts). It posits - A Service Federation approach would provide a better way of understanding, aligning and delivering business and IT services than that of traditional Enterprise Architecture.

‘Services Federation Architecture’ (SFA) is a simplified, more realistic and risk reducing approach to building IS systems. That is, realistic in the sense that the model provides a better representation of how the real-world actually operates.


Enterprise Architects usually approach their work top down– starting with business vision and strategy and working down to the implemented system components and the activities of the people that use them. This way of working has had a degree of success within the four walls of the organisation (in truth, however, rarely applied enterprise-wide). But more importantly, it breaks down across highly federated business scenarios like supply chains. Here multiple business domains interact around a common purpose and at the same time, operate within the context of their own business mission and behavioural traits. This world is less precision-engineered and more negotiated as events unfold – but within a simple model of well defined but relatively simple “touch-points”.

The need for a simplified approach services (from definition to delivery) is obvious in the highly federated world of international trading partners. For example, the joining up both human-based and technology-based services across an international supply chain involving different originations across multiple countries and many languages. Anything other than a simple model of the interfaces between interacting services would simply fail to be meaningful. Each of the members of this supply focused Value System ( “system” in the General Systems Theory abstract sense) operate both within the context of their own independent Value System and within that of the overarching supply chain.

Each constituent organisation is potentially both a consumer and provider of services (within the context of a particular business activity or task). However, despite the apparent complexity, these interacting services are naturally understood by the individuals involved and as is the notion of service governance through policies, contracts and SLAs between parties. The need to document the descriptions of the services provided and the associate information passed between each service (either verbal, paper-based or electronic) is also intuitive. There is a clear understanding of responsibility across the interacting domains and little desire to ‘peek into’ others processes as long as service levels are met or exceeded.

Contrast this with artefacts prescribed by many Enterprise Architecture frameworks. These frameworks focus on engineering rigour and traceability from the coarse-grained business strategies down to very fine-grained technology widgets. The architecture and engineering process wraps itself within its own language and with it, introduces multiple layers of translation between the originating business concept and the final operational outcome. This has the effect of dis-integrating IT away from the business and introduces delay and increases the risk of misinterpretation.

So what? - I believe we might be better off describing, creating and managing services using a “Service Provision in a Supply Chain” pattern rather than the “Construction Blueprint” or even, the slightly more applicable, “Town Planning” pattern. By doing this, perhaps, we can find a way to simplify how we conceive and deliver IT-enabled capabilities and at the same time, reconnect IT to the business.

There are many aspects to this discussion and as always, the interesting stuff is probably to be found somewhere between engineering rigour and operational pragmatics. I would like to explore this thinking here over the coming weeks. I also believe this is fundamental to the whole Services Fabric theme. While similar discussions have taken place in the past within the context of Object Orientation for example, I believe now is the right time to explore a more holistic, abstracted, macro approach to both business (e.g. trading-economies and global ecological needs) and IT (e.g. Web 2.0, Semantic Web, CEP.. et al). I feel this might drive out new insights and principles that can be applied at a macro level (e.g. pan-nation trade) right down to services delivered within an enterprise or by an individual - in all cases; without regard for the service delivery mechanism (e.g. IT-based or human-based).

Other related areas for discussion that come to mind:

• Fractal Model (i.e. a model that is recursively constructed or self-similar, that is, like a shape that appears similar at all scales of magnification)
• Value Networks and Domains of Control
• Service Granularity: How to get in right – the Holy Grail!
• A better representation of the real world and real-world-aware systems
• Social networking and trading models
• Multiple concurrent centres of gravity
• The importance of understanding Events in a federated model.
• Business and IT communication
• The relative importance of re-use and of what?

Demise of the Application?

Does SOA at last move us beyond the 'traditional' notion of an application and elevate the space between 'applications' to that of a first class citizen in the world of information systems? Today, users and IT practioners alike reinforce the notion of traditional application stovepipes in the way that they (applications) get discussed as servicing particular user communities. This affects many aspects of how we do IT, from how things are run to what is paid for.

SOA and event management operate in the world between 'applications' and as such require us to re-evaluate the boundaries of our functional and data blocks. Maybe EAI was the first IT trend to bring attention to the space between applications, but the Application was still central. SOA by definition places emphasis on Interface. We need to manage interfaces and the infrastructure that enables them, not just on a per project or application basis, but enterprisewide.

This is where applications move beyond the database in to the world of communications; not at only at the network transport level but at the semantic level. Indeed, this a paradigm that may be more readily understood by telecoms people, who talk in terms of protocols and interfaces, whereas application people talk in terms of databases, business logic and user interfaces. A user interface being no more than an adapter (a service wrapper?) for a particular form of external system, all be it a rather demanding and unpredictable one.

This emphasis on interfaces and boundaries between systems aligns well with the enterprise architects view of the world but naturally creates a tension with the application owners and developers. Ultimately for SOA to be successful we have to unlearn some of these traditional IT practices and look to other disciplines to help us.

The State-Machine in the Sky

The jokes about solving all information problems with the utopian concept of a single 'database in the sky' that knows everything are well known. But is the new utopia that some describe of centralised top-down process management just as bad, just as impractical? Service-Oriented Architecture (SOA) is often presented as wedded to this concept of centralised top-down process management, but it is not. SOA may require composition (creating services composed of other services) and choreography (sequenced interaction of service providers and consumers), but it doesn't necessarily 'depend' on centralised state-machine-type orchestration. I sometimes worry that people are chasing another conceptual utopia which is not fit-for-purpose to be applied across-the-board in the way that some seem to suggest it should be, and that's one of the ways that business-cases don't stack, and expectations are missed.

Of course this is not to say that BPM isn’t great, I'm certainly not saying that BPM doesn't have its applications, and Process Management is an important discipline. I just feel more and more that it shouldn't be touted across-the-board utopian end-state as it sometimes is. I have a strong gut-feeling that people's desire for visibility and coordination across businesses can often be served through ways other than enforcing top-down control (and by association, top-down constraints).

I had a conversation around a similar topic with Alec Sharp at a data management conference a few years ago and even though of course he used different classes of process to explain his framework, I've always found it very interesting. He described three classes of 'processes' (and I'm using my words here because I can't remember his exactly):-

1.Formalisable processes like certain well-known back-office processes (e.g. Purchase-to-Pay) or certain supply-chain processes.

2.Dynamic sub-processes like customer-interaction where actually you really needed to focus on how to respond in certain scenarios, because you either couldn't predict or formalise the end2end process, or it's not useful to do so.

3.Totally unpredictable processes where actually you just needed to focus on getting information together in front of a sufficiently skilled person who would decide what to do from it.

If I use Alec's categories I might speculate that the first class is most suitable for top-down process management (although in many industries, off-the-shelf application-centric flavours of process management may be more practical than pure BPM).

I might speculate that for the second class you really need to focus more on Event Management, and semi-formalised responses to business scenarios underpinned by information availability, rather than Process management, but there are some obvious similarities.

I might speculate that for the third class you need to focus on information management rather than anything else. And that doesn't mean data aggregation and databases. It's far more likely to mean providing means for federated groups to share their own information repositories, be able to search for it and find it in ways they can understand and aggregate. There is of course a lot of Web 2.0 implications in here, as this is more like searching, linking, tagging and subscribing, than it is like old data management solutions of consolidating databases, creating static interfaces etc.

One last kicker to this point is that conventional wisdom might split the three categories into different types of 'role', maybe something like 'procedural', 'management' and 'strategy'. But this runs the risk of underplaying the pervasiveness of the second and third classes of requirement. If you position them as just for a top few top-management, you miss the point that actually most Enterprise roles these days involve all three types and architectures for these can be just as important as, sometimes more than the one's focused on centralised process-management.

Technorati Tags: BPM Process Management SOA Service-Oriented EA Enterprise Architecture

CEP

Posit: bringing the event and services views together is at the heart a "Services Fabric" - links to event processing here:

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapide concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.


Intelligent automation that saves time and improves resource utilization:

Components of business systems typically have different formats for the information they collect about events. Companies cannot visualize all events from disparate components in a cohesive way to manage their environments efficiently. For example, if an IS team needs to figure out what made a business-critical e-business application go down, they may need to understand 40 different event log formats. Root cause analysis of the problem could require input and analysis by numerous system administrators, spanning the network, web and database.

http://www.complexevents.com/

Discussion Topics

Here are some of the topics I hope to get around to discussing here:

• Unified SOA and EDA
• X-internet, agents and services (real-world awareness)
  
• Process versus Service perspectives
• Service granularity
• Simplicity and technology alignment with operational reality
  
• "Semantic Web"-enabled services
• Web 2.0 - business value
• Business strategy and behaviour described as 'Services'
• Database-centric versus Message-centric
  

Other suggestions most welcome.