With a deeper understanding of the importance of layering services within a SOA, let's now focus specifically on the run-time phases of the SSLC. If managed correctly, these phases may provide a key ingredient to achieving organizational flexibility and agility powered by your SOA initiative. The following section provides detailed discussions on these aspects.
The Publish and Provision phase of the SSLC focuses on the understanding of what you need to do to release a service and establish boundaries for its use. In particular, this phase should establish the control points for SOA governance, and promote the acceleration of service reuse by defining such aspects as service interfaces and contracts.
When looking at publishing and provisioning services, it is important to have a strong understanding of what "pieces" of the service you are dealing with. At this stage, the implementation of the service is considered a static artifact of the design time and not the responsibility of the provisioning team. The provisioning team should focus its attention on the following aspects:
The service interface provides a standards-based mechanism for consumers to access the functionality offered by the implementation according to the contract it offers. It is through the service interface that the service will be published for consumption.
The contract should contain both functional metadata (how to interact with the service) and non-functional metadata (what conditions and restrictions apply to consumers looking to consume the service). By ensuring that the service implementation is free of logic such as conditions and restrictions to consumption, the service is more likely to be able to be composed in a myriad of ways, most of which have not been considered by the service engineering team or business at this point. It is important to realize that service contracts may be changed at run-time without the need to recompile code in the implementation; the trick is to leverage this flexibility efficiently.
In my experience it is the metadata and policies defined to support a service that truly enable service reuse and composition. Management of metadata is the secret sauce in establishing a truly flexible SOA environment. By defining a series of policies, the run-time control of a single service or a category of service may be easily managed external to implementations. The policies define not only which rules apply to which consumers but also to the service itself with regard to who can provision what and when. The added benefit of metadata-driven policies is that they can be enforced under dynamic conditions such as the context of the users session, and message payload.
In focusing on runtime requirements of the SSLC, control and governance begin to play an increasingly important part to successfully managing your SOA initiative. As a result, services should be published to some form of registry that can support configuration and change management aspects of a services lifecycle. This registry may also integrate with an enterprise repository, which may also house additional related information. In particular, control points should be established that, through tooling, should notify existing consumers of changes to a service, and potential governance policies should be established to provide a window of time for consumers to migrate to a new version of a service, if required. All of this information may reside in the repository and may be presented to the service consumer through the registry.
The SSLC and SOA promote flexibility and agility as central tenets of success. Service reuse is one method for accomplishing these goals. As identified in the Build and Compose phase of the SSLC, services may be consumed as part of new service implementation. It sounds obvious but this statement is important to ensuring that a design-time composite service does not inhibit flexibility through the Integrate and Deploy phase of the SSLC. The reliance on service implementations to dynamically assemble services to support business needs may cause issues with dependencies and version mismatches when changes are introduced at later phases. It is therefore suggested that you leverage dynamic tools such as Business Process Modeling (BPM) to facilitate roundtripping of service linkages rather than embedding them into the service implementation. Another approach may be to utilize proxy services in your service implementation rather than use true business service end points. By exposing proxy services through an Enterprise Service Bus, the physical service may change independent of consuming services. (Of course, if the service interface changes upstream, consumers should be notified through an established governance process.)
Unfortunately, dynamic assembly of services at run-time does not just happen. The ability to integrate and deploy seamlessly requires a decoupled service environment that targets the need to reduce point-to-point relationships between services or intelligent end points—these denoting that a service implementation contains coded logic inhibiting reuse of the service in a way that has not been explicitly planned (coded) for. In addition, the service engineering team must recognize that services do change over time and that new versions shall be released while others are retired. The integration and deployment phase should focus on support for multiple versions of services that may need to coexist for a specified period of time. Overlapping such a need is the governance control mentioned previously to determine appropriate actions to limit service sprawl focusing the organization into a kind of primordial soup of uncontrolled producers, or, as a colleague of mine so eloquently put it, "You need to eat your IT vegetables and not just your IT candy."
In order to support such dynamism within your SOA initiative, you need to look at mechanisms of configuration-based routing that, instead of hard coding end points, have the ability to interrogate the payload or context of a service request and route it appropriately in a configuration-based approach. Further, the environment needs to support seamless change control that provides accurate auditing of change information (remember, you reap a lot of the financial benefits of SOA through cost avoidance in aspects such as compliance!), provide the ability to aggregate configurations into manageable groups, provide real-time changes and simultaneous session support for transparent change control, and, of course, provide the ability to roll back when problems occur.
Finally, the Integrate and Deploy phase of the SSLC should support the notion of role-based operational views. These views should allow delegated configuration of composite services and not just limit their visibility and change management functionality to the service contracts defined in the Publish and Provision phase. By purely focusing on individual services and the ability to manage change at this level, the organization may not realize the full benefits of composite applications and be in danger of reverting back to some of the practices of traditional application development resulting in systems that are difficult to monitor, and provide concerns related to break-fix-style regression testing.
Initiatives within your organization can be successful only if they can be accurately managed to respond to the needs and demands of the business. In a SOA capacity this entails providing enhanced quality of service to the right customers through an understanding of the context in which the services are being used. I often think of the economic models that identify specialization as a way to increase the production probability curve within an economy. Without going into economic theory too deeply here, the ability to enable a shared service infrastructure to understand usage needs in both a proactive and reactive approach can provide a higher level of customer service or leveragability. In economic terms this may relate to an understanding of the aggregate demand of a service.
The Secure and Management phase of the SSLC should allow the organization to manage security constraints through the policy rather than the service implementation. The service policy can dictate such aspects as transport-level security with regard to the protocols the service can be called by as well as leverage WS-Security standards to ensure interoperability. Of course, lower-level data security can be managed through abstracted data services or some form of distributed entitlement engine. Specifically for the SSLC, this security is provided through management of the policy and associated contracts rather than service implementation.
At any stage in the SSLC it is important to have visibility into the process in real time. The Secure and Manage stage in the SSLC focuses on managing services to business requirements based on current reality usage. This may include SLA management on performance and error events. The ability to manage this information is an important aspect to adhering to governance control points established within your industry or organization. For example, let's consider that for each book to be purchased from the fictitious organization, you need to ensure that the order is responded to within a certain timeframe and any books of adult nature are sold only to people with whom some form of age verification has been conducted. In this case, a service policy may be implemented that confirms age verification has passed—possibly through the introspection of current customer canonicals. (It is important to note that, in a highly leveraged environment, a single service implementation can and should provide multiple service policies and contracts to determine its use.) Continuing the example of the purchase of an adult book, two policies are actually in effect here: first, the age verification if the book is of an adult nature, and second, a SLA that requires orders to be shipped within a particular timeframe. Any breach of these SLAs may be reported as an exception or violation of policy and likely reported in some manner. A mature SOA organization may have clearly defined governance processes that clearly identify control points and exception routines, all of which are likely to be recorded in an enterprise repository such as AquaLogic Enterprise Repository.
With SLAs and business policies established, the organization may leverage enterprise dashboard-style functionality to provide immediate and centralized feedback to users who may require visibility into the operational state of the organization. Through such visibility, the Secure and Manage phase should provide the run-time flexibility to enhance quality of service delivered to the consumer if the situation dictates it. One such example is the ability of the system to "dial-down" the service if an end point is unavailable or route the request to a lower-cost channel such as IVR (Integrated Voice Recognition) rather than costly CSR (Customer Sales Representatives) for the majority of standard requests.
Just like fiscal and monetary policy of governments, planning and preparation are subject to change when actions are put into practice. The final phase of the SSLC involves detailed analysis of how services are being used in run-time based on actual usage. The intention of such analysis and evaluation is to allow an organization to better govern and manage service usage behavior based on actual production influences.
The evaluation phase focuses on taking production services and assessing their usage based on the service categorization guidelines established as part of the service modeling methodology presented in Part 1 of this series. Experience has shown that a service developed initially with a particular function or level of use in mind may actually be much more heavily used than originally anticipated. Such run-time changes are part of the desired organic growth of the SOA within an organization, but they must be managed effectively to avoid detrimental effects upon SLAs and SOA effectiveness. During the evaluation process, the service engineering team should determine whether the service is being utilized as envisioned or needs to be recategorized to maintain or improve desired levels of service. This recategorization may change how a service is governed going forward and require a change in support or funding structure. This is especially true if a horizontal service, one that is initially designed for line-of-business usage, begins to be utilized across the enterprise. Such a service may be recategorized as an enterprise service and governed accordingly.
Another important aspect of the evaluation phase is to leverage the service infrastructure to collect metrics for demonstrating ROI and success of the SOA initiative. Both business and IT benefits may be identified through the gathering of SOA metrics. Determining ROI and cost benefits of SOA is a broad topic and beyond the scope of this article (but is being addressed in a further article I am writing). For the sake of brevity, one of the metrics that the SSLC is concerned with is the level of reuse of services. In particular, metrics that measure how often services are being reused verses being created are important when evaluating the future success of the SOA program. For metrics to be truly effective, they must be captured from day one and able to be compared to past metrics information such as time to market, reuse, and reduction in the break-fix cycle, of previous IT initiatives.
Finally, the evaluation phase of the SSLC should be leveraged to drive the next round of service candidates in conjunction with the catalog of needs. Usage metrics are direct evidence of whether the dependencies identified within the catalog of needs accurately represents reality. In addition, service usage and composition may identify additional relationships that warrant developing specific, governable, and measurable services to support. Through evaluation these relationship services are likely to become evident much more easily than purely through the design-time phases of the SSLC.