Choose One Of The Following Case Studies To Review.(Case Study PDF’s Attached)

TEACHING CASE

Lessons from attempting to backsource a government IT system

Nicholaos Petalidis1

Published online: 16 November 2017

� Association for Information Technology Trust 2017

Abstract Backsourcing is not a common term and refers to

the process of taking back development of a system that

was previously outsourced. Even though the term is not a

common one, the process that it describes is. Businesses try

to reverse outsourcing and start insourcing all the time. The

process however is not cost free and certainly is not paved

with roses. Herein we report from our own experience of

trying to backsource the development and maintenance of a

large information system, focusing on the technical prob-

lems encountered. The novel aspect of this paper is that it is

one of the few that provide insights into the specifics that

one has to include in any outsourcing contract, for back-

sourcing to be possible.

Keywords Code comprehension � Software maintenance � Backsourcing � E-government � Technology management

Introduction

Backsourcing refers to the process of bringing previously

outsourced operations back. Backsourcing occurs when

outsourcing is deemed as unsuccessful, or when a company

wants to take back control of its own operations. Solli-

Sæther and Gottschalk (2015) reported that 34% of the

firms surveyed in the US and Canada had backsourced at

one point. Contrary to what one would expect then, the

literature looking into the problems of this process is scant.

Most of the published literature on the subject, like –

Akoka and Comyn-Wattiau (2006), Whitten and Leidner

(2006), or Wong and Jaya (2008), narrowly focuses only

on the reasons behind backsourcing.

Akoka and Comyn-Wattiau (2006) present a framework

to understand the antecedent of backsourcing and clarify

why organisations backsource. Similarly, in Whitten and

Leidner (2006) the factors that are associated with the

decision to backsource or switch vendors are examined.

Similar research is also presented in Wong and Jaya

(2008), which examines the factors that drive organisations

towards backsourcing.

In Solli-Sæther and Gottschalk (2015), a stages-of-

growth model is proposed and it is argued that the constant

move of services from an in-house function to an out-

sourced and offshored function and finally to a backsourced

function is an evolution path and not simply a return to the

beginning.

There are very few studies or case studies that look into

the problems that one can expect when attempting to

backsource: Butler et al. (2011) present a case study of an

organisation that had backsourced its IT department. The

authors look into the different phases of the backsourcing

process, concluding that the research on the transitional

phase from one mode of operation to the other has attracted

little attention so far.

Two case studies of IT backsourcing are also presented

in Kotlarsky and Bognar (2012). One of these studies

looked into the backsourcing of an IT service, whereas the

other one looked into the backsourcing of an IT product

development. The focus of both case studies, though, is the

process through which backsourcing occurred and not the

problems that the projects faced.

The challenges of backsourcing information systems in

the case of government organisations are presented in

& Nicholaos Petalidis npetalid@teicm.gr

1 Department of Informatics Engineering, TEI of Central

Macedonia, Serres, Greece

J Info Technol Teach Cases (2018) 8:90–96

DOI 10.1057/s41266-017-0026-2

 

 

Samsudin et al. (2012). The study is based on interviews

contacted with government agencies and focuses on the

process that an agency should follow, suggesting that a

knowledge transfer should start at least a year earlier from

when the actual backsourcing takes place. Finally, in Nu-

jen et al. (2015) a specific strategy is suggested to be fol-

lowed in order to re-integrate knowledge coming back into

the organisation.

Thus, with the exception of Samsudin et al. (2012)

and Nujen et al. (2015), all of the studies try to answer the

why of backsourcing, providing little insight into the how.

Nujen et al. (2015) on the other hand do not focus on IT-

specific problems, whereas Samsudin et al. (2012) present

findings from information gathered through questionnaires

from external observers.

This report, similarly to Samsudin et al. (2012), also

looks into the case of backsourcing an e-government ser-

vice. However, unlike Samsudin et al. (2012), it is based

on first-hand experience and presents the resultant guide-

lines to help avoid the problem of knowledge re-integration

and increase the chances of backsourcing success.

In the next section, the environment under which the

backsourcing was attempted is described, followed by a

