Agile Offshore Development with SOA · Modern Offshore Development Agile and SOA The Agile...

16
Agile Offshore Development with SOA

Transcript of Agile Offshore Development with SOA · Modern Offshore Development Agile and SOA The Agile...

Torry Harris Business Solutions Inc, a US based services provider

with a large base of technologists located in the UK, India and

China has provided cost effective solutions at a design,

development and support level to a variety of enterprise clients

across the world since 1998.

The company specializes in integration, distributed computing,

and its focus on SOA is a result of nearly a decade of expertise

gathered in the middleware space.

The company has partnerships with almost all the leading SOA

and integration product vendors.

SOA, involving the creation of autonomous parts of a solution,

lends itself admirably to the cost effective model of offshore

service collaboration.

A separate white paper entitled “SOA Implementation with

an offshore partner” available for download, explores this model

in a more detailed manner.

Further information about the company and a variety of white

papers on SOA are available at www.thbs.com/soa.

For more information, write to us at [email protected].

Agile OffshoreDevelopmentwith SOA

Introduction.................................................................................................................................. 4

Modern Offshore Development................................................................................................ 5

Benefits...................................................................................................................................... 5

Risks............................................................................................................................................ 5

Agile and SOA.............................................................................................................................. 6

The Agile Development Process............................................................................................ 6

Service Oriented Architecture............................................................................................... 8

THBS Best Practices.................................................................................................................... 10

Team Integration................................................................................................................... 10

Team Composition by Functionality.................................................................................. 10

SOA-Driven Iteration Planning............................................................................................. 11

SOA-based Continuous Integration.................................................................................... 11

SOA and Test-Driven Development..................................................................................... 11

Immediate Feedback on Functionality............................................................................. 12

SOA-Driven Documentation................................................................................................ 12

Conclusion................................................................................................................................. 13

References................................................................................................................................. 14

Links............................................................................................................................................. 14

Table of Contents

2

Introduction.................................................................................................................................. 4

Modern Offshore Development................................................................................................ 5

Benefits...................................................................................................................................... 5

Risks............................................................................................................................................ 5

Agile and SOA.............................................................................................................................. 6

The Agile Development Process............................................................................................ 6

Service Oriented Architecture............................................................................................... 8

THBS Best Practices.................................................................................................................... 10

Team Integration................................................................................................................... 10

Team Composition by Functionality.................................................................................. 10

SOA-Driven Iteration Planning............................................................................................. 11

SOA-based Continuous Integration.................................................................................... 11

SOA and Test-Driven Development..................................................................................... 11

Immediate Feedback on Functionality............................................................................. 12

SOA-Driven Documentation................................................................................................ 12

Conclusion................................................................................................................................. 13

References................................................................................................................................. 14

Links............................................................................................................................................. 14

Table of Contents

2

It has been a long way from the tayloristicwork models of the early 19th century tothe advanced toyoistic work models ofour time which include concepts such asContinuous Improvement, Kanban, andJust in Time Production (JIT).

In parallel, many industries havealready undergone massive re-organizations and optimizations of theirvalue chains.

It often seems as if the IT industry is stillstuck in the early phases of theseprocesses.

However, it is unquestionable thattoday’s constant cost and efficiencypressure is also forcing our industry to lookout for similar ways to improve ourproduction methods and to optimize theIT value chain.

Offshore-development with thepromise of cost efficiency and resourceavailability has been looked at as away to optimize the IT value chain byoutsourcing tasks like implementationand maintenance.

However, in the past many customershave looked at quasi-tayloristicproduction methods in offshoredevelopments, often centered onwaterfall-like development models.

Similar concepts could be found inother industries decades ago.

However, modern supply chainsrequire a much higher degree in flexibilityand efficiency.

Hence, many vendors have inventedmodels which are better suited insuch situations.

For example, many car manufacturersare now allowing their suppliers to puttheir own production facilities directlyinto the car manufacturer’s factories.

This kind of tightly integratedproduction and supply chain is aprerequisite to make concepts such asJust in Time production possible.

In the same way opportunitieslie ahead for business organizations andtheir IT.

Agile development methodologiesand Service-Oriented Architectures(SOA) will cause major shifts indevelopment strategy, applicationacquisition and systems integration.

This will affect how global IT servicesand solutions providers are able tocontribute to the economic success oftheir business partners.

When brought together, Agile, SOA, andOffshoring will address the primary need fortoday’s business – the ability to adapt tochanges quickly and cost effectively.

This whitepaper presents a set of bestpractices around Agile Developmentand SOA which could help customersto improve ways in which they canmanage their offshore partner in orderto improve cost efficiency, riskmanagement and flexibility.

Introduction

abstractAgile Development and Service-OrientedArchitectures (SOA) will cause major shiftsin development strategy, applicationacquisition and systems integration.

Global IT services and solutionsproviders like THBS bring Agile, SOA, andOffshoring together in order to addressthe primary need for today’s business – theability to adapt to changes quickly andcost-effectively.

This whitepaper presents a set of bestpractices around Agile Development andSOA which help customers to improve theways how they can manage their offshorepartner in order to improve cost efficiency,risk management and flexibility:

�Benefits and risks of modern offshore development

�Efficient strategies to mitigate key offshore risks

�Best practices of THBS to make offshore development more efficient

3 4

It has been a long way from the tayloristicwork models of the early 19th century tothe advanced toyoistic work models ofour time which include concepts such asContinuous Improvement, Kanban, andJust in Time Production (JIT).

In parallel, many industries havealready undergone massive re-organizations and optimizations of theirvalue chains.

It often seems as if the IT industry is stillstuck in the early phases of theseprocesses.

However, it is unquestionable thattoday’s constant cost and efficiencypressure is also forcing our industry to lookout for similar ways to improve ourproduction methods and to optimize theIT value chain.

