devopsy.kinsta.cloud

Tag: banking

  • How DevOps Helps Banks Optimize Their Services

    How DevOps Helps Banks Optimize Their Services

    A world-renowned bank’s CEO was recently quoted as saying that while there are thousands of manual banks now, the future will see only a handful of digital banks. Along with the rest of the world’s critical business sectors, an overwhelming number of banks are also shifting to virtual platforms. This migration is being orchestrated by some of the best DevOps resources that the global FinTech sector has to offer.

    The convenience of personalized services that are always on-demand has incentivized the banking sector’s reliance on DevOps workflows. When the COVID-19 pandemic struck and limited physical banking services, the migration of enterprise banking systems onto the cloud had been in full swing. Most bank employees had to shift to a work-from-home setup, accelerating the use of virtual service delivery.

    As per an estimate by the IBM Institute for Business Value, about 59% of the companies surveyed are in various phases of their digital migration and the banking sector is naturally following suit. DevOps teams are tasked with writing software extensions for connecting digital banking services to the end customer in an agile manner.

    This article explores why DevOps is slowly becoming an essential foundation for any successful banking institution. We will also discuss how traditional institutions cope with these changes and what benefits they can look forward to once they make the leap to DevOps.

    Agile Processes Facilitate Digital Transformation

    Most banks these days have been adopting agile processes to stay ahead of the competitive curve. The main motive behind this is to keep up with frequent business requirements that come with efforts to improve clients’ banking experiences. Fine-tuning the project planning and execution processes that drive this improvement are what the DevOps teams would be mainly doing.

    Under the Agile methodology, banking applications would be created in small, controllable steps known as sprints. Each step is tested meticulously before it can be considered executable or complete. Before continuing to build on the delivered component, proper channels are followed for real-time feedback and course correction. The end goal is that the customer must get a product that is of value in a much shorter timeframe than is possible through any other development process.

    More than even the process and the rules governing it, the DevOps teams involved and their collaboration is a top priority as well as the eventual outcomes. Agile projects behind the most optimal banking services and products must involve continuous planning, testing and integration of finished components.

    Faster Success for DevOps Teams in Banking

    To successfully drive new digital banking services, large banks need billions in assets and need to gain millions of new customers along the way. It all boils down to shifting their processes to a more granular process and continuously improving upon it.

    In situations like these where DevOps practices need to be adopted proactively, the client’s line of business (LOB) teams move to Agile planning strategies fairly quickly. They use a variety of tools to implement Agile and DevOps practices to tackle growing customer demands for their improved digital banking services.

    But for this to work seamlessly, the developer experience for both the LOB and IT teams needs to be streamlined. The LOB and IT teams’ efforts can be integrated if the DevOps platform is automated with built-in Agile capabilities and bi-directional integration. This ensures seamless collaboration, faster DevOps implementation and the speedy delivery of banking services and products.

    Focused Insights and Better Predictability

    Large banks can standardize the internal IT development team on an engineering life cycle management platform, simultaneously providing support to the LOB team via the Agile issue tracking dashboard. Agile life cycle management tools extend an integrated solution for banks. Using these tools, the DevOps teams can be provided with full transparency and traceability of developer data.

    Developer-specific capabilities such as source code management, build automation, continuous integration and delivery and Agile planning are more accessible this way. The IT developer community considers Agile workflow management platforms as the benchmark for efficient and continuous business flow. Workflow management platforms and issue tracking portals are the places where most of the Agile planning takes place.

    Agile life cycle integration adaptors then link the LOB-defined Agile stories with specific developer tasks in easy-to-manage packets. The developer changes to the application code are tracked within the workforce management tool to draw useful and quantifiable insights from the data. The speed of application delivery is accelerated further because of the connections established between the projects, teams and tools.

    Minimizing Service Delivery Mishaps

    Using workflow management tools, the team can provide continuous build and integration functionalities. They can deploy automated integration builds on dedicated cloud or on-premises environments which minimizes errors in service delivery. A software bill of materials (SBOM) is generated for each build in the final audit trail which lets developers resolve errors retroactively as well.

    A broad picture is created of which new tasks and pieces of code went into the build and what software assets were created. DevOps implementation ensures continuous delivery of the banking application across test and production environments. Errors are reduced throughout the production life cycles of each banking service or product. This reduces the time taken from development to production. A fully automated and auditable delivery pipeline is created to make future deployments even faster.

    Reduce Banking Product Release Cycles

    DevOps provides a very robust and reiterable foundational environment for the bank’s business to thrive while reducing release cycle time with every iteration. This means every time a new banking service is delivered, the development life cycle is improved bit by bit. In some cases, the release cycle can be reduced by more than half the original time taken.

    While service delivery is improved, this also frees up release engineers for urgent tasks crucial to the deployment window. More deployments occur while still keeping the bank or financial institution in accordance with regulatory guidelines.

  • Open Banking Shouldn’t Be Open Season on Your APIs

    Open Banking Shouldn’t Be Open Season on Your APIs

    Open banking has become the latest technological advancement for financial services applications that’s modernizing the industry. For instance, Mastercard recently began its Start Path Open Banking program, which provides select startups the opportunity to use Mastercard’s expertise while learning how to apply open banking to their own business. Open banking is creating new opportunities for revenue sharing and reducing data licensing and transaction fees between financial institutions and their partners. 

    Customers who take advantage of open banking also gain a more comprehensive, holistic view of their finances so they can be in a stronger position to manage their wealth. Just as importantly, open banking will provide more opportunities to use data for products and loyalty programs across the full spectrum of their organization’s offerings. Financial services companies like Mastercard also believe that open banking programs improve inclusiveness and financial literacy. With greater financial literacy, customers can work to lessen the chances of fraud in their accounts. 

    This follows an overall trend of breaking down barriers when it comes to connecting financial organizations with consumers through new, innovative financial technologies. In fact, 96% of consumers globally are aware of fintech services, including at least one money transfer and payment. Additionally, U.S. consumers are steadily adopting new fintech, including peer-to-peer payments. 

    While open banking has the potential to shake up the foundations of the banking industry, there is also the possibility of it becoming a target for threat actors and cybercriminals alike. The reason: application programming interfaces (APIs) that power open banking are being targeted.

    Hazards Associated With Open Banking 

    Open banking uses APIs to connect financial institutions with third-party applications. The Open Banking Project is one of the leaders in providing open source APIs for banking and relies on an open source system for financial services providers to access consumer banking and financial data.

    Yet, the more financial services organizations rely on APIs, the greater their attack surface becomes. APIs, as the building blocks of today’s modern web applications, are already a big target for threat actors and a primary attack vector. Banks, and the financial services industry as a whole, are also targets for cybercriminals. 

    IBM’s X-Force Threat Intelligence Index 2022 noted that finance and insurance organizations were the second-most targeted industries. Further, IBM also found that among those attacks, 70% were against banks and 14% were against other financial organizations. This tells us that while other organizations might make the data breach headlines,  banks and financial institutions are most often under attack by threat actors and cybercriminals. While one of the major drivers for this is financial gain, there is also a wealth of data in banking, including personal identifiable information (PII), payment card industry (PCI) data, account and payment information. Much of this can be leveraged on the dark web for financial gain. 

    Unfortunately, attacks on financial institutions and the APIs that drive much of our engagement won’t change anytime soon. The problem associated with APIs is that, if left unsecured, they can provide threat actors a foothold into sensitive data that can be  exploited. Additionally, many organizations don’t have a true understanding of how many APIs they have (many are interconnected) or how these vulnerable endpoints are being protected. It is incredibly difficult to protect something that you don’t even know exists! Adding an additional layer of complexity to the API conundrum is how third-party APIs are often relied upon. Using these sources, while potentially a time-saving strategy, can leave your networks open to attack. 

    Secure Open Banking Means Protected APIs

    If you’re a company that plans to start taking advantage of open banking, it’s important to mitigate some of these threats by establishing sound API protection strategies. First, gain visibility into your entire attack surface. After all, knowing yourself, including your APIs and web apps, along with understanding your enemy, will lead to success on the battlefield (to paraphrase Sun Tzu). Once you have a comprehensive view of your endpoints, including those older and deprovisioned APIs, you can be in a better position to protect against the multitude of threats that they face. Ideally, you will be able to get real-time analysis of traffic hitting your endpoints so you can get a more holistic view of a surface that is always changing. 

    It should also be emphasized that sophisticated attacks consist of bot armies generating API traffic and attacks. Malicious bots are being leveraged on an ever-growing basis in attacks, including DDoS attacks and account takeovers. While many bot attacks are automated, being able to detect and block them in real-time, when combined with continuous monitoring, can help to lessen the threat posed by bots.  

    A future with open banking is an exciting prospect due to the fact that it will put financial control back in the hands of businesses and consumers. While there should be a reasonable amount of caution placed in many of the API-centric open banking solutions, there are ways to alleviate these concerns. Strong API security, along with bot blocking and detection, can go a long way toward protecting against modern threats.

  • How Developers Can Handle the FinServ Data Deluge

    How Developers Can Handle the FinServ Data Deluge

    A decade ago, if you were to ask developers what the biggest challenges in commercial banking were, they would likely cite the difficulty of accessing and collating high-quality data on the day-to-day operations of banking institutions. Today, that’s completely changed.

    Or it has to some extent, at least. Developers working in the banking industry certainly have access to more data than ever before. But this has created challenges of its own. With so much data being collected, stored and at least partially processed, some developers have started to talk of a “data deluge”—an unstoppable torrent that overwhelms the developer’s ability to process and use it.

    In this article, we’ll try and make sense of this. We’ll also explore what it is being used for and what this means for the future of the banking industry.

    Promises and Challenges

    Before we get too deeply into the specifics, however, let’s take a moment to note that the data deluge is not entirely new and that it will be with us for quite some time to come.

    In fact, most guides to technology in the banking sector note that many of our current issues are caused by the sheer amount of data being collected. It has become acutely apparent that our data harvesting capabilities have grown far more rapidly than our ability to ensure accuracy or to label it in accordance with legally-mandated compliance frameworks.

    And, of course, this is only going to get worse. No one knows yet how the global COVID-19 pandemic and ensuing economic downturn will affect the global payments market, but it was previously predicted to reach $2 trillion by the end of 2025, with a compound annual growth rate of 7.83%. Even realizing a portion of that growth will create real challenges for developers in the banking sector.

    Using the Data Deluge

    With all that said, however, let’s also recognize that this is a ‘good problem.’ It’s not necessarily a bad thing that we have access to so much data—the issue is making sure that it’s accurate, safe and useful.

    And when it comes to doing that, three opportunities are already apparent. Here they are.

    1. Increased Velocity

    Many of the new approaches to leveraging data in the banking sector are focused on increasing speed. Indeed, the ability to access real-time intelligence in banking operations was one of the original promises of the big data revolution, albeit one that has taken some years to come to fruition.

    There are several reasons for that, but one of the most important is the fact that banks have lagged when it comes to updating their hardware and software to correlate with the amount of information they are collecting. Most banks now undertake significant levels of quantitative analysis on business and customer data, for instance, but few do so in real-time.

    Instead, many banking systems are still run on monthly data-processing schedules, meaning that it can take even the most technologically advanced bank 30 days to spot consumer or business trends. Implementing new technologies such as Apache Spark is one potential solution to this problem. Like Hadoop, it’s an open source big data analytics engine, but it’s faster, more scalable and easier to use.

    2. More Reliable Governance

    Another challenge when it comes to managing the deluge is that of governance. With so much data flowing in, it can be a challenge for developers and operations staff alike to keep track of its source and how it should be managed within data compliance frameworks.

    This is one reason, as we’ve long argued, that banking should consider DevOps. By uniting developers and operations staff, both can come to a deeper understanding of data compliance and how this must be integrated into every aspect of the contemporary banking industry.

    This is one area, however, in which more data is not necessarily a bad idea. Rather than pausing data harvesting because of concerns that it will create compliance issues, developers should aim to build systems that can carefully and reliably label this data throughout the custody chain.

    3. Focus on the Customer

    Finally, developers shouldn’t lose sight of the ultimate aim of collecting data—improving the customer experience. Data can be used to do this in two primary ways.

    The first is to put data to work in your customer-facing systems. This is the approach recently pioneered by Western Union, which offers an omnichannel approach that tailors and personalizes customer experiences by processing more than 29 transactions a second and integrating all that data into a single platform for statistical modeling and predictive analysis.

    Secondly, data can be used to inform strategic decisions. Just as consumers are now more savvy about the way that their data is used, leadership needs to understand that this type of data-based decision-making is the future of the industry.

    In other words, banks must be able to move faster to transform their data into intelligent insights and then put those insights into action to improve customer service, connect customers to information and products when and where it’s needed most and protect sensitive data and customer accounts from threats.

    The Bottom Line

    The data deluge creates challenges for developers and leaders alike. These challenges are only going to grow as our ability to harvest consumer and industry data continues to expand. If we are going to realize the promises of technology-driven banking, we need to improve the way in which data is managed and processed and ultimately improve our ability to extract meaningful insights from that data.

    And just as this challenge is not new, neither is the outcome—a better banking experience for the customer.

    If you want to learn more about financial services and FinTech development, operations, architecture and leadership through expert-led talks, panel discussions and keynotes, check out FinCon DX—now available on demand!

  • FinConDX: The State of DevOps in FinTech

    FinConDX: The State of DevOps in FinTech

    The FinTech space has grown dramatically this year as more consumers shift their financial transactions online due to the COVID-19 pandemic.

    Financial services companies are learning how to ship better code, faster by adopting DevOps methodologies. DevOps helps companies develop fast, fail fast and learn fast so they can fulfill customer expectations and deliver quality features faster to market than their competitors. However, the shift to DevOps is not that easy.

    The digital transformation journey for banking and financial services organizations can be quite challenging. That is why, on Dec. 3, the top financial services and tech leaders in the industry will come together at the FinConDX Virtual Summit, a free virtual conference focused on the DevOps, DevSecOps and digital transformation practices and tools you need to thrive in the FinTech industry today.

    FinConDX features a stellar lineup of industry experts, including:

    • Yaniv Yehuda, co-founder and CTO at DBmaestro
    • Viktor Farcic, principal DevOps architect at Codefresh
    • Sladjana Jovanovic, vice president of payments technology, TD Bank Group
    • Shannon Lietz, director of DevSecOps at Intuit
    • Sanjeev Sharma, senior vice president, head of automation and platform engineering at Truist
    • Rosalind Radcliffe, distinguished engineer at IBM
    • Don Duet, CEO and co-founder at Concourse Labs
    • Ravi Lachhman, chief evangelist at Harness
    • Matt Wilson, senior product manager at GitLab
    • Mitchell Ashley, CEO and founder at Accelerated Strategies Group
    • Keith Murphy, senior solutions architect at OutSystems
    • Jonathan Smart, partner, business agility lead at Deloitte
    • John Rzeszotarski, senior vice president of technology infrastructure at PNC
    • Dan Garfield, chief technology evangelist at Codefresh
    • Gary Gruver, CEO at Gruver Consulting and analyst at Accelerated Strategies Group

    The virtual environment features auditoriums with different tracks where attendees can watch the sessions by industry leaders and an exhibit hall lined with booths showcasing the latest solutions from leading DevOps companies. In the exhibit hall, attendees can download resources and interact with partner sponsors including Codefresh, GitLab, WhiteSource, DBmaestro, Harness, Traceable, OutSystems and more.

    Breakout sessions and panel discussions will fall under following topics:

    • Leading digital transformation
    • Emerging technology
    • Security and audit
    • Modernization tools

    Attendees can participate in a scavenger hunt throughout the virtual environment for a chance to win amazing prizes. Participants earn points by visiting booths, watching sessions, downloading resources, networking with speakers in the chat and finding hidden objects in the environment.

    Registered attendees will also receive a link to access the virtual environment on-demand for a limited time once the live event is over.

    To see the full agenda and to register, please visit the FinConDX website.

  • Why Banks Must Ditch the ‘Build vs. Buy’ Mentality and Embrace a Platform Approach

    Why Banks Must Ditch the ‘Build vs. Buy’ Mentality and Embrace a Platform Approach

    The past decade has seen digital transformation change nearly every aspect of our lives, and banking has proven no exception. Indeed, proprietary data from Avoka shows that in mid-2017, mobile overtook desktop as the most popular channel for applying for new deposit accounts at one top 10 U.S. bank. Banks have accordingly ramped up their IT departments and technology investments to adapt to this brave new world and digitize their offerings, with the aim of making their financial products just as accessible and convenient as products offered by tech customer service giants such as Amazon.

    The push to make banking products digitally ready (and very quickly) has spurred the old “buy versus build” debate in bank IT departments: Should we build our own digital onboarding software from scratch in-house, or do we buy off-the-shelf solutions from third parties that may be generic and not customizable to our brand and product offerings? While this dichotomy may have been a suitable mentality years ago at the start of the digital transformation revolution in banking, it no longer fits with the reality of today’s more complex development landscape and is starting to cause significant problems in bank IT departments.

    It’s no mystery that the majority of today’s banking IT projects use elements of both “build” and “buy.” But banks tend to opt for the “build” option in the main, reasoning that in-house development drives better outcomes. But this is a serious misconception—recent research from Forrester shows that more than half of all banking customer experience projects take longer than expected, leading to a blown project budget an overwhelming 88 percent of the time. A critical point: Projects using or re-using internally built components are far more likely to suffer these issues.

    This inevitably leads to a spiraling buildup of technical debt—a concept that banks should familiarize themselves with and treat just as seriously as actual debt (after it, it ends up in the bottom line—total cost of ownership is higher for internal builds around 64 percent of the time, as per Forrester’s research). A snowball effect takes hold: Projects with problematic delivery are far more likely to require endless catch-up fixes and high maintenance costs, draining time and resources from the development team that otherwise could be put to use on the increasingly crucial work of updating the offering to meet the continually evolving needs of the market and customers. On average, one-third of customer-facing software releases are updated only once a year or less, a number that rises closer to half for projects that are over-budget.

    Forrester’s research shows that this isn’t a matter of under-resourcing; teams report being allocated the right amount of time and resources. Rather, stumbling blocks stem from architectural inflexibility and poor technology, as well as changing business priorities sapping stakeholder enthusiasm and project velocity.

    Neither “build” nor “buy” in the older sense of the two approaches provide an adequate strategy for today’s development environment. The aversion to buying mainly took hold during a period when third-party products were fairly self-contained black boxes—off-the-shelf offerings that provided none of the flexibility of in-house and came at a cost to branding. However, this is no longer true of the third-party vendor landscape. The advent of platforms and APIs means it is now far easier for banks to bring in multiple fintech integrations to fill the gaps in their offering in a modular, “mix and match” manner—all fully customizable, extendable, flexible and capable of being brought together on an organized, neat platform.

    Banks need to embrace this change and ditch the old “buy versus build” debate that so often prioritizes internal builds as a knee-jerk reaction. The constraints of the old build or buy choice means that the tendency is still to think of digital transformation as a series of off-one projects, when the most successful efforts treat it as a holistic, continuous evolution. After all, customer needs and expectations are constantly evolving, and so should customer-facing software.

    So, how should bank development teams and their stakeholders approach a new digital transformation project? The answer lies in BBEA: Buy, Build, Extend and Assemble. The rule of thumb here is that where services and capabilities are generic and not unique to the bank, they should be sourced from expert vendors with a proven ability to get the job done quickly and in an expert manner (why incur a longer development cycle and higher TCO by reinventing the wheel and building internally?). This frees up the bank’s own internal resources to work on building elements that are truly unique to the bank’s value offering. While it used to be prohibitive to pursue both of these approaches simultaneously, this is precisely what the new world of APIs and platforms enables.

    Sourcing and extending components in this way reduces technical debt significantly, and spreads the cost of R&D across external players. The platform approach makes it far easier for banks to tailor these external components to their own brand and specific circumstances, and makes adaption to changing future needs far less onerous, removing the tendency to revert to big and costly start-from-scratch projects on a regular basis.

    Banks that want to get ahead in their digital transformation strategies must their ditch old development habits and embrace the new platform approach. Buy vs. build is dead; long live BBEA.

    — Steve Demchuk

  • Simplifying Through DevOps in Banking

    Simplifying Through DevOps in Banking

    There are a great many assets available on the internet that talk about what DevOps is and how far DevOps adoption has come. So we will not repeat the “what” and the “how far.” Instead, we will focus on the road ahead and future of simplification and transformation at banking organizations and the role DevOps is likely to play in the same—in all three areas of “Run the Bank (RTB),” “Change the Bank (CTB)” and “Transform the Bank (TTB).”

    Figure 1: Change-Run-Transform Bank – POA with DevOps Maturity

    In this article, we take a look at what shape we think DevOps-driven simplification in financial organizations can take in the near future and also some opportunities for such simplification. As depicted in Figure 1, with DevOps maturity, the siloed processes of CTB, RTB and TTB will come closer together, allowing common activities and processes to be carried out in one place. The others will get simplified and automated thereby reducing elapsed time of cycle from ideation to production and application management drastically. This will yield benefits not only in terms of cost and time, but also in terms of feature availability to business.

    Banking Focus

    In banking, the early adopters are leading the march with a lot of good practices such as standardized tooling for specific technology areas, orchestration, feedback loop setup, process and technology rationalization, etc. The focus needs to continue on the same.

    We think that the challenge that DevOps architects need to now focus on is to be able to use DevOps to help financial organizations bring down the non-discretionary spend by simplifying the previously ignored maintenance, operations and infrastructure realms. The core of this DevOps driven simplification is needs to be move cost of maintenance to its lowest possible and hence releasing funds to discretionary areas in “Change the Bank” and “Transform the Bank.”

    While the point of arrival for DevOps-led transformation should be “full automation” and “zero maintenance” but they are a bit far in the future because the return on investment (ROI) on the monies and effort required to make that happen needs to justify the same. We see the focus shifting to value delivered to business by transformation of an application or suite of applications. Figure 2 depicts the core repeatable activities of a DevOps-led simplification exercise while keeping in mind these improvement cycles need the setup of feedback loops at each stage.

    Figure 2: Repeatable activities for DevOps-led simplification

    This brings us to our next idea, that the road map to DevOps-enabled simplification needs to be paved with metrics and measures and these metrics cannot be randomly chosen. These metrics have to be actually measurable and be divided into two areas of business metrics and IT metrics as we explain below and need to be diligently tracked to aid course correction.

    For example, release orchestration processes for applications are mostly complicated, need a lot of manual effort, have strict compliance requirements as well as security mandates, need to be carried out more frequently nowadays because of shorter deployment cycles and have to manage ever-increasing complexity of component interaction (upstream and downstream). Now, release orchestration is also a very important step in the entire CI/CD pipeline. So standardization and simplification of release orchestration process makes immense sense. But how does one measure success and quantify improvement?

    As already stated, intelligent insights (metrics and measures) are important in this process for both business and technical team members so that everyone has single source of truth for current status and distance from end goal. This kind of automation also helps focus on the continuous improvement pillar of DevOps adoption by logging everything that matters, have frame-by-frame data for everything that helps. This collection of metrics aids analysis of success as well as failure thereby furthering the cause of continuous improvement.

    Continuing with the example of release orchestration, there are many important best practices that help ensure that wheel is not reinvented. Some of the important learnings that only practitioners will be able to let you in on are as follows:

    1. Tools that need scripting will not be able to help you scale and create low-maintenance solutions.
    2. You need to invest in tools/orchestration solutions that help you visualize, get intelligent insights in a jiffy and can report in a variety of forms and shapes.
    3. Tools need to be able to capture and track business metrics, too.
    4. You need to spend effort on organization level compliance and security.
    5. Strive to automate your most effort-intensive and/or lengthy processes.

    Each step on DevOps maturity scale will have many such learnings and best practices that must get shared across the length and breadth of the organization.

    DevOps and Banking: Future Trends Prediction

    Based on our understanding & knowledge of financial organizations, we believe that the following areas will see focus in the next few years:

    Figure 3: Trends in short-medium term in DevOps adoption

     

    Continuous Improvement within Federation

    • Technology teams will need to enable and encourage localized innovation within a federated boundary of toolsets that will, in time, bring Dev and Ops toolsets to near mirror images of each other.
    • By federation, we mean a detailed homogeneous blueprint that gives flexibility but within an overarching boundary of tools and procedures while encouraging continuous improvement.
    • This must also inform relevant stakeholders about areas for continuous improvement that make the most evolutionary impact to business and use metrics suitably to track and reward improvement.

    Outcome Management

    • We also think that DevOps adoption needs to be driven by outcome management with evidence of impact taking the driving seat for road map management.
    • Focus will be on point of arrival (POA) and continuous measurement of business and IT metrics for outcome management.
    • We also believe that Culture-Automation-Lean-Measurement-Sharing (CALMS) model of DevOps will find more believers.

    Evidence of Impact

    • Metrics and metrics-based course correction will become the Holy Grail in the simplification exercise. The metrics collection will need to focus on areas of both business and IT. The metrics and measures will need to be redefined as:
      • Business Metrics for business value delivered or improved such as new products / services launched, conversion rate, net promoter score (NPS), customer retention rate, CSAT, ESAT, etc.
      • IT Metrics for value improvement and value management such as cost performance index, reduction in defect debt, reduction in lead time to change, etc.

    Design Thinking

    • We believe that the next big disruptor in this space will be bringing design thinking into the mix to ensure that DevOps-led automation is more customer-centric and iterative.
    • We see focusing on test data management (TDM) across the organization as an important step to ensure continuous delivery.
    • In our opinion, the testing process will undergo complete rethink with support of processes such as risk based priority and risk based test case design, test bed splits, TDM and so on.

    KM, Training and Governance

    • Tools and processes for knowledge management, training and governance need to ably support the DevOps-led simplification.
    • These processes will need systemic focus to create and nurture self-learning technology teams.
    • Transformation of the way of working to rationalize processes such as collaboration for lean and improved handover of work packages.

    DevSecOps

    • Security will be extremely crucial in the process of DevOps-led simplification. All the automation, cloud adoption, pipeline creation, IoT adoption and more is throwing up many new security concerns, thereby leading to a focus on DevSecOps.
    • Security processes will potentially need to move their execution points up in the CI/CD pipeline and be divided into stages based on iterations sizes and deployment cycles.
    • Focus on shifting left application security and role-based security.

    Conclusion

    The next wave of simplification of IT spaces in banking organizations will be aided by DevOps. To look for opportunities, a systematic approach toward DevOps will help—it will be perilous to ignore detailed assessment of existing spaces that will detail the current state, point of arrival simplified state, road map for simplification and the key guiding principles for the transformation.

    Carrying out pilots and proof of concepts in DevOps is not a problem; the challenge is with scaling—in all areas: tooling, training and processes. The key is to manage the horizontal and vertical spread of same/similar toolsets that also help drive efficiency associated with scale and standardization. DevOps-led simplification will need changes to processes, technology and people management (culture). The current role structures might need to be demolished to ensure there are no fiefdoms and cross-functional teams handle all requirements of Dev-Test-Ops. Finally, all the changes need to be able to define the new way of working  so that Change-Run-Transform organizations can be brought together.

    This article was co-authored by Babu Unnikrishnan, Head, Banking & Insurance Technology Group at Tata Consultancy Services.

    — Anshu Premchand

  • DevSecOps: Critical in Building the Bank of the Future

    DevSecOps: Critical in Building the Bank of the Future

    It is no secret that change in a large organization can be difficult. This is often true within banking, an industry that often has sought predictably instead of agility in software delivery. However, with the right tools, guidance and teams, creating a bank that can be both complaint and responsive may be more attainable than initially it may seem. For a digital bank of the future to emerge from a heritage of independent application, information security and operations departments, an organization should embrace new technologies that can unify these groups and improve the ability to respond to change more quickly.

    Read on to learn why the inclusion of information security within DevOps practices can play a key role in establishing a bank of the future, and why it is important.

    Digital-Only Banks Gaining Ground

    One of the shifts in the distribution of banking products is the movement from primarily branch-based banks to digital-only banks. In fact, Citizens Financial Group launched a digital-only bank in July of 2018 to appeal to a growing number of digital-first customers. JPMorgan Chase also has a new digital banking offering, Finn, aimed at millennial customers.

    While digital-only is meant to simplify the end user experience, it complicates security because it increases the number of attack vectors within the digital channel. In effect, bank security is judged not by how well physical transactions are protected within the branch (think bank notes and checks), but how well digital transactions are protected over the internet. This can require a commitment of applying security controls while also honoring agile delivery practices. In turn, this developmental agility can be more effective when it is part of a responsive organization—one that is willing to adapt and adjust quickly, often requiring institutional culture change to an organization that is more transparent, open and ultimately innovative.

    Incorporating Security from the Get-Go

    To be more responsive while at the same time hardening security, adapting to DevSecOps methods is becoming important in the journey to be a bank of the future. DevOps should never be only about the development (Dev) build and operations (Ops) implementation—it should have security in the middle (Sec). Information security should play an integrated role in the full life cycle of apps. DevSecOps can remove the isolation and boundaries that previously existed between the security team and the rest of the organization, and it brings security smack dab into the conversation, rather than as a part of a deployment checklist. With service level expectations from release cycles going faster—from months to weeks or even days—integrating and automated security into the delivery process can be even more critical. In a DevSecOps application methodology, digital bank initiatives would build security into every touch point from the very start.

    How is Information Security Evolving in Banking?

    Banking, like all other aspects of our lives, seems, to be  transitioning to a smartphone transaction. Deposit and savings accounts can now be fully opened and closed through the digital channel. Information is exchanged digitally and the process is often painless. Information security becomes even more critical to help make  information safe and secure from potential fraudsters.  So while these types of transactions are often expected by consumers, it is important to have proper security measures in place and that can be fully automated and throughout the development process.

    The Organizational Change to Embrace the Future of Banking

    The future of banking will not happen exclusively just by changing technology and tools. It can often be successful when it is adapting organizational change at the same pace as technology and Agile best practices, such as DevSecOps, can also be applied to cultural transitions. To prepare organizations to be successful, there should be clear commitment by leadership across applications, operations and information security; otherwise, the change may never be fully absorbed into the organization. The bank of the future will be more likely to be successful if it functions as part of an ecosystem of interdependent and more securely connected people, processes and technology to have the structural support in place to successfully engage.

    — Eric Marts

  • Why Open Banking Should Consider DevOps

    Why Open Banking Should Consider DevOps

    There is a craze sweeping Europe, and rippling across the world—and no, I’m not talking about the next British Invasion. Open banking is a trend that’s significantly altering how banks work with fintechs and maintain agility in the global marketplace.

    A main enforcer is PSD2, a piece of EU legislation that sanctions access to personal banking data. It’s resulted in an explosion of EU banks providing public application programming interfaces (APIs) for fintechs to develop with. The implications aren’t limited to Europe; many banks all over the world are looking to PSD2 as a baseline, forcing some tough evaluation of how financial architecture should adapt.

    Banks are also under consumer threat to evolve or get out — a 2016 Accenture study found that 78 percent of respondents would bank with a tech firm such as Amazon or Google.

    As banks transition into savvy software providers due to market pressure, one thing is certain: they must adopt agile software development strategies that streamline the deployment and maintenance of these services. In other words, banks must adopt a DevOps philosophy to maintain a market advantage.

    Open Banking Evolves Bank Architecture

    The bank has become programmable. Many banks are now required to allow third-party authentication and access to payment, account information, fee details and other data. This involves support for various integration methods; SDKs, APIs and OAuth for authentication, as well as documentation, sandboxes and other developer tools. Whether they like it or not, banks are now SaaS providers.

    It should be noted too that open banking is not limited to the European Union. The UK’s open banking standard is the Competition and Markets Authority (CMA), and Australia, Japan and other countries are making similar inroads with regulating banking data. The excitement has also encouraged North and South American players to open up.

    The new bank APIs help bypass traditional methods, saving a ton of time. In an article in American Banker, BBVA noted that online e-commerce system Dwolla was able to slash the typical three-day to six-day deposit time frame using their payment APIs. “We’re allowing that all to occur in real-time,” said Chad Ballard, director of mobility and new digital business technologies at BBVA Compass.

    Letting FinTechs focus on web UI development helps banks focus on their core competencies: banking and authentication. Establishing connections via API-driven microservices is also a safer alternative to screen-scraping.

    Why DevOps for Banking?

    Banking Exchange defines agile banking as “the future of retaining relevancy for banking as a whole.” For open banking to be successful, the platform must be tested, monitored and secured for fintech consumers. Sounds a lot like the hallmarks of quality DevOps practice.

    Popular services Google Maps, Uber, Stripe, Twilio and others have adopted an API-as-a-product mentality. These programs adhere to best practices, iterative feedback and agile development methodologies to excel. Similarly, for banks to remain competitive, they must treat their platform architecture and public gateways with the same tenacity.

    For banks, uniting iterative development with stability testing—essentially the Dev + Ops mantra—for their APIs, microservices and frameworks will go a long way to help reach open banking goals and maintain future regulations on API performance standards.

    A DevOps mindset is crucial to consider early on in the open banking journey, as it can impact how banks address:

    • Iterative development and testing: By tying in iterative development with stability testing, organizations can surpass the time limitation often incurred between shipping versions between development teams and testing teams.
    • Continuous monitoring: Many tools are available to monitor the CI/CD pipeline, helping banks respond to issues and improve uptime.
    • Versioning strategies: DevOps in banking will see the larger picture, working in the REST mantra to build on the scale of decades to avoid breaking change.
    • Transition to microservices: As enterprises dispose old monolithic architectures, bitesize services are arguably more appropriate for modern banking; however, they come with unique caveats that DevOps can address.
    • Collaboration between silos: By pivoting to more point-to-point, collaborative processes, banks can reduce friction to meet the responsive expectations set by FinTech, who are becoming new public faces for banking.

    An end result of DevOps is to increase agility in an organization. Especially for large banks, this signifies drying up the traditional “waterfall” development life cycle known to stigmatize the corporate approval process.

    Case Studies: How Banks Are Utilizing A DevOps Cycle

    Many banks have been vocal about what they are doing to ignite positive technological innovation alongside third parties. For example, Capitol One’s DevExchange recently announced a new initiative called experimental APIs. “They are designed with the goal of getting early feedback from the community around API desirability and design before the product release,” the company noted in a blog post.

    In this experimental setup, operational cues inform development. Getting the two sides to talk and respond to community feedback is paramount for DevOps to succeed.

    For banks to adopt an agile makeup, Manfred Bortenschlager, Red Hat’s director of Business Development for API-based Integration Solutions and API Management, recommends what he calls an “agile integration.” This involves a distributed integration for greater flexibility, containerization for the ability to scale better and managed portals for reusability.

    Another interesting effort is that of CIBC, a Canadian bank that is responding to the open banking movement with a responsive microservices framework the company has developed using open source components.

    What’s evident is that many banks already acknowledge DevOps principles as key for innovation in their sector. Through the the use of iterative testing, innovative tooling and automated workflows, banks can achieve greater operational efficiency.

    Open Banking Must Follow Software Development Practices

    A result of the open banking movement is that banks must keep technological pace with fintech. Especially with regulatory pressure, banks must consider how best to approach new technological initiatives.

    DevOps is a way to mitigate concerns. As a philosophy for uniting technical procedures with responsive operations, it’s a prime strategy for banks to consider when readdressing their technology.

    In defining what “agile” embodies for banks, Steve Williams of Cornerstone Advisors said: “The idea is you need to start taking the management and operations of a financial organization and start adapting some of the things that have made technology companies viable.”

    American Banker echoes this, believing that “banks should be more like software companies.”

    Now prodded by open banking, it’s high noon for luddite banks to embrace contemporary software development practices; that means incorporating DevOps into the open banking agenda.

    — Bill Doerrfeld

  • Bucking Bank Bureaucrats: From Convergent Thinking to Divergent Doing

    Bucking Bank Bureaucrats: From Convergent Thinking to Divergent Doing

    As customers, longstanding and new, the way we interact with banks and manage our personal spending, borrowing and saving is experiencing drastic change. New digital offerings in the form of apps and online banking show commitment to customer centricity, but overall, banks are slow to adapt to the pace of change. The vast majority of bankers do recognize the strategic need to respond to their industry’s digital disruption, and are busy assessing and developing transformative technologies such as mobile, blockchain and artificial intelligence, trying to find an emerging market need and a robust business model.

    How Should Banks Adapt?

    The operating environment of banks is unpredictable and, therefore, requires organizational agility. This agility requires a careful analysis of customer needs and (potential) capabilities. Bankers must ask, “How can my bank move from convergent thinking to divergent doing?”

    picture1

    From a strategic perspective, it’s essential to understand whether the person/organization wants to be a disruptor, innovator, ideator or bureaucrat. This differentiation defines the right strategic options available to them.

    N.B.: A quick proxy answer to the above question is the design of the bank’s reception and organization of the people working there, to see if it is like every other bank, or is in some way distinctive.

    Value Triangulation and Differentiation

    Every banking CEO needs a clear strategy that addresses their organization’s internal and external challenges. There is one global commonality for a strategic foundation: Every bank needs to deliver change rapidly and frequently. The better a bank is at improving customer experience, the more likely it will survive the onslaught of disruptors and innovators. Additionally, most banks must deliver cost reduction and drive income. Customer desire, the third corner of the triangle, is not a familiar banking concept, but a successful value triangulation delivers customer desire in the most efficient way possible.

    picture2

    This isn’t about value chain mapping and cost re-engineering; it’s about creating great customer experiences with adaptive capabilities and capital-light business models. All three values must be understood and practiced throughout the entire organization, especially among boards, chief executives and key decision makers to make adaptive banking possible.

    Customer Experience Comes First

    A culture of centralization, product-centricity and control-via-process stifles change. To be adaptive and create their own Digital DNA, banks must form new work spaces and ways of working. When bank employees don’t use their own company’s products, they are out of touch with the customer experience. They also may excuse customer complaints based on their organizational knowledge. Employees need to be the bank’s most critical customers, and ought to feel fully connected to other customers and their experiences.

    New, lean business models should flow through the organization and align to the desired customer experience. The business leaders who identify the “priority customer experience features” will focus the organization on accelerating delivery momentum. Rather than requesting large-scale, product-led programs, leaders need to focus on continually launching and redefining small-scale features.

    picture3

    Doing so moves away from the grand strategies or silver bullet approach so often prevalent during annual planning cycles and shifts toward agile, customer-centric strategies. Organizational change is fundamental for creating adaptive banks with Digital DNA.

    Fail Fast, Succeed Even Faster

    To accelerate growth, adaptive technology architectures and agile software delivery methods need to be available to deliver the relevant features. A “deliver, measure and learn” approach will amplify feedback across the organization to drive commercial decision-making. This will allow banks to fail fast, yet succeed even faster. The ongoing cycle—ideating, designing, building, shipping, measuring, learning and (of course) adjusting customer features—needs to become the norm.

    By becoming adaptive, the bank’s capabilities (people, methods, technologies, values) become more attuned to customer needs, making it far easier to deliver personalized offerings. For example, the bank’s data can be used to create feature personalization, allowing customers to pick and choose the right features for their needs. A customer should always be able to overwrite the choice an algorithm provides.

    Innovation, Transformation and Beyond

    Currently, the most apparent transformation desire and delivery exists in IT departments as opposed to business departments. Agile ways of working are often still alien to most bankers in product, finance, compliance, marketing and front-line teams.

    The banking playbook has already been rewritten for the digital age. It’s an exciting time to realize great change and how disruption/innovation can become commercial reality—this means bucking the system.

    About the Author / Darren Oddie

    Alistair Bayliss

    Darren Oddie is strategy director at Wipro Digital, where he works with global financial services companies on digital transformation and innovation. He’s had hands-on experience of designing and building financial services brands from a blank sheet of paper to industry leading propositions in both corporates and startups. He’s delighted that banking and customer experience are now regularly mentioned in the same sentence. Connect with him on Twitter.