Click here to load reader
Click here to load reader
Nov 24, 2015
The Executive Guide to Slashing Software Development Costs
How to reduce software development costs by 80%.
Utopia? No just the modernisation of
out-dated software development methods.
An eBook by
A no-holds-barred look at current IT practices and the impact they have on
Copyright 2013 by K M Galbraith. All rights reserved.
This eBook may be downloaded and circulated in its published form.
No extracts may be used without the authors permission.
This book is based on the personal experiences of the author.
Outcomes and productivity gains may vary in other organisations.
Experiences relating to Circatec clients or other parties have been changed to the extent
required to avoid identifying the other party.
All research material is from publically available sources.
CA, CA Plex and Plex are trademarks of CA Technologies.
XSOL InOrder is a trademark of XSOL Limited.
Copies of this eBook can be obtained from Circatecs web site:
Software excellence 2
The current state 3
The traditional software development life cycle (SDLC) 3
The Agile software development life cycle (SDLC) 4
Over reliance on methodology 5
Cant I just send it offshore? 7
The fundamental flaw 7
There is a better way 8
Automated software development tools 8
Application development 8
Rules Engines 10
Benefits of automated software development 11
Managing automated development projects 13
Requirements gathering 13
Architecture and design 14
User interface and patterns 15
Development teams 16
Planning automated software development 17
The benefits are enormous 18
It doesnt stop here 19
The larger the development the greater the savings 19
Compelling case for change 20
How corporate IT resists change 21
Common practices used to maintain control 22
I can do it just as quickly by hand! 24
The CEOs toolkit 24
Bringing about change 25
Existing systems 26
What about work-in-progress? 26
Resistance to change 26
Be prepared to start again 27
What will it take? 28
Change will occur when change is demanded. 28
About the author 29
Introduction Fundamentally the way software is developed and delivered hasnt changed in 40 years.
Over the last ten to fifteen years tools and methodologies to dramatically streamline software
development have been maturing in function and sophistication.
And yet the software industry has been able to resist change. It is reasonable to say that no
other industry has been able to resist change for so long and get away with it.
The impact on an organisations ability to deliver, adapt and take advantage of the rapidly
changing commercial and legislative environment is severe. In many instances IT dictates
corporate agility and speed to market.
While boards and CEOs require system agility and quick response to changing requirements,
their IT department often remains inflexible and resistant to change.
IT departments are empowered and trusted by their organisation to provide software and
technology solutions for the benefit of the organisation. Far too often they fail this trust by
blocking new ways and technologies, often using dismissive statements that, if challenged,
cannot be justified mostly however, they go unchallenged.
Too often Corporate IT is making key and fundamental decisions that have a significant
impact on the business and there is no mechanism in place to hold them to account. The
business managers most affected are seldom engaged in these decisions and are, therefore,
unaware of the alternative solutions available to them.
In 2005 Gartner Group (a leading technology trend forecaster) forecast that 40% of IT job roles
as they existed then would be lost to automation. They went on to forecast that more
American IT jobs would be lost to automation than to outsourcing. The most significant
forecast was that between 2005 and 2010 the productivity of IT workers would increase by a
factor of 10.
Today, some 8 years later, the uptake of automation tools and agile methodologies has
effectively been ignored (the generous view) or blocked (in my experience) by the broader IT
The impact is much more than just high cost and long delivery cycles for software
development, there is a very significant impact on operating costs when systems are out of
step with organisational needs.
This book looks at the current state of software development and then explores commercially
available and proven alternatives before discussing how to bring about significant change.
Let me clear here. The change I am talking about is a fundamental shift in the way we design,
develop and deliver software applications.
If we keep doing the same things we will continue to get the same results.
If we want to change the outcome we must change how things are done.
Software excellence We need to understand what constitutes excellent enterprise software in order to objectively
look at the tools and methodologies used to develop an enterprise application.
User experience The software must be easy to use and enhance the users undertaking
of their everyday job functions.
This means the software must be intuitive to use and reflective of the
enterprise business processes.
In high work load environments the software is so well aligned to the
process that user interaction with the application is highly efficient.
Value add The software must add value to the organisation by providing a more
efficient workplace, eliminating error and waste, enhancing the
customer experience, reducing corporate or financial risk, and other
tangible organisational benefits.
Flexible The ability to adapt to changing organisational demands is critical to
the long term value of the software.
Reliable The software must be available and run consistently day after day.
Other than infrastructure problems the software availability should be
100%. Transactional processing must be so consistent that once
audited subsequent transactions are accepted as correct.
Secure Security in this context is related to the validation of transactions to
ensure data and transactional accuracy. Protections around the
maintenance of data to prevent malicious transactions or accidental
data errors. Incoming electronic data files must pass through
validation filters before being posted to the database.
Cost effective The cost of development must pass a business test. Implementation of
the software must be efficient and the ongoing cost of maintenance,
including changes and enhancements, must be relative to the value
the software is delivering to the organisation.
Scalable The ability of the organisation to grow and/or expand its products and
services must not be hampered by limitations in the softwares ability
to process the increased volumes of transactions.
The tools, standards and methodologies adopted by corporate IT and their service providers
must be totally aligned to the delivery software excellence as judged by the organisation
The sole measure of successful software is the value it brings to the organisation.
The current state The traditional software development life cycle (SDLC)
The waterfall approach to software development has been around since the early 1970s and is
still widely used today. It is a sequential design and development methodology as shown in
this flow chart.
The waterfall model assumes each stage is complete before proceeding to the next.
Architecture & components
VerificationTest & install
Because Waterfall is sequential it is impossible to go back. The assumption is that the
requirements gathering is an accurate and complete reflection of the requirement (which it
seldom is) and the design is an accurate reflection of the requirement.
The advantages of Waterfall are:
It enforces discipline, every stage has a start and end and progress can be monitored
through the use of milestones.
There is considerable documentation which minimises the impact of staff turnover
on the project.
The client (external or internal business unit) knows what to expect. The detailed
specifications describe what the software will do on completion.
The disadvantages of Waterfall are:
Change of requirements is difficult to manage due to the large amount of
Once a stage has been completed it is difficult to go back.
If a specification error or change is required the project must go back to the
Bugs and design flaws arent identified until after the entire application has been
As waterfall moves from one phase to another it engages different d