Sei sulla pagina 1di 4

sqs.

com

Case Study banking & financial services

Building a Single Dealer Platform


Using Agile methodology in a highly regulated financial services environment

The Background
The bank is a Tier 1 global investment bank providing a range
of securities products to its client base in the US, EMEA (Europe,
Middle East and Africa) and APAC (Asia Pacific). The bank
operates in a highly regulated environment and provided its
securities products over a number independent desktop and
web applications.
The existing applications were feature-rich themselves and
each had a strong market position, but they were built on
varying technology platforms by different teams with limited
integration options and had an inconsistent look and feel.
In most cases clients had to utilise different user name and
passwords to access the individual applications. The legacy
and disparate technology platforms made it more difficult to
embrace modern client requirements such as mobile, social
and search. This obviously led to a less than optimal user
experience for clients and a significant and continued financial
investment in supporting the legacy applications. Across the
industry a number of the banks competitors had already
consolidated their client offerings under a single platform
or a single brand and the bank risked being left behind.

The bank made a strategic decision to build a unified crossasset single dealer platform rather than continue to maintain
the legacy applications. The business driver was to leapfrog the
competition rather than another me too offering. All budgets
would be funnelled into a single platform with the eventual
goal of replacing all of the legacy applications in a very short
timeframe. The new platform would be designed from Day 1 to
work consistently across all devices (desktop, web, tablet and
mobile) and to embrace the unique features offered by each
device. The platform would provide research, market pricing,
pre-trade, trade and post-trade across all securities products.
It would also embrace modern collaboration tools such as
social media, integrated chat, conference, authoring and
publishing as well as powerful search capabilities.
Market and regulatory demands meant that it was necessary
to continue to make minor feature updates to the legacy
applications while the new platform was under development.
Thus time to market was a critical success factor for this
programme to avoid having to build new features twice. Due
to the significant investment and multiple senior stakeholders
from the investment bank, it was necessary to be transparent
and demonstrate progress quickly and frequently.

All of this meant that the decision was made to build this
in-house using an Agile development methodology (Scrum).
As the bank had limited experience of Agile methodologies,
a new cross-functional team of highly skilled employees and
consultants was carefully selected for this programme.

Challenge

24 h

2 Weeks

Product backlog

Sprint backlog

Sprint

Working increment
of the software

Figure 1: Agile delivery methodology

The Solution
Scrum training and Scrum Masters were rolled out across the
programme and a Hub and Spoke model of delivery teams was
created. The shared or core functionality was built at the Hub/
Platform level. This was about 75% of total functionality. Each
Spoke team would then take the core functionality and customise
it for their product (e.g. FX vs. Equities).
Depending on the features in flight, the Scrum teams would
flex from 10-20 cross-functional Scrum teams working in 2
week sprints. The teams were reconfigured constantly to cater
for the type of resources needed for the feature stories in the
sprint backlog.

1 x Product Manager operated as the main contact with


business users and decided on and prioritised the user
stories for sprints.
2 x UX (User Experience) Engineers Information Architect
and Graphical Designer responsible for the design of the
user experience.
5 x Developers UI and server side developers responsible
for coding and unit testing.
1 x Scrum Master selected from the quality assurance
or development side of the project and responsible for
eliminating the sprint roadblocks and making sure the Agile
methodology was implemented correctly in the teams.
2 x QAs/Testers responsible for acceptance testing.
Generally, 1 for UI (user interface) and 1 for back end
testing. They were also responsible for execution of the
exploratory testing.
Historically the bank would typically deploy a major upgrade
release to production once per quarter due to the legacy infrastructure. Once this programme had fully ramped up, they were
deploying up to 60 releases per week to production, each one
a small incremental change or bug-fix. Large features or infrastructure upgrades were deployed once per month as these
often required system downtime.
Week 1
Release 160

Q1 Release 1

Q2 Release 2

Q3 Release 3

Q4 Release 4

New System Development


60 releases/week

Another significant challenge was a feature-rich MVP (minimum


viable product) and a very aggressive release schedule. The
goal was to build enough functionality on the new platform so
that they could stop maintaining the legacy systems and begin
migrating internal users and external clients.

Each cross-functional Scrum team included the following roles:

Legacy System Development


1 year / 4 releases

The primary challenge for this programme was the limited


experience in-house of using Agile methodologies on large
scale programmes such as this. This meant that external
consultants were brought in to help define the organisational
structure, strategy and governance, education, awareness
and delivery pods. It was also necessary to define the roles
and responsibilities in this new Agile structure, especially with
regard to risk, compliance, security, architecture and other
enterprise functions.

Week 2
Release 60120
...

...

...
Week 156
Release 93009360

Figure 2: Scaling deployments to production

Teams were initially co-located in the same building, but as the


project progressed the team was globalised. The Agile process
matured over time to accommodate the globally dispersed teams.
Dedicated teams were responsible for managing the deployment
of the releases into development and test environments. There
were 15 development environments used for coding and unit
testing and an additional QA integrated environment used for QA
testing of the functionality delivered from different Scrum teams.

DEV env. 1

QA
Integrated
environment

Tool Name

Tool Utilisation

Version One

Overall Agile project


management / ALM

HP Quality Centre

Test management

TeamCity

Continuous integration

