blogposts

How do we want to serve the Customer in the Future?

We have often spoken about platforms and ecosystems and its relevance for products and technology. But like we try to adapt organisations to new project methodologies and technologies (‘Digitization’) shouldn’t we also from an ecosystem perspective? Shouldn’t the  ecosystem not only determine the customer journey and the product, but also the organisation and operation model behind? I believe Yes like the model below describes:

Looking beyond

The customer as  member of an ecosystem is supported by the corresponding organisation with it’s products and journeys. For an insurance or bank it means one need to  look beyond classical product definitions and deployments. What do you think? Feedback welcomed! Further reading – The Digital Platform Model      

Do we have a common Terminology for Digital Platforms?

In the last weeks and months I often read about Platforms, Platform-Economy, Ecosystem-Strategies and its relevance for banking and insurance. Because I love APIs and API-driven approaches and as APIs are the backbone, the DNA of every platform approach, I’m happy about the increased interest of Insurers and Banks in platforms and subsequently APIs. But do we all have the same understanding of the corresponding terminology? I’m not quite sure, so I’ve developed the/my simplified Digital Platform and Digital Building Block models below.

Digital Platform Model

  Everything starts with an Ecosystem Strategy. The strategy selects the Ecosystem and defines the necessary Ecosystem Use Cases and corresponding Digital Building Blocks. A Digital Platform consists of Building Blocks. The Building Blocks provide Digital Capabilities. The Ecosystem is powered the Digital Platform. Ecosystems can have different flavors. And either it’s your own ecosystem and you are the Orchestrator.  Or you are implementing into a 3rd party ecosystem as Integrator.

Digital Building Block Model

The Digital Building Block is the smallest unit of a Digital Platform. A Digital Platform consists of Digital Building Blocks.  A Building Block can be a Simple or a Complex Building Block. A complex one is orchestrated out of n simple ones. The customer uses the Standalone Building Block directly. The developer and the partner integrate the Integration Building Block into the ecosystem of choice.

Your View?

What do you think? How would you model the relationship of platform, ecosystem and digitalization? Happy to receiving your feedback!

In a Nutshell

Open Insurance before others will do it. Bring Insurers back into the driver seat to competing with the current platform-economic and  Insurtech Digital evolution. Found an organization managing and governing our Insurance Open API Initiative. Start small and local, but within an important environment for Insurance in Germany – Cologne. Be open for every Insurer and every startup, every tech company. Create the Open Cologne Initiative and Group.

Everybody ist talking about Open Finance APIs.

The Open API is the power behind the disruptive Fintech and Insurtech movement. Open APIs are the fuel of the platform-economic revolution. People claiming the importance of Open APIs for future finance innovations are not wrong! But do we really find Open APIs within the finance business today? To acknowledge an API  as open it must at least fulfill  these requirements from my perspective:

1. The corresponding business sector must be mandated to open its business via API. An API consumer can find same functionality at all incumbents of a business sector.
2. An API must follow a comparable specification and technical standards. The consumer can apply to some extents the same technical API implementation for all incumbents.
3. The API is a B2C API protected by necessary technical customer governance and security. The consumer can decide where and how to use the API.
4. The basic and mandatory APIs are free of charge for the customer

No one is providing real Open Finance APIs today.

Banking APIs in Europe are slowly coming close to my definition of Open APIs. With PSD2 and GPDR Open Banking APIs are at least fulfilling three of the four requirements of my definition. At some point in the nearer future PSD2 APIs could also fulfill the one technical specification condition (like the one of the PSD2 BerlinGroup). It would become Fully Open API compliant then. Within the Insurance vertical there are no Open APIs today. Even if some Insurance companies are opening their systems via APIs today none comply with the given constraints.

Without Open Insurance APIs no successful Platform Economic and Insurtech Development

And without true Open Insurance APIs no democratic and sustainable innovative Insurance development over the coming years. Non existing transparent and standardized access to the customer’s data will  encourage specialized and proprietary aggregators. As it’s their business model they are the only ones being able and willing to investing in necessary technical infrastructure.  Aggregator architectures and corresponding aggregator platforms will lead to typical monopolistic Internet structures. It will slow down, if not even prevent at all innovative, customer-centric Insurtech developments.

