What is the difference to other API initiatives (e.g. BIPRO in Germany)
initiative I am often asked:
- Why do we need another, a new API approach?
- What is the difference to other activities like BIPRO et al?
- Why now?
- And why we as Insurer?
Many good questions. And for all of them I hope I can provide an answer and rationale. While I tried to explain in my last blog post
, what a ‘True Open API’ is I today would like to illustrate by the graphic below, why we need a ‘True Open API’ for Platform Economic scaling also for Insurance.
And why current approaches don’t scale as best as possible and aren’t the most suitable match for platforms from an Insurer’s perspective.
What are the key capabilities of an OpenCologne API or Platform API?
- Open Cologne wants to provide a ”True Open API” (see for Architectures and capabilities)
- Open Cologne wants to provide a “Platform API” in contrast to a “Pipeline API” (see above for architecture and differences)
- Open Cologne is designed for PULL-, Demand- and User- Driven Models
- Open Cologne wants to provide an API controlled and ‘owned’ by the Customer and User (“Consent Driven API”)
- Open Cologne wants to keep the Incumbent and API provider visible by keeping the Incumbent, the Insurer “visible”
- Open Cologne APIs wants to be as frictionless and as self-service as possible and thus as scalable as possible
- Open Cologne wants to keep the Platform’s Core Value and Filters transparent to everybody
- Open Cologne want to use modern developer oriented technologies and methods (Open Source)
Many of the given capabilities aren’t fulfilled by others today and thus the reason for trying something new. And I’m not alone with this interest – not any longer.
Your opinion? What are your thoughts, your approaches?
What is a True Open Insurance API
Another hype topic besides platforms and ecosystems are Open APIs.
Open APIs are the DNA for a friction-less scale on the supplier and demand side within an ecosystem.
But not every API is in my eyes a True Open API. While banks, as finance forerunners, especially in Germany in the past and long before PSD2, developed or are currently developing Open APIs I don’t see this trend yet within the Insurance space.
Only because an API is technically accessible and can be accessed via Internet standards it’s not fully open or a True Open API
And if an Insurance API is not a True Open API the API won’t scale on a platform as best as possible.
How to create an Open API?
To become an Open API for Insurance the Customer has to ‘sit in the Driver Seat’
and control the API like he can within banking in 2019 (B2C API).
The Insurance API must include everything necessary to be leveraged seamlessly
. The partner shouldn’t need to implement Identity management, security or validations etc. in order to use the API properly and securely.
The partner must be able to integrate the API in a Self-Service approach and the developer should be able to work autonomously
At a highest level of True Open Insurance APIs the partner should be able to use the same API definition not only for one incumbent.
Last but not least the API should be governed and regulated (in some form) in order to operate in a stable, transparent, reliable and by all parties broadly accepted environment
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:
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 Mode
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
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.
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.
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:
- 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.
- 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.
- 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.
- 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
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:
- All Open Cologne member publish an aligned and confirmed set of functions via APIs – on a mandatory base (besides optional functions are possible).
- The mandatory API part is free of charge for the customer
- The APIs focus a B2C API customer-controlled architecture (‘consent’)
- Open Cologne Group will govern and secure APIs comparable to PSD2 (SCA RTS) .
- 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
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
- Evolutionary collaboration over blueprinting
- Communication over perfection
- Active stakeholder participation
- Enterprise architects are active participants on development teams
- Enablement over inspection
- High-level models
- Capture details with working code
- Lean guidance and rules, not bureaucratic procedures
- 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 t
he 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
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.
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.
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:
- Define your goals and have them in mind. Keep in mind that your goals must create a measurable value!
- 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.
- You’re not done when an artefact is created; you’re done when you have reached your goals.
- 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.
- 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.