The Key to Going Digital

The Top Three Reasons for Considering Core Transformation
July 12, 2018
Data is the New Oil
December 3, 2018

The Key to Going to Digital

Digital. This word is heard so often in business context it’s become ubiquitous.
Yet it’s a word that can’t be ignored.

At its most basic level, being a potent digital enterprise means that your organization has developed the means to reach and effectively service customers through everyday channels (e.g. mobile and web) and emerging ones, like Alexa. It’s accomplished through developing or acquiring digitally composed assets and then deploying the technology.  From the customer-facing perspective, this technology must be intuitive, easy to use, and pleasing to the customer. From the company-facing perspective it needs to integrate seamlessly with back-end platforms, applications, databases and other necessary technology components.

In addition, this front-end technology must provide relevant content that keeps the customer coming back – even a great digital experience that doesn’t have applicability to the customer is akin to building a beautiful sports car that runs like a Yugo.

Why is going digital – and being good at it – important?  Look no further than real-life examples: Amazon and Netflix are the paragons. Others, such as Uber and Dollar Shave Club, continue to upend their industries. The world itself is going digital and beyond.

For the customer, banking itself is not trendy, it’s a necessary activity, but it’s possible to turn even an everyday occurrence into a digital experience. For example, The Dollar Shave Club managed to turn a mundane, sometimes painful experience into something fun through advertising and customer interaction. That company has learned to create a digital experience the customer enjoys.

How Does a Bank Go Digital? 

Many would assert they already are digital, declaring

  • “We have a mobile and web app.”
  • “We are doing analytics to ensure we make relevant offerings to our customers.”
  • “We are continually pursuing how to make the digital experience better for the customer.”

It’s not to say these efforts haven’t been successful.  A bank may offer a good digital experience. They may score highly compared to peers when comparing customer satisfaction. The apps may be easy to use. However, in the U.S. banking space most banks have surrounded antiquated core systems with a digital look and feel – this typically amounts to “Digital Window Dressing.”

The true benefit of digital is better services and improved customer experience through direct access that allows for self-service and speedy processing; the ability to allow the customer to initiate their own loan request through an automated loan request process with real-time underwriting decisioning, followed by loan documentation that is automatically produced and signed electronically, leading to a loan booking that can occur without back office intervention. This type of straight-through, seamless customer experience is not possible without digital systems that are integrated with a modern, real-time Core.

Some banks have pursued digital through integration between modern, front-end applications and an updated services layer. These banks are in a better place for having taken the digital front path; yet they are realizing the Core still must be addressed due to time-to-market delays for digital initiatives stemming from integration complexities with legacy systems.

Additionally, the high operating and maintenance costs of legacy Core systems diverts funds that could be invested to enhance the digital customer experience and make other critical advancements. In summary, unless an organization is able to offer this type of truly self-service, end-to-end experience, it is operating with a digital tablecloth.

Regardless of where the organization is on the digital spectrum, there must be an honest evaluation of the current state, and a strategy and roadmap to achieve the desired state. The organization then has a choice as to where it goes, what it does, and how it does it. For example, a single digital platform – one that services all business lines and customer segments – can have huge benefits to the organization in terms of consistent customer experience, employee support, and technology simplification.

No Silver Bullet

In truth, there is no single strategy to fit every organization. However, the factors that impact the strategies are common across all companies, regardless of industry, location or culture.

Understanding these factors is critical because it will lead to the right strategy for that organization.  These factors can include

  • the organization’s risk appetite,
  • it’s willingness (and ability to) change,
  • the urgency of broad market forces,
  • the internal push from either the Board or Executive Management,
  • the clamor from employees for better systems and experiences,
  • customer complaints and feedback (the most important of all factors).

In developing the right strategy for your organization, the answers to these factors need to be considered.

Digital Principles

In the ideal state, the customer would enjoy a true, end-to-end self-service experience. However, this is often prevented due to disjointed point solutions that are not well integrated. By disjointed point solutions we mean a system that is implemented to address a specific problem, but this system is not part of a larger strategy.

There are a few principles and practices to be followed when developing an ideal digital strategy:

  • Provide a consistent, intuitive user experience across all channels
  • Employ an open API-driven, extensible and configurable architecture
  • Ensure the solution is designed to allow for quick introduction of innovations for competitive advantage and enables effective understanding and anticipation of customer need
  • Use current cutting-edge techniques, such as responsive design

