The use of an IT Architecture can produce a number of benefits, but these will not be the same for all organizations. In one organization one of the potential benefits may be extremely valuable while other potential benefits may have little relevance; in another organization the situation may well be reversed. Having a clear focus on the benefits your organization hopes to realize can help you to plan how to expend scarce resources on your architectural efforts. That said, organizations often fail to anticipate potential benefits until they are actually well into the effort. Some work that may seem preliminary work of limited value to some - say mapping IT resources against programs being supported - may turn out to have great value down the road. So it isn’t usually wise to plan to skip whole areas of architecture just because you don’t immediately see the payoffs.

The eight benefits listed below are not intended to be inclusive, and could be described in different ways, but they may be of help in understanding the goals of an IT Architecture. The order of listing is random.

1. Development and Implementation of a Vision.

An architecture can be an effective tool for reviewing the overall current state of IT and to develop a vision of where the organization needs to or wants to go with IT in the future. By getting agreement on this, the organization can get people working in the same direction, make wider use of pilot project experiences, and ensure that procurements conform to this vision.

2. Development and Implementation of Principles.

An architecture is a tool to allow the organization to identify and distribute certain principles that should guide IT behavior in the organization. Without an architecture it is often difficult for the organization to come to agreement on basic principles and to make people aware of them. Without principles people may develop systems and make procurements than go against the organization’s objectives. There can be high-level agency-wide principles and more specific principles for particular areas of the architecture (e.g. certain software design tools to be used for a business area).

3. Identify Areas for Potential Cost Savings.

An architecture helps an organization to analyze its current IT and identify areas where changes could lead to cost savings. For instance, the architecture may show that multiple data base systems could be changed so only one product is used, reducing software and support costs. It may find that support costs could be reduced by standardizing on a limited number of desktop systems, reducing complexity. Analysis of the baseline architecture may show that other standards may be beneficial (on the other hand a good analysis can show when standards would not be beneficial and should be delayed or avoided). A key guide may be to look for ways to optimize internal and contract staff instead of technology per se - people cost more than most technology.

4. Enable Quicker Changes in IT Systems.

There is increased demand for systems to change quickly to meet rapidly evolving business needs, legislative requirements, etc. Planning for changes can be aided by having a clear picture of the affected system’s relationship to programs being supported, other areas of technology, and so on. For instance, you need to know how a system change will affect all users, and by having all this clearly identified in the architecture there is less chance of overlooking potential impact on smaller users. Models of the IT systems can help ensure that things like impact on network loads are properly considered when planning changes. An architecture can help to lay out complex situations in a clear and accessible manner, making planning easier and less prone to errors.

5. Help to Ensure Business Programs Drive IT Plans.

In some organizations an IT shop may run pretty much on its own with business processes being users of the system without a great deal of input to planned changes to the system. Some nightmare situations have resulted from cases like this. A proper architecture can help lay out the business processes as the primary drivers and refocus thinking along business lines.

6. Ensure That Things That Need to Work Together Do.

Everyone is aware of problems that occurred in the Armed Forces when different services could not communicate with each other in battle conditions because their technologies were incompatible. The problem isn’t one restricted to the military. Too often IT planning may be done at too local a level, not taking larger organizational needs into account. An architecture is an effective analytical tool for examining what systems need to communicate, exchange data, etc., and planning any changes necessary to ensure these needs are met.

7. Business Process Re-engineering.

It is a truism that if someone has just automated a paper process then they have not taken full advantage of the potential of IT. Really dramatic changes result from using IT to do work differently, and a consideration of IT needs to be part of any analysis of business processes. An architecture can again be an effective tool to help get an overview of data and work flow and how IT might enable new and more efficient ways of doing business.

8. Explaining IT System Needs and Benefits to Management and Budget Personnel.

An architecture can help to clearly show the connection between IT systems and requirements and the organization’s business processes and needs. This can help in obtaining support for the resources needed.