What Is Architecture?

For the purposes of this book, architecture is a coherent, unified technology plan. IT architecture emphasizes a holistic framework of process, interactivity, and technology, intensely focused on achieving business goals and objectives. An IT architect is a person who designs and guides a technology plan that is coherent and unified. In other words, both the architecture and the architect provide direction for IT work. By concentrating on these essentials, an architecture-first approach endeavors to achieve results that can be implemented effectively, while minimizing artificial complexity.

A common example of the need for direction is articulated in a scene from Lewis Carroll's Alice's Adventures In Wonderland:

"Would you tell me, please, which way I ought to go from here?" asked Alice.

"That depends a good deal on where you want to get to," said the Cat.

"I don't much care where," said Alice.

"Then, it doesn't matter which way you go," said the Cat.

This example directly speaks to the need of an architecture-first approach for planning, building, and managing almost any business activity. So many companies are like Alice, trying to get somewhere without really knowing where they are trying to go.

At the heart of this architecture-first approach are the simple questions we can ask regarding any project:

• How did we get to this point?
• How do we know where we are going?
• Why are we going there?
• What tasks are necessary to get there?
• In what order should we do the tasks?
• How will we know when we have arrived?
• What else do we need to consider?

An architecture-first approach strives to answer these questions early in the life of a project, and to continually provide a reference guide throughout the project. Additionally, an architecture-first approach helps an organization strike the appropriate balance between:

• Business-driven requirements.
• Critical design decisions.
• Human-resource requirements over the life of the project.
• Financial impacts on the organization.

Making a Commitment to Architecture-First Design and Practice

Unfortunately, many organizations honor architecture, as well as project planning, in word but not in deed. Instead of developing a clear idea of where they want to go, they simply go everywhere, hoping that where they wind up will be better than where they currently are. Many senior managers, in fact, feel that the job won't get done if they take time to plan.

The only way to break out of this cycle is if all management within an organization makes a commitment to an architecture-first approach. This approach includes the simple concept that time spent designing and planning up-front will save time in the end.

NOTE

---

This commitment to planning does not mean that work cannot be started until the architecture is established. As we explain in this and succeeding chapters, we advocate a plan-while-building approach. In other words, planning, building, and managing constantly follow one another in an iterative fashion, often overlapping to some extent.

Being committed to architecture-first design and practice means that all three parts of the IT task—planning, building, and managing—are based on a coherent, higher-level architecture; that the architecture has been worked out before the start of the coding work; and that the architecture drives the work. Before this level of architecture can take place for an individual application, higher level architecture and planning must occur for the entire enterprise.

When an organization makes a commitment to architecture-first design and practice, the natural inclination of its IT department is to start at the beginning, designing an architecture for the entire enterprise. Enthusiasm is high, and the IT group thinks nothing is going to stop it from building a completely comprehensive document and then recreating the entire IT environment to match.

When the IT department takes a serious look at what is involved, though, they begin to have second thoughts. The project begins to look more and more daunting. Finally, they have to ask themselves, "Is there any way we can get a handle on this? And considering the work involved, why should we try?"

The majority of our book strives to answer the first question, so let's quickly address the second. Why should busy IT professionals spend the time necessary to design and implement an enterprise architecture? The answer is simple: Every organization has an enterprise architecture whether or not it is planned. The organization can assess and plan, or be a victim of a random enterprise architecture that doesn't necessarily meet its business needs. Only by doing the work involved in building an enterprise architecture can IT professionals gain some control.

Challenges of the IT Environment

Consider for a moment the challenges that characterize the business environment today. We face rapidly changing domestic and global market conditions, accompanied by diverse and complex products and services. Management expects shorter product development cycles and faster times-to-market. To remain competitive, we must continually learn to understand an increasingly complex technology environment. To deal with these challenges, organizations may respond with the following measures (see Figure 1.1):

• Streamlining business processes.
• Flattening organizational hierarchies.
• Introducing complex technologies at a rapid rate.

Figure 1.1 Organizational evolutions

As the pace of operational changes accelerates, information systems must be flexible enough to quickly support them. Consider what's expected of the typical IT organization in this new and rapidly changing environment:

• Dual focus It must be specific and intensely concentrated on the needs of users, while maintaining focus on the business vision.
• Flexibility It must be able to accommodate a constantly shifting technology landscape, at the same time coping with the pressure for "better, faster, cheaper—now!"