Offshore-development with thepromise of cost efficiency and resourceavailability has been looked at as away to optimize the IT value chain byoutsourcing tasks like implementationand maintenance.

However, in the past many customershave looked at quasi-tayloristicproduction methods in offshoredevelopments, often centered onwaterfall-like development models.

Similar concepts could be found inother industries decades ago.

However, modern supply chainsrequire a much higher degree in flexibilityand efficiency.

Hence, many vendors have inventedmodels which are better suited insuch situations.

For example, many car manufacturersare now allowing their suppliers to puttheir own production facilities directlyinto the car manufacturer’s factories.

This kind of tightly integratedproduction and supply chain is aprerequisite to make concepts such asJust in Time production possible.

In the same way opportunitieslie ahead for business organizations andtheir IT.

Agile development methodologiesand Service-Oriented Architectures(SOA) will cause major shifts indevelopment strategy, applicationacquisition and systems integration.

This will affect how global IT servicesand solutions providers are able tocontribute to the economic success oftheir business partners.

When brought together, Agile, SOA, andOffshoring will address the primary need fortoday’s business – the ability to adapt tochanges quickly and cost effectively.

This whitepaper presents a set of bestpractices around Agile Developmentand SOA which could help customersto improve ways in which they canmanage their offshore partner in orderto improve cost efficiency, riskmanagement and flexibility.

Introduction

abstractAgile Development and Service-OrientedArchitectures (SOA) will cause major shiftsin development strategy, applicationacquisition and systems integration.

Global IT services and solutionsproviders like THBS bring Agile, SOA, andOffshoring together in order to addressthe primary need for today’s business – theability to adapt to changes quickly andcost-effectively.

This whitepaper presents a set of bestpractices around Agile Development andSOA which help customers to improve theways how they can manage their offshorepartner in order to improve cost efficiency,risk management and flexibility:

�Benefits and risks of modern offshore development

�Efficient strategies to mitigate key offshore risks

�Best practices of THBS to make offshore development more efficient

3 4

Benefits

In the past, many customers looked atoffshoring predominantly as a way ofcutting costs.

While offshore locations are indeedproviding highly qualified technicians andother specialists at low costs, one has toconsider two key factors: the cost fordevelopers and engineers are typically onlya part of the overall project costs.

Furthermore, it must be seen that offshoredevelopment is increasing the complexityand hence the costs and risks of adevelopment project.

It is important that the customer and theoffshore provider agree on realisticallyachievable cost savings.

THBS often helps customers reduce theirdevelopment costs by 20-30%.

Also, it is important that the customer andthe offshore provider are jointly developingmethods to address the pitfalls of offshoredevelopment, such as the ones presentedin this whitepaper.

In addition to the cost benefit, manycustomers are today looking at offshoreprovider as a means to improve flexibilityand in particular to overcome localshortages of skilled resources.

For example, if a customer is successfulin outsourcing maintenance and supportfor a legacy application to an offshorelocation, this means that he can free uplocal resources for new projects.

Also, being able to tap into offshoreresource pools means that a customer canmore flexibly ramp projects up and down,allowing him to manage his projectlandscape in a more demand drivenmanner.

Figure 1: Agile, iterative development allows to deal with unclear requirements in the early phasesof a project (© oose Innovative Informatik GmbH 2006)

Agile Software Development metho-dologies emerged in the mid-1990ies as acounter-position to the traditional waterfallmodels, which dominated the IT worlduntil then. The waterfall approach wasincreasingly seen as problematic, becauseit was largely seen as bureaucratic, slow,demeaning, and inconsistent with the wayshow software developers should performtheir work to be most efficient.

A key problem of the waterfall model is the

inflexible division of a project into separate

stages, which requires specifications to be

complete and stable in an early stage,

and causes problems in particular in

situations where requirements are

changing throughout the project or are not

100% clear in the beginning, which is almost

always the case in complex IT projects.

Modern Offshore DevelopmentAgile and SOA

The Agile Development Process

Risks

Of course, offshoring is not without risk,like any IT project. There have been manydifferent statistics on the failure rate of ITprojects in the past, some putting thenumber of failed projects at over 50%(see [Sta05]).

However realistic this number may be,the fact remains that IT is a risky andcomplex business, and adding offshoringto the equation is not reducing thecomplexity.

In a recent report, Gartner Group hasidentified the following key offshore risks(see [Gar]):

�Missed cost savings goals

�Quality problems

�Cultural differences and communication problems

�Legal issues

�Loss of control

We at THBS understand these risks, andwe continually work together with ourcustomers to ensure that these risks arecontrolled and managed in the bestpossible way.

This whitepaper outlines some efficientstrategies to mitigate these risks efficiently.

5 6

Benefits

In the past, many customers looked atoffshoring predominantly as a way ofcutting costs.

While offshore locations are indeedproviding highly qualified technicians andother specialists at low costs, one has toconsider two key factors: the cost fordevelopers and engineers are typically onlya part of the overall project costs.

Furthermore, it must be seen that offshoredevelopment is increasing the complexityand hence the costs and risks of adevelopment project.

It is important that the customer and theoffshore provider agree on realisticallyachievable cost savings.

THBS often helps customers reduce theirdevelopment costs by 20-30%.

Also, it is important that the customer andthe offshore provider are jointly developingmethods to address the pitfalls of offshoredevelopment, such as the ones presentedin this whitepaper.

In addition to the cost benefit, manycustomers are today looking at offshoreprovider as a means to improve flexibilityand in particular to overcome localshortages of skilled resources.

For example, if a customer is successfulin outsourcing maintenance and supportfor a legacy application to an offshorelocation, this means that he can free uplocal resources for new projects.

