This blog was originally written in 2014 for the Integrated EA Conference Site
I’ve been running this conference for quite a while now. I’ve been doing EA stuff for quite a while too. Penny (who really runs IEA) is very keen that I get off my backside and write some wise words for the conference blog. Well, here they are. I’m not certain that they are wise, but most of them are definitely words. My first attempt at an IEA blog turned out to be a fuming rant about methodologies. If I find a way to calm it down a bit, I’ll share it on this site at some point. For now though, I thought I’d share some of my experiences from all those years of harping on about EA. Hopefully it might help anyone starting out, if not it might at least start a debate.
FOR YOUR OWN SANITY, STAY AWAY FROM LINKED-IN DISCUSSION GROUPS
With the possible exceptions of the MODAF and Integrated EA groups (obviously), these discussions are truly awful. Imagine self-aggrandisement, paranoia, spite and bile expressed by people who believe they are legends in their own lifetimes. The vast majority of posts are either trying to sell you something (book, software, framework, methodology, services, etc). The rest are either posted by trolls or the unsuspecting goats that decided to walk over their bridge. Then you get the wars – usually between two “experts” but stirred up by troll fanclubs into threads that rumble on for months. The particularly nasty ones are easy to spot, as they’ll be about “which is the best framework ?” or “Is EA just large-scale IT architecture, or does it include business architecture too ?”. Cue onslaught of pointless debate. Then you get the ones about “How do I sell EA to my management ?”…
How do I sell EA to my Management ?
See what I did there ? I have a short answer to this, based on years of careful thought and observation. Don’t. Firstly, you’ll look like an idiot. Secondly, if you succeed in selling EA at a high level your project will fail. Counter-intuitive as it may seem, this is generally what happens. Folks decide that EA is a good thing and that it needs management “buy-in” if it’s going to succeed. The management, if they buy it, will throw resource at it because that’s generally all that they can do with something that sounds like it might be a good idea. What do you do when you get resources ? You build a team. Then you get that team doing good wholesome architecture stuff. They spend budget on tools and training. They architect the enterprise in excruciating detail over the next year. And what do you have at the end of it ? Some diagrams nobody understands apart from the team that created them. You spent a lot of money and delivered nothing of any use. All that happened is that you delayed looking like an idiot in front of the management. Except this time, instead of being the loon who tried a 5 min elevator pitch on the CEO and failed, you’re the person who just blew 2 million on drawing some pictures. Loons in lifts are easily forgotten. Budget bonfires tend to leave a lingering smell.
Now, imagine you didn’t sell it to the managers. Imagine you just tried to use some of the tools and techniques of EA to solve some of the problems you encounter on a daily basis. You had no budget for fancy tools or CV box-ticking certificates, you just started working a bit differently. Perhaps you started thinking outside the technology domain and considered how the users might want to work, or perhaps you decided to work with logical models to do your “what if ?” thinking. In my experience, this is where EA works. Not as a massive model of the whole business (bound to fail), but as just one of many analytical tools that engineers and business analysts can use in their day job.
EA as an Instrument of Business Change
To affect a business change, you have to change the behaviour of the people in that business. This is surprisingly hard to do, and drawing some pictures in an EA tool isn’t going to cut it. Management consultancies make billions out of selling business change (usually without any EA), but I’ve never seen a change programme that changes anything other than headcount. Endless process models are produced – and software is either tailored to the business process (which was dreamt up by a graduate “business analyst”) or the business processes are designed to fit around COTS processes – usually in an ERP system or some other dreadful basket-case “enterprise system” the consultancy is using as a vehicle to drive service revenue. Thing is though, nothing changes. People are remarkably resilient to business change. All that happens is that you spend a fortune replacing a legacy system with something less capable (but which runs on more modern hardware) or you drive your staff demented by expecting them to follow a byzantine process that is “off the shelf”.
“I mean, the joke about SAP has always been, it’s making 50s German manufacturing methodology, implemented in 1960s software technology, delivered to 1970-style manufacturing organizations, like it’s really — yeah, the incumbency — they are still the lingering hangover from the dot-com crash.”
Marc Andreessen, serial entrepreneur and venture capitalist talking to TechCrunch
In all my years of working in big change programmes and software delivery, the only time I’ve ever seen people change the way they work is when you present them with software that is SO GOOD and SO EASY TO USE that they just want to play with it. It’s all about user experience, and by that I don’t just mean pretty user interfaces (thought that is a factor too). Software has to be engaging and rewarding. It is often said that it is nearly impossible to get people to generate useful shared data in the workplace – they’ll just generate what they need for their own work. However, Facebook and Twitter get those same people generating huge amounts of data that is used by people they don’t even know to sell stuff to them they don’t even want. EA is all about people and technology – it is far better to put the architectural effort into human factors than it is to pretend you can change a business by drawing some BPMN diagrams.
We need a repository
You probably don’t. This is an early sign (usually about 3 months after the successful elevator pitch) that you’ve fallen into the <i>let’s model everything</i> pitfall. Your repository won’t result in one coherent model. It will result in lots of overlapping and inconsistent models that just happen to all be in the same bucket. If you get to the point where you hire an expert to come in and clean up your repository, you’re truly screwed. Time to get the CV up to date before someone smells the bonfire.
We’re all Enterprise Architects Now
Thanks mostly to TOGAF offering a qualification you can put on your CV, which can be obtained by taking a short course, everyone in IT now seems to be an enterprise architect. This is exacerbated by cautious (lazy?) HR departments who like to see certificates. The only people I’ve met who really exhibit the influencing skills and the breadth of business and technology knowledge that an EA should have would never dream of calling themselves Enterprise Architects. Just as I would caution against building a team to do enterprise architecture, I would caution you against calling yourself one. Just see it as something you do, not something you are. As I said before, it’s a way of thinking and a way of working that, amongst many others, helps you do your work more effectively.
Is SOA Making EA Redundant ?
No. Though, perhaps if people had indulged in a bit of EA thinking before the rush to SOA, it might have dawned on them that the company that was pushing it makes their revenue from hardware…
Is Cloud Making EA Redundant ?
Again, no, but I think it’s showing up big-scale EA projects for the wastes of money they can be. When your architecture can mutate, re-scale and be switched on or off in minutes, it becomes much more apparent that EA thinking – how people work with technology on an enterprise scale – is much more important than producing reams and reams of diagrams. Architectural principles and the interface between business and technology start to be the focus.
We’re doing Agile now, so we don’t need EA
Working for two weeks at a time then having meetings then working for two weeks again isn’t Agile – even if you’re daft enough to call them “sprints” and “scrums”. Read the Agile Manifesto and you’ll realise it’s about thinking differently, not slavishly following a methodology. In fact, it specifically encourages you not to follow one [2019 edit – take a look a Dan North’s blog on SWARMING]. Just like EA, it’s another tool in your kit bag. Oh yes, and “Agile” doesn’t mean you get to ignore the user requirements that look “a bit difficult”.
Recent Comments