For example, it’s critical to view the digital experience from the customer point of view – typically done through the use of customer journeys, which in turn become (effectively) high level business requirements.

From that exercise, technology strategies can be deployed that vastly improve the customer and employee experience. These strategies should be aligned with key principles of ideal-state digital technology, such as a single-digital-platform concept, and a technology that is easily scalable and can support quick introduction of new products and innovations for competitive advantage.

Customer-focused thinking also can help a bank determine what it wants to look and feel like as a digital organization. For example, do we want to provide an end-to-end lending experience, where a customer can initiate a loan request and go through the entire process through funding without human intervention?

Technology strategies can also be developed based on answers to the following:

  • What new technologies (and technology practices) do we need to embrace?
  • How will our current technology influence our ability to achieve our goals?
  • What is the impact of addressing our current technology stack?
  • What is the impact of not addressing our current technology stack?

Ancillary discussions branch off, such as:

  • It may be less painful in the short run to not address underlying legacy technology. But is this the best strategy to pursue?
  • If we can work around it, will it ultimately come back to bite us?
  • Will our focus on the immediate need detract from achieving a better future state (by adding complexity)?

These are all questions that need to have hard dollars and cents applied to them.

Again, there is no silver bullet. The strategy will depend on the company’s situation, the strength of the factors in play, and culture.

The Ultimate Key to Going Digital – and it’s not about Digital

This article is entitled “The Key to Going Digital”. But I’m going to assert that the ultimate key to going digital is not about digital.  What does that mean?

Let’s go back in time over a hundred years ago. Henry Ford was determined to figure out how to mass produce a new way of transportation. His quote, “If I asked people what they wanted, they would have said ‘faster horses’” remains a classic to this day.

Henry Ford did something that no one was able to do previously. Yet, fundamentally, it wasn’t about making cars. It was about thinking differently. He had conceived a way to do something no one else had done.

The Digital Revolution, like the Technology Revolution, and the Industrial Revolution before that, is simply the latest in a long line of revolutions. We are warned that more will come, with increasing speed and shorter cycles.  So, in the midst of this dizzying change, what is the key? What will allow an organization, particularly a bank, to survive and thrive in a sea of change?

Going Digital is All About Enterprise Agility  

We would submit that if an organization is struggling with becoming truly digital, this is a symptom of a larger challenge – that of not being an “agile” organization. No, we’re not talking about Agile/Scrum software practices; We are talking about the true meaning of agility – the ability to move, think and understand quickly and easily. Digital is simply another revolution in a long line of revolutions that exposes a company’s agility (or lack of).

For example, trends such as Artificial Intelligence (AI) and Virtual Reality (VR) are anticipated to be the next technological shifts that will upend entire industries and change the landscape. No one truly knows what shifts will fall out of these earth innovations.

The current goal should not be simply to “Go Digital.” The organization itself must become an agile enterprise, one that can react at the speed the market dictates; it will be able to combat whatever it faces whether from the market, competitors, or technology advances; it will be able to see what is coming, prepare for it, respond to it, and take advantage of it forcefully and with confidence.

Benefits of Enterprise Agility

It’s likely a book could be written on this subject, but we will be brief, as we will be focusing more on how an organization becomes an agile enterprise. The broad benefits are clear, as noted earlier:

  • Better response time to market forces.
  • Quicker to pick up on trends and beat competitors to the punch.
  • More easily able to both recognize and adapt to technological advances and take advantage of them for the benefit of the organization and its customers.

Depending on the industry, basic survival of the organization may be classified as a benefit and a goal.

The targeted benefits are those of efficiency, cost reduction, force-fed culture change, higher employee morale, and an ability to react to business needs that has a cascading effect to the entire organization.

How Does an Organization Become an Agile Enterprise?

Addressing how to become an agile enterprise is more than just conceptual, soft-sell ideas – although those have their place.   “Culture Trumps All” is shockingly true, everywhere. But there are hard ways an organization can integrate agility, and it’s in relation to technology.

