Selecting A Development Approach For Competitive Advantage

Selecting a Development Approach for Competitive Advantage 1

Running head: Selecting a Development Approach for Competitive Advantage

Selecting a Development Approach for Competitive Advantage

Matthew L. Todd

Bellevue University

CIS620-T301

Professor Cass


Abstract

Companies that rely on their information systems to provide a competitive advantage must

employ development methodologies that: facilitate innovation, improve customer and supplier

relationships, and enable change at the speed of business. Potential development approaches

include traditional, object-oriented, and vision and value oriented methodologies. The

recommended approach is a hybrid methodology that incorporates agility, adaptability, reuse,

collaborative thinking, and evolving innovation. At the foundation of this approach are agile

development philosophies and practices, and the system designer. From an architectural

perspective, the approach utilizes SOAs and SOMA methods. And, design thinking and

innovation evolution cycle principles are incorporated to drive system innovations.


Selecting a Development Approach for Competitive Advantage

Organizations that utilize an in-house development approach do so because their systems

provide them a competitive advantage. Some custom applications are developed and maintained

for internal use, or for use as an inter-organizational application. Other custom applications are

developed and evolved for resale to the organization’s customers. Companies that rely on their

information systems to provide a competitive advantage must employ the best development

methodologies to facilitate the innovative change needed to differentiate themselves from their

competition, and to improve customer and supplier relationships. And, they must be able to

adapt their systems at the speed of business to respond to changes dictated by their competitors,

customers, suppliers, and other external forces (Laudon & Laudon, 2007, p. 96-103).

The first section of this paper describes various systems development methodology

alternatives that can be employed to build custom applications. The second section of this paper

defines the recommended approach, toward resolving the aforementioned problem.

Alternatives

There are many systems development methodologies that have been used over the years to

analyze, define, design, build, test, implement, and maintain custom computer applications.

These approaches include (Jacobsen, Booch, & Rumbaugh, 1999, p. 4-5; Sliger, 2006; Turban &

Volonino, 2009, p. W281-W282; Woodward, 2009, p. 3-6):

- traditional development methodologies, like the waterfall development methodology,

that employ a plan driven approach, where the desired feature set is defined at the

beginning of a project, and cost and schedule are manipulated to adhere to the pre-

defined requirements


- object oriented approaches, like the Rational Unified Process, which offer an extensive

modeling language and development framework that combines a plan driven phased

approach with iterative refinements

- vision and value driven approaches that stress agility, adaptability, reuse, collaborative

thinking, and evolving innovations; with these approaches timeframe and resources are

usually fixed, and the feature set is adapted based on the value each feature adds to the

overall vision

Waterfall Development Approach

The first systems development methodology under consideration is the waterfall

development approach. According to Gartner, the waterfall approach is used 56% of the time

when a formal development approach is required (Prentice, 2009, p. 2). The waterfall approach

is a sequential approach where each project phase is completed prior to initiating the next phase:

analysis and requirements definition is completed and approved, then a solution is designed and

approved, then the solution is constructed and tested, and finally the solution is implemented

after user acceptance is obtained (Whitten & Bentley, 2007, p. 89-92). The strengths of the

waterfall approach are: it offers a more strict framework which provides support for less

experienced project staff, it enables up front budgeting for the entire project, and it encompasses

well defined milestones for measuring progress against a baseline plan. The weaknesses of the

waterfall approach are: it is inflexible and slow, it depends on early identification of all

requirements, problems might not be identified until late in the project life cycle, it promotes the

chasm between end users and systems developers, and it doesn’t respond well to unknown and

changing requirements (CMS, 2005, p. 2; Woodward, 2009, p. 3).


Rational Unified Process

The second methodology alternative is the Rational Unified Process (RUP). RUP was first

released in 1998. It evolved from the Ericsson Approach which was used to model systems in

the 1960s using a set of interconnected diagrams. The Ericsson Approach was the foundation for

the Rational Objectory Process, which eventually evolved into RUP. RUP uses a set of models,

and constructs, called the Unified Modeling Language (UML) as the foundation for defining and

designing systems and data structures. The RUP approach is driven by user wants and needs,

which are modeled via use cases to define a system’s functionality. It is architecture centric,

meaning a high level architecture, providing the system’s form, is produced or enhanced as early

as possible before proceeding into detail design and construction. RUP is iterative and