Open Cologne is the answer to fight Wallet Insurance Gardens

In the long run we believe other verticals need an openness and API regulation like PSD2 as well. Insurance is one of those business sectors.  It’s not only closely related to banking.  But with new digital Bancassurance models Insurance is getting closer to banking than ever before. We believe, we will need an official European regulation, but this will take some more years considering how long the evolution from HBCI to FinTS to PSD2 took. Therefore we suggest to founding the Open Cologne Working Group. Their strategic objectives are the following:

1. All Open Cologne member publish an aligned and confirmed set of functions  via APIs – on a mandatory base (besides optional functions are possible).
2. The mandatory API part is free of charge for the customer
3. The APIs focus a B2C API customer-controlled architecture (‘consent’)
4. Open Cologne Group will govern and secure APIs comparable to PSD2 (SCA RTS) .
5. The Open Cologne Group is the management and governance instance until a more suitable institution has been established. The OCG provides Third Parties (TPPs) with necessary certificates and governance to accessing Cologne Group Certified insurers.

Open By Nature

The Open Cologne Group is open to every Insurer, Insurtech, Tech Company and Fintech.  Therefore OCP invites all parties, who are interested in forming the group  and developing the API, to joining OCG. The name has been proposed as Cologne is a significant Insurance City with many insurers in Cologne (over 70) and as appreciation to the PSD2 BerlinGroup. Besides it makes sense to starting with a smaller and local set of Insurers to reducing complexity, efforts and risks (‘sandboxing’). If you are an Insurer, Fintech, Insurtech or comparable please send us a email to articulating your interest. We will start anyway. But we can only achieve ‘Real API Openness’ if a lot of our vertical members  participate. More Background – http://deliverythinking.com/how-regulated-open-insurance-can-power-the-ecosystematic-insurance-business-and-protect-against-monopolistic-aggregators/

Regulation seen as Chance not as Burden

From a financial and history perspective regulation has mostly be seen as a burden. Something to invest in, but with barley any benefit for the incumbent. This might change with newer regulations like GDPR and PSD2. These have been designed for the customer, but are a chance for the incumbents and the challengers, too. A win-win-win situation for all participants. The cited laws drive innovation by opening the business in a regulated and secured manner and by protecting customer’s data on the highest level. And due to the fact that we are talking about EU law I also see a competitive advantage over the rest of the world implementing these properly.

Banking and PSD2 as a Blueprint for Open Insurance

The given rules, especially the API opening ones with PSD2, are currently only for banking relevant. But as banking and insurance are growing together in a kind of revitalization of digitalized Bancassurance it might make sense to develop something comparable for insurance.

Why should Insurers ask for Regulation?

Today the Insurers are not forced to open their systems via APIs. Innovation is dependent on the good will of the incumbents. And when insurers open their systems third parties using the given APIs are somehow operating in a grey zone as B2C API access is not yet regulated.  Neither the customer nor the TPP not even the insurer know if and how to behave and operate compliant. This will slow down the development and therefore the acceptance of Open Insurance systems . And in the end this will lead to disadvantages in an ecosystematic world where open and standardized integration is key and king. It will lead to extended monopolistic aggregator structures as these are the only ones, who pretend to providing the necessary openness in insurance.

Open Insurance can fight back Insurance Aggregators

Believe it or not. I do believe standardized Open Insurance can be the answer to the Check24s, the GAFAs and the likes in our world. The today’s customer believes only the aggregator site can provide the necessary truth and comparability. The aggregator provides this kind of transparency usually in an intransparent way and with a lot of effort on all sides. What if this transparency can be achieved with a standard, law-backed API everybody can use and understand easily – like the payments API of PSD2? And what if the customer understands that and how these APIs are secured and regulated accordingly? The need for monopolistic aggregator structures declines as everybody can be an aggregator with simple means then.

Open Insurance is NOT DEAD. Has not yet begun

