Enterprise Architecture's 3 C's

One of the things that my second stint in Enterprise Architecture has clarified to me is that I have strong opinions on what Architecture is, and what it isn't. I feel like I understand now why Enterprise Architecture has a negative reputation, and what I can do to combat that in my own small way.

I've been building up a long list of topics that I want to cover on the blog, and I noticed that most of them were of the "What not to do" variety, and very few addressed the value proposition. It's easy to see things that are wrong, but the real work comes in identifying what right looks like. In building some planning documents outlining what I'm planning on doing in 2018, I developed the 3 C's of Enterprise Architecture - Consistency, Context and Collaboration.

Consistency

Why?

As Tom Graves likes to say, everything works better when it works together, on purpose. This is partially accomplished by ensuring consistency between the component parts of your architecture. Choosing between alternatives is generally an exercise in trade-offs. If you are consistent in your approach to making trade-offs, you can achieve more efficiency, more effectiveness and more value.

How?

There are a number of things that an Architect can use to drive consistency. One of the most powerful is establishing standards, documenting them and governing them. This means engaging stakeholders to ensure the right standards exist, and getting buy-in to following them. If you don't have buy-in, you'll be spending all of your time chasing non-conformance, and writing up exceptions.

How can it go wrong?

It's really easy to fall into the trap of establishing standards and then becoming an ivory tower governance structure. It's important to remember why we set standards, so it's easy to explain to our stakeholders when they should be following the standards (and also when it's ok to break with the standard.) It's also important to understand that standards are not set in stone. If you'd standardized on BlackBerry mobile development in 2007 (which might have seemed reasonable at the time) the world could easily have passed you by as you fought people who wanted to develop for iOS and Android.

Context

Why?

Individuals working in their own piece of a large enterprise often don't have the big picture view available to them. They will be driven by local metrics and local incentives to optimize on a small scale. This can lead to causing significant inefficiencies elsewhere. It's the job of Enterprise Architecture to ensure that decision makers are have their eye on the success of the whole enterprise.

How?

Understanding the integrated Enterprise Landscape (and the connective tissue between the parts of the Landscape) helps to identify second and third order effects that might not be obvious. Enterprise Architecture needs to provide the context surrounding any proposed change.

How can it go wrong?

Failing to provide the right context will lead to surprises once the changes are implemented. This can be as simple as one department solving their problem while introducing much bigger problems elsewhere, or as complex as leaving the enterprise in a broken state.

Collaboration

Why?

Fundamentally Enterprise Architecture needs to be concerned with helping the enterprise function better. This often means that compromise and local inefficiencies are required in order to ensure the most efficient overall system. Decisions are all about trade-offs, and negotiation.

How?

This is a lot more difficult to give a clear answer than the others. Primarily it's a bunch of soft skills - working with influence, helping people work together toward a common set of goals. Making sure there is enough transparency in what's happening that people aren't caught by surprise. This is a PR job as much as anything, making sure that everyone else can see the value in what's going on. Making sure that we're all pulling in the same direction.
I'll expand on this in a future post, but while people have often compared change in a large enterprise as similar to steering a large ship - slow to turn, slow to change - I view it as a bunch of ships of various sized and capabilities (hopefully) travelling in the same general direction, but at different speeds, some zigging and zagging, some plodding straight as an arrow. EA needs to keep those ships from running into each other, or running aground.

How can it go wrong?

If people aren't working together well, you can easily run into turf wars, competing projects working at cross purposes. Lots of wasted time, effort and money that could have been directed toward making things better.