Section 13.2. SOA-Driven Project Management
|
13.2. SOA-Driven Project ManagementAs we said in the introduction, this chapter focuses on how service orientation can support project management without inventing an entirely new project management methodology. Naturally, the level to which SOA elements should be included in project management depends strongly on the expansion stage of the SOAan organization that is already further down the road in terms of rolling out the SOA will in some cases be able to benefit more from these concepts. However, even in the early stages, an organization can benefit greatly from the concepts outlined in this chapter. When looking at SOA-driven project management, it is important to recall that an SOA introduction happens on many different levels within an enterprise:
As we will see, an SOA can help cut projects into more manageable pieces, which helps program and project managers to coordinate concurrently ongoing business projects, IT application projects, and IT infrastructure projects. Figure 13-2 again highlights the different levels of dependencies that an SOA can help to coordinate. Figure 13-2. SOA-driven program and project management contributes to the coordination of business and IT projects. It also enables a stepwise extension of the business infrastructure (deployed services) and the technical infrastructure (service bus).
13.2.1. USE SOA ARTIFACTS AS PROJECT CONTROL ELEMENTSA key issue in software project management has always been the mapping of project control elements (such as tasks, work breakdown structures, etc.) and software artifacts (program code, data models, specifications, and the complex relationships between all of these). Individual lines of code are clearly too fine-grained to serve as meaningful project control elements. Modules and object-oriented classes might be more suitable as control elements within individual tasks of a project. However, the challenge of SOA-driven project management is usually not the management of individual tasks, but rather the coordination of multiple concurrently executed projects and sub-projects. When looking at the entire enterprise IT landscape, we are usually looking at the program management level, where a program includes multiple projects. In some cases, this could even mean an application portfolio-based management approach. On this level, modules and classes are not suitable as project control elements, due to their fine level of granularity, as well as their technical orientation. Even within individual projects, we usually find that modules and classes are not suitable as project control elements on the highest level for similar reasons. Services in an SOA, on the other hand, represent an ideal tool for decomposing complex systems into manageable sub-systems. They are a powerful tool for controlling the state, integration, quality, and business readiness of individual components and sub-systems. The reason for this is twofold: First of all, a well-designed service provides the ideal level of granularity to be used as a project control element. Recall our discussion on service granularity in Chapter 4, which stated that the granularity of a service should be on the level of a meaningful business entity. Second, well-designed services in an SOA tend to be relatively business-oriented (taking infrastructure services out of the equation for now). This makes services an ideal communication tool not only between technical people but also between the non-technical people involved in the project management. Even if we sometimes find modules or classes with a level of granularity similar to that of services in an SOA, these APIs would usually still be fairly technology-oriented, thus lacking the business orientation that is required on this level of project management. Figure 13-3 provides an overview of the level of granularity of different types of software artifacts and how they relate to different levels of project management. Figure 13-3. Different levels of granularity of software artifacts at development time and runtime.
Another factor plays an important role in enterprise-level software project management: Enterprise-level applications almost always have to be synchronized not only during development time, but also during their lifetime in a production environment. Introducing a new release of a sub-system into a production environment must not have a negative impact on the other sub-systems. This means that we not only have to ensure that the technical interfaces (service contracts) between the different components in the production system are in synch, but also that data and expected behavior are compatible. For example, the restructuring of a naming service will not change and interface definitions but will require changing the configuration of those clients that have been configured to use the old structure. Coordinating the runtime compatibility of different sub-systems is a hugely complex task. Again, services are ideally suited for managing runtime synchronization of sub-systems. As depicted in the Figure 13-3, development time services match to service instances at runtime. As we can also see in this figure, services present something like the top-level abstraction layer for development time artifacts, as well as the bottom-level abstraction layer for runtime artifacts. This makes services ideally suited for managing the difficult region between development time and runtime synchronization. Figure 13-4 shows how service contracts (managed in a shared, centralized service repository) can support an SOA board (see Chapter 12) by providing the backbone for coordinating multiple projects on the program level (or, alternatively, coordinating multiple sub-projects on the project level). Figure 13-4. The SOA board utilizes service contracts in order to coordinate multiple projects.
13.2.2. INCLUDE SERVICE DESIGNS IN THE PROJECT DEFINITIONBecause services are a fundamental tool for structuring not only your architecture but also your project plan, it is only logical to demand that each project definition contain a high-level service design. We often underestimate the importance of the project definition phase, making too many implicit assumptions, including the answers to key questions such as "What is the scope of the project" or "What are the priorities?" The project definition phase enables us to ask these basic yet important questions, define a project vision, identify the major objectives and constraints, and so forth. In particular, the project definition should enable the different stakeholdersfrom both the business and technology sideto develop and articulate a shared vision. As we saw earlier, services are sufficiently coarse-grained and business-oriented to serve as a perfect communication tool in this critical phase of the project. The project definition should also contain an initial project plan, which defines the most important iterations and increments. Again, services are a very good tool for defining these and also for discussing implicit and explicit dependencies at this level. In an SOA-driven project, the project definition should therefore always contain a first draft of the architecture, including the most critical services that have to be developed or included. In a sense, these early service definitions and architecture blueprints serve as a common denominator between the different stakeholders and help in preventing unpleasant surprises during or after the project execution.
13.2.3. LEVERAGE SOA TO DECOMPOSE COMPLEX SYSTEMSAs with any large project or program, a key problem we must face in the early phase is the complexity of the undertaking, which requires that we find good ways of decomposing systems into manageable parts. The loosely coupled nature of an SOA is extremely well suited for this purpose. The following takes a closer look at how to leverage the SOA approach for project and system decomposition and how to manage the decomposed parts from a project management perspective. 13.2.3.1 Vertical Versus Horizontal SlicingMost enterprise applications can be decomposed using two different approaches, based on either vertical or horizontal slicing. A horizontal slice of a system usually presents a particular technical tier, such as the user interface, presentation layer, business logic, middleware, data management, and so forth. Vertical slices, on the other hand, represent specific business use cases, such as open account in a banking Web portal. Sometimes, large projects are structured in a way where different teams are responsible for specific horizontal slices of the systemfor example, one team does all the Web forms and graphics, one team does the complete database schema, one team does the business logic, etc. (see Figure 13-5). This can often lead to large integration overheads because each team is focusing only on its own specific layer, and there is a general lack of people with a good overview of the relationship between the different horizontal slices. Problems during development are potentially discovered only very late in the development cycle, usually the moment when large pieces of work that have been executed in isolation within each horizontal layer need to be integrated. Figure 13-5. Whereas horizontal layers are technology driven, vertical slices are driven by use casesthat is, business functionality.
When using horizontal slicing, developers with very different skills work hand-in-hand to deliver complete end-to-end slices, from application frontend to business logic to the middleware and data layer. This approach minimizes the integration overhead between components from the different horizontal layers of a complex system. In the following section, we discuss the "thin thread" approach, which is based on vertical slicing. 13.2.3.2 Thin Thread ModelThe "thin thread" development and project management model is essentially an application of the Iterative Application Development (IAD) approach, as described, for example, in the rational unified process. The "thin thread" approach is specifically suited for IAD in the context of Service-Oriented Architectures. A thread represents a vertical slice through the system, including an end-to-end implementation of a particular piece of application logic, going from application frontend all the way down to the database. The basic idea of the "thin thread" approach is to start with a very thin slice (or thread), which might, for example, only comprise the functionality of capturing a single string value in the application frontend, processing this information in the middle-tier, and writing it into the database. In the next phase, the thread might be "thickened" by adding end-to-end functionality for retrieving the string value from the database and displaying it in the application frontend. In a further iteration, a more complex data structure (e.g., a customer record) might be handled in a similar way, and so on. As the project continues, additional threads can be launched (see Figure 13-6). Figure 13-6. The "thin thread model" proposes an iterative development methodology. It is based on a simple process that starts with one piece of simple functionality. This functionality (the thin thread) is iteratively either thickened or complemented by additional thin threads.
Very often, the initial version of a thread might match an individual operation of a more complex service, and the final iteration of the thread represents the full-blown service. Most likely, the first iteration of a thread (especially if it is the first one in a new project) will be slow. Problems will arise in the initial setup of the system (including session management, transaction handling, middleware, data access, etc.) and in the development process, deployment, testing, performance, etc. The next iteration will be considerably faster, though, because all end-to-end problems will have been addressed in the first iteration. After the first couple of threads have been tried and tested, a more aggressive rollout of threads can start, as depicted in Figure 13-7. Figure 13-7. The number of concurrently active threads varies over time. Much of what is contained in this "thin thread" approach is obvious and common senseeffectively, it is a combination of widely established iterative application development concepts with a consequent vertical slicing approach on the architecture level. However, many projects struggle because they choose a horizontal instead of vertical decomposition approach. In addition, experience has shown that giving this approach a name (a "thread" denotes the basic work breakdown structure) and making it explicit in the project management plan simplifies planning and prevents miscommunication.
13.2.4. LEVERAGE SOA TO DRIVE DEVELOPMENT ITERATIONSService orientation is particularly well suited for supporting iterative application development, especially when combined with what we described in the previous section as the "thin thread" approach, which is effectively an iterative development approach based on vertical slices. Because SOA is particularly aimed at enterprise-level development projects, we often find situations where many projects (or sub-projects) are running in parallel often over long time periods. A key problem for such long-running parallel projects is the stabilization of the development process, which is required to decouple projects from each other, shielding each project from the dynamics of the other projects. Traditionally, the elements that can stabilize a project are the user interface and data model. However, in a distributed architecture with many layers between user interface and database, achieving stability in the top and bottom layers is often not sufficient for achieving overall stability. Service contracts are the ideal tool for stabilizing the development process in distributed architectures. They are conceptually located between the user interface and the data model, and if we carefully control the evolution of these contracts, we can greatly enhance the stability of the overall development process. Effectively, projects and sub-projects should evolve in parallel to the service contracts they share. We already discussed the loosely coupled nature of an SOA, referring largely to technical coupling. However, an SOA provides benefits beyond this technical loose couplingan SOA also enables loose coupling of tasks in a project. This reduction of dependencies between different tasks is directly related to the technical independence of different services, and it greatly enhances the flexibility of project managers with respect to the scheduling and coordination of different tasks. Effectively, although SOA does not eliminate dependencies between different projects, it documents them and helps to address them in an organized way.
13.2.4.1 Use SOA as the Basis for Divide & Conquer StrategiesIn addition to the "vertical slicing" of the thin thread approach, you often need to further decompose tasks, especially in phases where the initially "thin" threads start to "thicken"that is, a richer set of functionality is associated with the individual threads under development. In this case, it can often make sense to further decompose development tasks (i.e., threads) into "horizontal" slices. However, notice that this should always be the second stepafter the initial "vertical" slicing. As depicted in Figure 13-8, service contracts can help with the synchronization of this horizontal subdivision. We discussed earlier that the biggest problem with a horizontal slicing approach is the integration of the individual horizontal slices. In order to address this issue, service contracts should be leveraged as the key sync point between the individual slices, such as the application frontend and backend services. Service definitions are a result of the joint analysis and planning activities, which involve both sides of the service contract. The jointly agreed upon service contract should be approved by the SOA board and captured in the central, shared service repository. Based on the initial service contract (or its next iteration), both sides can now independently start development and testing of their respective parts (frontend or backend). Automatically generated test frontends and backends are an essential support tool for facilitating this divide-and-conquer approach. Only after the different sides of the service contract have reached a reasonable level of stability should they be deployed in a shared test environment, in which they can be integrated and tested further. Figure 13-8. The development cycles of SOA projects are driven by service contracts, which are the major outcome of the activity "define service."
Of course, a lot of these divide-and-conquer principles have been successfully used in the past. However, especially in distributed system development, where we often have complex infrastructures and project team members with very different skill sets (e.g., Java GUI programmers and COBOL mainframe developers), it would be helpful if these principles were adopted more often and if the appropriate support toolssuch as automated frontend and backend test toolswere provided. 13.2.4.2 Use SOA to Manage Parallel IterationsAfter service contracts have been established as the "heartbeat" that drives the overall project, it makes sense to look at them as a tool for enabling parallel development as well. As depicted in Figure 13-9, service contracts can serve as the basis for multiple service implementations that are developed in parallel (application frontends #1#N and backend services #1#M in this example). As a prerequisite, the underlying application scenarios #1#N will have to be analyzed, an iteration plan developed, and the service contract defined. After this, the individual front-end and backend services can be developed independently before they are eventually integrated. Figure 13-9. The SOA approach makes both the synchronization points of independent tasks and concurrent development efforts explicit.
Figure 13-10 shows how service contracts can serve as sync points, which help in coordinating the development and integration of multiple application frontends and services. Figure 13-10. An SOA project typically has to cope with many application frontends and services developed in parallel.
Their granularity and business-orientation make services ideal candidates for the breakdown and parallel execution of complex development tasks in distributed enterprise environments. This is an extremely powerful feature of any SOA-driven project, especially if time to market is critical and large development teams need to be synchronized. 13.2.5. TAKE A STEP-BY-STEP APPROACH TOWARD PROCESS INTEGRITYTo finish our discussion on SOA and iterative application development, we now look at transactionality and process integrity. In Chapter 8, we introduced the concepts of process integrity and how they relate to data integrity, transactions, and long-lived processes. A key discussion of that chapter was the tradeoff between process integrity on one hand and related costs on the other. Achieving 100% process integrity is almost impossible in most cases, unless we are prepared to spend the money usually required to build super-reliable systems, such as redundant electronics in an airplane or a nuclear power plant control system. "Normal" systems (such as an online banking portal, a stock trading system, or a telecom billing system) with "normal" budgets will have to accept the fact that certain rare failure situations will lead to process inconsistencies, which usually require human intervention to fix (e.g., through an DBMS administrator who is uses an SQL console to go directly into the system and fix problems reported by end users). However, in the real world this rarely presents a problem. Of course, it would be ideal if complex IT systems were completely self-sufficient and no system administrators were required to fix data or process inconsistencies caused by system failures. However, if the cost of building 100% reliable systems by far outweighs the cost of employing system administrators, the latter solution seems acceptable. The following describes a set of guidelines for introducing high levels of process consistency through an evolutionary approach, which helps in minimizing the cost and complexity of the development:
This approach will enable you to identify the few really critical parts of your system in an evolutionary msanner and focus on them specifically from a process integrity point of view (e.g., by migrating them onto a more reliable transaction model). This approach should be accompanied by a risk analysis of your services and processes, based on your formal service definitions. Table 13-1 shows an example of how this analysis should look (see also Figure 8-4).
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
EAN: 2147483647
Pages: 142