Political Architecture part 2: Black ops

If you’d read my previous post (from a long time ago – sorry this follow-up is so late) on Enterprise Architecture in Political organisations you might be forgiven for thinking I disliked office politics. And I suppose I do. I guess this is because I’ve generally had an analytical mindset that wanted to optimise the obvious things. Want me to build a web server? I’ll try and make it return pages as fast as I can. Ask me to design a solution? It’ll be as cheap and effective at its stated aim as my skill can make it.

To be honest my approach is more than a little lacking in imagination. Of course the people I work with want these things, but after a certain point, no-one notices. Initially I was horrified that someone might give me a task either to keep me distracted or to act as a lever in some other process, and then my horror gradually mellowed into cynicism and, finally, acceptance.

And therein lies the story of my long slide into middle-aged mediocrity. Except that there’s another side to this. In the comments on my last post Mike Lamoureux commented that politics can act to show “who is passionate, and about what, you just have to read between the lines”. There are some other reasons why politics might also be good:

• it can ensure that a one-dimensional view of the enterprise doesn’t get railroaded through
• it can be a way for the brightest in the organisation to rise to the top
• it might be needed to provide for change that is blocked by formal systems of governance

(list adapted from Mintzberg 1998: 243-244)

As we previously noted, politics is everywhere. So if all Enterprise Architects have to deal with politics, and it isn’t all bad, what do we do with it?

I think this lies at the heart of many of the problems with modern EA practices. Those with more political savvy can bypass, leverage, ignore, or exploit an analytical architecture group in more ways than the group itself probably understands. It may seem unethical to someone with a purely analytical education – it certainly did to me – but that’s the way humans are.

It’s time to man up. As my colleague Carl Haggerty might say, lets do Black Ops.

I think that one of the things an EA team needs to decide at the outset of its practice is what its political goals are. Political EA means having a future state vision, not just of the shape and plumbing of an organisation but of how power flows through it and the desired position of EA in that power flow (if you don’t include yourself in the design, don’t complain that you’ve been sidelined – that’s what you wanted, yes?). In other words, we need to architect the power architecture as well as the delivery architecture.*

EA teams also need to manage stakeholders differently. Now the idea that communication is essential is not new for an EA team. But I think we haven’t gone far enough: we need to explicitly play some games to make our future state a reality. If our future state doesn’t make it, someone else’s will: and then we have stopped being the architects of the enterprise and we might as well go home or go back to coding or whatever it was we were doing before. So lets pick some winners early on and put our weight behind them. A covert prediction market might be a good way to identify those people who are rising in the organisation and those who are on the way out. Quietly aligning some EA artifacts with the ambitions of those rising stars is one way to accelerate our own influence.

Finally, we need some political strategies of our own if we are to get our (analytical) architectural projects through. I’ve noted some basic ideas in a previous post but these can be expanded and seem to fall into five categories (thanks again to the awesome Mr Mintzberg 1998: 244-246):

1. Accept and manage political realities. If one thing has no chance of getting through, request something else. Lets not bash our heads against the wall fighting battles we’ll never win.
2. Target middle management. Most resistance to any kinds of change will lie with middle management (and lower). These are the people you need to be actively managing to find out their sweet spots and pitching ideas at to ease their pain. (ISO27000 standards, for example, systematically do this by devolving risk ownership to middle management, thereby making these people change the behaviour of their staff)
3. Use classical political tools. Politics is the art of the possible. Focus on ends, not means: “good enough” results are sometimes good enough: increase management options by focusing on broad issues rather than sensitive narrow ones: anticipate problems and show how they might be dealt with (you may get your way even if you don’t get the credit!): anticipate what coalitions might form against your ideas, who might be in them and why.
4. Manage coalition behaviour. For example, change the order in which issues are addressed to make different coalitions form: increase the visibility of some issues to influence coalitions: unbundle some of the issues into smaller issues. We can adapt strategies to satisfy some coalitions but its easier not to (unintended consequences and all that).
5. Take direct action against a coalition. Pre-emptive coalitions, counter-coalitions, re-shuffling (or removing) coalition members in an organisation, co-opting coalition members, or increasing communication efforts all fall into this rather high-risk category.

