Service Oriented Architecture: the big picture

Big Thoughts

27 February 2013 • Written by Nishant Srivastava

With all the talk about Service Oriented Architecture (SOA), it’s easy to miss the basics of the big picture. Nishant Srivastava explains

So what is Service Oriented Architecture? And what’s critical for its success?

SOA can be considered as a collection of frameworks, techniques and policies that define how to develop a loosely coupled software system so that it can be reused (as services) by different users (consumers) for different purposes. The key to these services is their loosely coupled nature – that is, the service interface is independent of the implementation.

Service Oriented Architecture is a vision. It’s a way for businesses to develop and implement technologies so that it helps them deliver their maximum potential.

SOA’s approach encourages the building of loosely coupled systems that are capable of working independently of each other. But SOA doesn’t encourage starting work on a small item of functionality with little consideration for the big picture. It’s an architectural style for how independent applications should be developed and integrated depending on the business needs.

Why do we need SOA?

The answer lies in the ever-increasing demand for more effective and efficient IT systems and services.

Over the years, the need and dependency for IT software has grown. At the same time, as businesses started to provide different services or to improve them, the way that IT systems functioned needed to change. This increased the software complexity to the point where businesses started to feel that IT was unable to cope with the changing requirements in a timely and cost-effective way.

It lead to the development of an architecture style that enables IT and the business that owns it to respond to market conditions, changes in user requirements and expectations etc quickly and effectively.

Here are two analogies that clarify the purposes of SOA, the first illustrating what drives us towards a SOA approach and the second the principle behind it.

Analogy 1. Why do we need SOA?

Imagine there’s a business called Home Entertainment Units that builds systems with different services such as audio/video playback/image browsing etc. Now, monolithic (and often legacy) software solutions can be compared to a (imaginary) fully packaged all-in-one entertainment unit.

When you buy this package, you get (inbuilt):

• 50-inch full HD LCD TV

• DVD player

• 280w home theatre amplifier and speaker system

This unit would serve most people’s current requirements but, in time, those requirements would change to:

• Play Blu-ray discs

• Have Wi-Fi connectivity with a laptop, printer and internet

• Provide a 3-D viewing experience

• Have a 65-inch display

None of these requirements are unreasonable and would all eventually be integrated. But when it is, what’s the ideal solution?

Replace the entire package with a new one and do the same again when it’s updated? Or build patchy, poorly integrated add-ons that cater to my requirements regardless of them being inefficient, ineffective and often costly. Or should the user have bought individual systems in the first place that can be easily customised or upgraded and integrated using different types of standard connectors/cables? As long as the different cables and connectors are built to set standards, the integrated system should be able to cater for any changes.

So this company needs to provide services that are:

• Loosely coupled

• Standards-based

• Scalable

The interface (remote control) of the systems is in the users’ hands. Even when an individual system is changed, the remote still works.

Analogy 2. What is the basic concept behind SOA?

Automobile production lines have been perfecting this principle for almost a century and can help us establish the concept behind SOA.

Typical automobile production lines work in the following way (analogies in brackets):

• A product (service) is made up of scores of components (application systems), each built from hundreds of parts (sub-systems, program functions). For example, engine, transmission, body frame, light cluster, dashboard etc.

• Each component is made from different materials using different techniques (different applications built on different platforms). For example, an engine is made primarily of aluminium compounds and a plastic dashboard with leather/wood trim.

• Each component is individually manufactured (independent build of the application systems) at a particular part of the factory (location of an application – where it can be accessed from).

• Strict rules govern which component should be added next, how each unit knows when more of their component is required and how they are assembled (standards and protocols which define how applications talk to each other). For example, specific nuts and bolts pairs must be used to mount the engine block on the chassis or the assembled car may fail.

Floor management ensures smooth running, prevents conflicts or delays and monitors safety via different techniques and practices (SOA governance).

So the concept behind Service-oriented Architecture can be related to real-world practices. SOA implementation evolves from these concepts, but must be standardised for maximum effectiveness, much like the connector cables and the assembly mounts in the analogy above.

Some basic governing principles should be remembered while working on SOA architecture. These are guidelines for how components can be built to achieve loose coupling, reusability etc, and how we standardise communication.

Implementing a SOA framework using these principles helps us deliver a stable solution. We do this using our existing resources or start afresh, depending on the circumstances.

All of this comes with its share of challenges since a SOA project involves various parts of the business. These interdependencies make programme management complex, management of the integration of the loosely couple systems with the usage of protocols and policies being a uniquely important aspect. This is achieved by ‘SOA governance’, which helps ensure the quality and performance of available services.

Even with SOA governance, it is not uncommon for SOA implementation to go wrong. Optimised Quality Assurance and testing become necessary.

A well-built SOA implementation can work like magic – almost. Each individual system should seamlessly integrate with the other, encapsulating the complex code inside it. Messages and data flow through layers of applications, with scalable performance capabilities and the loosely coupled nature of these applications providing amazing adaptability to the changing environment and business needs. All of these unite to provide the user with a service.

Sound pretty theoretical? Sure, but that's the whole point. SOA is like a vision, a thought process of how businesses can run their services and how IT can build their systems to play a vital partnership in the realisation of that vision. And this is where testing and QA are imperative.

The quality of a SOA implementation lies in its ability to provide the level of functional expertise and optimisation that the governing principles of SOA postulate. Adhering to these governing principles is what confirms that we have delivered a SOA solution.

There have been instances where the implementation has ended up being a combination of different systems (because SOA partly talks about building systems independent of each other), somehow integrated with each other (far from loosely-coupled).

The system’s performance is often slowed down by some application built with inadequate consideration of its role in the big picture of multiple systems working together to provide a service.

The huge investment of time, effort and money can easily go wrong. The prospects of not engaging enough testing are not uncommon, but the consequences can be detrimental. It is wise to engage in QA and testing right from the start as it ensures that the right product is built in the right way.

From concept to finished product, it must be confirmed that what is being delivered is a SOA implementation and that goals have not been compromised. Testing would confirm whether the system is delivering its functionality as per the requirements or not, and the QA ensures that the system hasn’t lost its ability to be a part of the SOA vision it belongs to, in its endeavour to achieve functional accuracy.

The benefits of adopting and delivering a SOA solution are great. For a business facing ever-changing and increasing demands, the returns are high. It also empowers them to deliver a faster product/service development. From an IT maintenance and build perspective, it helps establish improved reusability and easier maintainability. And from a customer perspective, it helps achieve better user experience, better scalability and better services.

 

Search the Assurity website (Hit ESC to cancel)