incremental, where iterations represent steps in the overall process, and increments represent

product growth. The approach has distinct phases: Inception, Elaboration, Construction, and

Transition. And within each phase there may be one or more iterations that proceed through

requirements, analysis, design, implementation, and testing (Jacobsen, Booch, & Rumbaugh,

1999, p. xx-xxvi, 3-13). The strengths of RUP are in its applicability to large system

development projects where iterative refinements and incremental delivery are required. It has

many of the plan related advantages of a waterfall development approach, without the

shortcomings of a purely linear approach (Woodward, 2009, p. 4). The robust incremental

nature of RUP, however, can be a disadvantage when trying to employ an efficient streamlined

approach for projects of short duration where architectural and integration risks are low (CMS,

2005, p. 6). Designing an application using object-oriented techniques and UML can entail the

development of many different models, including: class diagrams, collaboration diagrams,

sequence diagrams, state diagrams, and various architecture and interface diagrams. And this is


prior to writing a single line of code. According to Meiler Page-Jones (2000, p. 71-72), object

orientation is both an organizational and technical transition. Jones says that it’s important to use

UML and object orientation as a means to reach your goal, not as an end in itself. “If you don’t

keep your goal in mind, then object orientation with all its transitional costs (financial,

organizational, social, and emotional) will seem like an expensive boondoggle.”

Agile Development Philosophy

The third systems development alternative, agile, is more of a development philosophy

than it is a development methodology, although there are distinct agile based methodologies

including Scrum, Extreme Programming, and feature driven development (Keston, 2009b, p. 2).

The core principles underlying the agile philosophy are (Cockburn, 2002, p. 148, 216):

- a focus on individuals and their face to face interactions, because this is the fastest and

least expensive method for exchanging knowledge and information

- the delivery of working software as the primary goal and only meaningful deliverable

- collaboration between developers and customers throughout the project, which reduces

the need for intermediate deliverables and the formalities associated with “heavy”

methodologies

- adaptation to any change that brings value to the project, system, or business

In addition, the agile approach depends on the use of small self-managed teams, pragmatic

development choices, code refactoring, and frequent testing. Code refactoring leads to simpler

software, and frequent testing leads to reduced risk (Keston, 2009a, p. 2-4). Smaller teams

require less methodology and formality, which helps to reduce cost and improve overall

efficiency (Cockburn, 2002, p. 149). Agile views software development as an exercise in

communication, understanding, and invention, where the ampleness of the delivered solution is


the ultimate goal and achievement. Agile presumes that the best systems are built by individuals

in collaboration with other individuals, and that making mistakes and failure are a natural part of

the human condition and software development process. For those reasons agile depends on an

incremental, iterative, time-boxed approach to deliver value to the business (Cockburn, 2002, p.

28, 34, 48-49).

An agile approach requires developers with a broader overall skill set, strong business

acumen, and the ability to adapt to an informal approach and changing circumstances. Agile is

best suited for innovative initiatives where requirements are unknown and likely to change

(Keston, 2009a, p. 4-5).

Organizations that are able to adapt to the agile philosophy and approaches experience

significant increases in productivity, and substantial development cost reductions. A 2008 study

conducted by QSM Associates concluded that organizations using agile approaches are 16

percent more productive, and able to get products to market 37 percent faster, than organizations

that use traditional development approaches (QSM, 2009, p. 1). A second study, conducted by

Forrester Research in 2004, concluded that the use of ThoughtWork, Incorporated’s agile

development approach and tools provides organization’s a three year ROI of between 23 and 66

percent, with a 13 to 15 month payback period (Forrester, 2004, p. 4, 6).

Service-Oriented Modeling and Architecture

The fourth application development approach alternative is service-oriented modeling and

architecture (SOMA). This approach considers software functionality as a service that is made

available by a provider, through an easy to use interface, to a service consumer. Knowledge

about available services and service operations is made available to service consumers through

published service descriptions. Service descriptions are searchable and they provide all the


information needed by a consumer to connect to and use the operations of any available service.

Services can be developed to expose functionality provided by all types of applications: Web-

based applications, client-server applications, and mainframe applications. Service-oriented

architectures (SOA) provide many advantages for both information technology (IT) and business

professionals. For IT, SOAs create a framework of loosely coupled, functionally cohesive

components that can be easily used in new combinations to deliver new functionality to the

business. For business stakeholders, SOAs provide a technology that allows the business to

