_03 Experiences of Large Banks
1 like385 views
This document discusses the hurdles and enablers to adopting software product line practices in large corporate organizations, specifically large banks. It identifies some key hurdles including: different business units perceiving little return on investment for cross-unit product lines; and difficulties motivating investment and changing funding models. It proposes some enabling mechanisms that are showing positive results, such as aligning product lines with strategic business goals and establishing executive sponsorship. Large banks present additional challenges to product line adoption due to their multiple divisions, legacy systems, and focus on short-term profits over long-term IT strategies.
![Experiences of Large Banks: Hurdles and enablers to the adoption of
Software Product Line Practices in large corporate organisations
Martin Krsek, Dr. Jay van Zyl, Robert Redpath, Ben Clohesy
SystemicLogic Research Institute, Australia & South Africa
martin@systemiclogic.com.au, jay@systemiclogic.com, robert@systemiclogic.com.au,
ben@systemiclogic.com.au
Nick Dean
Australia and New Zealand Banking Group (ANZ)
nick.dean@anz.com
Abstract
Product Line concepts are widely used and adopted
across a number of industries. Whilst the software
product line concepts are readily accessible to
commercial software product companies, the
application within corporate environments whose core
business is not software has been less evident. What
are the types of challenges that large corporate
organisations need to overcome? This paper presents a
number of hurdles which have been observed during
the adoption of the concepts at two large financial
services organisations. One particular hurdle relates
to the difficulty that business divisions within those
organisations have in perceiving a return on
investment when a product line is established that
crosses business unit boundaries. Furthermore a
number of enabling mechanisms, related to funding, IT
project and general management aspects are proposed
which are showing positive results in facilitating the
adoption of Product Line Practices in corporate
financial service organisations.
1. Context and Introduction
Product line practices as a concept is used in many
forms by organisations around the world [1, 2].
Product managers in fast moving consumer goods
related organisations have created a well defined body
of knowledge as to the branding, marketing,
distribution, and other supply chain related activities in
product commercialization. Today these concepts have
proliferated throughout most industries as commercial
entities are trying to find the next market opportunity,
whilst reducing their product and supporting costs.
Commercial software companies, who produce
commercial “off-the-shelf” software products, have
found the concepts defined by the Software Product
Line Practices (SPLP) initiative of the SEI/CMU
helpful in producing versions of their products for a
number of markets. Corporate organisations, such as
banks however, who are traditionally consumers of
software, experience difficulties in adopting these
practices, which have the potential to address some of
their key IT issues.
This experience report documents our research and
implementation initiatives between 2002 and 2007. We
are introducing projects, implementing aspects of
product line practices, in two large banks (ANZ
Banking Group and another bank referred to as Bank
2). Large refers to a bank with four million or more
customers.
2. General approach and related activity
SystemicLogic has been involved in a number of
projects in large banks mostly in collaboration with the
IT departments at those institutions. Whilst all of these
organisations realize the potential benefits that may
accrue from the successful adoption of the SPLP
approach, they have encountered similar hurdles. A
number of these hurdles relate to difficulties in
motivating investment and amending existing funding
models for the facilitation of product line
developments.
In this paper we document the types of hurdles that
have been observed and propose a number of potential
solutions and enablers to overcome these hurdles.
Experience reports indicating challenges and best
practice have been published before; for example
Kircher et.al. [3] discuss the experience at Siemens and
briefly outline their views on the challenges relating to
skills, agility, outsourcing, tools and drivers for
12th International Software Product Line Conference
978-0-7695-3303-2/08 $25.00 © 2008 IEEE
DOI 10.1109/SPLC.2008.43
161
12th International Software Product Line Conference
978-0-7695-3303-2/08 $25.00 © 2008 IEEE
DOI 10.1109/SPLC.2008.43
161
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-1-320.jpg)
![product line development. Their discussion does not
explore models of investment and the disincentives
associated with software funding, generally regarded as
an expense in banks. Kircher et. al. [3] do make a
useful distinction between a product-driven business,
which they define as a business with a few
standardized products that they offer, and a solution-
driven business that is defined as a business that
custom makes a solution for each customer. Financial
organisations fall closer to a solution-driven business
but do not match either model well with one distinction
being the presence of a captive market consisting of the
various profit generating divisions of the organisation.
Krueger [4] also discusses the adoption barriers at
the deployment of product line practices. He advocates
an incremental approach with a rapid return on
investment. To achieve this he proposes choosing an
appropriate adoption model from
• proactive - plan based on predictable
requirements;
• reactive - implement several variations for each
development cycle based on predictions; and
• extractive – make use of existing software
products as a baseline for a new product line.
One of the adoption models is combined with
lightweight technologies to obtain the optimal
approach to reduce the barriers to adoption. Krueger’s
ideas are useful but are hard to apply in large financial
institutions where product line approaches require a
formal approach in part simply because of the size of
and number of divisions within the organisation.
Schmid and Verlage [5] identify big bang and
incremental investment approaches to product line
investment. They also recognize four situations and
corresponding adoption schemes for product line
engineering these being
• Independent – a new product line is begun
without predecessor products
• Project-integrating – existing systems already
under development are integrated into the product
line development
• Reengineering-driven – Legacy systems cannot
be used and non-trivial reengineering is needed
• Leveraged – A new product line is set up based
on product line already in place.
Relating this to the financial institutions in this
report, there were no pre-existing product lines in
place, although for some of the product lines there are
pre-existing legacy systems. Schmid and Verlage [5]
also demonstrate that there is risk associated with all
product line deployments and the investment will vary
for the number of products developed thus affecting
the break even point at which a traditional
development will become a higher cost option.
Another case study by Kim [6] considers an
insurance company. Kim sees the main problem in that
report as managing variability and he demonstrates a
method using rules changes to resolve variability
issues. For the purposes of this report variability is of
interest, as it will act to increase value to the business
divisions. They will still need to be convinced that a
return on investment will be obtainable in the short to
medium term.
Organisational factors are addressed by Jaktman
[7] where she considers the impact of organisational
structure, business domain, management practices, and
staffing characteristics on maintenance activities for
the product line and the consequent effect on the
quality of code. The study provided valuable insights
with one example relevant here being that funding
from Research and Development created a conflict
when staff had different reporting lines. The study did
not consider barriers to adoption and the two
companies in the case study had well established
product lines in the telecommunications sector at the
time of the study. One of the barriers to adoption
considered in this paper is establishing the business
benefit. Krueger addresses this in his paper [8] where
he suggests a 3-tiered methodology. The bottom tier is
development, the middle tier is the engineering
management and the top tier is executive and business.
The tiers build upon and use the capabilities of the tier
below. The approach has been found to reduce
development costs and avoid application-focused
processes and organisational structures that have been
seen as an impediment to adoption of product line
practices. While making clearer the benefits of a
product line architecture it does not address resistance
to adoption in the complex financial services sector
where multiple divisions have a focus on the short term
and an immediate return on investment.
With regard to cost models Nóbrega [9] provides
an excellent survey of the literature on costing and the
economic models for reuse generally and software
product lines. These models do not address the
necessity and particularities of returning funds to
multiple divisions in a large financial organisation as
are explored in this paper.
162162
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-2-320.jpg)
![derived products [10]. In that situation product time to
market is clearly linked to competitiveness and
consequently profitability so the incentive is stronger
for the establishment of the product line. Furthermore,
the requirement of investment in the product line is in
the forefront of business decision-making.
Business
Unit
2
Business
Unit
1
Year 2Year 1Year 0
IT Project
IT Project
IT Project
Business
Unit
3
Cost that could be
avoided through reuse of
common capability
Total cost of
developing
common
capability
Common
capability
development
Individual Project Funding
Individual Project Funding
Project Funding
Figure 2 Existing Project Based Funding
At the bank the incentive to establish a software
product line is not so apparent, primarily because
software is considered as a cost, with no profit
“upside”. Time to market is achieved by maintaining
control of IT capability, and thereby avoiding long
cross-divisional decision cycles. Each business unit is
heavily incentivised on profitability in the current
quarter or year making the time, cost and risk required
to establish a successful product line too high a hurdle
to overcome. The size of investments, the uncertainty
of returns too far in the future, combined with the other
factors detailed, all contribute to the lack of appetite to
adopt a product line approach.
Product line approaches have been successfully
deployed within a single business unit. Aspects of the
approach have been tried with success in internet
banking at one of the financial institutions (Bank 2)
considered. Bank 2 in this study linked the software
product line to its card offering (banking product),
thereby gaining recognition at the highest levels. This
was done through an executive champion who had a
strong appreciation for banking and IT, possessed
sufficient political clout, and the authority to accept the
risk of the approach. In addition for the approach to be
viable the bank's strategy was altered to allow the
offering to be extended beyond the internal business
units (which were viewed to have limited market
scope). Bank 2 was successful during their
implementation of the product line approach, by
having to reassess their approach to existing disciplines
such as configuration management, release
management and requirements engineering.
In spite of successes as just described it is
recognized that to realize the full benefit of a product
line approach, commonalities across business unit
boundaries need to be exploited. Enablers to assist in
achieving this are proposed and explained in the next
section.
4. Proposals to Enable Product Lines in the
Banking Context
4.1 Alignment with business strategic goals
In the organisations being considered in this paper,
application software may be capitalized but is often not
treated as an organisation-wide asset, rather as an
expense, and usually no strategy for the software
product(s) exists. One of the hurdles therefore is the
acceptance of the value to the organisation of the
software product lines; value in this context meaning
the recognition that it is contributing to the goals of the
organisation. A key advantage of software product
lines is the potential of strategic reuse and it is in the
alignment of the technology direction with business
strategy that we find indicators of where the
organisation value may lie.
Strategic reuse refers to the ability to implement the
derivative software products supporting different
segments of the organisation, exploiting their common
features whilst managing the variations through tools
such as COVAMOF [11]. It is incumbent on the
software product line initiative to prove that the
features and products produced at each point in time
are part of, and align with the strategic direction of the
organisation at that point.
The idea of ensuring that projects and initiatives are
related to the organisational strategy and outcomes is
generally considered in the context of the business case
when approving such undertakings. It is at this point
that the Software Product Lines can run into difficulty
It is suggested here that the relationship of the SPL to
the strategy needs to be broad and demonstrable; that
the outcomes that it helps deliver go beyond the ‘silo’
of the IT support function.
The evidence of the long term return on investment
from using software product lines is difficult to
impress on a short-term (year-on-year) strategy.
Software Product Lines will never be seen as a
valuable asset in and of themselves; it is the end result
and the by-products of the practices that will provide
business value.
To overcome this hurdle, the IT business line
should be proactive and indicate specifically where,
within the organisation’s business model, the software
product line approach will assist. The Business
164164
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-4-320.jpg)
![Motivation Model [12], as an example, provides some
much needed formalism within this domain. The
combination of the business meta-model and the
system meta-model ensures that there are mechanisms
for providing traceability and substantive argument for
the benefit of software product lines (this approach
could also act for other technical formalisms that
struggle for business relevance).
The key concepts that are applicable are1
:
• Strategy (long term, broad in scope, implemented
by Tactics)
• Tactic (short term, narrow in scope, implement
Strategies)
• Goal (long term, focussed scope, quantified by
Objectives)
• Objective (short term, SMART,2
quantify Goals)
• Project (courses of action taken by the business)
How do we then utilise these concepts to enable the
organisation to overcome the hurdles of adoption and
acceptance? The Software Product Line proponent
must consider the following steps:
• Review the Banks defined strategy, or establish a
strategy
• Model the strategy/tactics and goals/objectives.
This is likely to require working with other
business unit managers to understand their needs.
This is important to help generate the necessary
desire for the Software Product Lines in the
business lines.
• Review the planned projects for the strategy
cycle.
• Relate the projects to the Tactics they represent
and the Objectives they satisfy.
• Identify which projects are likely to benefit from
the Software Product Lines.
• Demonstrate the links and benefits.
Figure 3 indicates the relationships and flow of
information. With this in place, it becomes possible to
then draw a direct parallel between the Software
Product Line initiative and the objectives of business
units and their leaders. Given that a major objection to
the Software Product Lines is the initial cost which
needs to be incurred by a non-profit generating IT
function, the suggested steps provide a vehicle to show
that the value of the Software Product Line can be
1
Some of these are considered within the Business Motivation
Model, however for our purposes this is simplified and extended
2
SMART-Specific Measurable Achievable Realistic Timely
realised through the success of other projects and
objectives.
MeansMeans
Strategy
-Retail division
-Corporate division
-Markets & Capital
division
-IT Division
Strategy
-Retail division
-Corporate division
-Markets & Capital
division
-IT Division
Tactics
-Implement 2
software product
lines
Tactics
-Implement 2
software product
lines
Ends
Goals
-Enterprise goals
-Divisional goals
Goals
-Enterprise goals
-Divisional goals
Objectives
-Reduce 20% cost
through software
product line 1
-Product Line 2 to
deliver card
processing to new
client by end 2008
Objectives
-Reduce 20% cost
through software
product line 1
-Product Line 2 to
deliver card
processing to new
client by end 2008
IT Project
portfolio
IT Project
portfolio
Product line
1
Product line
1
Product line
2
Product line
2
Alignment &
planning processes
Figure 3 Aligning Strategy and the Software Product Lines
Formalising the business strategy model is an
important part of ensuring that there is recognition of
the value of the Software Product Line as a collection
of strategic assets. These strategic assets include the
strategy alignment model, requirements and software
architecture models, as well as the software
components, processes, tools, testing collateral, people
and skills. Gomaa [13] gives a comprehensive structure
for modeling software product line requirements and
architecture. In turn, these should be related to the
aligned business strategy model. Early definition of
these models provides elements of guidance toward the
prioritized delivery of the entire initiative and assists
with the necessary task of continuously ensuring that
the Software Product Line is in line with the unfolding
strategy. The modeling assets facilitate the Software
Product Line being leveraged in other parts of the
organisation as organisation priority and opportunity
allow.
To conclude this section, while it may seem
obvious that the business strategy should be aligned
with the product line adoption our experience has
found that in practice this has not been successfully
done at financial institutions in the past. The use of
models3
has been a key element in the strategic
alignment at ANZ and the expectation is that further
product line adoption will occur, now that alignment
can be demonstrated.
4.2 Organisation structure
As has already been described in section 3.2,
application software development in financial services
3
Including extensions in UML – disconnected documents,
spreadsheets and presentations are not enough.
165165
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-5-320.jpg)
![organisations is often solely driven by the immediate
requirements of individual business units. The
development organisation is reactive, executing IT
projects which address a collection of these short-term
business requirements. To overcome this hurdle a
number of measures must be taken. Firstly there must
be an individual possessed of sufficient authority who
will assume a visionary role to override the narrower
concerns of the individual business units. This
visionary must motivate that an appropriate funding
model is in place, secure funding for the establishment
of a product line approach and then subsequently
ensure the support of a critical mass of business units
so that it becomes sustainable. In reality business units
are very loathe to relinquish their power with respect to
IT development resources that are exclusively under
their control. The implications of the power shift
towards centralised IT is one of the greatest hurdles
that must be overcome. Alternate approaches with
measures including having representatives of the
business units on a controlling steering committee that
sets the funding priorities have had varied success.
This politically difficult issue has not been adequately
resolved at either of the banks considered in this paper.
Secondly a product management function, being
responsible for the requirements analysis, longer term
product planning and management for all of the
products which are in scope of the product family
supported by a software product line, must be
established. This is an unfamiliar role in corporate IT
departments and its establishment needs to be
motivated and accompanied by change management
interventions to address the short-term reactive
approach to applications development and
enhancement. The product management function,
similar to this role in the commercial software
companies, has the responsibility to ensure that the
product line addresses a sufficient scope to be
economically viable. It differs from the roles in
commercial software companies in that support for the
product line must be lobbied and commitment
obtained, since the deflection of a business unit could
drastically change the product line’s business case, as
the “market” is most often limited to the corporate
organisation.
In addition, governance mechanisms for managing
the product line scope, the product line architecture and
prioritization of features are required, albeit not all at
the same level. The product line scope is the primary
governance function, with the product line architecture
and prioritization of features governance, supporting it
and other organisation-wide objectives. The mandates
of these mechanisms must be clearly defined, using a
charter, or similar mechanism, approved at senior
level.
Figure 4 Product Line Implementation Processes
The cultural shift from a largely reactive project
focus to a more proactive product focus and
prioritization of features across the organisation, rather
than within individual business unit silos is another
hurdle. This prioritization is more difficult and requires
new decision making structures, and strategy driven
guidelines for decision-making to remove, as far as
possible, the role of individual business unit agendas
and vested interests as also identified by Murphy [14].
Figure 4 shows the proposed processes ANZ will
be using for implementation of the approach in
sequence and around which the governance is being
built.
4.3 Economic model
In order for the proven benefits of Software Product
Lines to be realised in non-commercial software
organisations, the product line visionary must motivate
the business units by demonstrating a link to the core
objectives that meet the organisation’s strategies. In
order to determine return on investment (ROI) with
any degree of confidence, and therefore achieve
commitment to the approach, sufficient planning,
strategically scoping the product line, is required. In
one case a bank (Bank 2) linked the software product
line to a banking product strategic proposition. In other
cases, adoption of the product line is preceded with up-
front product-line planning which determines the
product line scope and business model or business case
during which the ROI can be determined,
In [15] Böckle et al propose a method for
calculating returns on investment in software product
Product Line Implementation Processes
Define Funding
Structure the organisation
Train on Product Line Operating Model
Define Product Line Architecture
Plan execution
Implement Customer Interface Management
Develop an Acquisition Strategy
Manage risk
Define PL Features
Appoint Product Line
Define Product Line
166166
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-6-320.jpg)
![lines. These approaches are extended in [9,16,17,18]
However recovery and benefit allocation mechanisms
between business units can present further challenges
in corporate organisations.
The requirement for an investment to initiate the
product line is recognized in order to fund the
organisation change and establishment of the core asset
base e.g. [15]. Investment can be either funded
centrally by the CEO or CIO, and not explicitly
recovered (this is referred to as the taxation model for
funding [19]) or by a specific business unit or a
consortium of business units. In the latter case the
hurdle is providing equitable recognition (and
monetary benefits) to the investors. What has been
proposed is a per-use charging model for the core
assets of the product line realized from the investment.
Figure 5 illustrates a usage based model to recover
investment in the product line. The per-use charging
must cover maintenance and upgrade releases of the
product line’s core assets and provide a return to the
investors involved in its establishment.
Project Funding
Project Funding
Dividends
Year 3Year 2Year 1
IT Project
IT Project
IT Project
Total cost of
developing common
capability once less
than developing
separately
Cost of
integration &
configuration
of core assets
Production – pay per use
Income pool, (zero sum game)
Production – pay per use
Production – pay per use
Allocation for maintenance of core assets
Business
Unit
3
IT Project
Core asset
development
Seedfunding/investment
Business
Unit
2
Business
Unit
1
Project Funding
Figure 5 A Usage Based Economic Model
This is in contrast to the common approach where
business units fund the development of applications
up-front, with no follow up costs thereafter. (Some
variations on this theme exist). The often un-intended
consequence of this approach is that the application is
not “maintained” as any asset should be, until a new
business requirement is identified. Whilst the “per-use”
approach is not a new way to deal with hardware and
base software infrastructure, it is resisted especially for
internally developed software, because it implies that a
“cost-centre” may make a profit. However the benefit
is that non-investors getting benefits from the core-
assets will pay for their use proportional to their need
(relieving new smaller business units of the burden to
fund large up-front application development costs).
Under this scheme the costs to the investing business
units are off-set by the distribution of the “profit” back
to them proportional to their initial investment. This
may be implemented as a discount. Through this, the
operating cost centre does not retain any of the profit,
although prudently, some funds should be retained for
re-investment in the assets’ sustainability.
5. Conclusion
Table 1 below, summarises the approaches to
overcoming these hurdles observed at the two banks
we have worked with, and contrasted with the
approach previously observed at a commercial
software organisation using SPLP.
There are important differences between IT in
financial services organisations and commercial
software companies. These differences imply that there
are additional hurdles that must be overcome for
Software Product Line Practice to be successfully
adopted.
From our observations it is a key issue that the
Software Product Line approach is demonstrated to
align with the organisation’s strategic business
objectives, and is shown to provide business benefits
with acceptable risk. Modeling techniques and tools
are available for product line modeling and they should
be used to aid this strategic alignment. The business
silo project driven organisation design must be
amended and complemented specifically with the
creation of a product management function and
governance mechanisms to ensure that products scoped
into a product line are not withdrawn without due
consideration of the implications, and specifically the
implications for the product line business case.
An economic model comprising the initial
investment, charging model and return on investment
by the product line over time must be designed and
integrated into the internal costing mechanisms of the
organisation. Financial service organisations that
pursue the adoption of Software Product Lines by
addressing these hurdles are positioning themselves to
derive similar benefits, albeit on a smaller scale to
those obtained by commercial software companies
operating in the open market.
Future work will undertake further empirical
studies, at large financial institutions, of Software
Product Line adoption to more closely identify the
hurdles to adoption as well as refining the solutions
and enablers to overcome them. Approaches to be
employed will focus on identifying and formalising
points of commonality and variability during
requirements modeling and engineering.
167167
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-7-320.jpg)
![ANZ Bank 2 Reference
commercial
s/w company
Company
strategy
SPLP is an IT
response to
the business
strategy
demanding
variants of IT
systems.
Business
product
supporting a
business
strategy
incorporates
SPLP based
IT. This
approach
ensures access
to clients
outside of the
corporate
boundary.
Core
organisational
strategy to
develop
software
product
deployable at
multiple
clients and
markets, from
core assets.
Organisation
structure
IT General
Manager of all
Product Lines,
to whom
Product Line
managers
report.
Product Line
Councils
govern scope.
General
Manager of IT
Product
supporting a
business
product line
and relying on
SPLP
concepts.
Product
manager at
general
manager level.
Product line
architecture
compliance
responsibility
of CTO.
Funding
model
Seed
investment
from primary
business unit.
Per-use
charging
model being
implemented.
Investment
from founding
partners,
together with
shared risk /
reward model
for added
products.
JV Capital
raising phase
and arms-
length
responsibility
for ROI
thereafter.
Table 1 Enablers compared for different organisations
In addition, economic models and methods to
motivate a view of software as an asset based on
traditional valuation models, as used for physical assets
that exhibit features of an upfront investment,
compulsory charges for those making use of the asset,
ongoing maintenance costs and depreciation over the
life of the asset will be investigated. The presence of
service oriented architectures must also be factored
into approaches and a conception of Service Line
Practices introduced with their attendant implications
and shift in thinking.
6. References
[1] Pohl, K.; Böckle, G.; van der Linden, F., Software
Product Line Engineering, Springer, 2005.
[2] Clements, P.; Northrop, L., Software Product Lines,
Addison-Wesley, 2001.
[3] Kircher M. Schwanninger C. Groher I., Transitioning to a
Software Product Family Approach – Challenges and Best
Practices 10th
International Software Product Line
Conference (SPLC’06), IEEE, 2006, Pages: 9 pp.
[4] Krueger C., Eliminating the Adoption Barrier IEEE
Software July/August 2002, pp. 29-31
[5] Schmid K. Verlage M., The Economic Impact of Product
Line Adoption and Evolution IEEE Software July/August
2002, pp. 50-57
[6] Jeong Ah Kim, Case Study of Product Line Engineering
in Insurance Company IEEE International Conference on
Information Reuse and Integration, 2006, pp. 303-306
[7] Jaktman C. B., The Influence of Organisational Factors
on the Success and Quality of a Product Line Architecture
IEEE Australian Software Engineering Conference, 1998.
IEEE, 1998, pp. 2-11
[8] Krueger C. W., The 3-Tiered Methodology:
Pragmatic Insights from New Generation Software Product
Lines 11th
International Software Product Line Conference
(SPLC’07), IEEE, 2007
[9] Nóbrega, J.P. Santana de Almeida1, E. Meira, S.R.L., A
Cost Framework Specification for Software Product Lines
Scenarios WDBC Dec 2006 - Workshop de
Desenvolvimento Baseado em Componentes, Sociedade
Brasileira de Computa, 2006
http://wdbc2006.cesar.org.br/wp-content/uploads/23948.pdf
[10] van Zyl, J., Product Line Architecture and the
Separation of Concerns Second International Conference
Software Product Lines, SPLC2, 2002. published as
Proceedings Series: Lecture Notes in Computer Science,
Vol. 2379 Chastek, G. J. (Ed.), Springer, 2002, pp. 83-119
[11] COVAMOF: Variability Management in Software
Product Families, A Plug-in for Microsoft Visual Studio
.NET http://www.covamof.com/index.php/introduction
[12] Business Motivation Model
http://www.businessrulesgroup.org/bmm.shtml
http://www.omg.org/technology/documents/bms_spec_catalo
g.htm
[13] Gomaa, H., Designing Software Product Lines with
UML: From Use Cases to Pattern-Based Software
Architectures, Addison-Wesley, 2005
[14] Murphy, T., Achieving Business Value from
Technology: A Practical Guide for Today’s Executive,
Gartner Press - John Wiley & Sons Inc., 2002
[15] Böckle, G. Clements, P. McGregor, J. D. Muthig, D.
Schmid, K., Calculating ROI for Software Product Lines
IEEE Software May/June, IEEE 2004, pp. 23-31
[16] Yoshimura, K. Ganesan, D Muthing, D., Defining a
strategy to introduce a software product line using existing
embedded systems 6th ACM & IEEE International
conference on Embedded software, IEEE 2006, pp. 63-72
168168
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-8-320.jpg)
![[17] Clements, P., McGregor, J.D. and Cohen, S.G., The
Structured Intuitive Model for Product Line Economics
(SIMPLE) Technical Report CMU/SEI-2005-TR-003,
February 2005
[18] Ganesan, D Knodel, J. Kolb, R. Haury, U. Meier G.,
Comparing Costs and Benefits of Different Test Strategies
for Software Product Line: A Study from Testo AG 11th
International Software Product Line Conference (SPLC’07),
IEEE, 2007
[19] Bosch, J., On the Development of Software Product-
Family Components Second International Conference
Software Product Lines, SPLC2, 2002. published as
Proceedings Series: Lecture Notes in Computer Science,
Vol. 2379 Chastek, G. J. (Ed.), Springer, 2002, pp. 146-164
169169
Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.](https://image.slidesharecdn.com/ee1f538c-7645-4bc2-b965-7d40fce76642-150321035900-conversion-gate01/85/_03-Experiences-of-Large-Banks-9-320.jpg)
_03 Experiences of Large Banks
- 1. Experiences of Large Banks: Hurdles and enablers to the adoption of Software Product Line Practices in large corporate organisations Martin Krsek, Dr. Jay van Zyl, Robert Redpath, Ben Clohesy SystemicLogic Research Institute, Australia & South Africa martin@systemiclogic.com.au, jay@systemiclogic.com, robert@systemiclogic.com.au, ben@systemiclogic.com.au Nick Dean Australia and New Zealand Banking Group (ANZ) nick.dean@anz.com Abstract Product Line concepts are widely used and adopted across a number of industries. Whilst the software product line concepts are readily accessible to commercial software product companies, the application within corporate environments whose core business is not software has been less evident. What are the types of challenges that large corporate organisations need to overcome? This paper presents a number of hurdles which have been observed during the adoption of the concepts at two large financial services organisations. One particular hurdle relates to the difficulty that business divisions within those organisations have in perceiving a return on investment when a product line is established that crosses business unit boundaries. Furthermore a number of enabling mechanisms, related to funding, IT project and general management aspects are proposed which are showing positive results in facilitating the adoption of Product Line Practices in corporate financial service organisations. 1. Context and Introduction Product line practices as a concept is used in many forms by organisations around the world [1, 2]. Product managers in fast moving consumer goods related organisations have created a well defined body of knowledge as to the branding, marketing, distribution, and other supply chain related activities in product commercialization. Today these concepts have proliferated throughout most industries as commercial entities are trying to find the next market opportunity, whilst reducing their product and supporting costs. Commercial software companies, who produce commercial “off-the-shelf” software products, have found the concepts defined by the Software Product Line Practices (SPLP) initiative of the SEI/CMU helpful in producing versions of their products for a number of markets. Corporate organisations, such as banks however, who are traditionally consumers of software, experience difficulties in adopting these practices, which have the potential to address some of their key IT issues. This experience report documents our research and implementation initiatives between 2002 and 2007. We are introducing projects, implementing aspects of product line practices, in two large banks (ANZ Banking Group and another bank referred to as Bank 2). Large refers to a bank with four million or more customers. 2. General approach and related activity SystemicLogic has been involved in a number of projects in large banks mostly in collaboration with the IT departments at those institutions. Whilst all of these organisations realize the potential benefits that may accrue from the successful adoption of the SPLP approach, they have encountered similar hurdles. A number of these hurdles relate to difficulties in motivating investment and amending existing funding models for the facilitation of product line developments. In this paper we document the types of hurdles that have been observed and propose a number of potential solutions and enablers to overcome these hurdles. Experience reports indicating challenges and best practice have been published before; for example Kircher et.al. [3] discuss the experience at Siemens and briefly outline their views on the challenges relating to skills, agility, outsourcing, tools and drivers for 12th International Software Product Line Conference 978-0-7695-3303-2/08 $25.00 © 2008 IEEE DOI 10.1109/SPLC.2008.43 161 12th International Software Product Line Conference 978-0-7695-3303-2/08 $25.00 © 2008 IEEE DOI 10.1109/SPLC.2008.43 161 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 2. product line development. Their discussion does not explore models of investment and the disincentives associated with software funding, generally regarded as an expense in banks. Kircher et. al. [3] do make a useful distinction between a product-driven business, which they define as a business with a few standardized products that they offer, and a solution- driven business that is defined as a business that custom makes a solution for each customer. Financial organisations fall closer to a solution-driven business but do not match either model well with one distinction being the presence of a captive market consisting of the various profit generating divisions of the organisation. Krueger [4] also discusses the adoption barriers at the deployment of product line practices. He advocates an incremental approach with a rapid return on investment. To achieve this he proposes choosing an appropriate adoption model from • proactive - plan based on predictable requirements; • reactive - implement several variations for each development cycle based on predictions; and • extractive – make use of existing software products as a baseline for a new product line. One of the adoption models is combined with lightweight technologies to obtain the optimal approach to reduce the barriers to adoption. Krueger’s ideas are useful but are hard to apply in large financial institutions where product line approaches require a formal approach in part simply because of the size of and number of divisions within the organisation. Schmid and Verlage [5] identify big bang and incremental investment approaches to product line investment. They also recognize four situations and corresponding adoption schemes for product line engineering these being • Independent – a new product line is begun without predecessor products • Project-integrating – existing systems already under development are integrated into the product line development • Reengineering-driven – Legacy systems cannot be used and non-trivial reengineering is needed • Leveraged – A new product line is set up based on product line already in place. Relating this to the financial institutions in this report, there were no pre-existing product lines in place, although for some of the product lines there are pre-existing legacy systems. Schmid and Verlage [5] also demonstrate that there is risk associated with all product line deployments and the investment will vary for the number of products developed thus affecting the break even point at which a traditional development will become a higher cost option. Another case study by Kim [6] considers an insurance company. Kim sees the main problem in that report as managing variability and he demonstrates a method using rules changes to resolve variability issues. For the purposes of this report variability is of interest, as it will act to increase value to the business divisions. They will still need to be convinced that a return on investment will be obtainable in the short to medium term. Organisational factors are addressed by Jaktman [7] where she considers the impact of organisational structure, business domain, management practices, and staffing characteristics on maintenance activities for the product line and the consequent effect on the quality of code. The study provided valuable insights with one example relevant here being that funding from Research and Development created a conflict when staff had different reporting lines. The study did not consider barriers to adoption and the two companies in the case study had well established product lines in the telecommunications sector at the time of the study. One of the barriers to adoption considered in this paper is establishing the business benefit. Krueger addresses this in his paper [8] where he suggests a 3-tiered methodology. The bottom tier is development, the middle tier is the engineering management and the top tier is executive and business. The tiers build upon and use the capabilities of the tier below. The approach has been found to reduce development costs and avoid application-focused processes and organisational structures that have been seen as an impediment to adoption of product line practices. While making clearer the benefits of a product line architecture it does not address resistance to adoption in the complex financial services sector where multiple divisions have a focus on the short term and an immediate return on investment. With regard to cost models Nóbrega [9] provides an excellent survey of the literature on costing and the economic models for reuse generally and software product lines. These models do not address the necessity and particularities of returning funds to multiple divisions in a large financial organisation as are explored in this paper. 162162 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 3. 3. Product Line Concepts in Large Banks 3.1 Opportunities and Challenges There are some common characteristics possessed by the organisations that are documented in this paper. These include: 1)software is not a core business of these organisations with typically, IT and more specifically their application systems being regarded as an expense that has to be borne by the business in order to deliver their services effectively and efficiently, and to automate the myriad of internal processes; 2) in both organisations the accountability for funding and controlling the application software development is delegated to individual business units, whilst in one, each business unit has its own IT organisation; 3) the long term organisation strategies do not extend to the sourcing and management of application software; and 4) there is a belief that there is a large percentage of commonality existing between the software intensive, financial service products delivered in different regions, to a number of market segments, through a variety of channels, within multiple regulatory frameworks, often using different application systems and infrastructure. Figure 1 indicates some of the issues and challenges that confront large banks as they exist now. Weak strategic links Tactical engagement Reactive approach to IT capability Paper-based application architecture No IP preservation Key people dependence No product line implementations Duplication of capability Escalating cost Approach scalability issues Figure 1 Issues in the Existing Context In addition experience in working at the two banks in question revealed some specific challenges that need to be highlighted. These include: 1) reducing duplicate infrastructure in a situation where the banks have huge investments in large and complex IT infrastructures with much of the infrastructure mirroring the traditional line of business silos such as current/savings accounts, mortgage lending, card products, and wealth management products; 2) reducing maintenance and development costs in environments typified by legacy systems and the use of complex and extensively modified software products; 3) dealing with additional channel technologies with the banks deploying their banking services across many electronic and physical channels for example internet banking, automated teller machines, branches, various intermediaries and mobile phones; 4) managing portfolios of projects across many different types of assets with the more business project oriented cultures of banks forcing behavior away from strategic re-use and into more tactical decision making with in most cases no mechanisms for project teams to become aware of re- use opportunities; 5) addressing the limited organisational appetite for implementing the changes required by a product line approach, including the ability to change the organisational culture to allow these changes to be proliferated. 3.2. The Large Bank Context Large banks are typically divided into numerous divisions based on lines of business, geography, market segments, and channels of delivery. They are managed separately and each will usually constitute a profit centre in its own right. Whilst they may share infrastructure (although in some cases not even infrastructure is shared) they often have their own IT capability or employ the services of the IT department or independent software houses on a project by project basis. There is no funding for the common (those functions that are very close or common across the various divisions described above) in the sense required for the development of a product line or product family. Where reuse does occur it is usually arrived at on a very opportunistic basis. This project by project approach is shown in figure 2. When we compare this to a software company or manufacturing company, there is an external purchaser of the software or the manufactured item with embedded software function, and therefore a profit motive. There is no exact equivalent to the external purchaser of the software product in a bank. There is an absence of a clear, strictly commercial or profit motive for the establishment of the product line. Rather, in most cases, the motive is the reduction of IT costs. In contrast in a commercial software company there is a clear motive to employ a product line approach. The identification of commonality will allow its exploitation and the subsequent delivery to market of individual product variants in shorter times than would otherwise be the case and at lower cost, beyond a certain break-even point, based on the number of 163163 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 4. derived products [10]. In that situation product time to market is clearly linked to competitiveness and consequently profitability so the incentive is stronger for the establishment of the product line. Furthermore, the requirement of investment in the product line is in the forefront of business decision-making. Business Unit 2 Business Unit 1 Year 2Year 1Year 0 IT Project IT Project IT Project Business Unit 3 Cost that could be avoided through reuse of common capability Total cost of developing common capability Common capability development Individual Project Funding Individual Project Funding Project Funding Figure 2 Existing Project Based Funding At the bank the incentive to establish a software product line is not so apparent, primarily because software is considered as a cost, with no profit “upside”. Time to market is achieved by maintaining control of IT capability, and thereby avoiding long cross-divisional decision cycles. Each business unit is heavily incentivised on profitability in the current quarter or year making the time, cost and risk required to establish a successful product line too high a hurdle to overcome. The size of investments, the uncertainty of returns too far in the future, combined with the other factors detailed, all contribute to the lack of appetite to adopt a product line approach. Product line approaches have been successfully deployed within a single business unit. Aspects of the approach have been tried with success in internet banking at one of the financial institutions (Bank 2) considered. Bank 2 in this study linked the software product line to its card offering (banking product), thereby gaining recognition at the highest levels. This was done through an executive champion who had a strong appreciation for banking and IT, possessed sufficient political clout, and the authority to accept the risk of the approach. In addition for the approach to be viable the bank's strategy was altered to allow the offering to be extended beyond the internal business units (which were viewed to have limited market scope). Bank 2 was successful during their implementation of the product line approach, by having to reassess their approach to existing disciplines such as configuration management, release management and requirements engineering. In spite of successes as just described it is recognized that to realize the full benefit of a product line approach, commonalities across business unit boundaries need to be exploited. Enablers to assist in achieving this are proposed and explained in the next section. 4. Proposals to Enable Product Lines in the Banking Context 4.1 Alignment with business strategic goals In the organisations being considered in this paper, application software may be capitalized but is often not treated as an organisation-wide asset, rather as an expense, and usually no strategy for the software product(s) exists. One of the hurdles therefore is the acceptance of the value to the organisation of the software product lines; value in this context meaning the recognition that it is contributing to the goals of the organisation. A key advantage of software product lines is the potential of strategic reuse and it is in the alignment of the technology direction with business strategy that we find indicators of where the organisation value may lie. Strategic reuse refers to the ability to implement the derivative software products supporting different segments of the organisation, exploiting their common features whilst managing the variations through tools such as COVAMOF [11]. It is incumbent on the software product line initiative to prove that the features and products produced at each point in time are part of, and align with the strategic direction of the organisation at that point. The idea of ensuring that projects and initiatives are related to the organisational strategy and outcomes is generally considered in the context of the business case when approving such undertakings. It is at this point that the Software Product Lines can run into difficulty It is suggested here that the relationship of the SPL to the strategy needs to be broad and demonstrable; that the outcomes that it helps deliver go beyond the ‘silo’ of the IT support function. The evidence of the long term return on investment from using software product lines is difficult to impress on a short-term (year-on-year) strategy. Software Product Lines will never be seen as a valuable asset in and of themselves; it is the end result and the by-products of the practices that will provide business value. To overcome this hurdle, the IT business line should be proactive and indicate specifically where, within the organisation’s business model, the software product line approach will assist. The Business 164164 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 5. Motivation Model [12], as an example, provides some much needed formalism within this domain. The combination of the business meta-model and the system meta-model ensures that there are mechanisms for providing traceability and substantive argument for the benefit of software product lines (this approach could also act for other technical formalisms that struggle for business relevance). The key concepts that are applicable are1 : • Strategy (long term, broad in scope, implemented by Tactics) • Tactic (short term, narrow in scope, implement Strategies) • Goal (long term, focussed scope, quantified by Objectives) • Objective (short term, SMART,2 quantify Goals) • Project (courses of action taken by the business) How do we then utilise these concepts to enable the organisation to overcome the hurdles of adoption and acceptance? The Software Product Line proponent must consider the following steps: • Review the Banks defined strategy, or establish a strategy • Model the strategy/tactics and goals/objectives. This is likely to require working with other business unit managers to understand their needs. This is important to help generate the necessary desire for the Software Product Lines in the business lines. • Review the planned projects for the strategy cycle. • Relate the projects to the Tactics they represent and the Objectives they satisfy. • Identify which projects are likely to benefit from the Software Product Lines. • Demonstrate the links and benefits. Figure 3 indicates the relationships and flow of information. With this in place, it becomes possible to then draw a direct parallel between the Software Product Line initiative and the objectives of business units and their leaders. Given that a major objection to the Software Product Lines is the initial cost which needs to be incurred by a non-profit generating IT function, the suggested steps provide a vehicle to show that the value of the Software Product Line can be 1 Some of these are considered within the Business Motivation Model, however for our purposes this is simplified and extended 2 SMART-Specific Measurable Achievable Realistic Timely realised through the success of other projects and objectives. MeansMeans Strategy -Retail division -Corporate division -Markets & Capital division -IT Division Strategy -Retail division -Corporate division -Markets & Capital division -IT Division Tactics -Implement 2 software product lines Tactics -Implement 2 software product lines Ends Goals -Enterprise goals -Divisional goals Goals -Enterprise goals -Divisional goals Objectives -Reduce 20% cost through software product line 1 -Product Line 2 to deliver card processing to new client by end 2008 Objectives -Reduce 20% cost through software product line 1 -Product Line 2 to deliver card processing to new client by end 2008 IT Project portfolio IT Project portfolio Product line 1 Product line 1 Product line 2 Product line 2 Alignment & planning processes Figure 3 Aligning Strategy and the Software Product Lines Formalising the business strategy model is an important part of ensuring that there is recognition of the value of the Software Product Line as a collection of strategic assets. These strategic assets include the strategy alignment model, requirements and software architecture models, as well as the software components, processes, tools, testing collateral, people and skills. Gomaa [13] gives a comprehensive structure for modeling software product line requirements and architecture. In turn, these should be related to the aligned business strategy model. Early definition of these models provides elements of guidance toward the prioritized delivery of the entire initiative and assists with the necessary task of continuously ensuring that the Software Product Line is in line with the unfolding strategy. The modeling assets facilitate the Software Product Line being leveraged in other parts of the organisation as organisation priority and opportunity allow. To conclude this section, while it may seem obvious that the business strategy should be aligned with the product line adoption our experience has found that in practice this has not been successfully done at financial institutions in the past. The use of models3 has been a key element in the strategic alignment at ANZ and the expectation is that further product line adoption will occur, now that alignment can be demonstrated. 4.2 Organisation structure As has already been described in section 3.2, application software development in financial services 3 Including extensions in UML – disconnected documents, spreadsheets and presentations are not enough. 165165 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 6. organisations is often solely driven by the immediate requirements of individual business units. The development organisation is reactive, executing IT projects which address a collection of these short-term business requirements. To overcome this hurdle a number of measures must be taken. Firstly there must be an individual possessed of sufficient authority who will assume a visionary role to override the narrower concerns of the individual business units. This visionary must motivate that an appropriate funding model is in place, secure funding for the establishment of a product line approach and then subsequently ensure the support of a critical mass of business units so that it becomes sustainable. In reality business units are very loathe to relinquish their power with respect to IT development resources that are exclusively under their control. The implications of the power shift towards centralised IT is one of the greatest hurdles that must be overcome. Alternate approaches with measures including having representatives of the business units on a controlling steering committee that sets the funding priorities have had varied success. This politically difficult issue has not been adequately resolved at either of the banks considered in this paper. Secondly a product management function, being responsible for the requirements analysis, longer term product planning and management for all of the products which are in scope of the product family supported by a software product line, must be established. This is an unfamiliar role in corporate IT departments and its establishment needs to be motivated and accompanied by change management interventions to address the short-term reactive approach to applications development and enhancement. The product management function, similar to this role in the commercial software companies, has the responsibility to ensure that the product line addresses a sufficient scope to be economically viable. It differs from the roles in commercial software companies in that support for the product line must be lobbied and commitment obtained, since the deflection of a business unit could drastically change the product line’s business case, as the “market” is most often limited to the corporate organisation. In addition, governance mechanisms for managing the product line scope, the product line architecture and prioritization of features are required, albeit not all at the same level. The product line scope is the primary governance function, with the product line architecture and prioritization of features governance, supporting it and other organisation-wide objectives. The mandates of these mechanisms must be clearly defined, using a charter, or similar mechanism, approved at senior level. Figure 4 Product Line Implementation Processes The cultural shift from a largely reactive project focus to a more proactive product focus and prioritization of features across the organisation, rather than within individual business unit silos is another hurdle. This prioritization is more difficult and requires new decision making structures, and strategy driven guidelines for decision-making to remove, as far as possible, the role of individual business unit agendas and vested interests as also identified by Murphy [14]. Figure 4 shows the proposed processes ANZ will be using for implementation of the approach in sequence and around which the governance is being built. 4.3 Economic model In order for the proven benefits of Software Product Lines to be realised in non-commercial software organisations, the product line visionary must motivate the business units by demonstrating a link to the core objectives that meet the organisation’s strategies. In order to determine return on investment (ROI) with any degree of confidence, and therefore achieve commitment to the approach, sufficient planning, strategically scoping the product line, is required. In one case a bank (Bank 2) linked the software product line to a banking product strategic proposition. In other cases, adoption of the product line is preceded with up- front product-line planning which determines the product line scope and business model or business case during which the ROI can be determined, In [15] Böckle et al propose a method for calculating returns on investment in software product Product Line Implementation Processes Define Funding Structure the organisation Train on Product Line Operating Model Define Product Line Architecture Plan execution Implement Customer Interface Management Develop an Acquisition Strategy Manage risk Define PL Features Appoint Product Line Define Product Line 166166 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 7. lines. These approaches are extended in [9,16,17,18] However recovery and benefit allocation mechanisms between business units can present further challenges in corporate organisations. The requirement for an investment to initiate the product line is recognized in order to fund the organisation change and establishment of the core asset base e.g. [15]. Investment can be either funded centrally by the CEO or CIO, and not explicitly recovered (this is referred to as the taxation model for funding [19]) or by a specific business unit or a consortium of business units. In the latter case the hurdle is providing equitable recognition (and monetary benefits) to the investors. What has been proposed is a per-use charging model for the core assets of the product line realized from the investment. Figure 5 illustrates a usage based model to recover investment in the product line. The per-use charging must cover maintenance and upgrade releases of the product line’s core assets and provide a return to the investors involved in its establishment. Project Funding Project Funding Dividends Year 3Year 2Year 1 IT Project IT Project IT Project Total cost of developing common capability once less than developing separately Cost of integration & configuration of core assets Production – pay per use Income pool, (zero sum game) Production – pay per use Production – pay per use Allocation for maintenance of core assets Business Unit 3 IT Project Core asset development Seedfunding/investment Business Unit 2 Business Unit 1 Project Funding Figure 5 A Usage Based Economic Model This is in contrast to the common approach where business units fund the development of applications up-front, with no follow up costs thereafter. (Some variations on this theme exist). The often un-intended consequence of this approach is that the application is not “maintained” as any asset should be, until a new business requirement is identified. Whilst the “per-use” approach is not a new way to deal with hardware and base software infrastructure, it is resisted especially for internally developed software, because it implies that a “cost-centre” may make a profit. However the benefit is that non-investors getting benefits from the core- assets will pay for their use proportional to their need (relieving new smaller business units of the burden to fund large up-front application development costs). Under this scheme the costs to the investing business units are off-set by the distribution of the “profit” back to them proportional to their initial investment. This may be implemented as a discount. Through this, the operating cost centre does not retain any of the profit, although prudently, some funds should be retained for re-investment in the assets’ sustainability. 5. Conclusion Table 1 below, summarises the approaches to overcoming these hurdles observed at the two banks we have worked with, and contrasted with the approach previously observed at a commercial software organisation using SPLP. There are important differences between IT in financial services organisations and commercial software companies. These differences imply that there are additional hurdles that must be overcome for Software Product Line Practice to be successfully adopted. From our observations it is a key issue that the Software Product Line approach is demonstrated to align with the organisation’s strategic business objectives, and is shown to provide business benefits with acceptable risk. Modeling techniques and tools are available for product line modeling and they should be used to aid this strategic alignment. The business silo project driven organisation design must be amended and complemented specifically with the creation of a product management function and governance mechanisms to ensure that products scoped into a product line are not withdrawn without due consideration of the implications, and specifically the implications for the product line business case. An economic model comprising the initial investment, charging model and return on investment by the product line over time must be designed and integrated into the internal costing mechanisms of the organisation. Financial service organisations that pursue the adoption of Software Product Lines by addressing these hurdles are positioning themselves to derive similar benefits, albeit on a smaller scale to those obtained by commercial software companies operating in the open market. Future work will undertake further empirical studies, at large financial institutions, of Software Product Line adoption to more closely identify the hurdles to adoption as well as refining the solutions and enablers to overcome them. Approaches to be employed will focus on identifying and formalising points of commonality and variability during requirements modeling and engineering. 167167 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 8. ANZ Bank 2 Reference commercial s/w company Company strategy SPLP is an IT response to the business strategy demanding variants of IT systems. Business product supporting a business strategy incorporates SPLP based IT. This approach ensures access to clients outside of the corporate boundary. Core organisational strategy to develop software product deployable at multiple clients and markets, from core assets. Organisation structure IT General Manager of all Product Lines, to whom Product Line managers report. Product Line Councils govern scope. General Manager of IT Product supporting a business product line and relying on SPLP concepts. Product manager at general manager level. Product line architecture compliance responsibility of CTO. Funding model Seed investment from primary business unit. Per-use charging model being implemented. Investment from founding partners, together with shared risk / reward model for added products. JV Capital raising phase and arms- length responsibility for ROI thereafter. Table 1 Enablers compared for different organisations In addition, economic models and methods to motivate a view of software as an asset based on traditional valuation models, as used for physical assets that exhibit features of an upfront investment, compulsory charges for those making use of the asset, ongoing maintenance costs and depreciation over the life of the asset will be investigated. The presence of service oriented architectures must also be factored into approaches and a conception of Service Line Practices introduced with their attendant implications and shift in thinking. 6. References [1] Pohl, K.; Böckle, G.; van der Linden, F., Software Product Line Engineering, Springer, 2005. [2] Clements, P.; Northrop, L., Software Product Lines, Addison-Wesley, 2001. [3] Kircher M. Schwanninger C. Groher I., Transitioning to a Software Product Family Approach – Challenges and Best Practices 10th International Software Product Line Conference (SPLC’06), IEEE, 2006, Pages: 9 pp. [4] Krueger C., Eliminating the Adoption Barrier IEEE Software July/August 2002, pp. 29-31 [5] Schmid K. Verlage M., The Economic Impact of Product Line Adoption and Evolution IEEE Software July/August 2002, pp. 50-57 [6] Jeong Ah Kim, Case Study of Product Line Engineering in Insurance Company IEEE International Conference on Information Reuse and Integration, 2006, pp. 303-306 [7] Jaktman C. B., The Influence of Organisational Factors on the Success and Quality of a Product Line Architecture IEEE Australian Software Engineering Conference, 1998. IEEE, 1998, pp. 2-11 [8] Krueger C. W., The 3-Tiered Methodology: Pragmatic Insights from New Generation Software Product Lines 11th International Software Product Line Conference (SPLC’07), IEEE, 2007 [9] Nóbrega, J.P. Santana de Almeida1, E. Meira, S.R.L., A Cost Framework Specification for Software Product Lines Scenarios WDBC Dec 2006 - Workshop de Desenvolvimento Baseado em Componentes, Sociedade Brasileira de Computa, 2006 http://wdbc2006.cesar.org.br/wp-content/uploads/23948.pdf [10] van Zyl, J., Product Line Architecture and the Separation of Concerns Second International Conference Software Product Lines, SPLC2, 2002. published as Proceedings Series: Lecture Notes in Computer Science, Vol. 2379 Chastek, G. J. (Ed.), Springer, 2002, pp. 83-119 [11] COVAMOF: Variability Management in Software Product Families, A Plug-in for Microsoft Visual Studio .NET http://www.covamof.com/index.php/introduction [12] Business Motivation Model http://www.businessrulesgroup.org/bmm.shtml http://www.omg.org/technology/documents/bms_spec_catalo g.htm [13] Gomaa, H., Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley, 2005 [14] Murphy, T., Achieving Business Value from Technology: A Practical Guide for Today’s Executive, Gartner Press - John Wiley & Sons Inc., 2002 [15] Böckle, G. Clements, P. McGregor, J. D. Muthig, D. Schmid, K., Calculating ROI for Software Product Lines IEEE Software May/June, IEEE 2004, pp. 23-31 [16] Yoshimura, K. Ganesan, D Muthing, D., Defining a strategy to introduce a software product line using existing embedded systems 6th ACM & IEEE International conference on Embedded software, IEEE 2006, pp. 63-72 168168 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.
- 9. [17] Clements, P., McGregor, J.D. and Cohen, S.G., The Structured Intuitive Model for Product Line Economics (SIMPLE) Technical Report CMU/SEI-2005-TR-003, February 2005 [18] Ganesan, D Knodel, J. Kolb, R. Haury, U. Meier G., Comparing Costs and Benefits of Different Test Strategies for Software Product Line: A Study from Testo AG 11th International Software Product Line Conference (SPLC’07), IEEE, 2007 [19] Bosch, J., On the Development of Software Product- Family Components Second International Conference Software Product Lines, SPLC2, 2002. published as Proceedings Series: Lecture Notes in Computer Science, Vol. 2379 Chastek, G. J. (Ed.), Springer, 2002, pp. 146-164 169169 Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.