This document discusses research conducted by SystemicLogic on implementing product line concepts in large banks. The researchers found that while product line practices developed by SEI/CMU were relevant, a move toward "service lines" was needed to address banks' delivery of financial services through software. Key challenges identified in applying product line approaches included banks' huge invested infrastructures organized around traditional product silos, complex legacy systems, and skeptical perceptions of theoretical concepts. The researchers concluded the term "product" has different meanings, and a service line concept aligned better with banks' delivery of financial services through continually updated software processes and channels rather than discrete software products.

1. Product Line Implementation Experiences in Large Banks: Towards Service
Line Orientation
Dr. Jay van Zyl, Martin Krsek
SystemicLogic Research Institute, South Africa & Australia
jay@systemiclogic.com, martin@systemiclogic.com.au
Abstract
Product Line concepts are widely used and
adopted as Product Line Practices. The SEI/CMU has
developed, together with a global community, a body
of knowledge that encompasses a set of practices and
patterns, that are used for software related product
lines. How relevant are these practices to large
financial services organizations that construct service
oriented platforms? This paper presents some
conceptual findings from research studies and
implementation projects undertaken by SystemicLogic
in South-African and Australian banks and insurance
companies. We reason that a move towards Service
Lines is needed to capture the benefits in service and
more dynamic industries that do not develop software
systems for deployment, but software for delivering
on-demand process automation capability. The
service line concept is outlined and some of the
benefits and challenges discussed. The overall
objective of this paper is to present some of the
reasoning behind the development of service line
practices.
1. Context and Introduction
Product line practices as a concept is used in many
forms by organizations around the world. Product
managers in fast moving consumer goods related
organizations 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.
Service related industries have traditionally copied
most of this learning and applied it in hybrid form.
This report relates to one specific type of service firm,
the financial services business. Our experiences
started in 1994 as researchers trying to find the next
product cycle to deliver products to financial services
related organizations. One thing became apparent in
that banking technology and the integration with the
financial services product is not as clean as it seems
from the outside. The development of the strategic
product development framework [1,9] was our
introduction into the product line world.
The concepts presented here are about our research
and implementation initiatives between 2003 and
2007. We have done projects in four large banks
across two countries, South Africa and Australia. The
customer projects were with banks that have six
million or more customers and a total information
technology budget of more than US$ 1.0 billion each.
Research presented in this paper was funded by the
SystemicLogic Research Institute together with our
key clients.
2. General approach and research
background
Various methods were used to perform the research
projects that will be referenced in this paper. One
primary method is the overarching process that was
used to validate all findings.
Since the size of the sample is small, we needed to
approach the research from a qualitative perspective.
Firstly, nine organizations participated with
SystemicLogic in research, secondly the qualitative
approach revolved around in-depth interviews where
the researcher was a product line practitioner,
interviewing senior people in these organizations. We
executed product line related projects in four of these
organizations, where the results were also used to
formulate our findings.
Further investigative interviews were conducted in
Sydney and Melbourne, Australia, and Cape Town
and Johannesburg, South Africa. There were two
major rounds of interviews with various people in

2. these organizations on their views and perceptions of
using product line related concepts.
Our overall intent of the interviews were to:
 Determine the general perceptions in
organizational units toward using PLP
(Product Line Practices) as developed by
the SEI/CMU.
 Determine if PLP concept can be used in
its original form. Can the Product Line
Practices be used in their original form in
these financial organizations?
We are actively researching new implementation
approaches and practices to suit the global financial
services markets. Further empirical work is underway
across a number organizations.
2. Challenges in banks when using product
line concepts
Before any PLP initiative was kicked-off we
conducted in-depth interviews to determine the
general perception and attitude towards the concepts.
This process revealed some specific challenges that
need highlighting:
 Reducing duplicate infrastructure – Banks
have huge investments in large and
complex infrastructure. Much of the
infrastructure mirrors the traditional
product silos in banks – current/savings
accounts, mortgage lending, credit card
products, and wealth management
products. There are between 250 and 400
financial products sold by these large
organizations.
 Reducing maintenance and development
costs – old systems and the use of
complex and modified packaged software
products.
 Simplify channel technology – Banks
deploy their banking products (sold as a
service) across many electronic and
physical channels [12] for example
internet banking, automated teller
machines, branches, various
intermediaries and mobile phones.
 Managing portfolio of projects across
many different types of assets – The more
project oriented cultures of banks force
behavior away from strategic re-use and
into more tactical decision making.
 Organizational appetite for implementing
changes required by a product line
approach is limited. This includes the
ability of the culture to allow these
changes to be proliferated.
 Merging existing practices existent in
