All posts by ian

Monkeys at Typewriters Painting the Forth Bridge

Ian Bailey

Lets imagine there was once a very big EA project that involved lots of people modelling lots of things, in lots of depth, with no particular goals in mind, and in an environment where the things they were modelling were constantly changing. Under these circumstances, you’ve got “Monkeys at typewriters, painting the Forth Bridge” – a term I once heard used to describe enterprise architecture. I think it aptly describes a number of EA projects across various industries. Every bank, telco and defence organisation has had one of these, and most of them happened around the early 2000s.

I’d like to think that no-one does EA that way any more, certainly not at that scale. However, for the last couple of years various blogs and and LinkedIn posts have been mourning (or celebrating) the demise of Enterprise Architecture. There are plenty of these blogs out there, and while they all share a common theme, they don’t often agree on what the cause is. Some think the EA frameworks are bloated and overly complex – which is probably true, but it seems a somewhat churlish explanation for failing EA. Some think it’s all to do with IT taking over the discipline and ignoring the business aspects. Again, I think there’s an element of truth to this, but systems architecture seems to be alive and well, so why would it fail if you just happen to call it “enterprise architecture” ? Some like to blame the tools. Others argue that EA fails when you try to align business and IT, because that’s just not possible. I’d argue it’s difficult, but it’s not impossible.

So, why have so many EA projects failed ?  Well, I’m not sure that many have failed, and a lot of the blogs I’ve been reading seem to emphasise failures so they can sell their own particular brand of snake-oil EA that will definitely not fail. Probably.

Anyways, failing or not, dead or alive, I can’t help thinking the ones that failed did so because of the people involved. Not the individuals, but the combination of their personalities and approaches. There are a few organisational antipatterns that sometimes emerge when you get too many people of a certain personality type in the EA team.

The Men in the High Tower

OK, so they’re not all men, but the really bad ones are usually male.  This is the corporate EA function. A collection of beard-stroking (told you they were men) intellectuals who set policy and guidance for all architectures in the organisation. They like to argue – often amongst themselves, but usually with project/programme architects. They tend to be somewhat detached from reality and don’t have much experience of actually building anything. I’ve encountered a few of these units over the years, and they seem to  consist of highly paid, bright people who’ve somehow managed to become architects without ever having done anything else. They are universally loathed by the coders and solution architects they dictate to. They are also made of teflon. No matter how stupid their decisions, and how obvious the link from those decisions to project overruns, they never get the blame. Some poor sucker in the project always has to take it on the chin.



These guys love to dig. No problem is too small enough, no architecture is complete until it’s modelled the enterprise at a subatomic scale. They will spend every ounce of project budget modelling an as-is architecture that the project is intended to replace. This is sometimes called “analysis paralysis” and I’ve seen it more times than I care to think about. If you get enough of this personality type on a project (or even just one, in a leadership position) you’re in for a very expensive ride.

Steve Jobs, without the talent

These are very single minded individuals, so sure of their ideas, and so persuasive they get to bulldoze them past all technical objections. They’re great at persuading management, and they’re all about their ideas. Unfortunately, their ideas are often rubbish. That doesn’t seem to stop them though. Steve Jobs was said to have unbelievable tenacity and bullheadedness. He also had good judgement though, and he paid attention to the details. There aren’t that many people like that out there, only ones who think they are.

The Voice of the Business 

These are the user’s friends, there to defend what the user wants against those horrible naysaying techies !  Or are they ?  Maybe they just heard something in a user requirements session and wrote it down ? Maybe they thought it was a bit weird, but didn’t want to challenge the requirement because “the customer’s always right” ?

OK, so I’ve make up some really horrible caricature stereotypes, and emphasised some of their worse points.  But, nobody’s perfect, and my point is more that if you have an EA team made up of predominately one of these groups you’ve got trouble. Ideally you’d like a good mix of all those people, ready to challenge each other and get a balanced design that solves the business problem with affordable, reliable technology. You need the beard strokers to set policy, scan the horizon and specify the logical architecture. You need minecrafters to dig into some of the architectural problem areas, but you don’t want them doing deep dives on everything. You need the vision people with the ability to sell the ideas (not always their own ideas) to sceptical management, and you need good business analysts who are part of the design team rather than agents for a customer they don’t really understand.

If you don’t have all of those aspects, the EA function / project will be in trouble. Without the vision and salesmanship, the architecture will be ignored. Without the business analysis, the architecture will miss the point. Without the diggers, significant problems will be overlooked and workarounds will be needed. Without the beards, the architecture will be just business as usual. You need a balanced EA team. The projects I’ve seen fail over the years didn’t have that.

If you’ve got a lot of minecrafters with strong leadership, but you lack vision about what the goal is, or what the customer wants, then you’ve got a problem. Add a big budget to that, and you just might attain the holy grail of EA dysfunction –  monkeys at typewriters painting the Forth Bridge.



A Farewell to MODAF

Ian Bailey (@MonkeyChap)

As you will no doubt be aware, MOD plans to end its support for MODAF in favour of the new version of the NATO Architecture Framework (the acronymically challenged “NAF”). MOD has been very active in the development of NAF v4, sponsoring Team Ensure (including me !) to develop the standard based on existing NAF and MODAF documentation. It now seems that NAF will be a NATO STANAG, which is good news in many ways but does mean the process is slow.

Although MODAF isn’t gone yet, I thought now would be a good time to reflect on what we did as this is probably the last IEA Conference in MODAF’s life. IEA was established with the express purpose of starting a community of MODAF users. I think we did this, and what’s more I think we went further. The IEA community goes way beyond MODAF users, but I think everyone involved has a common view that taking a holistic view to business and technology, although difficult, is worth the effort.