Also, being able to tap into offshoreresource pools means that a customer canmore flexibly ramp projects up and down,allowing him to manage his projectlandscape in a more demand drivenmanner.

Figure 1: Agile, iterative development allows to deal with unclear requirements in the early phasesof a project (© oose Innovative Informatik GmbH 2006)

Agile Software Development metho-dologies emerged in the mid-1990ies as acounter-position to the traditional waterfallmodels, which dominated the IT worlduntil then. The waterfall approach wasincreasingly seen as problematic, becauseit was largely seen as bureaucratic, slow,demeaning, and inconsistent with the wayshow software developers should performtheir work to be most efficient.

A key problem of the waterfall model is the

inflexible division of a project into separate

stages, which requires specifications to be

complete and stable in an early stage,

and causes problems in particular in

situations where requirements are

changing throughout the project or are not

100% clear in the beginning, which is almost

always the case in complex IT projects.

Modern Offshore DevelopmentAgile and SOA

The Agile Development Process

Risks

Of course, offshoring is not without risk,like any IT project. There have been manydifferent statistics on the failure rate of ITprojects in the past, some putting thenumber of failed projects at over 50%(see [Sta05]).

However realistic this number may be,the fact remains that IT is a risky andcomplex business, and adding offshoringto the equation is not reducing thecomplexity.

In a recent report, Gartner Group hasidentified the following key offshore risks(see [Gar]):

�Missed cost savings goals

�Quality problems

�Cultural differences and communication problems

�Legal issues

�Loss of control

We at THBS understand these risks, andwe continually work together with ourcustomers to ensure that these risks arecontrolled and managed in the bestpossible way.

This whitepaper outlines some efficientstrategies to mitigate these risks efficiently.

5 6

Agile development helps minimize riskby developing software iterations, whichtypically lasts from two to four weeks.

Each iteration passes through a fullsoftware development cycle, includingplanning, requirements analysis, design, unittesting, and finally coding until the unit testspass and a working product can bedemonstrated to the stakeholders.

A key benefit of this is that softwareproduced by the offshore developers canbe demonstrated to the customer on aregular basis, dramatically increasingtransparency and reducing the risk ofprojects going in the wrong direction.

In 2001, a number of prominent figures inthe field of agile development created theAgile Manifesto, widely regarded as thecanonical definition of agile developmentand accompanying agile principles. Someof the principles included are:

�Customer satisfaction by rapid, continuous delivery of useful software

�Working software is delivered frequently (weeks rather than months)

�Working software is the principal measure of progress

�Even late changes in requirements are welcome

�Close, daily cooperation between business people and developers

�Face-to-face conversation is the best form of communication (co-location)

�Projects are built around motivated individuals, who should be trusted

�Continuous attention to technical excellence and good design

�Simplicity

�Self-organizing teams

�Regular adaptation to changing circumstances

While many of these Agile principlescan be applied in an Offshoredevelopment, one of the key requirementsis impossible to achieve: co-location of thedevelopment teams.

Consequently, Agile Offshore develop-ment will have to develop solutions toaddress this issue.

THBS has developed a number of BestPractices which help address this issue, inorder to make agile development feasiblein a distributed offshore scenario.

Prior to this, we will take a quick look atthe second key tool to modern offshoredevelopment, namely SOA.

An Enterprise SOA defines a businessoriented view on the structuralarrangement of individual applicationcomponents, and how they interact,including basic application components,business processes and business rules.

In the last five years, the large softwareproviders have created the necessaryinfrastructure for implementing anEnterprise SOA.

The table below describes the importantelements of the Enterprise SOA.

Service-OrientedArchitecture

Table 1: Elements of the Enterprise SOA (Source: “Enterprise SOA”, Prentice Hall 2004)

Enterprise SOA Element

SOA service

Enterprise Service Bus (ESB)

Business Process Manage-ment (BPM)

Business Activity Monitoring(BAM)

Business Rule Management(BRM)

Function

Stable, business-oriented basicapplication components.

Standardised communicationinfrastructure can be accessed viaSOA services.

Allows graphic definition of complexbusiness processes by businessanalysts. Processes access basic SOAservices during execution.

Enables monitoring of businessprocesses. Important process KPIs areautomatically captured and analysed.

Facilitates control of businessprocesses in the Enterprise SOA bymeans of business rules which can beadapted by business analysts.

Examples

Customer, loan application, contract,customer history.

Query of the current processing statusof the loan application.

Process control of the loanapplication, including capture ofapplication, credit check, credit score,decision, execution.

Analysis of average processing costsand success in the risk managementof loan applications.

Control of the loan decision processbased on the adjustable parameters

7 8

Agile development helps minimize riskby developing software iterations, whichtypically lasts from two to four weeks.

Each iteration passes through a fullsoftware development cycle, includingplanning, requirements analysis, design, unittesting, and finally coding until the unit testspass and a working product can bedemonstrated to the stakeholders.

A key benefit of this is that softwareproduced by the offshore developers canbe demonstrated to the customer on aregular basis, dramatically increasingtransparency and reducing the risk ofprojects going in the wrong direction.

In 2001, a number of prominent figures inthe field of agile development created theAgile Manifesto, widely regarded as thecanonical definition of agile developmentand accompanying agile principles. Someof the principles included are:

�Customer satisfaction by rapid, continuous delivery of useful software

�Working software is delivered frequently (weeks rather than months)

�Working software is the principal measure of progress

�Even late changes in requirements are welcome

�Close, daily cooperation between business people and developers

�Face-to-face conversation is the best form of communication (co-location)

�Projects are built around motivated individuals, who should be trusted

�Continuous attention to technical excellence and good design

�Simplicity

�Self-organizing teams

�Regular adaptation to changing circumstances