banks with those described in product-
line related literature.
Overall perceptions of using a product line
approach to reduce costs and the move towards
assembling systems based on user requirements, were
received with great skepticism. A typical information
technology support team for a large bank would range
from nine hundred to eight thousand people. People
directly involved with producing new requirements
based on user requirements would account for about
20% of the total staffing.
All banks have product teams. But “product” in
this context refers to business related products and
typically not technology related products. What
complicates the role of product is that banks actually
sell financial service products, and not products in the
traditional sense. It seems that the proliferation of the
Rational Unified Process, other IBM related process
products and consulting vendor methods, have created
a major focus away from the more “academic”
approaches like PLP.
Banks do not typically use intellectual property
protection schemes such as patents. None of the banks
interviewed used any form of patent process. This
affects the industry as a whole and drives a more
competitive landscape where copying or “fast
following” is seen as a viable competitive strategy.
The emergence of “customer and client focus” as a
viable long term strategy can be questioned in that the
copying process is well entrenched in modern banks.
The ability to respond quickly to a competitor’s
“fast following” strategies is to ensure that the product
line invention process can execute at the speed of
business change. This leans towards the separation of
business concept and financial services products, and
underlying technology [2]. In most instances the
financial institution is highly dependent on the
success of the technology, more so than the
dependence on the business concept.
3. General perceptions towards product
line concepts
Banks have been using consultants and theoretical
approaches for many years. Seventy percent of the
banks in South Africa and Australia are scarred

3. through the use of consultants and academic
approaches to solve their practical and pressing
problems. This creates a challenge for new and up-
and-coming concepts to take a foothold in these
organizations. Often a non-traditional competitor /
market entrant will introduce a new concept which
then triggers the mainstream banks to respond with a
defensive, me-too strategy.
Commercial research organizations for example
Gartner Group, Corporate Executive Board and
Forrester Research hardly ever refer to the product
line concepts in their commercial research outputs.
Early findings show that less than 5% of comments on
strategic re-use, assembly, asset management, etc. use
PLP as a possible solution.
Some specific common perceptions revealed:
 Software Product Lines is not the
problem, the issue is with large integrated
business systems that include process,
product, technology and people aspects.
 The current body of knowledge is
primarily focused on military, electronics,
and academic related interests. This
creates suspicion of the relevance to
financial services related organizations.
 Examples and cases refer to smaller and
simplified implementation projects that do
not match the scale and complexity found
in banking related organizations.
 Most (60%) of banks did not even follow
or could not relate to the current PLP
movement.
 For those companies who looked at the
existing product line practices, questioned
the adoption due to the large degree of
overlap between their existing
understanding of the concept and what has
already been implemented through other
methods.
We’ve found that our research process mostly became
an educational initiative, where most banks wanted
more information about their specific situations.
4. Towards a service line practice
The one common theme of discussion that raised
its head as we progressed through this research
initiative, is that the term “product” can be described
(and is understood) by different people in different
ways. With movements towards Service Oriented
Architectures (SOA) and Business Process
Management (BPM) [5,6], it became very difficult to
separate the various commercial movements from the
product line initiative.
The promise of systematic and course grained re-
use was well sold by IBM, Microsoft, SAP, Oracle
and other commercial vendors. This made the more
academic approaches very difficult to introduce. We
changed our approach and progressed our discussions
in the second major round of interviews and research
cycle, into finding another way to bring together three
concepts namely; Service Orientation, Process
Management and Product Lines.
Meta-Service Process
Product Line Practices
SOA BPM
Service Line
Practices
Figure 1: Conceptual view.
One aspect that will be discussed in this paper is
the Meta-Service Process. We are currently in a
process of defining an overall meta structure that be
used to simplify the adoption and implementation of
the service line approach.
Service Line Practices as a concept was created by
tying together all the benefits of these initiatives. In
using this approach, the following conclusions were
drawn:
 An overall conceptual framework needs to
be created whereby the service oriented
commercial firm can feel comfortable that
the practical issues are dealt with in the
context of their existing initiatives.
 Implications of using various related
methods need to be unpacked and used to
determine what a service line practice
would contain.
 Implementation implications need to be
researched and used to describe a series of
patterns of using BPM, SOA and PLP.
 Overall, financial services related
organizations are on a drive to reduce
their IT cost infrastructure and to increase
their delivery throughput. Can the

