Customers’ expectations of always-on, real-time services and convenience are in stark contrast with the reality of the core systems that serve them, and established institutions are seeing an exodus of customers to providers able to make good on those demands.

The irony is that older banks possess an incredible amount of data accrued over decades, yet are unable to capitalise on that rich seam of information at their disposal. Systems architected 30 or 40 years ago may be proven, reliable and relatively secure, but were never designed to leverage data in the ways now required to guide service design and refinement at the kinds of speeds needed to remain competitive.

Financial institutions have a dual challenge, therefore. Core banking systems need to be replaced or phased out, and the data archives locked into mainframes and legacy storage released to improve customer experience, offer innovation, and take the fight to the new and neobanks that threaten to out-compete longer-established businesses.

Trusted market intelligence organisation IDC recently published papers in conjunction with Thought Machine, a next-generation core banking provider, on the options available to banks reliant on outdated infrastructure. It describes how fourth-generation cloud technologies now offer a choice of migration strategies to replace and/or update core functions.

Source: Shutterstock

Non-exclusive options of progressive, greenfield and ‘big bang’ methods are considered in detail, and the papers assert that an amalgam of these strategies is the most likely to succeed in the majority of cases. All, however, are predicated on the embracing of technologies like interoperability via APIs, microservice-based architecture, low-code compatibility, platform agnosticism and scalability/elasticity.

Using methodologies like architecture-as-code, self-healing and baked-in scalability, banks can develop real-time services and downstream data for analysis, all based on modular architecture that’s secure and resilient. These methods enable fast, iterative development, lowering costs and time-to-market, as well as widening product portfolios (of both customer-facing and business intelligence applications).

Once banks engage in revising their core systems, they can begin to develop an ‘enterprise intelligence’ approach that unlocks their data assets that will inform, with empirical information, long-term strategies unencumbered by the limitations that are imposed at a deep level by aging code. Running on core technology that is based on interoperability and modularity ensures an open future, allowing emerging technologies (machine learning is often quoted in this context) to be implemented – creating the possibility to develop unique and differentiating products.

The emergence of an enterprise-wide data strategy unlocks a strategic treasure-trove of information that helps banks identify, via advanced analytics, key information used to drive innovation, enhance customer experiences, and improve operational efficiencies. The myriad advantages of EI (enterprise intelligence) are explored further and possible roadmaps are outlined in ‘Unlocking Enterprise Intelligence in Banking Systems’ which is available here.

There are clearly challenges on the route to modernisation, not least of which is the maintenance of reliable, steadfast services as work proceeds. The two papers describe the pros and cons of common migration strategies and how institutions might best pick their own course.

It’s important to stress, however, that although there are myriad options, there are a number of ‘givens’, paramount among them being the use of cloud-native methodologies and techniques, even when considering a waterfall, ‘big bang’ strategy. It’s also worth noting that cloud-native methods are not solely implemented on cloud providers’ resources. Like many industries subject to high levels of governance around data security and compliance, many financial organisations adopt a hybrid topology, often to maintain a separation between critically sensitive data (airgapping) or to prevent vendor lock-in, among other reasons. Cloud-native technologies allow for this, and ensure that during and after migration, data governance is strictly observed.

Source: Shutterstock

The agility and scalability of cloud-native confers on platform architects the ability to structure core and ancillary systems however they’re required to be distributed, regardless of hosting platform, remote or on-premise. With the right approach, a bank’s options remain open and it can react quickly to changes in governance, as well as to market conditions, altering topology at will.

Finally, it’s worth circling back to the reasons for overhauling core infrastructure. Replacing old technology with new should not be an empty gesture because of a perceived need to progress. The end goals should remain clear in the minds of decision makers: to enable practical use of existing and future data resources and to create a basis of technology that is adaptable, secure, compliant and agile. On that basis, banks can innovate, lower the cost and time required for innovation, and compete with new-generation financial organisations that operate with little technical debt.

Startup banks and neobanks may come to the table with fewer encumbrances, but they lack the powerful body of historic data spanning multiple products that older institutions have. And it’s data, at the end of the day, that is the one resource that truly empowers.

Read the reports, ‘Driving Innovation Through Cloud-native Core Banking Platforms’ and ‘Unlocking Enterprise Intelligence in Banking Systems’ for fuller discussion of the issues covered here. Discover the cloud-native core banking and data services portfolio from Thought Machine by heading here.

The post Data Strategies That Dictate Legacy Overhaul Methods for Established Banks appeared first on Tech Wire Asia.

As businesses rapidly digitize, their aim is to deliver enhanced, faster customer experiences to boost growth. Such experiences could involve dynamic personalization along purchasing channels, enabling customers to visualize bespoke product configurations before buying, or compare features side-by-side. In a cloud-native architecture, IT and business can efficiently convert customer suggestions or business owner ideas into application software.

