Where do we start with EA? – a practical question

You’re an experienced enterprise-architect, having spent most your working life in one industry. You now have a new job, in a new company, in an industry that’s entirely new to you. And the company at present has no architecture at all: you’re ‘it’. Where on earth do you start?

That’s the situation my friend Alan finds himself in right now. An interesting challenge – and some very real, very practical questions to face. Right here. Right now. Today.

[I guess this post can also start to answer in part the question from the previous post, ‘How do we make EA make sense?‘.]

So: in essence, we start from scratch.

Which means that several threads need to start straight away, somewhat in parallel:

• 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 first point is that everything about any form of enterprise-architecture is intensely ‘political’, in several different senses – which means we need to face the politics of this straight away, right from the start. One of the best guides to this is Kevin Smith’s PEAF (Pragmatic Enterprise Architecture Framework). In essence, it’s a step-by-step guide on how to get enterprise-architecture going within an organisation: see the website and book for more details. [Disclaimer: I edited the book.] The details are all there on the website anyway, so you don’t even have to buy anything (though no doubt Kevin would like it if you did! 🙂 ).

Probably the single most important concern is to get ‘buy-in’ at senior level – certainly from the respective CxO for the main focus area (e.g. the CIO, for enterprise IT-architecture), but preferably from the CEO and entire executive. To be blunt, if you don’t have that ‘buy-in’, you’ll be going nowhere: you need to get the executive on-side.

As PEAF emphasises, the key to getting the executive on-side – and everyone else on-side, too – is communication. One valuable aspect of this is to get them personally engaged in describing the big-picture of the overall ecosystem in which the organisation operates, and where the organisation fits within that ecosystem. In effect, what we would do here is identify the high-level ‘why’ for which the organisation is a ‘how’ – in other words, the ‘why’ that provides the anchor for all of the organisation’s strategy.

There’s a lot of detail on how to do this in the chapter ‘Step 1: Know your business’ in my book Doing Enterprise Architecture – that chapter is part of the ‘sample-ebook’ version that you can download for free from here. (See the post ‘Tools in action‘ for some photos of those techniques in live use in an executive-level workshop.)

What I also usually do is plough through the publicly-available sources such as the organisation’s website, publications, advertisements, intranet and annual-report. There’s usually enough information there to build some preliminary models with which to get started: or at least, enough for people to tell us that the models are wrong – which is a nicely sneaky way of getting them engaged in telling us their ideas about what it should be. 🙂 You’ll also notice in that ‘Tools in action’ post that we included people’s own photos on some of the larger wall-mounted models: this again is a good way to get people engaged, and to get conversations going between them about what they can do to improve their own work-context.

Whilst we’re doing this, we need to be looking for any allies – people who are already committed to other themes that connect with enterprise-architecture, and would be likely to see the value of synergy between those areas of interest. This is really important if we’ve only just started with the organisation, because – in my experience, anyway – enterprise-architectures depend greatly on person-to-person conversations and connections: knowing who to talk with, and how to talk with them, will depend in turn on backgrounds and credibility and personal-networks within that organisation that typically take at least five or more years to develop.

Those are people we need as allies: and finding them is one of our first and most urgent priorities as soon as we start work at new place. One tactic I’ve used for this is to sit in the cafe or whatever with a few interesting-looking diagrams spread out over the table: anyone who’s interested enough to stop by and chat is likely to be that kind of ‘connector’, or will at least know someone who is. Again, despite all those models and the rest, what really drives the architecture – what makes it happen, in real-world practice – is person-to-person conversations.

Another concern that those allies can help us with straight away is in identifying the standards that apply in the context. Some standards would apply to just about every industry, but we’d be likely to know those already. Other standards will be generic for the industry as a whole, but they’re usually not hard to find: for example, for this case, in retail, a quick web-search on “retail reference architecture” turned up a swathe of IT-oriented standards from Oracle, Microsoft, Cisco and IBM, together with articles on how to put them to practical use. This is also where TOGAF and the other enterprise-architecture ‘usual suspects’ will start to be of real value – though to be honest they can often be more of a hindrance than a help before this stage.

What we’re also looking for are all the other standards and guidelines and workarounds and the like that are specific to this organisation, some of which – perhaps many – may not exist anywhere in any written form. And that again is where our allies can be really helpful, because otherwise we’d have little chance to know what these are. (And yet everyone else would expect us to know them, because, after all, we are ‘the architects’, aren’t we? – we’re the ones who are supposed to know all this stuff… 🙂 )

And we’ll also need to be on the lookout for standards that should be there, and aren’t. Which can be a little bit tricky, from a political perspective – not least because it tends to highlight issues that people ‘should’ have known about already, and didn’t… Once again, our allies will be invaluable here, in finding suitably-stealthy ways to introduce these ideas, and to smooth out any ruffled-feathers that may arise.

One trap to watch for is to beware of bringing too many assumptions from our previous organisation and industry: many of those assumptions will not work in this new context. The skills and experience of ‘how to do architecture‘ are probably the only part of the work that will remain unchanged: we need to able and willing to challenge ourselves on just about everything other than that.

Almost all of that above is about enterprise-architecture as structure. The other side is about about architecture as story, the second of Matthew Frederick’s ‘two points of view‘ on architecture:

ARCHITECTURE IS AN EXERCISE IN NARRATIVE. Architecture is a vehicle for the telling of stories, a canvas for relaying societal myths, a stage for the theater of everyday life.

Although hardly acknowledged at present in mainstream ‘enterprise’-architecture, this is enormously important: story is emotive; story embeds meaning; story engages. Stories matter: in a very real sense, everything about the architecture is or represents or describes a story. Even the enterprise itself is a story. Which means that it’s well worth while to go ‘looking for the story’, much like a journalist or filmmaker or any other storyteller would.

What I usually do for this is ‘go for a walk’, either metaphorically via the website and intranet and so on, or – preferable – literally go for a walk, in person or with one of my new ‘allies’, around some of the organisation’s sites and spaces, looking for all of those interweaving stories that hold everything together. Some of these stories are straightforward enough: every transit through a business-process is a story; every customer-experience or ‘value-journey’ holds a story; every transaction is part of a story that extends far beyond the transaction itself.

Yet there are also the many stories that employees and others tell themselves, and tell each other, about what works, about what doesn’t, about what is or isn’t valued in practice within the organisation, about workarounds or special-cases that no-one’s gotten round to documenting but without which the store or warehouse or whatever won’t work. Those stories are often really important from a structure-perspective, too.

And there’s the story – or stories – that the organisation tells about itself, about how it positions itself in the market, about what it values most and would most like to share with others; and the stories that others in turn tell about the organisation – including whether they believe that the organisation holds to its purported values. Those last stories are some of the most essential real-world feedback for strategy – which in turn feeds back into changes in structure, in the what and how and where and when of the conventional enterprise-architecture.

Best stop there for now, I guess. But, yes, starting a new architecture is always a real challenge – yet always an interesting and worthwhile one!

I hope this has been useful, anyway: and good luck!