A technical API is not Open Insurance. Open Insurance is a regulated and transparent environment and operating room with technical and non-technical requirements and legal parameters. Open Insurance is just beginning. If you follow this interesting thread on LinkedIn and this new OpenInsurance initiative either. I know the regulator won’t be as fast as I believe we need him, but if a group of insurers and TPPs would start with first objectives and would copy from the banking what’s already there, we could leap frog a lot.

Delivery Thinking Enterprise Architects (DTEA)

In my last two articles on this topic I mentioned the interesting shift in Gartner’s definition from of EAM 2013 to 2018 towards innovation enablement and disruptive challenges. Also I have mentioned some initiatives from Germany which are creating new approaches of EAM either on a semi practical/academic or fully academic level. If you look at how agile EAM is understood in other parts of the world and how big technology companies actually do EAM you might get a better understanding of how this topic has evolved and where this shift in Gartner’s definition comes from. EAM derived from Disciplined Agile Delivery (DAD) is an interesting approach to have a deeper look at. It is amazing how pragmatic it is crafted and yet it does not seem to end up in chaos. Principles for Performing Enterprise Architecture Agilely according to DAD are

1. Evolutionary collaboration over blueprinting
2. Communication over perfection
3. Active stakeholder participation
4. Enterprise architects are active participants on development teams
5. Enablement over inspection
6. High-level models
7. Capture details with working code
8. Lean guidance and rules, not bureaucratic procedures
9. Have a dedicated team of experienced, enterprise Architects

You can read more on this on disciplined agile delivery’s site. We from deliverythinking.com fully agree with this approach and understand ourselves as Delivery Thinking Enterprise Architects (DTEA) in such a manner.

Open Banking the simple part – Open Security the difficult one?

Slowly the PSD2 API and SCA specifications become more concrete and available (e.g. BerlinGroup). One is now able to developing first test cases against PSD2. It becomes more and more obvious, how complicated Open Banking can become and probably will be in the future. And it isn’t the core banking functionality that makes a developer’s live complicated.  It’s the security diversity behind this new PSD2 SCA API architecture. If we in Germany wouldn’t know better (with HBCI and FinTS) one could believe security has to be that complex. Compared to FinTS the security model  behind PSD2 seems to becoming a complexity monster and a danger for the whole Open Banking approach.

Dead on Arrival?

In the end not only the developer and the integration and innovation party (TPP) might be disgusted. The user might become overwhelmed by the Open Banking based software and security usability.  Probably he will reject Open Banking solutions. The Open Banking market will die before ever gone live. If you like to feel and understand a litte of the given complexity go to the openpsd.org and download the first embedded SCA example (based on the BerlinGroup API). The embedded one is still the simplest one. But we will also work on the other SCA scenarios. I’m still very optimistic for  the whole OpenBanking approach, but compared with the 20 years of experiences of usable APIs in Germany there’s still a long way to go. That’s why we are here at OpenPSD. If you like to help let us know.

When I’ll start my new role as Chief Platform Innovation Officer the first of September 2018 it not only feels like coming home because I’m returning to one the most innovative and disruptive financial areas – INSURANCE. It also feels like coming home, because I’m returning to my former employer who, as a young man and for many years, has heavily influenced my career path and my way of thinking and acting – AXA Germany. And finally it feels like coming home because I’m believing I can now realize  my for many years evolving and developing API and PLATFORM ideas – hopefully as the perfect finish of my now more than 30 plus years working life. The time, the people, the mindset, the experiences, the technology and regulation are now providing the necessary circumstances and setup to building a bankinginsurtech-driven, API-powered platform finance carrier, who, with the help of partners like insurtechs and fintechs and others can stand and grow in the times of the happening platform economic revolution. For this believe and coming home I sadly have to leave apoBank after only six months today, but with a very optimistic view on their future. It was a honor to being part of this fantastic team, that will change the bank’s strategy and future within the next two years massively. If they will succeed, and I wish everybody at apoBank only the best for these challenging ambitions, apoBank will be one of the most interesting and also best prepared player in the emerging and disruptive German banking market, I’m sure. I’m very thankful for this short, but very educative and impressive journey.  

Part II Agile EAM …

