To follow up on the post about SOA from the other week, one of the SOA related things I find myself discussing with customers / colleagues / people in general, again and again is whether there is an equal sign between SOA and Web Services?

Put in another way – do you have to have Web Services in your architecture to be able to give it the big SOA label?

No.

… as such the post could end there, but OK, let’s dig a little deeper into things.

Am I against Web Services? No, that’s not it. Web Services are great and the right solution in many scenarios. They are easy to implement and have the ability to work across platforms – when implemented correctly.

The problem is that for years already whenever there was a need to expose a service there has been a tendency to default to achieving this through implementing a Web Service. Often without considering what’s already there.

I have even seen cases where a certain operation existed within a legacy system but because it wasn’t exposed in a satisfactory way (read through a web service) and that wasn’t possible from the legacy system – the entire operation was reimplemented and exposed in the wanted way.

As I wrote the other week, to me, one of the important points when designing a SOA architecture, is to utilize existing functionality. This also goes for interfaces. If there is a way to access existing functionality – be it through an old API, a stored procedure or even exchanging files – if it meets the requirements utilize the existing interface.

Of course the old interfaces will often come short some way or the other when presented with an up to date set of requirements, and then we can implement a new interface and if there is really no other way, the entire operation behind the interface.

And then I agree that web services might be the better, faster approach to a new interface … or is it!? WCF is looking good, more on that in the future.

These days I get to talk a lot about SOA and it excites me – it truly does – so I keep on talking.

To me one of the most important things when defining a SOA architecture is not really to do with technical aspects at all but the entire mindset around it. Unlike a pattern or a best practice I don’t think there is a step by step way of getting from ‘We want a SOA architecture’ to ‘We got a SOA architecture’. Instead you have to get your mind on the right track and think the right thoughts in a number of ways.

I have the following suggested guidelines that we always try to go by when approaching a new project at Vertica A/S – also none SOA ones, so feel free to apply the approach across all your customer engagements.

Think in business processes and in how to support and optimize them. Think in combining and utilizing different services and operations from across the IT landscape to help make the processes flow.

Utilize the existing components already found within the running systems. SOA is very much about exposing and utilizing already existing functionality from within legacy systems instead of re-coding. Involve people who know these systems.

Involve the business users as early and often as possible. No matter how much you try to see things from their perspective you’re never going to be as good at it as they are themselves.

Ask their opinions and get their requirements directly from their own mouth – yes meet with them! Try to explain things to them so they actually understand what’s going on. More often than not this will help the project as you might discover things that aren’t really making any sense because you simply can’t explain them.

Ensuring the involvement of business users this is normally one of the best ways to ensuring an actual feeling of value and success in the business.

Support real needs but prepare for the future when defining a scope for your project and designing a solution to support it. Do not insist on implementing a lot of not needed features, but listen to the customer and meet their actual requirements all the while you’re not allowing the existing needs be too much of a limitation for your design and always suggest improvements where you see fit.

It’s all about finding the very thin line – and remembering that no matter how flexible a solution you implement there will be unforeseen surprises in the future.

I am aware that being a consultant you have a wish to sell as many hours as possible but more often than not delivering the right solution is better than delivering the biggest solution – in the long run this will typically give you a happy customer who keeps coming back.

Challenge the customer whenever you can and have a valid and well argumented reason. You’re job is to ensure the customer the best possible solution – not to accept everything they say! It is always going to be healthy to be challenged on your ‘beliefs’ also for your customer.

Take things in small steps if you canas opposed to a ‘big bang’ approach. Deliver often and focus on the areas where there is the most to gain. Choose one business process / use case and implement (if needed) and expose the needed services to support that. Do not insist on building up a complete service library for all process in your customer business before deploying anything to production.

At the end of the day SOA is little more than a new label to, what I believe has always been the core of the IT business. Working together with the customer on getting even more value out of their IT systems – existing and new ones.

Perhaps the most important part is the strong focus on exposing operations and services – again existing and new – and combining them across systems to support the processes of the business.