There’s a lot more on this subject that a blog post can’t do justice to. I have yet to read any political theory, but am sure there’s a lot of stuff in there we might be able to use. But that’s for the future, I hope this post gives some practical stuff we can use now to get better outcomes for our organisations.

*One thing I’m missing is an actual reference architectural model for an architecture of politics. If anyone has any ideas how I could develop or steal one, please let me know in the comments. I promise I don’t bite!

Reference: Mintzberg, Ahlstrand, Lampel, “Strategy Safari” 1998 FT Prentice Hall

The discipline that dare not speak its name

Just over 3 years ago I was appointed to a position in my organisation called Enterprise Architect.  Naturally I researched the job before I interviewed for it, read the 50-page job description (I kid you not), bought a couple of books and read a metric shedload of internet articles and (since we were a client at that time) Gartner documentation.

I got a vague impression from all this that Enterprise Architecture was something that bridged the divide between business and technical people, that it was involved heavily with strategy, that there were a number of different competing frameworks involved, and that there was a high level of debate amongst practitioners with some people claiming to be the only ones in possession of  the One True Way of doing things.

In other words, par for the course. I had graduated through relentless discussions about what was really free software and what wasn’t, and I think I could cope with a few internet trolls. And surely as the discipline moved forward we would sort some of these issues out?

Seemingly not. And three years on from those heady days, the “enterprise architecture” team that I spent so long helping to try to form and drive forward along lines roughly similar to others in the industry and – most crucially – in a way that actually added value to my employer, is being de-scoped and effectively disbanded.

Initially this news was devastating to me, as I felt we were just about starting to get somewhere. But now I’ve just about settled with it and I’m starting to learn some lessons. Well, just one lesson really: and it’s one that I’m sure every enterprise architect, enterprise IT architect, technical architect or indeed anyone with an analytical nature who wants to succeed might do well to take on board: it doesn’t matter how clever you are.

We started strongly and soon had a very elegant programme for exploiting the organisation’s resources to drive higher productivity, better outcomes and lower costs. But no-one was interested. I now believe this wasn’t because people disagreed with it, it was because people didn’t understand it. And I think that has more to do with demographics than anything: there are still a large number of people at or near the tops of big organisations that have a blind spot when it comes to anything new: they can’t cope with big paradigm shifts and clever methods changing the way business is done.

So here are my four tips to anyone who calls themselves an Enterprise Architect:

1) By all means do the clever stuff. Analyse the current and future states of your organisation in its environment as well as you can. Use an expensive modelling tool or proprietary architecture framework if you must. But under no circumstances should anyone find out about it. Keep it under your hat. This work is just to ensure you have a good understanding of what the organisation has and what it’s trying to do so you don’t suggest anything stupid.

2) Break up the programme for reaching the future state into small chunks. And then break it up again. Projects that cost less than £100K at the very biggest. Less than £10k is ideal. Mainly though, they must be simple in concept and non-threatening in appearance. You aren’t re-engineering your financial payment processes: you are simply linking the website to your payments system. Because it makes common sense.

3) Build a business case for each project separately and gain business sponsorship, then get them through.  Sugar-coat each project with all the benefits you can find. Invest time and resources, if you have them, in ensuring they deliver what they say they will. Do the small stuff. Help people on the ground to implement and don’t compromise on quality.

4) Be clear about the services you provide. This is about how you work with people and the channels you use for delivering value: consulting on projects, providing and customising models, participating in governance and assurance, educating people about new developments, and doing research.

As for me, whatever role I find myself in in future, I think I’ll always be an enterprise architect. Even if I stay in IT I’ll still use these models and think this way.

Even if no-one I work with ever gets to hear about it.