Tom Graves / Tetradian » business-IT divide

On IBM’s ‘Component Business Model’

Tom G — Wed, 21 Jul 2010 12:05:13 +0000

(Another example of How To Lose Friends And Infuriate People, no doubt, but this does have to be said.)

[Update: this post was a reaction to a tweet I received yesterday, but Mike T. (@miket0181) tells me that the IBM CBM described here isn't new, in fact is apparently some years old, so my complaints on that regard are unfair. (Doesn't help that IBM don't put up any dates on their website-posts.) On that part, yes, I ought to apologise, and do - see 'How to screw up in one easy lesson...'. Yet the core critique still stands: it's not a complete model, and potentially is dangerously misleading if used as the basis for a business-architecture. That's my view for now an' I'm stickin' to it, anyways. ]

A couple of weeks back, as part of the ‘Patterns‘ section in the Enterprise Canvas series, I put up a an example of a variant of the Canvas which I said was definitely dysfunctional, all but guaranteed to be ineffective, and definitely not recommended – a kind of Taylorist-style model of the organisation and its (non-)relationship with its business-ecosystem:

I said explicitly that it was a stereotype, almost a parody – a guide as to how not to view an organisation, with quality-management and coordination subsumed into ‘management’, and rigid separation between the organisation and its broader shared-enterprise.

I was quite certain that no-one would be daft enough to try to model any real organisation in that way.

I was wrong.

Welcome to IBM’s new Component Business Model, where the organisation’s business-world is partitioned into just three layers: Direct, Control, Execute:

I’m going to have to be rude here, and describe this as a kind of ‘bastard child’ of Taylorism and TOGAF, combining many of the worst features of both and not many of their best. The one good item, and a definite improvement on TOGAF, is that the model does explicitly include People as well as Process and Technology:

Using the Component Business Model methodology, our consultants identify the basic building blocks of your business. Each building block includes the people, processes and technology needed by this component to act as a standalone entity and deliver value to your organisation.

But beyond that? – well, let’s compare it to Stafford Beer’s Viable System Model, which I regard as the minimum requirement for whole-of-business modelling:

system-5, ‘policy / purpose‘ – uh… might be tucked away somewhere in IBM’s ‘Direct’?
system-4, ‘outside / future‘ – sort-of in IBM’s ‘Direct’, but no reference to ‘outside’?
system-3, ‘inside / now‘ – yup, right there in IBM’s ‘Control’ – lots of it
system-3*, ‘monitor / audit‘ (including overall quality-management) – nope, not a sign of it – presumably squeezed into IBM’s ‘Control’?
system-2, ‘coordination‘ – nope – no sign of it anywhere
system-1, ‘operations‘ – yup, that’s IBM’s ‘Execute’ – probably…

In terms of the Enterprise Canvas model above, all it has is Staff-Management (what should be the guidance-services, but all scrunched up together in a nearly-unusable way), Line-Management (the Value-Management cell, blown up out of all proportion to its actual relevance) and, uh, Everything-Else…

In other words, there’s probably less than half of what’s needed to make sense of the organisation – but presented as if it’s the whole of it, much like TOGAF’s hopelessly-IT-centric model purports to be ‘enterprise’-architecture.

The four other worked examples are slightly better, but still dangerously incomplete: a Taylorist manager’s-eye view of the business-world, without any clue as to any of the glue-functions that hold it all together. You’ll also note that each one of those examples has a very different structure in its ‘horizontal’ axis – but no indication at all as to how it’s derived. Presumably only IBM’s own consultants could be considered competent to understand the ‘magic sauce’ needed to do this, and the rest of us mere mortals may do nothing else but bow down in awe?

What’s also irksome is that IBM have the temerity to present this as something ‘new’:

IBM’s Component Business Model is a new way of looking at your business. It represents the entire business in a simple framework that fits on a single page. It is an evolution of traditional views of a business, such as business unit, function, geographic or process.

Fact is that this is nothing ‘new’ at all: okay, it might seem new to IBM, but not to just about anyone else in ‘the trade’. We were doing it more than half a decade ago in Australia Post – certainly 2004, and probably earlier. It was only a Visio hack, but in business terms it proved straight away to be one of the most valuable artifacts from our Business Transformation team: just about every single manager in the whole organisation grabbed hold of their own copy and placed it, much annotated, above their desk. Since then I’ve done one or more of these models for just about every one of my enterprise-architecture clients: you’ll find a couple of (de-identified) examples in that VSM slidedeck referenced above, and in probably half of my other TOGAF-conference presentations over the past few years. I even published the instructions on how to build an ‘organisation-on-a-page’ map, complete with Visio templates, on my Tetradian Books website some two or three years ago. Aleks Buterman and his colleagues have had their own generic version – which they call an Enterprise Architecture Capability Map – up on their website for almost a year now. And it’s even built into some of the EA toolsets, such as Troux Metis, and, I believe, IBM’s own System Architect, and again has been so for years. So what’s ‘new’ about it? Nothing, frankly – other than the fact that IBM have finally cottoned-on to what the rest of us already knew anyway.

And I hate to think how much they charge for this ‘new’ approach… a lot, no doubt…

Sorry, folks, but I’d have to say I’m underwhelmed at all of this. Seriously underwhelmed. Oh well.

Bah.

TOGAF Rome conference in Tweets

Tom G — Thu, 29 Apr 2010 11:05:31 +0000

This is a fairly full collection of tweets over the past few days from the Open Group enterprise-architecture conference over the past few days – more detail on the conference-programme here. It lists most items posted under the #ogrome hashtag: I’ve left out a few RTs (re-tweets) and administrative items, but otherwise it’s pretty much all there.

There’s also a lot of it – at least a couple of hundred tweets – so it’s best to put in a ‘Read more…’ link at this point:

For simplicity, I’ve left out my own name on tweets that I posted (which seem to have been the majority for this conference – a slight disappointment, because it meant that there wasn’t that much of a backchannel). All posts other than my own are preceded with the respective person’s Twitter-ID in italics.

I’ve sorted the posts into the correct chronological order, and under headings for the respective conference-presentations. The ‘Other sessions’ headings relate to presentations that I didn’t manage to get to.

Intro/miscellaneous

stevenunn The Open Group Rome conference #ogrome kicks off to a full house, despite recent volcanic activity. Well done to everyone for getting here.
jdevoo: Follow The Open Group Conference Rome 2010 under #ogrome
a_josey New free EA WP from The Open Group released: World-Class Enterprise Architecture (reg’n requ’d) http://bit.ly/ahjc56 #ogrome
a_josey 2nd free WP from The Open Group: World-Class EA: Framework Guidance & TOGAF 9 Example (regn req’d) http://bit.ly/cLRozq #ogrome
a_josey TOGAF 9 Template Artifacts and Deliverables, Set 2 now available from The Open Group, http://bit.ly/9TGMQp #ogrome
a_josey The Open Group TOGAF White Papers repository has been updated today. Includes two new papers on EA adoption. http://bit.ly/PD5c6
a_josey Second White Paper on adoption of world-class EA published at provides guidance on how to implement TOGAF 9 http://bit.ly/cLRozq …
chrisdpotts: Will TOGAF be extended to include all the technologies a business uses, not just IT?

Terry Blevins (MITRE Corp): Air Force Architecting Concept of Operations – using architecture to support decision making

stevenunn Terry Blevins, of Mitre Corp, stresses the importance of having architects communicate with business at #ogrome.
Technodad Terry Blevins covers US Air Force Concept of Operation for architecture at #ogrome. About supporting decision making for mission/business.
stevenunn Terry Blevins tells #ogrome how the US Air Force uses architecture to support decision-making.
industryleaders Attending Air Force Architecting Concept Operations. EA Capabilities in action now live!!
stevenunn Critical capabilities for US Aur Force include effective decision-support, functioning governance, and optimal build capability.
Terry Blevins: USAF: architecture starts from values (not from IT or jargon!)
Terry Blevins USAF: no solution sits by itself – the really important part is the connections between architectures
Terry Blevins: architecture supports synthesis – and no, it’s not as simple as pushing a button! – governance is the key
Terry Blevins: the test of architecture-quality is whether it’s *usable* in practice – not just whether it’s in a standard form
theopengroup Terry Blevins concludes his presentation at #ogrome by urging the sharing of best practices in architecture through The Open Group.
Technodad Allen Brown and Terry Blevins discuss the role of the architect in supporting the warfighter. http://post.ly/dETe
Terry Blevins: anything you prescribe top-down for an architecture (e.g. segments) is likely to be wrong… must be emergent
trouxsoftware Great key to EA success. Blevins: “clear scope and purpose”

Leonardo Ramirez: EA Evolution from IT to Executive Board Conversation

Ramirez “Technology starts with really good business thinking” (i.e. not technology-first!) #entarch #soa
Ramirez: “SOA should not be a solution looking for an answer” #entarch #soa
Ramirez: “EA should properly be used to mean the architecture of an entire enterprise, not just its IT assets” #entarch
Ramirez: ‘IT’ projects are actually managed by business (as ‘owner’) rather than by IT
Ramirez: Obtain trust (via emotive speech): Think about what you want the technology to do for each audience and then validate it.
Ramirez: Audience did not care about (e.g.) use of process of agile development, as much as the result it could bring.
Ramirez: EA acts as mediator / translator between many different business groups (including IT)
Ramirez: EA provides end-to-end view, which includes IT metrics, business metrics, all people in the organisation
Ramirez: top-level business-results – from 1 country to 5, 1 business-unit to 8, roll-outs drive consistency across whole org
industryleaders Download the latest pdf presentation for EA evolution from IT to Execuitve board conversation from http://tinyurl.com/33lsxqf
industryleaders A pic from the Plenary made this morning http://leonardoramirez-zfwhc.posterous.com/

Jack Fujieda (RegIS Inc/Open Group Japan): 10 Commandments of Enterprise Architecture – For Whom the Bell Tolls? Value of EA to the CxO

Technodad Jack Fujieda presents Architecture 10 Commandments at. http://post.ly/dFcz
Fujieda: engineering happens *after* we understand the what and why of the context
mgl795: Some pictures of Fufieda-san’s session http://bit.ly/90u0cE

Chris Forde (Open Group): Enterprise Architecture – Getting Buy-in From the Business Line

Forde: if they don’t get it, they don’t get it – and if the decision is theirs, not yours, don’t annoy them by repeating yourself!
Forde: is what you’re doing sustainable? e.g. what happens when someone moves on? what happens when the org changes?
Forde: I try to leave the IT slant out of this: we talk about scale in terms of (different) people), not (identical) servers
Forde: who’s actually using what you do? no, who *really* uses it? if it’s not being used *now*, don’t spend big effort creating it
Forde: typical business view of time-to-success is 3-6 months (not classic-EA 2-3 years, but also not less)
Forde: remember that as an EA you *are* bringing to the (business) table a valuable body of knowledge – *you* need to value it too
Forde: everything you do in an IT context should always be traceable to a real, identifiable business outcome – no ivory tower!
Forde: every department in business is dysfunctional in some way – IT is no different (but probably no worse) than others in that..
Forde: there’s a lot of info in the TOGAF spec about soft-skills if you look around in there without IT-specific assumptions

