Why does your business need SOA?

Your software have stood the waves of technology change. And if you were not careful it has withered and your architects make a call to improve it bigtime to improve maintenance cost of old software. What worries you is “Let’s change and try a new approach” approach. There is complexity in your software, part of it is inherent in the domain and part of it is the way software is written. Most of the time when complexity grows enough, technologists wish to try a simple overlying approach, only to find out that some complexity cannot be done away with. You SOA thoughts could be started from your IT department or better you business guys. In any case it is good to have an overarching approach.

You could follow Seagull Software Five Point Plan to SOA (http://www.contactcenterworld.com/view/contact-center-news/SOA-Migration-Must-Be-Driven-By-Business-Needs-And-Not-Technology.asp) :

1. Identify your business pain points and the services you need to offer
2. Forget 'rip & replace'
3. Remember 'wrap & adapt' to service-enable underlying architecture
4. Understand the technology - but don't get bogged down by it
5. Adopt a staged approach to SOA

The first step is to understand business needs. Cutting total cost of ownership is also a business concern. So, it is good for you to find a higher level case for SOA without getting into technological aspects. Next section gives a list of probable causes so that you can think on these lines. Before that we have here some examples of reasons that various industries have.

What are some of the market forces leading your industry toward SOA? (http://www-306.ibm.com/software/solutions/soa/businessleaders.html )

Automotive:	Growing need for multivendor in-vehicle systems/software integrationShift of design and manufacturing among automotive value chains
Banking:	Continued regulatory involvement with added pressure on costs and integration
Electronics:	Disparate systems used in design, development, manufacturing, marketing, and sales
Financial Markets:	Regulatory compliance and automation of trading
Government:	Need to improve oversight, accountability, and compliance
Healthcare:	Increasing pressure to integrate payers, providers, and government agencies
Insurance:	Enhancing customer satisfaction and increasing up-sell/cross-sell opportunities
Retail:	Customize the consumer experience and real-time product availability
Telecom:	Create and connect applications with less development time, expense, and expertise

1.1. Hide organizational boundaries

Collaboration is in and internet is being used to build networks that are far more value adding. The softwares that a business uses have to work with the network partners. And fewer things can cross boundaries, definitely not design guidelines etc. Its difficult to even adhere to interfaces forget platform.

Even inside one company things get complex. If one is building a complex software across multiple teams, one need loose coupling and as less as possible design constraints on architecture. And if you are a company with multiple departments and you have some history, you have a complex situation. Your departments in past have bought different applications so diverse (with totally different architectures, platforms etc.) that they always worked independently with humans acting as integration points. And your departments wish to buy new softwares to enhance the existing functionality. And you start suffering from “How do I make all this work together?” syndrome then SOA can help you a lot.

1.1.1. Across companies

SOA provides you a standard that you can agree and then forget. The toolset in the market will help applications integrate. And you have series of options if you needed visibility into what and how the applications were communicating. SOA perhaps is designed for this kind of scenario.

1.1.2. Intra-company

You can have some sleep at the expense of some performance, which is not really considerable in some applications. This relieves the architect from worrying about yet another architectural concern – will it run together?

1.2. Bridge legacy and new systems

You have this legacy finance system which you wish to integrate with your new online marketing software. The two softwares are similar in only that they are software, rest all is different. The very thought of integrating these raises your hair. You need a new abstraction where you take these two systems a level up, call them as services and them at that higher abstraction you design the integration. All the while being supported by WS integration toolset.

1.3. Bridge current and far future systems

You had an experience like above and you are building a system which you feel that few years down the line will create the same hair raising experience. You wish to be pragmatic and you thing SOA is the abstraction this industry needed and you jump on the bandwagon.

1.4. Design for quality attributes

Some time there are architectural limitations that are put by architects to simplify the architecture. Architects and designers can then focus of other concerns that are of higher importance.

1.4.1. Design of unavailability of sub-systems

By allowing systems to be loosely coupled and lowering the availability of sub-systems, design is eased. One has to expend extra effort in designing highly available systems and this cost could be saved.

1.4.2. Design for ease of adding new sub-system

You have a situation where you are building a piece of a huge system and you either don’t any idea of how many other pieces will come in future or you do not wish to worry about them now. You design the system in min with integratability as a quality attribute.

1.4.3. Paradigm for robust design

Thinking of software as service helps in creating robust systems. With a clear contract – the inputs and outputs of a service and no assumptions on availability of service, the consumer of service can build in robustness instead of falsely assuming availability.

1.4.4. Extreme Rapid Application Development

You have an application team and a business logic team. Your business logic team is concerned with developing assets that your application teams can use to quickly create an application. For example a address validation and correcting functionality was built by business logic team by guessing its need. The application team wishes to use same functionality in multiple applications. And many times application design is dependent on what functionality is present, not only from time to market perspective but the fact that application developers are not aware what can be done now, which was not possible few years back (also called Technology Driven Innovation). You need a component model to manage these assets and SOA is not bad.

1.5. More reading

Service-oriented architecture: A practical guide to measuring return on that investment - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1025716?cntxt=a1002583&

Changing the way industries work: The impacts of service-oriented architecture - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1025932?cntxt=a1002583&

Blueprint for supply chain visibility: Service-oriented architecture can help drive agility, supplier collaboration and demand-driven replenishment - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1028723?cntxt=a1000453&