4. combination of these concepts deliver on
this elusive goal?
4.1. Service line practice characteristics
Product lines are based on the principle of having a
defined product, market, assets and other concepts
that all operate together [3].
A service line can be defined as: set of processes,
products, people, technologies and other physical
assets (e.g. non technical channels such as branches)
needed to present a uniform offering to a specific
market, where the offering encapsulates all aspects of
a service experience through a channel delivery
mechanism or indeed multiple mechanisms, whilst
providing consistency in the experience.
Service lines are used by banks,
telecommunication providers, and other service
product oriented organizations. In service
organizations where the product is a non-consumable
resource, the value of a product line is hidden in the
ability of the firm to capture more value in its use.
The service line becomes the vehicle whereby value is
extracted by executing more transactions or by
delivering better customer service over a well defined
and technically reusable product line. The service line
is the vehicle whereby value is extracted from well
defined and technically reusable product lines, by
executing more transactions and by delivering better
customer service over them.
4.1.1. Service Processes. Processes describe the ways
in which services are delivered to customers. These
processes can describe the automated components,
technology assisted components and finally the
manual actions that are performed by humans.
4.1.2. Service Products. Some aspects of the service
are described in the same way as physical products.
Features, advantages and benefits are defined in the
same way. In some cases physical packaging is used
to “package” the service to make it more tangible.
4.1.3. Service People. If the service includes a human
component, then people need to be managed similar
to service assets in order to deliver the appropriate
level of service quality.
4.1.4. Service Technology. Technology components
are used together with processes, products, and people
to complete the offering.
4.1.5 Service Physical Assets. Common physical
assets that may be used to deliver, or facilitate the
delivery of the service offering.
4.2. Service line practice key development
areas
Service lines are different to traditional products in
that they describe non-consumable goods. Some
aspects of traditional product thinking apply for
example; describing the product concept, developing
the product concept, describing launch characteristics
of the product. Service lines utilize common
infrastructure that is not supplied to customers the
same way as physical products. Consider a credit card
product from a financial services provider (as an
example); the customer never consumes the product,
but only accesses the services that the product
provides.
Customer Channel Process Service
Interface
Feature /
Function
Data /
Technology
BPM
SOA
PLPBanking
Assets
SLP
Figure 2: Bringing PLP, SLP, SOA and BPM
together.
In the above diagram the banking assets comprise
the bank’s core technology infrastructure, including
hardware, base software and packages, which are
assembled using traditional PLP. SOA entails the
definition of the technical services and their interfaces
(as patterns), excluding how they are specifically
implemented [12]; it includes patterns which define
how services can be consumed either by process
components such as instances of workflow, or by
banking channels or other orchestration mechanisms.
BPM covers the specifics of the assembling of
software components and manual procedures into
process flows enabling the end-to-end execution of
processes.
SLP (Service Line Practices), on the other hand,
concerns the customers’ experience of a service line:
as recipients of the “content” of the underlying
product line. As indicated in figure 2, the overall
objective is to separate the product line thinking
through the definition, design and delivery stages

5. from the evolutionary characteristics of the service
line.
Service Line Practices are required to provide the
content needed to be delivered over the product lines.
In a banking scenario it is not about the re-usability of
the various components or services in the overall
technical architecture, but how various types of
banking products (financial services) are provided
over this common architecture. This leads to a service
line architecture that is the connection between the
conceptual business view and the implementation
view.
4.2.1. Separation continuum. Key concerns need to
be separated [1] in order to obtain a conceptual view
of how all related concepts integrate. Previous
research revealed that separating the customer focus
and front-office related activities from the back-office
activities, present many opportunities in constructing
a more responsive business. The ability to respond to
new strategies, trends and customer requirement
changes is increased.
4.2.2. Service Oriented Architecture. SOA as a
conceptual framework for new systems development
and integration is well underway in most financial
services organizations. One key premise is that
business functionality can be delivered in a more
loosely-coupled way. The service line can be
constructed by capturing the value in the ability to
rapidly reconfigure a product line through service
oriented implementations.
4.2.3. Business Process Management. The last
frontier of productivity improvements are seen in the
realm of process automation. It is the final move
towards removing humans from complex often
repeated processes to focus on the more relationship
related and exception handling activities.
5. Business and technology service line
landscape
A service line delivery roadmap is needed whereby
service line practices can be integrated with product
line practices. There also needs to be a move towards
more relevant measures that relate to the value of the
service line.
5.1.1. Service line delivery. The service line
delivery roadmap needs to be supported by a
migration framework that can assist the practitioner
with transformation. Transforming towards a service
line approach requires firstly for a target landscape to
be defined, secondly for the context of transformation,
and thirdly for the key decision criteria with regards
to the ability to determine what the start point would
be. The intellectual property (IP) developed by the
SEI/CMU PLP team is well adopted in a number of
markets. The Service Line approach is dependent on
the development of IP and the provision of IP from
banking specialists.
Mass market’s
understanding of IP and
content
A B
C
Dynamic
relationships
and content
links (PACS)
SLP related to PLP concepts
More static
links and
relationships
(PACC)
Content providers and IP
generators
Figure 3: Service Line Delivery view.
Predictable Assembly from Certifiable
Components [7] is used to describe the technical and
software related components. Predictable Assembly
from Certifiable Services [4] is used to describe the
more dynamic world of services, i.e. both the
technical infrastructure and the content that is used to
deliver Service Lines to customers.
5.1.2. Service line measurement. Typically the
measures used in a product line approach will include
[8]; re-use rate, productivity increase, variation across
different customers, etc. These measures are mostly
focused on the software product lines that underpin
the organizations business model.
Service line measures need to be separate to, but
integrated with, the product line measures. Measures
in this approach can include; number of service lines
supported by product lines, number of customer
variations reflected in the service line utilizing
common product line infrastructure, etc.
This particular area requires more research as the
service line concept develops.
6. Comments on the future of product line
practices in financial services organizations

