Managing SOA Projects: Governing Project Teams

After a successful SOA pilot project, managing SOA projects is the next step; you need to roll-out the SOA initiative more broadly to a larger audience of developers and project teams. There is a lot of new information for these teams to learn, and many pitfalls of which they may not be aware. For example, services built by these teams may use a non-standard approach to security and they may not be WS-I profile compliant (the WS-I defines "profiles" which clarify standards ambiguity to ensure interoperability across platforms), or they may be technical as opposed to business-centric. These types of issues can become barriers to the overall SOA initiative as they make it more difficult to leverage the existing services.

There are a number of approaches to addressing this:

• Training: First and foremost, training teams on using the new tools and technologies is essential. Training on best practices and pitfalls is also essential. For example, training developers that relying on the use of time zones in "date" data types can impact interoperability.
• Infrastructure: Your choices of infrastructure software should be able to offload the development teams from having to make decisions that impact interoperability. For example, the infrastructure used for projects may offload the developers from needing to code security, auditing, management, etc. into their application. Not only does this make it easier and faster for them to roll out services, but also enforces corporate standards automatically.
• Tools: Tools that developers can use while building their services can aid them in performing automated checks for issues. For example, there are tools available that can help developers confirm that their service definitions (WSDL) are WS-I compliant as they build them.
• Checkpoints: As a final stage, your process should define checkpoints where you can validate that services are appropriate. These checkpoints should be placed at a point in the process where they cannot be easily bypassed by someone in a hurry. For example, the process of publishing a service in a registry may be controlled by requiring approval – this becomes a natural checkpoint. At these checkpoints you can perform automated assessment for common issues (such as services not being WS-I compliant or not following best practices about schema design) as well as manual reviews for checks that cannot be effectively automated (e.g. use of corporate approved schemas where appropriate, or service granularity). Of course, catching an issue at this stage is costly – it may require that the service be significantly rewritten or redesigned, introducing cost and delays to project delivery. As such, this should only be relied on as a last resort – your processes should be designed to address as many issues as possible up front (using training, infrastructure, and tools) to avoid wasted effort.

Many of the points raised about checkpoints and infrastructure have given rise to the popular subject of governance. Today a lot of the focus on governance is around how to architect, design, develop and deploy services. But this is only half of the governance issue. The other half occurs in the runtime environment and ensures that services are actually operating and driving the business as intended. These two parts of governance need to be addressed together understanding which parts of governance live in pre production, those that exist in runtime and those that span both.

In summary, managing SOA project teams boils down to some key concerns: training issues, the choice of infrastructure and software tools – and process elements (with a special focus on runtime governance).

More Information on How to Manage Your SOA Project

Learn the secrets of successfully managing SOA projects, read the free white paper, SOA Infrastructure: Strategies for Meeting Global Enterprise-Class Challenges