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

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.

Enterprise Architecture v Services Federation Architecture

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

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


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

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

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

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

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

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

Other related areas for discussion that come to mind:

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

The State-Machine in the Sky

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

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

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

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

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

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

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

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

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

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

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