building software in-house: too much control and flexibility

Building Software In-House

Too Much Control and Flexibility

Ivan Ruchkin

Institute for Software ResearchCarnegie Mellon University

March 19, 2011

BuildingSoftwareIn-House

Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Outline

1 Context

2 Initial decision

3 COTS emerged

4 Outgrowth

5 Outcome

2 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Practicum Context

Issue: to buy software or to build it?

Can build completely in-house.

Can buy commercial-off-the-shelf (COTS) software.

Can adopt open source software.

Can develop a hybrid solution.

Scope: non-software medium-sized business.

Common wisdom: (i) higher control and flexibility, but limitedscaling when building; (ii) higher initial investment, but lowercost-of-ownership and higher reliability when buying COTS.

My experience: started building → missed the point to turn toCOTS → suffered losses → transitioned to COTS.

3 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Timeline

1996 1998 2000 2002 2004 2006 2008 2010 2012

Si-Trans established

Build in-house decision

I joined Si-Trans

I left Si-Trans

Transition to COTS

Time

COTS available

System outgrew

1994

3 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Background of Si-Trans

Si-Trans—international logistics company. Established in1995-1996, and is still around.

Provides following services:

Transportation of goods from China to Russia and Europe(road, rail, marine, air).

Customs brokerage.

Cargo insurance.

Storage services.

Has expertise in respective areas.

4 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Geographic distribution as of 2011

5 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Organizational structure as of 2011

Legal team

Top management

Systemsadministration

Client relations

Transportationteam

Software development

Regionalmanagement

Transportationteam

Transportationteam

Client relationsClient relations

Regionalmanagement

Regionalmanagement

Organizational unit Reports to

Accounting and finance

6 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

More background

Details on Si-Trans:

Operates primarily in B2B segment.

Heavy reliance on subcontractors.

Steady growth in revenue and size from 1995 to 2010.

Reached 200 employees in 2010.

Business model and organizational principles persisted intime.

7 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Outline

1 Context

2 Initial decision

3 COTS emerged

4 Outgrowth

5 Outcome

7 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Timeline

1996 1998 2000 2002 2004 2006 2008 2010 2012



I joined Si-Trans

I left Si-Trans

Transition to COTS

Time

COTS available

System outgrew

1994

7 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Requirements

Functional needs for a company-wide information system:

Coordination between units.

Automation of processes (esp. report generation).

Data storage, analysis, and prediction.

Qualities needed: “good enough” security and performance.

State of affairs in 1996:

Unstable legislation: requirements shift monthly.

Unstable market: high turnover of companies.

No suitable COTS solutions available in Russian market.

Ad hoc management: situational decisions, no long-termcommitments.

8 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Build decision

In 1996, a decision (implicit/explicit?) to build an in-housesystem was made. A software development team of 1 personwas formed.

Interpretation

The decision was appropriate to circumstances. Even if COTSalternatives had existed, it probably would not have been worthinvesting into one because of overall instability of theenvironment.

9 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Architecture

Architecture of the system—thick client-based1. A singledatabase in Moscow; thick clients in other locations.

Interpretation

This architecture was sufficient for a number of years because:

Few employees used it =⇒ performance needs met.

Implementation size was small =⇒ no stability issues.

Required functionality was trivial =⇒ easy to modify.

1Thick client—a GUI application with ingrained business logic.10 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Outline

1 Context

2 Initial decision

3 COTS emerged

4 Outgrowth

5 Outcome

10 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Timeline

1996 1998 2000 2002 2004 2006 2008 2010 2012



I joined Si-Trans

I left Si-Trans

Transition to COTS

Time

COTS available

System outgrew

1994

10 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

COTS appears

In 2002–2003, a significantly advanced version of COTSproduct for enterprise management, 1C, was released. Itfeatured:

Ready-to-deploy components for personnel management,accounting and finance, wares management, contractmanagement, and report generation.

Different options for client-side applications: both thickand web-based.

More scalable architecture: decoupled data storage andclient request processing.

A platform (language, API, development toolkit) fordeveloping new components.

11 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

COTS evolves

By 2004–2005:

Significant expertise of extending 1C was present at jobmarket.

Russian companies made wide use of 1C platform.

The platform was reliable and tested enough to have beenadopted.

However, 1C had little to no support for transportationmanagement—one of Si-Trans’ main functional needs.

12 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

COTS missed

Si-Trans ignored the success of 1C and continued to developthe internal system.

Interpretation

Si-Trans missed an opportunity to adopt a platform that wouldadequately respond to the company’s growth. Also, Si-Transcould have avoided problems with in-house development thatfollowed shortly.

13 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Outline

1 Context

2 Initial decision

3 COTS emerged

4 Outgrowth

5 Outcome

13 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Timeline

1996 1998 2000 2002 2004 2006 2008 2010 2012



I joined Si-Trans

I left Si-Trans

Transition to COTS

Time

COTS available

System outgrew

1994

13 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Signs of outgrowing

Si-Trans started facing a number of issues with the homegrownsystem by 2006:

Source code difficult to manage: no investment inreadability, business logic growing complicated, increasingsize of source code.

Performance not sufficient: number of users grows, hencethe database becomes a bottleneck.

Poor stability: bugs do not get sufficient treatment as newfeature requests land on developers.