Enterprise agility means transforming into the type of organization that can react quickly to market forces, competitor innovations, and capitalize on its own treasure trove of ideas. And this means utilizing technology to achieve those means. Digital means that every company is now a technology company. So, it naturally follows that the critical need to be agile must apply directly to the technology of the organization; it’s tools, processes and people must be flexible, adaptable, and ready to react with as much speed as possible.

So, what does it mean to be an agile enterprise?  What can be done to integrate agility? How can I move my organization forward into the digital world and remain relevant?

Enterprise agility is conceptually simple yet requires effort to execute. Like my kids used to say when discussing an issue with me. “Dad, you make it sound so easy.”  I would respond, “I didn’t say it was easy, I said it was simple. It’s like digging a ditch.  The concept is simple.  The work isn’t easy.”

Creating an enterprise that can quickly respond is as simple as having a technology architecture that largely consists of small, logically organized components that can be built, modified, upgraded and deployed independently.  (The concept of digging the ditch.)  The effort lies in building, buying and integrating the technology in this fashion, which starts first and foremost with the culture and practices of the organization. (The act(s) of digging the ditch.)

What does this ideal look like, from the perspective of organizational culture and practices, and technology architecture?

Culture and Practices – The Ideal

Becoming an agile organization starts first and foremost with having a strategy and plan for technology, tools and business processes.

Every institution is made up of the Thinkers and the Doers.  The Thinkers want to take the time to ensure the right things are being done in the right way. The Doers are those that want to take action, yesterday preferably.  And they can’t understand why the Thinkers are hesitant to act.

While this is obviously an overgeneralization, there is some truth to it. Just about everyone has a bit of the Thinker and a bit of the Doer in them.

Culture and Practices sit a bit more heavily in the Thinker camp. Realizing that there is nothing more disastrous than enthusiastically heading down the wrong path, the way the organization conducts itself in relation to Culture and Practices is absolutely critical.

Culturally, these include principles such as:

  • Fail Fast
  • Embrace the MVP (Minimum Viable Product)
  • Incremental Wins

and practices such as:

  • Continual Business Process Improvement
  • Active Technology Management (e.g. continuous rationalization of the technology inventory and other practices)
  • Continuous Integration (CI)
  • Continuous Delivery (CD)
  • Deployment Automation

While Continual Business Process Improvement and Active Technology Management are fairly self-explanatory, the other terms mentioned above may not be broadly understood.

In laymen’s terms, Continuous Integration (CI) is a software development practice where members of the development team integrate their work frequently, at least daily.  The benefit of this type of practice is that each integration is verified and tested via an automated build that can detect integration errors as quickly as possible. Contrast this with legacy development techniques where developers often have code on their individual machines for days/weeks/months before they integrate with the larger code pool, and, as a result, the number of errors when integration happens are much higher, take much more time to investigate, and result in more rework overall – as an error that could have been caught early with continuous integration is instead perpetuated throughout the code.

Continuous Delivery (CD) is an extension of CI; it simply means that on top of automating your integration and testing, you have also automated your deployment.

There are other associated practices to CI and CD concepts, such as Agile/SCRUM practices (e.g. code sprints, test-driven development, etc), but fundamentally, CI and CD are cornerstones for DevOps.  DevOps, at its most basic level, means developing the practices and tools to be able to automate as much as possible the development, testing, deployment and delivery of small pieces of functionality. (Much more could be written on these subjects, the intent here was to mention them for context.)

Culturally, the resources in the organization – not just technology folks – are steeped in the concepts of a “quick hit” (e.g. deploying early and often), including incremental development, test and deployment.

The organization is comfortable with the “Ready, Fire, Aim” approach to getting things done.  This doesn’t mean sloppiness. It may mean that the organization allows risk taking and isn’t afraid to fail in order to succeed.

As an organizational leader I’ve always had the opinion that it’s better for the team to

  • fail multiple times to find the solution that then propels success by a factor of X than it is to
  • continue doing what we are doing, even though it’s not truly moving us forward.

If an organization has embraced the quick-hit and ready-fire-aim approaches, it will pave the way more easily for agility, such as CI, CD, and DevOps. Until an organization can change culturally to embrace these ideas, it cannot engage in the agility practices needed to transform. It starts with the culture.

Technology Architecture – The Ideal