respond effectively and efficiently to changing demands (Arsanjani et al., 2008, p. 377-379).

The IBM SOMA methodology is comprised of seven phases: Business modeling and

transformation, solution management, identification, specification, realization, implementation,

and deployment, monitoring and management. SOMA phases are not linear. SOMA is an

iterative and incremental approach where the breadth and depth of method usage depends on the

objectives, scope, and risks of a project. SOMA can be used to develop everything from flexible,

easy to maintain enterprise architectures, to robust business applications, to integrating software

components (Arsanjani et al., 2008, p. 381-383, 395).

SOAs can provide substantial cost savings in the development of software. The level of

component reuse with SOAs is 2.5 times greater than with other software development

approaches. And, although the cost associated with building services is 20% higher than the cost

associated with building non-reusable software, the savings associated with service reuse pays

for the increased development cost after 1.3 uses. Every reuse after the breakeven point

produces a 90% cost savings when compared to traditional software development approaches

(Poulin & Himler, 2006, p. 2-3).


Design Thinking and the Innovation Evolution Cycle

The final two alternatives are design approaches that depend on observation and the

experience gained through application usage as the driving forces for innovation. The first

approach, design thinking, originates product innovations by gaining an understanding of what

people need and want in a product through direct observation by multi-disciplinary teams

(Brown, 2008, p. 86). The second approach, the Innovation Evolution Cycle, depends on

designers and users working collaboratively to evolve information systems that meet the ever

changing needs of the operational environment (Davern & Wilkin, 2008, p. 133).

Design thinking follows an iterative and incremental approach for product design. Design

teams are comprised of multiple skill sets, and areas of expertise, with the designer(s) at the

center of the process. A design thinking project begins with the inspiration phase, where

observation and group brainstorming are used to determine what problem or opportunity the

project will focus on solving. From inspiration a project proceeds to ideation, where the multi-

disciplinary team uses brainstorming and prototyping to generate ideas and observable models of

possible solutions. A project then iterates between inspiration and ideation until a desired

solution is reached. Once a desired solution is reached the project proceeds to the

implementation phase, where the prototyped solution is transformed into a finished product

(Brown, 2008, p. 87-90).

IDEO, a product design consulting company, and its predecessors, David Kelley Design

and ID Two, have used the design thinking approach, over the last 30 years, to develop

numerous innovative products and processes including: Apple’s first mouse, the first laptop

computer, the Palm V PDA, and the Oral-B toothbrush (Brown & Wyatt, 2010, p. 33). Design

thinking is a light and flexible approach that, much like agile methods, depends on the skills and


expertise of the project team to determine what path the project needs to follow to deliver the

desired solution. The approach depends on designer involvement throughout the project: from

inspiration to implementation. And it relies on heavy user involvement, from a multi-

disciplinary team, and an experimentation mentality from all project team members (Brown,

2008, p. 87, 90).

The final approach under consideration, the Innovation Evolution Cycle, is similar to

design thinking in that it uses observation, and collaboration, as the driving forces toward

product growth. It puts the designer in the role of observing and understanding how users

interpret and use systems to get their work accomplished. Gaining an understanding of real

world use is the first step toward the innovative evolution of a system. The second step involves

cooperative interaction between designers and users to encourage innovative solutions to solve

system inadequacies. If employed effectively this approach should lead to a continuous cycle of

innovative system improvements. The ideal cycle begins with conformant use of an application,

followed by user led innovation to meet changing job needs, followed by the incorporation of

innovations into the system. Then the cycle begins again, and repeats continuously over the life

of the system (Davern & Wilkin, 2008, p. 133, 135).

Recommendations

The recommended development approach, for developing applications that provide a

competitive advantage to an organization, is a hybrid approach which incorporates agility,

adaptability, reuse, collaborative thinking, and evolving system innovations. This hybrid

approach should, at its foundation, be based on the agile development philosophy and practices.

An agile approach works well in environments where software must be adapted quickly to meet

the changing needs of the business (Schwalbe, 2010, p. 60-61). In addition, an agile approach


adheres to the Standish Group’s Chaos Report “Bridge to Success” recommendations: deliver

software early and often, follow an iterative software growth approach, and keep projects as

small and as simple as possible (Standish, 1995, p. 8).

From an architectural perspective, the hybrid approach should utilize SOAs and SOMA

