A common word in each of the individual components above is architecture. In this context, an architecture is merely “a set of shared definitions and constraints that are expected to effect a time, cost or risk reduction in future application development or operations" (Gartner - One IT Architecture...). The concept of an architecture is then applied to individual components of a company’s IT infrastructure, or taken all together, covering the entire enterprise. Each of the components mentioned above complement each other to form a common goal – effective and efficient IS planning (Willcocks 342).
A corporation of any size is going to spend a considerable amount of energy preparing a strategic plan for their business. Corporate strategic planning is where a corporation takes their current business environment and decides where they want to be in the future. They then construct a strategic plan on how to get from the current to the future state. A very analogous process can be applied to Information Technology – where the current infrastructure is examined, then the desired future architecture is laid out based on both the business plans as well as what is known about future technology. A set of projects is then constructed to achieve this goal. It is important that both business needs and technical needs are considered. Upgrades, replacements and improvements can’t be performed for technology’s sake unless there is a business need for it. Conversely, it wouldn’t make a lot of sense to built complex business processes on top of obsolete information technology infrastructure (Hoffer 141-146).
Traditionally, problems are identified and a project is initiated to solve that particular problem. A planning-based approach looks further into the future and seeks to find a solution to the problem both as it exists today and into the future. This is particularly important for projects that span multiple departments or business units in an organization or many organizations. Also, as IT costs are becoming a larger and larger piece of the budget, the cost of an IT “mistake” is more closely scrutinized. Internet and E-commerce applications and their associated technology are rapidly growing. An organization may outgrow a specific solution but a strategy is more long term (Hoffer 141-146). Granted, there are times when a tactical, short-term solution is the best approach to address a very specific, immediate need. However, it must be pointed out to the business leaders that this is the approach being taken, and the short term gains may be offset by future support costs, conversion costs, or other implications of not working within a well-defined strategy.
Building an IT strategy based on a specific architecture can be considered a good investment – spend the time today for a payoff in the future. Or it could be considered a risky “bet.” Whether or not it is considered a “bet” or an “investment” relies on the level of predictability of the environment. A limitation of an architecture is that it relies on being able to predict the business needs into the future, and the basics of the technical needs. For example, it is probably a pretty safe bet that a company is going to want to share files and printers well into the future. They are also going to be able to want to communicate effectively with their suppliers and retailers. If the exact technical requirements (of these business requirements) were known, then all that is needed is a design, not an architecture. However, the architecture is going to describe these requirements at a higher level - such as the type of programming languages (e.g. object oriented) or Intel hardware (vs. Sun). However, the less certain about the future environment, the shorter the life span of the architecture and it will have a more narrow scope. In highly volatile environments, maybe the architecture is only good for a year or two, but constantly revised each year for the next two (Gartner - One IT Architecture...).
Using the term "strategy", especially when discussing the development of an Enterprise Architecture, can be confusing. A strategy and an architecture are relatively analogous terms. However, an architecture is often thought more of as a static picture that you draw on the wall. A strategy is more like putting the architecture into motion, defining not only what is to be accomplished, but how it is going to be accomplished (Boar 188).
IT architecture is analogous to a homeowner discussing high level plans for a house with an architect. After the plans are made, the architect or the builder (designer) can make tactical changes later on to meet other requirements, but the overall framework will stay the same (Cook XX). The same thing applies to IT. An Enterprise Architecture is a high level planning guide for building the infrastructure out. It has to be flexible enough, however, to accept minor changes on down the road. Another equally useful analogy is that an Enterprise Architecture is a map that shows where you are and where you want to go - with a rough idea of how to get there.
