Tech Spark 7 - DevOps Issue

Faster, Cheaper, Better.

TECH SPARK

Innovation @ Pace

TECH SPARK | 1

ALE

SC

TY

&

FL

E

XI

BI

LI

A

E

D

UN

N

MA

PE

C

AP

R RFO

I ONT

T

T E EN I F I

RI

P ER

TE

CE

US

O NU

DR

ION

E CONTINUOUS IN CTURDE FAASSTER VALUE DTEGRA ITE AS CPOABLE & REVLEEREY DELI ELIVETION F E ATURVERY RY CH RE G SHIPOUS DELI AR CTUSTAYINNTINU FRASTRUCTURE AS CODE BA E FLAPIPE

SYSTE M

CA PLI

VALUE THIN STR KIN EA G M

N

RU CO IN LICATION RESILENCY F TCH GS LINE L O ST U A APP Q L SIZ W I T S E COLLECT Y ME NCE ME ING UE E I T V S E NG ST S OW TR RICS FID TEAM BT MAN E NT COTNIONAL AL DDEBACK LOOAPGS EMENNERIS CS TY UNC NIC FEE ADERS HIP T HIP F H & LE

TY T & TESTINMET ESTT G RI I

S

TURE STRUC FRA

E

S MENT IRE QU RE

G

IN FIED BACKLO G UNI

NT IME NT R PE ME EX AGE

TU

REQ CU RA UIR RIT EM Y T E

ST STRU IN CTU G RE RE COL EM E NC S LEC ER Y FL AL O YI A B W M INFRA TIVE OGEN NG L WNE T S PE E SH E AR RF TR T R U C T RSH AR A O I URE RM I C BAT PP CH PPLIC IP CH TI CH ABLE ITE ATION ANCES RES AS C O C T U DR I O T BAT IT L D N & E V E AP G STI E RE RE VEN I N CH E L S N G I E F P NFR TE L RAS ASE QU TRU L A I S C A TRUC CH CA E S C T TURE COLCL ON URE EME LITY FAST ARN IZE NIC TIO AS C ECTIVTIN RGEN CO ER AL N D ODE E OW UO T AR NF V PRA RI CH NE U I ITE RS S CTI VEN H CT IP D C CES UST EL UR I FLE NFR AS OM XIB ILI TRU C TY & S TUR CAL E E I E

ECNG

&

ES

USELEARN R EN &

OV INN IMENT & TECHNI D C E A L D IMP E BT

ENT M GE A AN

CS

TIC

D VE TE IS PERFORMANCE ST S PROCESS EFFECT TEST I IVEN IN IMPEDIME ESS &G QU RISK TAKIN NT CRO ALI G & SS AGILI

IV

VE

M

SIZE

S

OL

WO

PROCESS EFFECT TEST IVEN IN G E

IMPEDI E SS & QU E C A RISK TAKIM NGNT & ROSS LI

VALUE THIN S K T R EAING M

E NC DE

RIVEN INFRASTRUCTURE D N ATIO PRACTICES FLEXIBILITY EM C I & S ER CAL CTURES FLOW PL C T AP CHNI ARCHITEBILITY SECURITY TMEE GE STINRICS ALE E A E L E A C T G I I L O N MONIT T ALAB TRACMS APP AU R I TESTABLE ORING SETOMATEESOL NF NT SC RK TEA

C C I N EN I P R A T E SIL E T NF T E C H N I C A L CHI E ST G R AST L E A R TIO N R S B C R A A L I R NG A ATIUCTURE APPLIC O QU N A LI BL E

B A E AL C I

G

&

INFRASTRUCT DRIVEN U ION TICES FLEXIB RE E C I A L R I CAT T P Y & ME CTURES FLOW PLI CAL

M

AGILITY M TE T ENT RIM NT & TESTINGET STI RI PE ME EX AGE LABLE SYSTEM

TY

SCA E COD

LI

N ATIO

& ST I N E P E R FOR M AN C T E SYSTEM THINKING

E

IB I

S

V A T TION ION

R FLEX

ES

S

F

AP HNI ARCHITE ITY SECURITY TMETR SCA RG TEC LABLE RACEABILAPPLICATION MONITESTING IACU S R LE I EN T A S B E L T SCA K T TEAMS E ROREING SETOMATEESOLV NFR T Q WOR SIZE PERFORMANCE UICURITD TEESTISS A R E MYT I

E

Y

SC A T

ENT CTUR G R TRU E AS R E S M RA

IN

APPLIC

USELEARN ARCHITEC R E & TU N

LE

E

T

SC A

TIO N

QU B A E AL VE E A L L L O I C B I S I TY C NA K L GNM ONFIDENCE FLEX RE CES BL O G ENT S IC TI I

E

2 | TECH SPARK

E

36 Sprinting to DevOps

T IO

OF S R T AC E FI T NG E R M P T S CA L AB A B CIE W B AL L E A R C H I T ECTUR ES F L O W NIC TY H L I NC AR USI C I LOGY TE R N U N GY & E ESS AGILITY SEC BACKLIT Q C O U I N LLA IED QUA N O BORA ALITY F I N U G

EF N

34 Compliant by Design

S

G

Y SF I R T A IVE R S

M FRAS T E R UCT T UR O RI

32 How Fast Can You Go?

UN

30 DevOps in Machine Learning

CA

FR E N I T MO N I T N DRIVEN I T Y S ORIN G S E C U R C E TU I IV T C I N EN I R A CI T E SIL P L A N C E T E FRA T ECHNI CH ST G R STR UC T S C A L A B L E A R T I O N R IN UR A A N

TE S T AB L

28 Pragmatic Pipelines

LI APPICATIO

26 Moving Beyond DevOps: SRE

DR ON S A TI O U U LIC TE APP T I N E NC CON MA RI RP D F OR PER TE E EN I F I

20 DesOps in Finance

APPL

18 The Rise of the Citizen Developer

RM CS A R EA N C E T ESOL S COD VE E E S T ING Q U ALI T Y CO N FI

16 UCD to Break out of the Monolith

&

E

E

RF

14 Microservices: Friend or Foe

E RUCTUR RAST INF

PE

12 Splitting the ATOM

ME TR ICS

F L OW

06 Continuous Delivery. Are We Nearly There Yet?

NE

F

QUALITY LOW SIZE G E C N E COLLECTIV ME U G TI ENAMS E D N S S I E E T ONFNAL T DEBT MANAGEMOWNTERIC N Y CCTIO CAL EDBACK LOOPS EN RSH S T UN NI FE F H & LEADERSHIP T IP C E NG FIED BACKLO CS G UNI

NC

04 Focus of This Issue

E R TU

ENT EM AG AN

03 Introduction: The DevOps Issue

ST S

LIC APP

& UNIFIED BACKLOG CU STO IPELINE P Y ME R E V RT I L ES DEENT TI M NG IEERY N O I R T A V E V I S EXP DEL INNO ENT & TECHNIC M I D E E E AL & ALU C N DE IMP E B D ACTION G INKIN M TH E T SYS

OFNABL KLOGGNMENT TY CONFIDENCE FLEXI ICS RES I T METR S CA L AB WNG L E A R C H I T ECTUR ES F L O W A R BUSI E Q NESS A ITY U A L ITY GIL

Contents

CONTINUOUS E R ASTER VALU INTEG F U T E D RA C EE & RELEASE D O E C DELI ELIVETION T L B S A I R Y E P V A H UREING SHUIPOUS DELTIURE AS COD FEATURVEERY PRY C ARRUCT STCAOYNTIN INFRASTARTUICON RESILENCYE BATCH FLAGISPELI

The DevOps Issue Financial services is a digitally-intensive industry – it has been for several decades. In the past, clients used to say, “we’re banks, not software companies”, and this drove a lot of short-term decisions and behaviours around digital integration. However, this has left complex legacy technologies and processes that are costly to maintain, delaying the digital transformation of many traditional financial institutions.