methods. SOMA “SOA business modeling, transformation, and solution management” should

be used to ensure alignment with the business and evolving SOA architectures. And SOMA

“SOA implementation, deployment, monitoring, and management” techniques should be used to

drive the reuse and production implementation of services. Finally, design thinking and

Innovation Evolution Cycle principles should be incorporated to help drive system innovations.

Design thinking should be used to drive application visioning and significant product growth.

And, the Innovation Evolution Cycle should be incorporated to facilitate continuous innovations

toward conformant application use.

The agile hybrid development approach should be rolled out following a staged

implementation approach, starting with a single team, and a single pilot project (Rally, 2009, p.

1). Throughout the staged rollout it is imperative that the Chief Information Officer (CIO) play

the role of chief advocate and change leader. It will take time for this approach to begin reaping

the benefits that full agile practices and SOA architectures promise over time. There will be


resistance by some in the organization, and a steep learning curve to overcome for others. The

business will have to adapt to full time user involvement on projects, and IT staff will have to

develop a wider range of skills (Barretta, 2009).

During the pilot project the organization should use a community or freeware version of

agile methods and tools. And consulting expertise should be used to help integrate the various

aspects of the hybrid approach. The first project should be viewed as, primarily, a learning

exercise. The scope of the pilot should be a small, non mission critical application, or

application sub-system. The goals of the pilot are to master the collaborative, iterative approach,

and to prove that the approach is a good fit to the organization. The team should be made up of

IT staff and business experts who are enthusiastic about the adaptive, integrated, and innovative

nature of agile and design thinking. The IT team members should have the requisite

development skills necessary to design, build, and test the software. And, all team members

should exude the design thinker characteristics: empathy, integrative thinking, optimism,

experimentalism, and collaboration (Brown, 2008, p. 87; Keston, 2009a, p. 6; Rally, 2009, p. 1).

The second stage of the rollout involves multiple teams using the agile hybrid approach on

selected projects. This will require upgrading from a freeware or community version of agile

methods and tools to an integrated toolkit that will support multiple teams. The goals of the

second stage are to master multiple projects running at the same time, release management, and

to prove that the new approach can deliver value to the organization. Once the organization has

accepted the new approach, and adapted to the intricacies of agile development, it is time to

begin using the approach throughout the organization (Rally, p. 2). Team members, from

completed projects, should be disbursed to the new teams to help facilitate the transfer of

knowledge, and lessons learned.


One of the critical success factors to the expansion of the agile hybrid approach is the

identification of the designers/ developers that can facilitate the success of each project.

According to Dr. Fred Brooks, hiring and nurturing great designers is the most significant step an

organization can take to improve their software design and construction (Brooks, 1995, p. 202).

This depends on the realization that the designer/ developer should be involved, as the center

figure, on every development effort. This is especially important in agile based development

where documentation is minimal and continuous collaboration and communication, throughout

the life of a project, is critical to its success (Cockburn, 2002, p. 216-218). The ideal iteration is

like a surgical operation, with a small team supporting the lead designer/ developer, much like a

surgical team supports a chief surgeon (Brooks, 1995, p. 32). This encourages an integrated

thinking approach that is critical to agile development, and is the most effective and efficient

mode of operation for humans (Drucker, 1954, p. 293).

Costs-Benefit Analysis

The costs directly related to the implementation of the agile hybrid approach are consulting

costs, training and education costs, the costs associated with the acquisition of agile methods and

tools, and the costs associated with any hardware required to run the agile tools. The estimated

benefits associated with the agile hybrid approach, when compared to traditional approaches,

include: development team productivity improvements of between 16 and 25 percent, the ability

to get products to market 37 percent faster, 2.5 times more software reuse, and an improved

ability to envision, design, and delivery innovative software products (Brown, 2008, p. 92;

Poulin & Himler, 2006, p. 3; QSM, 2009, p. 1).

Using a cost benefit model (see table 1) that is based on the findings from the QSM

associates’ The agile impact report: proven performance metrics from the agile enterprise (p. 1-


6), the use of an agile based approach for the development of software products can be expected

to provide a 3-year ROI of 200%, with a payback period of less than 2 years. The model

assumes: a discount rate of 8 percent, a development organization consisting of 40 developers,

average salary and benefits of $125,000.00 per year per developer, one-time hybrid approach

integration consulting costs of $150,000.00, yearly training costs of $2,000.00 per developer, and

