Ensuring Service Reuse with SOA Governance
Asit Dan 110000NBQ1 email@example.com | | Tags:  service_reuse service_oriented_architec... information_governance soa business_glossary soa_governance
0 Comments | 3,049 Visits
The two primary objectives in delivering any service-oriented architecture (SOA) based solution are “service orientation” in aligning IT functions with business capabilities being enabled, and “service reuse” for sharing of IT functions and resources. As highlighted in previous blog entries, SOA governance plays a key role in making sure that the right decisions are made during the implementation of a SOA solution encompassing both the architecture and service life-cycle, to ensure that both of these objectives are achieved. Here, we will have a closer look at the key barriers in service reuse, and how these can be addressed through proper SOA governance.
So what could be so difficult to reuse a service? After all, each service provides a well defined interface, (e.g., WSDL) describing operations that can be invoked, and the formats for input and output fields for these operations. These interfaces for services are published in a service registry, and can be looked up easily for developing new SOA solutions. With new technologies for API management , these services can be made further consumable (i.e., easy to understand and accessible from a browser) and exposed to a broader public and end-users. Thus each business entity can publish their products and services both for internal and external consumptions.
Well, here are three issues that can get in the way of sharing services.
#1 - Understanding Business Information Used by a Service
In order to use an existing service, especially in an automated invocation by a business application, the client needs to provide all the right information as input in invoking this service, and subsequently, make use of the information delivered back as output. However, this goes beyond just following the right formats for the information fields; the information also has to be meaningful in the context of proper usage of this service.
For example, in a purchase order service, an address field can be a business address or a home address, and depending on the business definition of the service (e.g., merely describing one or more channels of postal communications, or a shipping address), getting such details right is crucial to proper use of this service. Take a slightly more complicated service for submitting a service claim to an insurance provider, where supplying a well-defined procedure code (such as ICD-9 or ICD-10) is essential for the claims not to be rejected. This is an example of data validation rule that must be satisfied by an information field. Another example could be an exposed interface for submitting a tax form where various input fields must adhere to strict interpretation of the definition of the fields.
Typically, within an organization, definition of such business information is governed by maintaining a business glossary and a data stewardship process. Certain types of information may be externally defined by a standard body (e.g., ICD-10 procedure code), while others may be defined by the business for its own use. Not only the definition of business information needs to be governed, there also has to be a decision point in defining a service to make sure that the right definition of business information is being used in developing this service. Furthermore, the accompanying definition of business information, and proper usage rules should be visible to clients, along with the formal description of service interface.
Without any SOA governance in defining a service, there will be no way to make sure that only the well defined and meaningful information fields are taken as input or output for a service, and furthermore, proper usage of business information fields are also published for look up by service clients. And without such assurances, the service is not reusable by another application. Therefore, addressing this challenge would require, setting up decision points in defining and publishing a service to make sure that only the meaningful business information are used in defining a service.
#2 - Evolving a Service to Meet New Client Requirements
It is hard to define a service in isolation without understanding all of its usage contexts, which incidentally, can evolve over time as new business applications and service clients are identified.
An example is a look up service to get customer information, which may be defined to deliver either the core attributes of a customer, such as name, address, phone number, etc. or a more comprehensive 360-degree view on the customer including various preferences and business classification of the customer (such as, “gold” customer). Another example is determining the granularity of a service and the business logic it encompasses. A coarse grained service encompassing both billing and collection can be decomposed into finer-grained services for “applying discount”, “creating bill” and “managing collection”. No one size fits all; on the other hand, customizing too many services to the need of each individual usage context will result in proliferation in the number of overlapping or similar services. There is no easy solution here. Starting on either end – either too broad or too fine-grained – a service definition needs to evolve in order to make a service more consumable to more clients without proliferating similar services.
Again, addressing this evolution in service definition would need a decision point on whether to define a new service or extend an existing service. Supporting capabilities include maintaining varying list of requirements by different clients, managing multiple versions of a service, and notifying and migrating existing clients to use a new version of a service. Things to consider include determining if the new version is backward compatible with the previous version. Governance should have rules around when consumers must be moved to the new version and the old version is deprecated and then retired.
#3 - Controlling Sharing of a Service by Multiple Clients
Just because a service can be reused by another business application doesn’t mean it will be or should be shared without establishing a proper control on this sharing. In sharing a service, what obligations must each party -- whether a provider or a consumer -- have towards the other?
Accessing an existing service by a new client can overload the IT infrastructure resources, on which the service is deployed, resulting in a poor response time and throughput not just for the new client but also for the existing clients. This is an undue interference for the existing clients. Alternatively, in reusing a service, a client relies on a service other than its own, and has little control in managing the allocation of underlying resources in achieving desired performance (i.e., response time and throughput). Therefore, a decision point must be used to establish an agreement between a provider and a client before allowing any sharing of an existing service. This decisioning should include a Service Level Agreement (SLA) on the performance (i.e., response time, throughput) and availability.
Ultimately, operations will have to determine how the SLA will be supported. There are multiple ways a service can be shared, either by creating a new instance of a service by deploying the same codebase on a new infrastructure, or by accessing a single instance by all clients. With cloud based technologies for dynamically provisioning new instances, and controlling allocation of resources, it becomes easier to facilitate sharing of a service as per established agreements.
In summary, deriving the full benefits of a SOA approach requires proper SOA governance for addressing various decisions on service definition and implementation that make service sharing feasible.