6. Service lines as a concept is the direct result of
feedback and comments from large financial
institutions. There needs to be a more contextual view
on how business is conducted in service oriented
organizations, so some issues with regards to product
line adoption need to be taken into account:
 Slow adoption due to the complexity of
the environment.
 Scale of investment required to implement
core asset concepts, product line thinking,
processes, etc is an obstacle.
 Measurement and core financial benefits
are not fully developed for financial
services related organizations.
 Organizational structures don’t reflect the
kinds of changes required to implement
concepts.
Overall we’ve found that the product line practices
are relevant to large financial services organizations,
but that the current decision making processes and
slow moving cultures, present major obstacles. A
move towards a bridging concept, such as service line
practice, could be the answer. Our ongoing research in
this field should reveal the pathways that can be used
to get to a more course-grained and disciplined re-use
based information technology environment.
7. Conclusion
This research initiative, Towards a Service Line
Orientation, has delivered some early results that
underpin the discussions in this paper. Another
research initiative, Built to Thrive, is delivering some
of the innovation related outputs that will assist in the
business models and other macro process related
changes requires by service lines.
The PLP SEI/CMU initiative [11] has produced a
significant body of knowledge [9] in our drive
towards understanding software product lines. It
uncovered some of the key concepts needed to enable
coarse grained, market relevant development
initiatives. Service lines can be seen as a parallel
development for the movement towards service
orientation for service related industries.
We are in the process of deploying and developing
the next generation of thinking of the concepts. A
method of deploying the concepts, which was not
covered in this paper, is the use of design teams that
bridge the gap between architecture and infrastructure
development. These teams focus on capturing the
variabilities with regards to service line requirements,
and guide the product line, SOA and BPM
developments in a direction where ongoing service
delivery is optimized.
10. References
[1] van Zyl J., Walker A.J., Strategic Product
Development, SPLC 2000.
[2] Van Zyl. J., Product Line Architecture and the
Separation of Concerns. Lecture Notes in Computer
Science. Berlin. 2002, pp91-109.
[3] SEI/CMU, Product Line Practice Body of
Knowledge, Web last visited: 8 March 2008:
http://www.sei.cmu.edu/productlines/
[4] Research on PACA done at the University Pretoria
(Can be considered a technical reference document as
opposed to a standard journal paper).
[5] Krsek M., “BPM”, Unpublished SystemicLogic
Research Institute Report. 2006.
[6] Krsek M., “BPO”, Unpublished SystemicLogic
Research Institute Report. 2006.
[7] Wallnau K.C., Predictable Assembly from
Certifiable Components, SEI/CMU Web.
[8] Clark K.B. and Fujimoto T.. “Product
development performance: Strategy, organisation, and
management in the world of auto industry”. Harvard
Business School Press, 1991.
[9] Tiley H., Walker AJ., Empirical Study of
Implementing Product Line Practices in a Software-
Producing Organisation, SAICSIT, 2002.
[10] SEI/CMU, Domain analysis, Web last visited: 8
March 2008.
http://www.sei.cmu.edu/productlines/frame_report/rel
_domains.htm
[11] P. Clements, L. M. Northrop, et al. A Framework
for Software Product Line Practice, version 4.2.
Technical Report. SEI Carnegie Mellon University,
Pittsburgh, 2004.
[12] Capilla, R. and N. Yasemin Topaloglu. “Product
Lines for Supporting the Composition and Evolution
of Service Oriented Applications.” Proceedings of the
Eighth International Workshop on Principles of
Software Evolution, 2005, pp. 53-56.