Services Fabric

A new context for EA: The Enterprise: An eco-system of Values and Value

2010-09-25T11:14:00.004Z

Reflecting on recent discussions, Tweets and other online threads, there seem to be two reoccurring and related topics:

Making Enterprise Architecture valuable
Selling the need for Enterprise Architecture practice to CxOs.

Recent discussions with the OMG EAC2010 Working Group, Brenda Michelson, Sally Bean, Verna Allee, Chris Bird and Chris Potts are shaping a ‘Next Practice’ point-of-view for Enterprise Architecture. All seem centred around values and value:

Values = ‘The things cared about”

Value = “The worth of an interaction between Systems”.

How do the V’s apply across an Enterprise? My definition of Enterprise includes the subject organization’s relationship with customers, markets, and trading-partner communities.

Value Network Analysis seems to provide one of the simplest ways to represent these relationships, in this System-of-systems, we call the Enterprise. Value Network Maps are a representation of the Roles (sub-systems) and the interactions between them. Each Role has a set of dominant Values (things-they-care-about) and a number of ‘transactions’ that produce and consume tangible and intangible value with other Roles.

Click here for examples of Value Network Maps.

I believe understanding “The Enterprise” as a complex system of interacting Values and Value-Transactions is fundamental to selling the need for Enterprise Architecture as a practice (note: whether or not someone carries the title ‘Enterprise Architect’). A recent LinkedIn discussion with Verna Allee helped clarify this perspective:

“… value network mapping indeed provides an overlay for business processes. … This gives you a "process" view, but it is one with all of the key intangible interactions built into the process and not mysteriously hanging outside. At Boeing VNA is their Lean + tool and they use it extensively prior to doing the deep dive into process modeling. It serves as that reality check to be sure that a) all of the critical interactions are addressed and b) the processes do not become over structured in contrast to what is most essential.

The discovery, and the concise abstraction of ‘The System-of-Values’ across the enterprise, seem critical to understanding the style of EA required and its “Worth” to the subject organisation.

The ‘Systems-Of-Values’, will vary, sometimes dramatically, from company to company and will change over time depending on all sorts of factors from market demand to changes in leadership.

Brenda Michelson recently commented that she always does anthropology before architecture; I believe this exploration of the ‘V’s’ aligns with that thought. I also believe, that it is possible to create a usefully abstracted, values-based reference model of the enterprise that acts as a grounding-point subsequent views of EA (e.g. process, information and technology).

This worldview of EA seems all the more important as governments and businesses need to become more connected to external organisations to stay relevant and aligned with the values of their citizens, customers and trading-partners.

Chris Bird: applying P-E-C @ Sabre

2010-06-21T07:13:00.001Z

Click to Play

Chris Bird explains how he has used the core of the vPEC-t framework as a set of principles from which to derive patterns for large-scale Event Distribution.

Balancing Reliability-X and Validity-Y

2009-06-06T17:20:00.009Z

Earlier this week a Tweet from@rotkapchen (Paula Thornton) introduced me to this video of the Canadian academic Roger Martin. He talks about 'designing in hostile territory' and the tension between 'Reliability' and 'Validity' in the context of the challenge designers face in working with business and vice-versa. He hints at the dangers of measuring the things that are easy to measure and challenges McKinsey's notion the that 'Gut feel' management is dead and that “management will go from art to science” because we can now use 'algorithmic decision-making techniques' to run businesses. He contrasts that with the a designer's recent article that quotes William Blake: “I must create a system or be enslaved by another mans; I will not reason and compare: my business is to create”. (I thoroughly recommend watching his video when you have a spare 50 minutes or so).

His presentation, however, is not banging-the-designer's-drum, it is all about reducing the Business-Exec/Designer communication gap – the same subject of that Carl Bate and I tackle (between Business and IT) in 'Lost In Translation'. It reminded me of a various conversations with Carl about the challenges of being a right-brained, theory Y, innovator in a predominantly left-brained, theory X, reliability-focused corporate world. Roger Martin also reinforced for me a the importance of patterns, analogy and story-telling 'to generate quasi past data' for the X-ers around me. He also reminded me that the X-ers are 'guardians of reliability' which probably explains why the creative 'Y-ers' are best left in their labs to innovate rather than run-the-business.