section that presents the backsourcing attempt. Conclusions

are presented in the final section.

Background

Despite the push for the use of open source software in the

public sector during the later years, a large number of

government agencies still base their operations on custom-

made software that is outsourced to private contractors.

The case study in this report focuses on such a government

agency. The agency in question has a multitude of IT

systems, the development and operation of which have

been outsourced. The agency has an IT department, but so

far the department has tackled only the development of

considerably smaller projects.

The particular system to which this case study refers has

been under development for at least a decade. In its current

state, the system consists of a number of PL/SQL databases

and their associated Java-based back end with a Javascript-

based front end. Most of the logic of the system is however

implemented at the database level as stored procedures.

This is typical of many government IT systems, although

the one in question is probably one of the bigger ones in the

Greek public sector. For each new version, more than 3000

tables and 3 million lines of Oracle PL/SQL code are

added, even though it seems that a lot of it is simply copied

and slightly altered from previous years. The system serves

more than six hundred thousand citizens; at its peak it has

around 3000 concurrent users.

Architecturally, it consists of a number of diverse sub-

systems, each related to a specific function in the agency.

The outsourcing process

Each year, a new Request for Tenders is issued (RFT)

asking potential contractors to bid for the maintenance of

previous versions as well as for the development of new

functions required to take into account new government

regulations. The tender also lays down the legal, financial,

and technical framework for the required services.

The outsourcing process starts with the drafting of the

Request for Tenders. Each of the agency’s departments is

asked to fill in the relevant section regarding the new

functionality that will be desired for the next year. It is

quite common that the exact requirements for the next

year’s version are not known, mainly because the legisla-

tion is not ready yet, so in most cases the requirements are

quite vague, e.g. The software must conform to the direc-

tive XXX. On the one hand, having a too generic description

makes the process of cost and time estimations difficult; on

the other hand, having overspecified the requirements

might create problems if the final version of legislature

differs from the initial.

Once the functional requirements are gathered, one or

more software engineers are tasked with completing the

tender with non-functional requirements such as the system

architecture, adherence to standards, mode of delivery, and

training requirements. As a matter of fact, the list of such

non-functional requirements is longer than the one of the

functional requirements.

Quite often, however, the non-functional requirements

are routinely copied from the previous year’s tender to the

current year’s tender, given that not a lot changes in these

areas. The non-functional requirements typically include

generic statements such as

The system must be parameterisable, modular and of

an open architecture.

The tender also tries to make clear that any source code

developed for the project is owned by the agency and not

by the contractor. To this end, statements such as the

following are included in the tender:

For any modification to the system, the source code

should be delivered to the agency. The source code is

property of the agency. Any modifications will be

accompanied by associated documentation describing

the implemented functionality, the data structures and

its dependence on other parts of the system.

The general understanding in this and other tenders as

mentioned later is that ownership of source code ensures

Lessons from backsourcing an IT system 91

 

 

that the agency is not tied to any particular vendor for

maintenance or extensions of the system in the future.

A committee is responsible for making sure that all the

requirements laid out in the tender, as well as the signed

agreement, are met. The committee usually consists of

people from the departments that will be using the system

as well as at least one from the agency’s IT department.

At predefined points in time, the contractor submits the

required artefacts and the committee ensures that they are

according to standards. When the software is finally

delivered, the committee’s focus is usually on ensuring that

it conforms to its functional requirements. After all, the

running software is the artefact to watch for. From our own

experience, other artefacts like documentation or source

code were noted but were rarely examined with respect to

their quality or usability.

During the system’s development, there is a close co-

operation between the agency’s departments and the con-

tractor in order to lay down the specific functional

requirements. The agency’s IT department has a small part

in this, as most requirements are communicated directly

from each of the departments to the contractor in various

forms: word documents and e-mails, which are a common

form of requirement exchange. An issue-tracking system is

in place but not always used.

Outsourcing perceptions

The process that was described previously is not unique,

but it is similar to the way outsourcing takes place in many

government agencies. As a matter of fact, we have

reviewed five more requests for tenders, published by