The term “cloud native” has evolved since big tech transformed itself using cloud technologies, redefining software development. However, the complexities and risks have limited cloud-native adoption to a few industry leaders.

Challenges and costs of cloud-native development

Although cloud-native development has numerous benefits, it is not always a straightforward process. The core of this approach involves containerization and Kubernetes, which is the container orchestration platform of choice for most companies. However, Kubernetes can become incredibly complex, and experienced practitioners are scarce.

Companies that deploy it often have to dedicate significant resources to configure and run their development operations properly. Additionally, there are other challenges that IT leaders need to consider when building cloud-native apps, including retraining teams on microservices architecture, learning and assembling individual cloud-native services for security, networking, data, and retooling DevOps processes.

These challenges can increase complexity, resulting in higher costs, including recruiting a team of cloud-native dev experts, building the environment, and scaling it. This cost depends on several variables, such as company size, in-house skills, the country where the team is hired, the current operating model, and the modernized app portfolio.

Source: Shutterstock

For instance, let’s consider ‘Atom’, a hypothetical US-based composite insurance company with a wide range of apps that need modernization. Atom has a sizable team of developers based in the US, but lacks in-house expertise in cloud-native technology. Its development teams predominantly employ a traditional linear waterfall model, contrasting with the rapid, iterative style common among cloud-native developers.

Atom hires an external consultant to support the IT manager during its planning phase. The consultant helps Atom identify four main initiatives spanning two phases: infrastructure environment and application development.

According to OutSystems’s Cloud-Native Development Report: The High Cost of Ownership, to launch the infrastructure for its new web portal, mobile companion, and back-office app, Atom needs to hire and onboard 12 new team members in the US with specific expertise in cloud-native technologies. This will cost the company US$663,000. Building and configuring the infrastructure environment will cost US$1.2 million, while maintaining and scaling the infrastructure environment will cost US$870,000.

The next phase involves training and reskilling in-house developers, as well as app development with traditional coding, costing a total of US$2.9 million. Training and reskilling existing developers will cost US$340,000, while traditional application development will cost US$2.6 million. During the 12-month development period, 17 traditional coders will work in three teams, and the application development team will collaborate closely with the cloud-native infrastructure team.

Factors affecting costs in transitioning to cloud-native infrastructure

The costs associated with transitioning to a cloud-native infrastructure depend on several factors. One of the most significant factors is the complexity of the app portfolio, which impacts the architecture and infrastructure requirements, necessary tools and skills, and team size.

For instance, if a company only needs a simple internal app, such as a vacation planning app, there is no need to shift to a cloud-native infrastructure or hire a new team of skilled developers. Only one or two developers with the necessary skills can handle the requirement.

Source: Shutterstock

The second variable affecting costs is the type of business and its apps. The number of users accessing the apps, geographical distribution of the business, and areas of operations determine the need for geographical redundancy, number of billing regions for the CDN, number of firewalls, and compute resources.

The third variable is the IT department’s operations, which may impact costs based on the location of the IT department, hiring strategy (in-house development, outsourcing, or hybrid model), and existing development culture (waterfall, agile, DevOps).

Low-code meets cloud-native: the future of rapid application development

Building a cloud-native development infrastructure from scratch can be costly, complex, and variable, making it difficult for many IT departments to adopt Kubernetes, cloud-native technologies, and microservices. The process can take several months to years and require millions of dollars before developers can begin building their first application. So, how can organizations leverage the benefits of cloud-native development without adding additional effort and resources to configure and manage it?

One possible approach is to use a platform like OutSystems, which integrates a state-of-the-art cloud-native infrastructure into its low-code offering. This allows organizations to enjoy the agility, scalability, security, and availability benefits of cloud-native development without needing specialized expertise or significant financial outlay.

Source: Shutterstock

The OutSystems high-performance, low-code platform uses visual development tools and automation to accelerate the application development lifecycle. This means organizations can utilize a ready-made cloud-native infrastructure, enabling existing teams to deliver applications more quickly. They can do this without the complexity of traditional coding or the need for specialized cloud-native expertise.

Combining low-code and cloud-native development methodologies can help organizations rapidly develop applications that drive revenue, reduce costs, and manage risk at an internet scale.

OutSystems offers a practical solution to the challenges of a cloud-native world. Its high-performance low-code platform aims to enhance developer productivity, enabling organizations to start creating mission-critical cloud-native applications from day one, without the complexities and costs of building their own platforms. To learn more about OutSystems, click here.

The post Building a cloud-native infrastructure from scratch: is it worth the cost? appeared first on Tech Wire Asia.