Why Enterprise Architecture?

A wise enterprise architect once worked for a very well-respected organization (name intentionally withheld). He was passionately engaged in a conversation with a senior executive about what direction the organization should take with its information systems. His recommendations fell on deaf ears until he asked the executive three very simple questions:

• How can we have a viable customer relationship management strategy when we do not even know where all of our customer's data reside?

• How does our technology spending equate to enabling our strategic business goals?

• Does our organization have an operational process model?

As you can surmise, the answers to these questions were not known. Many executives in information technology are not knowledgeable about what it takes to guide the architecture in the direction that results in the biggest bang for the buck. Sadly, many executives have lost control of the ship they steer, which has resulted in bloated infrastructures and conclusions being made on whims rather than on sound principle-based judgment and experience.

In many organizations, the annual budget cycle starts with clueless, disruptive questions such as "How many servers do we have?" or "Let's get the new Intel 3333 GHz machines as desktops." None of these statements is appropriate for a discussion about enterprise architecture. A good architecture addresses the following:

• The organization's business and information needs

• Leverage of the synergistic relationship between return on investment (ROI) and total cost of ownership (TCO)

• The ability to support migration from the current state (as-is)

• The ability to support easy migration to the organization's desired future state

• Ways to support the business objectives of reducing costs, improving operational service, and increasing revenue

Many organizations will claim to have an architect who creates architecture. Others will attempt to buy a nicely packaged architecture from one of the Big Five consulting firms without having a clue as to what they are getting. If your architecture does not address the following principles, you may be doing more harm than good:

• Data are separated from logic (business functions).

• The principles of modularity are observed by ensuring that each component within the enterprise architecture performs only one or two discrete tasks.

• Functions are separated into differentiated tasks that are generic and self-contained.

• The architecture is self-documenting. If it isn't, something is wrong.

  Figure P-1. Enterprise architecture model.

  

• All data and artifacts that are generated by an organization are managed and maintained by the same organization.

• The architecture is technically feasible and can be implemented at a reasonable cost within a reasonable time frame.

• The architecture is traceable from business requirement to technology implementation.

• Logical architecture is separated from physical architecture.