Technology is enabling greater product offerings in financial services but also bringing challenges of managing increasingly complex systems over time. Legacy systems can be difficult to migrate and modernize due to their age and number of products supported. Business knowledge is lost when outsourcing increases. Systems are becoming old yet critical, and supporting outdated closed products is costly. Compliance requirements also continuously add management challenges. When redesigning such systems, it is important to focus on information rather than individual applications or technologies, separate stable and changing elements, and design for continuous change, monitoring and knowledge distribution across teams.

1. Technology In Financial
Services
Todays challenges and future thoughts

2. Banking Today

3. Banking Challenges
Complex estates that have been running since the late 60’s and 70’s.
How to manage change in these large estates to migrate to newer
technology.
Complexity is not just hardware and software but offered products and
lifespan of those products, some entities that number can be 40000
different products.

4. Banking is not just Banking
Todays institutions offer greater ranges of products, some moved to
other areas like Insurance.
IT is the main enabler of the banking offers and has large delivery cycles
and large costs as part of the processes that must be followed.
Business have lost of knowledge even from their internal operations by
outsourcing or large use of consultants.

5. Banking is not just Banking
Many applications/projects have requirements restricted due to cost
controls.
Large amounts of information with different data models, created at
different times and now in support mode only.
Compliance that continuously add restrictions and new management
challenges. Bank are now part of the social fabric and enforce as well
as support some processes.

6. Banking is not just Banking
Systems are now old to the point that turning off one could impact
on most valuable customers.
The cost of keeping older system is masked by the overall cost of
platform.
Closed Book product sets that have not been separated from their
original system and have large life spans of maturity.

7. Banking is not just Banking
Many parallel projects that have localized objectives making
very hard to manage overall design approach.
Alignment by business areas, sounds good but creates a
problem of managing information across areas. Extra point
solutions are created more legacy.

8. Process meets Technology
Long and complex processes.
These are designed to protect service. In some cases defined in Law, its
not the the case of reducing processes.
Technology that requires specialized knowledge that has a reduced pool of
resources.
Large delivery teams that are driven by complex hierarchies that reduce the
contact between the team delivering the technology and the real
stakeholders.
Short-term vs Long-term approach.
Technology Hype-Cycle different from internal delivery cycles.

9. John F. Kennedy
“Change is the law of life. And those who look only
to the past or present are certain to miss the future.

10. How to Manage Change
The delivery of change is not a timed event. Change is
continuous.
Take a Socratic view, all we know is that we can't
assume every future event. Same way we can't just
process every events after they have materialized.

11. So what can we do ?
Use a good architecture to assume change and
entropy.
Don't try to overdoing it. If the design is good trying
to define everything ends up in analysis paralysis.
Innovate, what may not be possible a few year ago
may be possible now.
An app is different from an ecosystem.
Approaching both the same way is guaranteeing
future issues.

12. So what can we do ?
Make distinction between items that change often
and items that not frequently change.
Use technologies that are designed for change and
allow a level of control that exists today without
overhead of some processes.

13. So what can we do ?
Technology is a tool, its the human imagination that
makes it work.
Technology is not the answer it how the idea gets
realised. Business knowledge and understanding is
one driver of success.

14. –Albert Einstein
“Everything should be made as simple as possible,
but not simpler.”

15. System Design Principles
One Application can't define the overall Solution, its just a piece of
the puzzle. Unless the application is the system. Very rare in
banking or financial services.
Don’t over-engineer the solutions, change is the norm.
Follow a steel-thread principle, sort the basics and enhance as
you go along.

16. Application Design Principles
If we are managing change we don't need to make
everything future prof.
Some elements do require a long life span even
because some don't change or are very well known.
Separate knowledge and information from
representation.
A Person, a Product are well known definitions, we need to manage the
characterisation (properties). Not have 5 versions of a person.

17. Application Design Principles
Passing a challenge to a different layer of the stack is
not solving the problem. We should address issues on
its proper area.
Integration is a simple problem compared with
information mapping and repair so we look at
information not integration.
Use the right tools and languages, writing very good
code in Java still means more lines of code to maintain
than Scala to address same paradigm.

18. Application Design Principles
Monitoring & Audit are business requirements even when the
business doesn't know. First item a regulator looks at its at
the audibility of processes.
We want to know what , when, how and actions we have
taken. We don't want the developers to spend lots of time
thinking about it.
Building large data warehouses and data lakes is useful when
we have a good ideas what the information collected is, not
very useful do load data because I think I will look at it later.
Probably we won't know what to do after either.

19. The Information Model
Information is everything, like water, flows and you want to
store as much as possible.
Models evolve don't think tables think characteristics and
relationships.
There is no one final answer but some concepts are very
constant so we can employ some common sense.

20. The information Model
We should be careful how we define our domains. For
example:
Product domain manages all Products.
Customer domain manages Customers.
Does this mean I have a 2 definitions of customer, one from
either domain ? Good Question….
We may have two perspectives but not true information
separation or we have acquired IT debt to aggregate those
two later on.

21. The Teams
Multiple teams should develop different parts of a
system but knowledge is distributed across by
paring the developers across teams. Promote team
work and knowledge distribution.

22. The Teams
Any good architecture must cater for the fact we
live in distributed world not everyone work on the
same office.
Good communications channels, technology
supports this. Always have face to face even using
any messenger apps. Humans interact with
humans not a voice at the end of the phone.

23. What’s the answer … 42 ?
There is no right answer but we look at a solution
the reduces decoupling and assumes changes are
going to happen (this means async). Not like lego
as you need to break everything to remove a brick.
Must provide monitoring and audit as part of the
process to reduce extra work. Again async solution
with some why to guarantee we have the flows
recorded.

24. What’s the answer … 43 ?
Must use some of the micro-services principles that
allows isolation but revoke some of the possible
silos that could be created.
Performance is not a metric of just how fast you
can go but how much more efficient it can be and
efficiency means cost. Running on 2x the needed
hardware is still not efficient enough.

25. What’s the answer … 44 ?
The system must support and maintain the same
level of functionality of exiting institutions or legacy
systems will never be turn off.
Old systems usually means bad data quality of
missing data. Any new system must support this
fact. Some accounts were created before AML laws
existed so data hasn’t been collect at that time.

26. What’s the answer … 44 ?
The system must support and maintain the same
level of functionality of exiting institutions or legacy
systems will never be turn off.
Old systems usually means bad data quality of
missing data. Any new system must support this
fact. Some accounts were created before AML laws
existed so data hasn’t been collect at that time.

27. What’s the answer … 24 ?
The API layer is a view into the information sets is
not the information. We focus on information
consumption but information can be broader.
We always record complete datasets, we don't
have to know everything today, we can always add
functionality if information is available.

28. What’s the answer … 24 ?
The open source and linux community has
addressed a lot of the version management issues.
Any design approach should follow that model.
Debian, Ubuntu, CentoOS have their own DevOps
model that has been working for years. We should
follow it.

29. What’s the answer … 35 ?
The open source and linux community has
addressed a lot of the version management issues.
Any design approach should follow that model.
Debian, Ubuntu, CentoOS have their own DevOps
model that has been working for years. We should
follow it.

30. What’s the answer … a GoogolPlex
?
Sometimes we just have to create a new system. This
may look strange but is part of change.
NASA developed the Saturn 5, then created the
Shuttle STS and now the Orion. Why not just stick to
the Saturn V ? Tech evolution, take advantage of
change.
Technology evolves and starting changing things
when tech is already passed its prime just creates
more legacy.

31. What’s the answer … n ?
Why 83 ? No special reason besides its a prime
number. Its as arbitrary as 42
83

32. The End