As much as service-orientation can solve some of the more significant historical problems in IT, its application in the real world can make some serious impositions. It is necessary to be aware of these challenges ahead of time, because being prepared is key to overcoming them.
With a constant emphasis on reuse, a significant percentage of a service inventory can ultimately be comprised of agnostic services capable of fulfilling requirements for multiple potential service consumer programs.
Although this can establish a highly normalized and streamlined architecture, it can also introduce an increased level of complexity for both the architecture as well as individual service designs.
- increased performance requirements resulting from the increased reuse of agnostic services
- reliability issues of services at peak concurrent usage times and availability issues of services during off-hours
- single point of failure issues introduced by excessive reuse of agnostic services (and that may require the need for redundant deployments to mitigate risks)
- increased demands on service hosting environment requirements to accommodate autonomy-related preferences
- service contract versioning issues and the impact of potentially redundant service contracts
These design issues can be addressed by a combination of sound technology architecture design, modern vendor runtime platform technology, and the consistent application of service-orientation design principles. Solving service reliability and performance issues in particular are primary goals of those design principles more focused on the underlying service logic, such as Service Autonomy, Service Statelessness, and Service Composability.
The Need for Design Standards
Design standards can be healthy for an enterprise in that they “pre-solve” problems by making several decisions for architects and developers ahead of time, thereby increasing the consistency and compatibility of solution designs. Their use is required in order to realize the successful propagation of service-orientation.
Although it can be a straight-forward process to create these standards, incorporating them into a (non-standardized) IT culture already set in its ways can be demanding to say the least. The usage of design standards can introduce the need to enforce their compliance, a policing role that can meet with resistance. Additionally, architects and developers sometimes feel that design standards inhibit their creativity and ability to innovate.
A circumstance that tends to aid the large-scale realization of standardization is when the SOA initiative is championed by an executive manager, such as a CIO. When an individual or a governing body has the authority to essentially “lay down the law,” many of these cultural issues resolve themselves more quickly. However, within organizations based on peer-level departmental structures (which are more common in the public sector), the acceptance of design standards may require actual negotiation between IT departments.
The best weapon for overcoming cultural resistance to design standards is communication and education. Those resisting standardization efforts are more likely to become supporters after gaining an appreciation of the strategic significance and ultimate benefits of adopting and respecting the need for design standards in support of SOA initiatives.
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.
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.
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.
To supplement the benefits and challenges just covered, this page discusses some further aspects of service-orientation.
It Is Not a Revolutionary Paradigm
Service-orientation is not a brand new paradigm that aims to replace all that preceded it. As previously established on the Origins and Influences of Service-Orientation page it incorporates and builds upon proven and successful elements from past paradigms and combines these with design approaches shaped to leverage recent technology innovations.
This is why we do not refer to SOA as a revolutionary model in the history of IT. It is simply the next stage in an evolutionary cycle that began with the application of modularity on a small scale (by organizing simple programming routines into shared modules for example) and has now spread to the potential modularization of the enterprise.
Enterprise-wide Standardization Is not Required
There is a common misperception that unless design standardization is achieved globally throughout the entire enterprise, SOA will not succeed. Although design standardization is a critical success factor for SOA projects that is ideally achieved across an enterprise, it only needs to be realized to a meaningful extent for service-orientation to result in strategic benefit.
For example, service-orientation emphasizes the need for standardizing service data models to avoid unnecessary data transformation and other problematic issues that can compromise interoperability. The extent to which data model standardization is achieved determines the extent to which these problems will be avoided.
The goal is not always to eliminate problems entirely because that can be an unrealistic objective, especially in larger enterprises. Therefore, the objective is sometimes to just minimize problems by taking special considerations into account during service design.
In support of this approach, design patterns exist for organizing the division of an enterprise into more manageable domains. Data standardization is generally more easily attained within each domain, and transformation is then only required when exchanging data across these domains. Even though this does not achieve a global data model, it still establishes a very meaningful level of design standardization.