Technology
Why digital transformation means going back to IT infrastructure basics
Published by Jessica Weisman-Pitts
Posted on December 5, 2022
6 min readLast updated: February 2, 2026
Global Banking & Finance Review®
Company
Published by Jessica Weisman-Pitts
Posted on December 5, 2022
6 min readLast updated: February 2, 2026
By David Sandilands, Senior Solutions Architect, Puppet by Perforce
In financial services, the modernisation of IT infrastructure, mainly through automation, is an integral part of digital transformation. In theory, this brings multiple benefits, such as addressing scale, reducing complexity, improving security and compliance, and making better use of available talent. However, unless executed correctly, changes to the IT infrastructure may not solve those problems at all: indeed, they make matters worse or introduce new challenges. Users may even decide to bypass those changes.
This has been the experience of many financial institutions, who have discovered there is a big gap between IT automation theory and successful implementation. This is not a criticism: those organisations have been the pioneers of new technology territory, and we can also learn from their experiences. For instance, it has become clear that for organisations to move beyond the status quo, it is essential to reevaluate the fundamentals required, what can or should be taken forward, and the impact on staff.
Getting the house in order
The logical starting point is to work out the strengths and weaknesses of what is already in place, what fits into the future, and what processes to resign. That means having detailed knowledge of those processes, ideally involving whiteboard sessions with all relevant stakeholders, deciding what can be automated immediately (and what cannot), and eliminating process steps that do not add value.
This may sound obvious, but it is essential to understand the ‘customers’ of the project, their requirements and service needs, plus how they will engage with IT automation, such as making requests, raising issues or asking for status updates. Clearly, having the right tools in place to support automation is essential, but that does not just mean running it, but monitoring and observing too. The more coordinated and well-orchestrated the approach to IT automation, the better the chances of managing the unforeseen.
People first
Another area for examination is the impact of existing staff and any additional resource requirements. Questions to ask include: Is a team already able to actively support and develop the required level of automation? Are there both senior and junior team members so that there is a succession plan when the former leave, ensuring that there are heirs to take their place? If it is essential to look at external consultants, does the internal team have the skills and time to work with those consultants? What happens when those consultants leave the building? What is the expected growth of the IT infrastructure, and what resources will that require?
In the meantime, the more pressing question is, what happens on day two? This is when friction typically occurs, and the workload impact becomes a reality. It is usual for a bank to have several IT automation platforms in place, so if there is a service issue, internal customers may not know which one of those platforms is responsible. So they send a request to the wrong team, or multiple teams, possibly in different formats (online form, email and so on). Suddenly, several people could be working on solving the same issue or passing it on to someone else, eating away at available time. So, it is crucial to predict potential scenarios and plan accordingly.
The choice of infrastructure has a significant impact on teams. For instance, while native cloud has received lots of hype, very few organisations have access to the number of skilled team members required to support these complex, digital technology cathedrals. Instead, in many cases, on-premise and hybrid cloud are often far more practical (with clear technology decision-making trees to help decide when to use which one).
Expectations and early wins
Another vital factor for success is setting and managing expectations. As well as putting metrics in place for the project’s ultimate success, it makes sense to start small and work upward, such as starting with tasks that have demonstrable benefits and ROI. Moreover, smaller projects can make it more viable to involve junior staff members, giving them learning opportunities rather than depending on the deeper knowledge of more senior staff.
Patch management improvement is an obvious example and also demonstrates that IT automation can contribute to better security and compliance. Being organised, with clear owners and SLAs that allow for downtime for updates, goes a long way towards eliminating security and compliance tasks. In contrast, many organisations suffer from a more reactive approach, and it becomes an unplanned panic, yet this does not need to be the case. For instance, in a previous role I held in the banking industry, we pursued a policy of patching more regularly than the CVE requirement. So while we still needed to scan for evidence that the patch had happened, it could become just another part of the daily routine and not something that required an additional response.
Other early candidates for IT automation wins include frequent activities that involve a whole team to complete and with a hard deadline or toil-work that is draining and unrewarding. Processes known for human error are also good candidates. Similarly, change management tasks that typically involve three people and several days to draft, review and sign off can be transformed into a standard change or, better still, turn into a request on a service portal.
There will be problems
Another aspect of managing expectations is the company-wide acceptance that there will be teething problems. Inevitably, even the best-planned automation project will experience issues. We know of one instance where an outage happened, and in IT terms, it was not a huge deal, but for the customers who had heard so much about the new automation benefits, it was not acceptable.
Even when there are no problems, ensuring everyone has realistic expectations of what is achievable is essential to prevent support teams from being overwhelmed by requests.
Setting expectations also extends to IT operations staff not actively involved in the automation project. These individuals may feel left behind, so it is important to show them how the project may benefit them personally in the future. Invite them into meetings to feel involved from the get-go, even if they are not immediately involved in implementation. These meetings will also give everyone a forum to discuss issues and concerns and — above all — be honest when something is not going to work initially.
Clearly, there are multiple elements and issues to consider when modernising IT infrastructure, and these cannot all be addressed overnight. However, the rewards are worth the effort and arguably essential for financial organisations to achieve successful digital transformation.
IT infrastructure refers to the combination of hardware, software, networks, and services that are required for the operation and management of an organization's IT environment.
Digital transformation is the process of using digital technologies to create new or modify existing business processes, culture, and customer experiences to meet changing business and market requirements.
Automation in IT involves using technology to perform tasks with minimal human intervention, improving efficiency and reducing errors in processes such as software deployment and system monitoring.
Compliance in financial services refers to the adherence to laws, regulations, and guidelines that govern the financial industry, ensuring that organizations operate within legal frameworks.
Patch management is the process of managing updates for software applications and technologies, ensuring that systems are up to date to protect against vulnerabilities and improve performance.
Explore more articles in the Technology category