For the organization to remain competitive, the IT department must be responsive to changes in business and user requirements. They must be able to create applications quickly, and be able to modify them just as quickly. Flexible, incremental development methods that produce reusable code and reusable components are the key to an organization's success.

The challenge to most organizations is to respond quickly and incrementally to business needs at a relatively low financial cost. Whether an organization is trying to establish a competitive advantage by beating a competitor to market, to increase service levels and responsiveness to customer needs, or to deliver a less expensive product without sacrificing quality, IT plays a vital role. Key organizational functions such as product development, marketing, manufacturing, finance, and sales all require IT as an underlying foundation. These functions also require IT to seamlessly integrate and cooperate across the organization's functional or operational boundaries.

Additionally, organizations face enormously challenging application requirements. New applications are extremely demanding for a multitude of reasons, including:

• Broad distribution Applications may be distributed worldwide, via wide area networks (WANs) or the Internet.
• Broad user base There are potentially millions of users for these applications. In many cases, these users will be unknown to and outside the control of the company's IT organization.
• Connection limitations Connections between users and applications might be temporary or of limited bandwidth. For example, employees might use portable computers that are connected to the corporate network only part of the time. Customers might connect to the application via the Internet over a low-speed modem.
• Storage limitations Data required by applications might be stored on multiple computers. These computers might be geographically dispersed and might not be available at all times.
• Hardware limitations Existing hardware and software investments must be leveraged. Users might have different types of computers with differing capabilities. Data might be stored in different types of databases. New applications might need to interact with existing applications running on different platforms.

Add all these factors together, along with the number of systems in the environment, and anyone would agree that distributed application development is just plain hard. The combination of business problems, technology evolution, and the organization's existing complex applications drives a consistent set of key concerns for senior IT professionals. We can sum up these concerns as three imperatives:

• Deliver business value Tightly align IT to business objectives.
• Control costs Squeeze every ounce of leverage from existing IT investments and make careful and informed future investments.
• Sense and respond Improve the cross-functional capabilities within the organization and extend those capabilities outside the organization to reach customers, suppliers, and partners more effectively.

How Enterprise Architecture Responds to IT Challenges

Technology implementation can either accelerate or impede an organization's ability to adapt to changing business conditions. Today's IT solutions must fully meet business requirements, be sufficiently flexible to integrate new and emerging technologies, and yet not compromise the functionality and daily operations of the existing enterprise architecture. With these concepts in mind, any approach to enterprise architecture should:

• Place first priority on addressing business needs.
• Provide a technical solution that focuses on making the simple things easy and the hard things possible and cost-effective.
• Deliver the flexibility required to adapt to the natural evolution of technology and business.

A key factor in achieving these goals is to establish a comprehensive, high-level enterprise architecture. The enterprise architecture provides the framework for an ongoing process of discovery and refinement. This process is implemented as a series of projects geared towards getting the entire organization's IT infrastructure and application systems to their desired future state. This approach creates a strong framework for aligning IT strategy and day-to-day activities with the overall business strategy.

Goal of Enterprise Architecture

As we noted in the opening discussion about architecture, providing a direction or goal is an important part of the architecture task. The goal when developing an enterprise architecture is:

To provide a logically consistent plan of activities and coordinated projects that guide the progression of an organization's application systems and infrastructure. The plan should move incrementally from the current state to a desired future state based on current and projected business objectives and processes.

Let's examine this goal in more detail:

• Logically consistent When two or more parts of the architecture are compared, they fit together logically.
• Activities and coordinated projects The architecture addresses both ongoing activities and stand-alone projects.
• Progression from current state to desired future state The architecture does more than simply describe the current situation. It also offers a vision of the desired future situation. Most importantly, the architecture articulates a clear path to get from the current situation to the desired situation through versioned releases.
• Current and projected business objectives and processes An enterprise architecture plan is ultimately worthless if it is not built upon both the current business situation and the projected business plan and processes. It is possible, however, for the business plan to be shaped by developments in the IT arena, such as global Internet access, which is driving the creation of electronic commerce divisions within companies.

It is important to remember these points while considering the details of enterprise architecture in the rest of this chapter. It's also important to use these points to analyze the completeness of any enterprise architecture plan.