SOA Implications 3rd in a series
by
Charlie Bess
There are a number of implications of SOA that are not talked about much by the SOA vendors. They paint this rosy picture that could change quite rapidly after being in production for a while. With this entry I thought I'd discuss some of these implications:
1) Methodology - I hear some of the vendors talk about how all the SOA services need to be developed using pure iterative methodologies and that worries me. For an enterprise using existing services or creating leverageable enterprise components, there needs to be an effective mix of contract based (rigorous) and iterative development. For some of the foundational components of an organization, you can't afford to purely iterate. Are you going to make new versions every time you have a new consumer of your services? I'd doubt that the current consumers would appreciate going through another round of testing to ensure that their code works with these iterative changes. You do need to be careful not to have so many services (methods) that no one can figure out why they all exist.
Sure you can iterate when creating the contract, but once you define the contract you need to at least try to lock it in and create test models...
On the other hand, when you are assembling a solution from existing services, you will want to iterate with the customer, especially when the customer does not know what they really want.
2) Workforce - The development processes should focus more on delayed application assembly. Although components can be created remotely (off-shore), the custom assembly process may require higher levels of interaction with the user than a remote development team can support.
The communications may be too complex and dynamic. This will likely bifurcate the development team into industry assemblers and head down coders. As Model Driven Development techniques come into play, this will also change the dynamics of the workforce, particularly the head down coders.
3) Skill-set - Business Analyst functions will be in higher demand for SOA. In-depth industry knowledge will be needed to talk with clients and effectively assemble the desired functions. These analysts will need to be backed up by fewer architecturally strong technology specialists to ensure operational performance. The component/service creators will need to be experts in the creation and optimization of the components themselves. The project management skills for the back-office component creation will be more rigorous than those needed for the assembly process, which will need to flex through the interaction with the end user.
4) Governance - Organizations that adopt service oriented architecture techniques will need to have a more disciplined approach to the promotion to production process. They will not be able to afford to have each department have its own release schedule, otherwise every day that any organization releases a modification to their service it could be filled with unexpected side effects. Organizations will likely need to move to a block point release schedule in order to effectively test and deploy solutions. There can not be a "departmental" enterprise service.
5) Tooling - The Achilles heal of the object-oriented paradigm was: in order to be truly effective you had to understand the gestalt of all the classes available to you as a developer (grok). With the number of classes and methods available to your typical developer that is a tough task to master. This fact is one of the many reasons there is such a wide disparity in performance between the best developer in an organization and the average developer.
With SOA, this hrair limit problem is reduced by at least an order of magnitude, but is still there. This time, you need to understand the contracts for the services from a holistic perspective. Tooling will need to address this at the enterprise level, by helping the developer focus their search quickly to services that meet the current need.
6) Simulation – by definition services will depend on each other. Just because it works in a development or model office environment does not mean that it will survive the complex environment of production. Just because a service was designed to provide the result, it does not mean it will supply the result at the volume level or with the required degree of latency. The concept of the SOA contract needs to be developed more in this area.
I believe these are inherent to the concept of SOA, and are not effectively being addressed in the marketplace. I'd be interested in hearing about others perspectives...
