Five of the top 10 companies in the latest Forbes Global 2000 company list (published in May) are from China, and four of them are commercial banks. If you think this is only due to China’s massive consumer base, and that you can easily apply your global innovation strategy to the Chinese market, you’re almost certainly wrong. Enterprise architecture (EA) professionals at companies doing business in China should take a look at what the country’s banking and financial services industry (BFSI) is doing to enable customer-centric innovation.
I recently published two reports focusing on China’s BFSI. In these reports, I analyzed the Chinese banking landscape and the business challenges banks face, described a systematic approach to innovation that EA pros should consider when planning their transformations, and shed light on how they use both mainstream and emerging technologies to unleash the power of innovation around products, operations, and the organization. Some of the key takeaways:
Chinese banks suffer from their own customer experience issues. As a longtime monopoly, China’s BFSI has suffered from inefficiency, quality problems, and an uncompetitive ROI — and thus can no longer meet the high bar for customer satisfaction in the age of the customer. EA pros must find innovative ways to resolve these issues.
Internet companies and regulatory changes are challenging BFSI players. Visionary Internet companies like Alibaba and Tencent have launched financial services products, including innovative products like Yuebao, that are disrupting China’s BFSI with higher profits, lower barriers to entry, and better flexibility. The government is also making regulatory changes that will open up the market and intensify competition.
“Figuring out how to think about the problem.” That’s what Albert Einstein said when asked what single event was most helpful in developing the Theory of Relativity. Application integration is a problem. A big problem. Not to mention data, B2B, and other domains of integration. As an industry analyst and solution architect, what I’m most interested in first is how to think about the problem.
Pop Quiz: The Goal of Integration
Which of the following statements best articulates the goal of integration strategy?
The goal of integration is to keep data in sync across two or more siloed applications.
The goal of integration is to improve business outcomes by achieving consistent, coherent, effective business operations.
The correct answer is B. Was that too easy? Apparently not, because most of the integration strategies I see are framed as if the answer were A. Most, but not all — and it’s the ones framed around B that I’m most interested in. Here’s the difference:
A-style integration centers on technology. It begins with data and business logic fractured across application silos, and then asks, “How can integration technologies make it easier to live with this siloed mess?”
B-style integration centers on business design. It begins with a businessperson’s view of well-oiled business operations: streamlined processes, consistent transactions, unified tools for each user role, purpose-built views of data, and the like. It designs these first — that is, it centers on business design — and then asks, “How can integration technologies give us coherent business operations despite our application silos?”
There’s a big mistake often made with business architecture — a very big mistake, yet a very subtle mistake. As you might expect, there are a number of mistakes one might make with business architecture, but there’s a particularly big and common one that multiplies its effect through all the others.
The mistake is this: To position business architecture as a new layer on top of your existing processes and structures for EA domains such as application architecture, information architecture, and infrastructure architecture.
Here’s the issue: The traditional way many organizations have pursued EA, it should have been called “enterprise technical architecture” — ETA. The central focus has been on the likes of technical standards and reference architectures for application implementation — i.e., on the technology — and not on the enterprise itself. In a phrase, ETA is “technology-centered,” leading us to odd behaviors like assuming it’s only natural that business users, product data, customer data, and the rest will be fractured and split across multiple applications. We put applications at the center and make the business gyrate and adapt around our siloed and broken applications.