How effective is your SOA?
Posted by aartikaur on August 22, 2009
Business models of most industries focused on functional development rather than business processes, resulting in a heterogeneous system with interoperability issues because of tightly coupled point-to-point integration. Such integration is acceptable as long as the business processes are stable and integration of additional applications is required rarely.
The dynamic and collaborative nature of today’s business processes makes it necessary to have a scalable and flexible integration approach. This is when the paradigm shift occurred and the IT industry came up with SOA as one of the most viable solutions for enterprise application integration.
We know that SOA concentrates on “what” a business does than “how” it does. Implementing SOA in an organization involves many steps , the key amongst them being understanding the business environment i.e. analyze the applications to integrate, take a top down or bottom up approach and identify the services and their interfaces. The big question is whether implementing a pure SOA will address the real time business issues in the long term.
Let us evaluate this with a telecom domain business scenario; and try to adress a specific set of business and operational issues.
The basic services provided by the telecom providers are commoditized thus forcing them to come up with innovative value added services that will not only distinguish them from their competitors but also help them retain their existing subscriber base. Introduction of a new service means the ability to quickly test the service in the market, and if it is good enough then the ability to scale it as fast as possible. On the other hand if the service is not very popular then telecom operators should be able to decommission the service and replace it with another without a lot of integration effort.
Current system: Subscribers can subscribe/unsubscribe for a value added service using the CRM system. Each request has to undergo multiple processing steps based on parameters like, line type, subscriber and the requested service type. The first step is validation, the next step is service provisioning and the last step is billing after which the CRM system is updated to reflect the activation status and billing. Both service provisioning and billing often require interaction with in house or third party legacy systems. To sum up, introduction of a value added service is marred by various issues like time to market delay, fragmented OSS/BSS platforms, high operational and development cost thus resulting in lack of flexibility to introduce new business models and products rapidly.
SOA based resolution
Service identification and design: Here we need to identify key business requirements and/or operational issues and translate them into business logic using services. Another factor that would determine the choice of creating a service is its reusability.
In the current context, one of business pain areas is integration with legacy systems which leads to high integration and maintenance costs. Introducing a level of service abstraction composed of a set of generic services (which will implement the major service processing steps, i.e. validation, provisioning and billing) can address the above mentioned issue. The generic services will be Validation Service, Provisioning Service and Billing Service. These in turn will call core services based on the requested service type, line type and other parameters. There will be a core service specific to each type of request and will take care of the respective processing step. These services will interact with the BSS/OSS systems whenever required. Some examples of core services are SMS Validation Service, SMS Provisioning Service, SMS Billing service, MMS Provisioning Service.
Business process centralization:
One of the key issues with the current system is business process redundancy, i.e. based on the type of service requested the appropriate provisioning and billing subsystems are invoked. This process can be modeled as an orchestration which consists of all the steps (validation, provisioning and billing) arranged sequentially. The orchestration automates service request processing by interacting with a set of services i.e. at each step it calls the respective generic service.
Event driven SOA:
Pure SOA cannot address all the intricacies of a real time business. One needs to look at what business activities drive the business. Events can be of two types, internal system events and business events. A business event is any meaningful activity that alters the flow of a business process or triggers a new process. An end user subscribing for a service is an example of a business event, which will invoke the orchestration. Usually services follow a simple request-reply communication which may not be appropriate in the current scenario. For instance the generic provisioning service will interact with the appropriate provisioning system; time taken to provision a service can vary depending on the type of service requested. In this case the provisioning service should be able to signal the orchestration when the provisioning is complete. This is an example of an internal event. This can be addressed by using asynchronous web services, or using a generic and more sophisticated publish subscribe mechanism developed using WCF callback services.
Managing SOA with ESB:
An SOA makes perfect sense in this scenario because it enables providers to introduce new offerings with those of third parties and integrate them quickly with their internal, mainframe-based billing, provisioning, and other support systems. Provisioning and billing services which interact with the OSS/BSS systems need to be aware of the message format expected by these systems. In case we need to alter the business process to include any new service or a third party service then the orchestration should take care of the service discovery and resolution. This message transformation and routing logic can be segregated so that the services concentrate only on the business logic.
ESB is the infrastructure to manage an SOA. Microsoft ESB guidance package’s service discovery and invocation mechanism (itinerary web service) can be used for service discovery. The resolver mechanism can provide a generic service resolution. We can have an entry point to this system that is an itinerary service which will read the message and use the ESB resolver mechanism internally and invoke the business process orchestration. Adding a new service in the system means to register the service in a service registry and use the appropriate discovery mechanism. Also, message transformations can be done using BizTalk maps, thus each service will complete its processing and the ESB will take care of the message transformations and routing.
Managing SOA with ESB offers many potential benefits like service abstraction, ease of integration of new services, services can be deployed incrementally, speeding delivery of service to customers and reducing risk for large, complex projects and improved responsiveness to change in business processes quickly and effectively.
Events and services complement each other and either cannot be looked at in isolation from the other. SOA is a very powerful architectural concept but may not address the dynamics of a real time business all by itself. Combined with event processing and ESB, SOA can provide an optimal solution which not only addresses the business complexities but also adds value to it.