Len Fehskens / Tom Graves / Walter Stahlecker: ‘Extending EA to the Enterprise’ joint session

Len Fehskens: (asking if we’ve read certain EA classics) “you’re all woefully ignorant, historically – not that that matters”
presentation ‘Architecture on purpose’ for TOGAF Rome #entarch went well, will clean-up and post on Slideshare tomorrow
‘Enterprise-architecture on purpose’ – my slides from TOGAF Rome are now up on Slideshare http://bit.ly/9A0Uvd #entarch #bizarch
Stahlecker: “enterprise architeture is the union of all architectures in an enterprise”
Stahlecker: “EA has no a priori architectural hierarchy, alignments are what create and maintain an architectural hierarchy”
Stahlecker: for TOGAF: “needed: alignment among concerns via ‘boundaryless architecture-information flow’”
Stahlecker: business-architecture is the ‘chemistry’ – how the intended value, defined by stakeholders, are derived from the assets

Other sessions

trouxsoftware Lambert: Capability planning is about business outcomes.
harmenberg meeting on TOGAF tool certification at
harmenberg useful meeting on TOGAF tool certification at; interesting point: should it be primarily specification based or use case based?

Richard Sawhney (Forrester): ‘Evolving Traditional [IT] Architecture to Business-Centric Architecture’

sebastian_zeeb Richard Sawhney (Forrester) talks about next gerenration EA @ Opengroup Conferenc in Rome
Sawhney: emphasis on convrsations, agility, value-driven (inc. non-monetary), arch. as coaching, metrics on metrics not compliance
Sawhney: “it’s great that we’ve got this new thing called business-architecture” – this is new???
harmenberg @tetradian if you live in the IT-world, business might seem new to you
Sahwney: barely a third of orgs have implemented any real level of business-architecture (only 2% ‘nearly all we need’) #bizarch
Sawhney: “‘business capability map’ model of capabilities with IT associated with them” – where do we capture non-IT?!?
Sawhney: billed as moving beyond IT-centrism, but ‘business-architecture’ is same old ‘everything not-IT that might impact on IT’..?
Sawhney: capabilities provide a ‘Rosetta stone’ for business-IT communication – is best level of granularity
Sawhney: (‘business capability map’ is similar to what others would describe as a Functional Business Model – i.e tiered services)
sebastian_zeeb According to Forrester Capability maps are a good way to align business needs to existing IT capabiliies #eacom
trouxsoftware Richard Sawhney of Forrester: EA 2.0 is about business outcomes.
Sawhney: (interesting to see this viewed as ‘new’ – all of this we we did in live practice at AusPost 6+ years ago…)
industryleaders Great presentation from forrester at Open Group Rome Conference : Create and Validate Business View First
Sawhney: “architecture is more about listening than talking” – agree (though I admit I’m not good enough at it yet… )
Sawhney: ‘business skills’ are essential – being able to talk in the language of business – communication skills – avoid jargon
Sawhney: (IT-)EA needs to develop collaboration-guidelines to assist business to make best/wisest use of cloud
thobitz Another analyst who thinks that processes are just about fine-granular process steps, and therefore we need – “capabilities”
Sawhney / Allen: EA needs to be presented as a business-level strategic capability, not an IT-capability
thobitz Apparently he is also not sure whether it should be “capability” or “function” – uses the terms interchangably in the discussion
sailesh_panchal Richard Sawhney of Forrester: EA 2.0 is about business outcomes. /via @trouxsoftware Well duh!

Erik Proper (CapGemini Academy): Architectures for Service Innovation

Erik Proper: Architectures for Service Innovation – calling for case-studies in this area
Proper: from product to service; monolithic orgs to networked enterprise; new business initiatives times down from months to days
Proper: value web – not a simple value chain, is difficult now to determine direction; value-transforms often indirect/non-linear
Proper: business-services / business-service innovation not yet gain much attention, yet business drives needs for software services
Proper: architecture as a means to steer innovation (for business and/or IT etc) – service innovation is/cause enterprise-transforms
Proper: #entarch provides a more concrete description of what strategy needs for implementation (hence EA as governance)
Proper: (some nice crosslinks between EA-as-governance, de Leeuw on governance, and Stafford Beer on viable-systems)
Proper: service innovation is about the whole enterprise, not just IT
(re Proper) RT @SAlhir: RT @GrahamHill: RT @adfig: Last issue of ‘Service Science’ just out. http://bit.ly/cGIJv0 #servicedesign
gollwitzera Erik provided interesting cross link to research activity – see http://service-science.info/
Proper: recommends S2IP (sustainable services), TOGAF ADM (but *not* fixed IT-centric scope), VPEC-T (see @taotwit, @5Di), TRIZ
Proper: use design-science (create something, trial it, evaluate, iterate) as a way to enhance TOGAF in live practice
Proper: looking for #entarch case-studies for research @erikproper
Proper: difference b/w ’service’ and ‘capability’: capability implies ability to *execute* a service
jdevoo @erikproper @tetradian What is the role of business schools in educating on EA? E.g. http://bit.ly/aVV2pg

Mike Rollings (Burton Group): Changing the Conversation – Becoming Business Relevant by Redefining Your Focus

Rollings: quotes Gary Hamel and Shoshana Zuboff on drivers for overall rethink of management – making EA relevant in that shift
Rollings: Hamel: “removing the pathology of the management hierarchy” – becoming social-systems architects, human-centric
Rollings: Zuboff “There is no detailed map of the territory ahead – you are the mapmaker” – design-thinking, again human-centric
harmenberg Mike Rollings at: it’s good to see someone with presentation capabilities…
Rollings: th term ‘enterprise architecture’ does’t describe complexity behind it – we need to describe in business language not EA’s
Rollings: ‘enterprise architects’ are not the only ones doing EA-type work – our role is not to teach EA but help others *apply* it
CH_FEDARCH Burton Group Speaker says, architects need to change not only their language but their behavior to be more relevant to their org
Rollings: EA’s application should increase the awareness of dependencies, implications and constraints for decision-making
Rollings: most people do not care what ‘EA’ is, what they care about is the value gained from applying it
erikproper @tetradian Meanwhile, EA is still positioned subordinate to the CIO …
Rollings: integration not about EA (for its own sake) it’s about how well we connect with the other disciplines – watch for friction
Rollings: what are others’ roadblocks / blindspots to making better decisions – EA should illuminate range of perspectives context
Rollings: relevance: “examine everything from the context of another individual” – what is the problem that they’re experiencing?
Rollings: collaboration “develop a shared context from a fabric of ideas” – start from the intended outcomes, dynamic, opportunity
Rollings: “change the focus from the institution to the individual” – orgs are made up of unique people with unique views/needs
Rollings: change EA behaviour: individual > initiate, collaboration > engage, relevance > empathize, perspective > visualise
overall, a very useful / expressive / *relevant* presentation from Mike Rollings – recommended
Rollings: need to make the elements of EA more approachable, change the discussion to serve and to become more business-relevant
Rollings: a coming split between IT people who are running things vs those who focus on helping business improve/extend capabilities
Rollings: “the point is that ya gotta learn the business!” – strongly agree
mikerollings RT @tetradian: Rollings: “the point is that ya gotta learn the business!” – strongly agree #burtongroup #gartnerea
trouxsoftware Rollins: BPM teams separate from EA. Do not think that they are doing EA. Similar to how many others pursue SOA. #entarch
process2go RT @tetradian Rollings: most people don’t care what ‘EA’ is, they care about the value gained from applying it similar for #BPM
harmenberg Mike Rollings at: ‘language and communication are at the heart of many problems.’ A case for ArchiMate I would say!
bergmart @harmenberg I disagree with you. ArchiMate is for enterprise IT architecture not for enterprise business architecture.
harmenberg @bergmart yes, we do disagree. There is more in BA than in ArchiMate, but ArchiMate is more than enterprise IT architecture
erikproper @harmenberg Indeed. ArchiMate is more than EntWide IT architecture, but we are missing relevant aspects. Let’s clarify what we mis!
marcostong17 Proper: mentioned 3 levels of capabilities for service innovation. And service innovation is or cause enterprise transformation.#ogrome

Len Fehskens (Open Group): Business Architecture – Just Another IT-Centric Idea?

Len Fehskens session: Is ‘business-architecture’ just another IT-centric idea?
ARSzakal The practice of Business Architecture is a discipline of EA. Architects who practice BA, EA and EITA apply all of these disciplines.
ARSzakal Ok so we don’t really have a defacto industry agreement on what it means to be a business architect.
ARSzakal Show me someone who suggests they only practice EA and not EITA or BA and not EA and I’ll introduce you to the unemployed.
ARSzakal You almost never see a real productive archtiect only focus on one architectural discipline.
omkhar RT @ARSzakal: Would you create a business architecture and never create the supporting IT architecture? I think not. // agreed
Fehskens: IT centric defn of ‘business-architecture’ is probly OK is we’re honest about it, though it’s only useful to the IT domain
Fehskens: it would be helpful to remember to stop partitioning the world into ‘the IT’ vs ‘the business’
mikerollings Len Fehskens the separation of IT and the Business causes bias and is an outdated idea – I couldn’t agree more
industryleaders The main conclusion is that EA must be business relevant
Fehskens: ‘the business’ really deserves a more thoughtful characterisation than ‘whatever isn’t IT’
Fehskens: the ’siren song’ of “if the business had an architecture it would be easier for the IT architecture to align with it”…
sebastian_zeeb Business meets Architecture – Mind the Gap. The Lever for Integration of Processes and IT. http://bit.ly/abc90a #eacom
Fehskens: IT-centric version of ‘business architecture’ hijacks the term for another needed concept of ‘architecture of business’
Fehskens: “IT is a function; ‘the business’ is not” – very important distinction
ARSzakal Would you create a business architecture and never create the supporting IT architecture? I think not.
Fehskens: ‘naming-inflation’ – “naming something this way does not “automagically” realize our aspirations”
trouxsoftware Fehskens: Today, “enterprise architecture” is routinely used to mean “enterprise IT architecture” #entarch
Fehskens: names set expectations – we need to be more rigorous about naming (he presents some *very* useful rigour/syntax etc)
ARSzakal Discord between business and IT results from our separation of the management of the business function and IT operations.
Fehskens: IT-centric term ‘business architecture’ is convergence of several bad habits of enterprise IT-architects: need to fix this
mikerollings Allen Brown “if I use the word ‘enterprise’ outside the Open Group crowd, they think I am talking about Star Trek”
ARSzakal Business Architecture is the business strategy, mission and planning – this evolves in realtime and informs the EITA.
mikerollings EA as a profession: too broad of a designation. Current certification of someone as an ‘EA’ demands the question “what kind?”
mikerollings EA as a profession also misses that many outside IT do planning, optimization, and design without calling it ‘EA’ #gartnerea
BurtonGroupIT Great conversations happening at Open Group Conference Rome and Burton Group’s @mikerollings #burtongroup #gartnerea

David Potter (Quantum Lifecycle Management spotlight)

Quantum Lifecycle Management: open, trusted whole-of-life lifecycle mgmt for trillions of objects in ‘internet of things’
omkhar QLM – Quantum Lifecycle Management is the next leap beyond Product Lifecycle Management
Technodad David Potter introduces Quantum Lifecycle Management group @ – sharing lifecycle info for “Internet of things” http://post.ly/dWez
industryleaders At Quantum Lifecycle Management Meeting going beyond PLM
Technodad Jacopo Cassina at #QLM meeting at : how to replicate the “village cobbler” experience across design, supply and service chains

