SOA:Many Things!

SOA: Many things

SOA is not one but many things! Recall the story of blind men and the elephant; each one comes up with a different interpretation. Our individual perceptions and role in an organization is not an adequate basis to describe the entire SOA beast. Agendas of individuals or organizations defining SOA make it even harder to fathom through the myriad. For instance, for a vendor with a product line of applications, SOA is just web services. For a technologist, it is an IT issue and all about SOAP. SOA is about legal contracts for the general counsel, or delivering a business capability for a CIO.

In short, SOA means many things to many people. Yet we are not blind and should not be constrained by a narrow view. Thus the overall definition of SOA must arise from collective nature of the enterprise, with input from its constituents.

Let’s consider a situation involving the return of unused goods. In this typical reverse logistics scenario, understanding of a service varies from technologists to non-technologists, each with different priorities. For a technologist, a service is a network-enabled software component, which provides a specific capability. For a non-technologist, a service is some form of offering supplied by an organization that receives merchandise return requests, sends directions for shipment, updates inventory and applies credit to the customer. A customer service representative will make sure that customer requests are understood and s/he gets the information for the return. Shipment and receiving will be your focus if your role is operations. Accounting will be more interested in applying appropriate credit to the customer. While each participant has a defined focus, overall goal is to establish a means of delivering value to the customer.

This complex situation involves Customer Relation Management, Supply-Chain Management, and Enterprise Resource Planning. SOA solves this complexity by

• Decomposition
• Aggregation
• Orchestration

SOA decomposes this business process into well defined discrete services: some are automatic, some are manual, some short-lived and near real-time, some are long-running requiring human-intervention. Services may be aggregated and then orchestrated to create additional services depending on the granularity level of decomposition.

After all, a service is a unit of work done by one entity in order to meet the need of another entity. The primary entities in SOA are the service provider and the service consumer. At any point, the roles may be reversed, consumers becoming providers and vice versa. The consumer enjoys the value created by service without the ownership of the specific costs and benefits.

Service interactions, however, must be defined unambiguously for both entities to successfully communicate. Each interaction between the participants must be self-contained in a service contract, focusing on a specific capability. A greater synergy is achieved by the orchestration of these services in a coherent manner.

SOA embraces the fact that each entity may have a drastically different environment. Distinct systems or applications deployed at various agencies can interoperate because SOA makes as its pinnacle the use of ubiquitous XML which poses no limitation by platform or language. Choosing JAVA, .NET, or a mixture is not a headache anymore! By placing emphasis on business activity rather than implementation details, SOA can make that crucial inventory drop arrive at a warehouse manager’s Blackberry™ to shore up just-in-time measures. By adhering to the service contract, an organization can easily swap out its implementations or move to other locations. A service for sending out information to customers, for instance, may be reused by multiple departments.

SOA is more than a buzzword. It is the way for organizations to rapidly develop capabilities, to collaborate and meet the expectations of their stakeholders. SOA’s agility makes it an enterprise business strategy, however.

SOA may also be DOA, dead on arrival, if we narrowly assume that it is just a bunch of web services, a product or a panacea for integration nightmares.

Some organizations get their feet wet with a few services by creating prototypes and exploratory projects. This is a good point of entry for the technologists but the business executives need to start thinking big at the onset. For businesses, a concerted effort needs to be made to launch a SOA lifecycle at the enterprise or the segment level. A typical SOA lifecycle includes three stages:

• Initiation
• Roadmap development
• Plan execution

For continued success, the lessons learned in execution should create a feedback loop to the roadmap.

SOA initiation needs both business and IT to cooperatively decide on the business process that will be built or replaced. Creating the team and setting a project plan is necessary. Roadmap development establishes the SOA principles and reference architecture for business and technology (application, data, and infrastructure). Governance will guide with policies, measure effectiveness, control for compliance, communicate to inform all parties, and above all, empower for better decision making. Program management assures that the project is on time, on budget and on scope.

The SOA lifecycle is about implementing SOA enterprise-wide. It gauges smaller pilot projects to be on par to address the need of the organization and paves the way for properly scaling up. Once business and IT decide on the services, avoiding DOA requires establishing a Service Lifecycle to manage individual services.

Service lifecycle spans the activities from inception to retirement or decommissioning of a service. There are three stages:

• Requirements and Analysis
• Design and Development
• IT Operations

Following a service lifecycle assures accurate capture of business requirements, development of IT solutions that match business requirements and deployment/maintenance of services that provide business capabilities encapsulated in the requirements.

Starting a SOA lifecycle, or for that matter, choosing the candidate business processes along with governance, is not a small feat. A misfiring engine can cause headaches in the long drive. Choosing a vendor in this endeavor may be the biggest investment an organization may have to make in climbing the mount SOA.

Note that SOA is neither a product nor a single solution, but rather a comprehensive business enablement with IT elements. Make sure that your vendor is capable of bringing together business and IT stakeholders in a face-to-face collaborative where you, as an organization, not the vendor, make the decisions. After all, who knows your organization better than you? How rapidly will your vendor comprehend and assess your business processes to enable you to sail into service decomposition? Think big and ask about the end game. Establish governance and a program management. Spot the need to change early, especially organizational changes. Start small with services representative of your environment then you are ready to scale fast!

Burc Oral

http://www.linkedin.com/in/burcoral
http://www.soa-consortium.org/