All this got me thinking back to the thread of Tweets that had led up to Paula sending this link. Over recent weeks my fellow Twits and I (in particular, @Cybersal, @Chrisdpotts and @richardveryard) have been sharing views about Enterprise Architecture and the need for a broader set of lenses to fully understand the behaviour of organisations. And so this week when I saw a Tweet from complaining about the technical focus of many Enterprise Architects from Paula, it prompted me to reply “EA should be focused on business behaviour before tech drafting - good EAs provide organizational 'therapy'”. This in turn led to Paula sending me the link to Richard Martin's presentation.

So now I'm pondering the following:

A good Enterprise Architecture must be a balance of X(Reliability - Doing-things-Right) and Y (Validity – Doing-the-right-thing) or to put another way, Industrialization and Innovation.

We've spent to much time of methods that attempt to industrialise EA (to the point that I'm told TOGAF 9.0 runs to 800 pages)
We need to spend more time on developing pattern-based storytelling skills in Enterprise Architects for EA bring break-through changes and allow for innovation in TO-BE models.

Being X or Y minded is equally valid but both sides need to see the value of the other – I'm not always appreciative of my X colleagues as they 'herd' me towards on-time delivery and finished products, and I suspect they don't always see the value of my storytelling and idea-nurturing approaches.
Recession needs to bring forth more Y-minded thinking ( with some sensible X-controls) - because doing the wrong-thing-well (repeatedly) got us into this mess!

The world can't be fully explained or governed algorithmically (thank god!)– not while values and trust dominate the way organisations function.

Uploaded to Flickr by vaXzine (under Creative Commons license)

Thanks for thoughts about 'doing-the-right-thing' to @catuslee

Revamped Services Fabric Blog

2009-04-25T15:00:00.005Z

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

The Tao of Project Management

2009-04-10T06:52:00.010Z

I thought I'd do something different for Easter so I've dusted-off this short piece I wrote about 10 years ago after being asked to deliver internal project management training around the DHL Asia Pacific region (those were fun times!).Here it is...

We're all Project Managers. True, some of the projects we've managed might be nearer the gluing-autumn-leaves-in-a-scrap-book type than the launching-a-space-shuttle type, nevertheless, most of us would claim we have project management skills - after all it's just common sense, isn't it?

Taoists, of course, would agree - projects should be run simply, honestly, holistically and with a sense of fun.

A few thoughts that you are unlikely to come across on a Project Management training course:

Creating and managing projects is as much an art as a science. That is not to say that we should abandon tried and tested methodologies and techniques - just that balance is required - a 'Whole-Brain' approach to project management.

Taoist teachings emphasize the need for balance and unity - yin and yang.

Engineering and organisation alone do not guarantee success. I've witnessed well engineered and administered projects fail - the most significant of which ran to more than US$500 million before it was stopped - with very little to show!

The key to success is in the softer issues of business vision, people and flow. Much has been written about left and right brain and more recently 'whole brain' thinking. I suppose that's what I'm talking about. The most common representation of this thinking is the yin and yang symbol. Two opposites live together in a circle: one feminine/ right brain and the other masculine/left brain.

Projects are about people. People respond best to a balance of left and right brain - so projects are best run with a 'Whole Brain' approach.

Here are some key words that might help to stimulate a 'Whole Brain' approach …

Deliver	Communicate
Structure	Empathize
Standardise	Relate
Procedure	Share
Administer	Unify
Analyze	Include
Engineer	Simplify

Given that you believe like I that people are the primary concern of the Project Manager, Communicate must be at the top of his list next to Deliver. I leave the reader to judge the relative importance of the rest of the list.

Tao teaches us that neither side is more important. Balance and harmony matter most.

Thanks to http://www.chebucto.ns.ca/Philosophy/Taichi/lao.html for the image

Serious About Play and Comics

2009-03-22T12:17:00.011Z

This morning I watched Dr. Stuart Brown talking about the importance of play. He makes a number of compelling points about the role of play in the development of trust, innovation and social interaction. More specifically, Dr. Brown reminds us that stories and storytelling provide "the unit of intelligibility in our brains" (how we make-sense of stuff).

