More on starting EA from scratch

A follow-on to the previous post ‘Where do we start with EA? – a practical question‘, to address a number of comments and questions that came up via the Twitterstream.

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.