SOA : The very basics

SOA is one of those subject areas I’ve read a lot about of late.  I’ve delved deep into this topic to really grasp an understanding of what the topic entails and fundamentally what it means.  There tends to be a lot of guff (my word for ill-informed talk of a popular subject) in and around this topic and so in this article I’m hoping to sort out this guff and give newbies to the subject a bare bones definitive explanation.

A second reason why I wanted to write a bit about SOA is that I’ve heard twice this week the term ‘SOA Server’. Now whilst I understand what is trying to be conveyed (most likely a reference to an Enterprise Service Bus), it’s not like there is a single server product that just ‘does’ SOA in the same way your DNS server resolves IP to host names or your DHCP server ensures your network hosts have an IP address handed to them.

SOA what is it then?

SOA for the absolute beginner stands for Service Orientated Architecture. The name itself provides a clue to its fundamental meaning in that it’s an architecture for your Information Technology systems. Essentially it is the design and construction of service based IT.

Services are everywhere in our daily lives as our list below demonstrates:

1) The ATM provides you with a cash dispensing service

2) The sandwich shop offers you a sandwich making service

3) The courier offers you with a delivery service.

We just forget that we are being offered services every single day.

Using our example above of the ATM, Sandwich Shop and Courier services, it’s important to remember that not only are these serving us as customers but they are offering services to each other to enable their businesses to thrive. The sandwich shop clearly requires cash from an ATM to ensure that sandwich provisions can be bought and in certain cases the courier company services the sandwich shop by delivering the sandwiches to hungry customers. The ATM maintenance chaps also need to keep their energy up and so the sandwich service is a regular means of satisfying those lunch time hunger pangs. Whichever way you look at a scenario, services are provided and consumed by each other. In short, services consume other services to provide services and ultimately this is the goal of a Service Orientated Architecture.

Condensing what Service Orientated Architecture is into a single sentence I would say that it is An approach to building component service based IT systems.

SOA as a strategy

The more commonly used term used (instead of ‘approach’) is ‘business strategy’. SOA is one of several Business Strategies that ultimately result in a more effective running business because business change leads the way instead of the business being controlled by ‘what the IT can do’.

Having large complicated systems that don’t really talk to each other and invoke large costly ‘change’ projects that take months to complete is not an ideal scenario for a business that needs be dynamic. When I say dynamic, I mean having the ability to change with the market as well as change internal business processes without the need for long drawn out IT projects. Large costly systems are the shackles of business change and so taking a component service approach to designing IT systems is the key to freeing businesses from these shackles.

Employing a Service Orientated Strategy will allow the business to drive change and not the other way around. IT and the Business are more in line with each other.

Taking a SOA approach.

Now it’s clear why SOA is an important strategy to invest in, we need to know in what way SOA can help obtain this goal of a Business Driven IT Infrastructure.

The main goals of SOA is to allow IT to create component services using the latest frameworks (J2EE, .NET, Oracle Fusion, SAP Netweaver) and key technologies (XML!), leverage current IT assets that a business has already heavily invested in and to re-use services in a Lego brick type way. Re-use of already written services means that you write less code, there is less code to maintain when a service needs to change when being consumed by a bigger application, support for that application becomes simpler because change to a service component needs to happen in one place only.

Component services doesn’t mean just ‘Web Services’. Web Services are a type of component service but the main point of component services to wrap more bulky logic (normally old legacy systems) into simple service endpoints that do as little as possible (lots of tiny services doing lots of useful jobs means that other services can build on these and offer a greater level useful services).

Web Services

It would be criminal to leave the scene of a SOA discussion without covering the topic of web services and how they are changing the way companies interact internally (between systems) and globally with customers and partners. Web Services are a type of component service that should really be called ‘Business Services’ as they expose business logic over an inter-enterprise or global network. This has opened the door for disparate system interaction by connecting completely different systems through a common communications method using open standards. Essentially the introduction of web services has completely changed the landscape in terms of business to business interactions and internal systems interaction.

Since web services use HTTP and open standards such as SOAP to communicate, the consuming and providing systems do not need to understand anything about each other. You may have a SAP ERP system talking to an external .NET based ordering system and either doesn’t need to understand what the other is doing behind the scenes. All the consuming service needs to know is what information it needs from the service provider and in what format (the message) it needs to request it in.

Amazon has several exposed web services that allow you to query their catalogue. One particular web service allows a web service client to provide a product code and have a price returned instantly for that product. Many sites on the web today use web services transparently so you will never really know how much web services use you really do use.

Web services are the future and a major part of a SOA strategy.

SOA and Business Process Management

BPM, SOA and EAI are 3 of the most commonly used acronyms in my field. They are big areas of focus on many of today’s IT roadmaps as they are areas that are very closely aligned, but understanding the differences is important. Business Process Management is part of a good SOA strategy and can depend on the Enterprise Application Integration domain for improving system to system or user to system interaction for business processes. They interoperate as area’s of focus but understand that BPM and EAI are sub activities of SOA. Making improvements to business processes and connecting your systems are goals that should be detailed in a SOA strategy. SOA should be the umbrella strategy for BPM and EAI projects.


SOA is changing the face of business and IT interactions by improving relations, lowering the cost of supporting the IT engine and reducing the need for major cost investments in large packages by developing in-house systems on a component services foundation. My intention in this article was to literally touch the service of SOA, it is a large area and the tools used as part of the strategy are a plenty so please dig deeper into SOA and understand it from a day-to-day systems perspective and how it is helping in making the goals detailed above a reality.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s