An offshore ‘SOA Service Factory’ is the ‘delivery-arm’ that is primarily responsible for developing reusable services in a cost-effective manner, using SOA products. The team implements shared services taking specifications provided by the SOA CoE, refining these and working with multiple project teams, who stitch together these services into project-specific solutions for a customer. The Service Factory is therefore a delivery resource used by project teams accessing or developing shared SOA services.
Some obvious benefits from the service factory model:
- Applications would be highly componentized on a wide-spread, cost-effective basis.
- The focus of the core client team would be on integrating services produced in large numbers, rather than on churning out these services
- The adoption of such a model would mandate solid standards to be introduced in the very early stages, robust planning and a solid governance structure
- Services would become the pervasive fabric of all applications leading to highly integrated processes in lesser time owing to a large factory dedicated to producing them
- Increased manageability through smaller dedicated work streams enables the IT team to contribute directly to business agility and innovation
Need for an offshore SOA service factory
Considering the evolutionary, incremental nature of SOA, involving an ongoing conversion of services that increasingly perform autonomously, funding and production of these shared services would need to be planned for upfront as part of the Governance strategy. Typically, their production would either be funded centrally or the first project to use a shared service would fund it and would receive a greater share of the budget to cover the production. In either scenario, the decision on production of services and funding them becomes far more important if the services are shared.
The offshore SOA service factory enables building ongoing shared services cost-effectively and centrally addressing the challenges of funding and production. The service specification and high-level design activities are typically handled onsite while the actual implementation of shared services, testing and delivery are conducted by the offshore service factory team as detailed in the sections below. The offshore SOA service factory team is typically trained for building reusable, shared services, which require a different set of skills compared to building for one-off use and similar requirements.
A separate whitepaper titled ‘SOA implementation with an offshore partner’ available for download, explores the model of offshore service collaboration in more detail. A few excerpts from this whitepaper may be relevant in this context: “The nature of SOA mimics the model of offshore development where services are provided on demand for finite discrete parts of the whole. These units of service are atomic, created as single reusable units of logic that can be combined when required to fulfill business functionality. Therefore the model of constructing such units in offshore locations, within tightly defined parameters of construction and acceptance, mirrors the eventual use of these independent units in a business model. It permits finite parts of the project to be executed overseas under fixed prices and adhering to mutually agreed upon service levels, facilitated by the adoption of standards”.
To de-risk a typical SOA project and to reduce longer time-to-market, the production of shared services is typically divided into several work streams, executed by smaller teams dedicated to each work stream, enabling better coordination as depicted below.
The structure of a typical SOA service factory and the division of responsibilities among the work streams is summarized in the sections below.
SOA Service Factory Model
The structure of a SOA service factory is typically customized for specific organizations and focuses on components, services, frameworks and tools for automation. The services produced by the factory are integrated into the project portfolio as depicted below:
Typically, services are realised by exposing and stitching together functionality that exists in the customer’s back-end platforms and by creating new functionality as needed. The onsite Service Factory team has highly skilled designers who design services applying core SOA API design principles. The design team ensures the service contract is agnostic of the service consumer to help reuse SOA services across applications. The structure of a typical service factory is represented below:
The service factory manager would hold overall responsibility for successful coordination among the architecture, support and project groups for service production, deployment and documentation. A more detailed depiction representing the onsite and offshore roles is as below:
The service factory provides end-to-end application management for the services built. The delivery team in the Service Factory is typically divided into three silos, with each silo being self-contained teams consisting of developers and testers. This model is adopted to facilitate agility through smaller teams. The three work streams each consists of onsite and offshore members divided as above.
The reusable services are identified, service specification formulated and services are designed onsite. Services are typically designed to be long-lived such that they are not required to be modified or re-tested often by consumers of the service. In instances where there is such a need for alteration of the service designed, the SOA CoE coordinates service change and retirement of the old version. The high-level designs are then shipped to the offshore team. The offshore stream leads draft low-level designs for approval by the customer and these designs are then translated into code. The services implemented in this manner are tested offshore (functional and system tested) and delivered/released to the onsite team through VPN connectivity. A central version control system is accessible to both the onsite and offshore teams to ensure smooth coordination of activities.
An agile delivery model could be adopted for shared services delivery so as to implement a prioritized, time-boxed approach to deliver the most important functionalities in the initial iterations. This would also ensure the onsite and offshore teams work intimately on the deliverables. A typical break-up of roles in each work-stream is as depicted below:
Following are some typical activities in-scope of the Service Factory:
- Architectural Support and ongoing SOA program consulting.
- SOA Service Design, design of SOA services using tools and products identified by the customer
- Delivery arm, responsible for the development of services and portlets.
- SOA Testing, helping to automate and bring in the differentiation of a “SOA-aware” testing team.
- Assistance in run-time Governance, use of tools and monitoring
- Integrating Business Rules within the SOA Platform and ESB
- Stitching services into the project portfolio
- Active participation in Knowledge Management of SOA Services by documenting service design and development practices in Wiki
- Build and release management: follow an efficient and reliable build and release process.
Torry Harris recommends the ‘Distributed Agile’ delivery methodology (http://www.youtube.com/watch?v=vMTDfhKvSDE). Services could be developed within short Agile Sprints, where each Sprint could have a maximum duration of 2 weeks.
Specific aspects of Agile that could be implemented as part of the SOA service factory:
In distributed agile, ‘Team Integration’ plays a significant role and helps overcome challenges related to a geographically dispersed team. The integration is an ongoing activity. Some of the activities could be: visits by the client senior management to Torry Harris offshore, where they spend time with the core technical team and Torry Harris’ management team. These visits help to understand and appreciate the client’s vision and roadmap.
During the early stages in a project, the entire technical team is collocated onsite at the client location. In a phased manner, the team is then distributed to reflect an onsite/offshore model. With a planned rotation of resources, the communication channels are strengthened.
SOA Driven Iteration Planning
Taking in from the principles of SOA and Agile, the delivery iterations are planned to deliver discrete services. The services are typically a combination of standalone, composite, data, integration and presentation services. Further, the iteration apart from delivering the services also delivers the associated user interfaces so that end-to-end functionality is made available to the User community for testing. Iteration usually spans two weeks on completion of the Design phase.
Team Composition by Functionality
The delivery team in the Service Factory is divided into silos, with each silo being self-contained teams consisting of developers and testers.
Cruise Control could be used with a process for daily check-in of the developed code and overnight builds. This process would help capture integration related issues owing to a large team.
Immediate Feedback on Functionality
There could be permanent representatives from the business side involved from the start of the project. During the requirement analysis phase, group meetings could be held. Based on the MoSCoW technique, requirements are prioritized which then translates into iterations. During the course of the iterations, the business members need to be available to conduct tests on the intermediate releases and provide immediate feedback, enabling quick turnaround time for changes.
There is a misconception that in Agile, documentation can be compromised. On the contrary, the documentation requirement is reviewed with the client and the right amount of data to be captured is agreed upon upfront. Further, the documentation approach could involve the use of a wiki, wherein, the distributed team independently documents the services they work on.
Large SOA initiatives that seek transformational benefits should consider exploiting the offshore service factory model that enables realization of cost-effective, shared services for ongoing work. The implementation of such a model helps leverage every opportunity to consolidate functionality and manage cross-enterprise project needs, allowing greater efficiency in managing costs and better overall service to business.