For banks to flourish in an increasingly digital world, they need to find fresh ways of embracing digital. And if they want to recruit (and retain) the best digital talent, innovate at pace, compete with new players and remain relevant in a very crowded marketplace, they’re going to have to deepen their CTB pockets.

In a world where cloud technology has become the norm, there are few stumbling blocks to achieving continuous delivery and being able to get from idea to production in a single day.

This edition of Tech Spark looks at innovation in banking technology through the pin-sharp lenses of faster, better, cheaper. Enjoy.

TECH SPARK | 3

The Focus of This Issue...

SEC OPS

This edition of Tech Spark will help you accelerate your move towards enabling innovation at pace, while we answer some of the most challenging questions faced by financial services (FS) clients.

OPERATING MODEL DES OPS MONITOR

DATA OPS

How fast can you go?

Change is complex and costly. Here’s our formalised methodology for deciding what to change first. P34-35 Case study. Compliant by design Last but not least, we wanted to share one of our clients’ transformational journeys. Tackling many of the topics described in this magazine made it a really rewarding project to deliver.

P36

SRE

PIPELINES FEE

CK

PS

TS

LOO

EN

DBA

EM

4 | TECH SPARK

CITIZEN DEVELOPER

UR

Design operations (desops) in finance Design and user experience are key elements in your technology delivery pipeline. In the same way that you’d industrialise development, you need to industrialise user experience. Desops is

Pragmatic continuous-delivery pipelines We brought our SMEs together to formalise their blueprint for CD pipelines.

Here, we’re all about quality gates, parallel pipelines and best practices for delivering faster, better and cheaper. This is how we set-up our projects. P30-31

ARCHITECTURE

AS

Microservices: friend or foe?

Microservices have often been presented as an architectural silver bullet. We don’t agree. The fact is, sometimes microservices can be good and other times, not so good for you. P14-15

Moving beyond devops: site reliability engineering (SRE) Agile and devops go hand-in-hand, enabling continuous delivery to take you from idea to production in a day.

SRE is a set of practices, formalised by Google, which provide further metrics and practices to reach the next level of industrialisation. P26-27

Devops in machine learning As machine learning (ML) goes mainstream and is rolled out as part of an increasing number of applications, we need to stop treating these algorithms as unicorns and bring them into the devops fold. P32-33

ME

Splitting the ATOM (agile target operating model) Setting-up teams and work structures is the launchpad for continuous delivery.

We discuss how modern technology organisations should organise themselves for greater agility and pace. P12-13

The rise of citizen developer models Even with the most agile operating model in place, you’ll need to take a mainstream approach for certain requirements. You’ll still need to innovate on the fringes of your main operating model but without creating “shadow IT”. Models for citizen development enable innovation and experimentation with production data, within a safe sandbox. P18-19

an umbrella term for the best practices you should be employing to measure usage and feed back to your design and user-experience teams. P20-25

Is

UCD to break out the monolith Undecided about whether microservices are the right architectural pattern for you?

Well, here’s why we recommend breaking a monolith into microservices. P16-17

PS

O K LO

BAC D E FE

KP

Continuous delivery. Are we nearly there yet?

How has continuous delivery (CD) affected people, process, tools and architecture, so far? As consultants, we hear excuses as to why “continuous delivery can’t work for us”, all the time. We debunk some of these myths. P6-11

TECH SPARK | 5

Continuous Delivery.

Are We Nearly BANKING There Yet? LEGACY WAY OF Devops has been an area of focus within financial services for several years. So, why hasn’t this translated into continuous delivery?​ There are instances of continuous delivery (CD) in large banks, especially in the front office where teams are used to fixing forward. However, these are exceptions that prove the rule. There are notable cases of companies that

6 | TECH SPARK

are successful beyond the front office, like ING bank, where most application teams release-to-production several times a week. You can choose from several categorisations to gauge the CDreadiness of an organisation – CALMS

framework (culture, automation, lean, measurement and sharing) or Google’s DORA which focuses on technical, process, measurement and cultural (devops research and assessment) dimensions.

DOING THINGS

However, when studying advanced engineering practices such as devops and SRE for financial services, we find the people, processes, tools and architecture categories to be the most effective.

PEOPLE

PROCESS

TOOLESCTURE

ARCHIT

BEHAVE LIKE SOFTWARE COMPANIES TECH SPARK | 7

PEOPLE

OUR

ASSESSMENT

BUSINESS

PROCESS

IDENTIFY AN IDEAL

TOM

D

HAR

5

Working with several financial services organisations over the last 18 months has encouraged us to share the following observations:

IDENTIFY CHAMPIONS

LOOK TO:

CREATE A CULTURE MANIFESTO

REMOVE CULTURE

REDUCE REDUCE COMPLEXITY TOOL NUMBERS

02

03

2 1

MORE TEAMS

1 0

SCREEN TALENT TO FIT CULTURE

CULTURE

ER

0

ARCHITECTURE

Naturally, teams concentrate on the easiest things to change – tools – for which, the focus should be on standardisation and rationalisation.

In other words, cutting the number of tools to reduce complexity and simplify the creation of pipelines aligned to value streams that span multiple teams and applications.

This should be balanced by a “you build it, you run it” approach so that, within limits, teams are free to make their own technology choices.

SecOps

Secops – the integration of security controls within devops pipelines (which has only just become an area of focus for many organisations) – requires tooling extensions and possibly specialist skills. We recommend that clients include this in their delivery pipelines as soon as possible, iteratively expanding the ruleset.

Agile at Scale

Various levels of agile have been adopted throughout the industry. Now, the emphasis is on larger scale (more teams) and more encompassing (users-toops) operating models. Clients must ensure that all teams and components of the application landscape are included in these new ways of working, from user experience to machine learning.

Culture

The cultural change required to establish an environment with continuous learning and experimentation can be slow and painful. The “command and control” regimen and entrenched blame culture that have plagued the industry for years, will require senior sponsorship for change.

Technology Architecture

The architectural changes needed to enable devops have often been underestimated. While it’s possible to implement CD with legacy technology, monolithic applications and software packages which are not devops-enabled can prove challenging. Teams need to work backwards from the desired deployment patterns, to build a backlog of change for implemention.

4

OUR

5

FRIENDLY IS THE

IGNORED

DATA

2

CE G O V E RNAN INTO TECHNOLOGY ACROSS

HOW DEVOPS

OFTEN

TOOLSETS

OUR

2

3

5

DATA SOVEREIGNTY

TODAY LESS

4 DUE TO

REGS

LOW CLOUD MATURITY

5

ASSESSMENT

IDENTIFY KEY

TOOLS 8 | TECH SPARK

IMPROVE QUALITY GATES

0

TTER

DEFINE SLI’S

RETHINK YOUR

3 4

5

0

5

ASSESSMENT

PRE-2008

ASSESSMENT

2

BE

F

3

DEFINE SLO’S

1

1 Standardisation of Tools

3

2 OUR

GENERATE A

CONTINUOUS LEARNING

CONNECT

WHAT DOES GOOD LOOK LIKE

CULTURE CHANGE

STANDARDISATION

4

SERVICES

05 AVOID FEAR OF DOWNTIME

TOOLING EXTENSIONS

5

POLICIES & PEOPLE

TECHNOLOGY USERS AT EVERY LEVEL IN THE ORG

R TE AS

SEC-OPS

04

BENCHMARK YOUR CULTURE

EVANGELISTS

CHEA P

01

2

4 3

5

LEADERSHIP & GOVERNANCE

CRASH

ARCHITECTURE OFTEN IGNORED

TECH SPARK | 9

Some of the Things We Hear...