MODAF itself, despite having many detractors, has thrived. It may not be as well known as DoDAF, Zachman or TOGAF, but its influence has been significant. It introduced capability modelling before any of the business journals started rabbiting on about it, and long before the other architecture frameworks adopted the approach. It had a formal meta-model when none of the others did. And that meta-model, M3, has gone on to be used in UPDM (90% identical to M3) which it now seems is the US DoD’s favoured approach. MODAF spawned TRAK, which was free of the legacy user base MODAF had, and so was able to do a lot of things we’d been trying to do in MODAF for a long time. NAF, from v3 onwards has been based on MODAF, and most NAF users still use the MODAF documentation when developing their frameworks. Even DoDAF saw fit to adopt the MODAF capability and strategic views. Oh yeah, GCHQ and NATS use it too. Despite all this, MOD never really seemed to know what to do with its little success story, and MODAF really only survived because the sheer enthusiasm of its users.

MODAF had a tough birth. It came into existence with the purpose of extending the DoDAF specification to support the MOD acquisition approach. The work began just as MOD was fighting two expensive conflicts in far-flung locations. Funding was always tight, and priorities were always elsewhere. Inevitably, MODAF v1 was a compromise, but many of the problems were fixed in v1.1.

In the ten years MODAF has been around, I’ve seen MOD’s attitude to architecture change drastically. Initially, there was immense push-back from the military, and cash-strapped IPTs saw it as just another box-ticking exercise to waste their time. Some early projects spent large amounts of money, enthusiastically trying to model the world only to find the world had spun around since they started the modelling. After a number of failures, there was a time when it seemed no-one would ever consider architecture again. Throughout all this though, there was a cadre of individuals who kept it going, and by applying architecture approach sparingly and sensibly, started to make a difference. I’m pleased to say they were nearly all IEA regulars. I don’t think anyone in their right mind would try to procure a complex system today without some sort of architecture, but back in 2005 few if any were architected.

Looking to the future, I’m really pleased with NAF v4. My hopes for it being a website-based standard that could adapt quickly to changing requirements have been somewhat dashed by the requirement for a STANAG, but you can’t have it all, and the clout that a STANAG brings will more than make up for it. I’m still jealous of the freedom Nic had when he developed TRAK, and I still like the idea of an open-source framework.

MODAF was the work of many people over the years. Working with them has been thoroughly enjoyable, frequently stressful, and often humbling. There were some truly spectacular technical arguments, and some fantastically talented people involved (those two things tend to go together). Architects like an argument. People who architect architecture frameworks are able to bootstrap an argument out of thin air. I don’t ever recall a pointless argument though – every one of them was driven by a passion to build something that was right. I think NAF v4 is going to be better than MODAF ever was. They just need to do something about that acronym…

Keith Hasteley of MOD ISS will be at IEA to talk about NAF v4. I hope to see you all there.

There’s Madness in your Method

I wrote this last year, prompted by Penny asking me write something for the website that might get people talking. After I wrote it, I thought it was more likely to annoy than stir up debate. However, @martinfowler just wrote this, which I liked, probably because he’s better at presenting a coherent case than I am. Here’s my attempt…

As a consultant, I tend to have adapt to the customers’ ways of working.   Sometimes that even means I have learn something new. I had been considering going on a TOGAF course for a number of years now. Fear of getting into a public argument with the trainer over something pedantic like a meta-model issue or the exact meaning of “Service” has always prevented me though. Over the last few years, I have found myself working amongst TOGAF qualified architects, and it is this what is worrying me.

I’ve always had a bit of a problem with methods. Maybe it’s an aversion to being told what to do, or just a misplaced, egotistical belief that I probably know better. Either way, methodologies suck. Big time. They all look logical enough, and they’re hard to pick fault with because they’re based on best practice and the collected wisdom of experts in their field. Collected wisdom, renowned experts and logic have never stopped me having a pop at something I don’t like though, even if I can’t rationally explain why I don’t like it.

Firstly, completing a course and ticking the right multiple choice options doesn’t mean you know what you’re doing. Government and industry are littered with MSP and PRINCE2 qualified contractors. Many of them are clearly in the wrong job and some are utterly incompetent – evidenced by the eye-popping number of failed programmes and cost overruns. We’ve all met them, and we’ve all wondered how they manage to even dress themselves in the morning, never mind find their way to work. I wonder if Google pay their PMs four times what they pay their best coders ? Actually, I wonder if Google have ten times as many managers as they do coders on their software projects ?

Secondly, I’d rather have one person who can think for themselves than five people who are following a methodology. Zombies at typewriters aren’t going to produce the complete works of Shakespeare. They might well come up with a new methodology though, and the accompanying manual (with sample exam questions) will probably sell more copies than King Lear.

Thirdly, it lets HR off the hook, and if there’s a bunch of people in the organisation who you should never, ever let off the hook, it’s HR. They will always take the path of least resistance in finding candidates, and their natural tendency to cover their own arses means they’ll always choose candidates with a certificate of some sort no matter how experienced they aren’t.

Fourthly, these methodologies always seem to duck the difficult bits. They’re much more likely to tell you how to run an architecture / development / engineering team than tell you how to build something useful.

Finally, I think methodologies hurt the trades they are supposed to serve. The certification schemes are highly profitable, and it is not unusual for hundreds of candidates to go through them every year. This floods the employment market with a wide spectrum of abilities all concealed under a common qualification. Couple that with HR’s love of certificates and you get huge numbers of people working in roles they are unable perform. That hurts everyone. It tars the able practitioners with the same brush. It blots the career of people who have tried to take on too much without enough experience. And, it diminishes the reputation of the trade as a whole.


EA Pitfalls

Ian Bailey, Model Futures

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.

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 let’s model everything 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. 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”.