Availability is limited: not all sites have a powerful enoughinternet connection to run the system.

Update delivery is messy: no control over users’applications.

14 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

My role and context

I joined as a developer in 2010. Wide range of activities:

Fixing, improving, and extending the existing informationsystem.

Design and implementation of a prototype for a newsystem (3-tier architecture).

State of affairs in 2010:

Stable market of clients: the set of Si-Trans’ clients waswell-known and changed predictably.

Stable legislation: all forms to submit to governmentbodies did not change much over time.

The management style of Si-Trans persisted: it was still adhoc, experimentation-based.

15 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Technical debt

By 2010, the information system has accumulated serioustechnical debt. The development team has grown to 5 people,but was stuck struggling with the outgrown system.

Interpretation

It was inconsistent management that was accountable for:

Rapid accumulation of technical debt.

An overlooked opportunity to adopt COTS.

Their management style stemmed from absolute control overdevelopment.

16 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Example of inconsistent practices 1

Top management requests an immediate update that alllate transportations are checked and flagged every day.

The change is implemented as a complicated condition inclients (not a database-level operation).

The day after management decides to abandon the idea.Several weeks pass, and everyone forgets about therequest. The change is buried in other code.

Then, management decides to change the condition of atransportation being late. Now, it is implemented as adatabase trigger.

Result: intermittent bugs and staff-hours spent on findingout the cause.

17 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Example of inconsistent practices 2

A top manager has a very specific GUI in mind and wantsit implemented as soon as possible.

Several weeks after the GUI (and a corresponding datamodel) has been implemented and deployed, it turns outthat the change is conceptually inconsistent with otherparts of the system.

E.g. it operates a concept of “city” instead of a conceptof “office”.

Result: it takes a lot of time to spot all code that hasbeen built on the incorrect assumption. Being underconstant time pressure, programmers leave bugs behind.

18 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Conclusion of my experience

Interpretation

Chaotic management increased the cost of ownership andslowed down the development progress, mainly by constantlyserving contradicting feature requests and not leaving enoughtime for up-front design.

The shortsighted attitude of “we have programmers, so theywill do whatever we want” resulted in an immense technicaldebt and nearly stalled the development.

19 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Outline

1 Context

2 Initial decision

3 COTS emerged

4 Outgrowth

5 Outcome

19 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Timeline

1996 1998 2000 2002 2004 2006 2008 2010 2012



I joined Si-Trans

I left Si-Trans

Transition to COTS

Time

COTS available

System outgrew

1994

19 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Outcome

In January 2012, Si-Trans top management made a decision totransition to COTS. The development team (except the lead)was fired. Si-Trans and 1C started an analysis of how to tailor1C products to Si-Trans’ business model.

Interpretation

The decision of turning to COTS was based on the financiallosses on development that became obvious to management.These losses could have been avoided by acquiring the 1Centerprise management system as it became available. Toomuch control over the inherently flexible development processfrom the incompetent management costed Si-Trans a lot.

20 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Lessons 1/2

Inconsistent, chaotic management speeds up theaccumulation of technical debt as it makes requirementsdrift. Under such circumstances, building productsin-house is less attractive in the long-term perspective.

Excessive time pressure leads to a higher rate of technicaldebt accumulation because it forces sub-optimal decisions.One particular example is well-known: fix as many bugs aspossible before implementing new features.

“Degree of experimentation” in management shouldmatch environment and organization’s size. Whileappropriate in 1996, ad hoc and flexible management in2010 caused stagnation in development.

21 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Lessons 2/2

The issue of buying COTS or building software in-houseshould not be treated as a one-time issue. Constantre-evaluation of fitness for buying or building is needed.

The withdrawal of control over software development,introduced by acquiring COTS, may act as a forcingfunction to invest more into stabilizing requirements.While usually considered negative, lack of control mayhelp in case of abusive management.

22 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Thank you!

Questions?

23 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Carina Alves and Anthony Finkelstein.

Challenges in COTS decision-making: a goal-drivenrequirements engineering perspective.

In Proceedings of the 14th international conference onSoftware engineering and knowledge engineering, SEKE’02, page 789794, New York, NY, USA, 2002. ACM.

Xavier Franch and Marco Torchiano.

Towards a reference framework for COTS-baseddevelopment: a proposal.

In Proceedings of the second international workshop onModels and processes for the evaluation of off-the-shelf

23 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

components, MPEC ’05, page 14, New York, NY, USA,2005. ACM.

B. Craig Meyers and Patricia Oberndorf.

Managing Software Acquisition: Open Systems and COTSProducts.

Addison-Wesley Professional, 1 edition, July 2001.

Abdallah Mohamed, Guenther Ruhe, and Armin Eberlein.

COTS selection: Past, present, and future.

In Engineering of Computer-Based Systems, 2007. ECBS’07. 14th Annual IEEE International Conference andWorkshops on the, pages 103–114. IEEE, March 2007.

23 / 23


Ivan Ruchkin

Context

Initial decision

COTSemerged

Outgrowth

Outcome

References

Kurt Wallnau, Scott Hissam, and Robert C. Seacord.

Building Systems from Commercial Component.

Addison-Wesley Professional, 1 edition, August 2001.

23 / 23