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:
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:
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.
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.
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):
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:
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:
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:
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:
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.
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:
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.