various agencies of the Greek public sector. The main

procurement requirement for all of them was the devel-

opment of a software system and a total budget that

amounted (for the five of them) to more than 11,000,000,

i.e. they were large and complex systems. They all con-

sisted of multiple subsystems and had to be integrated with

existing systems. Moreover, they required the contractor to

pass ownership of the source code developed for the pro-

ject to the procuring agency.

The tenders were about projects from different services in

the public sector, handling different problems: These ranged

from information systems handling digitisation and encod-

ing of rules for managing Social Security benefits, to Man-

agement Information Systems and workflow management.

In all of these tenders there is a common pattern:

• The contractor is responsible for drafting the require- ments document.

• The main documentation required by the contractor as far as the system’s design is concerned is an ER

diagram (or class diagram in some cases).

• In all of the calls, there is a requirement for a modular solution but this seems to refer to the communication of

the system under development with the rest of the

agency’s systems. For this reason, all calls require

adherence to the Greek e-Government Interoperability

Framework (see http://www.e-gif.gov.gr/portal/page/

portal/egif/) or the more abstract European Interoper-

ability Framework, which describe, among other things,

the standards that need to be followed when interacting

with external systems (web services guidelines) but

make no reference to the internal design.

• There is no specific requirement for the system itself to be modular, other than being separated into three layers

(presentation, business, and data).

• The database seems to be the central point of connec- tion with everything else. This is evident in the calls

themselves where the requirement for separate modules

is in contrast with the database-centric approach they

all imply: All calls made reference to the presence of a

single database. One of the calls literally enforced it as

a requirement. Another call made it clear that the

database was to be considered as the point for

information exchange:

Technical description of the database schema (logical

and conceptual design) (is required to be delivered) in

order to be able to interconnect the application with

third party systems.

and even went further on explicitly accepting that, even

though the source code is owned by the agency, ‘‘…Before

any such intervention (to the database) the contractor’s

opinion will be requested’’.

• None of the calls put any specific requirements on how the source code will be delivered and what should be

part of the delivered code. Unit tests were not explicitly

mentioned as part of the source code in any of the calls.

One may argue that this is implicitly assumed but it is

our experience that it is not even when the contractor

proposes an agile methodology for the product’s

development. No adherence to a coding standard was

mentioned.

• All calls stated the requirement for the performance of user acceptance testing without, however, any distinc-

tion between manual and automated tests.

• None of the tenders requested any artefact describing the deployment procedures and there was no require-

ment for the contractor to deliver automated deploying

procedures for any of the systems developed. In cases

where training was required, this mostly referred to

end-user training or everyday operation training.

• None of the tenders required the contractor to deliver the whole history of the source code, and there was not

92 N. Petalidis

 

 

even a requirement that such a history should be

maintained. There was no reference either to maintain-

ing an issue management system or to any deliverables

related to configuration management.

• In all cases, the contractor could choose its own methodology for managing the project. There was no

requirement that the government agency will have to

participate in design meetings with its own personnel.

In all tenders, the contractor and the agency would have

to co-operate during the drafting of the requirements as

well as the general working plan, but no other form of

co-operation was described. There was no requirement

for the contractor to submit the updated project plans or

any other project information once the project

concluded.

The backsourcing process

Typically, the procurement process described previously

should have given equal chances to all prospective bidders.

The reality, however, was that the bidder who developed

the initial version of the system had much better chances of

succeeding. It had a better understanding of the architec-

ture, so maintaining the previous versions of the system

required considerably less effort than of any new player.

Similarly, any new functionality developed would have to

be connected to the existing one, so again the original

designer had an unfair advantage over the other bidders. In

essence, the agency had fallen in the trap of the vendor

lock-in.

For these reasons, and in order to avoid the problem of a

vendor lock-in for future tenders, the agency decided to

form a team with the purpose of laying out the required

steps to backsource the system’s design. A successful

outcome would lay out the foundations for outsourcing,

during the next years, only specific parts of the system,

keeping development of important features in-house. The

team consisted of two software engineers, a database spe-

cialist as well as two more members who have been

