Enterprise Architecture: Fish or Fowl?

After over a decade in Enterprise Architecture, David Dornbrack finds it both confounding and fascinating, because it’s not an exact science.



I come from an engineering background so, when I first got involved in Enterprise Architecture (EA) over a decade ago, I didn’t quite know what to make of it. The whole concept confused me and I found it difficult to see value. Since then, I’ve seen EA operating at various ends of a broad spectrum – which leads me to conclude that it’s more a case of ‘shades’ (or horses for courses) rather than black or white.

What is Enterprise Architecture anyway?

For large enterprises with complex and ever-evolving IT systems, EA provides a framework for new initiatives. The discipline cuts across a broad scope, delivering blueprints for the adoption and deployment of refined business services, often supported by additional technology platforms – in other words, planting goalposts to help target the design of each new project.

Irrespective of which domain EA touches, it is intended to reduce complexity, eliminate conflicts, and make it easier to deliver new projects faster without prolonged compatibility and integration testing. The ultimate benefits of well-executed EA derive from better planning, earlier visibility and more informed designs.

That’s all well and good, but in the real world, approaches vary.

EA can be used across many disciplines including Business, Information & Application and Technology. Unfortunately in too many cases the Business dimension is glossed over, and the focus is on Technology. However, what has interested me the most is that I have seen EA applied at opposite extremes of the spectrum, with varying degrees of success.

Extreme Example #1: The Scattergun Approach

Consider a large enterprise with a culture of exploiting technology to get to market fast. While paying lip service to traditional EA, it completely ignores ‘good’ EA practices. The guiding principle is: “Go ahead, get your project across the line and don’t worry about the overarching architecture.”

The result will be multiple non-compatible solutions. When the solution doesn’t work within the overall IT environment, these organisations sometimes even throw the solution out and develop yet another, again ignoring EA guidelines: doubling their effort and still failing to deliver an integrated and lasting application.

An example I encountered during an audit of an organisation like this was the deployment of over six different tokenisation systems. Under a strict EA regime, there would have been one. The consequence was that these different systems were bumping into each other – creating complexity and (presumably) customer and staff inconvenience.

That said, these organisations are often highly successful in terms of innovative customer services and products, delivering high returns to their shareholders. But they could benefit by setting some architectural tenets in place to prevent integration issues, costly back-flips and system re-design down the road.

Extreme Example #2: The Pure EA Approach

I’ve also worked with a large government enterprise that employed over 50 Enterprise Architects whose rule was ‘law’. In their theoretical world, no project or change would be delivered until all the dependencies lined up. They had fully documented the EA but it was difficult to follow and, worse, there was no measurement of value.

Deviations from the EA were a sackable offence but, because ‘the world won’t wait’ there was an exceptions process. In practice, this meant that teams developing new projects would continuously request exemptions, which were typically denied right up until the last desperate week of the project, when anything up to 50 would be allowed. This created a massive ‘architecture debt’ – which should theoretically have been ‘repaid’ – but no-one was tracking these exceptions and there was no ongoing process to address them.

So what are the issues?

EA is certainly critically important – but the real world is somewhere in between the ‘never mind the consequences’ scattergun method and a rigid, purist model. In my experience, and after much pondering of the various scenarios I’ve encountered, I’ve recognised three important considerations in developing the best approach:

  1. Metrics: The benefits of EA are rarely measured because it seems too hard. Unless you set some metrics in place – and follow up by actually tracking the results – your EA function will either become an overbearing dictator or a paper tiger, neither of which are ideal.
  2. Culture: EA purists tend to fall into the non-profit camp, while the scattergun approach to EA is more likely to exist in competitive sectors. I’ve also found that the attitude of the CIO is a huge factor in forming an enterprise’s EA approach. Aggressive CIOs just want their teams to get things done when and as the business needs it, while others take a more ‘softly, softly’ and considered stance on the overall benefits of an integrated IT environment.
  3. Standards: There are few accepted standards for EA as yet. The Australian Government Architecture (AGA) which “aims to assist in the delivery of more consistent and cohesive service to citizens and support the more cost-effective delivery of ICT services” hasn’t been widely adopted by government agencies, let alone commercial enterprises. In the USA, agencies receive no government funding unless they demonstrate that they have an EA function in place – but we’re nowhere near that here yet.

The Ideal Situation

I’ve reluctantly come to the realisation that there is no ideal situation for EA. But if there was, it would fall between the two extreme examples I’ve provided above.

EA purists live in a ‘cone of silence’ – believing the world is perfect outside their bubble. The reality is that IT architecture compromises are necessarily made for expediency. But those compromises often also compromise project success; through cost overruns, incompatibility with co-existing systems or just by unnecessarily adding to the complexity of (and cost of supporting) the entire enterprise ecosystem.

The ideal EA function puts effort into defining components, which then makes it quicker and less costly to respond to new opportunities. But, given the ever-changing nature of technology and market demands, it is a relentless pursuit that should remain agile, responsive and never become too prescriptive or restrictive.

I’d like to hear your views and experiences with EA to see where others sit on the EA spectrum.

About the Author

David Dornbrack leads our ICT security programs and strategic governance service offerings. With secret security clearance, he consults to both Government and private sector clients in Australia. David also delivers information security training and provides specialist advice in leading organisations through ISO27001 certification.

Prior to his career in Enterprise Architecture and IT Security, David served in the South African Army as a research scientist for the National Institute of Defence Research and as a software engineering programmer for General Electric.