Upload
ivan-ruchkin
View
38
Download
2
Embed Size (px)
Citation preview
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
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
Ivan Ruchkin
Context
Initial decision
COTSemerged
Outgrowth
Outcome
References
Geographic distribution as of 2011
5 / 23
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
Ivan Ruchkin
Context
Initial decision
COTSemerged
Outgrowth
Outcome
References
Outline
1 Context
2 Initial decision
3 COTS emerged
4 Outgrowth
5 Outcome
7 / 23
BuildingSoftwareIn-House
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
7 / 23
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
Ivan Ruchkin
Context
Initial decision
COTSemerged
Outgrowth
Outcome
References
Outline
1 Context
2 Initial decision
3 COTS emerged
4 Outgrowth
5 Outcome
10 / 23
BuildingSoftwareIn-House
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
10 / 23
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
Ivan Ruchkin
Context
Initial decision
COTSemerged
Outgrowth
Outcome
References
Outline
1 Context
2 Initial decision
3 COTS emerged
4 Outgrowth
5 Outcome
13 / 23
BuildingSoftwareIn-House
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
13 / 23
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
Ivan Ruchkin
Context
Initial decision
COTSemerged
Outgrowth
Outcome
References
Outline
1 Context
2 Initial decision
3 COTS emerged
4 Outgrowth
5 Outcome
19 / 23
BuildingSoftwareIn-House
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
19 / 23
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
Ivan Ruchkin
Context
Initial decision
COTSemerged
Outgrowth
Outcome
References
Thank you!
Questions?
23 / 23
BuildingSoftwareIn-House
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
BuildingSoftwareIn-House
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