In the first part of this article I tried to demonstrate that mankind is trying to manage complexity in enterprises for more than a hundred years and most of those processes, tools and techniques that we nowadays use to summarize under the discipline “enterprise architecture management” have been there before. My intention behind that was to demystify Enterprise Architecture Management by explaining the ideas behind it from a historic perspective. Part I stopped with explaining the shift of Gartner’s Enterprise Architecture definition. Gartner’s new definition of Enterprise Architecture Management is an implication of two main effects we have experienced in the last ten years.

EAM’s Reputation

First one is the sobering insight that actual results of EAM do not match the hopes enterprises put into that topic. Well, that doesn’t sound very surprising. That happens every time a new thing goes through the hype cycle. But in case of EAM it was a bit more than that. Enterprise Architects were known to be sitting in an ivory tower without any deeper knowledge neither of business nor technology. The governance concentrated approach and the concentration on frameworks was meant to be responsible for slowing down innovation and hinder usage of latest technologies to bring forward business.

New Digital Business Models

The second effect which forced a rethinking of the role of EAM was the rise of new technologies like cloud computing, mobile, big data, internet of things, artificial intelligence and distributed ledgers (aka Blockchain). Each these new trends created a whole universe of possible new so call digital business models. The impact of the latter we can even read directly in Gartner’s new definition. In the same time agile software development and DevOps models brought more flexibility and increased time to market in software projects. Design Thinking and Business Model Canvas brought new interdisciplinary and lean ways of invention, innovation and business development for digital customer communications in particular.

Bimodal IT

But that’s not enough … Enterprises started to ramp up so called bimodal IT organizations to have a proper answer for digital challenges. EAM’s suffering from its reputation, new digital challenges and new methods, tools and techniques and the challenge to bring together requirements of bimodal IT organizations motivated people to rethink the way EAM defined itself in the past.

Is Agile EAM the Answer?

There are several approaches to make EAM more lean, agile and pragmatic. Nearly all of those postulate to focus on business values rather than putting architecture frameworks into the foreground. Enterprise architects need to have closer communication with agile teams to understand their demand and to get informed about latest architecture developments earlier. Another pragmatic proposal is to create an artefact only, if there is a stakeholder for it. In terms of tools and techniques it is no surprise that new approaches try to integrate design thinking and business model canvas tool set into enterprise architecture management. Interestingly some initiatives coming from Germany criticize the framework centric approach of the past but then again they try to introduce new process models and method toolsets they call “Business Architecture” or “Architecture Engineering”. Those tool sets try to integrate design thinking and business model canvas elements. These initiatives hope that new processes will deliver better results than processes came before with those exiting frameworks. This might have to do with the traditional way the discipline called “Wirtschaftsinformatik” has created results in Germany. I still do not know how to translate it properly. Is it “Information Systems” or “business informatics”? I really don’t know. What I do know is that creating process models, methods and toolsets for a certain class of enterprises challenges have always been the core of it in Germany. To me this doesn’t sound like a pragmatic lean agile approach though.

What’s agile EAM to me?

To me a more pragmatic approach sounds reasonable. Agile core principles must be put into front not processes or methods:

1. Define your goals and have them in mind. Keep in mind that your goals must create a measurable value!
2. Check your set of actions against your goals continuously. Do not things because a process definition tells you to do so. Do things only if it helps you to achieve your goals.
3. You’re not done when an artefact is created; you’re done when you have reached your goals.
4. Always consider risks. You have to live with a high level of uncertainty and dynamics. Make use of anything that helps you reduce or mitigate risk. E.g. do things iteratively, communicate often and make things transparent.
5. Make use of common sense!

Enterprise Architects and EAM organizations have to consider these simple rules to follow a reasonable agile and pragmatic approach. In that case they can use processes and frameworks whenever it really make sense. It really doesn’t matter if they use TOGAF or any of those new agile process models then. Enterprise Architecture Management has always been a matter of soft skills not a matter of processes and frameworks.

Part I let’s talk a little bit about history …

