Quantifying Complexity – Changing the language not the conversation

For a mature bank the ability to address new requirements comes down to one thing; agility! To be completely clear I am in no way referring to the Agile software development method. What I am talking about is transforming a bank for quickness, lightness and ease of movement. In ongoing discussions I have been having on the topic the correlation between agility and complexity has become clear.

Nowhere in a bank is the correlation between complexity and agility more visible than in its technology group. A modern bank is, at its core, nothing more than services supported by technology. Technology is where the rubber hits the road in banking. The ability of a bank to meet market demand quickly with new services has a disproportionate dependency on its technology group. When a bank’s technology infrastructure lacks agility the entire bank immediately sees it and feels its affects. They see it in projects that have significant overruns in schedule and cost, or fail completely. Business groups see it when they ask for a single new data field to be added and are told that it will be an 18 month project with a $1.5 million dollar budget.

This isn’t due to incompetence, stupidity, or lack of talent or passion it is due to complexity. Ask the technology group why, what should be a simple project will take so long and cost so much and they will tell you it’s complicated.  Technology is the most visible example of complexity within a bank but only because it tends to be the longest pole in the tent. Complexity within banking extends into operations, processes, procedures, and organizational structure. Defining new requirements, detailing deployment plans, and developing training all take longer in a bank than is necessary because of complexity within the overall organization.

Historically we bankers have adjusted our expectations and learned to work within the complex systems we created. When I say we I mean it. I am just as culpable and complicit as the next guy in creating complexity. I’ve made decisions to save time and money on projects at the expense of future agility and I did it by adding additional complexity to the overall system.

Reductions in complexity will lead to increases in agility. Understanding and benchmarking your existing technology complexity is the logical and best first step. Measuring complexity and applying benchmarks to projects via initial solution planning will allow the entire organization to pinpoint the complexity, understand its effects, and start assessing the overall costs to the organization. Business casing required foundation upgrades, projects, and programs that reduce your organizations complexity will become easier.

If you would like to learn more about complexity measurements within banking please contact me.

