Tom Graves / Tetradian

Earlier today I came across a Tweet from the Open Group that pointed to an interview with Dr Leon Keppleman at University of North Texas. Given that the note was from Open Group, no surprise that it was mostly about IT, but to me, the headline was somewhat of a breath of fresh air, and I said so when I reTweeted it:

• tetradian: RT @theopengroup: On @infomgmt about “Getting Holistic with Enterprise Architecture” http://shar.es/fWDYZ >strong recommend #entarch

To me the article is a very good illustration of the crucial distinction between IT-oriented versus IT-centric.

In essence, the whole interview is all about IT, and IT-education: nothing much more than that. And parts of it show the usual IT-type errors, such as ‘information-systems’ solely in terms of software and the like, without any apparent reference to the human side of information. And it doesn’t exactly off all that well, either:

We have a pretty strong and broad curriculum, the students get several different programming classes, good grounding in network technology and database technology and software.

Which is not exactly what those of us in whole-enterprise architecture would be likely to regard as a ‘broad curriculum’. At first glance, it can seem so much “Oh no, not again…” that I wasn’t much surprised when a colleague complained at me for reTweeting it in such glowing terms.

Yet there are several points that make it stand out from the crowd. Keppleman continues the above with these comments (with the interviewer’s question in italic):

But we also try to bring in the big picture, how it really fits together. Though most of our students take entry-level jobs working on a particular project or part of a system, whether it’s infrastructure or software or some combination, we want them to leave with some sense that the things they work on are actually part of a much larger enterprise. That piece they are working on needs to be not just a good piece, but a great piece that creates value for the whole.

That sounds like a sales pitch for enterprise architecture.

Yes, and in my career it came to me backwards, too. My original focus was software development and obviously the importance of getting the requirements right. Well, it turns out that to have the requirements right, you need what you are working on in the context of the whole because otherwise you might build a great system but it doesn’t create value. It might be adding redundancy or be the 73rd system to connect 72 other systems. Even if those other 72 systems are part of stovepiped business units and are perfectly aligned with them and serve their needs, as a whole the enterprise is wasting a ton of money and a ton of resources and talent. That experience is what brought me to the enterprise architecture space.

The way I read that is that whatever you’re doing in software or whatever, there’s no point in doing it if it doesn’t support the overall big-picture. Whatever we’re doing, it’s always part of the whole – so we have to be aware of the whole, at all times. Hence the need for enterprise-architecture – which, as can be seen from above, has to be a real ‘architecture of the enterprise’.

In many people’s view of ‘enterprise’-architecture, IT presents itself as the centre of the business-world, the one undisputed core around which everything else revolves. ‘The business’, if mentioned at all, is described solely in terms of ‘anything not-IT that might affect IT’. (If you don’t believe me, go ask anyone not from IT whether TOGAF’s so-called ‘Business Architecture’ makes any sense to them in business terms…) That’s IT-centrism, and it’s a really serious problem in current enterprise-architecture.

But the article above, and the overall mood of the piece, is not IT-centric.

Sure, it’s unashamedly IT-oriented – no doubt about that. Dr Keppleman’s unit is nominally part of a business-school, but as he says, “most of our students take entry-level jobs working on a particular project or part of a system… infrastructure or software or some combination”.  (There’s a mild mis-labelling there, perhaps – it’s not what many of us would think of as ‘business’ – but that’s about the worst that I can see of it.) It is what it is: it’s just IT – and it doesn’t really claim to be anything else.

And yet it does maintain a broader awareness beyond itself. It’s clear that IT is seen as an important role, yet also that it’s just one part amongst many within that greater whole:

“…help us change how we work together and communicate within organizations to be more integrated, more holistic”.

I’ll admit that I really don’t like IT-centrism: it’s been the bane of the EA industry for far too many years. But I’m definitely not ‘against IT’, as some people have portrayed me to be. In a true ‘architecture of the enterprise’, everything matters, in depth as well as in breadth: so I’m very happy to see a piece that’s as IT-oriented as this, and yet does also know how to play its part within them whole.

IT-oriented is not the same as IT-centric.

Who or what is ‘I’? How does our experience of ‘I’ change as we interact with our world?

Yes, I do know that those questions might seem to fit more in philosophy or psychology. But as per the previous post, they also have huge ramifications in user-experience and user-interface design, in product-design, in sensemaking and decision-making, and in enterprise-architecture, business-architecture, security-architecture and many other architectures in general.

Quick summary so far:

• there’s a decision-making ‘I’ – “I am that which chooses”, that which experiences the world as ‘I’ and responds accordingly, and which can be highly volatile, especially in terms of real-time decision-making
• there’s a kind of presentation-layer of ‘I’, which is expressed through surface-appearance, through digital-personas and suchlike
• there’s a kind of interaction between each ‘I’ and that presentation-layer – an interaction which is particularly clear in work with Masks, as I’ll return to in a moment
• there’s a distinct identifier-layer for ‘I’, comprised of identifiers acknowledged or imposed by others as well as self, and typically associated roles, rights and responsibilities for ‘I’ – with the identifiers often associated with external or assigned personas (digital or otherwise)
• beneath it all, in most cases, there seems to be a kind of unitary ‘I’ that is experienced by self as ‘I’, and perhaps also experienced by others as one’s ‘I’ – though with reservations on that such as indicated by the classic Johari Window model

So, to identity and Mask.

I’ve just finished re-reading Keith Johnstone’s classic ‘Impro: improvisation and the theatre‘. To me, it’s absolute must-read for anyone interested in the human side of enterprise-architecture: its sections on status, spontaneity and narrative can be real eye-openers for understanding how organisations really work. (Or, more often, don’t work…) Yet for me it’s always been the last section in the book that’s always stood out the most: the section on Masks.

The term ‘Mask’ has a special meaning here – hence the initial-capital on Mask, to distinguish it from a more everyday theatrical mask. In many ways the Mask is just an ordinary half-face mask: the difference is more in how it’s used, not just as a costume-prop but as an active persona or literal ‘per-sona’ – an active filter on ’that through which I sound’.

[There's also another set of techniques that work with full-face Masks, or Tragic Masks, but I won't go into any of that here.]

The context in the book is improvisational theatre, of course – not enterprise-architecture. Yet there are a few themes that are extremely relevant for us.

One is that it’s a real and intensive research-environment. True, it’s subjective-research rather than objective-research, but in essence the principles of of investigation are the same, and certainly the level of discipline required is much the same if they’re to get usable results. So don’t dismiss it out of hand because it’s not IT…

Given that, note what is probably the key theme there: that there’s some kind of interaction that goes on between actor and Mask. It’s not as simple as a one-way ‘I am wearing this prop’: wearing a Mask has definite impacts on the actor, and it seems there’s even some continuity between different people wearing the same Mask:

Another Mask was called Mr Parks. This one used to laugh, and stare into the air, and sit on the extreme edge of chairs and fall off sideways. Shay Gorman created the character. I took the Mask to a course I gave in Hampshire. The students were entering from behind a screen and suddenly I heard Mr Parks’ laughter. It entered with the same posture Shay Gorman had adopted, and looked up as if something was very amusing about the ceiling, and then it kept sitting on the extreme edge of a chair as if it wanted to fall off. Fortunately it didn’t, because the wearer wasn’t very athletic. It really makes no sense that a Mask should be able to transmit that information to its wearer.

I’ll very carefully make no comment here as to how that kind of information could pass from one actor to another, just through the medium of the respective Mask: just note that it is so, under those types of technical conditions.

Also explained in the book is that the whole thing depends on some quite specific psychological or psychosocial conditions. To translate it into the terms I’ve been using with the SCAN framework, it’s all happening in the real-time space, and it just does not work on the Belief (‘control’) side of the decision-modality spectrum. It only works either on the Faith-side of the decision-spectrum – where conscious choice of some kind is available, though primarily as a kind of ‘intentional surrender’ – or when there’s no conscious thought at all – which also means no conscious choice.

The fundamental point in Mask work is that there is a sense not so much of loss of ‘I’, as a kind of negotiation with the Mask as to what that surface-’I’ will be. And the Mask can impose some fairly severe constraints on what it can allow, its ‘repertoire’ and suchlike: for example, it can be very difficult to do any kind of predefined script whilst doing Mask-work. If there’s no awareness of that negotiation with the Mask, there are two likely outcomes: either the student will attempt to’take control’, which results in poor outcomes and sometimes literally ‘wooden’ performances; or the student will fail to notice the impacts of the Mask, and in effect believe that the results are their own choice of ‘I’, rather than the default sort-of-choices imposed by the Mask. Which might well not be a good idea…

So what on earth has any of this to do with enterprise-architecture?

The answer is this: anything can be a Mask in this sense. Anything.

To be slightly more specific, anything that can act as a surface-level filter or persona – a ‘that through which I sound’ – can act as a Mask in this sense. Whether or not we are consciously aware of it doing so.