We will dig a bit deeper here, as there is quite a bit the organization can do to integrate enterprise agility. The ideal organization that integrates agility — at 10,000-feet – will model the following

  • The technology that creates the bridge between front-end/customer-facing systems and the back-end/core/operational systems consists mainly of Application Programming Interfaces (API’s)
  • These APIs contain logic from underlying systems, bundled into services that are focused on business domains, processes and channels.
  • These services sit between underlying legacy and enterprise systems and allow them to communicate with front-end, employee and customer facing systems.

However, unlike a full-enterprise Services Integration Orchestration Layer (SOA), these APIs consist of small microservices that are independent of each other, small enough to be managed by a small team, and contain discrete functions. These functions are business and functionally focused. The advantage of creating these discrete microservice functions — when compared to a fully-integrated/enterprise-level SOA — is

  • avoidance of duplication,
  • increased agility/ ability to react to change, and
  • less cost to maintain, upgrade and operate.

In the banking world, for example, there may be a microservice focused on the customer account-opening process, or on depositing and transferring funds between accounts, or any number of customer banking functions.

Because industry standards exist for APIs in terms of the language they use to communicate from the source system, they are easy to implement. And, the developer can write the microservice is any language they choose.

In an industry filled with monolithic systems (such as banking), the idea of Enterprise Agility may seem a bit daunting, like colonizing Mars.  In reality, even the most agile organization will have a landscape that has a mix of microservices, APIs, enterprise platforms, and other technology.  There are drawbacks to implementing a microservices architecture, as it does create additional complexity. There is simply more to manage and orchestrate – although there are software platforms and tools in the market that can help an organization do this well.

There is simply more to manage and orchestrate – although there are software platforms and tools in the market that can help an organization do this well.


In Closing

An organization that can integrate these concepts and practices will be on its way to Enterprise Agility. It will be building into its fabric and culture the ability to identify change, plan how to address it, and then react swiftly.

No matter the revolution – Digital, AI, VR – or the solution to it – APIs, Microservices, Continuous Integration, Continuous Delivery, Deployment Automation – the key lies in the organization’s ability to integrate agility into their practices and systems.

The key point is that an organization that can react with agility – both culturally and technologically – will be able to weather whatever change comes its way, even the digital revolution.                                                                                                                                                            

CLICK HERE to receive a complimentary PDF of the

complete whitepaper: The Key to Going Digital.

AARON SCHLENZ, Managing Director, Core 20/20 LLC

Aaron Schlenz is a creative and dynamic financial services executive who has made a career of delivering groundbreaking and transformational efforts in support of business strategy across a wide spectrum of domains, including application, governance and operations. Complimenting his expertise as a highly effective cross-functional collaborator bridging operations, business and technology, Aaron possesses a natural ability to identify customer needs and partner for results, tackle ambiguous, complex problems, and develop workable solutions. Utilizing his skills in program and project management, execution strategy, and transformation, Aaron managed the successful Zions Core Banking Transformation program, with responsibility for planning, delivery and governance. In addition to Zions, Aaron has deep financial-services transformational experience with Fannie Mae and Freddie Mac. Aaron took his skill set and leadership experience and partnered with John Kershner to create Core 20/20 LLC. Aaron received his MBA from Mount Saint Mary’s University in Maryland, and his B.S. in Accounting from Illinois State University.

JOHN KERSHNER, Managing Director, Core 20/20 LLC

John Kershner is an executive leader with proven experience developing and executing strategies that deliver bottom line results utilizing creative abilities, knowledge and skills gained as a management advisor and coach. Key areas of interest include strategic technology management, business process improvement, change management, and organizational design and development. John successfully led three large core banking transformations and many other core and non-core technology improvement and replacement initiatives. Most recently, John organized and led the program for the first U.S. implementation of the TCS BaNCS global core banking platform at Zions Bancorporation. In 2018, John partnered with Aaron Schlenz to create Core 20/20 LLC. John received his MBA from The University of Texas at Austin, and his BBA in Finance from the University of Houston.


With proven leadership, real experience, and demonstrable results, we exist for no other reason than to ensure your success! To learn more about how we can partner to help you realize your vision, please contact us.

Leave a Reply

Your email address will not be published. Required fields are marked *