involved with drafting the tenders or outlining functional

requirements during the previous years.

Division into knowledge areas

It was clear from the start that backsourcing a project

meant that knowledge pertaining to all of its aspects had to

be transferred back to the agency.

It was conjectured that all software projects go through

some form of requirements capture and analysis, design of

system architecture, implementation and testing, and

finally deployment, irrespective of any development

methodology followed. Of course, different methodologies

might perform these sequentially, iteratively, or incre-

mentally giving different emphasis to them in different

stages, but the fact remains that, more or less, this is what

goes on in a software project. In parallel with these, two

more disciplines that cut across all of them were also

considered to be of importance: that of the software con-

figuration and change management as well as the project

management itself (see Fig. 1).

In the following, we report the problems we encountered

when attempting to transfer knowledge back to the

organisation for each of these disciplines and the lessons

learned.

Discipline 1: requirements capture and analysis

The main purpose in this discipline was to gather infor-

mation regarding the business domain and modelling. The

team’s task was to gather all requirements and understand

the business model. Given that the agency itself specified

the requirements, this should have been an area with no

problems. Indeed, each department provided a list of

requirements on which the system was developed. Unfor-

tunately, it was also revealed, during the investigation, that

some of the requirements were also informally put across

to the contractor through e-mails, whereas the same went

for bug fixes or other problems. Discussions also revealed a

number of hidden requirements. So a lot of effort was made

to gather them into one place.

A requirements document, for each of the subsystems

implemented, was also among the deliverables the con-

tractor produced. However, these documents recorded the

end-user requirements but nothing that would describe the

actual business processes. For example, there was plenty of

information on what each field in a form represents, but no

description of how the data submitted to the form should be

processed. Similarly, there was no information that would

describe the flow of information between the subsystems.

In essence, the contractor’s requirement document was a

user manual. Overall, the team felt that the time spent on

this discipline was a lot more than what was planned for,

Fig. 1 Project’s disciplines where transfer of knowledge was deemed important

Lessons from backsourcing an IT system 93

 

 

and a lot of new knowledge had to be produced and not

merely transferred from the contractor to the agency.

Discipline 2: system design and architecture

The main purpose in this discipline was to understand the

design of the system, identify its separate subsystems,

isolate them, and start working first on the ones that were

deemed critical. The main task of the team was to map

software constructs (database schemas, groups of stored

procedures, and so on) to the identified subsystems and

understand design decisions. For this reason, the team

started looking thoroughly into the design documents the

contractors produced as well as the database structure.

All of the design documents delivered were entity

relationship (ER) diagrams. However, these were found

inadequate and proved of little help to the process of

understanding the system design and architecture.

Another point that presented difficulties was the fact that

all communication went through the database. Most of the

subsystems seemed to have direct access to tables; the ones

that did not were accessing it via stored procedures. Given

that the system included thousands of them (tables or stored

procedures), it was practically impossible to view one sub-

system independently of the others and understand it.

Discipline 3: implementation and testing

Focus here was on understanding implementation issues and

being able to purposely alter the behaviour of the system for

specific use cases. The team started gathering the source

code, attempting to execute it and debug it. In order to be able

to do any of these of course, one would need to comprehend

the code. The first main hurdle was the lack of any descrip-

tion on how to set up the necessary development environ-

ment. The requirement for the inclusion of this information

in some deliverable by the contractor was a serious omission

that created major problems. Apart from an actual develop-

ment environment, missing libraries also hindered the

attempts to produce an executable.

A critical issue was the high degree of coupling we

mentioned already when looking into the design: All intra-

module communication in the systems we examined took

place through the database, making it extremely difficult to

implement changes without the fear of breaking some

unrelated subsystem.

Another issue that might seem minor, but created

comprehension problems, was the lack of any standardis-

ation across the delivered code.

In addition, a lot of the front end Javascript-based code

was automatically generated by code generators. Code

generators are very useful since they can automatically

produce code and have been in use in software engineering

for quite some time: a parser generator will nicely produce

a parser for a specific grammar. One of their drawbacks,

however, is that they frequently produce unreadable code,