And anything that can act as a filter on ‘I’, also in effect changes the surface experience of ‘I’, of how others experience that ‘I’, and also the actions and choices of that ‘I’.

A couple of really simple everyday examples:

– Someone may be the most mild-mannered person face to face, but suddenly an absolute demon behind the wheel of a car.

– Conversations in Twitter often seem artificial, terse, mechanical – the Mask of the 140-character constraint.

Consider all the ‘professional props’ of just about every trade and tradition: the doctor’s stethoscope, the barrister’s wig, the consultant’s clipboard. All of them are Masks: the person’s behaviour, demeanour, stance and language will all change the moment they pick up that prop.

Consider a business uniform, a brand, a shop layout, a user-interface layout: they’re all Masks in this sense too – an active filter for a persona, as ‘that through which I sound’, impacting on and constraining the choices and actions of the respective ‘I’.

Every role is a Mask. Every digital-identity or digital-persona is a Mask. (Think for a moment about the impact of that on the ways that people interact with digital systems – especially when multiple personae intersect.)

Layer upon layer upon layer of Masks, changing continuously throughout every day.

And, if we’re not conscious of those impacts and constraints on ‘I’, will find our ‘I’ seeming to change with each change of Mask, yet not knowing how or why.

In short, the sense of identity may – and probably will – become fluid in the context of a Mask.

And almost anything may act as a Mask.

Often in unpredictable and/or emergent ways.

Affecting interaction with just about everything else.

Hence, also in short, a definitely non-trivial concern for security, privacy, user-experience design, process-design, branding and a whole host of other themes in enterprise-architecture and elsewhere.

Identity and Mask might perhaps seem somewhat abstract at first. A bit less abstract by now, I hope?

Over to you for comment, anyway.

Who or what is ‘I’? How do others recognise that ‘I’? How does that ‘I’ express itself? – with what voice does that ‘I’ speak? And how do others recognise that voice?

Yeah, I know, sounds like philosophy and stuff – woefully abstract, deep and pointless. Yawn.

But those ‘pointless’ questions are the core – the heart – of a lot of really important everyday concerns for enterprise-architecture: privacy, security, sales and marketing, just to name a few. The core of ‘enterprise’ itself. Abstract, yes; yet also just about as pragmatic as it gets. Hmm…

Where this got started was a post by Brian Hopkins, on his Forrester blog:

• practicingEA: 2012 Predictions – Technology Will Shape Who We Are As People And Businesses

The post itself is a quick summary of some key themes happening in the IT side of enterprise-architecture at the moment: the fading of ‘Big IT’, a new focus on data, the convergence of social, mobile and local, and the ongoing hype around cloud. Fair enough: interesting to IT-oriented folks, certainly. The comments, though, focussed in on questions about identity in that space – and that’s where things got really interesting…

In essence, we ended up with those questions above. There’s a lot in those comments on Brian’s post, and I won’t repeat it all here: go look at it in the original, it’s well worth the read, especially the notes by Stephen Wilson on on digital-identity. What I’d like to pick up on briefly here are four of those themes:

• identity is simple, complicated, complex, ambiguous, unknowable – all at the same time
• identifier and identity are not the same
• identity and persona are not the same
• identity is filtered through many layers of persona

Identity is complex – that’s the shorthand version, anyway. It’s fluid, it stays the same: we can recognise friends after thirty years’ absence, we barely recognise our own face in the mirror each morning. For me, it changes with the clothes I wear, both in my own sense of identity, and how others seem to see and interact with me. I am my car, my house, my phone, my ideas, my memories: I think I possess them, but they also possess me.

Identity is like a hologram: blurry, muddled, indistinct – until the light shines on it in just the right way. For a brief instant, identity is certain, crystal-clear – and then vanishes again. Until the light shines on it from another direction, showing a different facet, a different face – yet of what is still the same hologram of identity.

Identity is multi-faceted, bewildering, chaotic. There’s one sense I have of ‘I’ when I’m at home, another in the office, another when I’m on stage at a conference, yet another with friends or colleagues in the cafe, and different again when chatting online, or chatting with the ‘checkout chick’ at the market or the mall. On the surface, and from the ‘the inside’, those can be very different people: so which one is me? Which one is real? Which is the myth? And when two or more of those myths collide – meeting work-colleagues at home, for example – there’s a kind of ‘mythquake‘, where for a brief panicked moment nothing seems real at all. Is everything just an act, a mask? Is there anything real behind all of those masks? And yet there is a single unitary ‘I’ in there somewhere, the one voice behind all of those different voices – otherwise we couldn’t recognise it as ‘I’. To quote the Cluetrain Manifesto:

…These markets are conversations. Their members communicate in language that is natural, open, honest, direct, funny and often shocking. Whether explaining or complaining, joking or serious, the human voice is unmistakably genuine. It can’t be faked.

Yet Cluetrain is also about another kind of identity-clash: the distinction between individual and collective, the identity of ‘I’ versus the identity of ‘We’. When I’m part of ‘We’, where is ‘I’? Which one is real? Which one is the mask, the myth?

Confusing, to say the least. And if that’s at the core of so much of enterprise-architecture, it’s no wonder that that’s complex too. Too complex: hence no surprise that so many people try to make it out to be simpler than it is – and that’s where things get messy…

Identifier and identity are not the same - an identifier is not identity, it’s a proxy for identity, for when we don’t have other means to recognise identity. An identifier is just information - and information about something is not the same as the thing itself. It seems this should be obvious, yet evidently it isn’t –  especially to many of those who work on Digital Identity and suchlike, designing IT-systems that seemingly assume they are the same.

We talk about ‘identity-theft’, yet in most cases – perhaps all? – it’s theft of identifier, not identity. An identifier links not to identity, but to a persona associated with that identity – the identity as a role, a set of rights, responsibilities, authorities, tasks. In a possession-based culture, an identifier provides ‘rights’ of access to resources, ‘the right to know’, the right to use: if the identifier is hijacked, those ‘rights’ are hijacked too. That’s what all the worry is about: loss of access to resources, loss of control, loss of concealment for key information. That matters, obviously. But it’s identifier-theft, not identity-theft: the distinction is important.

Going the other way, identity is not identifier. I may put on a company-uniform to identify myself to others as a member of the company; my business-card carries both my own name (a personal identifier) and the company-name (a collective identifier); but that doesn’t mean that I am the company, or that the company ‘is’ me. I use the company-identifier as a persona, and others may recognise me via that persona: yet it isn’t who I am. That distinction is important, too.

[A side-note here: in terms of asset-dimensions, relational-assets link to identity, whereas aspirational-assets mostly to the persona - concrete versus abstract. For more on this, see the post 'Relational-assets are not 'possessions' '.]

Identity and persona are not the same – a persona is an overlay of identity, in exactly the same sense that my clothes are an overlay on myself. A persona is literally ‘that through which I sound’ – a filter, a mask. Online, we have many different personas – not just as represented by distinct avatars and the like, but every online account is in a sense a persona, a ‘that through which I sound’ to or with the respective application.

And the same the other way: the application presents a different persona – a different interface – for us depending on whether we’ve logged in or not, and in some cases (such as the Amazon website) may even adapt itself over time to match the changing history of the relationship. Note the ‘identity-confusion’ that can occur when we present a mismatched persona – such as entering the wrong username / password combination, or using the same avatar in different social contexts.

So too in the offline world. Almost everything is or can be used as a persona: clothes, props, language, body-stance, the way we may drive differently in a rental-car compared to a car we consider ‘ours’. And it’s not just one-way, from us outward: we feel different in different clothes, in different cars, in different climates. There’s an interaction between people and place, and the place has choices too – certainly in a metaphoric sense, perhaps in a literal sense as well.

Identity is filtered through many layers of persona. Persona is ‘that through which I sound’ – a Mask. Each of us has layer upon layer of Masks, some of them seemingly our choice, others less conscious, and yet others sort-of imposed by culture, by context, by the impacts of advertising and the like. It’s complicated… complex…