While many of these Agile principlescan be applied in an Offshoredevelopment, one of the key requirementsis impossible to achieve: co-location of thedevelopment teams.

Consequently, Agile Offshore develop-ment will have to develop solutions toaddress this issue.

THBS has developed a number of BestPractices which help address this issue, inorder to make agile development feasiblein a distributed offshore scenario.

Prior to this, we will take a quick look atthe second key tool to modern offshoredevelopment, namely SOA.

An Enterprise SOA defines a businessoriented view on the structuralarrangement of individual applicationcomponents, and how they interact,including basic application components,business processes and business rules.

In the last five years, the large softwareproviders have created the necessaryinfrastructure for implementing anEnterprise SOA.

The table below describes the importantelements of the Enterprise SOA.

Service-OrientedArchitecture

Table 1: Elements of the Enterprise SOA (Source: “Enterprise SOA”, Prentice Hall 2004)

Enterprise SOA Element

SOA service

Enterprise Service Bus (ESB)

Business Process Manage-ment (BPM)

Business Activity Monitoring(BAM)

Business Rule Management(BRM)

Function

Stable, business-oriented basicapplication components.

Standardised communicationinfrastructure can be accessed viaSOA services.

Allows graphic definition of complexbusiness processes by businessanalysts. Processes access basic SOAservices during execution.

Enables monitoring of businessprocesses. Important process KPIs areautomatically captured and analysed.

Facilitates control of businessprocesses in the Enterprise SOA bymeans of business rules which can beadapted by business analysts.

Examples

Customer, loan application, contract,customer history.

Query of the current processing statusof the loan application.

Process control of the loanapplication, including capture ofapplication, credit check, credit score,decision, execution.

Analysis of average processing costsand success in the risk managementof loan applications.

Control of the loan decision processbased on the adjustable parameters

7 8

THBS Best PracticesThe following section summarizes a set of bestpractices which THBS has developed in anumber of projects, combining SOA and Agileto make offshore development more efficient.

Team IntegrationIntegrating the work across multi-site teams ischallenging, especially if the teams are multi-national, multi-cultural, and are working acrosstime zones.

The agile approach stresses the importanceof face to face human interaction, which isdifficult to achieve in a multi-site project.

In order to overcome this issue, THBSrecommends that the following beimplemented:

On-Site Teams: THBS usually sends a part ofthe team to the customer’s location to workon-site directly with the customer.

Especially in the early phase of the project,this is an important measure to help ensure thatkey people in the project get to know eachother personally and can establish a trustrelationship.

Also, in the early phases, direct interactionshelp short communication cycles.

THBS can deploy as much as 30% of the overallteam on-site for critical phases of the project.

Offshore Ambassadors: THBS usuallyrecommends that the customer also sendsrepresentatives to work at the offshore locationin India or China.

Such an ambassador is usually very well linkedto the on-site team, and can thus leverage hiscontacts into the customer organization to helpthe offshore team to communicate moreefficiently.

It often makes sense to combine adevelopment ambassador with a businessambassador.

The business ambassador helps providebusiness context to the offshore team, whichhelps the offshore team to get a much betterunderstanding of the overall project and the“why’s” of many decisions.

Ambassadors should be rotated every fewweeks or months, since to maintain contactwith their home base, they can’t fulfill their jobsanymore.

The purpose of a SOA service isthe encapsulation of a relevant aspect ofthe business.

A service consists of several parts,including a number of interfaces (e.g.defined in WSDL), a service contract (aninformal specification of the service thatdescribes the purpose, functionality,constraints, and usage of the service),and the implementation.

A service owns its business logicand data.

Data is share with other services onlythrough the public interfaces of the service,never through direct database access.

A service can be compared to a ratherlarge module or an application sub-system.

Figure 2: Definition of a Service (Source:“Enterprise SOA”, Prentice Hall 2004)

An Enterprise SOA is typically comprisedof a number of different services.

These services can be grouped intodifferent layers.

Layering in an Enterprise SOA isindependent of the underlying technology,and is more concerned with the lifecycleand the overall functionality of the service.

For example, basic services are typicallyrelatively stable, i.e. they change lessfrequently, while process services arecontrolling business processes, e.g. throughthe use of BPMS and BRM, and are morefrequently changing.

Mapping services to the right layer helpswith more efficient management of theoverall SOA landscape.

From an offshore developmentperspective, SOA is a powerful mechanismfor managing the relationship between thecustomer and the offshore developmentteam, as we will see in the followingsections.

Figure 3: Enterprise SOA (Source: “EnterpriseSOA”, Prentice Hall 2004)

Address cultural issues: As an Asian offshoreprovider, THBS recognizes that it is absolutely vitalfor both sides to learn how to address differencesin the culture.

To make Agile Development work, a lot ofautonomy and decision making power has torest with those team members who are actuallyresponsible for the doing.

This is not exactly how a traditional“command and control” organization works.

THBS is constantly thriving to establish a culturewhich allows the individual to take responsibilityfor his/her own work in the Agile sense.

Establishing a personal relationship with thecustomer through on-site visits and theambassador mechanism helps build a trustrelationship, which is also important for offshoreteam members to overcome their own culturalbarriers and work more effectively in a mixedenvironment.

Team Composition by FunctionalityWhen applying the traditional waterfall modelto offshore development, one often sees atendency to define the onshore/offshoreboundaries through the activities that people do.

Often, analysis and design is done onshore,implementation and unit testing offshore, andacceptance testing again onshore.

THBS has found that in order to work mostefficiently, it often makes sense to draw theboundaries between onshore/offshore work notalong the lines of activities, but rather alongfunctionality.

Especially with SOA, it is possible to break upa system into loosely coupled services (eachservice comprises of a set of interfaces, businesslogic, and data).