since it was assumed that humans will rarely need to alter

the generated code, and only modify the template through

which the code was generated. However, neither the gen-

erator nor the templates used to generate the code were

delivered.

A final problem that was uncovered was that it was not

clear what constituted ‘‘source code’’. The contractor only

formally submitted the JEE back end and the Javascript

front end. The bulk of the business logic, written in PL/

SQL, was never submitted as a separate deliverable.

Instead, it was assumed that since one could access the

code in the production servers, no separate deliverable,

containing it, needed to be submitted. However, the code

there was mixed with other PL/SQL code used by different

back ends from previous versions of the system. Extraction

of the source code was then not a straightforward

operation.

Discipline 4: deployment

The purpose in this discipline was to be able to deploy the

system in a QA environment and be able to exercise it in a

realistic environment. Deployment procedures are

increasingly complex these days. It is a matter of setting up

load balancers, caches, clusters, a number of linked data-

bases, configuring parameters, and so on. Even the process

of setting up the environment for development purposes

might be daunting, especially if one needs to set up the

necessary initial data to fill into a number of different

schemas, fix the parameters on the application servers, and

locate the correct version of libraries. Thus, knowing how

to deploy the product is a mini-project by itself, one that is

frequently left out in outsourcing contracts. In this partic-

ular case, it also turned out that there was no clause that

required the delivery of any sort of documentation or

scripts from the contractor that would ease deployment

procedures. Access to the actual production system was

possible and shed some light but it was extremely time

consuming to isolate the exact environment needed. After

all, production systems were configured to support a mul-

titude of products and not only this particular one. In fact,

the difficulties faced in this stage were the reason for the

decision to abandon the project; the timeframe required to

find out all the necessary parameters was prohibitive.

Discipline 5: configuration and change control

management

The purpose in this discipline was to gather all of the

system’s versions and associated issues and try to match

94 N. Petalidis

 

 

the code changes with any change requests. In this case, as

in many others, there was no obligation by the contractor to

deliver the full history of the source code, but only its final

version. This was true, even though the system was in

operation before the final version was delivered, and there

was no way to check the source code used to implement

these operations.

Similarly, an issue-tracking mechanism was in place,

but not all change requests went through it.

Discipline 6: project management

Backsourcing a project is related to a lot more than just

transferring it in-house. It actually means that the project

also needs to be managed in-house; it has been frequently

noted that project management practices are key to a

software project’s success; see for example Kwak and

Stoddard (2004) and Art Gowan Jr and Mathieu (2005). In

the particular case presented here, it was expected that the

project will be managed and supervised by in-house

personnel.

For this reason, historical project data had to be gathered

and estimates had to be made regarding costs and activity

durations. Unfortunately, though such data were not part of

any project deliverables. Of course, it was possible to get

an idea of the total cost and duration based on the costs of

the outsourced project. However, these were too coarse-

grained. There were no estimation records for particular

subsystems, e.g. ‘‘how long it will take to implement sub-

system X’’. Similarly, it was not possible to have an idea of

the risks associated with a particular functionality or sub-

system. In general, the organisation was lacking one of its

most important assets for project management: lessons

learned and historical data.

Aftermath

Given the difficulties faced, the backsourcing attempt had

to be abandoned because it could not be realised in the

required timeframe. At that point, the amount of work

completed for each of these disciplines is presented in

Fig. 2. Note that the two disciplines (Configuration and

Change control management and Project Management) that

cut across all disciplines are not shown since the work there

is included in the work completed in the other four

disciplines.

The total cost of the backsourcing attempt was at that

point at the 4.5% of the cost of the latest outsourcing

contract. The effort distribution across the disciplines is

presented in Fig. 3.

Thus, our experience agrees with Samsudin et al. (2012)

that backsourcing should start at least a year earlier. Since

the main problem was that not enough care was put into

drafting the initial contract and laying out the contractor’s

requirement, it is of crucial importance that these should

not be overlooked by anyone planning to backsource at

some point his/her information systems.

Conclusions

Backsourcing an IT system requires that knowledge needs