Clients often say that continuous delivery or a devops-led approach wouldn’t work for them. However, we’ve never met a team, yet, that wouldn’t benefit from “a little devops love”. Much of this sort of resistance can be countered by straightforward mitigation strategies:

This is a common issue for data warehouses, data lakes and risk warehouses. The first iteration should look at the size of the regression test required – how much automated testing do you need to prove that a new version is correct? This will require sign-off from business and operations stakeholders. If full regression tests are required, employing an immutable bus to share source and input data between environments such as Kafka or Pulsar will enable cheaper, like-for-like regression tests.

“We don’t have high enough automated test coverage”

Seemingly, there is little you can do other than stopping all development and focusing on tests for 6 months. However, there are some pragmatic steps you can take. For instance, selecting significant areas of change for test coverage, deconstructing a monolith into high and low change components, or scaling-out your QA function temporarily (outsourcers can really help here).

10 | TECH SPARK

“Our application is a monolith, we can’t deploy bits of it”

The article, “Microservices: Friend or Foe?”, contains strategies for breaking down your monolith into more manageable components.

Discuss this with your operations and testing stakeholders to see what they would feel most comfortable with. It doesn’t make sense to run a full, manual, regression test cycle, if only part of the application has changed and small, quick, automated tests can be run instead.

“Our change approval board (CAB) process and operations teams would never allow it”

This is probably the greatest objection faced by most application teams. It can seem insurmountable without the support or influence of senior decision makers. Discuss any concerns with senior operations, business and QA stakeholders, and then find a way to alleviate them. Introduce the necessary tooling, testing and observability to help them verify that the software is in good working order. The more your

application is operationally fit-for-purpose with minimal overhead, the more their operational teams can focus on other backlog items.

“Our application is a black box. We don’t know what’s happening inside”

Any platform launching today would, more than likely, be architected for observability.

However, this can be retro-fitted into most architectures, through counting and measuring log messages and throughput, perhaps. Or through database activity (being mindful of lock escalation), maybe. In any case, observability is an important facet that should not be ignored.

HAV E

HIG H O EN

“Our dataset is huge; we can’t test it”

WE DON’T

OUR CA

B PR O C E

SS

UG A TION H A U R E P ST /O

ST COVERAGE E T D

TE A M TO

EA M

S W O ULD

N

E EV

R

L AL

OW

IT

“Our application is database-centric, so failed releases are a nightmare”

Deployments, as well as rollbacks, need to be scripted (and checked into source control with the help of a deployment tool like Salt or Ansible) and fire drilled regularly as part of the CI pipeline, possibly. Also, you could introduce a regression table so that v1 and v2 run in parallel for a couple of days.

TECH SPARK | 11

ATOM

Splitting the

GANISATION FS OR PEOPLE (EMPLOYEES)

CULTURE

Agile will be the beating heart of the operation, lowering costs, improving efficiency and maximising performance. Excelian has substantial experience in helping FS organisations craft and deliver an ATOM. Using our deep knowledge and expertise, we tailor the ATOM to match the way each organisation wants to work.

12 | TECH SPARK

● ● ● ● ● ● ● ● ● ●

Attracting senior-level sponsorship from users, business or operations (not just technology) Establishing clearly-defined leadership principles for everyone in the organisation Recruiting and assessing people according to the organisation’s leadership principles Developing a blameless, entrepreneurial culture where failure is considered a learning experience Encouraging experimentation and short feedback loops Considering hybrid methodologies that provide a structured transition to agile (e.g., SAFe, LeSS, etc.)

Using scaled, agile tools to manage backlogs across several feature teams Valuing ownership and accountability over reporting and programme management (carrot, not stick) Aligning architectures, teams and value streams (Conway’s law) Familiarising everyone with the product vision via Design Thinking workshops and then breaking down into value streams

FEAT

URE

E ST

TEAM

CT ODU

REA

PR

M

Customer AGILE (ATOM) Centricity

R

USE

INNOVATION

Businesses are accelerating innovation, becoming truly customer centric with a flexible outlook that makes employees feel part of something special. And as customer needs change, the organisation will be able to adapt to fresh market conditions. Regular reviews and reinventions with continuous learning and fail fast will empower further innovation.

How can we get this off the ground?

LEADERSHIP

VALU

chnology Te

I

n the future, really successful FS organisations will be able to adapt, change and transform at pace. They’ll need to behave like high-performing teams, where hierarchical management (top to bottom) is less relevant to the running of the business. Companies will be reinvented, moving to a more agile target operating model (ATOM).

mer Experience o t s Cu Business

(Agile Target Operating Model)

Financial services companies are accelerating innovation, becoming truly customer centric and adopting new ways of working using different flavours of agile.

RM ATFO

PL

TEAM LAB PTER

GOVERNANCE

A sample ATOM we created

HA UI C

R

R

E OWN

VALUE STREAM A value stream is the encapsulation of all the people, processes and technology involved in a customer’s interaction with your organisation en route to achieving their goal.

FEATURE TEAMS DEFINITION A multidisciplinary team aligned to features. A single team may be responsible for one or more features.

TOOLS USED JIRA: managing and tracking product design and development.

CULTURE Bottom-up innovation, not top-down buy lists.

Architecture aligned by team shape.

WHAT GOOD LOOKS LIKE High-performing team (dev + design + qa + devops) Build and run together (no separate ops team).

CHAPTER TEAMS DEFINITION A community of practitioners covering a specific discipline.

ATTRIBUTES A chapter lead has energy, experience and is organised.

Influence tech buying decisions + culture + processes.

Self-organising teams.

Granularity of chapters is dependent on organisation.

PLATFORM AND SRE TEAMS DEFINITION Delivers the underlying platform to the feature teams including some shared services.

TOOLS USED Cloud infrastructure and associated scripting, container clusters, monitoring and cloud security.

CULTURE Can do attitude and service centric.

WHAT GOOD LOOKS LIKE Infrastructure as code, fully flexible and on-demand with self-service facilities for the feature teams, anticipating demand, quick to provision and short lead times.

APTE

H MS C

TECH SPARK | 13

System Boundary

Microservices: Friend or Foe?

I

SL

O I

SL

I

SL

E2 E AS SLIC E C CAL USVERTI

I SL I I

SL

E1 E AS SLIC E CICAL

US ERT O V

SL Define vertical slices

I

SL

14 | TECH SPARK

● Dependencies can limit the benefit of microservices architecture. If the journeys that users need to achieve are spread across multiple systems and only parts of the system are microservices-based, then that will limit the value of this microservices part, significantly (user journeys can only be as agile and fast as the least agile component of the journey).

I

● Microservices bring scalability.

However, initially, they slow you down. It’s not a good architecture

● Breaking out a monolith only makes sense if you’ve reached certain limits. Have you done an in-depth analysis of your actual limiting factors (“choke points”, as mentioned in the Phoenix project)?

Are there issues around scalability?

Performance? Pace of delivery?

SL

● Microservices bring architectural complexity. You will end up with a distributed system that might mean accepting certain trade-offs like consistency, which could be a transactional challenge.

for experimenting and innovating, so you’d be better off starting with a (well-decoupled and organised) monolith

I

● Microservices introduce executional complexity and you need the right expertise in place to handle it. This is at the infrastructure (containers, service mesh), devops (microservices without automation are pointless) and operating model levels. Microservices without a well thought-out agile operating model are just too complex.

Do you have a stable team committed to developing this project over time and reaping the transformational benefits?

Users

SL

Microservices have often been portrayed as a silver bullet, capable of solving most architecture problems. But there are challenges and complexities associated with them.

Use Case

SL

WHEN MIGHT THIS BE A GOOD IDEA?

SLO/SLIs

SL

Microservices have often been portrayed as the new best-practice architecture because of their inherent qualities – scalability, maintainability, compatibility for agile operating models and devops.

Map Components

YER A L N

OP SKT

DE

TIO A R EG

INT

