Enterprise Architecture : An Introduction

The practice of enterprise architecture (EA) is to support the business decision making process by providng information about complex organizations' structures, their functions, and technology supports requirment for accomplishment of that functions. Considering EA as an IT job only will not be fair because it is far broader than that.It must be considered that, in most cases, increasing complexity in IT drives the need for adopting EA.
EA is the model that helps in identification of relationships between the business and technology in such a way that key dependencies are exposed from the underlying complexity and so can be used to support decisions. E.g. by ascertaining which business processes are supported by a given software application, and then which platform the application runs on, it is possible to calculate the impact on the business of hardware obsolescence. From the same model, it would also be possible to examine, the cost of replacing the application, or which processes could be best re-designed to reduce the IT portfolio. When other dimensions are introduced such as data models, organizational structure and standards, questions which initially appear impossibly convoluted can be answered, provided the dependencies between domains are all known. The information that is used to inform an EA can often be obtained from the appropriate departments of the organization (though the information can vary in quality). For example, the IT department will probably have a reasonable model of the application deployment throughout the organization, HR will probably maintain an organization structure, and the ubiquitous management consultants will have modelled the organization’s processes at least a dozen times.
Clearly, the task of assembling the information for analysis of an enterprise of any significant scale is not going to be easy. For this reason, EA is never undertaken without first having a question (or preferably a set of questions) whose answer would provide sufficient business benefit to justify the cost of analysis. EA is not an audit exercise, it is a decision support process. And, once one has gone to the trouble of producing a model on an enterprise scale, it is usually more economic to maintain it than let it “go stale” and have to conduct the whole analysis again next time a question is asked.
It is worth clarifying that “enterprise” usually does not mean
“corporate-wide”. The scale of the enterprise architecture is decided by the boundaries set by the analysis – it could be a department, a project, a team, or a government of a country.
Enterprise Architecture closes the gap between business and IT. It provides a way for management to understand the consequences of their decisions and allows simple questions to be asked aboutcomplex organizations. It is difficult to measure specific cost benefits of an EA approach, but figures are starting to emerge that show how IT disasters can be averted by closing the gap between business and IT.
EA is not an IT discipline - a good Enterprise Architect possesses a rare fusion of business, technical and communication skills, Great care should be taken in selecting a candidate to fill an EA role, and the higher levels of management should be fully behind the architect, especially as the EA programme is starting up.As the EA market grows, there have been an increasing number of modelling tools and repositories designed (or adapted) to serve the enterprise architect. Some of these tools can offer great benefits in terms of architecture re-use and ability to query the architectural model. A great deal of thought must be put into the configuration of these tools, as re-configuration can be costly when there is a large back-catalogue of architectural data.

Comments

Popular posts from this blog

23 Tips to Speed Up your Windows XP Performance

Potential problems in implementing Business Intelligence

How to uninstall McAfee Security Center from your System