Blog 1 of 3 – Technology Infrastructure Architecture

As I mentioned before, I’m not a technologist. For this first blog on this topic, I decided to hone in on the infrastructure problems plaguing the banking part of the financial services industry to understand more of the technical challenges I’ve heard about over the years in my business architecture role.

Here are some of the highlights that resonated from a Capgemini article:

• Core banking systems (legacy) were developed 20-30 years ago in a siloed manner.
• Communication integration points differed between these siloed systems—they each had their own protocols.
• Maintaining the integration points became very cumbersome which equates to expense.
• Documentation upkeep was inconsistent so solutions were set-up separately to achieved desired (sometimes duplicative) needs.
• Add in the decades of layered functionality added over the original infrastructure, and systems became more and more complex to maintain.

It’s a known fact that at some point, these outdated infrastructures will impede growth.  So why don’t more banking institutions replace their infrastructures?  This article by Deloitte made a strong case for the why:

• Business leaders are so short-term focused, it’s hard to justify the return levels for such a large investment—the IT maintenance cost reductions are a drop in the bucket so to speak.
• Even if approved, there are many examples of how large endeavors of this type come in way over budget or completely failed.
• Endless number of other examples show that IT outsourcing has resulted in poor results.

After researching this topic, it’s easy to empathize with business leaders who have to put their careers on the line to endure/justify this type of transformation and to understand why so many choose the “path of least resistance” (incremental changes to legacy systems).

Blog 2 of 3 – Technology Infrastructure Architecture

For this second post, I decided to research the IT infrastructure issues plaguing the insurance portion of financial services.  Much of what this Onbase whitepaper outlines mirrors the pains outlined by the banking sector (Blog 1 of 3), but provided more detail which made the points resonate more with me.

• Band-aided and siloed systems: Business lines are best positioned when they can reuse (versus recreate) data across systems.  As with bank, insurance legacy applications have been hardcoded together—not how they were intended to be used.  Many are opting to recreate the data which is not ideal for functional or financial reasons.  In addition, they take the business silo to further extremes by having channel-centric systems. So, if insurance customers provide information in one channel process, stop, and try to pick up in another they have to re-enter the data all over again.  Not a good customer experience.
• Growing maintenance and staffing costs: I’ve presented the cost issue with bank, but something I’ve professionally experienced more in insurance than bank is the unique programmers required to maintain the insurance legacy systems.  Most legacy programmers saw “dying languages” on the wall and re-trained.  Those who stayed can name their salaries.  In addition, attracting top talent means you have the latest technology. With insurance companies stuck in the dark ages, they are facing talent shortages.
• Compliance and regulatory concerns: New lens on this issue that I didn’t realize—legacy systems were not “designed to live up to today’s stringent compliance standards like internal audits, Sarbanes-Oxley (SOX) and Health Insurance Portability and Accountability Act (HIPAA).”
• Limited innovation opportunity: Technical resources are too busy keeping these legacy systems running.  There’s limited opportunity to innovate for new products and services like the Internet of Things and Telematics, which are heavily dependent on flexible data infrastructure.
• Prohibited business insights: Because legacy systems are built with data-driven languages, it’s very challenging to identify process issues, trends, and workload needs.  The architecture of these systems create “great repositories of information, but they can’t be counted on to draw conclusions or make predictions based on the information contained in them.”  And, we all know, that business leaders want/need real-time information to make in-the-moment decisions.

Two years ago, I developed the property line leader’s target state for our P&C business.  By researching the insurance infrastructure challenges for this blog, I got to a more granular appreciation of the issues he faces—in addition to seeing the EA vertical thread possibilities to the bank portion of our larger financial services eco-system.

Blog 3 of 3 – Technology Infrastructure Architecture

For this final post, I want to focus on the technology standards for the financial services industry.  I worked in the food services industry in EA in a past life.  There, we called these standards “architecture principles” and they were outlined in the EA charter, and we all lived by them.  Any deviation from the principles required a waiver with a remediation plan.  In my current business architecture role in financial services, we don’t have a formal EA, nor such principles as far as I know.  If we did have such EA charter, I wanted to get an idea of what principles it could contain.  This IBM article, titled “21 principles of enterprise architecture for the financial sector,” outlined some of the principles I would expect to see:

• IT and business alignment: IT decisions are always made under the business alignment perspective to achieve maximum company benefit.
• Business continuity: Despite IT changes, the business must continue to operate without disruption.
• Adoption of market best practices: IT activities must always be aligned with market best practices for governance, processing, and management.
• Information as an asset: It’s valuable and will be guarded and maintained for its value.
• Information sharing and accessibility: Information should be easily shared and accessible by permitted roles and across entities.
• Technology independence: Applications do not depend on specific technological options—they can operate on different technology platforms.
• Application usage: Applications should be easy to operate by its users.
• Component re-usability and simplicity: Enterprise architecture is implemented over low-coupling, reusable, and modular components.
• Technical diversity: This is minimized to control maintenance costs.
• Supplier control: These are minimized to control management costs and reduce risk.
• Low-coupling interfaces: Interfaces are low-coupled and are self-described as to have less risk of impact on the financial services operations.

There were several more, but these resonated most based on my earlier banking and insurance research and personal experiences.