Many papers and articles identity the benefits of a SOA for organizations. However, any new technology has new challenges associated with it. In particular, SOA SSLC and related governance processes must be prepared for these challenges. The following section identifies a handful of challenges, some good and some bad, but all important for the service engineering team to have a good understanding of them.
The preceding section described the run-time phases of the SSLC and how they relate to an organization's SOA initiative. Just as important as the SSLC is one constant factor that requires special attention: change—an inevitable and necessary part of business evolution. Having an accurate understanding of the SSLC is a great way to be prepared for change and allows a consistent methodology for implementing a SOA initiative. Managing change within SOA and the SSLC introduces new challenges to managing change. In particular, introducing services into your organization introduces a number of new abstractions that require careful consideration. Such concepts as service contracts and policies require a different way of thinking about how functionality is developed. This takes time and practice to get right until the shared services team can promote some form of consistent adoption across the organization.
SOA also introduces the likelihood that the organization may have multiple versions of a service implementation in production at any given time. This idea, foreign to many organizations, introduces governance and support challenges pertaining to how long to support prior versions, support for consumer applications, the ability to change versions without detrimental upstream effects, and the ability to notify consumers of impending changes. I have worked with a number of organizations that have addressed these issues purely through governance to "force" consumers to migrate to the latest service version. Although this is definitely one solution, a more mature organization may provide a window of opportunity for consumers to migrate to the latest version if required, offer support for previous versions though a service registry and also leverage the flexibility of service contracts to provide seamless change control, transformation of requests, and so on. You need to remember that SOA is about promoting the agility of organizations. Requiring application teams to upgrade to each point release of a service may be considered detrimental to such agility.
Another new challenge that the success of a SOA initiative within the organization may come from a very unexpected source; your existing packaged applications. Most vendors these days provide web service interfaces to functionality within their products which are enabled by default. Depending on the size of these packaged applications within your organization, they may introduce hundreds of services, which may not adhere to your established service guidelines. The influx of unstructured services is likely to wreak havoc on the success of your SOA initiative. These services may not adhere to SLA requirements, may be managed by lines of business verses enterprise groups, and may also cause concern from a compliance perspective. This is especially true if the services exposed are published from core enterprise systems such as CRMs, Data Warehouses, and ERPs. It is strongly suggested that the organization establishes an aspect of the governance model to specifically deal with what services should be exposed and managed accordingly. One such approach may be to provide additional service policies or contracts to control package applications through the Publish and Provision phase of the SSLC. In conjunction with some prep work at the Secure and Manage phase, this approach may alleviate a proliferation of ungovernable services within your organization.
When you consider service contracts as part of implementing a service, most of the time you don't really give it much thought except for the fact that contracts help determine service usage. This is true but often people fail to recognize that a service contract is a formal, binding agreement that may restrict future flexibility. By definition, a contract is a binding agreement between two or more parties to behave in a particular way. Like it or not, by establishing a service control, the producer and consumer are governed by its stipulated rules.
Let's jump back to our catalog of needs that determined that we wanted to develop services to accept as an input a generic orders canonical. This canonical schema forms part of the binding contract that you expose. Any consumer must provide this canonical as an input parameter to the service. Careful attention must be paid to ensure that the schema does not allow too much flexibility resulting in many permutations of how a service may be called. The result of very flexible contracts is that the service becomes brittle and prone to difficulty when attempting to debug or maintain the service.
On the positive side, service contracts provide a great way of ensuring that your services can be leveraged quickly and efficiently. By designing service implementations to free of business logic and run-time decisions the service is more likely to be able to be leveraged as part of a composite service. Such benefits can be further achieved by recognizing that services can have multiple contracts that determine how they are used at run-time. This concept is similar to polymorphism in object orientated (OO) programming. Best practices in service design allow independent evolution of needs at the contract level, thereby keeping the service implementing simple and clean. The ideas of a service having multiple contracts can be extended further when it becomes clear that policies and contracts may have many-to-many relationships themselves and that multiple services may implement the same contract. Suddenly, the run-time operation of a system can be managed in real time by leveraging the power of a services repository to tweak usage as needed. True loose coupling requires the presence of many-to-many relationships within your services infrastructure. This is a powerful concept that, in my opinion, is still in its infancy within SOA initiatives.
Unfortunately, the full benefits of SOA gained through the leveraging of contracts and policies at run-time includes some technical limitations. In particular, WSDL cannot currently support all functional and non-functional requirements needed by an organization. In addition, the WS-Policy specification falls short in that it provides only an interoperable container for exchanging policy information but does not provide the support to specify that policy behavior. In time, I am sure these limitations will change as organizations continue to mature with their SOA adoption and techniques.
In my experience, in the long run the success of an organization's SOA initiative is dependent on how it manages and leverages metadata. Although many organizations will benefit from SOA initiatives by reduced time to market, service reuse, and so on, I believe that the harnessing of metadata within the organization will prove to be the difference between short-term success and long-term transformation. Metadata, the description of services and how consumers of those services interact with them, provides the flexibility to focus on the creation of shared services through composition to meet the business needs on a continual basis.
Having an understanding of metadata helps the organization avoid hard coding governance and process into tools and implementations and allows dynamic discovery of resources. The organization must be able to leverage the SOA infrastructure for more than just service details. A metadata repository must be established that supports all SOA artifacts and allows the description of a process within the environment and the context of the operation. This ability to manage metadata effectively will have a direct correlation with the ability to establish appropriate and measurable control points throughout the governance process.
To harness the full benefits of a SOA initiative within your organization, it is critical to adopt the notion that a service in run-time is a corporate asset that can be inventoried and tracked. This will help not only in building your shared service catalog and reducing time to market through reuse but also as a continued justification of SOA spend. If you cannot track and measure the benefit or cost avoidance through your SOA platform, future cost benefit decisions may be limited to subjective information.
Through accurate run-time governance of shared services, the organization shall improve the effectiveness of its SOA initiative. Unlike traditional software development, SOA focuses on building reusable atomic services that facilitate flexibility through contracts and policies. Through the successful design of services and consistent modeling methodologies, run-time aspects of service orientation should be more focused on the service infrastructure present in your organization.
In addition to solid design and run-time practices, organizations should recognize that SOA introduces new challenges that must be managed effectively through a consistent governance model and an embracing mentality. By embracing environmental certainties, such as change, your SOA initiative should provide organic growth matched only by the organization's desire to remain competitive and be considered a leader in the industry. After, all change is about innovation, and innovation is about thinking differently from the rest. If managed correctly, SOA can be a critical component to this change.
Finally, as an architectural paradigm, SOA is aimed at promoting reuse and allowing the business to bring new offerings to the market more quickly. As a methodology, SOA requires a detailed understanding of how an organization can rapidly adapt to change. The run-time aspects of the SSLC are directly related to building organizational flexibility. This article has attempted to provide insight into how, through careful analysis of current needs and service-orientated design practices, organizations may achieve this goal.
Quinton Wall is a Sr. Product Marketing Manager for Integration at BEA where he is responsible for articulating the strategic vision and direction of the products such as WebLogic Integration and AquaLogic Integration.