Introduction to
Service-Orientation
|
|
Service-Orientation
Design Principles
|
|
|
Effects of Service-Orientation on the Enterprise
|
|
Service-Orientation
in the Real World
|
|
|
|
Service-Orientation in the Real World
|
Challenges Introduced by Service-Orientation (Part II)
...continued from previous page
Top-Down Requirements
A preferred strategy to delivering services is to first conceptualize a service inventory by defining a blueprint of all planned services, their relationships, boundaries, and individual service models. This approach is very much associated with a top-down delivery strategy in that it can impose a significant amount of up-front analysis effort involving many members of business analysis and technology architecture groups.
Though preferred, achieving a comprehensive blueprint prior to building services is often not feasible. It is common for organizations to face budget and time constraints and tactical priorities that simply won't permit it. As a result, there are phased and iterative delivery approaches that allow for services to be produced earlier on. These, however, often come with trade-offs in that they can require the service designs to be revisited and revised at a later point. While this can introduce risks associated with the implementation of premature service designs, it is often considered an acceptable compromise.
The principles of service-orientation can be applied to services on an individual basis, allowing a reasonable degree of service-orientation to be achieved regardless of the approach. However, the actual quality of the resulting service designs is typically tied to how much of the top-down analysis work was completed prior to their delivery.
A best practice for addressing this issue is to ensure that, at minimum, a high-level service inventory blueprint always be defined prior to creating physical service contracts. This establishes an important "broader" perspective in support of service-oriented analysis and service modeling processes and, ultimately, results in stronger and more durable service designs.
Counter-Agile Delivery
Irrespective of the potential top-down efforts needed for some SOA projects, the additional design considerations required to implement a meaningful measure of each of the eight design principles increases both the overall time and cost to deliver solution logic.
This may appear contrary to the attention SOA has received for its ability to increase agility. To achieve the state of organizational agility we described in Chapter 3 requires that service-orientation already be successfully implemented. Given that it takes more effort to design and build service-oriented solution logic than it does to build a corresponding amount of logic that is not service-oriented, the process of delivering services in support of SOA can actually be counter-agile. This can cause issues for an organization that has tactical requirements or needs to be responsive while building a service inventory.
A effective best practice (when sufficient resources are available) is to allow SOA initiatives to be delivered alongside existing legacy development and maintenance projects. This way, tactical requirements can continue to be fulfilled by traditional applications while the enterprise works toward a phased transition to service-oriented computing.
Governance Demands
The eventual existence of one or more service inventories represents the ultimate goal of the typical large-scale SOA initiative. It establishes a powerful reserve of standardized solution logic, a high percentage of which will ideally be classified as agnostic or reusable. Subsequent to their implementation, though, the management and evolution of these agnostic services can be responsible for some of the most profound changes imposed by service-orientation.
In the past, a standalone application was typically developed by a single project team. Members of this team often ended up remaining "attached" to the application for subsequent upgrades, maintenance, and extensions. This ownership model worked because the application's overall purpose and scope remained focused on the business tasks it was originally built to automate.
The body of solution logic represented by reusable services, however, is intentionally positioned to not belong to any one business process. Although these services may have been delivered by a project team, that same team may not continue to own the service logic as it gets repeatedly utilized by other solutions, processes, and compositions.
Therefore, a special governance structure is required. This can introduce new resources, roles, processes, and even new groups or departments. Ultimately, when these issues are under control and the IT environment itself has successfully adapted to the required changes, the many benefits associated with this new computing platform are there for the taking. However, the process of moving to this new governance model can challenge traditional approaches and demand time, expense, and a great deal of patience.
|
|