The offshore team is often very well able totake full responsibil ity for the completedevelopment cycle of some or even all services,allowing the onshore team to focus on otherissues, such as the overall architecture, etc.

An important prerequisite for teamcomposition by functionality is to ensure thatthe offshore team is sufficiently equipped withlocal analyst capacities. The ambassadormechanism described above can be veryvaluable here.

9 10

THBS Best PracticesThe following section summarizes a set of bestpractices which THBS has developed in anumber of projects, combining SOA and Agileto make offshore development more efficient.

Team IntegrationIntegrating the work across multi-site teams ischallenging, especially if the teams are multi-national, multi-cultural, and are working acrosstime zones.

The agile approach stresses the importanceof face to face human interaction, which isdifficult to achieve in a multi-site project.

In order to overcome this issue, THBSrecommends that the following beimplemented:

On-Site Teams: THBS usually sends a part ofthe team to the customer’s location to workon-site directly with the customer.

Especially in the early phase of the project,this is an important measure to help ensure thatkey people in the project get to know eachother personally and can establish a trustrelationship.

Also, in the early phases, direct interactionshelp short communication cycles.

THBS can deploy as much as 30% of the overallteam on-site for critical phases of the project.

Offshore Ambassadors: THBS usuallyrecommends that the customer also sendsrepresentatives to work at the offshore locationin India or China.

Such an ambassador is usually very well linkedto the on-site team, and can thus leverage hiscontacts into the customer organization to helpthe offshore team to communicate moreefficiently.

It often makes sense to combine adevelopment ambassador with a businessambassador.

The business ambassador helps providebusiness context to the offshore team, whichhelps the offshore team to get a much betterunderstanding of the overall project and the“why’s” of many decisions.

Ambassadors should be rotated every fewweeks or months, since to maintain contactwith their home base, they can’t fulfill their jobsanymore.

The purpose of a SOA service isthe encapsulation of a relevant aspect ofthe business.

A service consists of several parts,including a number of interfaces (e.g.defined in WSDL), a service contract (aninformal specification of the service thatdescribes the purpose, functionality,constraints, and usage of the service),and the implementation.

A service owns its business logicand data.

Data is share with other services onlythrough the public interfaces of the service,never through direct database access.

A service can be compared to a ratherlarge module or an application sub-system.

Figure 2: Definition of a Service (Source:“Enterprise SOA”, Prentice Hall 2004)

An Enterprise SOA is typically comprisedof a number of different services.

These services can be grouped intodifferent layers.

Layering in an Enterprise SOA isindependent of the underlying technology,and is more concerned with the lifecycleand the overall functionality of the service.

For example, basic services are typicallyrelatively stable, i.e. they change lessfrequently, while process services arecontrolling business processes, e.g. throughthe use of BPMS and BRM, and are morefrequently changing.

Mapping services to the right layer helpswith more efficient management of theoverall SOA landscape.

From an offshore developmentperspective, SOA is a powerful mechanismfor managing the relationship between thecustomer and the offshore developmentteam, as we will see in the followingsections.

Figure 3: Enterprise SOA (Source: “EnterpriseSOA”, Prentice Hall 2004)

Address cultural issues: As an Asian offshoreprovider, THBS recognizes that it is absolutely vitalfor both sides to learn how to address differencesin the culture.

To make Agile Development work, a lot ofautonomy and decision making power has torest with those team members who are actuallyresponsible for the doing.

This is not exactly how a traditional“command and control” organization works.

THBS is constantly thriving to establish a culturewhich allows the individual to take responsibilityfor his/her own work in the Agile sense.

Establishing a personal relationship with thecustomer through on-site visits and theambassador mechanism helps build a trustrelationship, which is also important for offshoreteam members to overcome their own culturalbarriers and work more effectively in a mixedenvironment.

Team Composition by FunctionalityWhen applying the traditional waterfall modelto offshore development, one often sees atendency to define the onshore/offshoreboundaries through the activities that people do.

Often, analysis and design is done onshore,implementation and unit testing offshore, andacceptance testing again onshore.

THBS has found that in order to work mostefficiently, it often makes sense to draw theboundaries between onshore/offshore work notalong the lines of activities, but rather alongfunctionality.

Especially with SOA, it is possible to break upa system into loosely coupled services (eachservice comprises of a set of interfaces, businesslogic, and data).

The offshore team is often very well able totake full responsibil ity for the completedevelopment cycle of some or even all services,allowing the onshore team to focus on otherissues, such as the overall architecture, etc.

An important prerequisite for teamcomposition by functionality is to ensure thatthe offshore team is sufficiently equipped withlocal analyst capacities. The ambassadormechanism described above can be veryvaluable here.

9 10

Modern SOA test tools allow completesimulation of service providers and serviceconsumers. This allows for de-coupleddevelopment, but also for very efficientdefinition of test cases as part of arequirements definition.

Requirements can be defined, for example,as a combination of WSDL and test scripts.

An iteration plan can then define that inthis particular iteration, a frontend shoulddevelop a certain functionality which willinvoke a pre-defined WSDL interface in a pre-defined order, and react to pre-defined testdata in a certain way.

Immediate Feedback on FunctionalityIn order to reduce the risk that the offshore teamis not developing the functionality that wasenvisioned by the onshore customer, thepreviously described mechanism of ContinuousIntegration and SOA-driven test managementenable THBS to provide customers with aconcrete version of the software that can betested at the end of each iteration.

This feature of Agile development is a keyelement to help support close alignmentbetween the customer and the offshore team.

THBS encourages customer to participate inregular remote demos of the current state ofthe software through remote desktop software,presented by the offshore team.

This is also a great opportunity to build agood relationship between onshore andoffshore, and between business and ITdevelopment.

This can be a powerful mechanism tomanage very large projects more efficiently.