GitHub

Version control system

RiaTest, other open source


test automation tools and
a custom built automation
framework

Test automation

DEV env. 2
DEV env. 3

VersionOne

DEV env. 4
DEV env. ...
DEV env. 15

Figure 3: Environments overview

The project used a dedicated team to design and complete


the automation testing and also a separate team was used
for non-functional testing that included performance and
security testing. Testing of the project consisted of 80%-90%
automation coverage and this significantly increased the quality
of the code delivery and reduced the amount of manual testing
required. A subset of the automation tests were also run in
production as automated health checks, every hour on the
hour. This further increased the ROI (return on investment)
from automation.
Acceptance tests were added to each story in the ALM
(Application Lifecycle Management) tool VersionOne and then
these were imported into the central test management tool,
HP Quality Centre, for regression testing purposes. All tests
were automated and scheduled through HP QC so that all
test results and test evidence were centrally tracked for audit
purposes.
A number of bespoke and specialist tools were deployed across
the organisation. These were chained together where possible
to provide an end-to-end solution.
The primary tool utilised for overall Agile project management
was VersionOne. This was supported by HP Quality Centre,
which was used for test management. TeamCity was applied
for continuous integration and GitHub was the distributed
version control system tool employed. The main tool for
test automation was RIATest and this was also supported by
other open source test automation tools and a custom built
automation framework.

PMO

UX

DEV

QA

Support

HP Quality
Centre

Automation
Framework

RIA Test

Team City

GitHub

Figure 4: Integrated toolchain

A PMO (Project Management Office) oversaw the end-to-end


programme. This team was responsible for tracking progress
across the vast programme against committed goals and
providing transparency to the multiple stakeholders. The PMO
team also worked with finance to govern spend against budgets.

Benefits for the customer


The success of this programme was widely recognised across
the financial industry, as the Single Dealer Platform won multiple
awards including One To Watch, Best Platform and Best
Navigation, among others. The platform itself delivered numerous
benefits to the bank and to its customers with billions of euros
flowing through the platform daily. The bank benefited from a
significant de-deduplication of effort through a lot of reusable
assets, services and processes that were rolled out across the
company. The customers benefited from a fully customisable
user experience, the ability to trade all asset classes seamlessly
and access to expert research, sales and trading professionals
at the click of a button.
SQS consultants were heavily involved in all phases of the
programme from inception to building out the infrastructure,
go-live and migrating clients to the new platform. This involved
long days and weekend work to ensure the project was
delivered on time and to minimise the impact on customers.

SQS consultants provided unique expertise to help define the


QA/Test strategy and governance particularly in this complex
environment. The following were the main initiatives SQS consultants were responsible for:
Building out a highly skilled QA/Test team in a short timeframe with the right level of experience in the domain of
complex financial services
Management of QA/Test within each Scrum and across the
Scrum of Scrums
Embedding technical testers in each Scrum team from
beginning to end
Delivery of the platform-wide test strategy
Provision of multi-vendor QA governance
Delivery of the enterprise mobile QA strategy
Implementation and completion of the automation framework for Adobe Flex, HTML5 and mobile products
Delivery of the performance, security and resilience test
strategy across all of the new technologies introduced and
the build-out of infrastructure across US, EMEA and APAC
Identifying and gaining sign-off on the acceptance criteria
for the user stories
Planning, designing, managing and executing the user experience, compatibility, security, automation, performance,
manual UI, manual back-end and exploratory testing for the
project
Providing transparency to all stakeholders on the status and
overall quality of the platform and its readiness for launch
QA governance

SQS consultants helped to deliver the programme on schedule


and the methodology was rolled out across the bank.

Conclusion
The outcomes of this project generated significant benefits that
improved the customers business. Some of the major benefits
were:
The decommissioning of multiple legacy IT systems. This
caused huge cost reductions and reduced production
support needed in the long run as a result of having one
integrated system instead of multiple separate applications.
Rolling out the Agile framework across the enterprise
increased the flexibility and agility of the teams to faster implement the continuously changing business requirements.
This enabled quick time to market for the organisation.
Automated regression testing reduced the maintenance
cost, accelerated product delivery and increased product
quality.
The project was completed on schedule and during this time
it managed to entirely transform the IT department processes
and the mindset of the business units within the organisation.
It enabled the company to strengthen its competitiveness in
the continuously changing marketplace.
The award winning platform goes from strength to strength
and continues to evolve to stay ahead of the competition. The
journey continues

Updates on status, overall quality and


readiness for launch
Platform wide test strategy
Enterprise mobile test strategy
Performance, security, resilience test strategy
Test automation framework

Release

Multi vendor governance

In addition the QA team was also involved across the project


lifecycle in matters such as: user design planning sessions, story
planning, release planning, game/sprint planning, reporting of
results, sign-offs, go/no go decisions, retrospective meetings,
etc.

Contact

Embed technical testers in each Scrum team


Acceptance criteria for the user stories

If you are interested in SQS and our Agile services please


send an e-mail to info@sqs.com or visit sqs.com

UX, compatibility, security, automation, performance,


manual UI, manual back-end and exploratory testing

Governance

Strategy

Delivery

Figure 5: QA delivery dramework

SQS the worlds leading specialist in software quality

Potrebbero piacerti anche