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 can as 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.