Project Management Pitfalls within SOA

Hi everyone. When the request came through to address the topic of project management within the context of SOA (our sixth part in our 10 part series), we could not think of a better person who works at the coal face, as Anton Gouws. Anton is our SOA Domain Lead for Oracle Consulting in APAC...

Project Managers: Know thy SOA

I have come across very few people that have really understood that SOA is not about solving an integration problem, but really about solving some very fundamental business issues (e.g. business agility, reduced maintenance cost, visibility of information, etc). Once people understand how a Services Orientated Architecture (with the focus on Architecture) is able to do this, their whole approach to implementation is changed. This is not rocket science but so few project managers (and customers) really understand this and it often leads to a host of SOA Implementation failures. For those of you that are still in the dark, I would urge you to have a look at the following SOA Video on YouTube.

Not understanding the principles of SOA by Project Managers often results in the following 2 key SOA Project Management mistakes. Now there are plenty more, but these are really fundamental to most issues:

Mistake 1: SOA without the Architecture
I can recall many Oracle Application projects, where I have been called in to help the team with their SOA implementation. On arrival at the site it becomes very apparent that this “SOA thing” is being equated to solving their integration issues. The Project manager also typically thinks that they are delivered on their SOA project commitments through the service enablement of the integration touchpoints. In my mind this is a BIG mistake, a massive opportunity loss for the customer and an outright project failure. On these projects rather than creating an architecture where common functionality (e.g. Credit Checking, Creation of an unique Customer across the organisation), business rules and information is available for all to use across applications and the organisation, they are perpetuating another silo’ed implementation that offers very little in terms of business agility and flexibility.
Below is a small checklist that you can go through to determine if your SOA project may not be using SOA architectural principals:

1. Your integration team has never seen the business process that their integration code is suppose to support.


2. No one is insisting on common functionality to be made available to the rest of the organisations.


3. No one is fighting about ownership of data (e.g. customers, products, assets) or who is going to pay for the development of the service.


4. No one is asking about the service lifecycle management.


5. There are no canonical data models.
   

Mistake 2: Silo’d Teams
Having worked on many SOA projects, the most successful SOA projects that I have seen, typically follows a more Agile approach to project management (typically using Scrum). I believe the reason why this approach works so well on SOA projects is because it allows people across the project to rally around a particular activity (or business process) and provides the framework for rapid iterative development. This allows all the developers and business users to collaboratively work together to get the task at hand completed and breaks the traditional boundaries between the development communities (SOA Developers, Legacy Developers, Oracle Applications Developers, etc). Although this sounds easy enough, it is actually very difficult when you consider that many of your resources may be working off-shore and in different timezones and that communication issues across geographies are plenty. However these communication barriers have to be broken down for your SOA project to be successful and the communication to flow freely between team members.