Sebastian Zeeb (Detecon International GmbH): The Business Value of Information – Information Architecture Case Study Telecommunication

Zeeb: “what’s the use of a common language if nobody wants to talk?”
Zeeb: “Information need from today’s business require a holistic approach to architecture” – strongly agree
Zeeb: (exactly what it says – is a detailed case-study for Enterprise Information Management – very useful if you need case-studies)
5Di RT @tetradian: Zeeb: “what’s the use of a common language if nobody wants to talk?” > why ‘Values’ and ‘Trust’ are important #vpect
StevenvtVeld @sebastian_zeeb “holistic approach to architecture” Do you agree this approach is outside IT? Ought to define need. @tetradian
StevenvtVeld @sebastian_zeeb In practice we see big differences between information and IT professionals. Like demand versus supply. @tetradian
StevenvtVeld @sebastian_zeeb Ah, you’re talking supplyside Information Architecture. Then what do you mean by holistic?
StevenvtVeld @sebastian_zeeb Only reason for demand for IT is information. Conceptually this demand must be holistic. Good to see holistic supply

Robin Meehan (Smart421): Producing Metrics to Measure Strategy-Execution Alignment During ADM Phase E / F

Meehan: “how do we know how well this project portfolio moves us towards the business vision?” – hence need for metrics
Meehan: “Is the target to have 100% alignment? Not necessarily … stop once you’ve got value from the process” – pragmatics
Meehan: emphasis on alignment to intended *execution* – alignment to strategy should have been dealt with in previous ADM phases
Meehan: “if there is no traceable ‘business value’ [in a project or its execution], then why are we doing it?” – stop ‘pet-projects’
Meehan: (runs a demonstration inside Sparx Enterprise Architect) – good illustration shows where an objective has no IT support etc
Meehan: if a strategy has no change-project to implement it, it ain’t going to happen…
Meehan: “[metrics will show that] some projects have no discernable relationship to strategy” – often points to tricky politics
Meehan: provides a means to test whether strategy is deliverable (or that anyone is actually delivering it) – enforces SMART checks
Meehan: a lot of the issues are from the strategy side (e.g. implicit, too woolly, ‘pet project’) rather than on the project-side
Meehan: important to have an ‘innovation-strategy’ item to provide traceability for innovation-projects, don’t hide as ‘pet project’
Meehan: “not all traceability relationships are equal, not all projects are considered equal” – e.g. 1-5 scale for opportunity-cost
gfriend Important reminder! RT @tetradian: Meehan: if a strategy has no change-project to implement it, it ain’t going to happen…

Mamdouh Ibrahim / Kevin Daley (IBM) session: Actionable Business Architecture

Mamdouh Ibrahim / Kevin Daley
Daley: “is it ‘IT/business alignment’, or ‘IT/business convergence’?” – explicitly places ‘business-architecture’ as part of IT…
Daley/IBM: (personally I *really* strongly disagree with his very IT-oriented base-assumptions here, but that’s just my opinion…)
Daley: “split the business conceptually into ‘Strategy & Transformation’ and ‘Operations’” – because they have different worldviews
Ibrahim (IBM): “addressing #bizarch only as a piece of traditional ([IT-centric) #entarch can be problematic"
Ibrahim: if bizarch is seen only as IT, business-stakeholders won't/don't participate - also who owns the bizarch?
Ibrahim: use-cases are the best mechanism to capture *systems* reqmts, but may not be suitable to capture *enterprise* reqmts
Ibrahim: incorporating bizarch as a critical and business-relevant component of entarch requires a new perspective
Ibrahim: actionable business architecture may be used/usable for understanding of business on its own [e.g. without assuming IT]
Daley: “information technology has become almost inseparable from the business itself” – [oh no, not again... rampant IT-centrism]
Daley: [okay, this is IBM selling tools, but this is exactly what *not* to do with business-architectures... e.g. IT-driven BPR/BPM]
Daley: [what is 'actionable business architecture'? seems to be 'whatever bizarch can be implemented by IBM automated tools'???]
Daley/Ibrahim: [an odd presentation - half extreme IT-centrism, half real awareness of bizarch beyond IT]

Salah Musa (Object Computing International): ‘The “Business” in Enterprise Architecture – The Business Value’

Musa: entarch *must* deliver *demonstrable* business-value – keyword here is ‘demonstrable’ (and “perception is reality”)
Musa: “is the reason why we need ‘IT/business alignment’ because IT is more broken than any other function within the business?”
Musa: if IT focus only on cutting costs, can only save a few million; but if focus on creating value, can return far far more
Musa: [EA defined as a subset of IT - again... how many more years before the discipline can finally break free of this mistake??]
Musa: “reality, awareness and perceptions are completely different from each other” – yes, that’s important, esp. for #entarch
Musa: “bizarch building blocks are data, people, function and rules organised by location and timing” [yes, *people*, not just IT]
Musa: “facilitate change [with] more complete and accurate info for line managers etc to make decisions” [yes, decision-support]
Musa: “give custodianship of EA to the corporate enterprise! but are they interested, and how?” – good questions

Other sessions

harta75 Interesting SOA discussion about services and the importance of keeping the service contract stable @#ogrome
industryleaders Attending to emergence of industry reference architectures in financial markets
omkhar Very interesting presentation on Cloud Computing ROI by Mark Skilton
chrisjharding @omkhar We will build on this in the meeting on Business Architecture for Cloud Services at 9:00 tomorrow
rmeehan Just posted Open Group Rome 2010 day 1 blog – http://smart421.wordpress.com/2010/04/28/open-group-conference-rome-2010-day-1-blog/
omkhar At a very interesting Realtime / embedded systems group talk.
harmenberg ArchiMate Forum meeting at: discussing steps to take and futher releases of ArchiMate

Bob Weisman: ‘Using TOGAF 9 in Conjunction with Other Frameworks on Emergency Management Systems’

Weisman: Web 2.0 is collaboration, it’s not about technology
Weisman: need a unified architecture in the collaboration environment [architecture is *more* important in agile response, not less]
Weisman: a key problem is culture: creating willngness to share, then technology (capability to share), policy (rules for sharing)
Weisman: managing expectations – don’t promise what you can’t deliver – interoperability is much trickier than it looks
Weisman: pre-planning on governance and resources provides an architecture for the architecture – test in e.g. live simulation
Weisman: a lot of architectures fail because of implementation issues around acquisition – if you can’t get it you can’t build it!
Weisman: “pick the content metamodel” – too many to choose from? (MODAF/OMG UPDM etc etc) but all implementable, all maintained
Weisman: [my own opinion: this is _much_ more real-world than the finance/insurance etc models we usually see for TOGAF etc]
Weisman: for interoperability, re-use and extend existing models (incl. arch. models), don’t create new ones w/o v.good reason
CH_FEDARCH @tetradian I agree, government cases are *real world* and are insightful – especially for other gvmt guys…
Weisman: (provides a crossmap between TOGAF phases, DODAF deliverables, UML etc models to ‘get everyone on same page’)
Weisman: people talk about interoperability, but as soon as they have to *do* it, they tend to back away…
Weisman: capability: ability of a person, process or organisation to provide business value
Weisman: models for interoperability for emergency-response will be available publicly in the fairly near future

Sanda Morar (Cognizant): ‘Integrating TOGAF Architecture Development Method with Other Enterprise-wide Processes’

Morar: TOGAF spec says that “in all cases” adaptation will be required – ie. the ’standard’ is not an out-of-the-box standard
Morar: a lot of talk about mapping (between TOGAF and other frameworks), but info was not that much actual help in integrating them
Morar: (appears to be a crossmapping of TOGAF phases with Zachman layers – row-1 to row-5? struggling with proprietary IP again..)
Morar: diagram suggests that TOGAF metamodel needs entities for lifecycle, technical constraint – good point
Morar: (focus of their MLR model is requirements rather than architecture as such, but there is a useful crossmap between them)
Morar: [my opinion: this is again showing the fundamental problem with TOGAF's fixed IT-specific B/C/D scope - ADM needs open scope]
Morar: crossmap to TOGAF metamodel provides a very valuable crosscheck – gaps in their own model “jump out” from the comparison

Other sessions

omkhar My Security in the Cloud presentation begins at 4pm local
jim_hietala Listening to @omkhar and Stuart Boardman describe great progress on a cloud security reference architecture at
harmenberg Useful meeting of ArchiMate Forum at, with a number of concrete steps to take the coming month(s).
harmenberg Alexander den Hartog (Boskalis) presents on the use of ArchiMate at Boskalis.
harta75 Had a lot of questions about use of Archimate in Boskalis at. Always good to have discussions after a presentation.
rmeehan Blog from Open Group Rome 2010 day 2 posted http://smart421.wordpress.com/2010/04/28/open-group-conference-rome-2010-day-2-blog/
rmeehan Good event – well done to Open Group organisers. Any event with wine at lunch time every day has got to be good )

A week in Tweets: 21-27 Mar 2010

Tom G — Sun, 04 Apr 2010 13:59:00 +0000

Running a bit late this time due to self-imposed pressure to get a book complete. But it’s the same old miscellany of a week’s-worth of Tweets and links, sorted into the same old categories, preceded by the same old ‘Read more…’ link.

Enterprise-architecture, business-architecture, business-strategy and various themes around the structure of business:

SAlhir: RT @jorgebarba: Why Businesses Don’t Experiment – Harvard Business Review http://ff.im/-hPD7d

SAlhir: RT @jorgebarba: Innovation posts of the week: Break patterns. Create new ones to spread your ideas http://ff.im/-hPINJ

unorder: Anecdote post: Strategic stories http://bit.ly/9S0gwg featuring the amazing origami video HT @vivmcw

tebbo: Thanks @dweinberger ‘Is authority the first word or the last?’ http://j.mp/ajgGdL < #entarch #bizarch #e20

