This from an interview with MIT-CISR‘s Jeanne Ross in the current (29 April 2012) online edition of CIO.com:

Myth: CIOs should own enterprise architecture. Not so fast. CIOs often wind up accountable for the entire enterprise architecture, despite not typically having the authority or vantage point needed to create one that provides what the organization needs. This leads to a disconnect. “When the CIO owns enterprise architecture, it’s a bad fit,” says Ross. “IT is being asked to do something the organization isn’t committed to.”

In reality, companies need to acknowledge that “architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO,” says Ross. “If the CEO doesn’t accept that role, there really can be no architecture.”

Yep, that’s exactly what we’ve been saying for, oh, well over half a decade now – with the full explanation of why we’ve been saying it, too. But now that the same is being said by such an EA-luminary as Jeanne Ross, perhaps there’s some chance that it might actually be heard at last?

Here’s hoping, anyway…

Yet is all as it seems? I’d have to admit that the conference-programme does worry me a bit. Despite the presence of a fair few people with a broader view than just IT – Alex Osterwalder, Len Fehskens and Stuart Boardman, to name just a few – so much of it still seems to be the same-old search for the ‘next big thing’, the next soon-to-fail IT-based magic-bullet: currently ‘Big Data’, mobility, cloud, cloud and more cloud. Oh well.

A bit of history might be relevant here. Back at the start of the 20th century, the electric motor was the great ‘next big thing’. Huge excitement! – huge hype! – the electric motor will solve everything! No doubt that it transformed industry: freed at last from that terrifying tangle of belts and pulleys, machines now placed wherever fits the workflow, smaller, more compact, more convenient. A whole new infrastructure to power it, control it, monitor it, measure it, manage it.

(Sounds familiar, perhaps?)

And finally, when electric motors were literally everywhere, embedded in almost everything, the realisation that although the electric-motor is an important enabler, it’s only an enabler: isn’t the enterprise itself.

The enterprise isn’t solely about machines, or information, or ‘making money’: it usually includes all of those things somewhere within the overall picture, but first and foremost it’s about the hopes and desires and aims of people. If we ever forget that fact, there’s no space for enterprise – and hence nothing against which enterprise-architecture, or enterprise-transformation, could ever make sense.

As Simon Sinek puts it, any enterprise-scope work must always start with ‘why’: the ‘how’ and ‘with-what’ come later in the story. And for enterprise-architecture that ‘why’ must always be about the whole of the scope – not solely about some arbitrarily-selected subset. Open Group’s TOGAF is excellent for enterprise IT-architecture; yet its rigid focus on IT (as defined in sections B, C and D of its Architecture Development Method) renders it problematic at best for anything else in the enterprise-architecture space. It’s fixable, as I’ve explained at various Open Group conferences and elsewhere over the past five years or so: yet still that kind of update has not been applied to the ADM, and in that sense TOGAF 9 represented a sadly-missed opportunity. As a profession, we need to do better than that.

To give some idea of what I mean by ‘the enterprise’ – and hence its architecture and its transformation – take a look at some of the projects I’m exploring at present in Latin America:

• a medium-sized brewer needing to resolve problems with internal theft
• a large manufacturer addressing multi-way ‘cultural translation’ between Asian ownership and executive, US management and methods, and Latin engineers and workforce
• a government department working with a film-producer to use social-media to break the cycle of mutual distrust between police and schoolkids and teenagers in the slum-districts
• an NGO wanting to use the ubiquity of cell-phones as a means to improve health-care in widely-dispersed indigenous communities

It’s likely that in each of these contexts, an enterprise IT-architecture will play some important part: but the IT itself is not the sole focus of the overall task. To make any of those transformations work, we need to start from people, not IT – start from enterprise as enterprise – and keep that whole enterprise in mind at every moment.

It may well be that enterprise-architecture is dead – but if so, it was killed by inanely inappropriate IT-centrism, in Open Group and elsewhere. As we move to a nominally broader-based enterprise-transformation, could more effort be made to ensure that we do not repeat the same IT-centric mistakes? Please?

Why Archimate?

Archimate aims to be the standard notation for all enterprise-architecture work, bridging an important gap between free-form whiteboard-style sketches and detail-layer executable models.

The catch is that it all depends on what’s meant by the term ‘enterprise-architecture’… which is not a trivial point, as Len Fehskens explained on the Open Group blog early last year, in his seminal post ‘Enterprise Architecture’s Quest for its Identity‘.

The short answer is that version 1.0 of Archimate was a very good fit for what Fehskens describes as ‘EITA’ – enterprise IT-architecture. It was not a good fit for whole-enterprise architecture – a literal ‘architecture of the enterprise’ – because in essence everything in Archimate 1.0 centred around IT, and it had no real means to describe anything that did not in some way directly impact upon IT.

