SOA has a rather bad reputation among CFOs nowadays.
The huge high front investments and the absence of resulting business value of big SOA implementations are the blame for this. But SOA is still a very important part of an IT strategy. What’s really needed is a more pragmatic approach to SOA.
Let’s imagine you custom build a website to serve your customers, a Customer Portal. Going back to Geoffrey Moore’s Core/Context model, your Customer Portal seats on the top left quadrant and usually performs a function that is part of your competitive advantage.
Let’s further assume that along with your website you’ve built a sophisticated provisioning process to fulfill orders and capabilities to send to your customers' reports by email on the status of those orders and other information. This is a function that you didn’t have available in your existing systems and so you had to build it in the context of your website project.
Now let’s imagine that you decide to implement a new Call Center application to further leverage the differentiating capabilities provided by your website.
Turns out that most functions the Call Center needs are already implemented on the portal, namely the order tracking and provisioning process.
It’s these events, when you discover that parts of an existing system can be reused by other systems that are decisive moments in keeping the health of your enterprise architecture. The best option for you here is to go back to the portal, carve out the shareable or reusable components, expose their functionality as services and reuse the components on your next project. If you do this constantly, you’ll end up with a SOA environment that is built incrementally and is based in real needs for real services.
So why don’t we see a lot of companies do this? Why do they always try to imagine what are the services that are going to be reused in the next 3-5 years? Because the refactoring part is hard. Refactoring is the equivalent of surgery, where you slicing away a piece of the system. When you refactor, you risk destabilizing the running applications and you risk introducing bugs into the software.
The solution to dramatically reduce the risk of refactoring is three-fold.
First, you need tools that enable you to refactor your software without disturbing the running processes and that enable you to quickly re-glue your systems back together.
Second, you need to have a regression tests strategy to make sure that refactoring doesn’t change the way the system behaves.
And finally, you need to have your architectural team constantly help project teams defining what is refactored and what is reused.
At this point, your CFO is probably unwilling to invest more money on SOA, so it makes no sense presenting the huge budget on that area.
Instead, you need to use these arguments to explain that each project needs a bit of extra budget for refactoring and testing and that you need to invest in tools that will make your refactor and reuse strategies successful.
On my next video, I will show you how these refactor and reuse strategy ends up by keeping your custom software projects and maintenance under control.