aojensen: Zachman Framework: Not a Point of Departure for an Enterprise Methodology (http://bit.ly/dpQ1il) #EntArch #thinkingenterprise

CreatvEmergence: RT @zenext: vision is not a denial of problems, nor the search for solutions, but the creation of a whole new reality all together

CreatvEmergence: RT @SemiraSK: Organizing For Uncertainty – a Rich Agile Model for the Organization of Work by @zenext – http://bit.ly/bygL7Q

joyce_hostyn: visualizing the customer experience through customer experience journey maps http://bit.ly/bmYVo0
oscarberg: RT @driessen: Who Owns Information Architecture? All Of Us. | Forrester Blogs http://bit.ly/diYRjC via @driessen < #entarch #km

joyce_hostyn: 10 new business models for this decade http://bit.ly/daErqJ (also: the knowledge game to brainstorm your own http://bit.ly/9WHxKg)

CBAtInnovation: RT @jamet123: Blog post: Business rules are king #gartnerbpm http://bit.ly/cGq0n7

tetradian: ‘On business-rules’ (response to Gartner’s ‘Business rules are king’) http://bit.ly/bM4hhY #entarch #itarch #in

You_Me_Us: Customer Experience Lessons From Marks And Spencer http://bit.ly/9874EA

SAlhir: “Responsiveness, emergence and self-organization” RT @EskoKilpi: Complexity and the Internet http://bit.ly/7M3K2J and http://bit.ly/a2xDUF

SAlhir: RT @zenext: We don’t create vision to better see inevitabilities in the future, but to better to see possibilities in the present.

tetradian: Kevin Smith (PEAF): ‘The Pragmatic Gardener’ http://bit.ly/9mkGTZ

CreatvEmergence: When creativity & imagination are infused into knowledge & information-based structures, a system becomes generative & alive. // In addition to being agile and adaptive, organizations need to become generative.

Tomoye: The Economist: The open society, Governments are letting in the light http://bit.ly/clN5tr

Mule_Kick: Blockbuster Business Model Update – Can the #businessmodel be fixed http://bit.ly/b7iGPX

davidcushman: http://www.stoweboyd.com/message/umair-haque-is-another-new-spatialist.html > epic stuff from @stoweboyd < #e20 #entarch – brilliant expansion on a previous slidedeck, using an urban-planning motif to re-assess different approaches to social-media etc

Cybersal: Attended John Kay’s talk on Obliquity at RSA and bought the book. “The most profitable companies are not the most profit-oriented” #rsakay

SAlhir: “Leader & followers R both following the invisible leader — the common purpose.” http://bit.ly/aNolzx #tlcc

CreatvEmergence: RT @frankspencer via @VenessaMiemis, @rotkapchen: Thinking in the 21st Century Organization – http://bit.ly/bdYBri

hebsgaard: HBR: The Delicate Art of Unauthorized #Innovation http://bit.ly/dui4od

chrisdpotts: Susan Cramm writing for HBR on “IT Leaders, it’s Time to Give It Up” http://bit.ly/diKW8p – vital step in 3rd-Generation CIO strategies

(via @hebsgaard) Mike Brown: Innovation Metrics: a ‘whole-brain’ strategy http://bit.ly/8ZIyjX

joyce_hostyn: “Most companies are corporate iguanas.” Reptilian brain to act. Neocortex to think. But no limbic system (empathy, courage) – Wired to Care // Deeply unfortunate, because companies are made up of people, not iguanas. And people, not iguanas, buy products and services.- Wired to Care // Solution? Open channel of empathy between org & customer. Show employees link between what they create & people who use.

toddbiske: New blog post: Enterprise Architect: Advisor versus Gatekeeper http://www.biske.com/blog/?p=768

DavidGurteen: Dave Snowden: Origins of Cynefin (pt.1) http://j.mp/dmkeqx

SAlhir: RT @jorgebarba: Chaos by design http://ff.im/-icTOu

Narrative knowledge, knowledge-management and in-person collaboration:

oscarberg: Knowledge = the things you have already understood & can use to take the proper action (or avoid taking action) // Information = the things you need to understand to take the proper action (or avoid action) but don’t yet have received or understood // Your knowledge can only be evaluated from your actions or non-actions – exceptional performance = wisdom

oscarberg: RT @lindegaard: Recognition and Respect: How to Earn It | 15inno.com http://tinyurl.com/y87njju

DavidGurteen: PKM in a nutshell (by @hjarche) http://bit.ly/aZNWQ2 #km

business_design: Nice infographic on dialogue by @prugelmeister http://post.ly/Uf3L (via @davegray) http://post.ly/Ufl4

DavidGurteen: Knowledge management and technology http://bit.ly/dhWyjv #KM

EnterprisingA: Thought for today: Knowledge is not wisdom. Experience is not ability. Volume is not value. Perspiration is not productivity.

oscarberg: It’s not trust. It’s social capital. http://bit.ly/d1885E #e20 not work…

CBAtInnovations: RT: @jens_coldewey: An old but great article by @jerryweinberg: Why we never run out of reasons: http://bit.ly/b8Vpk2

davidcushman: FasterFuture: Plug collaboration into your business http://bit.ly/9WaE77

thoughttrans: RT @presentationzen: The secret to great work is great play http://snipurl.com/v2zhs (new pz post)

joyce_hostyn: RT @rossdawson: How to build participative strategy in large organizations http://bit.ly/aWOzQb

hebsgaard: Why People Fail http://tinyurl.com/ye6vhg6

bartleeten: John Hagel: Passion and Reason http://icio.us/vaxhxn

Social-media, ‘Enterprise 2.0’ and in-person collaboration:

oscarberg: Nestle: Don’t be Human, Even with Social Media. We will hate you for that http://dlvr.it/L2Ns /via @rickmans

Cybersal: Maslow’s Hierarchy of Enterprise 2.0 ROI http://bit.ly/a7t36O>>nice expression of trade-off: measurability v impact (via @pevansgreenwood)

oscarberg: Enterprise 2.0 and our tendency to think and talk in terms of efficiency http://goo.gl/fb/H2qk

CreatvEmergence: @VenessaMiemis Junto: Discussing Ideas Worth Spreading @ http://bit.ly/aRhPFp

oscarberg: With social software, other people help you find, organize & refind your digital stuff – it’s Social Information Management // I used to be an Information Architect – now I help customers so they can do the organizing & findability stuff themselves

You_Me_Us: Does Nielsen’s 90-9-1 still add up in 2010? Help us find out http://is.gd/aTTyV

ChristineArena: RT @TomOB: RT @chrisbrogan The end of the social media? I’ll keep working, thx. http://bit.ly/b3pUlL (and they are selectively approving comments!)

DavidGurteen: Enterprise 2.0 is not a game anymore, it’s serious business http://bit.ly/cP1rOG

oscarberg: RT @ceciiil: New post #e20 evangelists: the revolutionaries and the evolutionaries http://wp.me/p58hh-AE feat. @oscarberg Vs @bduperrin

craighepburn: Driven by distraction, the value of social networks! http://post.ly/VN7t

DavidGurteen: By @jonhusband: 10 General Principles For Leading and Managing in the Networked Knowledge Workplace http://bit.ly/bIk22Z

Technical-architectures and technical matters in general:

taotwit: IBM on Event Processing here http://bit.ly/aUfY3x – interesting defs of Simple, Complex and Business Events #sbep #entarch

toddbiske: it continues to amaze me how little shared #entarch doc templates are available on the internet. // Example: Technical architecture questionnaire for due diligence. All big companies (should do) it, nothing proprietary about it. #entarch

eatraining: Does Microsoft have an EA Framework like TOGAF ? http://www.mikethearchitect.com/eatk/

Society, culture, business social-responsibility and suchlike matters:

DavidGurteen: RT @neridahart: fascinating view of our world from Dave Pollard http://bit.ly/8ZOHIl <’Manifesto – how to save the world’ – “I am not a consumer” etc

joyce_hostyn: cultivating insights through the culture networks that shape us – excellent presentation by Tim Stock http://bit.ly/96snE3

oscarberg: If we had a different def of making a career than climbing up hierarchy, we would already have other ways of organizing work

CreatvEmergence: RT @simonmainwaring: IDEO magazine launches monthly column. Super cool. I think it’ll be worth checking out. http://bit.ly/cl3FG6

And, of course, the meritoriously magnificent miscellany:

SAlhir: RT @chrisbrogan: Thousands of blogs give commentary. Hundreds give how-to. How many give you “why?” <- Fundamental question…

oscarberg: RT @euan: powerful, powerful water image http://bit.ly/aoklGE > Wow!

thoughttrans: Article: Memory Isn’t Consistent http://short.to/14fpq

CreatvEmergence: Childish Creativity @scienceblogs – http://bit.ly/b0xTsV

CreatvEmergence: Nature by Numbers video (worth seeing in its entirety): http://youtu.be/kkGeOWYOFoA (via @SheriHerndon)

unorder: RT @hnauheimer: Wow! The best and simplest demonstration of complexity I have seen: http://bit.ly/10NIEw (via @reverand)

CBAtInnovations: RT: @NigePaulDavis,@GuyKawasaki: Sneak peek at the new Photoshop http://tinyurl.com/yg96ow3 >Wow, timesaving Content-Aware Fill. Can´t wait. serious image-faking once this is released…

On business-rules

Tom G — Wed, 24 Mar 2010 09:52:12 +0000

Reading James Taylor’s recent piece “Business rules are king“, pretty much every one of my enterprise-architecture alarm-bells went off.

Yes, it’s a good article – recommended reading. And I would strongly agree with its implication that there’s a real and urgent need for discipline around business-rules. But the reason for the alarm-bells is that it’s promoting business-rules as ‘the answer’ – and for the most part IT-based ‘business-rules engines’ at that.

Which us places straight back in Taylorist territory, along with all those other classic IT-driven business failures such business-process re-engineering. Not a good idea…

The reasons why it’s not a good idea are three-fold:

placing all the business-rules into an automated system will lead to a ‘fit and forget’ attitude unless there is a very strong emphasis on rule-maintenance – one of many ‘human factors’ that were forgotten about in BPR’s rush to ‘IT-ise’ all business processes

identification and codification of business-rules assumes that the rules that can be derived from the people who run the existing processes are sufficient, invariant, accurate and complete – which, as early-generation knowledge-management also discovered, they rarely are…

the viability of using automation for decision-making is dependent on the context – a fact of which frighteningly few IT-system designers seem to be aware

There seems to be a view that everything can and must be reduced to simple rules, following a cart-before-horse thinking that everything should be done by IT, and simple rules are what IT handles best. In other words, dangerously back-to-front. It’s bad enough trying to get anything useful out of IT for decision-support; but using IT for all decision-making – which is the ‘nirvana’ that the article would evidently prefer – is likely to be lethal. And I don’t quite know what we as enterprise-architects can do to prevent this headlong rush into repeating the exact same mistakes as in BPR and the rest – all that’s different this time is that it’s more explicitly coming from the ‘rules’ part of the process, rather than process-implementation overall.

This is clear if we look at it from the perspective of context-space mapping:

The point is that there’s a spectrum of abstraction of rules: principles sit at the low-abstraction end of this spectrum, rules sit at the high-abstraction end – in fact a conventional ‘rule’ is actually an extreme abstraction of a principle that applies to a specific context. If we try to use the wrong level of abstraction, especially in the wrong context or wrong type of context, we are all but guaranteed to hit serious trouble. And I see little to no awareness of that fact in most of the current literature on business-rules: instead, there seems to be an assumption that just about everything can be reduced to simple binary rules that can be implemented by simple IT, because that’s what we want to happen. In other words, the entire approach seems driven by little more than wishful thinking – which again is not a good idea…

IT-systems and simple business-rules work well together: both operate on a binary true/false logic, and both will enable high-speed binary-logic decision-trees – in other words, over on the lower right-hand side of the usual Cynefin-derived context-space base-map.

Most IT-based analytics – over on the upper-right of the base-map – work on the same binary logic as the simple systems, but introduce the ability to handle more and more layers of complication. The catch is that each layer of analysis takes a finite amount of time – which takes it further away from the ‘Now!‘ demanded by real-time decision-making. And the only real result of increased computing-power has been to increase the levels of complication in the analytics, sometimes beyond anyone’s ability to understand it – as was the case with the software systems used in many of the risk-calculation models that drove the current financial crash.

IT-systems are still not good at handling non-binary modal-logics – “the logic of probability, possibility and necessity”, such as expressed in the MoSCoW set of requirements-priorities of must, should, could and can wait. Humans are very good at modal-logic; IT isn’t. James Taylor’s article refers to pattern-based decision-making, which places it somewhat on the upper left of the base-map – but note again that each pattern-match must always take a finite amount of time, and it does not fit well with the underlying binary-logic of current IT-systems. Using IT as decision-support for human decision-making is generally okay, but the more that IT is involved, the higher the risk of what Dave Snowden describes as ‘pattern-entrainment’ – in other words, premature selection of a pattern, trying to force-fit a pattern to the context rather than ‘listening’ to the context itself. Current IT is getting much better at near-real-time pattern-matching, such as face-recognition or smile-recognition on most present-day digital cameras. Yet as anyone who’s used such systems would know, they’re nowhere near accurate enough to decide when a picture is actually any good – and sometimes we don’t want a smile in the picture. Much the same applies in business: using automated pattern-matching is great for decision-support, but extremely dangerous for decision-making.

And no IT-system is likely to be much good at dealing with real-time chaos, ‘the new’, where no possible pattern exists because it is new – but again, real people can handle decision-making in such contexts via skills and principles. In those contexts, there are no rules – and yet business-rule proponents seem to promote the delusion that their ‘business-rule engines’ can handle everything.

So I’m wary: very wary. Before letting any of such systems loose on any real-world context, I would want to make very sure that they’ve done the appropriate context-space mapping, and matched the decision-making methods to the respective contexts. But I don’t see much evidence of that: what I see instead is way too much wishful-thinking, and an almost desperate desire on both the business-side and the IT-side to try to force the world to fit their respective delusory dreams of ‘order’ and ‘control’. Oh well… Guess we have to wait and let them fail yet again, even more expensively, and then set out to tidy up the mess? – though I do worry that we’re getting close to the point where we’re no longer able to afford such expensive mistakes, in any sense of the word…

Enterprise architecture and strategy

Tom G — Thu, 28 Jan 2010 20:13:30 +0000

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Strategy and architecture are different in some quite fundamental ways. Strategy sets the direction: that’s the whole point of any strategy-capability. Architecture identifies the available choices and constraints for the most effective structures, or configuration of structures, that could implement that strategy; it also usually makes some concrete suggestions towards design, but that’s where EAs should really be starting to hand over to the solution-designers, and so on down the implementation chain.

Strategy has a clear decision-making role; whereas it’s arguable that architecture should only have a decision-support role at the strategic level. The architect may well be landed with making key strategic decisions, perhaps for practical reasons, or because no-one else will accept the responsibility; but blurring the two roles together can be problematic, not least because of the risk of ‘cart before the horse’ strategies such as where an arbitrarily-chosen technology ends up driving the strategy, rather than the strategy driving the choice of technology.

For enterprise-architecture, this is another example of why it’s useful to distinguish between ‘organisation’ and ‘enterprise’. An organisation is tightly bounded by the respective rules; an enterprise is a much more fluid affair, bounded by shared-commitment to shared principles, vision and values. (In effect, as described in the previous post, the enterprise is a story.) Another way to understand the difference:

the organisation is about ‘truth‘, about demonstrable compliance to extrinsic constraints

the enterprise is more about ‘value‘, about mutual agreement and alignment with intrinsic constraints

An organisation and its rules can exist at any level, from a work-team to a huge conglomerate or an entire nation: hence a business is an organisation, with explicit legal boundaries of responsibility and control. Organisations can be nested, with the rules becoming more and more and specific as we move downward into the detail-layers of the organisation-hierarchy. So in this sense the IT-department is usually also a distinct organisation in its own right, an organisation-within-an-organisation, with its own rules and reporting-relationships. Similarly for each enterprise: these too can be nested, or intersecting – and usually are. There’s a special-case where the boundaries of an enterprise coincide with those of the organisation, which sometimes gives rises to the illusion that the organisation is the enterprise – but it’s important to understand that this is only a special-case, and one that is rarely useful for strategy or architecture.

If we follow the logic of this, some important themes start to become clear:

A strategy is a set of rules and guidelines for future action. It therefore applies primarily to an organisation (rules) rather than an enterprise (values).

A strategy is bounded by the context of an enterprise. To put it another way round, a strategy is only usable in relation to an enterprise. An enterprise-architecture, which identifies the structure and purpose of the selected enterprise-of-interest to the organisation, must always precede strategy – otherwise it will not be able to provide the necessary decision-support about the nature of the enterprise, on which the strategic decisions will depend. Without that architectural understanding, the assumptions about the enterprise on which the strategy is based may well be invalid – hence, for example, the prevalence of cart-before-horse ’solutions’ in so many organisations’ IT-strategies.

A strategy applies to an organisation, not to an enterprise. This is a direct corollary of the two themes above. Without awareness of this distinction, the rules of the strategy (extrinsic motivation) tend to feel ‘imposed’, and hence shut down commitment within the enterprise (intrinsic motivation).

A strategy for any given organisation must always be defined in relation to an enterprise with broader scope than that of the organisation. The enterprise defines the context for the strategy, and hence must be larger than the applicable scope for the strategy itself. Note also that if the enterprise boundary is the same as the organisation-boundary (‘the organisation is the enterprise’), there is literally no space for anyone outside to connect with the organisation, and hence no reason to do so – a classic source of failure in marketing and most other forms of ‘outward-facing’ strategy.

A strategy will almost certainly fail if any attempt is made to apply or impose it onto an enterprise that is larger in scope than the respective organisation. This again is a direct corollary of the previous two themes. In effect, what happens in such cases is that the encompassing enterprise is treated as if it is an ‘organisation’ that is under the control of the subordinate organisation. For example, attempts at monopolistic business-strategies will almost invariably cause resistance and rejection in the respective market (ie. enterprise), often by creating large numbers of anti-clients. For the same reasons, an IT-strategy that attempts to tell the overall organisation how to run its business is guaranteed to cause friction – further exacerbating the infamous ‘IT/business divide’ – and, again, will almost certainly fail as a result of that resistance.

A useful rule-of-thumb is that the enterprise in scope should be at least two to three steps larger than the organisation in scope, both horizontally and vertically. This guideline applies regardless of whether the organisation in scope is self-contained or is a subset of a larger organisation. For example:

business-strategy: defined in relation to partners and supply-chain (horizontal), and customers, prospects and broader community (vertical)

IT-applications: defined in relation to people-based and/or machine-based components of processes (horizontal), and business and its customers (vertical)

IT-infrastructure: defined in relation to buildings, power-supplies, cabling and other physical infrastructure (physical-horizontal), IT service-management (people-based horizontal), and IT-applications and business usage (vertical)

Hence business-architecture and applications-architecture are part of the ‘enterprise-architecture’ for IT-infrastructure strategy – but to say that enterprise-architecture is solely about those specific IT-related themes is to miss the point. An enterprise-architecture is always about a scope larger than that of the respective strategy – whether the strategy relates to IT or anything else.

Most existing IT-centric ‘enterprise-architecture’ frameworks completely fail to understand this crucial point. TOGAF 8, for example, described the ‘enterprise-architecture’ sufficient to guide IT-infrastructure strategy: it was not suitable (because not sufficiently-broad scope) for IT-applications strategy or, especially, business-strategy. TOGAF 9 has probably expanded the scope sufficiently to cover IT-applications-strategy, but is still far from sufficient for business-related strategy – even though many IT-folks try to do this, and then wonder why there’s then an increase in resistance from the rest of the business. TOGAF’s horizontal scope is also notoriously inadequate, describing all non-IT infrastructure-level items as ‘business’ (confusing horizontal with vertical); FEAF’s reference to ‘Human Capital’ and ‘Other Fixed Assets’ indicates a somewhat better grasp of horizontal scope, but still attempts to define strategy for higher-level organisation, from IT (‘department’ level) to ‘business’ (whole-of-organisation level). A whole-of-organisation or ‘business’ strategy’ will necessarily depend on a whole-of-enterprise architecture that describes the context two or three layers outward from the formal boundaries of the business-organisation itself.

So in effect every architecture-discipline can also do strategy – but only for the ‘organisation’ implied by their own discipline, and should only do so with the decision-support of an architecture that has a broader scope than that of the respective discipline. In practice, this means that IT-architects can of course do IT-strategy, but should only do so if they have a solid understanding of the enterprise (ie. ‘the business’) within which that IT will operate. The same applies for process-architects and manual-process strategy. And business-architects may also do business-strategy, but only if they have a solid grasp of the broader context described by a whole-of-enterprise architecture that can summarise the context of partners and suppliers, clients, prospects, non-clients, anti-clients and the entire business milieu.

To do strategy, you must be facing outward, towards the enterprise. To do design, or to convert strategy to tactics, you need to be facing inwards, towards the fine detail. The aim of strategy is to define rules; much of architecture is more about identifying and expressing shared values. Expecting just one person to do all of these things is a big ask – especially in a large, complex organisation. Hence, although architects can also do strategy on the one side, and design on the other, it’s probably wisest wherever practicable to keep those roles apart.

A week in Tweets: 17-23 Jan 2010

Tom G — Sun, 24 Jan 2010 14:56:14 +0000

The current week’s-worth of assorted Tweets and links, in the usual categories, and with the usual ‘Read more…’ link to open ‘em up.

Enterprise-architecture, business-architecture and anything to do with the high-level overview of the business and the organisation:

enterprisearchs: IBM’s crack at Enterprise Architecture value: http://bit.ly/6Gy67P not bad

SAlhir: Crowdsource labor: Economic benefits of large orgs + Human benefit of small orgs (per @egobillot) http://shar.es/aBrs0 <#entarch

SAlhir: RT @PaulaGray: Corporations live or die by their connection to culture” Grant McCracken-Chief Culture Officer book @Grant27 // “Without a connection to culture, Coke is merely carbonated water and syrup” Grant McCracken-Chief Culture Officer

business_design Blogpost The Music Industry (part II) – two of the new models http://bit.ly/55pEzv

SAlhir: Organizational Entropy: measure of disorder/randomness by which work is created within an org. (via @mcottmeyer) http://bit.ly/7efjjy

rettema: EAM pattern catalog of TU Munich (Ger), worlds best cartography system for EA http://bit.ly/6nbGPj #EntArch

bartleeten: sebis : EAM Pattern Catalog Wiki http://icio.us/dqbwjj

greblhad: #entarch is a bit like the Swedish smörgåsbord it has a bite of everything

SAlhir: Forrester Customer Experience Index (via @btemkin: http://bit.ly/cxpi2010

(via @SAlhir) “Customer Experience Counts In All Channels” (re Forrester CxPi) http://bit.ly/8A4xOt #entarch #bizarch

tetradian: (via @SAlhir) LibertyMutual ‘Responsibility Project’ http://bit.ly/34ulRt and BusWk article (watch the video) http://bit.ly/6ADImZ #entarch http://www.responsibilityproject.com/ and BusinessWeek: “Liberty Mutual, Doing the Right Thing” http://www.businessweek.com/managing/content/jun2008/ca20080625_251589.htm – very important for visioning and for customer-centric #entarch #bizarch – describes what is almost a text-book example of how to do visioning properly, and what happens when you get it right

business_design: Business Model Canvas Poster V.1.0 of #bmgen available for download on my blog http://bit.ly/5Tlqbz

SAlhir: RT @Armano: 10 Ideas For The New Decade http://bit.ly/6gO7Go

oscarberg: Drucker: “In the knowledge economy everyone is a volunteer, but we have trained our managers to manage conscripts”. /via @VMaryAbraham

oscarberg: Systems that eliminate failure, eliminate innovation by @snowded http://icio.us/xoupma /via @johnt <”We learn from tolerated failure” – importance again of @snowded’s point about ’safe-fail’

tetradian: re architect/business relationship: Frank Gehry and ‘the organization of the artist’ http://bit.ly/5WGJM2 – key for #entarch #bizarch etc

greblhad: RT @leodesousa New my notes A&G Webinar The State of EA http://bit.ly/8rkwRn #entarch

jdevoo: Thinking of using the Matrix of Change to communicate transition to new Internet radio player across large organization http://bit.ly/6PqcEa <’Matrix of Change’ is a useful method and Windows-based tool for any form of comparative analysis

EnterprisingA: post on “Agile architecture – some random musings” http://bit.ly/6BiCCS

EnterprisingA: Following several requests I have posted my comments to @bankervision re: agile architecture on my blog http://bit.ly/6BiCCS

tetradian: “The autism of EA?” (with thanks and apologies to Patrick Lambe) http://bit.ly/8GPUVH

antosotomayor: Umair Haque (HBR): The Scale Every Business Needs Now http://bit.ly/79u8Er #in /via @raesmaa < (interesting: competition vs ambition)

greblhad: At first I thought about writing a book like Enterprise Architecture for Dummies, but I soon realized I embody the concept

adrianrcampbell: @greblhad In ‘EA for dummies’ the first topic should be that EA is not = IT Architect #entarch

EnterprisingA: RT @leodesousa: Starting Your EA Practice – what roles would you pick? http://ping.fm/SICnu #entarch <- Comments added

tetradian: BBC interview with Russell Ackoff – *essential* for all #entarch #bizarch practitioners http://bit.ly/6MnZlZ (apols, audio may be UK only)

business_design: Nice post – Curious about the book! IMHO lacks the crucial visualization of a BM RT @mdbraber: HBR: Framework for Biz Models http://bit.ly/7LLjvz

jdevoo: Location: Chile. Year 1971. Project name: Cybersyn. http://bit.ly/5uWV3u #VSM #egov

tetradian: r @jdevoo re Cybersyn, see also reconstruction and further detail at http://www.cybersyn.cl/ingles/cybersyn/index.html #entarch // Wikipedia page on Cybersyn http://bit.ly/6Pqgy1 #entarch – crucial early example of whole-enterprise (whole-country!) architecture

GetStoried: @CreatvEmergence: Convergence culture, collective intelligence, co-creating the larger story, participatory creativity – http://bit.ly/13DehP

enterprisearchs: RT @leodesousa A&G Webinar The State of EA http://bit.ly/5VioVp

greblhad: RT @bmichelson RT @j4ngis: “entarch” – snds lke a beast from LotR. “Oh, help us, they brought the Entarch. <- ha! <- And a killer Bizarch too

bartleeten: Where architects are spending their time http://icio.us/ibzeow

bartleeten: RT @bartleeten: A Resurgence of Portfolio Management? http://icio.us/d1rz5m

thoughttrans: SBDi Biz2Geeks Post: Before Strategic Plan http://short.to/11ump #in #e20 #bizarch

A discussion on enterprise vs organisation, starting from a throwaway comment by Paula Thornton (@rotkapchen):

oscarberg: RT @rotkapchen: There is no Enterprise. “Organisations are not things but patterns of interactions between people.”

tetradian: r @rotkapchen …I agree that orgs are “patterns of interaction between people”, but Enterprise requires purpose, else is literally aimless // r @rotkapchen org & enterprise not the same: org is defined/bounded by rules, structure; enterprise by purpose, shared-commitment

snowded: Possibly use ideation/rule based culture difference from anthropology. Purpose does not need to be articulated just understood

tetradian: @snowded: “Purpose does not need to be articulated just understood” – strongly agree, also ‘people know more than they can say’ etc

enectoux: @tetradian @rotkapchen “Enterprise” is what unify organizations to achieve the same ultimate target. Taken apart org are selfish and useless

krismeukens: @tetradian @enectoux @rotkapchen Enterprises are in the first place “systems” in their own right, with a predermined purpose

pauljansen: @tetradian ‘…enterprise by purpose, shared-commitment’ <- and by stakeholders (meaning ALL; intended, identified and all others effected)

rotkapchen: @tetradian “enterprise by purpose, shared commitment” Doesn’t exist in ANY firm I’ve worked for // And yes, they’re all effectively aimless. Why? The parts don’t have feedback to each other. There’s no transparency.

tetradian: . @rotkapchen: “Doesn’t exist in ANY firm I’ve worked for” – I repeat, ‘org’ (firm) is *not* the same as ‘enterprise’! http://bit.ly/8wWNSq // “[orgs] are all effectively aimless. Why? The parts dont have feedback to each other. No transparency” – agree w you on that

tetradian: . @krismeukens: “Enterprises are in the first place “systems” in their own right, with a predermined purpose”
JohnPolgreen: RT @tetradian @enectoux I generally use the term ‘whole-of-enterprise architecture’ to separate real-EA from IT-centric ‘enterprise’-arch

tetradian: . @JohnPolgreen: “do you have some sources?” defns ‘enterprise’, ‘architecture’ ‘Practical Guide to FEAF’, V1.0, US CIO Council Feb2001, p.5 // “Enterprise: an organization (or cross-organizational entity) supporting a defined business scope and mission.” // “An enterprise includes interdependent resources (people, organizations, and technology) who must coordinate their functions”… // “…and share information in support of a common mission (or set of related missions).” – does not assume IT, often may be >org // re FEAF defns: their defn of ‘enterprise architecture’ falls back to standard mostly-IT-centric, but ‘enterprise’+'architecture’ is broader

JohnPolgreen: @tetradian back on my turf – should have read The FEA def of ‘enterprise’ more closely… What about a source for def of ‘org’?

tetradian: @JohnPolgreen source for defn of ‘org’? – try Wikipedia?? http://bit.ly/71G6kV (I prefer “framed by … institutional rules”) #entarch

rotkapchen: @tetradian Now I’m just confused. Your piece describes enterprise exactly as I speak to it. Was there a point I’m missing you were making?

tetradian: @rotkapchen point was disagree with your ‘There is no enterprise’ – ‘orgs are patterns of interaction’, but enterprise is not solely the org

rotkapchen: @tetradian Ah! The message is for the ‘commoner’. People who believe that there’s a ‘they’ and a ‘company’ to talk to.

tetradian: @rotkapchen uh… sorrry…? what ‘message’? for what ‘commoner’? apologies, but I just don’t get what you’re saying here…

rotkapchen: @tetradian “There is No Enterprise” is attempt to reframe common reliance on a ‘thing’ vs. real people.

tetradian: @rotkapchen point taken, tho’ to me it still sounds way too close to Margaret Thatcher’s infamous “there is no such thing as society”

A brief discussion about processes and organisations:

oscarberg: Processes don’t cross organizations, it’s organizations that cut through processes

rettema: @tetradian @oscarberg Same statement as Michael Hammer, customer centric means no recognition of internal customers in processes.

tetradian: @rettema @oscarberg my take was that processes are often blocked by silo boundaries – esp. transitions b/w IT and ‘manual’ process-segments

oscarberg: @tetradian @rettema it’s a matter of which perspective we use when we define & address a problem / challenge

rettema: @tetradian @oscarberg The blockade states Hammer also as the internal customer, more imprtnt are his principls to redesign without blockades

Another brief discussion about checklists and blind-spots in architectures – particularly enterprise-architecture:

greblhad: RT @jorgebarba Using Checklists to Prevent Failure – Harvard Business IdeaCast – http://ff.im/-eHfWr < recommended for #entarch

greblhad: What are the common blind spots of #entarch?

tetradian: @greblhad: “What are the common blind spots of #entarch?” for most, inability to see anything beyond IT? at best, anything beyond the org?

greblhad: @tetradian I agree about those big issues. More interested in smaller issues like wrong types of viewpoints, missed viewpoints and such

tetradian: @greblhad hence your cross-ref to Gawande on checklists? ie. what are #entarch equivs of surgeon/pilot checklists? – v.good point…

greblhad: @tetradian cross-ref to Gawande on checklists? ie. what are #entarch equivs of surgeon/pilot checklists? – < Exactly

tetradian: @greblhad #entarch checklist item: create/maintain responsibility/RACI matrix for each arch.item – identifies stakeholders & engagement

Knowledge-management, narrative-knowledge and in-person collaboration:

oscarberg: RT @fdomon: The Community Manager: enabling knowledge flows http://bit.ly/8PycuW by @hjarche <#entarch is v.similar

SAlhir: Creation Spaces, Collaboration Curve, & Managing Knowledge RT @HarvardBiz: A Better Way to Manage Knowledge http://bit.ly/7cN1KJ

DavidGurteen: RT @DavidGurteen: Knowledge sharing: it may not be what you think it is http://bit.ly/6Fsr4p /good

DavidGurteen: How Social Ecosystems Grow (Or Not) http://bit.ly/7yUXWF #KM

‘Enterprise 2.0’, social-media and online-collaboration:

oscarberg: Is cooperation a better term than collaboration when reasoning about what value #e20 can create beyond teams?

BillIves: RT @stangarfield: Book review of Enterprise 2.0 by Andrew McAfee http://bit.ly/897uzV #KM #E20

oscarberg: #Agile impacts knowledge work in a similar way than #Lean impacted manufacturing. /via @EskoKilpi

oscarberg: Blogged: Enterprise 2.0 and Collective Collaboration – Part I http://goo.gl/fb/QVHv

oscarberg: Blogged: Enterprise 2.0 and Collective Collaboration – Part II http://goo.gl/fb/iIHH

jbowles: RT @humancapleague Complexity, the Web and the business of information by Harold Jarche #hr #workplace #e20 http://su.pr/1iLgkS

hebsgaard: Transparency and social pressure. Via @gilyehuda http://tinyurl.com/yzadjmb

bartleeten: Signs of Intelligent Life in the Corner Office http://icio.us/fr2crc

oscarberg: Blogged: Interesting Enterprise 2.0 Readings – Week 3 2010 http://goo.gl/fb/zW6Q

SAlhir: Social Business Reality: Beyond Twitter http://bit.ly/67ZXAr

Society, culture and corporate social responsibility:

SAlhir: The Compassionate Instinct (via @EmergentCulture @kaskadia: @FullySustainabl) http://bit.ly/5UmPKM <”Think humans are born selfish? Think again. Dacher Keltner reveals the compassionate side to human nature.”

Cybersal: Is anyone else getting irritated by the proliferation of trademarks for phrases in common use (eg. actionable architecture)?

And the ever-insightful-or-just-plain-useful miscellany:

Cybersal: Must-read blog for conference presenters about effective design of PowerPoint slides http://bit.ly/2iukdN (via @happyhenry) 4/5 bullet-points)

oscarberg: Blogged: How to switch to a new laptop in 5 minutes http://goo.gl/fb/wpLF

BillIves: Skype at the Tipping Point? http://bit.ly/7eBzxn from @robpatrob <”This is more than long distance and conferencing. An employee of Skype contacted me and told me that they have a permanent link between offices. So you can just look up and see your colleague who may be a thousand miles away. Quite a few of my friends are living in different cities from their families. Of course they contact their families by Skype – but one is leaving his connection open in the evening. So he is close to being home as he shares all the mundane as well as the special. This makes the distance shrink. So what I am seeing that is new – more than just a cheaper alternative to the phone – is the idea of “Presence”. As Skype comes to TV and into our living rooms and bedrooms and into our offices – we can connect as a matter of course. Time and space can shrink.”

EnterprisingA: Thought for today: Too often, the endless quest for information is driven by desire to avoid making a decision

EnterprisingA: Thought for today: Often, the only difference between fact and fantasy is the viewpoint

EnterprisingA: #rebadged (7) Don’t call it “disconnecting from the business and disappearing up your own techno-babble behind”. Call it “IT as a Business”

DavidGurteen: Unlimited Gmail accounts http://bit.ly/74ctVq /very cool

unorder: RT @tweetmeme Your Farmer List http://ff.im/-eBTGP

(via @modera6072) Danish Centre for Design Research: “Is Design Philosophical?” http://bit.ly/7Mot1S

unorder: Why questions get U big picture. What & How = details. When & where = stories and emotion. (conversation with @longboardfella)

The autism of Enterprise Architecture?

Tom G — Wed, 20 Jan 2010 20:05:36 +0000

Yet another longish one about enterprise-architecture (EA) and related themes – skip over it if that’s of no interest, otherwise click the ‘Read more…’ link to what follows.

This one starts not from a single Tweet, but a combination of several themes that have come up over the past couple of days.

Perhaps the first here was a one-line comment from Andrew Marosy on the long-running ‘What is the purpose of EA’ thread on LinkedIn. Various folks (including me) had been talking about EA in structural terms, but as Andrew reminded us:

EA is also about flows (information, goods, energy, control…)

…which, yes, strictly speaking, are also a kind of structure, but a structure in time – a dimension that’s all too often missed in the conventional approaches to EA. Important point, and one to which I’ll admit I haven’t paid enough explicit attention as yet in my writing on EA. Slightly blinkered in my thinking there, you might say.

Then there was a Tweet by Jörgen Dahlberg pointing to a review by Leo de Sousa of a webinar on the current state EA. There was a one-line quote that especially caught my attention:

think of data and information as the currency that the business runs on

…and yes, many IT-folks would think that, because that’s the ‘currency’ that they run on, too. But whilst it may be true that information is “the currency that business-management runs on”, it may not be the currency that the business runs on - a rather important distinction! We can just about get away with blurring them together when the business of the business is information – as is the case with banking, insurance, finance or tax, for example. But when the main business of the business is about things – as in retail or logistics – or about people – as in recruitment or consultancy or health or many government departments – then acting as if information is the core of the business is going to cause some serious problems. An article by KM specialist Patrick Lambe (which we’ll come back to in a moment) quotes an example where an over-focus on information about the activity has become a substitute for understanding the activity itself:

“Computerized baking has profoundly changed the balletic physical activities of the shop floor. Now the bakers make no physical contact with the materials or the loaves of bread, monitoring the entire process via on-screen icons which depict, for instance, images of bread color derived from data about the temperature and baking time of the ovens; few bakers actually see the loaves of bread they make… As a result of working in this way, the bakers no longer actually know how to bake bread… The work is no longer legible to them, in the sense of understanding what they are doing.” Richard Sennett The Corrosion of Character (New York: W.W. Norton & Company, 1998) p.68

In Cynefin terms, the information-centric view provides the semblance of control within predictable Simple or Complicated contexts, but actually prevents the understanding needed to make sense of what’s happening when the context moves into the inherently-unpredictable Complex and Chaotic domains. And much the same applies to management itself, of course: in service-modelling terms it’s just another ‘cost-centre’ support-service for the overall business – so if the managers start to think that they are the business, chaos and confusion will inevitably ensue… Failing to even acknowledge the real world outside of one’s own domain is a lot worse than ’slightly blinkered’ – more like heading towards a form of self-centrism so extreme that it could almost be classed as a form of mental disorder. What’s frightening is that this near-’autism’ seems to be regarded as normal, even ‘desirable’, by many in ‘the trade’ – which is not a good idea…

Which leads to the third theme in this thread, arising from another Tweet by David Gurteen, which pointed to a post on knowledge-management by Mark Gould, which pointed in turn to an old (2002) post by Patrick Lambe, and thence to a much longer essay of his, called ‘The Autism of Knowledge Management‘ [PDF, 76kb].

There is a profound and dangerous autism in the way we describe knowledge management and e-learning. At its root is an obsessive fascination with the idea of knowledge as content, as object, and as manipulable artefact. It is accompanied by an almost psychotic blindness to the human experiences of knowing, learning, communicating, formulating, recognising, adapting, miscommunicating, forgetting, noticing, ignoring, choosing, liking, disliking, remembering and misremembering.

Which fits exactly, because what we’re so often dealing with, in the obsessive IT-centrism of so much purported ‘enterprise’-architecture, is precisely the same kind of ‘autism’ – the autism of EA. In some ways it’s hardly surprising, since it’s the same kinds of people – myopic managers and information-obsessed IT-types – who are making the same kinds of mistakes in both KM and EA. And after all, EA is a close relative of KM, because much of it is about creating and conveying and applying a particular type of knowledge around the single central idea that ‘things work better when they work together’. For example, translate into an EA context Patrick’s comments (p.16) about use of a predefined ontology in KM:

The apparent objectivity of this approach collapses as soon as you look at how the

ontology is derived. It must be widely agreed, and there must be common definitions with

common meanings. Very little of real working life is run on agreed, common definitions.

At best we run on approximations to that. Most of what we do is highly interpreted, time

and place contingent, and constantly shifting. We disagree constantly on how to interpret

the world.

The apparent objectivity of this approach collapses as soon as you look at how the ontology is derived. It must be widely agreed, and there must be common definitions with common meanings. Very little of real working life is run on agreed, common definitions. At best we run on approximations to that. Most of what we do is highly interpreted, time and place contingent, and constantly shifting. We disagree constantly on how to interpret the world.

In EA, that’s the same kind of difference between a predefined ‘reference model’, for example, and the hard-graft that’s needed to make that model actually usable in the real world. So it’s well worth reading the whole of Patrick’s essay with an EA eye, because everything fits: all of the critiques, all of the consequences, all of the actions that need to be taken to get out of the mess.

First, Patrick describes “five big myths”:

The Myth of Reusability

The Myth of Universality

The Myth of Interchangeability

The Myth of Completeness

The Myth of Liberation.

An EA is supposed to be reusable: that’s the whole purpose of TOGAF’s Architectural Building Blocks and Solution Building Blocks, for example. That gives us useful content; the catch is that the real world is much more context-dependent, with the result that our ‘building blocks’ are often reusable only as abstract guidelines.

An EA is supposed to be universal, to apply everywhere throughout the enterprise: blunt fact is that it doesn’t, for exactly the same reason – the inevitability of context-dependent detail, and hence of context-dependent variation.

An EA is supposed to describe components that are interchangeable. In a basic IT-centric EA, they often are; but the reality is that as soon as a business-process touches the human domain – the so-called ‘manual’ process – almost nothing is directly interchangeable. We can sometimes use IT to convert raw data to business-information, but we always need real people to translate that information into contextual meaning and business knowledge. Which means that IT concepts of ‘interchangeability’ can’t apply at the level of the whole architecture of the enterprise. Which in turn means that a conventional IT-’EA’ will probably be too limited to be of much real use to resolve real-world enterprise-level concerns.

An EA is supposed to be complete, to cover every need in the enterprise. But as with measuring a coastline, any definition of ‘completeness’ depends on the level of granularity we choose – because the blunt reality is there’s an infinite amount of detail that could go into an architecture, which means that by definition a full description of the architecture could never be complete. Worse, the detail is dynamic, not static: by the time we’ve documented everything, the enterprise will have long since moved on. So an architecture can never be ‘complete’; the best it can be in practice is ‘complete enough‘ – which is a very different concern.

An EA is supposed to give us liberation – in particular, liberation from uncertainty. But it can’t: the world is uncertain. The best that our architecture can do is provide useful guidelines, and useful pointers for conversations towards appropriate action in an uncertain world: the key is that it’s not about whether our architecture is ‘true’, but whether it’s useful – which again is a very different concern.

Like so much IT-centric KM (and ‘Enterprise 2.0′, for that matter), IT-centric ‘enterprise’-architecture has spent a couple of decades resolutely refusing to face these facts. A few years back, much of what we saw would match all too well with Patrick Lambe’s comment about ‘the myth of liberation’ in KM:

So let’s talk about liberation. You don’t have to look far in the technical writing of knowledge-object enthusiasts to find almost mystical hyperbole about the potential of knowledge objects for humanity. Just look for the exclamation marks.

In EA these days there’s quite a lot less of that hype: instead, cynicism and disillusion have become a lot more common, especially amongst business-folks elsewhere in the enterprise, as the standard IT-centric TOGAF or FEAF architecture-developments have taken literally years to deliver little or no real business value. As a profession, EA is now at real risk of being dismissed as an insanely-expensive waste of time. So if we want the profession to survive, and start showing its real value, we need to do something about that, and fast. And the first thing we need to do is to face down the absurd ‘autism’ of so much self-styled ‘enterprise’-architecture.

Once again, Patrick Lambe shows us a way to move ‘beyond autism’. In the later section of the essay (p.20 on), he lists six key principles for a valid, functional, successful KM:

Highly effective knowledge performers prefer knowledge fragments and lumps to highly engineered knowledge parts.

Parts need to talk to their neighbours.

The whole is more important than the parts.

Knowledge artefacts provide just enough to allow the user to get started in the real world.

Learning needs change faster than learning design

Variety is the spice of life

To paraphrase these into an EA context:

‘Highly engineered’ components may make some degree of sense in an IT context – though in practice much less than many vendors would purport. But they don’t make so much sense at a true whole-of-enterprise level. Highly-effective users of architecture will usually prefer ‘knowledge fragments and lumps’, in the form of abstract principles and proven guidelines, than someone else’s pre-packaged ’solution’ that may well take more effort than it’s worth to force-fit into a different context.

Much of a functioning architecture is about facilitating conversations, so that ‘parts can talk to their neighbours’. Some of these ‘conversations will be at a detailed technical level, as messaging-interfaces, APIs and transaction protocols. Others will be literal conversations between people. Sometimes some of those types of ‘conversations’ may need to be interchangeable, at every level – especially in disaster-recovery scenarios, where we may need to have people take over the IT’s usual tasks, and swap back again once the emergency is over. Ultimately this brings us back to that basic principle of all architecture, that ‘things work better when they work together’.

The real danger of an IT-centric architecture is that it deal only with one part of the enterprise – the IT, and the small subset of enterprise information managed by that IT – and pointedly ignores the rest. But the enterprise is a whole: we can’t make sense of it by pretending that most of it doesn’t exist. We also can’t make sense of it as a whole without setting out to understand it as a whole – because the whole is greater than its parts, and is more important than any of its individual parts.

We need to provide the right amount of architecture – not too much, not too little. Without an intentional architecture, the end-result is chaos; but too much architecture makes the enterprise unwieldy, unyielding, inflexible, too reactive, too resistant to the inevitabilities of change. Our architecture artefacts provide just enough to allow the user to get started in the real world: a ‘just enough, just in time’ approach to architecture and to architecture-governance will give our stakeholders the clarity and agility they need, without getting in their way – and will be a lot cheaper all round, too.

Development takes time; yet the world doesn’t wait for us in the meantime. So architecture-needs change faster than architected designs: most large projects will be architecturally out-of-date by the time they’re complete, and we cannot know beforehand everything that we’re going to need. Whatever we do, it’ll be ‘wrong’ by the time we use it; there’ll always be something that needs fixing up, making do, making mend. Frustrating: always. So we need to acknowledge that as part of our reality; accept it, design for it, and move on. Service-oriented architectures will certainly help, especially if they extend beyond IT to the whole enterprise; but simply being aware that unexpected change is a certainty will probably help the most.

And yes, variety is the spice of life, in architecture as much as in most other maters. Whatever reference-model we develop, there’ll always be something that not only doesn’t fit but can’t fit: some ‘essential’ new system that someone needs, or some ancient legacy package limping along on even more ancient hardware. That’s a fact of architecture-life too: we need to work with it, not fight in futility against it… As before, the ‘just-enough’ approach is what’s needed here: and that depends on diplomacy, the delicate art of personal persuasion, a technical architecture, perhaps, but always one that includes our own human face.

That’s what architecture really is: an active expression of “the human experiences of knowing, learning, communicating, formulating, recognising, adapting, miscommunicating, forgetting, noticing, ignoring, choosing, liking, disliking, remembering and misremembering”. All those myriad technical details are important, of course, but it’s the human factors that make it work. Falling back into the ‘autism’ of conventional IT-centric EA is a guaranteed route to failure: we forget that fact at our peril.

TOGAF Phases B C D

Tom G — Tue, 15 Sep 2009 15:25:52 +0000

A few days ago my colleague John Polgreen posted an article of mine Adapting the ADM for Government Architectures on his ‘TOGAF for Feds’ blog on the (US) Government Technology Research Alliance (GTRA.org) website. The main theme was that to make TOGAF work well for non-information-centric government agencies and similar organisations, we need to do some significant changes to TOGAF’s Architecture Development Method cycle (the ADM). I summarised the modified ADM and taxonomy-framework, and illustrated all of this with a fairly lengthy case-study of the use of this modified framework in a government agency in the social-services sector.

The problem is that for many TOGAF practitioners, those changes are often too much of a jump from standard ADM practice. For example, in an unattributed comment on the blog, John’s colleague ‘GB’ complained:

One can transform TOGAF into any process one wants.

Is this really TOGAF for government? Or even for enterprise architecture?

Or is it TOGAF for business consultants dealing with a government department?

There are actually two separate points here. One is the implicit assertion that ‘enterprise architecture’ is still solely the architecture of the enterprise-IT; as John also mentioned in a comment, that notion is at last becoming more generally acknowledged as unworkable, and that we must extend the architecture out to the full scope of the enterprise. (Importantly, this extended ‘architecture of the enterprise’ is not the same as business-architecture.) The other is that many TOGAF folks are still uncomfortable with the idea of dumping the existing phases B, C and D – ‘Business Architecture’, ‘Information-Systems Architecture’ and ‘Technology Infrastructure Architecture’ respectively – even though they don’t work in practice for anything other than IT strategy-development and implementation. (In the re-worked version of the ADM they’re replaced entirely by a separate focus on as-is, to-be and gap-analysis for the selected scope – similar to the structure of the ADM in the earlier TOGAF 7.)

The core problems here are that the TOGAF 9 ADM is usable only for top-down strategy development (the sequence of the phases B, C and D), and only for IT-systems and IT-delivery (the current content of B, C and D). The enterprise-architecture method needs to cover a broader range of development types – overview, horizontal optimisation, top-down, bottom-up and spiral-out – and to address any scope in the enterprise. Hence the reason for suggesting some fairly fundamental changes to the ADM structure. But as long as we’re comfortable with sticking solely to top-down development, we can still retain something very close to the existing B, C and D, but capable of covering any enterprise scope. To do this, we rename the Phases as follows:

Phase B: ‘Business Big-picture’

Phase C: ‘Communication and Common’

Phase D: ‘Domain Detail’

Phase B: Business Big-Picture

In this layer we explore the strategic imperatives for the business – what we might call ‘business-architecture proper’ – and the business drivers that impact on strategy. This is all at the big-picture level, and would typically include vision, values, business-role, business-missions and suchlike, and whole-of-organisation reference-models such as the Functional Business Model, and the FEAF Business Reference Model (BRM) and Performance Reference Model. This would be similar to the high-level components in the TOGAF 9 ‘Business Architecture’, though would not necessarily focus solely on strategic themes that would impact on IT.

What it would not contain is any tactical or operational themes: so-called ‘manual’ bsuiness-processes and the like. The tendency of TOGAF practitioners to bundle together everything ‘not-IT’ as ‘business architecture’ is a common cause of friction between IT units and the rest of the business, and also a common cause of architectural design-failures at the implementation stage.

Phase C: Communication and Common

In this layer we explore what needs to be shared with domains other than the primary domain in scope. For IT, applications and data are what are shared with other business domains – hence the two subsidiary components in TOGAF’s ‘Information Systems Architecture’. But here we need to make this more general, because the primary domain in scope may be any part of the business – HR, for example, or security, or manufacturing, or marketing. Typical deliverables here would be the domain equivalents of FEAF’s Service Reference Model (SRM) and Data Reference Model (DRM).

A service-oriented analysis of the enterprise will usually be the most appropriate tactic here: define everything as services, and summarises the structure and content for interfaces, service-contracts and SLAs, qualititative criteria, success-factors (CSFs) and performance-indicators (KPIs). This is also where trade-offs between different implementations should be assessed.

Phase D: Domain Detail

In this layer we explore the fine detail that’s specific to the ‘primary domain in scope’, and which should in general not be of any active concern for other domains (‘black-box encapsulation’, in service-oriented terms). For IT, this is the detail about network infrastructures, configuration-management, life-cycle management and so on – the TOGAF Technology Infrastructure Architecture’. Typical deliverables here would be the domain-equivalent of FEAF’s Technical Reference Model (TRM), and else capability-architecture models that cover IT-based, human-based and machine-based capabilities.

This layer in particular is where the often-idealised top-down strategy needs to connect with the bottom-up constraints of real-world operations. Architecture governance becomes extremely important here, with cross-linkages to ITIL, CoBIT, Six Sigma and other detail-level process-management and quality-management disciplines, as appropriate to the respective domain.

Anyway, try this in your TOGAF practice: see what you think, see how it works in practice. It’s not as versatile as the full amended-ADM, but it’s a useful ‘halfway-house’ that’s easier for existing TOGAF practitioners – and because it is truly generic, rather than IT-centric, and consistent across all domains, it should also help to bridge the chasms of the dreaded ‘IT-business divide’.

What is NOT enterprise-architecture?

Tom G — Sat, 04 Apr 2009 06:39:02 +0000

In another interesting thread on LinkedIn, Roderick Lim Banda suggested that one way to resolve some of the arguments about what enterprise architecture is would be to ask what it isn’t. The discussion has gone round the houses a bit, as one might expect, but I thought my most recent addition to that thread would be worth repeating here:

One possible way to sort out this tangle is to deconstruct a single-sentence description:

“Enterprise architecture is a business-capability that manages a body of knowledge about enterprise structure and purpose.”

It manages a body of knowledge: it’s a decision-support system, not a decision system. Decisions are the role of strategy, and in a smaller organisation the EA may do that too, but it’s not actually the core of the role.

If it doesn’t manage an explicit body of knowledge used in organisation-wide decision-support, it’s probably not enterprise architecture

The core business role is to advise: “if you change the strategy, these are the implications on structure, this is the structure we will need; if you change the structure, these are the implications on strategy, these are the kinds of strategy this structure can support”, etc etc.

If it doesn’t provide executive-level advice, it’s probably not enterprise architecture

It’s about the overall enterprise – the ecosystem in which the organisation operates, not just the organisation itself (which is the preserve of business-architecture). A scope any less than the whole enterprise (business-architecture, applications architecture, technology architecture), it’s domain-architecture.

If it doesn’t have a whole-of-enterprise scope, it’s probably not enterprise architecture

It’s a body of knowledge about structure and purpose, and especially the intersections between them. If it’s only about structure, it’s primarily an operational issue, or a straightforward structural issue such as software-architecture; if it’s only about purpose, it’s strategy, without any actual attachment to the enterprise or organisation reality. In a small organisation an EA may well also cover some aspects of strategy (e.g. IT-strategy) and will often cover aspects of operational structure (especially e.g. IT-structures), but the real role is about purpose and structure.

If it doesn’t deal with the intersection of structure and purpose, it’s probably not enterprise architecture

Hope this helps, anyway.

TOGAF Munich

Tom G — Wed, 22 Oct 2008 11:22:50 +0000

As mentioned in a previous post, I decided at the last moment to go to the TOGAF Munich enterprise-architecture conference. Kind of a wild one-day dash – up at 3:30am; 100kms there and back to Stansted; two hours each way on Ryanair to Salzburg; 300kms there and back Salzburg-Munich; back in Colchester at just before 1:00am – and not exactly cheap (a whopping £170+tax conference-fee for what was in effect just one afternoon), but I hope will be worth it in the long run. If nothing else, it was very good news to see a big shift in perspective about the nature and role of enterprise architecture, such as in these almost throwaway remarks by Len Fehskens, the Open Group’s ‘VP, Skills and Capabilities’:

The conventional wisdom is rapidly becoming that Enterprise Architecture is more than Enterprise IT Architecture.

There’s a lot more to an enterprise than its IT; IT budgets represent about 2% of revenues.

An increasing number of enterprise architects believe that the rest of the enterprise, often generically referred to as “the business”, should be architected as well.

To address the architectures of things outside the domain of IT, we need a concept of architecture that is not technological, and that is expressed in nontechnical language.

(Full link to Len’s talk Re-Thinking Architecture is here, but may require login.)

Considering how much so many people in ‘the trade’ (though not Len himself, I’ll hasten to add) have put me down, mocked me and a whole lot worse, for saying such things over the past few years, I’ll admit it is perhaps a little galling to see this now described as “the conventional wisdom”… But hey, the message is getting through. At last. At last.

So can now we actually get down to doing this, as a profession? Can we at last get the tool-vendors to give us some tools that will actually work for this purpose? And perhaps can those of us who’ve been stuck out there on ‘the bleeding edge’ for so damn long now get some help and support in doing so? – and perhaps, just perhaps, even some respect for the work we’ve had to do to get this profession to break out of its utterly inane IT-centric rut? :bleakwrygrin:

A slightly wary sigh of relief: hey ho. But yeah, good news. Worth the trip for that alone.