[One of the best sources to get a sense of of all of this is in impro-theatre: for example, see Keith Johnstone's classic 'Impro: improvisation and the theatre' - particularly the later section on Masks.]

In enterprise-architecture, one of the more useful concerns is provide conditions under which the distinctions between identity and persona become more visible – are ‘surfaced’, to use the psychology-jargon. When people become aware of those distinctions, they also become aware that they can choose the extent to which they identify themselves with a persona – and can let it go and choose an alternative that is a better fit to a changing context. Often we might intentionally set up some kind of ‘ritual’ to mark the boundary: for example, donning a safety-helmet on a building site also triggers a more safety-aware persona.

There’s a lot more to explore here, of course – anyone interested in taking it further?

Okay, let’s go back to something that’s perhaps a bit less controversial than the past few posts…

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?

The Archimate notation aims to be the standard to be used by everyone in enterprise-architecture and related fields. But what exactly is its anatomy – its underlying structure? And if it’s aimed at enterprise-architecture, what is it about that structure that makes it seem only to support IT-architecture, and in such an awkwardly IT-centric way?

(Apologies, folks, because, yes, this is going to be another one of those very long, very technical posts… Skip it if you’re not interested, of course, though I believe this actually is important for anyone involved in enterprise-architecture and the like.)

Read more…

A selection of Tweets from various folks – with an especial thank-you to @systemsflow and @theopengroup – from the Open Group conference, Austin, Texas, 18-20 July 2011, via the Twitter hashtag #ogaus. (Selected in the sense that most of the Tweets I’ve included are on business-architecture and enterprise-architecture – I haven’t included much on Cloud, IT-security or other strictly IT-oriented themes.)

Various breaks added to split the overall Twitter-stream into (I hope) more meaningful clusters; I’ve also added comments in various places in italics preceded by a ‘>’ marker, >like this.

There’s quite a lot of it, so take a wander after the ‘Read more…’ break.

Read more…

This one started from a Tweet from Vince Outlaw, one of the attendees at the recent Gartner EA conference in San Diego:

• SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R Very timely as Enterprise Business Architecture is a HUGE subject at #GartnerEA

If you know me, you won’t be surprised that to me that was like a red rag to a bull. Yup, I admit it, I fulminated:

• tetradian: RT @SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R >Business Architect is _NOT_ an IT job!!! #entarch #fercryingoutloud..

Then Ivo Velitchkov (backed up by Patrick Lujan) came back in with a dose of realism. Unwanted realism, maybe, but realism nonetheless:

• kvistgaard: @tetradian Well, let’s face it: it is! “Business” is misused in #BPM and Business Architecture, same as “E..” in #entarch. So really, Business Architect, nowadays, sadly, is an IT job.

Whilst Nick Malik dived in from another direction:

• nickmalik: RT @SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R >Business Architect is _NOT_ above EA either!!! #entarch

…and, later, expanded on this with a post of his own:

• nickmalik: [post] Different Specialties of Architect http://bit.ly/iRmtCE  –> To reduce the arguments about #entarch

Which might well look like Yet Another Pointless Argument About Job-Titles… “Oh no, not again”, I hear you cry?

Actually, this is a serious problem, and all of those are valid responses, in their own ways. Enterprise business-architecture is a very important aspect of enterprise-architectures; done properly, it is definitely not an IT-role, but at present it is still all too often portrayed as such; and the relationships between the various roles have become very blurred, very messy, and very confusing, to the point where that confusion is causing a lot of damage to organisations and their business-related architectures – and to the profession as a whole. Oops…

The core of the problem is not merely one but two related term-hijacks:

• portraying enterprise-architecture as minor subset of IT-governance;
• portraying business-architecture as a kind of random grab-bag of ‘anything not-IT’ that might affect IT’.

The worst perpetrator of this, I’m sorry to say, has undoubtedly been the Open Group, aided and abetted by ‘the usual suspects’ – the big IT-consultancies and analyst-firms. All of whom have only just realised how much they’ve succeeded in getting themselves ‘hoist by their own petard‘, but have unfortunately caused (and are still causing) a lot of damage with their previous overly-myopic IT-centrism.

I hasten to add that some of the Open Group crew are well aware of the problem, and the damage that it causes. For example, the indefatigable Len Fehskens has been fighting this particular battle for even longer than I have: his blog-post ‘Enterprise Architecture’s Quest For Its Identity‘ is an absolute must-read for anyone involved in anything to do with enterprise-architectures. His nomenclature of roles is really useful here: xA, ExA, EA (about which more in a moment). In essence, the architect’s role consists of bringing things together into some kind of unified whole, for a chosen purpose. I’ve expanded on this a bit more in my earlier post ‘Making sense of architecture roles‘, but the key point is that to understand and describe the role, we need to understand both its scope (or ‘breadth’) and its direct skill-level (or ‘depth’). A domain is a region of scope and expertise: for example, IT-infrastructure, security, brand, organisation, process, logistics and so on. In Len’s nomenclature, ‘x is any specific domain:

• xA (e.g. applications-architect, brand-architect): a domain architect, with emphasis on a single domain or closely-related cluster of domains, almost always with high skill-level (strong depth) in that domain – i.e. deep, but probably not broad
  (a solution-architect is usually a domain-architect assigned to a specific project or change-programme)
• ExA (e.g. EBA, ‘enterprise business-architect’; EITA, ‘enterprise IT-architect’): an enterprise-scope domain-architect, with emphasis on how a single domain links with other domains; the skill-level is sometimes referred as ‘T-shaped’, deep-skill in one domain, but sufficient of knowledge of other domains to able to support good ability to converse with other domain-architects and other specialists from those other domains
• EA: a specific domain-architect whose domain is the enterprise as a whole, and for whom the core skill-set includes cross-context specialisms such as systems-theory, human-factors, futures, strategy and other ‘big-picture’ themes; the skill-level across domains tends to be broad rather than deep (i.e. ‘comb-shaped’ rather than ‘T-shaped’), but must include all domains that are in scope for the enterprise

(Note that in most countries, by law, the only people who can describe themselves as ‘architects’ – without any other qualifier – are building-architects. Everyone else in all other cross-context-linking or cross-domain-linking professions must use some kind of qualifier – hence naval-architects, civil-architects, security-architects and, of course, enterprise-architects.)

What the Open Group have done in TOGAF is to completely scramble that nomenclature: routinely, an IT domain-architect or, at best, an EITA is labelled as an ‘EA’, with business-architecture – which should be a domain that is business-focussed and functionally distinct from IT – parked somewhere entirely arbitrary ‘under’ the IT-centric ‘EA’ banner. Hence that ‘business-architecture’ is simultaneously both ‘below’ and ‘above’ that ‘enterprise-architecture’, in several different utterly confused and utterly confusing senses. It is, bluntly, a mess – an unusable mess. And whoever it was that insisted on incorporating that mess into TOGAF 8.1 and TOGAF 9 should be quietly taken out and have their noses rubbed in that mess every single day until they themselves have sorted out the mess, because the end-result is that it’s made it almost impossible even for IT-architects to do their jobs, let alone anyone else.

So yes, Ivo and Patrick are right: it may well be true that ‘business’ architect is currently described as an IT role. But the blunt fact is that it really doesn’t help to do so: it just perpetuates the mess. Every one of us needs to be emphatic about this, because it is probably the primary cause of damage to the profession at present.

And yes, Nick is right, too: business-architecture is a distinct domain – the architecture of ‘the business of the business’ – that must not be seen as ‘above’ the scope of the broader shared-enterprise in which the business operates. By definition, it’s sort-of ‘under’ EA, because EA provides (or describes, or maintains, or whatever) the overall umbrella (or coverage, or network, or mesh, or whatever) under which (or through which, or within which, or whatever) everything connects with everything else. But when only IT-architectures are described as ‘EA’, then there are some circumstances in which BA or EBA is ‘above’ that kind of ‘EA’. Yet also circumstances when they’re not – given the way that TOGAF describes BA and EA. Which again adds to the mess…

Which is where we come to the second term-hijack in TOGAF and similar IT-centric ‘EA’: defining ‘business-architecture’ as ‘anything not-IT that might affect IT’. Reading the TOGAF spec – particularly the TOGAF ADM’s Phase B, ‘Business Architecture‘ – there is almost no distinction made between high-level strategy (whose main impact is at Zachman layers 3 and above), process-design (typically Zachman layers 3-4) and protocols and the like process-execution (typically Zachman layers 4-5): it’s all ‘not-IT’, hence all jumbled together into a kind of blobby blancmange with no functional meaning at all. Take a look, too, at the TOGAF description of ‘business scenarios‘ – somewhere around the Zachman layer-4 – and compare that to the business-usage of the term – which is more like Zachman layer-2. Hence, overall, no wonder that business-folk get seriously annoyed at IT-centric ‘EA’ and its daft description of ‘business’-architecture that makes no business sense.

So we have TOGAF – and just about everyone else in the so-called ‘enterprise-architecture’ space – describing an ‘enterprise-architecture’ that isn’t about the enterprise as enterprise, and a ‘business-architecture’ that has very little connection with the business of the business. Oops… not helpful…

So in that sense, no, I disagree with Ivo and Patrick: it may be ‘realism’ to say that “really, Business Architect, nowadays, sadly, is an IT job”, but it is definitely not wise to allow that misnaming to go unchallenged, because the consequences are very serious indeed. (The building-industry has long since discovered this blunt fact the hard way – hence the legal controls around the ‘architect’ term.)

And I also sort-of disagree with Nick – not from what he’s said as such, but more from where I know he’s coming from: when the business of the business is IT – as in his own business-context at Microsoft – it’s again all too easy to fall back into IT-centrism, and I do detect more than a hint of that in his follow-on post about ‘Different Species of Architect’.

Overall, though, I’d have to insist on this as a summary:

• business-architecture touches IT, but is not an ‘IT role’
• business-architecture is a domain-architecture – ‘the business of the business’ – and hence necessarily comes ‘under’ the broader whole-enterprise scope of enterprise-architecture

Any other way to describe the relations between business-architecture, IT-architectures and enterprise-architecture will merely compound the mess that TOGAF et al have already made of this profession. Sigh…

That’s my opinion, anyway. For what it’s worth. Over to you?

Software-architect extraordinaire Simon Brown kindly pointed me to the InfoQ article ‘Agile and Architecture Conflict‘, which summarised the views of various folks on the ‘agile vs architecture’ debate, including myself, Simon and another of my regular co-creators (co-conspirators? ), Jan van Til, all of us looking at different aspects of the idea that agility needs a backbone in order to serve the needs of the enterprise well.

The InfoQ article included a really important question: “But how does it all tie up in the real world?” In other words, what is this ‘backbone’? How does it work? And how do we define it, build it, maintain it, use and reuse it to support enterprise agility? So from my admittedly architecture-oriented side of the fence, here are some suggestions towards a practical answer.

Step 1: It’s all about the enterprise. In effect, the backbone represents the core of the organisation’s relationship with the enterprise. Agility only makes sense if it directly supports the enterprise, and that relationship with the extended-enterprise. So to make any sense of this, we need to identify what that extended-enterprise is – in other words the deep-’Why’ for the organisation and its relationship with others, as expressed in its business-model, system-interfaces and so on. There are quite a few ways to do this: I typically use a workshop based on the sequence Vision, Role, Mission, Goal (there’s more detail on this in various of my books, such as Doing EA and Mapping the Enterprise), but there are plenty of other options.

What we need to end up with at the end of this step is some kind of vision-descriptor (about the extended-enterprise, not solely the organisation!), and an overview of the various players and key assets, activities and resources in use throughout that extended-enterprise. That becomes our starting-point for the next step.

Step 2: What part do we play in the enterprise? For what assets, activities and resources do others come to us and our organisations, or which we need from others? In the IT part of the organisation, this should tell us the types of information of which we need to keep track. We need to take a note at this point to try to distinguish between information whose structure remains stable and is used by many different areas of the organisation and its partners – because those items are likely candidates for the ‘backbone’.

Step 3: What enterprise items are unique to this organisation, and/or to its immediate partners or competitors? For example, the national mail-provider (Australia Post, Royal Mail, USPS etc) will usually have the responsibility ‘on behalf of the nation’ to maintain an up-to-date list of addresses, locations, post-codes and even probable addressees; Google maintains huge physical data-storage capacity and unique search-algorithms; Amazon builds and maintains a vast index and repository of opinions about products. Any such ‘unique items’ are almost certain candidates for the ‘backbone’. Note that these items can be much more than data alone: for example, the armed forces in principle represent unique capabilities for the nation, not just weaponry, but communications, logistics, field-hospitals and much more besides. We may also be able to identify some of these items by reviewing business-processes and other activities: for example, a national mail-provider will also maintain street post-boxes, which represent a ‘unique enterprise asset’.

In some ways what we’re looking for here are similar to ‘core competencies‘ and the like – yet it’s also sufficiently different that we need to take care not to get too sidetracked down that route. For example, equivalents for some data-items, such as industry-wide product- or service-identifiers, may also be held by competitors, by suppliers, or even by customers. The point here is that they’re unique within the shared-enterprise – which again makes them key candidates for inclusion in the ‘backbone’.

Step 4: What enterprise items are essential to our work for and contribution to this enterprise, and will need to be shared across our organisation? For example, if we are a commercial organisation, we’re very likely to have customer-records and service- or inventory records; almost every organisation will have HR records, organisational-structure records, account-codes, and so on. The point is that these are items that will need to be shared by everyone, in a consistent way – because if it’s not described and handled consistently, it’s almost certain to cause problems. If they’re essential to the business of the organisation, and shared across the organisation, they need to be in the ‘backbone’.

Step 5: Using all of the items identified in the previous steps, define the ‘backbone’. We would typically do this through the tools and techniques of the various domain-architectures: data-architecture, applications-architecture, process-architecture, organisational-architecture, brand-architecture and so on. (Notice, by the way, that not everything needs to be in the backbone! We don’t try to record everything in ‘excruciating detail’, in classic Zachman style – instead, this applies only to the items that really are core to the organisation and enterprise as a whole.) We may well need to do a ‘clean-up’ at this point to improve consistency and reduce duplication, such as described in TOGAF and the like. Once any item is included in the backbone, it should be placed under strict governance and change-control, with an explicit item-owner. Each backbone item should also be included in an explicit glossary and thesaurus, which itself should be subject to strict governance and change-control. The scope of governance depends on the context: in some cases it may be constrained to a single business-function or business-discipline, but in others the scope may need to be organisation-wide, or even broader.

Step 6: Define the interfaces to the ‘backbone’. This is where service-oriented architectures come into their own – IT-SOA, service-based process interfaces, and so on – with explicit service-catalogues and the like. Anyone who uses the information or other items (process-functions, assets etc) will need clear rules and, in many cases, development-support, on how to use the item, and the conditions under which it may be changed. There’s nothing particularly new in this: it’s fairly straightforward service-architectures, except that it should not necessarily be constrained only to information or IT.

Step 7: Define the spectrum of governance from waterfall-control to free-form agile, and the conditions that apply to change-projects and experiments at each point along that spectrum. In other words, define a flexible form of governance across the change-space, in which, for example, ‘Shadow IT’ would be explicitly encouraged as long as it’s outside of clearly-defined bounds. Provide support to enable agile projects to identify non-negotiable constraints such as regulation or mandatory standards.

Step 8: Define governance needed to migrate new items into the backbone. This is an important part, because the core will slowly change – some things will be dropped, but new processes and information-stores and the like that have proven both useful and reusable out in the agile space will be valuable in the core. As they move more towards the backbone – i.e. become shared by more people, and those crosslinks become more business-critical – they would also move ‘upward’ in terms of strictness of governance, from free-form agile towards waterfall-control.

The end-point of all of this is that we end up with a layered structure: a core that has a set of defined content with defined interfaces that can be be accessed anywhere required, and all tightly controlled; then a mid-layer in which interfaces tend to be shared across a more limited range; and finally agile hacks and mashups that may well be used only for one business-unit or even for one short- to medium-term purpose, but which still accesses the backbone for anything that is and needs to be common across the whole organisation. Some people might see this as somewhat hierarchical, but in fact it isn’t: mashups can connect to other mashups as required, perhaps bypassing the backbone completely. The point is that the backbone interfaces are guaranteed not to break (or, if they do need to change, then anyone who might be affected by the change would know about it in advance); the mid-range interfaces are not guaranteed; whilst the agile-layer interfaces – if they exist at all – can be all but guaranteed that they will break at some point. And it doesn’t matter that they might break – that’s the whole point. In other words, whilst the backbone must usually be as ‘fail-safe’ as we can make it, and the mid-layer must ‘fail gracefully’, the agile layer is intentionally designed to be ‘safe-fail’ – we often want it to fail, so as to learn from the ‘failure’, and adapt and retry accordingly.

This also resolves some of the classic fights between ‘the IT department’ – the conventional big-IT systems – and the ‘shadow-IT’ of little Excel quick-and-dirty kludges and local databases and HTML5/JSON/NoSQL hacks. In this scheme, each has their explicit place, with their own governance, their own role: each needs the other, and hence needs to respect the other, too. And it also clarifies the role and place of upcoming technologies: cloud, for example, has a really strong place in the agile context – but is often likely to be a very bad idea for the backbone.

So that’s my understanding of all of this: a way to unify architecture and agile, linking process-management, asset-management, information-management and everything else via a systematic enterprise-scope architecture, to support agility wherever it’s needed, and in whatever form is needed.

Something to play with, anyway: comments/feedback/suggestions, anyone?

The following a selected subset of the Tweets and links sent out by attendees and other from the Open Group (TOGAF) conference on enterprise-architecture, IT-security and cloud-computing. Given my own interests, I’ve emphasised enterprise-architecture, but I’ve included many of the others as well. (If you want to see the full set, follow the ‘#ogsdg‘ hashtag on Twitter.)

I wasn’t able to attend the conference this time, hence many thanks to @theopengroup, @togaftm, @stevenunn, @masrod, @aleksb6, @TechnoDad and all the others who kept us ‘outsiders’ in touch with what went on.

For what it’s worth, I’ve added my own comments at the end of some of the Tweets, in italics and preceded by a ‘<’, <like this. Feel free to ignore, them, of course.

Read more…

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…