SY

M STE

RY

Define Tech Stack

B

DA OUN

TECH SPARK | 15

● ●

16 | TECH SPARK

You can still take an automated test or devops approach with the system but everything will be simpler (technology, skills, deployment, operations and testing). Later, you can decide if you want to go with microservices or serverless, or lambda maybe.

Can I test and release in isolation modules, in an automated fashion?

How quickly can I deliver business value?

CE

Are my services user-centred enough?

RV I

You can apply the principles of microservices without distributing them across the network.

If you know the features you want to achieve and can separate them clearly, you can drop them into any framework, module, or container and avoid the microservice “tax”.

SE

At the same time, we need to reflect on the technology stack for these microservices to determine: ● An appropriate framework ● Whether or not we need a service-meshtype solution ● A devops strategy to allow for independent continuous delivery of these microservices ● The migration path and associated architecture workaround which might be needed to create a hybrid architecture (i.e., with legacy services running alongside microservices within the same application – a “hollow-out” approach)

The different microservices needed to deliver these journeys. Scalability, availability and resilience qualities are based on the SLOs or SLIs Service boundaries are defined by reusability as well as SLOs or SLIs Components of the current architecture which need to be rearchitected and reused are included in the microservices.

And then we surround newly identified boundaries with automated tests to allow the rewrite to happen. This ensures the entry points into the services emerge, are available for testing and are switched between old and new when ready.

So, going back to basics is important. Ask yourself a few simple questions like:

RO

●

How about just a good-old modular architecture?

IC

This helps define the microservices as an iterative approach and to figure out the “slices” of architecture needed.

M

From then on, it’s a matter of deconstructing the problem and aligning the architecture by going through:

S

Usually when presented with this problem, our approach is based on user-centred design (UCD) principles – inspired by Martin Fowler’s “strangler pattern”. After listing all the users, we map the different journeys they undertake while using the system (or set of systems). Often, this exercise expands beyond the core system being studied. For each one of these journeys we look at service level objectives or indicators (SLOs or SLIs) to understand how they need to be executed, and the non-functional requirements the architecture will need to manage.

MONOLITH

UCD to Break out of the Monolith

TECH SPARK | 17

CUSTOM ALGORITHM DEVELOPMENT

INITIATE QUICKSTART PROGRAMMES QUALITY

NON CONFRONTATIONAL APPROACH

SMART

COLLABORATIVE

FREES UP IT

SHARED

NIMBLE

CONS

ISTEN CY

PARTNER WITH SHADOW IT

RESPONSIVE

ET

PUT OB PS TO FACILIT U I L D AP AT T

PO WE RS

E

DEVELOPMENT OF EITHER SIGNAL CREATION ALGORITHMS (E.G. TRADING) OR DECISION MAKING ALGORITHMS (E.G. DATA SCIENCE), WITH BACK-TESTING REQUIREMENTS CHALLENGE FOR TRADITIONAL IT: EXPLORATIVE AND WITH REQUIREMENTS EVOLVING BASED ON FINDINGS AND DATA

EM

BESPOKE DASHBOARDS & TOOLS

GEARED TOWARDS HELPING ANALYSTS AND THEIR MANAGEMENT TO PRODUCE FAST VISUALISATION TO MAKE BUSINESS DECISIONS QUICKLY CHALLENGE FOR TRADITIONAL IT: FAST CHANGING, EXPLORATIVE AND SOMETIMES THROW AWAY

DE VE LO PE RS US EM INI MA

CH

L L A

EN

REPRODUCIBLE DOCUMENTS

CI TIZ EN

GE

S

'IT’ CAN BE SEEN AS RENEGADES, TOO BUSY OR A BLOCKER TO GETTING THINGS DONE

ONE TIME AND RECURRING DOCUMENTS OFTEN BASED ON TEMPLATES, BUT WITH THE CONTENT OFTEN CHANGING BASED ON CONTEXT OR BUSINESS EVOLUTION CHALLENGE FOR TRADITIONAL IT: FAST ITERATIONS REQUIRED, EVOLVING METHODOLOGY

L CO DE F RAM EW OR KS T

HELPING YOU GAIN ADVANTAGE SHADOW 'IT’ CAN OFTEN UNWITTINGLY CREATE DUPLICATED APPS AND DATA AND PUSH BIGGER ISSUES BACK OVER TO IT

H

FOLLOW IT GUIDELINES

DE

18 | TECH SPARK

CITIZEN DEVELOPERS ARE DRAWN TO THE IT PLATFORM AS IT PROVIDES FRAMEWORKS, DATA, ACCELERATORS AND APP MANAGEMENT – THE PLATFORM SEAMLESSLY ENFORCES POLICY AND IS INHERENTLY SAFE – AND HELPS PROTOTYPE PRODUCTS FOR ENTERPRISE IT.

TIV

Because of the very experimental nature of some requirements, you need a sandbox to innovate and explore the data in a safe and organised manner.

This is a different class of problem and should be met by a different type of solution, enabling what we now call Citizen Developer models. They allow new ideas and problems that warrant fully-fledged IT solutions able to feed mainstream requirements.

THERE IS A CONSTANT NEED TO IMPROVE LEGACY PROCESSES/PRACTICES, & FOR NEW REQUIREMENTS IN ORDER TO COMPETE AND STAY COMPETITIVE

U BACK I TROL O N Y O C N INGE PROCESSES OF BU S I N E SS OPERATIONS IT.

EAC

Working in IT has never been tougher. The demand for custom applications and reporting is at an all-time high, data science is creating new challenges for managing models and data, and “shadow IT” is as active as ever in most organisations. As business needs grow, IT departments struggle to meet the requirements causing friction between IT and the business.

WHEN SHADOW 'IT’ IS UTILISED THEY CAN OFTEN FOLLOW NON COMPLIANT STANDARDS AND IGNORE COMPANY BEST PRACTICE

CITIZEN DEVELOPERS USE MINIMAL CODE FRAMEWORKS TO BUILD APPS TO FACILITATE THE PROCESSES OF BUSINESS OPERATIONS IT.

R DE CO PID NO RA

The Rise of the Citizen Developer

DEVELOPING, MAINTAINING, AND ENHANCING CORE COMPANY WIDE APPLICATIONS DRAIN THE MAJORITY OF THE 'IT’ BUDGET & RESOURCES

TECH SPARK | 19

DESIGN OPERATIONS ON-BOARDING

DesOps in Finance.

Desops (design operations) is loosely inspired by devops. The design bottleneck has always been a problem in the product delivery process. Desops looks to minimise that pain by bringing tighter collaboration with engineers, scalability of design and automation to the creative process.

Many things can affect design operations: teams scaling in size; companies creating new working environments and spaces; mixed ways of working (remote and physical); designers having a wider customer remit, and companies evolving with new capabilities.

Organisations are realising that their employees and the way they work, the tools they use, the culture they enjoy, together with success measurement are all critical ingredients to customer centricity. They have a direct impact on company success in terms of customers, products and the bottom line.

To make a success of desops you need a solid plan, and Excelian utilises the following approach to help organisations knock their desops into shape.

20 | TECH SPARK

PEOPLE

TOOLS

CREATIVE CULTURE DESIGN SYSTEM

TEMPLATES PROTOTYPING

RECRUITMENT

Design operations include the tools and infrastructure required to achieve design innovation. As a framework for desops we focus on five main areas of impact. They should be familiar already as they’re also relevant to devops:

PROCESS

01 People

WORKFLOWS

02 Process 03 Tools 04 Culture 05 Measurements

MOTIVATION

RETAINMENT

DesOps

MEASUREMENTS DESIGN STANDARDS TECH SPARK | 21

E CR EA TIV

GN SI DE DS PS

AU TO N

CR RE T EN TM UI VE ITI

NG

T

EN

NM

I TA

RE