Obviously, great care has to be taken tomanage individual versions of services and theircompatibility amongst each other, especiallyat the end of each iteration.

SOA and Test-Driven DevelopmentThe Agile approach puts a lot of emphasis ontest driven development. The idea is that tests arewritten before the implementation and serve asa requirements definition.

With an offshore approach, it often makessense that the onshore customer writes uprequirements as a narrative to define a feature.

An offshore analyst and/or tester can thentranslate this narrative into a formal test script.

The onshore customer then reviews the testscript. Inquiries appearing during these earlystages of the development cycle are extremelyhelpful to improve the quality of the specificationfor the subsequent implementation, testing, anddeployment phases.

Resources in terms of business analyst,architect and developer time invested here areinvested wisely because their effort will pay offlater in the development cycle.

Agile software development process modelslike Scrum support this test-driven approach.

SOA can contribute a great deal to thisapproach: since service consumer and serviceprovider are separated through interfaces, theirindividual development cycle is de-coupled, asdepicted in the diagram below.

Figure 4: Individual development cycles ofservice consumer and service provider(Source: “Enterprise SOA”, Prentice Hall 2004)

Figure 5: Example: generic test driver for SOA Service(Source: “Enterprise SOA”, Prentice Hall 2004)

SOA-Driven Iteration Planning

In the Agile approach, a high emphasis is usuallyput on the iteration planning.

Ideally, the whole team should be involved inthe iteration planning to ensure that everybodyis clued in on the tasks for the next iteration.Because of the distributed nature of an offshoredevelopment, the iteration planning meetingmust be carefully prepared, in order to reducecommunication inefficiencies during the meeting,which is usually done over the phone.

Consequently, in close cooperation with thecustomer the THBS onshore team maps eachfeature in the upcoming iteration to the differentelements of the SOA which are required to worktogether in order to support the feature.

This should be done in a work breakdownstructure (WBS) which leverages SOA as a highlevel structure, and which is largely agreed uponbetween the onshore and the offshore teambefore the actual meeting.

SOA-based Continuous Integration

Even with the SOA-based approach, integrationproblems will never go away. While it is often easyto specify the signatures of the interfaces of an SOAservice, it is usually very difficult to get the semanticsagreed upon. Adding a service contract to theservice definition helps, but it is not a silver bullet.

Consequently, introducing a ContinuousIntegration approach to the project can helpspeed up task execution significantly and at thesame time ensure that all parts of the projectare always closely aligned.

Daily checks and overnight builds, so that thecode is ready for inspection by the onshore teamin the morning, are one of the strikingadvantages of offshore development.

Proficient service providers use frameworksand tools like Cruise Control for this process.

With the rise of service oriented architecturesanother interesting question appears: Shouldthe Continuous Integration approach be appliedto the entire code base or only on individualSOA services?

Since each SOA service basically owns its owndatabase schema and business logic, it is entirelypossible to separate the code base of all servicesand integrate them only at runtime.

SOA-Driven DocumentationFinally, we must look at the issue of

documentation.The Agile approach emphasizes face-to-face

communication over written documents.In an offshore situation, regular face-to-face

communication is not always achievable.Consequently, the amount of documents to

be written is larger than in the usual Agile project.THBS has a lot of experience in finding the

point of “sufficient” documentation.THBS puts emphasis on the structure of the

documents which are exchanged between theonshore and offshore team.

Leveraging SOA to structure thedocumentation is very helpful, since the SOAlevel is sufficiently concrete, without being tooclose to the implementation.

Using state-of-the-art tools like BusinessGlue’sPlanCentral™ to manage the documentationof different SOA artifacts between the onshoreand offshore team can be very helpful.

THBS Best Practices

11 12

Modern SOA test tools allow completesimulation of service providers and serviceconsumers. This allows for de-coupleddevelopment, but also for very efficientdefinition of test cases as part of arequirements definition.

Requirements can be defined, for example,as a combination of WSDL and test scripts.

An iteration plan can then define that inthis particular iteration, a frontend shoulddevelop a certain functionality which willinvoke a pre-defined WSDL interface in a pre-defined order, and react to pre-defined testdata in a certain way.

Immediate Feedback on FunctionalityIn order to reduce the risk that the offshore teamis not developing the functionality that wasenvisioned by the onshore customer, thepreviously described mechanism of ContinuousIntegration and SOA-driven test managementenable THBS to provide customers with aconcrete version of the software that can betested at the end of each iteration.

This feature of Agile development is a keyelement to help support close alignmentbetween the customer and the offshore team.

THBS encourages customer to participate inregular remote demos of the current state ofthe software through remote desktop software,presented by the offshore team.

This is also a great opportunity to build agood relationship between onshore andoffshore, and between business and ITdevelopment.

This can be a powerful mechanism tomanage very large projects more efficiently.

Obviously, great care has to be taken tomanage individual versions of services and theircompatibility amongst each other, especiallyat the end of each iteration.

SOA and Test-Driven DevelopmentThe Agile approach puts a lot of emphasis ontest driven development. The idea is that tests arewritten before the implementation and serve asa requirements definition.

With an offshore approach, it often makessense that the onshore customer writes uprequirements as a narrative to define a feature.

An offshore analyst and/or tester can thentranslate this narrative into a formal test script.

The onshore customer then reviews the testscript. Inquiries appearing during these earlystages of the development cycle are extremelyhelpful to improve the quality of the specificationfor the subsequent implementation, testing, anddeployment phases.

Resources in terms of business analyst,architect and developer time invested here areinvested wisely because their effort will pay offlater in the development cycle.

Agile software development process modelslike Scrum support this test-driven approach.

SOA can contribute a great deal to thisapproach: since service consumer and serviceprovider are separated through interfaces, theirindividual development cycle is de-coupled, asdepicted in the diagram below.