For more than a hundred years, almost in parallel with the rise of corporations, business administration as an academic discipline offers ways to manage complexity in organizations. Although it has IT roots, Enterprise Architecture Management is one of the latest contributions to this field. I would like to have a short look at this history to give you an idea what happened in the past on the field of management of complexity and why that happened.

Organization Theory

Organization theory was the first and very early approach which splits up an Enterprise into functions, tasks, workers who execute tasks. It claimed that splitting up an enterprise can either be done by separation of different execution steps on the same task object or by distinction of task objects that are to be treated in each task. Procedural instructions and operating procedures defined the way how a single task or a set of tasks should be executed.

Cybernetics, System Theory

In the 1950s cybernetics and system theory appeared. The latter originally being defined on the field of biology found its way into many other disciplines. Both cybernetics as well as system theory influenced economics and information technology significantly. Enterprises started to be looked at as systems having interrelated components and serving a certain function. Organization theory has dominated management of complexity in enterprises for decades (actually until the 1970s). Upcoming economic challenges as well as the emergence of computers were two main forces in that time which brought new methodologies into light from the 1980s on.

Business Process Engineering

Business Process Engineering aimed to increase efficiency and reduce time to market by introducing a new behavior centric definition of an organization and considering improvements information technology can bring. Processes (behavior) moved into foreground instead of isolated functions (structure).

IT Architecture

On the other hand, almost at the same time in the 1980s programmers started to think about managing complexity in software and IT systems by introducing a new discipline called “IT Architecture”. Some of those postulated software architecture considerations others introduced frameworks which aimed to systematically define the role of IT in an enterprise in terms of contributing economic value. All those initiatives were IT-centric though. In organization theory’s terminology, enterprise IT systems are nothing more than a particular type of workers executing tasks. Hence, is obvious why IT systems found their way into new approaches to define an organization’s composition.

  In the 1990s there were bunch of different business process modelling frameworks which allowed describing an enterprise from business as well as IT perspective. These were the beginnings of enterprise architecture management without naming it that way. But in the real world’s implementation it still it was an IT people’s playground. I remember times when we discussed with business how to optimize processes and derive requirements for it landscape transformation from those processes but they didn’t understand.

Enterprise Architecture Management

In the 2000s complexity increased in IT departments. Internet widely spread in the society and brought the net economy. New multi-tier architectures were established and open source were introduced for business purposes. Sustainability and stability of business as well as IT operations became very important. Enterprise Architecture as a term was about to be established. Enterprise Architecture in that time integrated methods, models and techniques other management methods like organization theory, system theory, business process engineering and IT architecture had introduced before and added even some more. Enterprise architecture was about streamlining business functions, services and applications as well as technology and was meant to contribute value in order to achieve enterprise’s strategic goals. If you look at how Gartner used to define Enterprise Architecture back in 2013 and how they changed their definition in 2017 you may recognize that there is a shift from ensuring sustainability and stability to enabling innovations and giving answers to distributions.

Gartner’s Definition 2013

“Enterprise architecture (EA) is the process of translating business vison and strategy into effective enterprise change by creating communication and improving the key requirements, principles and models that describe the enterprise‘s future state and enable its evolution.”

Gartner’s Definition 2017

“Enterprise Architecture is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions.” So apparently “evolution” was not enough anymore. Is that actually a reaction on the impact mobile revolution and new digital disruptive business models started to have on the whole economy? So what happened until then? Did Enterprise Architecture Management keep its promise according to the first definition in 2013? Is it going to be a proper answer to the latest challenges enterprises are facing according to the new definition? In the next part of this series I will have a deeper look into why this shift of definition happened, what this has to do with agility and how this new approach has changed tools, methods and hopefully mindset (which is the most important thing) behind Enterprise Architecture Management.

The BerlinGroup PSD2 working group has released a new PSD2 API specification – Version 1.2.  This time The NextGenPSD2 Framework and Implementation Guide also includes an OpenAPI file: The OpenAPI file integrated into a Swagger editor including documentation and examples can be tested at OpenPSD (http://specs.openpsd.org/). We, from OpenPSD,  will use this new OpenAPI file to creating (at first) a PISP and then a AISP PSD2 test server. If you like to contribute to OpenPSD please send us a DM.