Month: July 2018

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.

All insurance carriers must bank.

The headline has been borrowed from Matteo  Carbone . This topic in general ist not really  new. But today the headline focusses on a different approach. Instead of using bank branches as added sales channels, Open Banking and banking connected APIs will play the key role. With PSD2 all banks from EU have to act as API enabled PISP (Payment Initiation Provider) and AISP (Account Information Provider). On behave of a customer’s account third party providers (TPP) can read account data and initiate payments. New PSD2 API  capabilities have to be provided in a non-discriminatory manner´, what usually translates to ‘at no additional cost for the TPP and the customer’.

Banking as a Free API lunch

A banking enabled Insurtech (BankingInsurtech) can now leverage these capabilities:

• Verify identities via bank accounts and use the banking ID for registering and signing.
• Initiate payments and combine payment transactions with insurance  transactions:
• Combine MultiBanking with MultiInsurance customer views.
• Analyse bank statements for a diverse set of possibilities.

If focussing on a B2B2C business model one can also power the partner by banking enriched Insurtech and mixed banking and insurance capabilities. All of this will be more or less standardized, available via API and very likely as ‘free lunch’.  And if not standardized via BerlinGroup API e.g. then at least a lot of tech API banking aggregators and providers like Figo and others will cover the different API specifications. From my view it has never  been easier to do banking and to combining banking with Insurtech by becoming a BankingInsurtech company. And to transforming to a tech enabled B2BC financial full service carrier. The market is not sleeping. Companies and Startups are already working. Archimede is just one example. There also some OpenSource projects out there implementing OpenBanking APIs, like the one from OpenPSD based on BerlinGroup specification, 

openpsd.org starts its first user story

Bootstrapping a new initiative is always amazing! You have to study specs and implementation guides, think about components you need and choose technology you want to use. In our case  we decided to provide a test server for Berlin Group’s NextGenPSD2 specification. You might think that we are going to provide yet another set of boring mock implementation of the rest API Berlin Group is currently specifying. And I tell you no, we won’t do that! What we want to have in place is a set of components which allow you go through a complex use case. Consent As consent is crucial to psd2 we decided to start with Account Information Consent Flow. This is a very complex multi-dimensional process both from business as well as technical perspective. From business perspective you need to consider that a consent itself has different information such as type of account service it is granting access to, frequency of its usage and its validity duration. Then there are different consent models like detailed, global and bank offered. Technically Berlin Group defines redirect, OAuth2, decoupled and two different embedded strong customer authentication (SCA) methods with which a customer (PSU) may give its consent to the bank. Berlin Group’s implementation guide defines a sophisticated sequence diagram for each of those SCA methods.

[Source: Berlin Group's Implementation Guidelines]

Our approach is to have components in place which allow to go through all those steps in a complex test case. And that’s a lot more work to do than simple mocks for rest api interfaces. PSD-Server, SCA-Server, Modelbank We started to implement a modelbank, a psd-server and a sca-server. Our modelbank will simulate an Account Servicing Payment Service Provider (ASPSP) in this user story. Other roles a bank can take over will come in future. Our target is to have a simple model bank which can provide account servicing and simple payment processing services. PSD-Server provides the rest api and SCA-Server will provide different SCA approaches mentioned in Berlin Group’s implementation guide. Both PSD-Server and SCA-Server will use modelbank’s services. Go, Go, Go We decided to use golang for all of our component’s implementation. This is not because we hate Java, no. It is simply because of the dynamic progress golang is facing during last few years. We think it is one of the most promising programming languages for now. There are a lot of articles out there emphasizing golang’s strengths and comparing it with Java. We don’t want to go through this here. Clean Architecture In UHUCHAIN we already introduced our clean architecture approach in golang projects. We continued this approache in our components here as well. All of our components will separate technology dependent stuff in a provider layer. They have controllers, use cases and entitites separated from each other by using input and output ports in each layer. Implementation is not completed yet but we have reached our first milestone to bootstrap everything and have a clear understanding of what is going to be done next.

GO to PSD2 – DO, deliver and learn!

The PSD2 regulation and the corresponding RTS require from every bank to provide a full functional PSD2 test server against every TPP can implement and test. This server also needs to support the corresponding SCA and TPP onboarding flows. The test server must be available 6 months before the first release of PSD2 APIs in September 2019. We, from OpenPSD, decided and started to develop an Open Source PSD2 test server which covers the BerlinGroup standard. And although the regulator did the mistake not to regulate the technical interface of PSD2 we assume BerlinGroup API becomes de facto standard, at least in Europe and Germany. We decided to implement the test server with today’s most promising programming language GO. We believe GO will sooner or later replace Java due to its simplicity and robustness.

Be inside the castle and walls, don’t stay outside

So if YOU want to participate in our Open Source development you will not only learn a lot about PSD2.  You will also teach yourself with the hottest stuff technologies (GO, Docker, Kubernetes, DevOps etc.) And of course every developer participating will receive its stake in OpenPSD and corresponding rights. Please feel free to send us a direct message and apply as developer supporting our approach. We are already a team of six very motivated and skilled people, but we need more of YOU to succeed.  The roadmap is challenging, but promising!