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

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

1. Making Enterprise Architecture valuable
2. 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

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

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

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

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

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

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

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?

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


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

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

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

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

http://twitter.com/taoofit

Why Service Orientation should start with Systems and not (always) end in systems

In publishing this I'm throwing caution to the wind (and ignoring, in part, the good advice of a respected friend!). Chris Bird, suggested that I should avoid talking about Systems Thinking, Service-oriented Architecture and other such consultantese. But I've decide I will talk about Systems Thinking and SOA as they relate to a broader world-view of services (given the focus of this blog).

To start the discussion, however, I'd like to quote Chris: “ SOA starts in the wrong place. The tools are tools and not grand strategies. I don't look at the screwdriver in my hand and say, "Cool, now what projects can I undertake?" I think about what needs fixing in my house and what tools I need (aside - the checkbook is my favorite tool)”.

Mindful of Chris's words and a client's SOA-related organisational challenges in mind, I thought it was about time I added my two-pennies-worth to the SOA-doesn't-work debate. My observation is that many SOA projects start in the wrong place - that being in the technology weeds i.e. Conversations around ESBs, WS*, Registries, EJB, XML et al. I believe the first step towards 'service orienting' a business is taken by applying Systems Thinking (that is Systems in an ecosystem sense) rather than thinking about Services per se and certainly before technology view of SOA). Most importantly, the notion that a business is comprised of multiple, interacting, 'Systems' of people, processes and technologies (agents of the system) that cannot be viewed in isolation one from another but accepts each system/sub-system works within a unique set of values.

Taking a fresh Systems Thinking (capital 'S' Systems from now on) perspective helps to breakdown the more traditional organisational and process bounded views of the business and that the complexity of the behaviour of the business is best tackled by examining the interactions between 'Systems' that often span traditional boundaries. This then helps layout the organisation as a set of 'System' behaviours that can, for example, be examined as core or context to the business operation/strategy/well-being. I've found that with this approach, its possible to evolve certain 'Systems' into 'Services' by defining the Consumers, the Policies/Contracts that apply, the Events that trigger action and the Content being exchanged (physical and/or informational). This 'Big Services' (Systems)view allows the business to see how to chunk-up aspects of the operation in new ways that helps with business problems such as: simplifying post M&A situations, executing major transitions, outsourcing. And, from an IT perspective, where/how to apply SOA, COTS packages or SaaS for that matter.

I've been accused of being too idealistic when I say Service Orientation starts in the boardroom not the IT department. I agree, it's often hard, if not impossible, to get SO on the business agenda but if your SOA is being 'sold' as a way to achieve 'business relevant' efficiencies and associated cost reductions through service reuse, then board members must be the sponsors. This becomes most obvious when organisations realise they must change the way they fund software development and/or procurement projects to realise the desired sharing and reuse.

So how can 'Systems Thinking' be introduced to the CxOs without appearing to be too academic?
The rule is to avoid talking about Systems Thinking and, for that matter, SOA. Instead, the discussion is focused on delivering business value around a topic that is front-of-mind for the board: Compliance, Profitability, Green-agenda or Strategy execution might be such topics. Then the trick is to use simple 'Systems Thinking' techniques and tools (akin to S.W.O.T. or Forcefield and Mindmaps or PowerPoint) to start to describe the emergent services.

As Chris points out, it's important to be looking at the cross-cutting concerns of the enterprise (and the extended enterprise - but extended from a business sense, not an IT sense). I believe that getting the CxOs to buy-in to SOA via Syetms Thinking - (without necessarily trying to teach them the Theory!) - is the way to make SOA work, and for that matter, improve many aspects of their business operations and strategy execution with or without SOA or with or without IT systems.

To bring to a close, I'd like to paraphrase Chris again:

“We must focus on what the enterprise wants to achieve. There are many ways of getting "it done". Goldblatt in "The Goal" makes some useful analogies. The goal in manufacturing isn't about keeping the machines busy, it is about increasing value - converting raw materials into products at the optimal rate for making profits (even if you have to underutalize resources). In the SOA world, the corporate goal is not to maximize the use of IT tools, (to suborn everything to the technical services oriented architecture), but to look for services that deal with the Events that the business has to deal with. I think we have to get the very loose coupling done first before thinking about SOA in companies. Until the businesses think in terms of hand-offs instead of commands, they won't get any of the benefits possible anyway”.

I believe subtly applied Systems Thinking will help us put controls where controls are needed, don't control what doesn't matter and help us answer the question; “How do you focus on what is important, and at the same time not miss the critical details?”

The Cynefin framework and 5D lens are both tools that can help introduce Systems Thinking to broader audiences.

As always, I welcome your comments.

VPEC-T Google Group

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

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

n.

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

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

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

Thanks Roy!

n.

The Tao of Enterprise IT Episode 2

Heres the next episode in the Tao of IT webcast.

Click To Play

Tao of Enterprise IT

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

Click To Play

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

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

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

Thanks

Nigel.

X&Y and Enterprise 2.0

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

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

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

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

Business behaviour before technology

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

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

Generic VPEC-T

view presentation

As always, comments and builds most welcome.

Thinking Adaptive and Adoptive over Fish & Chips

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

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

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

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

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

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

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

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

What is an Enterprise Architect?

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

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

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

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

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

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

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

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

CADS part II

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

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

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

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

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

n.

Context Aware Dialogue Systems

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

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

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

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

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

n.