Figure 4: Individual development cycles ofservice consumer and service provider(Source: “Enterprise SOA”, Prentice Hall 2004)

Figure 5: Example: generic test driver for SOA Service(Source: “Enterprise SOA”, Prentice Hall 2004)

SOA-Driven Iteration Planning

In the Agile approach, a high emphasis is usuallyput on the iteration planning.

Ideally, the whole team should be involved inthe iteration planning to ensure that everybodyis clued in on the tasks for the next iteration.Because of the distributed nature of an offshoredevelopment, the iteration planning meetingmust be carefully prepared, in order to reducecommunication inefficiencies during the meeting,which is usually done over the phone.

Consequently, in close cooperation with thecustomer the THBS onshore team maps eachfeature in the upcoming iteration to the differentelements of the SOA which are required to worktogether in order to support the feature.

This should be done in a work breakdownstructure (WBS) which leverages SOA as a highlevel structure, and which is largely agreed uponbetween the onshore and the offshore teambefore the actual meeting.

SOA-based Continuous Integration

Even with the SOA-based approach, integrationproblems will never go away. While it is often easyto specify the signatures of the interfaces of an SOAservice, it is usually very difficult to get the semanticsagreed upon. Adding a service contract to theservice definition helps, but it is not a silver bullet.

Consequently, introducing a ContinuousIntegration approach to the project can helpspeed up task execution significantly and at thesame time ensure that all parts of the projectare always closely aligned.

Daily checks and overnight builds, so that thecode is ready for inspection by the onshore teamin the morning, are one of the strikingadvantages of offshore development.

Proficient service providers use frameworksand tools like Cruise Control for this process.

With the rise of service oriented architecturesanother interesting question appears: Shouldthe Continuous Integration approach be appliedto the entire code base or only on individualSOA services?

Since each SOA service basically owns its owndatabase schema and business logic, it is entirelypossible to separate the code base of all servicesand integrate them only at runtime.

SOA-Driven DocumentationFinally, we must look at the issue of

documentation.The Agile approach emphasizes face-to-face

communication over written documents.In an offshore situation, regular face-to-face

communication is not always achievable.Consequently, the amount of documents to

be written is larger than in the usual Agile project.THBS has a lot of experience in finding the

point of “sufficient” documentation.THBS puts emphasis on the structure of the

documents which are exchanged between theonshore and offshore team.

Leveraging SOA to structure thedocumentation is very helpful, since the SOAlevel is sufficiently concrete, without being tooclose to the implementation.

Using state-of-the-art tools like BusinessGlue’sPlanCentral™ to manage the documentationof different SOA artifacts between the onshoreand offshore team can be very helpful.

THBS Best Practices

11 12

Modern SOA test tools allow completesimulation of service providers and serviceconsumers. This allows for de-coupleddevelopment, but also for very efficientdefinition of test cases as part of arequirements definition.

Requirements can be defined, for example,as a combination of WSDL and test scripts.

An iteration plan can then define that inthis particular iteration, a frontend shoulddevelop a certain functionality which willinvoke a pre-defined WSDL interface in a pre-defined order, and react to pre-defined testdata in a certain way.

Immediate Feedback on FunctionalityIn order to reduce the risk that the offshore teamis not developing the functionality that wasenvisioned by the onshore customer, thepreviously described mechanism of ContinuousIntegration and SOA-driven test managementenable THBS to provide customers with aconcrete version of the software that can betested at the end of each iteration.

This feature of Agile development is a keyelement to help support close alignmentbetween the customer and the offshore team.

THBS encourages customer to participate inregular remote demos of the current state ofthe software through remote desktop software,presented by the offshore team.

This is also a great opportunity to build agood relationship between onshore andoffshore, and between business and ITdevelopment.

This can be a powerful mechanism tomanage very large projects more efficiently.

Obviously, great care has to be taken tomanage individual versions of services and theircompatibility amongst each other, especiallyat the end of each iteration.

SOA and Test-Driven DevelopmentThe Agile approach puts a lot of emphasis ontest driven development. The idea is that tests arewritten before the implementation and serve asa requirements definition.

With an offshore approach, it often makessense that the onshore customer writes uprequirements as a narrative to define a feature.

An offshore analyst and/or tester can thentranslate this narrative into a formal test script.

The onshore customer then reviews the testscript. Inquiries appearing during these earlystages of the development cycle are extremelyhelpful to improve the quality of the specificationfor the subsequent implementation, testing, anddeployment phases.

Resources in terms of business analyst,architect and developer time invested here areinvested wisely because their effort will pay offlater in the development cycle.

Agile software development process modelslike Scrum support this test-driven approach.

SOA can contribute a great deal to thisapproach: since service consumer and serviceprovider are separated through interfaces, theirindividual development cycle is de-coupled, asdepicted in the diagram below.

Figure 4: Individual development cycles ofservice consumer and service provider(Source: “Enterprise SOA”, Prentice Hall 2004)

Figure 5: Example: generic test driver for SOA Service(Source: “Enterprise SOA”, Prentice Hall 2004)

SOA-Driven Iteration Planning

In the Agile approach, a high emphasis is usuallyput on the iteration planning.

Ideally, the whole team should be involved inthe iteration planning to ensure that everybodyis clued in on the tasks for the next iteration.Because of the distributed nature of an offshoredevelopment, the iteration planning meetingmust be carefully prepared, in order to reducecommunication inefficiencies during the meeting,which is usually done over the phone.

Consequently, in close cooperation with thecustomer the THBS onshore team maps eachfeature in the upcoming iteration to the differentelements of the SOA which are required to worktogether in order to support the feature.

This should be done in a work breakdownstructure (WBS) which leverages SOA as a highlevel structure, and which is largely agreed uponbetween the onshore and the offshore teambefore the actual meeting.