N IO AT ING TIV AIN MO TR &

PO S

PA RE NT TR

DI

AN S

R OA

-B ON

GN SI DE

PLE PEO E TUR L U C

NI

LL

AB

N

IO

OR

SS

AT IV

RE

E

S

TIE

OG

PR EN LI

GH T

EN IN

G

NG DI

AR BO

F-

OF

Physical areas are also important for ideation: ● A design room (war room) ● Sketching facilities (e.g., whiteboards) ● Teleconferencing for remote teams ● Informal areas for brainstorming

U & RT RT N PO PPO TIO OP SU EDIA HR EM R

OF

N

IO

SS

Other digital areas to consider include: ● Standardised communications and workflow software ● File naming and versioning ● File storage (Dropbox, OneDrive, etc.) ● User-testing tools

ER LIV DE

EM ST SY / S GN TE S SI LA T DE C MP FA TE RTE FS A

ND

HA

T& OR ON PP ATI SU EDI HR EM R

TIES

ING

S LE IP

O LO

S

C IN R DA

AN ST

K

OM OU

PR

GN SI DE C BA ED FE ER OV

G IN

T EN

T

-BO ARD

DY N

N SC DI

ST TE

ITM

P

UNI

It’s important design team members maintain a standardised approach to tools. For example, if team members use different design applications (e.g., Sketch or Illustrator), two separate UI kits need to be maintained. This holds true for prototyping and diagramming tools, too.

So, a standardised approach across digital toolsets is crucial.

E FIN DE

ER

U CR

LE EOP

OFF

S

CES

PRO

US

RE

ORT

NG

AM IC

N IO AT IC OW UN KFL MM OR CO & W L & SIG TA E GI D DI ICAL YS

E, AG ITY OR UR ST SEC &

CK BA

N IO AT ING TIV AIN MO TR &

OPP

MEN

RDI

RE

● ● ● ● ●

Testing and feedback loops A clear set of design standards Design principles relevant to everyone A design system (design patterns, layouts) A consistent set of design templates Artefact templates for each ‘D’ phase Reusable, coded UI components A clear prototyping process An articulated design–dev handover process

OG

● ● ● ●

PR

We use a variation of the Design Council’s Double Diamond model. Its important to establish a clear design process to help plan and create activities such as:

RET AIN

S

L TOO

PH

GN

ED

GN

EM ST SY / S GN TE S SI LA T DE C MP FA TE TE FS AR OF ND

HA

ING

ES PL CI IN S PR RD A GN ND SI A S ST OP LO

SI

FE

ER OV SC

SI

ER LIV

ON

-BO ARD

NG NI IO NG RS ILI VE & F

DE

DE

DI

E FIN

BOA

DE

SI

OFF

Collin Whitehead — DROPBOX

ON-

DE

TIES

SS

CE PRO

DE

G IN ST TE

UNI

“Companies are beginning to understand the value of design, and are investing in the role of DesignOps to maximise design’s value and impact.”

03 ER US

T

E, AG ITY OR UR ST SEC &

PLE

PEO

Culture

LS TOO

NG NI IO NG RS ILI VE & F

T EN

NG

ES

22 | TECH SPARK

5. Offboarding Like onboarding, you need a well-structured plan for handovers and knowledge transfer.

ORT

RDI

GR

2. Onboarding Have a comprehensive and well-structured onboarding plan that covers how teams work and what’s expected of the candidate.

4. Opportunities and Progression Ensure the design team can see a clear, supportive progression path to aid talent retention.

N IO AT ING TIV AIN MO TR &

O PR

N IO

NG

1. Recruitment Make sure the brief is thorough, and screen candidates to make sure they’re comfortable with your organisation’s culture, agility, working environment and toolsets. Invite promising candidates in for a day to see how you work.

3. Motivate and Train It’s important to keep the design team hungry.

Collaborate closely, ensure regular creative sessions and provide training for skill gaps and realising ambitions.

MEN

T& OR ON PP ATI SU EDI HR EM R

S TIE NI

U & RT RT N PO PPO TIO OP SU EDIA HR EM R

SS RE

OG

PR

DI

AR BO

F-

OF

Onboarded individuals must fit the organisation’s template for culture and approach – skills alone are not enough.

Mismatched personalities and working methods can derail the success of a product design and delivery. With that in mind, there are several things to consider.

RET AIN

OPP

ITM

GN

ER LIV

ND HA

EM ST SY / S GN TE S SI LA CT DE MP FA TE RTE FS A OF

PEO

U CR

SI

DE

NG DI

PLE

Tools

N L & SI G TA E GI D DI ICAL YS PH

RE

E FIN

DE

T EN ITM

BOA

N IO AT IC OW UN KFL MM OR CO & W

ES PL CI IN DS PR R DA AN S ST OP LO K

ER OV SC

DE

U CR RE

ON-

R OA

-B ON

NT ME IN TA RE

& TMROTIVA AIN TION ING

ESS

C PRO

CO

GN SI DE GN SI DE C BA ED FE

Process

DI

01 People

Examples of good cultural attributes for design: ● Customer centric (customers treated as a priority) ● Enlightenment (doubling down on customer insights) ● Empathy and understanding ● Open, inviting and transparent environment ● Autonomous working where necessary ● Positive and fun working rhythm ● Professional recognition ● Continuous feedback and design crits ● Designing as a team, not individuals ● Constant knowledge sharing ● Collaborative, realistic and honest outlook ● Dynamic, agile and creative environment TECH SPARK | 23

CR EA TIV E

Measurements

DY N

AM

IC

N IO AT IC OW UN KFL MM OR CO & W L & SIG TA E GI D DI ICAL YS

PH

OLS

TO

Indicative KPIs Onboarding and delivery (lead time per project; number of days it takes from request to final delivery).

Team health (measure morale on a daily or weekly basis).

Project health (using a scoring system for the project status from a design perspective).

User satisfaction (both end-users and business-users).

N GN PS

TO N AU

RE CR

EN

LI

GH

TE

NI

NG

ING

24 | TECH SPARK

T

E

PLE O E P E TUR L U C

TIV

NG

SI

RDI

PO

T EN SP AR AN TR RA TIV E LA BO CO L

-BO ARD

MEN

T

N IO

SS

OFF

EN

RE OG

NG ORI T C A REF

PR

N ATIO

T& OR ON PP ATI SU EDI HR EM R

RE

OPP ORT UNI TIES

TM

TING POR

RET AIN

N IO AT ING TIV AIN MO TR &

N HA

E ER R

UI

GN

ER

LIV

DE

EM ST SY / S GN TE S SI LA CT DE MP FA TE TE FS AR OF D

ENT

TIS ORI

ES PL

CI DS

O LO

OU S

IN R DA

AN ST

K

OM

PR

GN

R

BOA

SI

S

ITM CRU

PRI

ON-

DE

TING

R TE

USE

US

SI DE C BA ED FE E OV

SC

G

IN

E

ST

FIN

TE

DE

ER

TR

KPI

US

G

IN ACK

SS

CE PRO

DI

ME

E, AG ITY OR UR ST SEC &

ASU

SI DE

NG NI IO NG RS ILI VE & F

TS

EN REM

Continuous improvement demands solid measurement, feedback loops and KPIs. We advise tracking the following measurement categories to get a wellrounded idea of what’s working and what isn’t:

User testing Adopt a clear plan for user-testing throughout the design lifecycle (from an internal face-toface-testing lab set-up, to more guerrilla-type techniques).

User recruitment Participant recruitment, scheduling and incentive management are probably the toughest issues in user research and testing, and can be sidelined. Careful planning and consideration are major contributors to the inflow of business benefits.

Prioritisation and refactoring Feedback and changes based on impact and business value are important. They should be prioritised and refactored into the designoperations process and customer-centric culture, to ensure smooth delivery and overall success.

