Section 1.1. Who is this book for?

1.1. Who is this book for?

ESA should be of primary concern to anyone charged with making IT support a business. The intended audience of this book includes:

Enterprise architects

Those involved in looking at the whole company from an architecture perspective.

Business analysts

Those who look at different business processes to assess the best way to run them.

Senior executives

Those who rely on IT to support their business and need to know what is expected of their IT departments, enterprise architects, and business analysts.

Developers and engineers

Those who will have new roles in this new world and will need to learn the new skills they will require.

This list is a broad umbrella that encompasses a range of responsibilities from reducing total cost of ownership (TCO) to decreasing development time to choosing new platforms and development methodologies. This wide perspective matches almost exactly the domain of ESA shown in Figure 1-1.

Figure 1-1. Three perspectives on ESA

What distinguishes ESA from all other approaches to SOA is that ESA explains how the business, application, and technology should be organized to produce maximum value. The business strategy and process design, the application architectures, and the way technology supports applications are synchronized in relation to enterprise services. Figure 1-1 is an accurate oversimplification, but as our explanation proceeds, it will become clear that a unified approach to designing services is the first step. From that first step flows the ability to create a unified process model, a unified information model, and a unified approach to building UIs. All of these things combined comprise the engine of value that makes new innovations possible based on existing systems of record.

Synchronizing business strategy and technological applications through enterprise services has two enormous advantages. First, the business architecture is defined by exactly those processes that are supported by enterprise services. Second, this synchronization brings business executives, analysts, and technologists onto the same playing field as application experts and engineers. Each group has clearly defined responsibilities. Business analysts define and modify processes and UIs using modeling and simplified tools based on services. Technologists build services and tools based on services for use by business analysts. Each group manages its own domain of complexity and can talk about enterprise services from its own perspective. The conversation is structured. Business analysts request services and UIs when they are missing and then modify them from there. Technologists provide these services. The communication disconnect that plagues business and IT is conquered by a form of information hiding in which each side has its own domain, and communication is structured. Improved communication may be the most profoundly valuable contribution ESA can make.