Architecture Domains

Within an EA Framework one can define various domains for further focus. Examples could be Business, Information, Data, Applications, Storage, Security, Networks, Disaster Recovery, etc. These domains could relate to one of the layers in an EA framework, but they could also span across all layers (e.g. Disaster Recovery concerns the enterprise from a Business level right through to an Infrastructure level).
It seems that not many enterprises have a central department that practises EA on all levels from Business to Infrastructure, e.g. Business Architecture is often executed in some business department removed from the IT department. We would like to hear from anyone where EA is practised centrally on all levels of the organisation.

Frameworks

It is useful to have a framework for organising and positioning all of the information about the enterprise’s business, information and technology, as well as different views on these. Many enterprises develop their own framework (e.g. the United States Department of Defence developed their own C4ISR Architecture Framework), but there are also industry standard frameworks such as the Zachman framework.
Frameworks typically distinguish among the various “layers” of architecture, e.g. business, information, applications and infrastructure. Regardless of what framework is used, it is preferable that the business layer views get attended to first, as these should drive the information, application and infrastructure views – not the other way around.
For a very basic example of a custom framework, see the accompanying diagram where the various layers of the EA are evident.

Definitions

EA is the process of aligning a business’s strategic vision with its information technology. In my view this process is never-ending, because the strategy of a business will continually change for the sake of survival, and because IT is forever changing. Alignment between Business and IT is twofold: IT must adapt to support changing Business objectives, and the Business must leverage changing technology to its benefit.
The activities associated with EA are therefore about creating and maintaining the views that illustrate what the enterprise’s business looks like, what its IT landscape looks like, and how these will be aligned at some point in the future. The remainder of EA activities are about addressing any gaps between Business and IT as time goes on.

Introduction

This EA Blog will have a dual purpose: Firstly to convey the basics of EA – that is, surface the essence of EA without all the blurb – and secondly to get your views of what EA means to you or your enterprise and which aspects of EA you apply successfully or find challenging. As the blog progresses and depending on where the interest lies, I might also cover other aspects of EA such as common mistakes, tools for EA, frameworks for EA and roles within EA.

At this point it would be interesting to hear comments on this introduction, e.g. what particular aspects of EA you expect to be covered here, how you think this Blog will best benefit readers or particular challenges this Blog might have.