7 Responses to Quantifying Complexity – Changing the language not the conversation

  1. Congratulations on your clear explanation of ‘complexity’.

    We should call it:”Entropy of the technology.”

    You’re absolutely right in the quantification of the complexity “in the current paradigm.”

    The chart shows exactly the ratio agility/complexity “in the current paradigm.”

    Likewise, the start of the fifth paragraph is absolutely right.
    But I’ll disagree with the rest of the paragraph as having support two quotes:

    Steve jobs in his office in 1982.
    He was asked if he wanted to do market research, said:
    “I do not want because consumers do not know what they want until you show them.”

    And Henry Ford, about the needs of the consumers:
    “If I asked people what they wanted, they’d have said: faster horses”.

    Bearing in mind these two points of view and since that time, I have drawn the architecture of a ‘cathedral’ for technology, starting from scratch, to support the business banking.

    The result was phenomenal! A disruptive paradigm!

    The best result of this underlying architecture – which I call BOA = Business Oriented Architecture – is in the elimination of the saying that: “new services has a disproportionate dependency on its technology group”

    And from this architecture the model of the BANK OF THE FUTURE is born!

    It’s amazing the simplicity and versatility of the new solution. And about agility: everything is instantaneous. Even a new product can be defined, tested and deployed on the same day!

    What is the primary practical outcome?
    It’s the segregation of the business and management issues, from those of the technology.
    The business staff builds and deploys new products without the intervention of technology staff.

    It is estimated a reduction of AT LEAST ten times in the IT costs. (hardware, software, personnel, redundant processes, physical space, interfaces, DWs, etc.).

    The corresponding chart of the ratio agility/complexity will be a straight line which is parallel to the complexity axis.

    And finally, no more ‘Core Systems’. No more transformation programs. Only conversion and adjustment of data to catch up with the ‘BANK OF THE FUTURE’.

    That’s a breakthrough!

    If more information is needed, don’t hesitate to contact me.

    [email protected]

  2. João

    I completely agree with your thesis. I have been working with companies that are committed to putting the power of data back into the hands of the business in various ways. The problem with all of the theories behind Business Oriented Architecture and the “Bank of the Future” is that there are lots of Monday morning quarterbacks talking a big game but no one in the industry is helping existing banks develop a roadmap to realization.

    At some point a workable process for understanding where a bank starts and how best to mature needs to be provided. Measuring complexity, understanding it, then managing it in the early phases of the move towards a BOA is the first best step.


  3. George,

    this is a new ‘high entropy’ proposed solution (six for half a dozen):

    Oracle Banking Platform


    Oracle Banking Platform is composed of banking-specific applications (Oracle Banking Base, Oracle
    Banking Channels Bank User Base, Oracle Banking Channels Bank User Experience, Oracle Banking
    Current Accounts and Savings Account, Oracle Banking Loans, Oracle Banking Term Deposits, Oracle
    Banking Limits and Collateral Management, Oracle Banking Relationship Pricing, Oracle Banking
    Originations, Oracle Banking Collections, Oracle Banking Reference Process Model, Oracle Documaker,
    Oracle Financial Services analytical applications); enterprise applications (Oracle CRM On Demand,
    Oracle Master Data Management’s customer hub products, Oracle Financials Accounting Hub, Oracle
    Incentive Compensation); Oracle Fusion Middleware products; and Oracle Database technologies.

    How about that?


  4. Completely endorsed and agreed. There is no better technology service than making things simpler for banking organizations.

  5. João, While i do agree with you the abstract form of your vision for OBP, achieving simplicity in the way in which we use technology (or the way in which it is rendered to a banker) is still an evolution we need to catch up to.

    I would like to imagine that bankers of tomorrow (well, today) would just need an app to be downloaded from the technology providers for their “OBP OS” (if i can use that term for a hypothetical connotation) – that helps them asses number of premature redemption s done on term deposits above a certain value – with an ability to directly draft an email contacting them if they’d consider renewing the deposit with another maturity plan/rates/offers (instead of withdrawing).

    OBP shouldn’t stand for be just loosening of the components into an easily integrateable one powered by just data – but also a highly evolved, smart and efficient servicing / rendering layer as well.

    Let me know your thoughts


  6. João I do not see the point of having just banking applications that can be interconected as you note, but the fact of being a complete flexible ecosystem that supports banking business. A lot of Bankig solutions have applications that can be plugged in. When client-server and relation databases enter the arena, any all other architectures were “deprecated” in terms of flexibility and resposiveness. Now we have SOA, SCA or POA, Enterprise Architecture applied to the Banking Industry, Big Data, etc. Banks, are like any other customer? do they follow dealer´s pretended tendencies?
    When and where any customer has dictated to any bank what to do? and following the chain when and where any bank has dictated software industry what to build? So we are in a kind of perverse circle of suposicions.

    What you try to do with your current old Core system is like trying to tune that old 55 Chevy to compete agains top notch modern F1 or Hybrid vehicles at the same time, just because your neighbour has a Brand new Prius. Those systems were built in a day to day needs basis. So, are unestructured in some parts and that demands a lot of effort to add just a single field. Try to think that you now decide to compete tomorrow in an IronMan and the farther you have even went was the grocery across the street.

    For having a complete independency and flexibility to move in the market, to define new products completely addaptive to your needs and current customer risk, you need to deal with Intelligent Banking Systems, one that has Core unmutable componets who deal with basic information and are completely agnostic about the business that is moving in the surface, then you will have independent Intelligent Business Process Components (BPC), they will respond to the current state and will call and connect with the right BPC Cell who in turn will decide what to do, who with interact and if it is the final step. In such way you can define any new product just by combining BPC Cells and attaching rules to help them decide how to react to current conditions.

    I have seen a lot of Frank-Banking-stein spagetti systems. Where a lot of different technologies try to live together. Why? just because some “anchors” in the IT department does not allow to go for change, they see the Core change as the final judgement day, just because they do not think in the business itself but in their retirement days.

    So, the next time you intend to ask an apparently easy change, try to undestand the potentially deprecated solution you have in hands. Because software has an obsolesence period that is short in a number of cases. Now you have to deal with Big Data to understand your customers and be an step ahead of their needs, because they won´t have any needs at least you or other competitor create a new one.

    For solving a current demanding need there´s always the solution of asking someone to build a new system that utilices the data your current Core has or think if the future and look for a new comprehensive Core Banking Solution, I´m sure you could find some good ones that will let you survive software obsolescense and be full competitive.

  7. I forgot to mention that maybe is fair to change the concept of Bussines Oriented Architecture for Customer Centric Architecture. Sincé customers are technologically independent, they are no longer loyal to the neighbourhood bank, they can use its mobile capacity to change from bank to bank, open an account here and ask for loans there. If you do not asnwer in a timely expected frame you are out from its list. In case of enterprises if you can not Support its business, you are out. Just to think that a new concept comes to place, the Ubiquous Financial Services-

Leave a Reply

Leave a Reply

Skip to toolbar