to be transferred back from the contractor in-house. Even

though a lot of tenders and contracts theoretically take

measures for ensuring that such an information transfer is

possible, we found out that indeed this is extremely

difficult.

The most important of the delivered artefacts, aside

from the actual product itself, is the source code, but the

code that you do not comprehend is the code that you do

not really own. Developers need to understand the code, or

at least some part of it, before they can extend its func-

tionality or fix its errors. They need to be able to recognise

modules that can be reused, or modules that need to be

updated. If they cannot do these things, code ownership is

just an issue relevant to lawyers that might want to argue

over copyright, but of little practical value otherwise. We

believe that one of the reasons that government agencies

Fig. 2 Work completion on each of the disciplines

Fig. 3 Effort distribution across the different disciplines

Lessons from backsourcing an IT system 95

 

 

find it easier to request the development of information

systems from scratch, even when they could have reused

existing software is exactly because code comprehension is

quite low in many projects.

We concluded that in order for backsourcing to be

possible steps should be taken, early on when tenders are

drafted, to ensure that any information produced during the

project is correctly registered and communicated to the

agency.

Questions

• Since it was the agency’s departments that drafted the requirements, why there was such a problem in

transferring this knowledge back to the organisation?

• Why having all subsystems communicating through the database is a problem? How one would tackle the

problems uncovered during the review of the system

design and architecture?

• Why were ER diagrams considered inadequate? Dis- cuss on the perceived usefulness of diagrams in design

documents.

• Think about how do software engineers understand code. What kinds of artefacts and which practices

would have helped the engineers better comprehend the

code?

• How important, do you think, is the presence of source code history in comprehending source code? How this

should affect the tender?

• List some common misconceptions that the back- sourcing attempt uncovered.

• In summary, what points do you think should be included in the original tenders to make backsourcing

an easier process? How do you think agencies should

proceed when planning for outsourcing?

References

Akoka, J., and I. Comyn-Wattiau. 2006. Developing a framework for

analyzing IS/IT backsourcing. In AIM 2006—information

systems and collaboration: State of the art and perspectives,

330–340. Luxembourg.

Art Gowan Jr., J., and R.G. Mathieu. 2005. The importance of

management practices in IS project performance: An empirical

study. Journal of Enterprise Information Management 18 (2):

235–255.

Butler, N., F. Slack, and J. Walton. 2011. IS/IT backsourcing—a case

of outsourcing in reverse? In 2011 44th Hawaii international

conference on system sciences (HICSS), 1–10. IEEE.

Kotlarsky, J., and L. Bognar. 2012. Understanding the process of

backsourcing: Two cases of process and product backsourcing in

Europe. Journal of Information Technology Teaching Cases 2

(2): 79–86.

Kwak, Y.H., and J. Stoddard. 2004. Project risk management: Lessons

learned from software development environment. Technovation

24 (11): 915–920.

Nujen, B.B., L.L. Halse, and H. Solli-Sæther. 2015. Backsourcing and

Knowledge Re-integration: A case study. In IFIP international

conference on advances in production management systems,

191–198. Springer.

Samsudin, N.M., A.N. Bakar, and R. Hashim. 2012. Challenges of

backsourcing of e-government services: A case study. In 2012

IEEE colloquium on humanities, science and engineering

(CHUSER), 463–466. IEEE.

Solli-Sæther, H., and P. Gottschalk. 2015. Stages-of-growth in

outsourcing, offshoring and backsourcing: Back to the future?

Journal of Computer Information Systems 55 (2): 88–94.

Whitten, D., and D. Leidner. 2006. Bringing IT back: An analysis of

the decision to backsource or switch vendors. Decision Sciences

37 (4): 605–621.

Wong, S.F., and P. Jaya. 2008. Drivers of IT backsourcing decision.

Communications of the IBIMA 2 (14): 102–108.

Dr. Nicholaos Petalidis has been working as a software engineering consultant on issues regarding software management and software

design for government organisations and companies in Europe and the

US for the last twenty years. His research interests include software

design methodologies as well as software dynamics and software

development processes.

96 N. Petalidis