Chapter 1. The IT World Is Evolving
From Systems to Processes
Business pressures are changing the way things are done in the IT world. The system-centric design focus of the past (Figure 1-1) is no longer sufficient for today’s projects. The reason for this is that a narrow focus on individual systems leads to a proliferation of point-to-point interfaces. They are so specific in terms of implementation technology and information content that they are unusable in any other context. The resulting rat’s nest of dedicated interfaces is brittle and expensive to maintain. It impedes the enterprise’s ability to respond to changing business conditions.
Figure 1-1. System-Centric Design Focus
Service-oriented architecture (SOA) is based on the design concept that functionality can be packaged and made accessible in a way that allows common capabilities to be implemented once and shared widely. Most services end up being wrappers around functionality that already resides in one or more existing systems. The service provides access to this functionality in a platform-neutral manner, thus facilitating the usability of the service.
Conceptualizing suitable services, however, requires an expanded design focus (Figure 1-2). Consideration of the service users as well as the service providers is required to ensure that the functionality is conveniently usable. Conceptualizing the service operations requires thinking about the capabilities of the systems providing the functionality and the needs of the systems utilizing the functionality. A failure to take the consumer needs into account yields services that are not well suited to the consumer. Such failures negate all of the potential SOA benefits.
Figure 1-2. Service-Centric Design Focus
Improving the business often requires optimizing a collaborative business process (Figure 1-3). In these processes the actual structure of the business process is not explicitly represented—it is implicit in the pattern of communications between the process participants. For example, the implicit process shown in Figure 1-3 starts when a user interface action invokes a service provided by System A, which invokes a service provided by System B, which ultimately invokes a service provided by System C. Improving such processes requires a design focus that encompasses all of the process participants and their interactions.
Figure 1-3. Collaborative Business Process Design Focus
Business process management (BPM) seeks to further improve a business process through its explicit management (Figure 1-4). In contrast with collaborative business processes, a managed business process requires an explicit representation of the business process and the resources required to execute the process. The process manager then manages the process through a series of interactions with the process participants, generally some combination of both people and systems. This type of project requires a design focus that encompasses the process definition, the process manager, and all of the process participants.
Figure 1-4. Managed Business Process Design Focus
What these examples illustrate is that the focus of IT projects is evolving away from system-centric design toward process-centric design. This shift certainly makes sense from the perspective of business-IT alignment since business process improvements are what bring value to the enterprise. Process definitions provide the tangible connection between the business and IT. Whether a process defines an unmanaged collaboration or a managed orchestration, it precisely identifies the participants (both people and systems) and defines their required interactions. This perspective thus defines the requirements for each participant while ensuring that these requirements, collectively, provide business value.
Many business processes will extend beyond the boundaries of the enterprise to include customers, business partners, and regulatory agencies. These processes define the role of your enterprise in the larger ecosystem in which it participates. They define the interactions between your enterprise and external entities and, in so doing, define the requirements for external-facing system interfaces.
Whether processes are fully contained within the enterprise or extend beyond its borders, it is the process perspective that is required to conduct today’s IT projects and keep them focused on delivering business value. But who assembles this perspective and relates it to the systems that are involved? The answer is the architect.
Architecture and Architects
When a design involves two or more participants (whether systems or organizations), the processes that define the required participants and their collaboration must be rationalized. The product of this effort is the solution architecture, and the responsibility for producing it belongs to the architect.
What actually comprises an architecture will be discussed in the chapters that follow, but for now we simply make an observation: It is amazing how infrequently projects consciously define their architectures. Ask yourself: Is there is anybody on your project team whose responsibility it is to define the business processes and identify the participants and their interactions? Does anybody evaluate this architecture in terms of its suitability for the task at hand? But before you answer these questions, take a look at the next few chapters to understand what we mean by architecture—you may be a bit surprised.
If the answer is no, then nobody is responsible for the overall architecture. Often you end up with an accidental architecture, the result of an accumulation of system-centric design decisions. This is the source of the chewing-gum-and-bailing-wire collection of systems that result in high IT maintenance costs and lengthy development projects.
The alternative, a well-considered architecture, is not just nice to have. As we shall see in Chapter 5, spending time on architecture consistently leads to shorter project durations—shorter by as much as 25%. You literally can’t afford to ignore architecture.
There is, however, a challenge. Individual projects rarely (if ever) implement complete architectures. Instead, each project implements or modifies only a fragment of the enterprise architecture. It takes the accumulated results of multiple projects to realize the enterprise architecture.
Two distinct architecture roles emerge from this challenge: project architects and enterprise architects. Enterprise architects define the overall vision for the enterprise and guide the projects so that each contributes to achieving the vision. Their design scope is the entire enterprise. Project architects have a narrower scope: the portion of the enterprise architecture that is impacted by the present project. They are responsible for determining exactly what this scope is and making changes in a manner that is consistent with the enterprise architecture vision. Project and enterprise architects must obviously collaborate to achieve the enterprise architecture vision. Chapter 5 explores these two roles and their interactions in some detail.
Summary
As your approach to designing IT systems becomes more sophisticated, the perspective that governs the design has to evolve. Early designs focused largely on the needs of individual systems. Services force the perspective to expand to include the consumers of the services as well as the providers. Improving business processes requires a focus that includes all process participants, both people and systems, along with their interactions. Business process management requires an explicit model of the process as well as an understanding of how the process manager interacts with all of the process participants. This evolution reflects a shift in thinking away from system-centric designs and toward process-centric designs.
The responsibility for maintaining a perspective that includes the business process, along with the multiple systems and organizations involved in the process, belongs to the architect. But you don’t build the enterprise’s business processes and systems all at once: You build them piecemeal, one project at a time. This requires two variations of the architect’s role. The enterprise architect keeps the complete picture in perspective and defines what the eventual enterprise architecture should be. The project architect looks more narrowly at the portion of the enterprise architecture being impacted by the current project. It is important that the enterprise architect guide the project architects to ensure that individual project design decisions are consistent with the enterprise architecture vision.
Let’s start by taking a look at what we mean when we say architecture.