Why Does A Business Need SOA?

If an enterprise is willing to invest in enabling existing applications as well as developing new applications using service oriented architecture (SOA), then there has to be concrete business benefit. In this article, we explore causes behind investments in service oriented enterprises. We try to see what senior management must be visualizing when they approve budgets for SOA based applications.

Competition:Every business domain is experiencing fierce competition, hence there is tremendous pressure on IT infrastructure to support continusously changing business expectations. Business is expecting quick implementation of new ideas, so that the market can be captured before competitors are even ready. Time taken to generate an idea and realize it has to be very less. Applications invoving these business changes should also undergo transformation rapidly, and make new things available to customers. SOA introduces modularity which eases introduction of new modules without largly affecting other application stack. Thus the desired functionality can be brought to market with unit development and can be pluged in to existing functionality.

Cost Implications:Business always wants cost effective solutions. IT budgets are usually to run existing applications to continue business, and to change applications to intruduce new things. It is expected that there should be lesser and lesser expenditure in maintaining the existing applications. Also the cost of chaning existing applications as well as introducing of new functionality should be minimum. Service oriented structuring of applications introduces loose coupling, which allows changing applications without much impacting others. Loose coupling also helps in introduction of new functionality easily. In short IT is commoditized to benefit business.

Adaptivity:Loose-coupling makes applications adaptive. Applications can grow and shrink as required. Also Service oriented architecture is based on standards. This makes applications (interfacing) generic enough so that these can be integrated with each other without much effort. Also this avoids vendor locking. Any change in vendor (application server, operating system etc.) can be accomodated easily.

Operational Effectiveness:Each service in an enterprise can be treated as a separate business unit. Now we can manage these servicess individually with better effectiveness instead of managing a bunch of highly integrated functionalities in an application. This improves the operational effeciency of people supporting these services. Support team does not face complexities arising due to integrated nature of applications.

Better Control: Services are individual business units. We can monitor each of them for service related paramters such as performance, service level agreement, revenue generation, business loss etc. This can help in defining road map of a service along with business growth.

The list of business reasons can be endless. Here we have few important business drivers which impact most of the decisions. In a nutshell, we can say that SOA is needed to make IT catch up with high speed of changing business environment.

Technology Drivers for SOA

Service oriented architecture gives an organization – enterprise IT. Functionalities are expected to service more than one application need i.e. enterprise need instead of residing in each application separately. When an organization decides to go for enterprise IT, there will be definitely business drivers which will result in monitory benefits. But in addition there will be technology factors, which force the management and architect to think of a SOA approach. In this post, we are going to discuss few common technology factors which drive SOA decisions.

Platform: Java and .NET technologies make an application platform independent. But when we want two or more heterogeneous applications i.e. one in Java and other in .NET to talk to each other, then it becomes difficult to introduce an independent interfacing platform. We can go for an adapter that understands other application and makes talking possible. But if there are multiple applications to be connected, then we may end up building as many adapters as the applications. Sounds cumbersome! Instead, if each application provides a generic interface which every other application can understand, then it will be a easy solution. SOA is used to fulfill this requirement. SOA uses webservices which offer platform and technology independent integration possibilities.

Standard: Taking above application integration point further, there is need of some guidelines/standards which can govern application integration. Availability of standards will bring uniformity in application integration. Standards also help in defining interface contracts, which work as a service agreement between the applications. Webservices can be written using standards that make platform and technology independent integration work.

Maintainability: SOA introduces modularity in application; hence addition of a new functionality is actually modifying a module or adding a new module. This can be achieved without impacting rest of the application. Addition of functionality can also be dynamic in nature because of SOA.

Complexity: As discussed in above point, breaking of application into smaller modules and definite services, reduces complexity. Further this approach can be used to break all enterprise applications into smaller services. This simplifies complex application environment into a simple serving modules.

Middleware: Enterprise application portfolio can be organized to have a central enterprise communication bus (also called as enterprise service bus) to which different enterprise services can be plugged and played. This enterprise bus can be a back bone of an enterprise. Also it can provide better control over enterprise application stack.

Reuse: Identifying a service that can cater to need of many applications avoids placement of such functionality in all applications. It increases reuse in application ultimately resulting in cost reduction.

Service Oriented Architecture – Introduction

SOA, which is Service Oriented Architecture, is a buzz word since recent past. It is also getting accepted in organizations having a pool of applications supporting business requirements. To understand what is service oriented architecture, let us start with the first word ‘Service’. We understand what a ‘Service’ means and then take it forward to connect with architecture.

What is a Service?
In real world, we know service is getting some help/work done from others. (And you also know that it is getting expensive day by day). This ‘others’ includes living as well as non living things. An animal can also provide us service in an hour of need, while many electronic products provide us day to day services.

If we want to identify characteristics of a service then -

A service -

• means getting something done from others
• may involve cost
• involves rules of service, can be called as a agreement or contract
• must have contract which changes less frequently
• can be provided by anybody who will be called as service provider
• can be used by any user/client
• may change the way of implementation without affecting contract or client
• can be published (advertised) by service provider
• should involve some rules of quality
• can be monitored for performance

In our case, when we connect service word with architecture, these characteristics need to be fulfilled by a service and also by the architecture which is backbone of this service. Hence a service oriented architecture is an architecture which can transform a component build on it into a service satisfying above characteristics (sometimes partially based on priorities and context).

Let us take an example. An organization has many applications, e.g. order entry, order processing, billing, complaint management, etc. These applications rely on customer information which reside in database. All these applications read customer information from database and use as required. This means the code, to read customer data from database, resides in all applications. We can think of moving this customer data read logic from all applications to a separate component. This component will be responsible for reading the customer data from database and presenting it in certain generic form suitable for all applications. It will also be accessible to all applications irrrespective of platform and location. All applications will just call the interface provided and get customer data irrespective of how the component internally reads data. Here the component can be called as customer data service. There are more technicalities involved in this, but we keep these for later discussion.

In short, SOA is a architecture pattern that can convert a component into a service.