A DesOps Owner is responsible for... ● WORKFLOW: How the design activities flow through the company ● TOOLS: What’s needed to get the job done ● GOVERNANCE: Who needs to see the work, and when ● INFRASTRUCTURE: What the team needs to be able to work more efficiently ● BUDGET: How much running the team costs ● HEADCOUNT: How many people (and which skills) are needed ● PIPELINE: Projects coming up and team capacity ● RETENTION: How to make people want to stay ● EDUCATION: Which skills are missing and how they can be developed ● EVANGELISATION: Helping the organisation understand the value of design TECH SPARK | 25

26 | TECH SPARK

KE T AR M S ON AT I OP

ER

PR

S

ES

T

BU SI N

EN

M

OP

VE L

S IS

E

TH

S

SR

LV E

SO

TH

IS

IL E AG

SO LV ES

Supported by the following practices: Metrics and monitoring, demand and capacity planning, change management, emergency response and culture.

NC

EP

T

SO LV E

BU

DE

SI

TH

VO

NE SS

LV E

IS

PS

S

TH I

S

SR

E

IS

SO

SO

LV E

S

TH

AG IL

E

DE

SO

LV E

DE V

VE LO P

M

O S P TH S IS

EN

T

DE SS NE SI

05 Measure everything, including reliability and toil

OC

AT I

ER

OP

SS NE SI BU

04 Leverage tooling and automation by automating common cases

S

T

KE

AR

M

ON

S

S ES OC PR

SLOs are a collaboration between dev and business stakeholders, and should specify which business functions and features are more important. For instance, a frontoffice system will have higher availability and durability SLOs for pricing and order management than for user administration.

This allows the dev team to deconstruct the application into separate cooperating applications, each with its own lifecycle and resiliency guarantees.

That’s not to

This principle becomes self-reinforcing: large applications will naturally break down into smaller parts. At the moment, failure in one part of a monolithic application could have a domino effect, bringing down the whole application. Separating mission-critical features from other less-critical areas, means features attract investment according to business priorities.

CO

So how is SRE related to devops?

Devops is a set of guidelines and practices designed to break down silos in IT development, operations, architecture, networking and security. SRE is a devops implementation that prescribes a set of principles, practices and language for developers, operators and the business.

BU

intersection of software development and systems engineering. SREs approach their work with a spirit of constructive pessimism; hoping for the best and planning for the worst.

03 Implement gradual changes by reducing the cost of failure PT

But what is SRE exactly?

According to Ben Treynor Sloss, Google’s VP of 24x7 Engineering, “SRE is what happens when a software engineer is tasked with, what used to be called, operations”. Basically, site reliability engineers are motivated people capable of writing automation who use software to accomplish tasks normally carried out by systems administrators, and data to inform decision making. They design more reliable and operable service architecture from the ground up. SREs develop solutions to design, build and run streamlined systems at scale, efficiently and effectively. They guide system architecture, operating at the

02 Accept failure as normal through error budgets

CE

But for both FAANG and financial services companies, there’s still a virtual wall between developers, operators and the business because their incentives are different. Developers prioritise agility, while operators favour stability and the business wants to reduce end-toend product lifecycle friction.

01 Reduce organisational silos by sharing ownership

CO N

Site reliability engineering (SRE) is easy to ignore because financial services institutions don’t operate at FAANG (Facebook, Amazon, Apple, Netflix, Google) scale.

SRE embraces outages by setting error budgets that recognise failure as a fact of life. The error budget measures the difference between the 100% availability and the SLO. It’s a clear metric for determining how unreliable a service is allowed to be, which enables decision makers to create downtime and deployment strategies. This allows teams to focus on system areas that are of prime importance to stakeholders.

ULTIMATELY: FASTER, BETTER, CHEAPER

What can my stakeholders expect?

Initially, there may well be significant change for the development and operations teams to absorb. However, in the longer term, SRE approaches will deliver reduced MTTR and increased MTTF (more reliability), allowing releases to happen much more often.

Consequently, development teams will become more engaged and produce higher quality software, faster.

say the user administration portal should accept sloppy code or developer neglect, but deployments can be simplified (e.g., by allowing downtime). In contrast, application pricing might have more redundancy with hot rolling upgrades which is more to manage (more risk of failure), clearly. A 10-minute outage in a user-management application would be dwarfed by the same outage in a pricing or order-management application.

Therefore, it makes sense to focus dollars and development on the areas where failure is most costly to the business.

ES

Moving Beyond DevOps: Site Reliability Engineering

ERROR BUDGETS Not all failures are created equal One of the key principles of SRE is the concept of error budgets. Often, in FS operations teams we see that the only service level objective (SLO) is “100% uptime for 100% of an application for 100% of the estate”. This is then enshrined as dogma in the operations director’s KPIs and the teams lose all sense of pragmatism.

TECH SPARK | 27

Pragmatic Pipelines

software performs along several new

facets. This empirical feedback is used to increase the quality and reliability of software releases before they can be

deployed into a production environment.

Int eg rat ion

03

07

CK BA

N

LL

IO AT

06

GR

E

TE IN

UR CT

US

05

UO IN NT

N

Co de

04

CO

IO AT

U TR AS

FR RO

An aly De sis vS ec Op Ar sS tef ca ac nD t Up Pr ep loa ov en isi d de on nc En En ies dt d oE to En nd Pr dE T od e nv s uc t iro tio nm De nC vS en o mp ec t Op a r Pe iso sS rfo nR c an rm eg Ru an res Ris nn ce sio kA i ng T e nT st ss Ap es es Ru Tag pli t s n m c n So a i e n t nt ion urc gA Ba Re eC p pli se lea od ca d se e On tio No n M Pr te LM ov + isi od Ev on els i de Pr nc od eT uc es tio t nE nv iro nm en t

Tes t

Tes t Un it

02

SE EA EL

IX TF HO

H/ TC PA

So urc eC on Co tro mp l ile

give developers feedback on how their

01

ER

R TU FU

Q

UR

FIG

N CO

IN

Continuous integration (CI) has been an essential part of software production since the early 2000s (Cruise Control was released 18 years ago). In recent years, development teams have sought to emulate the success of the pioneers of continuous delivery (CD) at places like Netflix and Google. Increasingly, financial institutions are adopting CD to help them produce software faster, better and cheaper. However, the cultural shift required is seismic and effects everything from production users to support via the dev team.

The increased numbers of quality gates

s

te y Ga t i l a u

08

09

10

11

14

15

16

the risk of failed releases. However,

cie

s

Tes

de n en

sS ca

nD

ep

sis

and deliver faster into production.

t nT es es

TECH SPARK | 29

on

gr

n tio

gA

pp

lic

ati

Re on ris

07

pa

Ar

tef

sio

ac

tU Pr p ov isi on E2 EE nv t iro nm e

nt

Op

from outages to maximise overall uptime

S TE GA

ec

pipelines in place, we can fix forward

ITY

De vS

L UA

aly

adopt an SRE mindset. With intelligent

EQ

An

IV

de

approach to our CD pipelines, we can

DR

on

TO

t

by adopting a richer, more pragmatic

S

Co

IC TR

eg rat i

13

T

The cost of software complexity is

ME

Int

12

N ME OY

PL

Automated tools will assess the impact based on the performance characteristics of a new release, plus a risk evaluation based on the impact of previous releases (outages, performance, bug reports, etc.), all allied to the characteristics of the new release’s change set (e.g., code authors, areas effected, complexity and size of the implementation).

DE

For instance, a configuration change might only require quick, end-to-end and regression tests before the secure pipeline deploys straight into production. With the right level of testing coverage, this can be done with tool-based, human sign-offs – the only intervention required for coordination instead of manual sign-offs and hold-ups masquerading as quality gates.

US

Is complexity sustainable?