Dr. Stuart Brown: "The basis of human trust is through play-signals"

This reminded me of an article I wrote for IASA where I talk about my experience of importance of storytelling skills to Enterprise Architects. Here's a couple of things I said:

"Enterprise Architects should be convincing and credible storytellers....We architects must learn to become comfortable with the journalists’ technique of ‘Simplifying and Exaggerating’. It’s much more important to convey a highly simplified message about a complex problem to the business stakeholders than it is to demonstrate our grasp of the complex and the obscure. We must become proud of our ability to distill and communicate the important opportunities – and the barriers to change.”

and

“Cartoons and other visual media are a powerful way of communicating often quite complex, and sometimes contentious issues, simply".

Building on the value of play and storytelling in communicating sophisticated ideas, another TED video from Scott McCloud got me thinking more about the value of comics & cartoons.

Architects are comfortable with the idea of creating visual maps and blueprints. They seem less inclined, however, to see the value in 'less scientific' visual expressions. Scott McCloud does a great job of resolving this science v. arts discomfort. He uses a number of phrases that rung-a-IS-architecture-bell for me – he talks about “watching for patterns” and explains the journey from "visual iconography to language" and creating “temporal maps” - this is the stuff of IS architecture.

Finally, he talks about creating “durable mutations” of the comic medium that create window's back into our world. And as these mutations develop they will “provide people with multiple ways of re-entering the world through different windows and when they do that it allows them to triangulate the world that the live in and see its shape".

Could one of these “durable mutations” be a new way to express Enterprise Architecture to 'the business'? And is this idea more generally applicable to how we communicate our values and build trust - independent of practice or discipline?

The Great Granularity Debate

2009-03-14T13:44:00.015Z

Events of the past week have led me back to the "Great Granularity Debate" that goes hand-in-glove with Service Orientation. I was discussing this with some colleagues last night - I described the problem I was dealing with as a 'nano-Lego' problem. This problem seems to come about when technically-focused architects define a 'SOA' without binding it to business drivers and objectives - this results in a plethora of fine-grained 'architecture-for-architecture-sake-services-for-god's-sake technical services that look suspiciously like re-usable 'OO' objects (they didn't get reused either did they?).

In this particular case, the business would like to move away from their old monoliths to more granular architecture that would allow for more efficient change. They don't seem to be bothered about reuse and put performance much higher on the list. They also recognise that they're not experienced in doing things a 'Service Oriented' way and can see some of the problems in funding cross-project service development.

All this tells me that the most appropriate SOA for these guys would be a coarse-grained and business focused. Finer grained services might be developed later as their maturity in things service oriented develops.

So my message to the techies - put the tweezers away and find some heavy lifting-gear to put those chunky business services in place first.

A Question of Meaning

2009-03-01T23:09:00.012Z

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.

Why Do I Find Twitter So Useful?

2009-02-15T15:02:00.003Z

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

2009-02-01T11:08:00.007Z

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

2008-11-02T14:15:00.003Z

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!)

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

2008-10-25T11:52:00.007Z

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!

The Tao of Enterprise IT Episode 2

2008-10-25T11:05:00.004Z

Heres the next episode in the Tao of IT webcast.

Click To Play

Tao of Enterprise IT

2008-10-19T14:05:00.003Z

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

2008-09-16T07:17:00.006Z

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

2008-07-22T16:02:00.009Z

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

2008-07-06T13:44:00.022Z

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?

2008-06-25T10:35:00.003Z

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:-

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.
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

2008-06-22T11:43:00.004Z

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

2008-06-17T07:09:00.005Z

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.

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

2008-02-17T11:24:00.003Z

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

2007-12-11T10:05:00.001Z

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

2007-07-22T11:58:00.001Z

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

2007-02-06T20:51:00.001Z

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.

2006-11-19T14:20:00.002Z

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

2006-10-08T10:17:00.001Z

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

2006-08-05T09:34:00.002Z

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?

2006-05-25T23:39:00.001Z

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

2006-04-29T12:21:00.001Z

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?

2006-04-11T04:45:00.001Z

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

2006-03-20T20:25:00.001Z

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

2006-03-20T09:09:00.001Z

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

2006-03-04T09:42:00.001Z

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.