I have seen enterprises struggle with adopting SOA whereby attempting to define and develop services using their existing development methodology and their exists development organizational structures. I will tackle the topic of service engineering development methodology in a future blog. In this blog I want to cover some work I have done around organizational structures for development teams who are developing services.
On many occasions I have recommend to enterprises to separate the development of applications from the development of Services as each approach can utilize a different development methodology and ease the option of outsourcing.
Below are samples of the possible organizational patterns that can be used to address Service engineering structures.
Embedded Service Factory
An embedded Service factory is regularly used in initial SOA project efforts and small SOA initiatives.
This model provides a single unit that is responsible for producing Services for “each project team” and is considered part of the project team to which they are assigned. They alleviate project management reporting concerns and the high response needs of a project.
It is important that each embedded Service factory communicates with the Service advisory council to maintain a strategic focus by balancing short-term goals of individual projects and long term SOA goals.
Early on in a SOA initiative, it is common for a Service factory to be deployed within the LOB where the project/program is being executed. But as more LOBs develop SOA solutions, they in-turn will want to deploy their own Service factory.
This is initially fine but as more LOBs come online the communication, alignment, resource, and skills needs becomes a burden; therefore a centralized Service factory can be utilized. Service Advisory Council assists in maintaining a strategic focus by balancing short-term goals of individual projects and long term SOA goals.
Shared Resource Service Factory
Shared resource service factories are regularly used in SOA initiatives where SOA skills are at a premium and there is an increasing adoption of SOA projects across the enterprise.
This model provides resources at the central IT level to support individual project specific producer requirements while increasing resource sharing opportunities. It also allows skills and resource sharing between Service factories while still having a focused services delivery team. This leads to improved customer relationship and increased customer responsiveness.
Enterprise Service Factory
The enterprise Service factory model is used in more mature SOA initiatives with considerable enterprise adoption.
This model provides a unit that is responsible for producing and maintaining Services for the whole organization. The enterprise Service factory is sub-divided into specific business and/or technology areas for better skills and Service classification focus. This leads to an effective environment to foster business and technology knowledge in IT staff via rotational opportunities.
As with any example, it is intended for you to take these examples and customize to what makes sense in your environment. Another key area within a SOA initiative is the topic of change management. Hopefully in the future I will be able to cover this topic.
Good Luck, Now Go Architect…