As software estates grow ever-larger – spurred on by development of the microservices design pattern – the problems they solve become more complex. So, the impact of code changes and releases will need to be measured and monitored.

In future, insight will be delivered to those charged with keeping production environments stable.

06

28 | TECH SPARK

CD-driven development Just as TDD and, later, BDD are techniques for designing code and architectures that support an outcome, the same mindset can be applied to CD. If systems are architected starting from the required deployment characteristics together with quality gates, observability and testability, CD becomes a real possibility.

Pragmatic pipelines: one size doesn’t fit all Quality gates are needed for different software changes in our recommended pragmatic approach. Ultimately, this is dictated by the business drivers for the change. With the right foundations, you can define deployment pipelines and the sets of quality gates required for different kinds of change.

E US

Operational responsibility should run like a golden thread through every development team – nothing focuses the mind of a developer more than the risk of a midweek, midnight callout. Many larger, highly regulated financial institutions resist CD adoption, preferring the familiar security of existing CAB processes and documentation.

Change approval board (CAB) release theatre Misplaced trust leads to the complete absence of checks to ensure that documented test evidence (often just screenshots of SQL query windows) was generated by the version of the source code used to create the build in question. Worse, more faith is placed on manual release steps than versioned, highly automated, repeated and repeatable deployment configurations.

UO

IN

NT

CO

Resistance to CD Operations success is measured by production incidents. Therefore, the mindset becomes “achieve 100% uptime through near-zero releases”. This is clearly at odds with CD. If operations have to be kept separate, they should be evaluated by combining uptime with the amount, rate and lead time of business value delivered to production.

Pr ov i

15

16 vir on

e Co d

En

el

nd

od

oE

es

od Tag

te

tio

No

uc

se

09

Pr ov is

ion

Pr od

lea

08

Re

t

nE

+

nv

Ev

iro

ide

nm

nc

nif

ec k-

07

E

Ch

en

es to

eT es t

fV ers ion

s&

ac kte Tes t/B

nd oE

in

LIN

10

ENGINEERING AND ARCHITECTURAL PRINCIPLES

E IN

EL

IP EP

R CO E LIN PE PI

LINEAGE Once data is catalogued, the lineage of data coming in from external sources can be recorded. This will sit alongside the ML platform’s version manifest to record any derived data values, creating a lineage across – not just input data but derived data and model decisions – which will be reproducible enough to convince the regulator that there are no intentional biases in the ML application.

ML

DOMAIN MODELS Between 60% and 80% of the work involved in data science is data wrangling. If data lakes can be catalogued and expressed as domain concepts or tier 0 facts that have happened in

the real world, they can be reused a cross models with little or no modification.

NG NI AI TR

MASKING AND DATA GOVERNANCE To make data available to as many different data scientists and groups within an enterprise as possible, you’ll need to implement data masking (depending on jurisdictions at play) and field + row level tracking and monetisation, plus security.

L DE MO

CONTINUOUS TESTING AND EVALUATION Once models and the core platform are under source control and tested on every check-in, the entire ecosystem can be envisioned and evaluated for the effectiveness of the model. For instance, the model parameters can be tested to ensure they are only within +/- 5% of the last set.

If they’re out of bounds, the build could be failed.

tes tM La ith

st w

Ma el od

in M ck En

Ma

N

IPE

dt

TIO UA

Ch e

AL EV

05

US

EP

the model. This will be used to stand up the entire application, end-to-end, with the latest version of all build artefacts (including the model parameters).

VERSION TRACKING The version of an ML platform is the sum of all the components: platform code + model code + training set + model parameter matrices. This manifest of all versions can be prepared by a stage in the pipeline and then checked back into source control to form a full method of tracking and recreating all required components.

el

ter me

tri xP ara

lM de Mo

ate

04

UO IN NT

CO

Ev alu

s

ix Va lu atr

l de

Tra in

03

Mo

02

Pr ov isi on

En

dt

it T e Un

me

el st M

Co m

pil eM od

tes Ga Qu ali ty

01

R WA

PIPELINING As for different software changes, there are different pipelines for ML platforms, too. The underlying and feeding platforms are subject to their own set of pipelines. However, in the ML sphere, different pipelines have different duties.

Model parameters are prepared by a separate pipeline, with their output fed back into source control, which can be used as one of the triggers of the main core pipeline. The core pipeline checks the code used to prepare and calculate

FT

VERSIONING From code to configuration and training sets to resultant parameter matrices, everything should be treated as code. Any environment should be reproducible from source control for all aspects of its delivery. Containerisation is invaluable, as well as tools such as git (+ git-lfs or Annex), Docker, Jupyter, Jenkins.

SO

30 | TECH SPARK

The holy grail for data scientists is an environment where they can quickly ingest new data sources, change or retrain a model on a new training set, then test its effectiveness without worrying about the burden of tracking all of the moving parts.

For business owners, the goal is an environment where changes are safely tracked and audited, as well as being reproducible (for when the regulator comes a-knocking).

By adopting a devops mindset, ML teams can employ simple tools like CI, source control and containers, to add lineage and reproducibility to their platforms.

ML DEVOPS PRINCIPLES

CD

When embarking on a project, the temptation is to dive into the data and demonstrate some quick wins and the sheer power of ML. The danger is that models may become difficult to track and, worse, difficult to reproduce. If the provenance of a model is insufficiently understood, how can it be modified with confidence?

Furthermore, as ML becomes more embedded in technology and business landscapes, regulators will insist on companies explaining and reproducing ML models. Therefore, data governance, lineage and a systematic engineering approach to ML models is vital for cultivating data science success.

CI/

Apparently, data is the new gold (or the new oil, the new black, or the new whatever). Why? Because you can use machine learning (ML) techniques at scale to mine for insight. And large cloud vendors provide easy access to their algorithms, so there’s no need for hordes of in-house PhDs. Any ML project or team will require experimentation until insights and business benefits are realised. So the rigour of devops engineering is a key discipline for any data science team.

06

DevOps in Machine Learning

nt

Co d

e

To unlock the full potential of data science and be ready to answer any compliance questions, data scientists should adopt devops’ best practices and build robust, scalable analytics platforms for the future.

TECH SPARK | 31

How Fast Can You Go?

Many organisations are looking at faster ways of responding to meet the ever-increasing needs of their businesses and deliver better business value to customers, more often.

Financial services has always relied heavily on technology. This has given rise to large ecosystems of interconnected platforms and tools. However, inertia now represents a major challenge to adopting CD in any kind of value-stream-aligned manner. The average landscape within a financial institution will contain legacy (sometimes mainframe) applications, and vendor applications alongside more modern approaches. These applications are usually chained together or interconnected with message queues: ESBs or worse, CSV extracts and direct database links. As any good project manager will tell you, external 32 | TECH SPARK

dependencies impact both timelines and productivity as developers wait for gaps in other team schedules for information, data or releases. Any organisation considering adopting CD needs to know where the bottlenecks (“chokepoints”) are. To achieve this, Excelian’s consultant toolkit – assesses an organisation’s agility and devops maturity – uses a metric we have defined as the “cost of change”.

“Cost of change” enables decisions about which teams can be prioritised for any agile, devops or CD transformation.

Furthermore, once the dependencies (and

the directionality) between systems are known, you can architect platforms and align agile release trains along value streams to reduce dependencies and increase release throughput. This is coupled with our methodology to assess and rate capability and maturity of platforms, plus application ecosystems. This picture - in conjunction with the appropriate target - feeds into the strategy Excelian will develop and progress with clients to help them achieve their CD goals and KPIs. Our clients have found that devops rigour is the catalyst to unlock the true value of agile and continuous delivery within regulated environments.

TECH SPARK | 33

AGILE RELEASE TRAIN (ARTS) LEADING

ANALYSING

IMPLEMENTING TIPPING POINT

SAFE PO/PM

