Getting Independent Advice

Last Tuesday we got a couple of consultants from interstate to advise us on how my organization is sailing with its initial steps toward SOA. Their brief was fairly broad. They spent a couple of days meeting with various groups including management, legacy developers, java developers and architects.

The idea was to get some idea of what we are doing wrong, what we doing right and what we should do in the future. This is a good thing to do if you can find respected practitioners who can provide this advice. It is easy to be insular and head off in your own direction without considering other options. This can apply to the organization, to groups of organisations and it can even apply to whole regions. I always object when the Federal Government or the eastern states regard South Australia as a regional outpost, but when it comes to best practice in IT we have to acknowledge that our expertise in major enterprise application development can be thin.

I was involved in a few of the meetings. I expect them to focus on our run-time stack, our development standards and development methodologies. The major focus was on our legacy software. This is a big problem and one which I was happy for them to take head on. We have many large systems written on the mainframe in technologies that are out of date and do not easily lend themselves to being accessed through services. The few tools that are available to assist are prohibitively expensive.

The report from the consultants has not come in yet but I was able to glean areas that the consultants seemed to be targeting. One was how to address issues such as Data Integrity, Process Integrity, processing exceptions and auditing in relation to making providing services using our legacy applications. These are the concepts discussed in chapter 8 of Krafzig et al "Managing Process Integrity". They are common application integration problems which pre-date SOA and they are the sort of problems that do not yield to simply adopting particular middleware or standards.

The other issue that the consultants were targeting was how much we were investing in our SOA. We are trying to fund SOA by paying for infrastructure and the development of skills out of project funding for the development of particular applications and enhancements. This may not be sufficient to get the critical momentum we need to get to a desired maturity with our SOA. It would be a good outcome if our independent advisers can report to our executive that we need more money specifically for SOA. It is a bit hard to do this from the perspective of the IT Department. The executive would suspect we were investing the money for no good business reason, perhaps just for buying new toys for IT. The opinion of the consultants may help to put our case.

Of course the consultants might be hoping we spend more money on them. We have to be on lookout for such bias in consultant findings. In general though it is always valuable to get a second opinion and I eagerly await the report from this exercise.

Reference

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004