APPLICABILITY OF AGILE SOFTWARE DEVELOPMENT … · Chapter 2 gives the reader an introduction to...
50
Helsinki University of Technology Software Business and Engineering Institute T-76.650 Software Engineering Seminar: Agile Software Development APPLICABILITY OF AGILE SOFTWARE DEVELOPMENT METHODOLOGIES TO DIFFERENT DEVELOPMENT ENVIRONMENTS DETERMINED BY A VENTURE’S BUSINESS MODEL AND EXTERNAL ENVIRONMENT 15.4.2002 [email protected] Jan-Mikael Tierala 48726M
Transcript of APPLICABILITY OF AGILE SOFTWARE DEVELOPMENT … · Chapter 2 gives the reader an introduction to...
Helsinki University of Technology
Software Business and Engineering Institute
T-76.650 Software Engineering Seminar: Agile Software Development
APPLICABILITY OF AGILE SOFTWARE DEVELOPMENT METHODOLOGIES TO
DIFFERENT DEVELOPMENT ENVIRONMENTS DETERMINED BY A VENTURE’S BUSINESS
MODEL AND EXTERNAL ENVIRONMENT
15.4.2002
Jan-Mikael Tierala 48726M
Table of Contents
1 Introduction .......................................................................................................................... 3 1.1 Background .................................................................................................................. 3 1.2 Research Problem......................................................................................................... 4 1.3 Objectives of the Research........................................................................................... 4 1.4 Scope of the Research .................................................................................................. 5 1.5 Research Methods and Reliability................................................................................ 5 1.6 Structure and Outline of the Report ............................................................................. 6
2 Agile Software Development Methodologies ...................................................................... 7 2.1 Definition of a Methodology........................................................................................ 7 2.2 Evolution of Methodologies......................................................................................... 8 2.3 Agile Methodologies .................................................................................................. 11
2.3.1 Extreme Programming Methodology................................................................. 13 2.3.2 Scrum Methodology........................................................................................... 15 2.3.3 Difference between Extreme Programming and SCRUM ................................. 16
3 Software Business Environment ........................................................................................ 17 3.1 External Environment ................................................................................................ 18 3.2 Internal Environment.................................................................................................. 20 3.3 Internal Processes....................................................................................................... 20 3.4 Software Business Model........................................................................................... 20
4 Business Model Elements & Internal Process Impacts...................................................... 24 4.1 Product Development Model ..................................................................................... 24
4.1.1 Value Proposition Type...................................................................................... 24 4.1.2 Product Cooperation & Networking .................................................................. 30 4.1.3 Product Compatibility ........................................................................................ 32 4.1.4 Intellectual Property Rights Management.......................................................... 33
4.2 Revenue Logic............................................................................................................ 35 4.2.1 Sources of Revenue............................................................................................ 35 4.2.2 Pricing Strategy.................................................................................................. 37
4.3 Marketing & Sales Model .......................................................................................... 38 4.4 Servicing & Implementation Model........................................................................... 40 4.5 Summary of Business Model Elements & Process Impacts ...................................... 43
5 Agile Methodology Applicability ...................................................................................... 45 6 Conclusions, Recommendations & Future Research ......................................................... 47 7 References .......................................................................................................................... 48
1 Introduction
1.1 Background
During the late 1990’s we experienced a tremendous growth in the number of software and
Internet related companies world wide. In the U.S. alone, the software industry generated
revenues of over 141 billion USD in 1998 with an annual growth rate of 15,4 % between 1994
and 1998 (Business Software Alliance, 1999). The software industry is a significant contributor
to the U.S. economy, providing direct employment for over 800 000 people, and indirectly
contributing to employment for 2,7 million people (Hietala, 2001). Today, many of the
companies are facing difficulties in generating profits or have already failed and do no longer
exist. Industry scholars point out that some of the difficulties can be explained by a natural
selection in a young, dynamic industry with too many players – only those with the best modes
of operation and who constantly manage to meet or exceed customer expectations can survive.
Uncertain and dynamic environments present fundamental challenges to managers of the new
product development process. Between successive product generations, significant evolutions
can occur in both the customer needs a product must address and the technologies it employs to
satisfy these needs. Even within a single development project, firms must respond to new
information, or risk developing a product that is obsolete the day it is launched. (MacCormack
et al., 2001)
To thrive in this turbulent environment, we must confront the business need for relentless
innovation and forge the future workforce culture. Agile software development approaches
such as Extreme Programming, Crystal methods, Lean Development, Scrum, Adaptive
Software Development (ASD), and others view change from a perspective that mirrors today’s
turbulent business and technology environment. (Cockburn & Highsmith, 2001a) These
methodologies provide tools for managing changing requirements and monitoring the team’s
performance throughout the development process, and should therefore be considered the
answer to our prayers. But can and should all companies engaged in software development
implement them?
In this report we take a look at agile software development methodologies, at business models
of software companies as well as their external environments, and build a framework for
analysing whether or not agile practises should be implemented in a specific situation. It is
expected that the company’s business model and its external environment will impact the
company’s internal software development processes in such a way that conclusions about the
applicability of agile methodologies can be justifiably made.
1.2 Research Problem
The ultimate purpose of this research is to contribute to the understanding of the success
factors of software companies. This paper will focus on the software development process and
discuss the benefits and restrictions of agile software development methodologies. The
underlying reason for this discussion is the fact that the agile practises have received an
enormous amount of publicity and praise in industry journals but many software companies are
still hesitating to implement them. This hesitation is caused by concerns related to the
suitability of the new practises to a specific software development environment – after all, each
company has its own environmental requirements and failure in just one project may have
significant consequences to the company.
The concept of a business model will be introduced to guide the discussion and establish a set
of critical elements that impact the company-internal software development processes. The
concept will be treated as a machine for turning valid ideas and opportunities into money.
The research problems can be expressed as follows:
1.3 Objectives of the Research
The ultimate objective of this report is to contribute to the understanding of the applicability of
agile software development methodologies to different software development processes.
In order of importance the objectives of the study are:
1. To present a framework for determining the applicability of agile software development
methodologies to a specific development project determined by a venture’s business
model and external business environment
How applicable are agile software development methodologies to
different company-internal development processes determined by a
venture’s business model and external business environment?
2. To define software business model and external business environment elements and
identify how element variations affect the company-internal software development
environment
3. To present Extreme Programming and Scrum as examples of agile methodologies
4. To identify differences between agile and traditional software development
methodologies
5. To establish a basis for further research
1.4 Scope of the Research
This report will focus on Extreme Programming (XP) and Scrum as examples of agile software
development methodologies. This report will not discuss different types of “traditional”
software development methodologies. They will be treated as being more robust and inflexible
than agile methodologies. This report will focus on external factors as elements affecting the
applicability of agile methodologies.
1.5 Research Methods and Reliability
The research will be limited to literature research. Material will be gathered from research
reports, industry journals, books and the Internet. The availability of literature concerning both
agile software development and Extreme Programming, as well as software business models, is
expected to be scarce. The impact of the scarceness of sources of information on the reliability
of the study needs to be evaluated once the study has been finished. Especially the expected
lack of empirical evidence will undermine the reliability.
BusinessModel
ElementExternal Environment Internal Processes
Business Environment
BusinessModel
ElementExternal Environment Internal Processes
Business Environment
If external impact
Identify businesmodel element
Check if business modelelement is affected byexternal environment
Identify impact oninternal processes
1.2. 3.
ResearchMethodology If external impact
Identify businesmodel element
Check if business modelelement is affected byexternal environment
Identify impact oninternal processes
1.2. 3.
ResearchMethodology
Figure 1: The research methodology used in establishing the impact of the external environment on the
internal software development processes.
Results presented in this report will be based on literature research. Testing and modification is
left to future work. This limitation is set due to both time and financial limitations. Thorough
testing would require monitoring portfolio projects for their full lifecycle and within the
framework of this study it is not feasible.
1.6 Structure and Outline of the Report
This paper is divided into four chapters in addition to the introduction and the conclusion.
Chapter 2 gives the reader an introduction to agile software development methodologies by
defining a methodology and comparing “traditional” and agile methodologies. Also brief
summaries of Extreme Programming and SCRUM methodologies are provided as examples of
agile methodologies. Chapter 3 introduces the reader to the concept of the software business
environment consisting of the external and internal environments, internal processes, and the
business model. Chapter 4 discusses software business model elements in detail and links them
to factors in the external environment, which are further linked to the internal software
development process. A short summary of the findings is provided in the end. Chapter 5 links
the findings in the previous chapter concerning the impact on the internal software
development process of the external environment and the software business model to the
applicability of agile methodologies in specific situations.
2 Agile Software Development Methodologies
2.1 Definition of a Methodology
The Merriam-Webster dictionaries define a methodology as "a series of related methods or
techniques." Furthermore, a method is defined as a "systematic procedure", similar to a
technique.
According to Cocburn (2002), “your ‘methodology’ is everything you regularly do to get your
software out. It includes who you hire, what you hire them for, how they work together, what
they produce, and how they share. It is the combined job descriptions, procedures, and
conventions of everyone on your team. It is the product of your particular ecosystem and is
therefore a unique construction of your organization.”
Simply put, a methodology is the way a company does business and consequently all
organisations have one. It is a social construction determining individual tasks, ways of
communication and distribution of decision-making, and it has been agreed upon by all group
members. Figure 2 illustrates the elements of a methodology and their inter-relations.
Figure 2: Elements of a methodology (Cockburn, 2002).
The elements are further explained in Table 1 below.
Table 1: Methodology element descriptions (adopted from Cockburn, 2002)
Element Description Roles Who you employ, what you employ them for, what skills they are supposed
to have. Equally importantly, it turns out, is the personality traits expected of the person.
Skills The skills needed for the roles. Teams The roles that work together under various circumstances. Techniques The specific procedures people use to accomplish tasks. Activities How the people spend their days. Process How activities fit together over time, often with pre- and post-conditions
for the activities. Work products What someone constructs. Milestones Events marking progress or completion. Standards The conventions the team adopts for particular tools, work products, and
decision policies. Quality Quality may refer to the activities or the work products. Team Values The rest of the methodology elements are governed by the team's value
system.
2.2 Evolution of Methodologies
Most software development is a chaotic activity, often characterized by the phrase "code and
fix". The software is written without much of an underlying plan, and the design of the system
is cobbled together from many short term decisions. This actually works pretty well as the
system is small, but as the system grows it becomes increasingly difficult to add new features
to the system. Furthermore bugs become increasingly prevalent and increasingly difficult to
fix. A typical sign of such a system is a long test phase after the system is "feature complete".
Such a long test phase plays havoc with schedules as testing and debugging is impossible to
schedule. (Fowler, 2000)
The above citation describes how software development was conducted 15 years ago, and how
it is still done in many companies. However, as a response to the uncertainty and
unpredictability related to ad-hoc programming, some software developers started to impose
disciplined approaches, i.e. methodologies, to manage the development process with the aim of
making software development more predictable and more efficient. First we saw the
emergence of heavy, or monumental, methodologies, such as the waterfall model.
Figure 3 illustrates the different approaches on software development in terms of scheduling of
analysis, design, implementation, and testing tasks. The waterfall model is a robust and
efficient model that expects us to know all requirements of the final product already in the
analysis phase. If we indeed do know them, this may be a good process for our software
development. But if we don’t, the cost of changes will increase dramatically with time. And
how often do we really, really know all the requirements in the beginning? Furthermore, these
early methodologies have been criticised for being too bureaucratic.
The next step in the development was the spiral methodology introduced by Boehm (1988).
The linear waterfall approach is executed repeatedly in several phases to deliver the end
product. This was and still is commonly used in conventional projects and on many object-
oriented projects with inexperienced leadership. According to Sutherland (2002), productivity
gains compared with the waterfall model are typically less than 30% using this approach with
object technology.
Analysis
Design
Implementation
Test
Time
Scope
WATERFALL ITERATIVE AGILE
Analysis
Design
Implementation
Test
Analysis
Design
Implementation
Test
Time
Scope
WATERFALL ITERATIVE AGILE
Figure 3: The evolution of the Waterfall Model (a) and its long development cycles (analysis, design,
implementation, test) to the shorter, iterative development cycles within, for example, the Spiral Model (b)
to Agile Software Development’s (c) blending of all these activities, a little at a time, throughout the entire
software development process. (Adopted from Beck, 1999.)
The iterative model was developed as a response to this uncertainty of requirements and a
typical example of an iterative model is the spiral model developed by Boehm (1988). By
splitting the development process into several shorter development cycles, we can first focus
on components and issues we know for certain. Once these components have been tested, we
will make another round of analysis and select new components whose requirements have now
been revealed. This process of iterative steps will continue until all requirements have been met
in the software product. This model may not be as efficient as the waterfall model, but it averts
some of the risk of developing software with the wrong requirements and paying big bucks for
changes. According to Sutherland (2002), productivity gains are typically at least 30% on
object-oriented projects. However, many development groups have complained that the
dramatic productivity gains promised by object technology have not been achieved using this
method.
Agile software development is the most recent family of software engineering processes in a
series of efforts of averting risk and associated cost of changing software. The agile model
presented in Figure 3 is a representation of Extreme Programming (XP), but nevertheless
brings forward the idea behind all agile methodologies. In agile methodologies, the traditional
phases (design, implementation, test) following the initial analysis are no longer organised
subsequently. Instead, these activities are done simultaneously and little at a time, throughout
software development. The cost of having to change software becomes minimal. According to
Sutherland (2002), productivity gains of 600% have been seen repeatedly in well executed
projects by using Scrum, which is a representative of the agile methodologies.
The incredible productivity gains of agile methodologies (of which Scrum was used as an
example) reported by Sutherland (2002) are questioned to a certain extent by Cockburn (2002).
According to Cockburn, successful serial development takes longer than successful concurrent
development, but requires fewer working days. In other words, Cockburn states that it might in
fact be cheaper to use serial development such as the waterfall model specifies. One should
keep in mind that in highly volatile and uncertain environments, the cost-benefit of serial
development is rapidly evaporated as in most cases the deliverable does not match with real
requirements and consequently the development process is no longer successful. Figure 4
illustrates the difference between serial and concurrent development as a function of time.
RequirementsDesignProgrammingTestElapsed TimeRequirementsDesignProgrammingTestElapsed Time
Figure 4: Successful serial development takes longer (but fewer workdays) compared to successful
concurrent development.
2.3 Agile Methodologies
Today’s software business environment continues to change at a dramatically increasing pace.
To survive and thrive in this turbulent environment, businesses need to adopt practises of
relentless innovation and flexibility to meet changing requirements. Conforming to plan is no
longer the primary goal of a project; instead, satisfying customers at the time of delivery has
taken precedence.
Similarly, the problem of increasing cost of change through the software’s development life
cycle is being tackled in a new way. The question isn’t anymore how to stop change as early as
possible but how to better handle inevitable changes. Traditional approaches assumed that if
enough resources were assigned to analysis and design in the beginning of a project, the
complete set of requirements could be anticipated and cost reduced by eliminating change.
However, in today’s business environment, eliminating change early can and should be
associated with unresponsiveness to business conditions and thus, business failure.
Agile software development is a response to the market’s demand of innovative, high-quality
software that meets its needs and is delivered quickly. The strategy is to reduce the cost of
change throughout the software development project. According to Cockburn & Highsmith
(2001a), agile methodologies stress two concepts: working code and the effectiveness of
people working together with goodwill.
Working code is something real, deliverable and measurable, as opposed to promises made to a
customer. Even more importantly, customers can test and provide feedback on working
components throughout the project. Using people effectively by having them communicate
face to face instead of writing and reading documentation achieves maneuverability, speed, and
cost savings. A team can become more effective in responding to change by (1) reducing the
cost of moving information between people and (2) reducing the elapsed time from the making
of a decision to seeing its consequences (see Cockburn & Highsmith, 2001b).
While this focus on team dynamics should ensure that a team spirit develops and team
performance improves, it can infuriate the brilliant loners who like "to pull all-nighters" as they
code software idiosyncratically in solitary confinement for 24 hours or more. But a frustrated
diva is considered a small price to pay for ensuring that the code remains relevant to the
customer's changing needs. (see Economist, 2001)
There does not exist one universally used agile methodology: Instead, a whole family of these
new approaches have recently been introduced and they offer a wide variety of methods to be
used in different development environments. Common agile software development approaches
are e.g. Extreme Programming, Crystal methods, Lean Development, Scrum and Adaptive
Software Development (ASD). Scholars largely responsible for the development of these
documented agile methodologies met in 2001 and agreed on common guidelines. The product
of this meeting was the ‘Manifesto for Agile Software Development’ (Beck et al., 2001), which
can be summarised by the following excerpt:
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.”
Finally, we would like to remind the reader of a fact that is often forgotten: methods and
methodologies should not be implemented and maintained for their own sake. Instead, they
should be treated merely for what they are, i.e. tools for reaching business goals. Goldman et
al. (1995) discussed agility and agile processes in relation to manufacturing. Even though
software development can and should be thought of as something very different, the citation
below is just as valid in our context:
“Agility is dynamic, context-specific, aggressively change embracing, and growth-oriented. It
is not about improving efficiency, cutting costs, or battening down the business hatches to ride
out fearsome competitive ‘storms.’ It is about succeeding and about winning: about succeeding
in emerging competitive arenas, and about winning profits, market share, and customers in the
very centre of the competitive storms many companies now fear.”
2.3.1 Extreme Programming Methodology
Extreme Programming (XP), currently the most popular agile methodology (Economist, 2001),
uses techniques such as pair-programming, in which one person programs while a partner
checks the result for bugs and makes sure that only essential code is produced. Below is a
quick summary of each of the major practices in XP (see Beck, 1999).
Planning game. Customers decide the scope and timing of releases based on estimates
provided by programmers. Programmers implement only the functionality demanded by the
stories in this iteration.
Small releases. The system is put into production in a few months, before solving the whole
problem. New releases are made often—anywhere from daily to monthly.
Metaphor. The shape of the system is defined by a metaphor or set of metaphors shared
between the customer and programmers.
Simple design. At every moment, the design runs all the tests, communicates everything the
programmers want to communicate, contains no duplicate code, and has the fewest possible
classes and methods. This rule can be summarized as, “Say everything once and only once.”
Tests. Programmers write unit tests minute by minute. These tests are collected and they must
all run correctly. Customers write functional tests for the stories in an iteration. These tests
should also all run, although practically speaking, sometimes a business decision must be made
comparing the cost of shipping a known defect and the cost of delay.
Re-factoring. The design of the system is evolved through transformations of the existing
design that keep all the tests running.
Pair programming. All production code is written by two people at one
screen/keyboard/mouse.
Continuous integration. New code is integrated with the current system after no more than a
few hours. When integrating, the system is built from scratch and all tests must pass or the
changes are discarded.
Collective ownership. Every programmer improves any code anywhere in the system at any
time if they see the opportunity.
On-site customer. A customer sits with the team full-time.
40-hour weeks. No one can work a second consecutive week of over-time. Even isolated
overtime used too frequently is a sign of deeper problems that must be addressed.
Open workspace. The team works in a large room with small cubicles around the periphery.
Pair programmers work on computers set up in the centre.
Just rules. By being part of an Extreme team, you sign up to follow the rules. But they’re just
the rules. The team can change the rules at any time as long as they agree on how they will
assess the effects of the change.
According to Glass (2001), the bad news of XP are:
- Pair programming: many professionals will feel uncomfortable with this
- Refactoring: Ongoing design at development time is inefficient and impossible
to manage in large projects
- Short bursts of planning: starting a large project without a full vision of the
development project is a disaster
Glass (2001) also identified the good news of XP: unit testing, relying on metaphors,
continuous integration and the emphasis on simplicity. Nevertheless, he states that “many
elements are inappropriate for all but the tiniest projects, so there is little excuse for seeing this
as a mainstream methodology”, but that some practises could scale up to larger projects as
well.
2.3.2 Scrum Methodology
Scrum literature focuses mainly on the iterative planning and tracking process. It's very close
to the other agile methodologies in many respects and should work well with the coding
practices from XP. (Sutherland, 2002)
SCRUM’s goal is to deliver as much quality software as possible within a series (3-8) of short
time-boxes called Sprints that typically last about a month. Each stage in the development
cycle (Requirements, Analysis, Design, Evolution, and Delivery) is now mapped to a Sprint or
series of Sprints. The traditional software development stages are retained for convenience
primarily for tracking milestones. So, for example, the Requirements stage may use one Sprint,
including the delivery of a prototype. The Analysis and Design stages may take one Sprint
each. While the Evolution stage may take anywhere from 3 to 5 Sprints.
As opposed to a repeatable and defined process approach, in SCRUM there is no predefined
process within a Sprint. Instead, Scrum Meetings drive the completion of the allocated
activities.
Each Sprint operates on a number of work items called a Backlog. As a rule, no more items are
externally added into the Backlog within a Sprint. Internal items resulting from the original
pre-allocated Backlog can be added to it. The goal of a Sprint is to complete as much quality
software as possible.
During a Sprint, fifteen-minute Scrum Meetings are held each day in order to check on:
1. What items were completed since the last Scrum Meeting
2. What issues or Blocks have been found that need to be resolved
3. What new assignments make sense for the team to complete until the next Scrum
meeting
Scrum Meetings allow the development team to "socialize the team members knowledge", and
have a deep cultural transcendence. In turn, this "knowledge socialization" leads to a self-
organized team structure, where the process is invented in an adaptable way on a daily basis.
At the end of each Sprint, there is a Demo to:
1. Show the customer what’s going on
2. Give the developer’s a sense of accomplishment
3. Integrate and test a reasonable portion of the software being developed
4. Ensure real progress – reduction of backlog, not just more papers / hours spent
After gathering and re-prioritising the leftover and new tasks, a new Backlog is formed and a
new Sprint starts.
SCRUM allows us to build softer software, so there is no use trying to write full requirements
up front. The user does not know what is possible and will ask for the pre-tech-paper solution
that he perceives to be possible. But not even the software developers know fully what can be
built before it is. And therefore the user has no clue of what is possible before he can feel it, or
touch it.
The primary difference between the defined (waterfall, spiral and iterative) and empirical
(SCRUM) approach is that The SCRUM approach assumes that the analysis, design, and
development processes in the Sprint phase are unpredictable. A control mechanism is used to
manage the unpredictability and control the risk. Flexibility, responsiveness, and reliability are
the results. (Schwaber, 1996)
2.3.3 Difference between Extreme Programming and SCRUM
According to Sutherland (2002), Extreme Programming (XP) coding practises work well
together with SCRUM’s iterative planning and tracking process. Rautiainen et al. (2002b) have
compared the scopes of XP and SCRUM from a product development management and
product road-mapping perspective. The 4CC framework used in the evaluation of XP and
SCRUM identifies four cycles of control of software development. The results are presented in
Table 2 below.
Table 2: A mapping of key elements of XP and SCRUM to the concept of 4CC framework. (adopted from
Rautiainen et al. 2002b)
Concepts in 4CC \ Process Model
Strategic Release Management
Release Project Management
Iteration Management
Mini-Milestones
XP - Planning game - Metaphor - On-site customer
- Small releases -Continuous integration
SCRUM - Product backlog - Sprint planning meetings - Sprint reviews
- Release backlog - Sprint backlog - Daily Scrum meetings
Based on the information presented in the two previous sections and the short comparative
analysis in this section we can conclude that SCRUM has a high-level approach to managing
software development, i.e. that it focuses on general guidelines and does not address details
concerning software development, whereas XP has a low-level approach and addresses the
details but lacks tools to control general guidelines. Consequently, we can conclude that they
are complementary in their nature instead of excluding one another.
3 Software Business Environment
In this chapter we will present the general concept of a software business model and identify
how it relates to the firm’s external and internal environments, and to the company-internal
processes. To understand these relationships we should examine Figure 5. A business model
can be considered as a firm’s strategic way of dealing with the outside, a gateway between the
external environment and the internal processes.
BusinessModel
Product
InternalProcesses
ExternalEnvironment
InternalEnvironment
BusinessModel
Product
InternalProcesses
ExternalEnvironment
InternalEnvironment
Figure 5: The software business environment - the business model as an intermediary between the external
environment and the internal processes of a firm (adopted from SoberIT, 2002).
The external environment poses challenges and requirements on the internal processes and vice
versa, and the business model functions as an intermediary in between. Generally, when a firm
is small in comparison to the total size of the market it operates in, the external environment
can be considered quite rigid and the firm is left with little chance of shaping it. Thus, in most
cases a firm needs to align its business model and its internal processes according to the
external environment. However, if a firm achieves a very dominant market position, like
Microsoft for example, it has the ability to shape the external environment to a certain extent
according to its own strategy and processes. However, it is questionable whether this kind of
market orchestration by involuntary lock-in can be sustained in the long run (Eloranta, 2002).
The internal environment on the other hand has a direct and thus less obscure relation to the
internal processes. The internal environment and the internal processes also pose challenges
and requirements on each other, but without an intermediary. Consequently it is easier to
understand the causality of various implications, but this does not by any means mean that this
relationship would be stronger. Because firms often have the ability to shape both the internal
environment and the internal processes, this relationship can be considered easier to deal with
In this chapter we will start by looking at the external environment and assume that it strongly
affects a firm’s strategic options and the internal processes. We will also take a short look at
the internal environment in order to give the reader an understanding of the concept but the
discussion will be limited to a general overview since this has been ruled out of our scope.
Finally, we will provide a general definition of what we mean by the firm’s internal processes
and of a software business model.
3.1 External Environment
In this sub-chapter we will present a short overview of the fundamental elements of the
external environment. The purpose is to give the reader a general understanding of the
environmental elements as a reference for future discussion. Here the purpose is not to
extract specific environmental factors that affect the internal processes. This discussion will be
introduced in conjunction with the presentation of the business model elements.
Hitt et al. (1999) present a comprehensive set of external factors, which is illustrated in Figure
6.
Figure 6: The company’s external environment (adapted from Hitt et al., 1999).
The general environment is composed of elements in the broader environment that can
influence an industry and the firms within it. The general environment cannot directly be
controlled by a single player, and thus the strategic challenge is to understand the impact of
each of these elements and align the company’s business model accordingly. The demographic
segment includes issues such as population size, age structure, ethnic mix and income
distribution. The economic segment encompasses inflation and interest rates, GDP
development, as well as trade and budget deficits or surpluses. The sociocultural segment deals
with gender equality, environmental concerns, and quality of work life. The political/legal
segment discusses antitrust, taxation and labour training laws, and educational policies. The
technology segment treats innovation and R&D expenditure levels, and finally the global
segment discusses international politics, access to critical global markets, and cultural aspects.
The industry environment encompasses a set of factors that directly affect a company and its
business model. These factors are: threat of new entrants, power of suppliers, power of buyers,
product substitutes, and intensity of rivalry. The interactions of these factors determine the
industry’s profit potential and the ability of a particular company to favourably influence them
determines its potential to earn above-average returns.
The competitor environment is the firm’s understanding of its competitors and it
complements the insight provided by a study of the general and the industry environment. A
competitor analysis should encompass benchmarking in at least the following areas: future
objectives, current strategy, assumptions and capabilities.
3.2 Internal Environment
In this section we will present a short overview of the fundamental elements of the internal
environment. Again, the purpose is to give the reader a general understanding of the
environmental elements as an explication to earlier discussion – not to extract specific factors
that impact the internal processes.
Hitt et al. (1999) define three elements in the internal environment as the foundation of
competitive advantage: resources, capabilities, and core competencies. Resources are inputs
into a firm’s production process such as capital goods, skills of individual employees, patents,
and finance. Capabilities represent a firm’s ability to utilise allocated resources. Capabilities
are often based on developing, carrying and exchanging information and knowledge through
the firm’s human capital. Core competencies distinguish a company competitively and reflect
its personality and they emerge over time through an organisational learning process. Core
competencies are the essence in differentiating a company in its ability to provide value to
customers over a long period of time.
3.3 Internal Processes
A process in this context is a series of activities with a specific purpose. A process is actually
very similar to a methodology in the sense that it is everything you do to achieve a certain goal.
In the context of this report we distinguish them by stating that a methodology represents the
strategic decision to operate in a certain way, whereas a process is the embodiment of the
methodology. This difference is, however, not important and the terms will be used as
synonyms. Consequently, internal processes are modes of operation within the firm.
3.4 Software Business Model
The concept of a business model is in frequent use especially by strategy- and IT-consultants,
but most of them use the expression quite freely to signify anything related to the way a firm
conducts its business.
Before the term business model had entered the arena, one might have used for example the
definition of a product strategy for discussing strategic issues and company operations
related to a specific product. The concepts of core product and whole product are discussed in
the literature of strategic marketing. According to Cravens (1987) a product strategy consists
of the following dimensions:
1. Positioning of product offering
2. Setting strategic objectives for product offering
3. Selecting a branding strategy
4. Developing and implementing new strategies
This definition of a product strategy focuses on the external market environment and does not
address e.g. the product development process. Consequently it is by far too narrow to suite
our needs.
Another concept used for describing a firm’s vision of generating value with its functional
capabilities is technology strategy. According to Maidique & Patch (1978), technology
strategy is defined by a set of interrelated decisions encompassing e.g. technology choice,
level of technology competence, level of R&D funding, timing of technology introduction in
new products/services, and organisational capabilities for technology application and
development. Technology strategy is analogous with financial and human resource strategies
(Burgleman & Rosenbloom, 1989), and it is much broader than R&D strategy (Mitchell, 1986).
In comparison to Cravens (1987) definition of a product strategy, which discussed the external
market strategies, technology strategy seems to have an internal focus.
Today these definitions are, especially when treated separately, far from sufficient in
explaining the concepts we want and need to associate with a business model. The first
literature definitions of a business model appear in the late 1990’s. Put simply, a business
model is a machine for turning valid ideas and opportunities into money (Whittingham, 2000).
Figure 3 below illustrates on a conceptual level the scope of a business model in comparison
to the scopes of technology strategy and product strategy.
Business Model
TechnologyStrategy
ProductStrategy
Business Model
TechnologyStrategy
ProductStrategy
Figure 7: A conceptual illustration of the scope of a business model in comparison to the scopes of
technology strategy and product strategy.
Only recently have academic efforts been made in order to establish a definition of the concept
of a business model. The first literature definitions of a business model appear in the late
1990’s. Put simply, a business model is a machine for turning valid ideas and opportunities into
money (Whittingham, 2000).
Rajala et al. (2001) define a business model as an entirety comprising of two elements: value creation and value appropriation. The same research report also identifies a three-step
evolution of ideas, or concepts, as the root of a business model. These concepts are:
business idea, business plan, and corporate and business strategy. A business idea explains
the existence of a company by answering the questions:
1. What? 2. To whom? 3. How?
A business plan is a written explanation of how the business idea is put into operation. A
corporate strategy answers the question: What businesses is the company involved in? In
addition, it deals with resource deployments and environmental interactions. A business
strategy focuses on one particular business, or product segment. According to the definition,
one business strategy corresponds to each business model. Consequently, a corporate business
portfolio may include several business models. Figure 8 presents a graphical description of this
interrelationship between the discussed concepts.
CorporateBusinessPortfolio
Business Strategy
Business Plan
Business Idea
Corporate Strategy
BusinessModel
CorporateBusinessPortfolio
Business Strategy
Business Plan
Business Idea
Corporate Strategy
BusinessModel
Figure 8: The concepts of business idea, business plan, business strategy and corporate strategy linked to
the concept of a business model.
Furthermore, the study by Rajala et al. (2001) defined a conceptual framework of a software
business model, which is presented in Figure 9. This framework divides a business model into
four elements and an extensive set of sub-elements. The four main elements are: product
development model, servicing & implementation model, marketing & sales model, and
revenue logic. We want to remind you that a business model focuses on one product/business
only. If a company has several products, it will consequently need a portfolio of business
models as well. But as we will see, business models can support and rely on each other
strategically.
Marketing &Sales Model
Servicing &Implementation
Model
ProductDevelopment
Model
RevenueLogic
BusinessStrategy
ProductOffering
CompetingEnvironment
Customers
FinancingEnvironment &Stakeholders’Utilities
ResourceEnvironment
BusinessModel Marketing &
Sales Model
Servicing &Implementation
Model
ProductDevelopment
Model
RevenueLogic
BusinessStrategy
ProductOffering
CompetingEnvironment
Customers
FinancingEnvironment &Stakeholders’Utilities
ResourceEnvironment
BusinessModel
Figure 9: Elements of a business model (Rajala et al., 2001).
The framework is the most comprehensive definition currently available and does indeed
include the most important factors. This framework does also support the previously presented
relationship between the external environment and the internal processes of a firm with the
business model as an intermediary in between (see Figure 5). However, it does not establish the
frontier with the internal processes as clearly as with the external environment, and this poses
some challenges on us as we are especially interested in the factors of the business model that
affect the internal software development processes. Consequently, we will have to look at each
of the business model elements and their sub-elements to establish a set of factors that affect
the internal processes of our interest, the software development process.
4 Business Model Elements & Internal Process Impacts
In this chapter we will look at each of the elements that constitute a business model and
identify factors that affect the internal software development process. Discussion will focus on
providing a general description of each element and on linking the element at hand to both the
external environment and to the internal software development processes according to the
research methodology presented in Figure 1 in the research methods-section in the introduction
chapter. Note that only the software development process is in our scope and hence impacts on
other processes will not be discussed.
A summary of the findings will be provided in the sub-chapter 4.5.
4.1 Product Development Model
Technology strategy is one of the most important aspects of any firm’s strategic posture
especially in dynamic environments such as the computer software industry (Zahra & Bogner,
1999). According to Rajala et al. (2001), the product development model defines how the
process that creates the value proposition is structured, i.e. what components it comprises of
and which actors provide them. In this section the product development model element has
been divided into several sub-elements in order to provide the reader with understanding of all
aspects. The Rajala et al. (2001) study chose to focus on only one of these sub-elements,
namely the value proposition type. We have identified three additional sub-elements of the
product development model: product cooperation & networking, product compatibility and
intellectual property rights management.
4.1.1 Value Proposition Type
The value proposition type can be defined as a combination of the object of trade, the degree of
productisation, the novelty, the complexity, and the criticality of the offering.
Object of Trade
According to Nukari & Forsell (1999), the offerings, or objects of trade, of the software
industry can be roughly divided into three categories: software products, customer tailored
software (or customized software), and embedded software, as shown in Figure 10.
EmbeddedSoftware
Customer-TailoredSoftware
SoftwareProducts
EmbeddedSoftware
Customer-TailoredSoftware
SoftwareProducts
Figure 10: Three types of software offerings: customer-tailored software, software products, and embedded
software (Nukari & Forsell, 1999).
Software products are traded on their own, not as part of other products. Although software
product business often includes other things such as installation, training, and even
customisation, the main object being traded is software. (Hietala, 2001)
Embedded software, on the other hand, consists of software that is built into other products,
such as cellular phones, refrigerators, paper machines or television sets, and not sold separately
(Hietala, 2001). Embedded software has several characteristics of pure software products, e.g.
it is developed once, it is sold in many identical copies, it has high development costs and low
manufacturing costs, but from a customers point of view it is not the essential issue.
Customer-tailored software, or customized software, are traded as a package consisting of
consulting services, feasibility and IT advice, software development, installation, training and
support. The main object being traded is the effort of making the software. Instead of buying a
software product in an off-the-shelf package, the customer pays for the work of making the
software specifically for her needs.
The object of trade is determined by customer needs and market characteristics such as market
size and heterogeneity, customer willingness to pay for personal services, and customer
perceived value driver. The type of the object of trade does have some implicit impact on the
internal software development processes. However, the impact is caused by the difference in
the degree of productisation that is directly associated with whether the offering is a product or
tailored software. No direct conclusions can be made on the impact of embedded software
either. Consequently, we will not consider the object of trade as an element impacting the
internal software development processes.
Degree of Productisation
Software can be prefabricated, developed specifically to the needs of each customer, or a
combination of the two. This dimension, the degree of productisation, is crucial in striking a
difference between software product and project business. (Hietala, 2001)
Hoch et al. (1999) identified three levels of productisation in the software business:
professional services. Enterprise solutions, and packaged mass-market software. Figure 11
illustrates the spectrum of software productisation and shows the positioning of the identified
software offering types within it.
1
10
100
1 000
10 000
100 000
10 000 000
1 000 000
Professional Services
EnterpriseSolutions
PackagedMass-Market
Software
Degree of Productisation
Unit Sales
MediumLow High
1
10
100
1 000
10 000
100 000
10 000 000
1 000 000
Professional Services
EnterpriseSolutions
PackagedMass-Market
Software
Degree of Productisation
Unit Sales
MediumLow High
Figure 11: Three levels of productisation in the software product and service business: professional
services, enterprise solutions, and packaged mass-market software (Hoch et al. 1999).
Packaged mass-market software products are sold off-the-shelf. The level of productisation
is very high and identical copies are sold to large number of customers.
Professional services are customer tailored software. The software is developed according to
the needs and specifications of individual customers, resulting in a low level of productisation.
The software is rarely reproduced in its original form, although consulting companies offering
customer-tailored software often reuse some of the software components. The accumulated
knowledge and problem solving skills from previous projects are of high value.
Enterprise solutions are a combination of packaged software and software tailoring services.
The need for this type of solutions arises when a packaged software isn’t sufficient for the
customer, but it is still cheaper to work from a packaged software than to start from scratch. In
fact, many consulting companies try to develop a customisable product, which they then use
for communicating their skills.
The object of trade is determined by customer needs and market characteristics such as market
size and heterogeneity, customer willingness to pay for personal services, and customer
willingness to compromise on specifications. The degree of productisation does have an
obvious impact on the internal software development processes. A low degree of
productisation calls and allows for more customer cooperation in e.g. requirements
management, and also necessitates early and continuous test releases to allow the customer to
evaluate tangible prototypes. Thus, an agile and flexible methodology is important. On the
other hand, a high degree of productisation often rules out direct customer cooperation as there
is no specific customer who to turn to. Instead, customer intelligence and marketing should be
incorporated to the development process so that the developed product satisfies the needs of a
large amount of customers. To reach a high level of productisation, the customers’
requirements need to be similar across the market and the customers need to be willing to
compromise on the specifications. Agility and flexibility of the software development
methodology is not a necessity because of the customers’ needs. Packaged mass-market
software development can be successfully executed with both robust and agile approaches.
Often no customer cooperation is available, which makes the implementation of agile practises
harder.
Offering Novelty & Radicality
The dimension of offering novelty, or radicality, is a relative measure between the
characteristics of the current and the previous offering. Radicality is evidenced usually in the
newness of the technology itself (as in the case of breakthroughs or paradigm shifts), or in the
newness of applications the technology offers to the customer. Offering radically new
technologies (products) can be risky because customers may not accept them, or they may not
become the industry’s standard. On the other hand, if customers do accept the new technology
(product), the firm will be able to benefit from its first-mover advantage.
According to the results of an empirical study by Zahra & Bogner (1999), new product
radicality has a positive impact on both return on equity and market share in dynamic
environments and a negative impact on both parameters in highly competitive environments
when price is the primary source of competitive advantage. The success of new product
radicality does not seem to be influenced by the level of competition in regard of quality as the
primary source of competitive advantage, nor by the level of fragmentation of markets.
Technology and product novelty correlate with uncertainty of requirements during the
development phase, which further correlates with market dynamism. In dynamic environments,
flexible and agile development methodologies have most advantage. The level of competition
in regard of price does impact the software development process in the sense that when cost is
the primary source of competitive advantage, one should implement the least costly
methodology. As presented earlier in sub-chapter 2.2 in Figure 4, successful serial
development is less costly than successful concurrent development. In dynamic and price-
sensitive environments, concurrent development is expected to significantly outperform serial
processes because of its superior ability to handle uncertainty.
Offering Complexity
Cockburn (2002) uses the term ‘problem size’ to describe “the number of elements in the
problem and their inherent cross-complexity.” There is no absolute measure of problem size, or
offering complexity, since different people with different knowledge and experience are likely
to make different estimations. However, in many cases it is possible to make estimations and
comparisons (launching a space shuttle is a bigger problem than printing a firm’s invoices).
Customer demands and market characteristics shape the complexity of the offering. The
development of a very complex software product requires more management efforts, control
mechanisms and pre-defined processes, whereas a simple product can be developed largely
without any predefined practises at all. Cockburn (2002) uses the term “methodology weight”
to describe the robustness of a methodology. The question of serial vs. concurrent development
cannot be answered in terms of offering complexity, although agile approaches are generally
recommended for less complex projects.
As an alternative approach to evaluating the problem size, we can use some parameters of the
planned project. This approach is not always convenient since it requires a complete analysis of
the problem and also planning of the entire project. Nevertheless, if this has already been done
we can use it as a guideline in determining the problem size. Figure 12 illustrates project
complexity in terms of project size (number of people) and project length.
Project Length
Project Size(Number ofPeople)
MediumShort Long
2
4
8
16
32
64
128
256
High Complexity
MediumComplexity
LowComplexity
Project Length
Project Size(Number ofPeople)
MediumShort Long
22
44
88
1616
3232
6464
128128
256256
High Complexity
MediumComplexity
LowComplexity
Figure 12: Complexity levels of software projects in terms of project size (number of people) and project
length.
Projects with a low level of complexity (small & short project) will not require much overhead,
e.g. in the form of formal documentation. As complexity increases (larger & longer project)
however, more and more formality is required in order to keep track of all parameters,
eventually increasing methodology weight.
Offering Criticality
Offering criticality refers to the impact an undetected defect will have on the customer.
Cockburn (2002) divides criticality into four categories: loss of comfort, loss of discretionary
money, loss of irreplaceable money, and loss of life. Offering criticality affects the
development environment in the way that low criticality necessitates a less formal approach
with low methodology weight, whereas high criticality requires an extensive safety-net with
control mechanisms and high methodology weight.
Project criticality is determined by similar factors, i.e. customer needs and market
characteristics, and has a similar impact on the software development processes as project
complexity. High criticality requires a robust methodology whereas a less critical project is
better off with less expensive, lightweight processes. Project or offering criticality is in essence
a type of risk management – in high-risk operations you pay more to manage the risk with
methodology weight. In general terms, methodology weight can be added to both serial and
concurrent processes.
4.1.2 Product Cooperation & Networking
If the product or the product family of a software company is unique and specialised enough,
the company may not have any necessity of cooperation. Either the synergy effects of
cooperation are non-existent, or the company’s products do not face serious competition and
there is no immediate need for seeking additional business value for the offering from grouping
it together with other products.
More often, however, companies decide to work together. In such partnerships, we generally
find one company functioning as a product integrator, or market front-end, bringing all
components together into one basket. Customers can then be allowed to chose components
according to their wishes, or they may have to buy the entire integrated product. The individual
companies may continue with their own sales activities as well, or they may choose to engage
in a strong strategic alliance and rely on the product integrator for all sales and marketing
activities and focus their own efforts on product development. Either way, obviously there
needs to be an agreement about sharing the revenue stream for the partnership to work.
Figure 13 illustrates the strategic cooperation postures a software company may chose to align
to. The illustration is very much simplified but nevertheless highlights the aspects we wish to
bring forward. Part A illustrates a situation where each company works for themselves without
any cooperation. In part B the companies have formed a loose strategic alliance. They are
selling their offerings as a product family via the product integrator, but are still engaged in
own sales activities as well. In part C the companies have formed a strong strategic alliance
and the companies’ products are only offered via the product integrator.
Company E
Company D
Company C
Company B
Company A
Market Company D
Company C
Company B
ProductIntegrator
Company A
Market Company D
Company C
Company B
ProductIntegrator
Company A
Market
A B C
Company E
Company D
Company C
Company B
Company A
Market Company D
Company C
Company B
ProductIntegrator
Company A
Market Company D
Company C
Company B
ProductIntegrator
Company A
Market
A B C
Figure 13: No product family cooperation (A), loose strategic alliance (B), and strong strategic alliance (C).
As mentioned, the situations described in Figure 13 are much simplified and we can find many
hybrid partnership models as well. Oracle Corp. for example has formed a loose strategic
alliance with several software companies, but has decided to simultaneously compete with each
of them by developing matching components in-house. The other partners rely too much on
Oracle’s product for their sales and consequently can’t afford to brake up the alliance. IBM, on
the other hand, has decided to pursue another strategy in its competition with Oracle. It wants
to form a stronger alliance with its partners, which to a great extent are the same as Oracle’s,
and has made a strategic decision not to compete with its partners. In other words, IBM is
backing a best-of-breed approach in which it stitches together a quilt of business software from
various companies, including itself. Obviously, IBM is winning most of the other companies
on its side, leaving Oracle more and more alone. It is, however, too early to say which strategy
is the more viable one. The comment of Oracle CEO Lawrence J. Ellison on IBM’s strategy
was “You would never buy a car that way”. (see Kersetter & Spencer, 2001)
The success of any of the presented cooperation and networking options is dependent on the
interrelation between internal and external environmental factors. The most profound
characteristics are (1) the relative strength of the discussed company in comparison to the size
of the market and (2) the level of competition. A very strong player may have the ability to
sustain its market position without extensive cooperation in a market with low competition. As
the relative strength of the company decreases and the level of competition increases, it
becomes increasingly difficult to succeed without cooperation. According to the empirical
study by Zahra & Bogner (1999), external technology sources and strategic alliances in product
development have a positive impact on both return on equity and market share under all four
investigated external environment moderators (market dynamism, competition on price,
competition on quality, fragmentation of market), except being insignificant in the case of
growth of market share in situations of quality as the source of competitive advantage.
Software development in a network poses some challenges on the individual players as well as
on the network as a whole. As each player will focus on their own component of the entirety,
co-ordination and orchestration of the interfaces and, even more importantly, the vision of the
future deliverable becomes crucial. In essence, this is a question of communication
management over large distances since it would be almost impossible to have the different
players work close to each other. According to Cockburn (2002), delays and lost-opportunity
costs will rise in correlation with the increase in distance and the degeneration of means of
communication. Extensive documentation will be required in order to distribute information to
all parties as well as store the information for future use. In short, the impact of technology and
product development cooperation on the firm’s internal software development processes is
increased project complexity and thus implicitly increased methodology weight.
4.1.3 Product Compatibility
Software built on different standards do rarely work well together and most often the
underlying technology and product platform is the decisive factor. Obviously customers will
want their software to work seamlessly together and consequently non-compatibility can be a
real deal-killer. What implications does this pose on software companies?
Firstly, companies need to align their product development according to existing technology
standards and platforms such as operating systems. Secondly, companies need to create several
versions of their products if they wish to offer their product to customers using different
standards. Thirdly, companies should co-operate to decrease the number of industry standards
and thus limit the necessity of versioning. To sum it up, the multitude of standards seems to
pose a lot of trouble and extra work for software companies.
But companies may also use incompatibility to leverage the value of their own offering. In
other words, companies may benefit from the fact that other offerings are not compatible with
theirs. For example, large companies can create their own proprietary standards, then package
new software utilising this standard together with a product family which already has large
market penetration, and make customers use their new software. Because the large company
can rapidly distribute its own software to a large number of customers, its proprietary standard
will in fact become a de facto industry standard, and thus kill competition. Microsoft Corp. has
for a long time successfully exercised this kind of a competition killing strategy. Perhaps the
best known example is that of the MS Internet Explorer, which was distributed in conjunction
with other Microsoft products with tremendous market shares, and made it very difficult for
other players to compete. A more recent example is that of MS Windows Media Player 8,
which contains a new music-compression format called WMA. The WMA is positioned to
replace the now popular MP3-format with several technical advantages such as smaller file
size. If Microsoft succeeds, they can add yet another proprietary de facto industry standard into
their portfolio.
The existence of several standards in one market causes either extra expenses or lost sales to
software companies, depending on how compatible they want their offering to be. Several
standards in one market actually effectively splits the market into separate segments with low
cross-border competition because of the compatibility problem. Consequently, in today’s
competitive environment software companies need to address the issue of compatibility in their
product development by e.g. developing modular products, which facilitates versioning and
frequent upgrades. There seems to be a few exceptions to the rule that compatibility is good –
(1) when a player is strong enough to attempt to utilise its market position in adjacent markets
to leverage its position and doing it by introducing a product which lacks compatibility with
competitors’ products but facilitate own compatibility, and (2) when a new technology is
expected to clearly outperform existing competition the holder of the technology may utilise
non-compatibility to leverage its own offerings.
The development of market-compatible offerings requires an external focus, which is bound to
increase methodology weight in terms of communication and management of external relations
and factors. If several compatibility segments are targeted by versioning of the offering,
iterative processes in the development of the external interfaces will remove most of the
duplicate work otherwise experienced with traditional serial development for each version.
4.1.4 Intellectual Property Rights Management
According to Shapiro & Varian (1999), digital technology poses two challenges for rights
management. First, it reduces the cost of making copies, Second, it allows the copies to be
distributed quickly, easily, and cheaply. These challenges offer opportunities in terms of
advertising e.g. by giving away free samples. Obviously it benefits those who sell illicit copies
as well, but their need to advertise caused by growth visions will eventually attract too much
attention and result in them being caught. In the short term however, illicit copying is a
significant problem. In fact, a Business Software Alliance (2000) Delphi survey among its
member companies’ CEOs identified strong copyright protection as the factor that they believe
will have the greatest impact on the future of the software industry. However, according to
Shapiro & Varian (1999), copy protection schemes impose costs on users and are highly
vulnerable to competitive forces, and are thus unlikely to play a significant role in mass-market
information goods.
A recent development against the traditional approach of proprietary software development is
the open source software phenomenon. According to Schrage (2000), the question of open
source vs. proprietary software will have a position similar to such core strategic questions as
make vs. buy, standardised vs. customised and expense vs. investment. Let’s take a closer look
at what implications open source software has on the software industry.
Open source software is software for which both source code and binaries are available for
free. The main benefit of open source software is that a large population of software developers
can be motivated to work for “free” if they can be convinced that the new software will be of
benefit to them. The much larger community of developers has a major impact on both code
writing and debugging, often resulting in better code faster (see Raymond, 1999). However,
once the software is ready to be used commercially, it lacks business value because it can be
acquired for free, e.g. from the Internet. Consequently, business value needs to be created from
other components that utilise the open source technology, but are proprietary. These other
components can be physical, such as hardware, CDs and manuals, or other software. In the
context of this report we will classify a firm as a software company only if the source of
competitive advantage is internally developed software.
In summary, all software companies should strive to reap the benefits of open source software,
but should keep in mind that it cannot be the value driver of their offering. Consequently, in
our opinion, Schrage (2000) was not correct with his comment that open source software
would pose a viable strategic alternative to proprietary software for software companies, since
open source software can never be a source of competitive advantage for them.
The success of intellectual property rights management is greatly affected by external
environmental factors. Furthermore, markets are affected differently depending on the level of
productisation – the intellectual property rights of tailored or customised software are much
easier to manage than those of mass-market products, because of obvious restrictions on the
benefits of illicitly copying tailored software. Players in markets with a high degree of
productisation need to consider three issues. First, the level of illicit activity affects directly the
success of any business model. Second, strict copy protection enforcement poses costs on users
and source code visibility and openness is of strategic importance especially to business
customers (intellectual property rights may be imposed even though source code is available to
customers, although illicit activity is harder to control). Third, according to Shapiro & Varian
(1999) the use of copyrights, patents and other means of protecting the company’s intellectual
capital in dynamic environments appear to speed up the diffusion of knowledge to rivals and
therefore undermine company performance. In summary, copy protection enforcement is bad
to business, but so is illicit activity. Companies need to analyse their target markets and select
the optimal trade-off.
The impact on the internal software development processes of open source software utilisation
is that the specifications of the utilised code cannot be affected by the company (unless it
participates in the open development process or it alters the code before utilising it) and that
the remaining components developed internally need to be constructed around the open source
software. Consequently, the final solution may be far from optimal. The available open source
components should be identified already during the analysis-phase of the project so that they
can be appropriately incorporated to the development plan. Otherwise there is a risk that the
open source code will not fit to the implemented architecture. If open source code is still under
production, it is very risky to rely on it being delivered in a specific time-frame because the
development is often based on voluntary work by some community. In summary, open source
software utilisation offers obvious cost savings but poses challenges on project planning and
management in terms of architectural design compatibility & risk.
Copy protection schemes or illicit activities in the market do not have a major impact on
software development processes because the format the software is distributed in as well as the
way the intellectual rights are managed are separate from the development process.
4.2 Revenue Logic
Rajala et al. (2001) define the revenue logic element as an entirety including both sales
revenues and other sources of financing, and pricing strategy. However, the general
understanding in the field of economics is that financing and operative decisions should be
dealt with separately, not directly affecting each other. The obvious limitation to this is that
without financing, it is not possible to act on the operative level either. Nevertheless, we agree
with the general opinion and do not believe that sources of financing should be included as
elements in the business model. Consequently, we will next discuss sources of revenue and
pricing strategy.
4.2.1 Sources of Revenue
Hietala (2001) divided the sources of revenue for software product and enterprise solutions
business models into six groups. These were (in parenthesis the per cent amount of total
revenues in the software business in Finland in 2000): sales and rentals of user licenses (50%),
customer specific projects and tailoring (23%), customer installations (6%), user training (7%),
maintenance and customer support (11%) and other (3%). In addition to these, Rajala et al.
(2001) identified the loss leader, the media and the magic revenue models.
Licensing is a revenue model that generates cash flow through sales, rentals or subscriptions of
proprietary software products. The terms of payment vary but the essential issue of handing
over the right to use proprietary software in exchange for compensation remains. Profit
sharing is another way of arranging for compensation; once the customer generates revenues
of its own using the traded software, a certain percentage is transferred to the party selling the
proprietary software product.
Customer specific projects, installations, training, maintenance and support create a revenue
stream in comparison to the effort exercised by the service provider, which is called effort-
based compensation. Compensation drivers can be worked hours, number of tasks, or a pre-
arranged amount based on an estimate of either one.
In business models where software is an embedded components of another product or service,
we will have another set of sources of revenue. If the main component of the deal is a physical
object such as hardware, the compensation for the software is included, or embedded, in the
hardware deal. On the other hand, if the main offering of the vendor is a service, e.g. on the
Internet, and the software is handed out for free in order to stimulate the use of these on-line
services, we talk about a loss leader model. Revenue is acquired as a payment for the use of
the services.
In a media model software is used to create a community of users. Third parties are then sold
access to this community, for example in the form of advertising or in the form of behavioural
information and statistics. Revenue is collected in the form of fees from the third parties.
According to Glynn (1999), the magic revenue model involves a large group of different
economic effects, for which the common factor is that the company can appropriate value
created by the good or service in economic exchanges with third parties.
The success of a specific approach on the source of revenue is highly dependent on external
environmental factors. A software good may be valuable to a number of parties in the market.
In such cases it is necessary to analyse their ability and willingness to pay to establish the
most lucrative revenue model. An example when software has value to a number of parties is
an electronic marketplace - primary users such as customers experience value as they can
shop on-line and don’t need to leave their home, secondary users such as suppliers
experience value as they can sell on-line and cut their cost of sales, and tertiary users such as
advertisers experience value as they gain access to an established user community. How
should revenue be generated to the software supplier?
In our opinion it is very difficult if not impossible to make generalised judgements about the
strategies related to selecting the best revenue model. External factors that affect the success of
a specific model and consequently should be analysed prior to selecting a revenue model are:
the market structure in terms of user groups experiencing value from the software, their
proportional strength, interdependency, and ability & willingness to pay. The selection of
revenue model is one of the most fundamental strategic decisions in the software business,
especially in the case of network goods.
We do not believe that the source of revenue does affect the internal software development
processes, i.e. the choice of methodology. The supplier can choose to collect revenues in a
number of ways but the total amount collected should correlate with the value generated to a
customer. The supplier’s task is to maximise this value by selecting the appropriate
methodology, independent of the chosen way of collecting compensation for this delivered
value.
4.2.2 Pricing Strategy
A pricing strategy is fundamentally coupled with the sources of revenue and consequently
these need to be considered together. Cost is often coupled with uniqueness as opposite poles
of competitive advantage. Hitt et al. (1999) identify two main types of pricing strategy: cost
leadership strategy and differentiation strategy. A cost leadership strategy aims to produce
products at the lowest cost, relative to competitors, with features that are acceptable to
customers. A differentiation strategy is designed to produce products that customers perceive
as being different in ways that are important to them. Differentiation does not necessarily have
to be done with something tangible – many software consulting companies use their reputation
to reap a market premium for their services.
The trade-off between cost and uniqueness in terms of competitive advantage does hold for the
software tailoring, or project, industry where software is developed from scratch according to
the specifications of the customer. However, once the same good can be sold to a number of
customers, the special characteristics of the software industry change the rules. As the software
development costs can be considered sunk, economies-of-scale become increasingly important
as it allows the supplier to spread the development costs on a larger number of customers.
Different potential customers have different valuations of your software product, and
consequently have different willingness to pay. In order to maximise your profit you should
find a way to sell your product at different prices to the different customers. Shapiro & Varian
(1999) have identified a number of pricing strategies that allow you to do this: versioning of
information, bundling of information, non-linear pricing and promotional pricing. The core
idea behind these strategies is to create a number of products in stead of just one and emphasise
differences so that customers may select an offering and price most suitable to them.
Pricing strategy should also reflect the general strategy of the company in the competitive
environment. Sometimes short term benefits may turn out to have a negative impact on the
future. For example, high prices in the early stages may hinder the creation of a critical mass of
customers, as well as attract competitors. Pricing strategy is affected by external environmental
factors. The degree of productistation expected by the market has a fundamental impact as
described above. Furthermore, the competitiveness and the size of the market pose constraints
on the amount of potential customers.
In a market with a low degree of productisation, pricing strategy does have an impact on the
internal software development process while there are differences in cost and time-to-market
characteristics of different software development methodologies. If we look back at Figure 4,
which illustrates the difference between successful serial and concurrent development in terms
of time-to-market, we realise that a concurrent methodology is more suitable for a
differentiation strategy, whereas serial development is more appropriate for a cost leadership
strategy, as long as uncertainty of customer requirements does not make it inapplicable.
When producing mass-market software products and offering them in different versions to the
potential customers, iterative software development may prove most cost-efficient for the
components subject to versioning.
4.3 Marketing & Sales Model
According to Rajala et al. (2001), the marketing and sales element reflects the decisions of
marketing strategy and distribution strategy including distribution channels. Kotler (2000)
defines marketing strategy as a “game plan” to accomplish the objectives of the marketing
plan, i.e. manoeuvring under the restrictions of market conditions. This definition includes
everything from advertising, customer relations and competitive intelligence to matching
demand and supply. In essence, marketing is the company’s way of communicating with the
outside world. This topic seems by far too much of a challenge to be covered in this paper. We
will confine with concluding that a marketing strategy should reflect the nature of the offering,
with direct and more personal customer relations models for services and more efficient and
impersonal models for packaged products.
Elements of the distribution strategy are e.g. sales channels and logistics. The demands set by
logistics obviously depend on the type of offering at hand. Packaged software can be
distributed as physical products, whereas services generally need at least some degree of
human interaction and on-site operations. Both types of offerings can also be delivered
electronically, and with the development of security on the Internet more and more transactions
are expected to be totally electronic.
Rajala et al. (2001) identified one direct and six indirect types of sales channels, in addition to
strategic partners. McHugh (1999) points out that direct selling is especially important in early
stages in company development to secure first customers, but that it generally remains
dominant later on as well. Indirect sales models are used to provide greater selling coverage
and implementation muscle.
The indirect sales channels are: agent, dealer, distributor, re-publisher , reseller, and retail
outlet. Agents, dealers and retail outlets do in essence the same thing: sell the product to the
final customer. Distributors sell large volumes of products through a network of dealers. Re-
publishers label the product as their own and sell it as a part of their product portfolio.
Resellers sell the product to the final customer and package it with related software products or
services.
Strategic partners provide products or services that complement each other. Essential is that
the value of the combined offering exceeds the combined value of the individual offerings.
Strategic partners provide an excellent sales channel, especially if the offerings of the two
companies are closely tied together and consequently their sales are tied to each other. A
strategic partnership network can consist of, besides the customer, software product
developers, consultants, system integrators, service providers and outsourcers. Strategic
partners will be discussed further in association with the servicing and implementation model
below.
The external success factors of the sales & marketing model are the availability and quality of
indirect sales channels, the level of market fragmentation and difficulty of reaching potential
customers, and the level of competition (increased competition necessitates increased
marketing efforts). When selecting the appropriate software development methodology, the
applied sales model needs to be considered. As most agile methodologies rely on a customer
providing constant feedback and information, an indirect sales model does seem like an odd
match. Nevertheless, it is possible to define a “customer” within the own organisation who
would represent the sales & marketing front-end with most customer contact, but results are
dependent on how reliable the flow of information really is. If requirements are well defined
and customer contact is scarce, a viable alternative would be to use the more cost-effective
serial development approach. Nowadays more and more companies tend to turn away from this
approach, however, and instead establish themselves a network of partners or virtual customers
to test the product under development. Then an iterative approach is used together with
feedback from this test-user community.
In the case of a direct marketing & sales model, the availability of customer cooperation should
definitely be explored. In the case of a consulting type of business where software is tailored
according to customer specifications, projects should be set up in a way that involves constant
communication between the supplier and the customer. In the software product business a new
version should be released to a test group after each iteration cycle in order to collect feedback
on the new features.
4.4 Servicing & Implementation Model
The servicing and implementation model includes all offerings related to the company’s core
product or service. They can either be provided by the company itself or a network of strategic
partners.
In the software business, as in many other businesses, customers are becoming more and more
demanding and often require a set of integrated offerings instead of a single one. This has been
especially evident in the B2B segments. At the same time, however, the customers don’t really
know what they want and that therefore they must often be led and educated to raise their
expectations. Consequently companies able to provide a total customer experience rather than
providing just bits and pieces will have a competitive edge. Recognizing that value can be
created only in the customer’s space, the customer focused mindset understands and articulates
activities in the “customer activity cycle” presented in Figure 14; “pre” the experience when
the customer is deciding what to do, “during” the experience when the customer is doing it,
and “post” the experience when the customer is keeping it going, updating and reviewing. The
“value adds”, or activities, performed by the vendor, or in this case the network of strategic
partners, are: consulting (strategic, feasibility and IT advice), systems and software integration,
sourcing assistance, installation, training, support, maintenance, and new offering
development.
”PRE”’deciding what to do’
”DURING”’doing it’
”POST”’keeping it going’
CustomerActivityCycle
CONSULTING
FEASIBILITY AND IT ADVICE
SYSTEMS & SOFTWARE
INTEGRATION
SOURCING BUYING DISTRIBUTING CONNECTING
PILOTING INSTALLING
TRAINING & ON-LINE HELP
DIAGNOSING REPARING
PLANNED PREVENTATIVE MAINTENANCE
REVIEWPLAN NEEDS & SYSTEMS
take strategic decision
understand IT options
develop systems integration
purchase
install & set up
train
repair
maintain
review
update
= customer activity
= VENDOR / PARTNER ACTIVITY
Figure 14: Customer activity cycle presenting customer “value gaps” and vendor “value adds” at specific
points in their relationship (redrawn from Vandermerve, 2000).
Rather than chasing margins of single products, services or countries, companies should be
interested in leveraging high-quality cash flow from the long-term value of the customer by
getting longevity, depth, breadth, and diversity of spend (see Vandermerve, 2000 for
definitions). Long customer relationships may not be up-front as lucrative as anonymous trades
but as the relationship matures and trade becomes frequent, eventually the investment in the
relationship will pay off many fold. The network of partners will play an important role in the
fulfilment of the complete customer experience, as most companies will try to focus their
scarce resources on their core competence.
The customer activity cycle is best adaptable in B2B markets, where the customers of obvious
reasons require service rather than a single-transfer product. The customer activity cycle can
also be applied in certain consumer segments were the offering is technologically complex and
its monetary value is significant.
The success of the service & implementation model is highly affected by internal as well as
external factors. The external factors are the market requirements for additional services (i.e.
market & customer type – B2B customers are expected to require service and are willing to
pay for it, whereas individual consumers are generally less willing to do so), and the
availability and quality of strategic partnerships. Furthermore, the level of competition and size
of the market as well as adjacent (service) markets has a profound impact since large and/or
highly competitive markets restrict the potential share-of-wallet of a single supplier.
The impact of the level of required service is very profound, even to the degree that it may
cause involuntary alterations to the intended business model. A very product-oriented software
company may find itself in a position that it cannot sell its products without guaranteeing
additional services. Consequently the company is “involuntarily” drawn into the servicing and
consulting business against its wishes if it cannot find strategic partners to take over. Even
though servicing can be charged from the customer, it requires resources that could have been
allocated elsewhere. In a resource scarce environment this can be problematic. The impact on
the internal software development process is such that if servicing, maintenance and change
request processing are provided, a very agile approach is required since it is often very difficult
to pre-determine the requirements and associated tasks. The core business should be
streamlined to facilitate service provisioning which should be portrayed e.g. in the architecture
of the software. When very little or no services are required and provided, the company may
concentrate on its core business.
4.5 Summary of Business Model Elements & Process Impacts
In this section we will present the results of the previous discussion of software business model
elements that affect the internal software development processes.
Table 3: Business model element impacts on the internal development environment.
BM Element External Factors Internal Process Impact Product development model
Value proposition type
Object of trade Market size & heterogeneity, customer willingness to pay for personal services, customer perceived value driver
No direct impact. Indirect impact via degree of productisation.
Degree of productisation
Market size & heterogeneity, customer willingness to pay for personal services & compromise on specifications, availability of customer cooperation
A low degree of productisation requires customer cooperation & evaluation test releases. A high degree requires customer intelligence for specifications to meet the needs of a large amount of customers.
Novelty & radicality
Market dynamism & level of competition
Dynamic markets require agile processes. Price-sensitive markets require cost-efficient processes. Dynamic & price-sensitive markets require agile processes in order to meet requirements.
Complexity Customer needs & market characteristics
Complex offerings require high methodology weight, i.e. more management efforts, control mechanisms and pre-defined processes. Simple offerings require very little methodology weight.
Criticality Customer needs & market characteristics
Critical offerings require high methodology weight, i.e. more management efforts, control mechanisms and pre-defined processes. Not critical offerings require very little methodology weight. Methodology weight functions as a risk management tool.
Product cooperation & networking
Relative strength (financial & technological) to market, market dynamism, level of competition & fragmentation
Strong players may focus on their own processes and force others to align. Cooperation accelerates total development and spreads risk, but increases methodology weight because of necessity for external communication. Delays and lost-opportunity costs increase.
Product compatibility
Benefits & availability of compatibility with complementaries, amount and strength of market standards, relative performance of technology to market, firm’s relative strength in complementing markets
Compatibility efforts increase methodology weight in terms of communication and management of external factors. Versioning requires an iterative or agile approach for the interfaces. Non-compatibility strategy allows firm to focus on internal issues.
IPR management Copy protection schemes
Level of illicit activity, customer experienced cost of copy protection enforcement & risk associated with hidden source code, market dynamism
-
Open source software utilisation
Availability & quality of open source software
Early analysis and incorporation to (architectural & project) plan required. Risk of delivery delay if open source software is still under development.
Revenue logic Sources of revenue
Market structure in terms of customer groups experiencing value from the software, their relative strengths, interdependencies, and abilities & willingness to pay
-
Pricing strategy Market size & level of competition pose constraints on the amount of potential customers, degree of productisation affects the available set of pricing strategies, market segmentation & customer willingness to pay affects versioning possibilities
In a market with low degree of productisation concurrent development brings time-to-market advantage and serial development cost-advantage. In mass-markets the use of agile and iterative processes is useful for versioning of software.
Marketing & sales model
Degree of productisation, availability and quality of indirect sales channels, level of market fragmentation and difficulty of reaching potential customers, and level of competition affect the choice of direct vs. indirect model
A direct model facilitates and often necessitates intense customer cooperation. An indirect model poses challenges on identifying “real” customer requirements. If no customer cooperation is available, either an internal “customer” is appointed or agile approaches need to be discarded.
Servicing & implementation model
Market requirements & willingness to pay for additional services, availability and quality of strategic partners, level of competition and size of market as well as adjacent (service) markets
A high level of servicing requires that ease-of-maintenance is incorporated in software development. This is best achieved by modular design and agile methodology. A low level of servicing allows company to focus on core business.
5 Agile Methodology Applicability
In this chapter we will evaluate the applicability of agile methodologies to different software
business models and external environments. As specified in the scope of this report, we will
discuss only Extreme Programming (XP) and SCRUM as representatives of agile
methodologies. The evaluation will be a continued discussion of the results of the analysis
presented in the previous chapter. The discussion is presented in Table 4 below.
Table 4: The applicability of agile methodologies in software development as determined by a company’s
business model and external factors.
BM Element External Factors Agile Methodology Applicability Product development model
Value proposition type
Object of trade Market size & heterogeneity, customer willingness to pay for personal services, customer perceived value driver
-
Degree of productisation
Market size & heterogeneity, customer willingness to pay for personal services & compromise on specifications, availability of customer cooperation
Agile methodologies are very suitable when degree of productisation is low but is also applicable for products with a high degree of productisation if virtual customers and test users can be acquired.
Novelty & radicality
Market dynamism & level of competition
Dynamic markets require agile methodologies. Price-sensitive markets require cost-efficient methodologies, which are not necessarily agile. Dynamic & price-sensitive markets require agile processes in order to meet requirements.
Complexity Customer needs & market characteristics
XP alone is not very suitable to complex problems but SCRUM provides some assistance. Some agile practices may still have to be discarded. Agile methodologies are very suitable to small problems.
Criticality Customer needs & market characteristics
Critical projects require more methodology weight and robust practices. Some agile practices may have to be discarded but XP in general is quite suitable because of its extensive testing practices. Agile methodologies are suitable for non-critical projects.
Product cooperation & networking
Relative strength (financial & technological) to market, market dynamism, level of competition & fragmentation
Agile methodologies are suitable to a cooperative environment as software is developed in components anyway.
Product compatibility
Benefits & availability of compatibility with complementaries, amount and strength of market standards, relative performance of technology to market, firm’s relative strength in complementing markets
Versioning requires an iterative or agile approach for the engineering of compatibility in the interfaces.
IPR management Copy protection schemes
Level of illicit activity, customer experienced cost of copy protection enforcement & risk associated with hidden source code, market dynamism
-
Open source software utilisation
Availability & quality of open source software
Agile methodologies in principle applicable but analysis and planning needs to be done early.
Revenue logic Sources of revenue
Market structure in terms of customer groups experiencing value from the software, their relative strengths, interdependencies, and abilities & willingness to pay
-
Pricing strategy Market size & level of competition pose constraints on the amount of potential customers, degree of productisation affects the available set of pricing strategies, market segmentation & customer willingness to pay affects versioning possibilities
In a market with low degree of productisation agile methodologies are most suitable when time-to-market is the source of competitive advantage but may cost more than serial development and be of disadvantage in price-sensitive markets. In mass-markets the use of agile methodologies is useful for versioning of software.
Marketing & sales model
Degree of productisation, availability and quality of indirect sales channels, level of market fragmentation and difficulty of reaching potential customers, and level of competition affect the choice of direct vs. indirect model
Agile methodology especially suitable when using a direct model. In the case of an indirect model, a customer and test users need to be specified or else agile methodologies are not useful.
Servicing & implementation model
Market requirements & willingness to pay for additional services, availability and quality of strategic partners, level of competition and size of market as well as adjacent (service) markets
A high level of servicing and ease-of-maintenance is best achieved by modular design and agile methodologies.
6 Conclusions, Recommendations & Future Research
This paper presented an evaluation of agile software development applicability to software
development processes determined by a venture’s business model and external business
environment. The findings of the report state that agile methodologies are indeed applicable in
most software development projects. However, the following restricting factors to the
applicability were identified:
- Lack of customer involvement
- High complexity of development project
- Price-sensitivity of market
As discussed in the paper, none of these factors do totally exclude the use of agile
methodologies, but the restrictions posed by them should be kept in mind when selecting a
methodology.
Future research in the field of the applicability of agile methodologies should focus on either
company internal factors as determinants of applicability or on collecting empirical data as
evidence of the success of agile methodologies.
Finally I would like to bring forward seven principles that are useful in designing and
evaluating methodologies and were identified by Cockburn (2002):
1. Interactive, face-to-face communication is the cheapest and fastest channel for
exchanging information.
2. Excess methodology weight is costly.
3. Larger teams need heavier methodologies.
4. Greater ceremony is appropriate for projects with greater criticality.
5. Increasing feedback and communication lowers the need for intermediate deliverables.
6. Discipline, skills, and understanding counter process, formality, and documentation.
7. Efficiency is expendable in non-bottleneck activities.
7 References
Beck K. 1999. Embracing Change with Extreme Programming. IEEE Computer Society, Los
Alamitos, CA, USA.
Beck K., Beedle M., van Bennekum A., Cockburn A., Cunningham W., Fowler M., Grenning
J., Highsmith J., Hunt A., Jeffries R., Kern J., Marick B., Martin R. C., Mellor S., Schwaber
K., Sutherland J., Thomas D. 2001. Manifesto for Agile Software Development, Agile Alliance.
URL: http://www.agilemanifesto.org/. Accessed 7.3.2002.
Beck K. 1999. Embracing Change with Extreme Programming, Computer, Oct. 1999, pp. 70 –
77.
Boehm B. 1988. A Spiral Model of Software Development and Enhancement. Computer, May
1988, pp 61 – 72.
Bygrave W. 2000. Calling on family and friends for start-up cash. Financial Times Newspaper.
Cockburn A. 2002. Agile Software Development, Pearson Education Inc., MA, USA.
Cockburn A., Highsmith J. 2001a. Agile Software Development: The Business of Innovation,
Computer, Sept. 2001, pp. 120 – 122.
Cockburn A., Highsmith J. 2001b. Agile Software Development: The People Factor,
Computer, Nov. 2001, pp. 131 – 133.
Cravens D. 1987. Strategic Marketing. Richard D Irwin Inc., Homewood, Illinois, USA.
Economist 2001. Agility Counts, 22.9.2001, pp. 11.
Eloranta E. 2002. Orchestrating Business Systems. E-business lecture, Helsinki University of
Technology, 21.3.2002.
Fowler M. 2000. The New Methodology, URL:
http://www.martinfowler.com/articles/newMethodology.html. Accessed 15.3.2002.
Goldman S. L., Nagel R. N., Preiss K. 1995. Agile Competitors and Virtual Organisations,
Van Nostrand Reinhold, NY, USA.
Hietala J. 2001. Finnish Software Product Business: Results from the National Software
Industry Survey 2001. Helsinki University of Technology.
Hitt M., Ireland R., Hoskisson R. 1999. Strategic Management: Competitiveness and
Globalization (3rd ed.). South-Western College Publishing, Cincinnati, Ohio.
Kersetter J., Spencer A. 2001. IBM vs. Oracle: It Could Get Bloody. Business Week,
28.5.2001.
Kotler P. 2000. Marketing management (10th ed.). Prentice Hall International Ltd., London, UK.
MacCormack A., Verganti R., Iansiti M. 2001. Developing Products on “Internet Time”: The
Anatomy of a Flexible Development Process. Journal of Management Science 47(1), 133 –
150.
Maier M., Rechtin E. 2000. The Art of Systems Architecting, 2nd Edition, CRC Press, Boca
Raton, FL, USA.
McHugh P. 1999. Making it Big in Software – a guide to success for software vendors with
growth ambitions. Rubic Publishing, Tiverton, Devon, NW.
Nukari J., Forsell M. 1999. Suomen ohjelmistoteollisuuden kasvun strategia ja haasteet.
Technology Review 67/99. TEKES, Finland.
Rajala R., Rossi M., Tuunainen V., Korri S. 2001. Software Business Models – A Framework
for Analyzing Software Industry. Technology Review 108/2001. TEKES, Finland.
Rautiainen K., Lassenius C., Vähäniitty J., Pyhäjärvi M., Vanhanen J. 2002a. A Tentative
Framework for Managing Software Product Development in Small Companies. Software
Business and Engineering Institute, Helsinki University of Technology.
Rautiainen K., Lassenius C., Sulonen R. 2002b. 4CC: Balancing Flexibility and Control: A
Framework for Product Development Management in Small Software Companies. Software
Business and Engineering Institute, Helsinki University of Technology.
Schrage M. 2000. Open for Business. Strategy+Business, Issue 21, pp 101 – 105.
Schwaber K. 1996. SCRUM Development Process. American Programmer, June 1996.
SoberIT 2002. The business model as an intermediary between the external environment and
the internal processes of a company. “Avoimet Ovet” public relations fare, SoberIT, Helsinki
University of Technology, 22.3.2002.
Sutherland J. 2002. SCRUM Hyperproductive Software Development Method, 1995 – 2002,
URL: http://jeffsutherland.com/scrum/index.html. Accessed 15.3.2002.
Whittingham J., Durlacher Research. Starting out – some guidance notes on new technology
based business ideas and business plans. Published 7/2000. URL: http://www.durlacher.com/fr-
research.htm . Accessed on 15.1.2002.
Zahra S., Bogner W. 1999. Technology Strategy and Software Ventures’ Performance:
Exploring the Moderating Effect of the Competitive Environment. Journal of Business
Venturing 15, 135 –173.