S AM FY E TI STR EN E ID ALU V , ES RS IV E UT AD EC LE EX S, N R AI GE TR NA MA LE GI S -A NT AN GE LE A N E AI NG TR CHA

IMPLEMENTATION PLAN

BEGAN A TRANSITION TO SAFE TO PROVIDE AN EASIER TRANSITION FROM WATERFALL TO FULL AGILE.

36

TRAINED 30 STAFF (SENIOR LEADERS) TO SKILL UP ON THE SAFE CONCEPT; WIDER TRAINING FOR THE WHOLE DEPARTMENT (100+ HC)

SAFE SCRUM MASTER

WEEKS

IMPLEMENTATION PHASE

TRAIN TEAMS LAUNCH ART

PREPARE FOR ART LAUNCH COACH ART EXECUTION

LAUNCH FURTHER ARTS & VALUE STREAMS

SAFE FOR TEAMS

LEADING SAFE

12

WEEKS

EMPOWER TEAMS TO RELEASE ON-DEMAND

CITIZEN DEVELOPER STARTED WITH A MAPPING EXERCISE ACROSS THE ORGANISATION; THE BIG SURPRISE WAS THE SCALE OF THE ISSUE

CATEGORISED GROUPS

INT ER ME

DEVOPS TRANSFORMATION

DELIVERED A COMMON FRAMEWORK

C

Compliant

by Design 34 | TECH SPARK

REMOVED A CRITICAL BOTTLENECK BY DELIVERING A COMMON FRAMEWORK TO BE REUSED ACROSS ALL SQUADS AND EMPOWER EACH TEAM TO OWN ITS OWN PIPELINE VS HAVING A CENTRAL "RELEASE TEAM"

THROUGH IMPROVED TOOLS AND PROCESS

BASI

Case Study:

SAFE ADVANCED SCRUM MASTER

A SQUAD = FRONT END DEVELOPERS / DATA ENGINEERS / CALCULATION ENGINE SPECIALISTS / AUTOMATION TESTERS; IN TOTAL 8-10 PEOPLE INCLUDING SCRUM MASTER + PRODUCT OWNER + BA IN SOME CASES; THERE ARE CHAPTERS ALIGNED TO UI / DATA / CALCULATION

SUSTAIN & IMPROVE

A GRADUAL TRANSITION TO MULTI-FUNCTIONAL TEAMS TO BREAK THE TECHNOLOGY SILOES; WE PROVIDED 8-10 SQUADS ACROSS 2 LOCATIONS.

PILOTED AGILE SQUADS

DEFINED SET OF ROBUST KPIS MOST IMPORTANT ONES: VELOCITY PER SQUAD, RELEASE LEADTIME AND WEIGHT OF THE BUSINESS PRIORITIES DEFINED AT THE END OF THE PI PLANNING SESSION

CE LEN L E C F EX TRE O N E C E L LEAN AGI

DISCOVERY PHASE GO SAFE

EXTEND TO THE PORTFOLIO

DATA & ENVIRONMENT MANAGEMENT

DASHBOARD CREATION VISUALISATION TOOLS

BASIC SKILLS COVERING VISUALISATIONS DASHBOARDS EXPLORATION

INCREASED THE LEVEL OF AUTOMATION TESTING

ATE DI

BASIC + INTERMEDIATE SKILLS COVERING NON-TRIVIAL CALCS AUTOMATION REPRODUCIBILITY

AD VA N

PROCESS & ORGANISATION TRANSFORMATION

RELEASE TRAIN ENGINEER

INTRODUCED VIRTUAL ENVIRONMENTS ADDRESSED CHALLENGES ON INTERNAL CLOUD RELATING TO DATABASE AGILITY

D CE

BASIC + INTERMEDIATE + ADVANCED SKILLS COVERING MODELLING/ANALYTICS MDLC MODEL MONITORING

MACHINE LEARNING & INFERENCE MDLC

PROMOTION OF INNOVATION

REDUCED CYBER RISK £

RECOMMENDED A TARGET PLATFORM

DELIVERED A ROBUST OPERATING MODEL

USERS CAN BUILD THEIR OWN APPS AND PROTOTYPES WITHIN A GOVERNED ENVIRONMENT AND THEN ONCE THE CONCEPTS ARE PROVEN, IT CAN BE FED INTO THE SAFE MACHINE / BACKLOG FOR INDUSTRIALISATION TECH SPARK | 35

Sprinting to DevOps Excelian can deploy a wide range of expertise to help you deliver software faster, better and cheaper, in a reliable and repeatable process. We can package this expertise as advisory engagements, as transformation teams working alongside your internal teams, or as feature teams to help you scale your engineering capability.

36 | TECH SPARK

Continuous Delivery and SRE

User Experience

Machine Learning

Citizen Developer and Data

Short term engagements, outcome-based

Assess

Assessment versus market best practices and industry standards Strategy definition and validation

Set Up

Transform and Execute

SME-based support to put in place building blocks in place High level collaboration

Fully functional engineering teams, working side by side with our clients Story point pricing

TECH SPARK | 37

Contributors

Andre Nedelcoux Head of Digital Consulting

James Bowkett Head of DevOps

Andy Hall Creative Director

Ian King Senior Director

Jose Dalino Principal Consultant

Andre has been working in the financial

James has 20 years experience as a lead developer in the finance industry at various banks, hedge funds and startups. He cares deeply about design and building quality into the heart of all software and is a firm advocate of XP practices such as TDD and BDD.

Andy is Creative Director at Excelian and has 25 years of User Centred Design experience with over 20 years dedicated in digital covering user experience and information design. He helps organisations to use creative techniques to drive design innovation and specialises in complex problem solving for the financial services sector.

Ian is the Global Head of Delivery, Digital Consulting with responsibility for all deliveries spanning small advisory projects of a few weeks to large multi-year projects delivered from multiple locations. Ian has worked within Excelian for over 8 years taking on project management, senior leadership and project director roles for our clients.

Jose is currently a Principal Consultant at Excelian. For the past 12 years, he has been helping FSI enterprises and start-ups retire and/ or prevent technical debt, architect, operate and scale applications and operating models through cloud migrations, infrastructure automation, DevSecOps and site reliability engineering.

services industry for 20 years, helping clients make decisions around innovative technologies and new ways of working. He has extensive knowledge of the industry and advises organisations on digital transformation, go to Cloud strategies, modern data architecture but also Digital Experience and the introduction of User Centred Design into the software design process. He is responsible for Excelian’s Digital Consulting business globally.

38 | TECH SPARK

It is not the strongest of the species that survives but rather, that which is most adaptable to change.

Charles Darwin

DesignForFinance.Sprint

DesignFor.Finance

A five day rapid design and prototyping exercise to understand a problem and user test solutions DAY 1

DAY 2

DAY 3

DAY 4

DAY 5

REA OF VALUE

are war room ea to focus on s and users

to products ard team

F

Understand

Ideate

Refine Design

Prototype

User Test

Set goals for the 5 day week Map out the landscape Interview SMEs/Users

Get inspiration/moodboard Sketch out high level concepts Present back and critique

Ideas gallery and dot vote Refine and finalise Storyboard out prototype

Build out screens/UIs Stitch together a single flow Prepare user testing script

Set up testing room/video Kick off first testing session Aim to undertake max of 5

Luxoft Financial Rework/iterate Service’s is a proven, pragmatic design service Identify Painpoints ideas 5-day sprint Plan out interactions Clarify roles for testing Take notes/graphic record Capture Opportunities Recruit users for testing Undertake a trial run Wrap up/discuss findings that gets you both qualitative and quantitative results fast. Our experienced Synthesise any research FS designers work with you and your users to define and deliver a phased, innovative and measurable solution.

Get in touch and get results... fast

Integrate testing Discuss impleme Write up stories f

Create roadmap Undertake anoth