the use of Rally Software’s software as a service (SaaS) delivered agile methods and tools.

Because SaaS delivered methods and tools are being used, there are no additional hardware

costs. In addition conservative productivity gains are being assumed: 5 percent for the first year,

10 percent for the second year, and 15 percent for the third year.


References

Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., & Holley, K. (2008). SOMA: a

method for developing service-oriented solutions. IBM Systems Journal, 47(3), 377-396.

Barretta, J. (2009, February 1). Agile at the wheel. CIO, 22(8). Retrieved on May 6, 2010, from

the ProQuest database.

Brooks, F. P. (1995). The mythical man-month: essays on software engineering (anniversary ed.).

Addison-Wesley Longman, Inc.

Brown, T. (2008, June). Design thinking. Harvard Business Review, 86(6), 84-92.

Brown, T., & Wyatt, J. (2010, Winter). Design thinking for social innovations. Stanford Social

Innovation Review, 8(1), 35-39.

CMS. (2005). Selecting a development approach. Department of Health and Human Services:

Centers for Medicare and Medicaid Services. Retrieved on April 20, 2010, from

http://www3.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentAppr

oach.pdf.

Cockburn, A. (2002). Agile software development. Boston, MA: Addison-Wesley.

Davern, M.J., & Wilkin, C.L. (2008). Evolving innovations through design and use.

Communications of the ACM, 51(12), 133-137.

Forrester Research, Inc. (2004, January 20). The total economic impact of using Thoughtwork’s

agile development. Retrieved on April 20, 2010, from

http://www.thoughtworks.com/sites/www.thoughtworks.com/files/files/forrester_tei.pdf.

Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Software Development Process.

Reading, MA: Addison Wesley Longman, Inc.


Keston, G. (2009a). Agile software development. Retrieved on April 19, 2010 from the Faulkner

Information Services Web site:

http://www.faulkner.com.ezproxy.bellevue.edu/products/faulknerlibrary/.

Keston, G. (2009b). Scrum project management techniques. Retrieved on April 19, 2010 from

the Faulkner Information Services Web site:


Laudon, K. C., & Laudon, J. P. (2007). Management information systems: managing the digital

firm (10th ed.). Upper Saddle River, NJ: Pearson-Prentice Hall.

Page-Jones, M. (2000). Fundamentals of object-oriented design in UML. New York, NY:

Addison-Wesley Longman, Inc.

Poulin, J., & Himler, A. (2006). The ROI of SOA: based on traditional component reuse. Logic

Library. Retrieved April 23, 2010 from

http://www.logiclibrary.com/pdf/wp/ROI_of_SOA.pdf.

Prentice, B. (2009, August 10). Adapt development methodologies to create simple applications.

Gartner Research.

QSM Associates. (2009). The agile impact report: proven performance metrics from the agile

enterprise. Retrieved on April 20, 2010 from

http://www.rallydev.com/agilevalue/email_request/thankyou/make_the_case.html.

Rally Software. (2009). Rally Deployment Guide. Retrieved on May 6, 2010, from

http://www.rallydev.com.

Schwalbe, K. (2010). Information technology project management (6th ed.). Boston, MA: Course

Technology, Cengage Learning.


Sliger, M. (2006). Relating PMBOK practices to agile. Retrieved on April 26, 2010, from

http://www.stickyminds.com/s.asp?F=S10365_COL_2.

Standish Group. (1995). The Standish Group Report: chaos. Retrieved on May 8, 2010, from

http://www.projectsmart.co.uk/docs/chaos-report.pdf.

Turban, E., & Volonino, L. (2009). Technology guide 5: a technical view of systems analysis

and design. In Information technology for management: improving performance in the

digital economy (7th ed.). Retrieved on April 27, 2010 from

http://higheredbcs.wiley.com/legacy/college/turban/0470287489/techguides/tech05.pdf?n

ewwindow=true.

Whitten, J. L., & Bentley, L. D. (2007). Systems analysis and design methods (7th ed.). New

York, NY: McGraw-Hill/Irwin.

Woodward, K. (2009). Project management best practices. Retrieved April 19, 2010 from the

Faulkner Information Services Web site:


Selecting A Development Approach For Competitive Advantage

More Related Content

What's hot

Similar to Selecting A Development Approach For Competitive Advantage

Recently uploaded

Selecting A Development Approach For Competitive Advantage