For a logistics context, for example, we could model how information about a package would move through the system, but not the physical package itself: so there was no real way describe any of the scenarios by which the parcel and the record of that parcel might become misaligned – or, perhaps more importantly, become realigned. (In the real world, that kind of misalignment still happens way too often for anyone to be comfortable or complacent about it – as can be seen in so many Twitter-complaints with the ‘#fail’ hashtag. It’s a very real business-problem – and usually a problem that is rooted somewhere deep within the architecture of the enterprise. Which is why it is our problem.)

There were also several key items that were missing from the Archimate metamodel that were going to be needed by anyone aiming to bridge the infamous business/IT-divide – particularly about motivation. (There’d been some coverage of that in the earlier versions of Archimate, but were dropped in the 1.0 release, perhaps to improve its alignment with the TOGAF 9 metamodel.)

The underlying anatomy of Archimate is also somewhat problematic. As I explained somewhen mid last year in a long post, ‘Unravelling the anatomy of Archimate‘, to me there are what seem to be several fundamental flaws in the structure of its metametamodel that actively constrain its use to an IT-oriented view of enterprise-architecture. And there seems to be no easy way to resolve those flaws without going a long way down into the internals and starting again. The surface-layer can look much the same – and certainly remain backwards-compatible – but the internals would need to be very different to make Archimate usable for the kind of business-oriented enterprise-architecture that so many more EAs are moving towards now.

So when I first found out about the revision for this new version, my attitude was ‘high hopes but not high expectations’. And that’s pretty much what’s happened – except that there’ve been some been very useful additions, some of them in places that I didn’t expect.

So for those of us working in whole-enterprise architectures, there’s good-news, and there’s bad-news. And there’s quite a lot of good-news, and nothing in the bad-news that we wouldn’t have expected, so let’s get the latter out of the way first.

Bad-news: there’s no fundamental move away from IT-centrism

The bad-news it that we’re still stuck with the same inane IT-centrism as before – right from the very first sentence of the specification:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization. … Architecture descriptions are formal descriptions of an information system, organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.

There’s a lot more to any enterprise than just its IT-based information-systems, but in essence that’s all that this new version of Archimate would allow us to handle. And that annoyingly-arbitrary constraint is carried through into the same old pseudo-layering of Business, Application and [IT] Technology, in which ‘Business Layer’ is a similarly arbitrary and annoyingly-incomplete placeholder for ‘anything not-IT that might affect IT’. Not only absurd, but now seriously out-of-date for current EA practice – as even Open Group would freely admit, given the nominal focus of many of the presentations at the San Francisco conference and elsewhere

Sigh.

And they’ve used the same ‘plug-in’ concept for all the new add-ons as in the TOGAF 9 metamodel – which is a nice idea, but there’s nothing to support it in the existing Archimate metametamodel. So the result is that the underlying architecture has become yet more fragmented – which is going to make it even harder to do the fundamental rework of the architecture that must be done it’s to be usable forward into the future.

Oh well.

But that’s about the sum-total of the bad-news, and none of it was unexpected, so let’s move on to what is good in the new release.

Good-news: the Motivation extension

This wasn’t unexpected, but it’s still very good news: we can now link any architectural-entity explicitly to the reasons why it exists, and in a manner that allows for formal rigour between all of those interrelationships, roughly in line with the Business Motivation Model (BMM). The new entities are a subset of the BMM, but still eminently usable:

• Stakeholder
• Driver
• Assessment
• Goal
• Requirement
• Constraint
• Principle

In the Business layer we can link these to the existing entities for Value and Meaning, to create a (mostly)-complete trail of derivation for business-purpose. No equivalents in the other two layers, but it probably doesn’t matter as long as entities there are linked up into the Business layer, either direct or via the new Motivation entities.

The only thing that’s bizarre about this is the whole idea of treating motivation as an ‘extension’, rather than core. To use Simon Sinek’s term, surely we should always ’start with why‘?

Good-news: the Implementation & Migration extension

This one’s likewise very good news, and I wasn’t expecting it at all. This gives us a means to model the dynamics of an architecture – the way in which the architecture itself undergoes change. Again the new entities here are only a subset of what we really need for this, but they’re certainly enough with which to get started:

• Work-Package
• Deliverable
• Plateau (for example, an ‘intermediate state’ at some predefined time-horizon)
• Gap

It does make sense to describe this as an ‘extension’, because we don’t need it to describe a particular configuration or ‘state’ of an architecture – though we do need it whenever the architecture is to change.

The really good-news about this is that it provides a nice graphic workaround for the fact that almost none of the existing toolsets handle architecture-dynamics in any useful way. And if the toolset-vendor implements the appropriate ‘hooks’, this would also provide a solid anchor-point for cross-links into project-management tools and the like. Nice.

Good-news: the Location entity, and other minor amendments

A Location entity had been included in the earliest iterations of Archimate, but for some unfathomable reason it was dropped long before the Version 1.0 release; it now makes a very welcome and very necessary return.

A glance at Zachman should give the reason why it’s so important: without it, we have no means to describe the ‘where‘ of the architecture, whether in virtual, physical or any other form.

The Location entity is arbitrarily placed in the Business layer – which makes no sense, of course, because location should apply to everything, but it’s probably the only way that it can be handled within that absurd IT-oriented ‘layering’. Despite that placement, it is allowed to connect with every other entity, mostly via ‘assignment’ or ‘association’ relationships.

The other oddity is that there’s no explicit distinctions between types of location – particularly virtual versus physical, which is extremely important even in IT-architecture. No doubt this can be handled within toolsets via attributes, but it is a distinction that needs to be addressed.

There are a few other clean-ups down in the Technology layer, mostly new types of IT-specific relationships for newer technologies. To me the most significant item is Infrastructure Function – significant mainly because its stated purpose is to reinstate some much-needed structural symmetry in the underlying metametamodel for Archimate.

What next?

The specification ends with a ‘Future Directions’ chapter, which summarises some ideas about what could be added in future. Which is all fine: except they still don’t include anything that would make it more usable for the non-IT aspects of enterprise-architecture.

At the very least, if Archimate is to be usable for what it purports to do, we need it to be able to cover the symmetric equivalents of Application and Technology in the non-IT space – and not try to dump it all into ‘Business’, where most of it does not belong. The core partitionings that we need in an architecture are:

• role-type – passive-structure, behaviour and active-structure
• asset-type – physical-object, virtual-information, human-relation
• agent-type – physical-machine, IT-system and/or human-process

Role-type is the nominal core of current Archimate. But asset-types are in effect conflated into and scrambled within Technology, Application and Business layers respectively; and the only agent-type fully acknowledged is IT-system, with the others either ignored (physical-machine) and/or arbitrarily shunted into the Business ‘layer’ (human-process). This makes it all but impossible, for example, to use Archimate to describe business-process redesign or process-fallback where the existing or alternate implementation-methods would use machines or manual-processes; it makes it impossible to describe a business-continuity plan for a context where the IT is out of action; it still leaves it impossible to describe that logistics paralleling-problem between physical parcel versus information about the parcel. This are real needs in any viable enterprise-architecture, and we need a notation that can cover them. Hence, if Archimate is to be the notation of choice for EA, it needs to address these concerns: there is simply no other option.

From assorted snippets of conversation with various colleagues I know that such concerns are being explored in the discussions for the next version of TOGAF, currently code-named ‘TOGAF Next’. So if Archimate is to keep aligned with TOGAF, any putative ‘Archimate Next’ would have to follow suit. So I do still have high hopes for something useful and usable happening there; is it too unreasonable this time to have high expectations as well?

• rtolido: @tetradian just show me the non-IT people that invented #entarch and / or #bizarch
• tetradian: @rtolido we’re in a circular-definition here: what you call #entarch or #bizarch is whatever was ‘invented’ by IT-people… //  crucial problem is that IT-people labelled as ‘enterprise architecture’ to something that wasn’t ‘architecture of the enterprise’ // likewise with IT version of ‘business-architecture’, which _isn’t_ ‘architecture of the business’ // once we sort out that mess, it becomes obvious IT-people did not invent it – but until then, we have those circular-definitions… // non-IT-people: Deming, Boyd, Beer, Alexander, even Taylor, for heavens’ sake…
• rtolido: @tetradian All true! Just pointing to the actual roots of both #entarch and #bizarch . Not saying it’s a good thing per se.
• tetradian: what you’re doing at present is propping up _fundamental_ mistake: mislabelling of ‘IT-view of business’ as ‘business-architecture’ // ‘Open Group Cert in IT-view of Business’ is fine – just don’t call it ‘business-architecture’, because it isn’t! // Data Architecture 101: don’t assign names to things that don’t mean the same as what those things actually are!

And that last point is actually a good idea: apply a bit of bog-standard data-architecture practice to this problem. Let’s look at this whole mess from the perspective of Data Architecture 101:

– Step 1: A core principle: all entities shall be assigned meaningful names or terms – i.e. that the assigned name shall correspond to the ‘natural meaning’ of the entity.

– Step 2a: If a term that is currently assigned to an entity does not match the ‘natural meaning’ of the entity but is not in common use, the updated name for the term shall be promulgated, and action taken to dissuade use of the former misleading-term.

– Step 2b: If a term in common use is currently assigned to an entity but does not match the ‘natural meaning’ of that entity, an architectural ‘waiver‘ or ‘dispensation‘ shall be issued, acknowledging the current usage of that term.

– Step 3: If a waiver is issued, the waiver does not mean that the misleading usage is acceptable, but rather that although the fait-accompli is accepted in the present, all efforts must be made to prevent the misleading-term from becoming further entrenched, and every opportunity taken to promulgate a replacement ‘natural-meaning’ term.

This is basic stuff, the kind of routine data-architecture work I was doing twenty years ago and more. Software-coders do it every day; web-designers do it; database-administrators do it. But not, apparently, the people who purport to maintain the formal standards for this kind of work. To use a certain famous phrase, “this does not compute…”

Let’s look at this in a bit more detail.

First, that principle from Step 1, the notion of a ‘natural meaning’. A term or entity can of course be assigned any name at all: sometimes projects and the like are intentionally assigned misleading names, for security purposes or because they’re being used only as ‘working title’ or suchlike. Sometimes such names do stick, misleading or not: ‘tank’ is a classic example. But in general – especially in a data-architecture or in any part of an enterprise-architecture – an entity should be assigned a name that aligns with its use and function: for architectural purposes it doesn’t help anyone if we decide to use the label ‘Glue Pot’ for a delivery-truck, for example, or ‘Salmonella Breeding Station’ as the label for the cafeteria business-unit. In general, it’s a lot more helpful if we call a spade a spade, and so on.

[We can take this a bit further, perhaps - hence the old adage that "An Englishman calls a spade a spade, but an Australian calls it a bl**dy shovel"... ]

Hence the notion of ‘natural meaning’, that in order to minimise the potential for confusion, things should be named according to what they are or what they do.

And a simple test for ‘natural meaning’ is inversion of the term: if the inversion gives the same meaning as the assigned term, it’s more probable that, overall, the term won’t cause confusion. (There’s a proper grammatical-term for this inversion, but I’ve forgotten it: someone remind me, perhaps?) Take ‘data architecture’, for example: the inversion is ‘the architecture of data’, which in both cases is what actually happens in the practice of data-architecture – so we can be reasonably comfortable that we have something close to ‘natural-meaning’ there. In practice, ‘data-architecture’ is a term we can trust to make sense.

Likewise ‘security-architecture’, as the architecture of security; or ‘brand-architecture’, as the architecture of the relationships and the like between business brands;  or ‘IT-infrastructure architecture’, as the architecture of the infrastructures of IT-systems. These all make clear sense, whichever way round we put it; and keep the same meaning, whichever round we put it.

But when we try this inversion with the supposedly-’official’ usages of ‘enterprise-architecture’ or ‘business-architecture’, it just doesn’t work:

– enterprise-architecture:

• natural-meaning (from inversion): the architecture of the enterprise (i.e. organisation as a whole, plus extensions into the value-network and overall ecosystem within which it operates)
• common-usage in TOGAF, FEAF etc: the architecture of the IT-systems in use within the organisation, with some reference to the usage of those systems within the organisation’s business

– business-architecture:

• natural-meaning (from inversion): the architecture of the business (or, more specifically, ‘the business of the business’)
• common-usage in TOGAF, FEAF etc: anything not-IT that might impact upon IT, organised and described solely in terms of its actual or potential impact on IT

In both cases the IT-oriented common-usage is a very long way from the natural-meaning of the term – which guarantees confusion as soon as we move outside of the narrow confines of an IT-oriented view. And in both cases that common-usage meaning describes only a very small subset of the scope of the natural-meaning – in other words, wherever the IT-oriented common-usage is dominant, it represents a serious term-hijack that blocks visibility of the remainder of the natural-meaning scope.

Which, in any competent data-architecture, would clearly indicate that have a couple of seriously-invalid term-usages here. Which means we need to do something about it. Which brings us to Step 2.

It’s clear that Step 2a can’t apply here, because both of these invalid terms are very much ‘out there’.

Which means that we move to Step 2b: we issue a waiver.

But we do not forget what a waiver actually means here, and what responsibilities it places on all of us, collectively, in terms of action we must take in future to correct the architectural risk. In particular, it does not mean that we simply throw up our hands in the air and say “oh well, it doesn’t matter” – because clearly it does matter, because equally-clearly that usage of the term will not make sense to anyone outside of the ‘in-group’ cabal. Instead, the waiver says that we must take action to correct the fault – exactly as with any other type of architectural fault.

Which brings us to Step 3. What we actually need in this case is the metaphoric equivalent of a full ‘Cease & Desist’ order, to demand that people not only stop all use of this misleading usage of the terms, but take action to correct all materials in which either of those two misleading usages occur. For example, TOGAF would need to be rewritten from scratch: given the natural-meaning, it wouldn’t be allowed to use the term ‘enterprise-architecture’ just about anywhere in the whole document, and ‘Phase B: Business Architecture’ would either cease to exist, or be reconstructed as a proper multi-domain structure, within which ‘the architecture of the business of the business’ is merely one amongst many other domains that can impact upon IT.

Let’s not beat about the bush here: that is what needs to happen. Anything less represents not only only an architectural risk on a major scale, but an ongoing risk whose impacts increase exponentially with every passing day.

Sadly, Reality Department indicates we’re very unlikely to get this – not least because it would require Open Group, CapGemini, Federal Enterprise Architecture, Gartner, Zachman and all the rest to recall every scrap of their past publications on ‘enterprise’-architecture, and rewrite the whole darn lot. But we need to say, and continue to insist, that this is what needs to happen in future. We do not simply allow them to continue promulgating these (and many other) fundamentally-wrong term-usages in the enterprise-architecture space.

That’s Data Architecture 101, as applied in a perfectly straightforward way to current ‘enterprise’-architecture – what the Americans call ‘eating our own dogfood’.

And if we aren’t willing to do it to our own work, why on earth should anyone else trust us to do it to theirs?

Pretty simple, really.

So, whatcha gonna do about it, folks?

—

One separate but related and very important addendum: I am not knocking TOGAF in itself here, nor anything or anyone else in the IT-architecture space. IT-architecture is extremely important, and Open Group and others have been doing sterling work in that space for many years. To my mind, no-one should doubt this, and I’m very happy to sing their praises on that part of the work, and invite and encourage others to do likewise.

All that I’m saying is that what TOGAF etc call ‘enterprise-architecture’ should not be called ‘enterprise-architecture’, for the simple reason that it is not ‘the architecture of the enterprise’.

Likewise the somewhat jumbled collection of bits-and-pieces that TOGAF and its ilk call ‘business-architecture’ should not be called ‘business-architecture’, for the simple reason that it is not ‘the architecture of the business’.

[The latter point should be obvious when we consider that TOGAF's 'business-architecture' assumes that the entirety of the non- IT executive - in other words, the CEO, CFO, COO, CMO, CHO and any non-IT CTO, and all of their respective domains - can all meaningfully be lumped together as 'the business', with only IT needing aany differentiation from the rest. Anyone who's had any dealings at executive-level will know that it's, uh, not quite as simple as that? :wry-grin: ]

Best leave it there for now, I guess. Over to you?

Competence is where someone knows what they’re doing, and does it. And, oddly, often don’t bother to say that they’re competent – perhaps because they don’t need to say it, their actions say it well enough instead. The outcome of competence is fairly certain, even in contexts of high uncertainty.

Non-competence is where someone doesn’t know what they’re doing, and will either not do it, or will do the best they can, yet with the explicit intent to use it as a learning to improve their competence. Importantly, they will usually say that they don’t know what they’re doing. The outcome of non-competence is uncertain, even in nominally-certain contexts, but at least we are aware of the risks.

Incompetence is where someone doesn’t know what they’re doing- i.e. is non-competent to do the task – but either purports and/or believes themselves to be competent. They will usually say that they are competent, even though demonstrably they are not; they claim to be responsible, yet have limited ‘response-ability’. The outcome of incompetence is fairly certain, and frequently dire, yet lack of awareness of the risks is often rampant, or in some cases the risks actively concealed.

Someone who is non-competent can become competent by learning the respective skills, or be competent by proxy, via finding someone else who is competent at doing the respective type of task. I treasure my non-competence, because it means there’s always more for me to learn. And as an enterprise-architect, I am, almost by definition, non-competent in much if not most of the detail-aspects of areas that I need to cover: hence one of my key competencies is the ability to learn enough of a new area fast enough to be able to guide meaningful exchanges between people who are fully competent in some detail-area but are not competent in others with which they need to connect.

Yet one of the key criteria for non-competence, and to separate it from incompetence, is a willingness to accept that we are non-competent, and say so. If we’re not aware that we’re non-competent, we automatically increase the risk of being incompetent. And if we know that we’re not competent, yet somehow ‘need’ to claim that we are competent, we would, again, automatically be incompetent – with a very high risk of inappropriate or ineffective outcomes of the work.

In part it’s a cultural problem: the risk of incompetence increases wherever a culture exhibits any of these characteristics:

• prioritises content over context, ‘truth’ over context-dependent usefulness
• has an insistent ideological base (leading to the same as above)
• is typified by rampant egotism, self-advertising and self-centrism
• is frequently swayed by tides of hype and ‘following after the latest fad’
• displays an almost desperate need to be ‘right’

Unfortunately, all of these attributes are extremely common in business, and in many cases are actively prized… By definition, they’re also more likely to be common in any ‘truth’-oriented domain, one which operates primarily on ‘true/false’ decision-making – hence, in practice, the tendencies towards IT-centrism and finance-oriented business-centrism, both of which rely on simple true/false logic for most of their operational decisions.

In SCAN terms, all of these are where the Simple certainties of Belief – either as ideology and/or as self-belief – are inappropriately applied to the far side of the Inverse-Einstein Test, where the uncertainties of the Ambiguous and the Not-Known cannot be avoided.

This gives us a dysfunctional ‘diagonal’ decision-path, where Assertion is imposed on the Not-known, or Ambiguity ‘solved’ by arbitrary Belief:

Yet the real problem here is somewhat more subtle:

• someone who is competent will typically not bother to say so, but will just get on with the work instead
• someone who is non-competent will typically say that are not competent, but will often actually be adequately-competent, or at least willing to learn to become so
• someone who is incompetent will typically claim that they are competent, and will usually not be willing to learn how to become so, because to do so would betray to themselves and others the fact that they are actually not competent

Which, in practice, leaves us with a huge dilemma:

• those who do not claim to be competent usually are competent
• those who do claim to be competent frequently are not competent

Hence, again, the kind of mess that we see so often in enterprise-architectures, wherever IT-centrism, business-centrism and the like predominate… Oh well.

Comments, anyone?

• rtolido: interesting stuff coming soon around a global Business Architect certification standard by The Open Group #ogsfo

Important to say here that I have enormous respect for Ron: quite apart from his senior role at CapGemini, he’s also an amazing innovator in IT-architecture and enterprise-architecture, with ideas such as Slow IT, the importance of a demolition strategy, and the SCOOTER metaphor. Yet I must admit I was absolutely horrified at that comment above, and said so:

• tetradian: @rtolido IT-centrism in TOGAF etc has crippled #entarch for half a decade: please don’t let OG do the same to #bizarch as well…

The point is that, given their track-record so far on business-architecture,  I can hardly think of any organisation that’s less qualified than Open Group to create such a standard. For Pete’s sake, even the Piddletrenthide Parish Parent-Teacher Panel would probably do a better job of it…

And no, I’m not being nasty here – I’m serious about this. The utter shambles that is TOGAF’s ‘Phase B: Business Architecture’ should sound clangorous alarm-bells about any such suggestion: it’s just a random collection of ‘anything not-IT that might affect IT’, with no structure, no symmetry and no sense. If you want to see how so much of so-called ‘enterprise’-architecture actively increases the infamous ‘business/IT-divide’, you need only to take a careful look at the TOGAF specification for its ADM Phase B. And these people seriously consider themselves competent to define a global certification for business-architecture? No way! – please…?

Anyway, my Tweet-response above triggered a reply from Ron:

• rtolido: @tetradian it’s an IT thing to criticize IT-centrism but after all: #entarch is an IT people invention. Let’s try to do better with #bizarch

To which my first response was ‘What the…?‘, which came out in more polite form on Twitter as this:

• tetradian: @rtolido “it’s an IT thing… entarch is IT-invention” – disagree on both counts, but yes, please let’s do better with bizarch…

Let’s tackle Ron’s points in reverse order…

At least there’s an acknowledgement that we could do better with business-architecture than has been done with those current attempts at ‘enterprise’-architecture. That’s something. Good.

On “#entarch is an IT-people invention”, it isn’t. That’s a convenient myth that IT-people want to believe – though no doubt a fair few of them will want to throw various historical quotes at me to ‘prove’ their provenance. Sure, the term ‘architecture’ has long since been linked to IT – almost half a century, by now. And somewhen around a couple of decades back, some bright spark extended that idea to distinguish between a context-specific IT-architecture versus an IT-architecture at organisation-wide or enterprise-wide scope, as ‘enterprise-wide IT-architecture’ – at which point some idiot conflated that nominally-valid term to a no-doubt ‘simpler’ shorthand term as ‘enterprise-architecture’, without any awareness of just how misleading that would be, or how much damage that term-hijack would cause. Yet reality is that there are many long-established business disciplines such as systems-thinking and design-thinking as applied to the enterprise that have a much better natural fit with the term ‘enterprise-architecture’; the original meaning of ‘business-analysis’ was also probably very close, too. In short, ‘enterprise IT-architecture’ is arguably “an IT-people invention”; but enterprise-architecture most definitely is not.

On “it’s a IT thing to criticise IT-centrism”, I’m not quite sure what Ron means there – whether only ‘IT-people’ have the right to do so, or else that anyone criticising IT-centrism is inherently self-identifying as an ‘IT-person’. If it’s the former, then the fact that I’ve had perhaps 30 years experience in and around IT might qualify me to criticise? But more to the point, my background is as an explicit cross-discipline generalist – I’m one of the few people formally qualified as such, with an MA in General Studies from London’s Royal College of Art. And it’s in that sense, as a long-experienced practitioner of ‘design-thinking’ within a very wide variety of business contexts, that I see IT-centrism as such a problem. (And, for that matter, business-centrism – which I’ll come back to in a moment.) In terms focus of attention, the single most important fact in enterprise-architecture, or business-architecture, or any other architecture, is this:

Within any architecture, everywhere and nowhere is ‘the centre’, all at the same time.

What happens in any form of ‘-centrism’ is that we keep on being dragged back to some specific area that claims to be ‘The Centre’ of the architecture. Rather than an ‘outside-in’ view – an awareness of the whole – we’re constrained to an ‘inside-out’ view, where everything in the architecture is seen only in relation to and in terms of that single ‘The Centre’. If there is no direct connection to that ‘The Centre’, or no direct impact, whatever-it-is is usually dismissed as ‘out of scope’, and often deemed not even to exist. Hence, in TOGAF’s inherently ‘inside-out’ view – in which IT-infrastructure is its actual ‘The Centre’ – we have no means to describe anything that is not-IT and that does not in some way impact directly on IT.

[To illustrate the point, try using TOGAF or its linked Archimate-notation to describe the physical activity of a production-line, the trucks and conveyor belts and other machines of physical logistics, the human activity of paper-based record-keeping, or the physical infrastructure - cooling, power-supplies and suchlike - of an IT data-centre: if you can do it all, you'll have to use some horrible kludges and fudged reframings of the supposed standards in order to do it... And yet all of these things would be essential in an enterprise-architecture for the respective industry.]

I need to reiterate that it isn’t only IT-centrism that creates this kind of problem: it’s any-centrism. What I’ve also been seeing recently is a lot more ‘business-centrism’ in enterprise-architectures, where ‘the business of the business’ is taken to be ‘The Centre’ of the enterprise-architecture. We see this, for example, in the insistence that financial metrics are the only metrics that count, and that return-on-investment (ROI) and the like can only be measured in financial terms – which might be valid within certain subsets of business-architecture, but are way too constrained to be valid in the far broader scope of enterprise-architecture. In some ways this trend worries me even more than IT-centrism, because by the nature of business it will tend to have even more of the wrong kind of credibility, making that much harder to counterbalance and correct within the architecture.

Anyway, Peter Bakker dropped in a useful comment at this point, pointing to a classic early essay by Christopher Alexander, famed author of A Pattern Language:

• pbmobi: @rtolido @tetradian #entarch & #bizarch just see the trees, we need architects who see the semi-lattices http://www.chrisgagern.de/Media/A_City_is_not_a_tree.pdf #ogsfo

• taotwit: @tetradian @rtolido erm.. Tom I think you’re mixing up what EA is with what should be!
• tetradian: @taotwit @rtolido if someone’s defining a new standard, surely it should be about what should be, not about preserving current mistakes?
• taotwit: @tetradian @rtolido good point – I hope they listen to the likes of Alec Sharp and Patrick Hoverstadt

Agreed with Nigel there: a business-architecture certification scheme would need input from people like Alec or Patrick, or likewise from other key figures in business-architecture or business-innovation such as Alex Osterwalder or Steve Blank. But, like me, none of them are members of Open Group – which means that not only do we not have a voice, but what we say will be ignored anyway. In other words, Open Group expressly locks out many of the people who are doing real innovation in business-architecture, and then wonders why there are real doubts about the usefulness or validity of what it then produces as its ‘standard’.

Which brings us to the disaster-area of certification. In principle it’s a good idea, even a very necessary idea: every profession needs some way to identify and validate core knowledge and the like. But when the certification for a discipline is managed by a group that evidently do not understand what that core-knowledge actually needs to be, then we have a problem… and that’s exactly what we have with Open Group and business-architecture.

Open Group are an IT-standards body: and they’re very, very good at what they do in IT. But they’re not a general business-standards body – and that fact is becoming extremely important here. In the days when TOGAF was solely about IT-architecture – as it was up until version 7 – then it made sense for the ‘enterprise IT-architecture’ standard to be maintained by the Open Group. But the problem with any enterprise-scope architecture is that, by definition, you have to take everything in the enterprise into account: hence an expansion out into data- and applications-architectures in TOGAF 8, and then, in TOGAF 8.1 ‘Enterprise Edition’, the addition of a loosely-defined ‘anything not-IT that might affect IT’. Unfortunately they made two fundamental errors at that point: because that random bundle represented IT’s view of what it called ‘the business’, they labelled it ‘Business Architecture’; and they then described the whole IT-specific structure as ‘Enterprise Architecture’ – both of which sort-of made sense from their own inside-out perspective, but made no sense to anyone else, especially when looking outside-in. Oops…

Anyway, back to certification. So first, there is a real value in having a common language for specific types of architecture. In that sense, the TOGAF 9 ‘Foundation’ certification is genuinely useful, because it tests knowledge of that common language.

Likewise the practitioner-certifications such as ITAC, which assess someone’s practical skills and competence. Unfortunately it’s no use to me, though, as it still assumes that the only possible path to enterprise-architecture is via detail-level IT-infrastructure architecture, which I don’t do and never have. (I’ve done a lot of mainstream data-architecture in my time, but that doesn’t towards ITAC certification either.)

But to my mind – and in my experience, too – the mid-level certification, ‘TOGAF Certified’, is actually worse than useless: to be blunt, it’s almost a measure of how much someone is not competent to do enterprise-architecture. Yikes… there are some serious problems there…

That perhaps sounds a bit harsh: it’s not. There are two interlinked reasons why this is so.

The first is that ‘TOGAF Certified’ is a content-based exam. All it tests is how well people know the TOGAF specification – not architecture-practice. And to be blunt, the TOGAF specification is a long way from what’s needed to do enterprise-architecture – especially in any industry other than ‘the usual suspects’ of banking, finance, insurance, tax. (Why those industries? Because their business-models are built almost entirely around large volumes of simple structured information with automatable business-processes – in other words, strongly IT-oriented. Which doesn’t apply to most other industries.) I almost failed my TOGAF 8.1 exam because I answered several questions in terms of what I knew worked in practice, rather than what’s written in the book. And the ‘correct’ answer in the book was just plain wrong: I knew from real-world practice that it was exactly what not to do. Needless to say, I wasn’t impressed when I was penalised in the exam for doing it right…

The second reason is that TOGAF is not a standard. This isn’t some arbitrarily-unkind assertion that I’m making: it’s not only common knowledge, but I’ve even heard several senior Open Group figures say so in public. (Exact quote: “Of course no-one uses TOGAF out of the box! – we always have to customise it one way or another”.) The best way to describe TOGAF is that it’s a somewhat-better-than-random cookbook of ideas and practices vaguely held together by a almost equally-vague structure of the Architecture Development Method [ADM] – and that’s it. There’s not much guidance in TOGAF itself on how to customise TOGAF: you get that from experience, with a bit of help from some of the better training-providers.

So what we have at present in the ‘TOGAF Certified’ exam is a way-too-simplistic multiple-choice test on the supposed content of a ‘standard’ that actually isn’t a standard and often doesn’t match up at all well with real-world practice anyway. So just how much use do you think that’s going to be? To anyone? Honestly? Hmm…

And given that, how much credence would you place on a certification-scheme by the same people on a domain which they demonstrably don’t understand much if at all, judging by the current content of TOGAF’s ‘Phase B: Business Architecture’? Oops…

Hence why I’m extremely wary of letting this current attempt by Open Group go unchallenged: they really are almost the least-appropriate group to do the job.

No question at all that we do need some very good work to happen on business-architecture, and urgently so. But please, not from Open Group? – at the very least, not until they’ve tidied up the utter shambles of ‘Business Architecture’ in the current TOGAF, and can demonstrate that that they can keep their reflex IT-centrism under better control than at present?

Sigh… Oh well… back to the grindstone, I guess…

Over to you for comment or whatever, anyway.

• togaf_r: TOGAF Resource: The TOGAF 9.1 changes overview and 6 other slide decks are now at http://t.co/Arm40mgA (free PDF) #ogsfo

The link points to the Open Group’s ‘public resources’ website for TOGAF (The Open Group Architecture Framework), which includes the respective slidedecks.

One of those slidedecks is ‘TOGAF Version 9.1 Management Overview‘ [PDF] – which turns out to be an interesting illustration of exactly how IT-centrism creeps into enterprise-architecture…

We’ll start with slide 18 (lower part of p.9):

What is an Enterprise?

• A collection of organizations that share a common set of goals

– Government agency

– Part of a corporation

– Corporation

• Large corporations may comprise multiple enterprises

• May be an “extended enterprise” including partners, suppliers and customers

They don’t give the source for that definition, but it’s one I’ve seen elsewhere – I think it’s used in FEAF, for example. Importantly, this definition explicitly does not regard ‘organisation’ and ‘enterprise’ as synonyms. In my view it doesn’t go far enough in that separation, but at least it’s clear that there is a difference, and that ‘the enterprise’ often extends well beyond the boundaries of ‘the organisation’. In short, so far so good.

Next, look at slide 19 (upper part of p.10):

What is an Architecture?
• An Architecture is the fundamental organization of something, embodied in:
– its components,
– their relationships to each other and the environment,
– and the principles governing its design and evolution.

As they say on the slide, that definition is adapted from ANSI/IEEE Standard 1471-2000, another well-known and much-used reference. Again, so far so good.

But note what happens in slide 20 (lower part of p.10), which purports to bring together those previous two definitions:

What is Enterprise Architecture?
Enterprise Architecture is:
• The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. [MIT Center for Information Systems Research]
• A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. [SearchCIO.com]

Which for me brings up an instant response of  ”Huh? Now wait a minute?”… The SearchCIO definition would make reasonable sense if it wasn’t arbitrarily constrained only to the view of the organisation – not the enterprise, as per that previous definition of ‘enterprise’. And in the MIT definition it’s constrained even further, with an unexplained emphasis on IT-infrastructure and “integration and standardization” – which doesn’t make sense at all.

One slide further on, and without any explanation or justification, we’re suddenly down in classic TOGAF territory, where the foundation for everything is IT-infrastructure, and where ‘Business Architecture’ is ‘anything not-IT that might affect IT’. Oops…

And by the time we get to slide 22 (lower part of p.11), we’re presented with this:

Why Enterprise Architecture?
• Effective management and exploitation of information through IT is key to business success
• Good information management = competitive advantage
• Current IT systems do not really meet the needs of business
– Fragmented, duplicated
– Poorly understood
– Not responsive to change
• Investment in Information Technology
– Focussed on system maintenance
– Tactical developments rather than a strategic plan

All I can say to that is “You what???”… To be blunt, what has any of this got to do with enterprise-architecture, in terms of the definitions of either ‘enterprise’ or ‘architecture’ above? “Some but not much”, is the short answer. To illustrate the point, let’s deconstruct some of those assertions above:

–  ”Effective management and exploitation of information through IT is key to business success” – is it? Can you prove this? Given this arbitrary assertion about the importance of IT, can you show the connection – if any – to either ‘enterprise’ or ‘architecture’? And what do you mean by ‘IT’ anyway?

– “Good information management = competitive advantage” – possibly. But what about government and other organisations for whom ‘competitive advantage’ has little or no priority or point? And what about all the other non-IT issues – such as respect and trust – that might have far greater impacts on ‘competitive advantage’?

– “Current IT systems do not really meet the needs of business” – so what? The same is true of many other business-systems, such as the structure and design of core business models – which, architecturally speaking, would usually need to come before any fix-up of outdated IT-systems.

– “Investment in Information Technology [maintenance focus, tactical]” – again, yes, we know, but so what? The same is likely to be true about almost every other aspect of the enterprise – especially in multi-partner enterprises.

So let’s again be blunt about this: that slide above is best dismissed as mere marketing-puff – a sales pitch for large consultancies who want to sell ‘IT-rationalisation’ programmes to clean up the IT-mess that in all probability they themselves had created in the first place… In practice, there’s so much that’s missing from that ‘Why Enterprise Architecture?’ – such arbitrary and unjustifiable constraints on scope – that it really is all but meaningless. It describes only a tiny subset of the actual scope of ‘the architecture of the enterprise’, but somehow seems to purport that this is the whole. Which would be laughable if it wasn’t such a bad joke – or such a destructive one.

In other words, somewhere between slide 19 and slide 22, we’ve gone from enterprise and business, to a largely-spurious attempt at business-justification for one specific subset of enterprise IT-architecture. The remainder of ‘the architecture of the enterprise’ – especially about anything not-IT – has been erased from the story.

Which is why the TOGAF-style EA story just does not make sense to anyone who’s not already embedded and wedded to an IT-centric view of the world.

If you want to see how and why enterprise-architecture is still such a darned hard ‘sell’ to just about anyone in business, all you need to do is read that ‘Management Overview’. And quietly weep…

Surely by now we can do better than this? Please?

• davidsprott: RT @gkathan: John Seddon – a master class in how NOT to use IT in services. Optimize value, not cost. Brilliant. http://tinyurl.com/dygdcpg

It’s a 40-minute video (split into three parts) of a keynote by John Seddon at an IT-conference somewhen last year. And it’s magic – absolutely brilliant.

If you’re into enterprise-architecture, business-architecture, organisational-architecture, service-design, or any related field such as service-management of any kind, you need to watch this video – there’s no other way to say it.

Some of the insights I picked up on my first pass through include:

• “standard times are for dummies”
• “manage for value, not cost; if you manage to costs, your costs go up”
• “it’s failure-demand, not value-demand”
• “specialise – it increases the costs”
• “people who study systems focus on demand”
• “[you get better results because] you’re trained to identify the things you’re not capable of doing”
• “we get rid of all the activity-measures, because they’re of no value whatsoever”
• “whenever we create a back-office, we see an increase in activity: it should be a signal… but what do they do, no, they specialise the activity, they outsource it, they lean on people to do more faster, and that just creates more work.”
• [vid3, 05:00-07:30 "it's just wrong"]
• [on 'Lean'] “never give it a name: if you give it a name, the managers will expect if to come in a box”
• “the problems you’ve really got are not the problems you think you have, when you study”
• “[Taiichi] Ohno’s favourite word was ‘understanding’”
• “[managers think] if you’re a service organisation, and you standardise the work, the costs will go down – wrong!”
• “when you standardise and specialise in service design, you stop your system absorbing variety, and your costs go up: economy comes from flow, not scale”
• [important summary in vid3: 13:00 - 14:30]

I’m going back to watch it again… very strong recommend.

Again, I’ll keep the emphasis on the ‘how-to’, and hold back on the theory this time. (Have a wander elsewhere through this blog for the theory-bit! )

A quick reminder about the context of the previous post. A colleague of mine, Alan, has found himself in a new job, company and industry. What’ he’s used to doing is IT-oriented ‘enterprise’-architecture for utilities-management. His new company is in retail and e-retail – a lot of IT, sure, but a fundamentally different type of business, for which a conventional IT-centric version of EA may well be more of a hindrance than a help.

So the recommendation in the previous post was to start off with a focus, in parallel, on five distinct themes:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The post gave a quick summary on each of those themes – enough to get started, I’d hope, though obviously each could be a book (or several) just in itself.

What followed in the Twitterstream was interesting. Some of it was from Alan, some from others – I’ll paraphrase a bit to protect people’s identities and get it into a more usable sequence:

• I know I can’t get same performance as last job right now, but feeling frustrated with this low performance at start.  // I doubt they have same background, it’s new for everyone on strategy/leadership side.
• First week there: trying to find some point to start, there is no architecture there yet. //  I need some kind of quick-start to show EA value first. // I’m trying to start with TOGAF, but is so big for a people without EA culture.
• Everything depends on environment you’re in (culture, timing, IT strength) to propose a quick move
• Is dangerous trying to say something execs want, and end up doing something wrong. Get to know background first // What is the company mission/vision here? – is a good start for any EA.
• So, need to be calm, take a deep breath, do baby-steps on each thread with execs’ participation?
• Do you know why PEAF doesn’t have Security and Governance principles examples on this “starter-set” ? // Maybe new edition of the PEAF book soon with these principles?

Let’s explore each of those in a bit more detail. (From here on I’ll use a ‘you’-format rather than ‘we’, for simplicity and to make it more direct, but it’s important to realise that this is generic, not solely advice to a single person.)

First, about frustration. Yeah, that’s very real at this point. The short answer is that it’s normal, absolutely to be expected, nothing wrong with it, yet you do have to deal with it, because the bald fact is that this is going to take time.

A good enterprise-architecture is a kind of conceptual infrastructure: and without it it, you are going to get poorer performance: no doubt about that. But like all infrastructure, it’s easy to not notice it, or to forget about all the effort that went into building it. The one time you do notice it is when it suddenly isn’t there…

It’s really easy to blame yourself here for poorer performance, to think that the poor performance is somehow your fault, your responsibility. But don’t, because without that infrastructure in place, you’re in a situation of ‘reduced response-ability’ – literally, a reduced ability to respond. The responsible action at this point is to deliver the best that you can within the constraints of that inadequate infrastructure, and set out to enhance that infrastructure. Which is exactly what you’re doing. But yes, it will take time, and effort, and everything else.

Getting lost in frustration won’t help. Saying that the infrastructure ‘should’ be there already won’t help. What will help is “be calm, take a deep breath, do baby steps”, and follow the programme. Which is exactly what no-one wants to hear, I know – but unfortunately it is the only way that works.

The need for a quick-start is very real. We need quick results, but above all we need to get the interest and, if possible, real excitement, going right from Day 1. We have to make sure that EA matters to everyone, in their context, their workspace – because without that engagement and excitement, this ain’t goin’ nowhere.

I’ll have to be blunt about this: don’t try to start off straight away with TOGAF, or any of the other ‘heavyweight’ frameworks. They do have very real value, in later stages of EA (though often only in specific sub-domains of EA). But at the start, as that comment in the Twitterstream makes clear, all they’ll do is scare people off. For this earliest stage, we need something simpler.

I usually describe EA-development in terms of six distinct steps:

• Step 0: Get started (initial setup to do EA at all)
• Step 1: What business are we in? (big-picture)
• Step 2: Clean up the mess (horizontal optimisation)
• Step 3: From strategy and execution (top-down)
• Step 4: This is the real-world calling (bottom-up)
• Step 5: Resolving the pain (spiral-out)

TOGAF and the like tend to come into their own in Step 2 and Step 3: the old TOGAF 8 was excellent for Step-2 clean-up of the IT infrastructure and application-landscape, for example, whereas TOGAF 9 is more focussed on Step-3 strategy and the like. But before that happens, we need to have done the Step-1 work of establishing the enterprise-context (which TOGAF’s so-called ‘Business Architecture’ does not do well); and before that, we need to have established, in Step-0, the reason and desire for doing EA at all (which TOGAF’s ‘Vision’ is probably supposed to do, but doesn’t). And it’s in that very first proto-step that PEAF in particular comes into its own.

Do take a look at PEAF’s structure, especially its startup phase. To me at least, PEAF doesn’t compete as such with TOGAF or the like, because it describes what you need to do before going anywhere near any of the ‘heavyweights’.

And what PEAF emphasises is that the very first step after someone in the organisation decides to do something about EA is a first-stage training, education, above all communication. In PEAF, that first-stage introductory workshop includes slidedecks for each of these topics:

• EA – Why I Don’t Need It
• EA – Frameworks
• EA – Enterprise Debt
• EA – Model vs CMDB
• EA – Traits of an Enterprise Architect

It’s structured so that senior execs need be there only for the first few items: in particular “Why you don’t need EA” and the core concept of “Enterprise Debt”. The more detailed information is relevant only to those who need to be more actively involved in everyday EA.

[Notice the unusual negative, 'Why you don't need EA': it's a deliberate 'anti-sell', showing the value of something by being open about where it does not add value - and not presenting it as 'The Answer To Everything', as happens so often elsewhere...]

Perhaps the most crucial point is that there is a step-by-step process here: and it really is important to follow those steps, because that sequence and content is the end-result of a very careful study of what doesn’t work…

The ‘executive’ part of that workshop is no more than half a day; the remainder of that entire process probably doesn’t take much longer than a week of elapsed time. In other words, it’s not a lot of work. But you cannot skip it: more to the point, if you do skip it, you can can guarantee that the enterprise-architecture will be going nowhere, slowly, with a lot of frustration. Your choice, really…

Getting to know the background is also crucial, though most of it will happen after that first ‘Step-0 stage’ proto-step. In the previous post, this is what ‘setting the stage’, ‘finding allies’ and ‘finding the story’ were all about. The summaries from the previous post should be enough to get started: for example, the ‘setting the stage’ theme must include concerns such as identifying vision, values and mission – and also being clear about the crucial difference between ‘the organisation’ and ‘the enterprise’, because they’re not the same.

Another really important point here: don’t fall into the ‘TOGAF Trap’ of describing enterprise IT-architecture (EITA) as ‘enterprise-architecture’ (EA). Everything up to this point has been, and must be, about real whole-enterprise architecture – because we must establish the overall scope before we can focus in on any specific subset such as EITA or security or business-architecture or process-architecture anything else. If we constrain the scope too early, we’re then left with no adequate means to connect to the other domain-architectures – which again would guarantee architectural failure, especially over the longer term.

[This, by the way, is another reason why we don't try to use TOGAF for EA until such time as we do want to focus specifically on the IT-related domains. It's very good for EITA, but way too constrained for real-EA: it's really important to understand the difference!]

The other theme, around principles and standards, is something that we shouldn’t worry about too much until we’ve already gone some way down the track. This is why a question such as “Do you know why PEAF doesn’t have Security and Governance principles examples on this ‘starter-set’?” kind of misses the point. In its current design, PEAF’s primary role is at that Step-0 / Step-1 stage, when we’re still only just starting out: and at that point the only thing we need to say about principles and standards is that we are indeed going to need principles and standards, and how to apply those principles and standards to real-world practice. That’s it. Hence the example-principles in PEAF are just that – they’re examples.

Any competent architect – which you would be, if you’ve been in an EA role for some while elsewhere – will know that yes, we will definitely need Security and Governance principles. But in the early stages – particularly the Step-0 ‘Gain Agreement’ stage of PEAF – all you need to do is add them to that list of examples. It doesn’t need anything more that that, for that stage.

Later on, yes, you’ll need a lot more detail. And that’s the point at which we would start to use something like TOGAF, because it does have a very good descriptions of how to specify principles and define reference-architectures and their related standards. But we don’t try to do that too early: all it’ll do is confuse people, drowning them in too-much-detail and putting them off, just at the point when we need to gain their engagement.

So, quick summary: find a way to live with the frustration, because it’s going to be there for a quite a while, whatever you do; and do settle down to do everything step-by-step, because it is the only way that works.

Hope this helps, anyway.

This one starts with a ‘rant’ (as he put it) by Anders Jensen, about the ongoing hype over (gosh!) ‘the Cloud’:

• aojensen: As phk of FreeBSD says: #cloud is no different to the IBM mainframe. // It puzzles me why so many people put #entarch and #cloud in the same tweet. The former is a mgmt function, the latter a tech concern. // In other words, #cloud is a solution pattern and delivery mechanism. #entarch is about systemic management of all of the enterprise. // Thus, #cloud architect is nothing but a fancy word for solution architect. // Okay, rant over. #entarch

• tetradian: @aojensen: “puzzles me why .. people put #entarch and #cloud in same tweet” – is valid if about enterprise strategy or strategy-to-tactics
• aojensen: @tetradian true, but then it is still a delivery mechanism realising a certain strategic/emergent intent.

• tetradian: @aojensen for viable biz-strategy, #cloud needs #entarch much more than entarch needs cloud – cloud can be biz-lethal without proper entarch
• dougnewdick: @tetradian @aojensen couldn’t agree with Tom more – whether you are talking EITA or “proper” EA

And Doug Newdick is right here, too: this isn’t just a ‘real-EA’ issue. It applies just as much to an IT-oriented or even IT-centric ‘enterprise’-architecture, because it’s about the organisation’s strategy for managing its business-critical information.

I’ve seen some people – okay, probably only the most hype-ridden and IT-obsessed, admittedly – who’ve argued that the availability of cloud-storage and cloud-based applications means there’s now no need for any enterprise-architecture. Let’s just be blunt about this: that’s dumb. Stupid – seriously stupid. Demonstrates an almost complete inability to grasp the role of enterprise-architecture – and probably of the role of cloud, for that matter. Various other irritated epithets… definitely worthy of Anders’ ‘rant’… mumble mumble grumble grrr…

Okay, back off for a moment. Cool down, Thomas. Etcetera…

For the moment, let’s just assume a ‘classic’ TOGAF-style ‘enterprise’-architecture, focussed solely on IT. (It’s perfectly adequate for this purpose, so for once I’m not going to complain about ‘IT-centrism’ etc here. ) It has four distinct domains: IT-infrastructure, Applications, Data, and ‘Business’, which in essence is a ‘none-of-the-above’ relative to the other three IT-specific domains. Let’s assume, then, that we now believe the cloud hype, and hence that we can do everything via the cloud:

• IT-infrastructure: don’t need any, it’s all ‘bring your own IT’
• Applications: don’t need any, it’s all in the cloud, accessed via browsers and apps
• Data: don’t need to define any, it’s all defined in the cloud
• ‘Business’ (process-workflows, business-models etc): we can build it all around what’s already available in the cloud

So: get rid of the IT-department, because there’s nothing for them to do any more. And get rid of all the enterprise-architects, because they’re just part of the IT-department that we don’t need any more. Simple, right? Huge savings in costs, too.

Hmm. Right. Let’s take just a few points that are missed in those glib assertions above:

• Who’s going to test the apps on all that range of different hardware and software and screen-resolutions and everything else?
• Who’s going to help people when their ‘bring your own IT’ doesn’t work?
• Who’s going to help people understand how to access those cloud-apps, to understand the security-issues, and why leaving their iPhone in a cab could be a lot more serious than just the loss of a few of today’s Tweets?
• Who’s going to choose which apps to use? Why will they choose those apps, from which providers?
• Who’s going to design the workflows that bridge between all the different apps? Who will be responsible for the end-to-end business processes that jump around between different apps and different cloud-providers?
• Who’s going to identify the business-metrics that bridge across those end-to-end business-processes? How will you gather those metrics, and ensure that they make business sense?
• Who’s going to manage the reverse-backup, where you back up your own cloud-data in local storage? Who is going to be responsible for information-security, for end-to-end business-continuity and disaster-recovery, for escrow and recovery when (not ‘if’) one of your cloud-providers goes out of business, or when (not ‘if’) one of your providers starts getting too greedy, or for deciding what to do when your cloud-provider is taken over by one of your own competitors?

That list goes on, and on, and on, and on: and you won’t be able to answer many, if any, of those questions, without a solid enterprise-architecture. You’ll probably discover that you do indeed need that IT-department, too – a lot more than you’d realised. Oops… perhaps throwing everything into the cloud isn’t such a good idea after all…

(There’s not much difference between this IT-oriented analysis and one coming from a ‘real-EA’ perspective. The latter would cover a rather wider scope that’d throw up yet more crucial issues that cloud-providers, uh, somehow seem to forget to mention, but that’s about all, really.)

The key point is this: cloud is just another outsourcing arrangement. Anders is right: in many ways it’s just a reversion to the IBM ‘data-processing’ bureaus of half a century ago – brought up to date a bit, of course, and with a few more fancy bells-and-whistles such as ‘access by anyone from just about anywhere’, but otherwise the core principles are almost exactly the same.

So if it’s ‘just another outsourcing arrangement’, we need to handle it architecturally much as for any other outsourcing arrangement. In other words:

• Never outsource your business-vision.
• Never outsource your strategy.
• Never outsource your business-critical information – and especially, never outsource the ownership or control of your business-critical information.
• Know what you’re getting into, and why.
• Know what it will cost, in every sense – including all of the myriad hidden costs that no-one seems to notice until too late.
• Know what rules and regulations apply, under which jurisdictions.
• Know how to ensure alignment between your organisation’s business vision and values, and those of the outsourcing provider.
• Know how to ensure customer ‘single-view’, end-to-end continuity and suchlike whole-enterprise requirements.
• Know who’s responsible for what, when, where, how and why – and how to plug the inevitable gaps between boundaries of responsibility across the overall partly-outsourced business-structure.
• Know what can go wrong, and what impact each type of ‘going wrong’ could have.
• Know what to do when (not ‘if’) things go wrong.
• Know how to get out of what you’re getting into.

(That’s another list that goes on and on, too… and again, that’s why enterprise-architecture exists, to help you resolve each item on that list.)

What’s scary is the number of business-folks and IT-folks who’ve never even looked at that list, for any kind of outsourcing arrangement: they seem to buy into all of the sales-hype of the latest ‘fad-du-jour‘ instead, and apparently just hope for the best… Perhaps not the wisest strategy, shall we say?

There’s no question that cloud is great for a typical start-up – because there you do usually have to outsource everything you can, to keep the initial costs right down. Yet in a more mature business, things get radically different. Sure, you can scale cloud-apps themselves, and data-storage in the cloud, and so on. But not the way in which information itself is used across a 5,000-person company: that’s a different ball-game entirely.

What we find in practice is that, yes, some parts of the business do still need to be as nimble as any start-up – and hence, at first glance, would be seem to be ideal candidates for cloud-apps and the like. But some parts of the business need to be very stable, in some cases for decades or more – as in health, for example, or retail-banking, or some aspects of pharmaceuticals, or some types of engineering. After half a century and more of IT practice in organisations large and small, we do know how to manage that kind of data, those kinds of processes – and one of the things that that tells is that those kinds of requirements are not a good fit for cloud. And it’s different for every industry, every organisation, every size of organisation – whereas the best that most cloud-providers seem to offer is a kind of vaguely-customisable one-app-fits-all which in some ways combines all of the disadvantages of the different options with almost none of the advantages, other than some surface-layer cost-savings that may well evaporate and worse once Reality Department barges its way into the real picture. Hmm… Tricky, that…

To make it even more difficult, most large organisations have organisation-specific taxonomies and schemas that do need to be enforced across all usages throughout the business – which may well not be supported in the kind of prepackaged schemas offered by many providers. As a result, we’d have to do some potentially-tangled to-and-fro translations between the internal schemas, and the providers’ schemas – all of which is doable, of course, but increases the cost and the risk-potential, and reduces the actual savings from the outsourcing arrangement.

To make sense of all of this, we need a solid understanding of backbone versus edge – of what must be maintained strictly according to standard, or what must be managed internally for strategic reasons, versus what can be much more freeform; and the transitions and translations and governance-issues between them; and how all of the respective choices are guided in turn by enterprise-strategy. Which, again, is where a solid enterprise-architecture really needs to be part of this outsourcing picture.

Which brings us back to Anders’ point with which we started: cloud is ‘just another outsourcing-arrangement’. And as with any other outsourcing arrangement, the business needs a solid strategic understanding of all the implications of that outsourcing-arrangement – its potential advantages and disadvantages, its costs and revenue-possibilities, its opportunities and risks, its impacts on business-processes, and much, much more. And almost the only way to identify whether that outsourcing arrangement does or does not make strategic sense is via a well-described enterprise-scope architecture-description, fully linked to enterprise strategy.

Outsourcing everything – or anything, actually - to the cloud could be lethal to the business: yet without a proper enterprise-architecture, there’s no way to know what is a risk, and what is not. As Anders says, cloud is just a solution-pattern: there are usually plenty of other options that can be used instead. But enterprise-architecture is a management-function, a strategic function: not wise to try to run a business without it…

So cloud isn’t actually necessary to any business: but an enterprise-architecture certainly is. In that sense, cloud needs enterprise-architecture much more than enterprise-architecture needs cloud. Might be useful for everyone if some of the current clutter of cloud hype-merchants were a bit more willing to grasp that point?