SOA-based Continuous Integration

Even with the SOA-based approach, integrationproblems will never go away. While it is often easyto specify the signatures of the interfaces of an SOAservice, it is usually very difficult to get the semanticsagreed upon. Adding a service contract to theservice definition helps, but it is not a silver bullet.

Consequently, introducing a ContinuousIntegration approach to the project can helpspeed up task execution significantly and at thesame time ensure that all parts of the projectare always closely aligned.

Daily checks and overnight builds, so that thecode is ready for inspection by the onshore teamin the morning, are one of the strikingadvantages of offshore development.

Proficient service providers use frameworksand tools like Cruise Control for this process.

With the rise of service oriented architecturesanother interesting question appears: Shouldthe Continuous Integration approach be appliedto the entire code base or only on individualSOA services?

Since each SOA service basically owns its owndatabase schema and business logic, it is entirelypossible to separate the code base of all servicesand integrate them only at runtime.

SOA-Driven DocumentationFinally, we must look at the issue of

documentation.The Agile approach emphasizes face-to-face

communication over written documents.In an offshore situation, regular face-to-face

communication is not always achievable.Consequently, the amount of documents to

be written is larger than in the usual Agile project.THBS has a lot of experience in finding the

point of “sufficient” documentation.THBS puts emphasis on the structure of the

documents which are exchanged between theonshore and offshore team.

Leveraging SOA to structure thedocumentation is very helpful, since the SOAlevel is sufficiently concrete, without being tooclose to the implementation.

Using state-of-the-art tools like BusinessGlue’sPlanCentral™ to manage the documentationof different SOA artifacts between the onshoreand offshore team can be very helpful.

THBS Best Practices

11 12

References

“The Best Practices which we

have jointly developed with

THBS and which are partly

documented in this

whitepaper have enabled us

to establish a very efficient

and risk controlled offshore

development process.

This is important to us on

two levels: first, because THBS

is a strategic partner for us in

the development of our

PlanCentral™ product. Second, because

THBS is also an implementation partner for

us in our end-customer projects” says Dirk

Slama, Managing Director BusinessGlue

GmbH (Germany) and Co-Author of

“Enterprise SOA”.

“We enable large enterprise customers

to manage IT projects more efficiently

through our IT Excellence™ IT strategy

framework and our SOA-based

PlanCentral™ IT planning suite. It was vital

for us to find a partner who shares the same

principles and methodologies for

managing complex IT transition project.

THBS has proven to be a partner who

understands the mechanisms of Agile and

SOA-based IT transformation projects.”

Links[Gar] Gartner Group, Gartner on Outsourcing, www.gartner.com[Sta05] Standish Group, Chaos Report,www.standishgroup.com/chaos_resources/index.php

Establishing a long-term trust relationship

with our customers is the first important step

towards mutual success.

In order to address the 5 key issues in

offshore projects that were mentioned

at the beginning of this whitepaper

(missed cost savings goals, quality problems,

cultural differences and communication

problems, legal issues, loss of control),

THBS has developed an offshore

development methodology which

combines Agile with SOA.

The best practices documented in

this whitepaper are specifically tailored

to address the risk factors in offshore

development by addressing cultural and

team issues proactively, by increasing

transparency through test-driven

development and immediate feedback,

and by identifying quality issues immediately

through continuous integration.

Conclusion

13 14

References

“The Best Practices which we

have jointly developed with

THBS and which are partly

documented in this

whitepaper have enabled us

to establish a very efficient

and risk controlled offshore

development process.

This is important to us on

two levels: first, because THBS

is a strategic partner for us in

the development of our

PlanCentral™ product. Second, because

THBS is also an implementation partner for

us in our end-customer projects” says Dirk

Slama, Managing Director BusinessGlue

GmbH (Germany) and Co-Author of

“Enterprise SOA”.

“We enable large enterprise customers

to manage IT projects more efficiently

through our IT Excellence™ IT strategy

framework and our SOA-based

PlanCentral™ IT planning suite. It was vital

for us to find a partner who shares the same

principles and methodologies for

managing complex IT transition project.

THBS has proven to be a partner who

understands the mechanisms of Agile and

SOA-based IT transformation projects.”

Links[Gar] Gartner Group, Gartner on Outsourcing, www.gartner.com[Sta05] Standish Group, Chaos Report,www.standishgroup.com/chaos_resources/index.php

Establishing a long-term trust relationship

with our customers is the first important step

towards mutual success.

In order to address the 5 key issues in

offshore projects that were mentioned

at the beginning of this whitepaper

(missed cost savings goals, quality problems,

cultural differences and communication

problems, legal issues, loss of control),

THBS has developed an offshore

development methodology which

combines Agile with SOA.

The best practices documented in

this whitepaper are specifically tailored

to address the risk factors in offshore

development by addressing cultural and

team issues proactively, by increasing

transparency through test-driven

development and immediate feedback,

and by identifying quality issues immediately

through continuous integration.

Conclusion

13 14

Torry Harris Business Solutions Inc, a US based services provider

with a large base of technologists located in the UK, India and

China has provided cost effective solutions at a design,

development and support level to a variety of enterprise clients

across the world since 1998.

The company specializes in integration, distributed computing,

and its focus on SOA is a result of nearly a decade of expertise

gathered in the middleware space.

The company has partnerships with almost all the leading SOA

and integration product vendors.

SOA, involving the creation of autonomous parts of a solution,

lends itself admirably to the cost effective model of offshore

service collaboration.

A separate white paper entitled “SOA Implementation with

an offshore partner” available for download, explores this model

in a more detailed manner.

Further information about the company and a variety of white

papers on SOA are available at www.thbs.com/soa.

For more information, write to us at [email protected].

Agile OffshoreDevelopmentwith SOA