overthetopseo.com

How to navigate the COVID-19 crisis as a digitally enabled banker

Authors: Yves Van Beethoven – Principal Consultant, Tom Wybaillie – Partner 

In this article we give insight on how financial institutions can execute their digital transformation and navigate the COVID-19 crisis as a digitally enabled banker. Our expectation is that the move to digital for financial institutions will be accelerated due to the recent crisis. In a recent BCG COVID-19 Consumer Sentiment Snapshot we see online shopping almost not being affected by the crisis and some press articles are indicating e-commerce is booming these days

At this stage it is difficult to predict what will be the impact of COVID-19 on financial institutions, but they are for sure facing challenging times. A concrete example is that they will have to cope and implement specific demands by customers due to COVID-19 financial measures (‘betaalpauze’) recently announced by the Belgian government. 

As highlighted in the following EY article we can expect different types of customer behaviours to arise: the back-to-usual clients for whom the crisis was just a small break; the new practices adopters for whom it was a period to rethink their mode of consumption; and the hedonists who will seek to make up for lost time. New digital players as opposed to incumbents might be better positioned to gain market share in these situations. 

In order to cope with this all we want to highlight our Bank on a Page methodology focusing on putting in place the technology foundations of a digital transformation. It will allow you to chose the right pathway on how to implement this structural change. It gives an overview of the long term actions you should take and accelerate to allow your workforce to become fully digitally enabled bankers. 

Structural changes for the digitally enabled banker 

For sure in these times increasing mobility demand will be asked to do business remotely and ‘on the go’ and be able to perform digital sales and servicing smoothly and in a transparent way through different channels. 

In addition we see a trend towards a digital one office where teams function autonomously across front, middle and back office functions to promote broader processes with real-time data flows that support rapid decision making. It’s where front, middle and back offices will cease to exist, as they will be, simply, one office. 

Below a summary of the business capabilities where we show the different channels through which the customers can connect to the front office and can get access to financial advisory services. We indicate the main capabilities offered by the front office employees and highlight their role in the different end to end processes of the core financial services. 

In order to get to this end state it is important to close the experience gap between the customer and the banker, but equally there is a need to close the gap between the customer experience in the channels and the experience when the customer is meeting his advisor in the branch, remotely or on the go. In general we notice that user experience for B2B applications is lagging behind B2C applications. As a reason there is often stated this is because lower visibility and lower mobility of the users. People tend to accept more easily lower usability and inefficiency of professional B2B applications than B2C applications. 

Customers have more and more ways to engage with financial services ranging from the traditional visit to the branch, contacting the financial services through the phone and using online digital channels. However we see a trend towards getting in contact with financial services remotely and via chat, more and more financial institutions are setting in place financial planning & advisory tools, chatbots and offer an increasing amount of services via their online digital channels. This gives an increasing expectation for the financial advisors to be aware of this and have data and insight available at the tip of their finger across the different channels. The customer expects this information to be shared across the different channels and the financial advisor to be aware of this. Financial services who are able to make the switch to digital and use data as a way to improve the relationship between the customer and the financial advisor will lead the pack. 

However most financial services need to overcome significant constraints in their current IT landscape. This article provides a framework for their efforts based on two questions: 

  1. What are the main building blocks for a digitally enabled banker? 
  1. How to chose the best pathway to your digital platforms? 

Key building blocks for the digitally enabled banker 

We first introduce our Bank on a Page model. This model defines the application map to support the business trends. We use it here to identify the main building blocks to become a fully digitally enabled banker. It is used to support decision making and priority setting. 

At level one we identify the different platforms that provide each their own functionalities. We have a Digital Platform which is composed of omni-channel interfaces and a party centric core. The omni-channel interfaces are the entry doors of the bank. They offer a secure channel experience for all parties supporting omni-channel switching and hopping, serving customers and the extended ecosystem of the banks. The digital selling and servicing backbone for customers and employees is there to offer the right content to the right customer at the right time and via the right channel. The omni-channel characteristics are managed here, not in the channels directly. 

The Digital Data Platform supports the bank to better understand and personalise customer experience. Customers and employees expect data and insights at the tip of their finger. The Digital Backbone integrates the different platforms through a plethora of integration patterns and allows to shield and create reusable interfaces across the different platforms. 

The Core Banking Platform contains the factories, corporate and support systems. The factories are product engines supporting the fulfilment during the life cycle of the product agreements, organised per product group or transactional service. Support systems, being common and product-independent, supporting multiple processes and/or multiple (product) engines. Corporate services which support the bank’s support domains, like Finance & Risk, HR, Procurement. 

These platforms are detailed at level 2 and level 3 to indicate the lower level building blocks that they are composed of. As you can see becoming a digitally enabled banker is a big journey that requires priority settings and the right approach to be chosen depending on the ambitions, budget implications and the risks associated. 

Pathways to your digital transformation journey 

Given the complexity of the challenge it is no surprise that financial institutions are using different approaches to building their digital platforms. The two principal decision axes we show here are to use a best of breed approach or going for a suite approach and whether to focus on the digital front end platform or to have an end-to-end platform encompassing both the front end digital platform and the core banking platform. The tradeoffs create four pathways with different investment and risk profiles. Each also has a different business impact. 

A digital front end banking suite approach is the best option for bankers that are looking for mature mainstream digital functionality and look for the outside world to offer them a digital competitive edge. These packages, which employ standard software, work well with stable legacy systems that allow for easy integration with the front end. The packages also require little upfront investment owing to their pay-per-use models, but they can constrain rapid experimentation or radical innovation. Their biggest implementation risk is in data consistency, particularly maintaining a full customer view across legacy systems. 

Quite a lot of Belgian banks have chosen the digital front end banking suite approach by implementing suites like Mainsys FronteO and Backbase Omni-Channel Banking Platform. 

A digital front end platform approach is the best option for bankers facing competitive pressures and needing fast-differentiating digital solutions. They are using custom built or based on best of breed platforms to drive digital innovation in customer engagement. Like the digital front end banking suite approach, they require stable legacy systems and the ability to integrate them with new platforms. Speed of change depends primarily on how fast the banker can build an internal engineering capability. These platforms can be significantly less expensive than digital front end banking suites. They offer full control of the front end, but implementation of end-to-end digital customer journeys is constrained by the legacy IT back-end systems. 

A Belgian bank recently chose for a SaaS based contact center solution to give them a fast forward to interacting with customers through video conferencing and chat. The solution allows a light integration with the existing banking apps with limited upfront investment cost. The plan is also to offer this solution to their back office employees to allow for direct interaction with the customer. Based on standardised data feeds they can stream all the customer interactions which will allow them in a latter phase to perform analytics to better personalise the next customer interactions, but equally to take this knowledge into account to offer better next best offer and next based actions in the online channels. 

An integrated banking suite is typically the best option for bankers facing a scattered legacy landscape at the end of its useful life. This approach, however, which involves the modernisation of back-end systems to enable digitisation of end-to-end processes, requires top-down commitment to endure the large scale transformation that encompasses significant reengineering of business processes as well as major data migration. It also involves a big upfront investment (which can be 100% to 150% of the annual IT budget). Transformations take time— typically two or more years (often even longer in some segments), although this can be shortened to about six months to one year in the case of a greenfield project that starts with a clean slate. 

A lot of Belgian banks still have their core banking platform on the mainframe. Some switched to package solutions like Sopra Banking software already years ago. Others are on the verge of this journey with solutions like Infosys Finacle and Temenos Transact. 

A digital best in class platforms approach is the best option for bankers that put a strategic priority on technology-led innovation. This approach requires a very mature engineering capability that helps the bankers compete with actual digital natives. The level of investments depends heavily on the complexity of the business model, but it is not necessarily prohibitive or even large. Greenfield implementation can also be fast (as little as 12 months); regulatory approvals are often the bigger constraint. The main risk factor can be the difficulty of maintaining custom-built software owing to the competition for, and attrition of, key engineers. 

Often quoted are the neobanks like Monzo, Revolut and Starling which have built brand new digital banking platforms often based on cloud technology. However neobanks like N26 are also using new core banking platforms like Mambu to make their implementation cost efficient. 

Four Major Considerations 

Bankers should focus on four overall considerations. First, digital affects the entire IT landscape. Many successful companies take an integrated front-to-back approach that goes beyond mere digital channel functionality. For those that choose to focus more narrowly, at least initially, the party centric core is key to offering customer-centric tailored services. 

Second, digital architectural strategy should extend beyond the solutions offered by mainstream software. Most digital functionality today is available through ready-to-go SaaS platforms or open source software. By applying a SaaS & Cloud first approach we can quickly have an up and running solution and accommodate for changing demands both to upscale and downscale. Belgian bank Belfius recently chose to move all of its banking services to the cloud. 

Third, implementation pathways (such as best of breed or suite) should be carefully designed because they pose radically different investment and risk profiles. Bankers that aspire to radical innovation typically invest in building an internal engineering capability, while those with less extensive goals can rely on mainstream commercial software. Bankers with major legacy IT constraints should take an end-to-end transformation approach. Others have the option of a front-end focus. 

A big fourth consideration to be taken is chose for a greenfield versus a brownfield approach. The additional costs of integration and migration in a brownfield approach are often underestimated leading to overrun in budgets and initiatives put on hold. A greenfield approach is not always an option, but should for sure be considered. 

The complexity can be confounding, but companies should not be put off. The range of solutions available today, both tailored and off the shelf, vary widely, but they make it possible for every company to determine how best to address its particular circumstances. 

Ludo Wijckmans gaat XPLUS leiden

Alle ingenieurs werken aan duurzame oplossingen. Dat zit in hun DNA

Een omgekeerde piramide voor elke onderneming

Enterprise Architecture & Agile –

By Patrice Kerremans, Stéphane Campo, Jan Casteels, Jean François Declercq, Kristof Dierckxsens, Bart Du Bois – XPLUS Consulting

As enterprise architects, we are so often confronted with this question:
How can we embed an agile way of working into our practice? Or even in a waterfall/agile hybrid?

We’re not here to write another article about roles and responsibilities – these are defined by the different methodologies. We’re not here for a high-level vision, either.  We’re here to share our pragmatic observations and thoughts about the role of an Enterprise Architect within an agile context.

Observations

Admittedly, we sometimes feel lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead….

Figure 1 – Feeling lost in a desert city full of straight shooters – the squad masters – with one esoteric sheriff, the tribe lead….”

Hence we have classified our observations into three categories:

 

the good (dos): the bad (don’t): the ugly (really don’t ):
1.      Manage your architecture backlog

2.      Deliver value incrementally

3.      Be clear about Definition of Done

4.      Distinguish Design Authority from Architecture board

5.      Deliver architectural decisions continuously

6.      Be clear about confusing role names

7.      Be in control of the big picture

1.      Write monolithic architecture documents that nobody reads

2.      Focus too much on the target

1.      Become the blocking factor

2.      Ignore the daily life of the squad

We do not pretend to be exhaustive, and welcome any observations to enrichen the debate.

The good – The dos

Do #1 – Manage your Architecture Backlog

Adding, adjusting, grooming, and prioritizing architectural work items on an architecture backlog has been elaborated by Eltjo Poort [1] and Gerben Wierda [2] . In essence it’s about considering architectural decisions as deliverables in themselves.

 

 

Figure 2 – Gerben Wierda’s Enterprise Chess style of managing Architecture Backlog and Solution Backlog [2]

For these decisions we should be able to build a decision plan: Without this decision, at that time, we’ll start getting into trouble…

Do #2 – Deliver value incrementally

Architects must follow and contribute to the increment, whilst also being able to position this increment in the overall vision. Hence we need to excel in delivering the narrative about the relation between the current increment and the overall delivery scope.

 

Figure 3 –  incremental value delivery – from Henrik Kniberg’s article [3]

Do #3 – Be clear about the Definition of Done.

Endless deliveries are difficult to follow. In agile, it’s tempting and dangerous to end up with an unclear definition of done and therefore everlasting architecture tracks. At key points in the delivery process, architecture governance should contribute to measure and visualize potential deviations.

Figure 4 – checking for course deviations

Do #4 – Distinguish Design Authority from the Architecture board

Enterprise architecture is a relatively young discipline with tangible variations across organizations. We often confuse the level of granularity, mistaking architectural decisions as design decisions or vice versa.

By clearly separating the design authority function from the architectural decision, we enforce the right level of decision to the appropriate audience/board, avoiding useless meetings for a tribe lead or frustration at the squad master level. The right decision, at the right place.

Figure 5 – Distinguishing between architecture and design

Do #5 – Deliver architectural decisions continuously

How do we present a complete vision when we want to be iterative? At first glance it seems schizophrenic. It’s not. A vision must be made, with acceptable levels of risk and assumptions. Clarify iterations and validate or invalidate these assumptions.

Experienced architects will limit failed iterations but, by definition, we should be realistic and accept that also at the level of enterprise architecture we will make failures.

Figure 6 – Fail fast, iterate and pivot [4]

Do #6 – Be clear about confusing role names

We need to share terminology, also on roles and responsibilities. Be clear about confusing terms such as solution architect and feature architect, even if it’s not 100% backed by a strong theoretical background. We are not in avionics or core science. IT is one of the youngest and fastest changing industries, so nothing is written in stone. We must remain pragmatic and adapt to new situations.

Figure 7 – Roles are defined in context of other roles

Do #7 – Be in control of the big picture

EA is not dead – yet it needs more focus on business architecture and more focus on customer journeys.  The enterprise architects of tomorrow must be more and more capable of talking with business.

Execution is gaining autonomy. Instead of fighting to preserve any prerogative, we should adapt and be in control of the big picture more than ever.

Figure 8 – sensemaking and storytelling as key qualities

The bad – The Don’t

Don’t #1 – Write monolithic architecture document that nobody reads

Very detailed RFPs, documents of 50 or more pages or long lists of cryptic principles are a thing of the past. Instead, we have to try to work with one-pagers and references cards that are printable, readable, actionable and pragmatic for a broad audience. When a document is used, understood, shared and endorsed, it’s a win.

Figure 9 – Margaret Hamilton, lead software engineer of the Apollo Project, stands next to a huge stack of code written by her and her team, in 1969 [5].

Don’t #2 – Focus too much on the target

Having a target is important, it’s a starting point. But the focus must be on stable intermediate steps. It’s typically far more difficult to achieve than we initially assumed.

The beauty of an architecture in IT is not to build a cathedral, but rather to build a tent and to turn it into a cathedral step by step (I can’t remember whose sentence this, but he or she deserves the credit 😉

Don’t #3 – Try to control everything

Again, it’s impossible. Learn to control and mitigate risks instead.

Don’t #4 – Throw stuff over the wall without face to face interactions.

Value is delivered through interactions between people. The same applies to delivering architecture value.

A good collaboration model between enterprise architects and solution architects is essential. This should include face-to-face sessions where architecturally significant observations can be introduced and/or bubble up.

 

Figure 10 – Two forms of the Architect as the navigator : (i) the cartographer mapping/guiding ; and (ii) the scout exploring. A good collaboration model between them is essential. [6]

The ugly – The really don’t

Really don’t #1 – become the blocking factor

Accept to work with identified risks and assumptions and measure the deviations over the time.  Work with the limitations.

We have seen enterprise architects becoming the unique point of reference when it comes to integration, communication… In the beginning, such a role is rewarding but it turns into hell over time.

Try to explain the principles, the concepts and the big picture to ALL members. Their autonomy will save your life. A good enterprise architect distributes the information and makes sure everybody understands the rationale.

Really don’t #2 – ignore the daily life of the squad

Attend the different ceremonies and participate. The ivory tower must be destroyed, now more than ever.

References

  1. Just enough anticipation, Architect your time dimension, Eltjo Poort, 2016
  2. Agile & Architecture, Gerben Wierda, 2017
  3. Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable, Henrik Kniberg, 2016
  4. Fail fast, iterate and pivot, Kyle Galbraith, 2017
  5. What to know about the scientist who invented the term “software engineering”, Lori Cameron, IEEE Software Magazine, 2018
  6. The perceived lack of business value of visual models, Charles Edwards, 2014

Related articles

XPLUS Community: How to send your legacy applications on a well-deserved retirement? Ep. 1

How to send your legacy applications on a well-deserved retirement?

In this series, several of our consultants will give their advises on one of the hottest market  topic of the moment. How to manage legacy applications decommissioning?

When you are working as an IT consultant within established businesses / industries (as in my case, banking), you will have probably encountered a lot of legacy landscapes.

As a consultant we help the banks to enrol large transformation programs to be ready to serve the customer in a new Digital way.

The implementation of these programs is most of the time well organised (everyone in IT likes to work on challenging projects which make use of cutting edge technologies). However, one task is often forgotten, to get rid of the obsolete applications.

Nevertheless it is important that the Banks Business strategy and its evolution towards Digital is reflected in its application portfolio. And here the problem starts, the application portfolio of banks is often the result of decades of history with solutions to punctual problems, technology brought in to solve an immediate challenge, incomplete consolidation after M&A or corporate restructuring, change of legislation.

Management attention is set on new functionality which makes decommissioning a “deferrable” expense.

In order to (partially) solve this issue, we should make the projects / programs which deliver new solutions also accountable for the obsolete applications. These teams should take specific actions (i.e. lifecycle management update, reengineering, decommissioning, …) in order to put the legacy applications that they are replacing in retirement.

In order to obtain a good obsolescence rate, it also seems important that this work is done by a different team than the team that maintains the legacy.

A fresh view on the existing business / IT problem is often welcome. Nevertheless, it has taken IT decades to reach its current state, so we can assume that we will not be able to remedy all of this in a portfolio overnight.

The decommissioning exercise is a serious transformation initiative on its own.

Frederic Crabbe

XPLUS Talks: meet Rudy Wouters, ING chief architect

Last week I spent a few hours talking with the Chief Architect Rudy Wouters ( ING Tech Chief architect for Market Leaders ).

Rudy answered a series of questions regarding Digital transformation and enterprise architecture.

We are happy to share his experience with you !

In one sentence, how would you describe what is a ‘digital transformation’?

[Wouters, R. (Rudy)]  Digital transformation is happening to the daily life of everyone, i.e. activities like shopping, socialising, gaming, gambling, managing finances are now done online.

How would you describe your role as chief architect?

[Wouters, R. (Rudy)] As a chief architect, my mission is : “ To develop, advise on and execute the architecture policy, standards and strategy, in order to position adequate IT capabilities for realizing and enabling changing business needs and moving towards a globally scalable and secure banking platform.”

As part of this mission, we create an environment to continuously foster the professionalism of the architects. After all, stable and secure solutions are delivered by good professionals.

What are your daily difficulties?

[Wouters, R. (Rudy)] Finding the right balance and priorities. Dividing the attention between Horizon 1, 2 and 3 work, between planning and operational support, between less and more detail to deliver to the squads, between first time right and iterative improvements, between global and local solutions.

How do you see architects’ responsibilities evolving?

[Wouters, R. (Rudy)] ING is implementing globally a new and agile way of working. Predominantly this means that accountability and autonomy is given to multi-disciplinary squads. To get the full potential out of the squads, they need to be fed with sufficient context and boundaries, not with details. This means that although the purpose of the architects still remains the same, the service is delivered in a different way. In addition, architects will have to spend more time in structuring the portfolio well in advance and provide a view of how business outcomes can be realised across the different assets and thus teams. The latter requires a mature collaboration, between architects and tribe leads. Overall, communication competencies become more important than deep technical knowledge in specific technologies.

What  is – from your point of view – the next innovation that will impact your activity?

[Wouters, R. (Rudy)] As the digital transformation advances, also within the bank, the business processes are moving towards full digitisation. E.g. some of the least expected ones a few years ago, are now picked up by robots. This means that, whatever happened within and often also outside the company, is available in exploitable data. Still today, humans interpret these data to take business decisions. More and more of these feedback loops will become automated, meaning that commercial and operational aspects of the business will adapt themselves to the reality created by the customers. This means that software engineers will focus more on smart algorithms and artificial intelligence to keep up with the required agility. Stand-ups will be more organised around screens showing how systems are currently running the business, trying to understand why this is happening and consequently maybe steer the responses in a different direction.

What  is the current digitalization challenge of your company today?

[Wouters, R. (Rudy)] We still have difficulties to benefit from our size, i.e. it is a challenge to work towards globalized solutions, that are being used many times. Mainly this is coming from the different speeds of the business in different parts of the world and leads to differences in priority. Eventually, the speed of change is limited by the amount of engineers that can be put to work in an effective manner.

Which transformation project is the most risky from your point of view?

[Wouters, R. (Rudy)] To be really competitive in a digitalised world, also the core systems of the bank must be adapted to more real-time and data driven processing. As this happens in flight, it is risky for many reasons: because they are part of nearly all business flows, there is a real danger of jeopardising stability and continuity of the business, at the same time, there is only in the long run additional value visible, which increases the risk of losing focus leading inevitably to failure to deliver.

Which transformation project will bring you the most value?

[Wouters, R. (Rudy)] In terms of potential, it will most probably be situated around the core systems upgrade, in terms of immediate value it will be related to how we change our means for integration in to the ecosystem.

Explain the risk of omission of EA, in other words, what happens when it is not present?

[Wouters, R. (Rudy)] Every company with a sizable change portfolio has had this experience already several times. Without the structuring capabilities of EA, it is very difficult for executives to have sufficient overview to determine a strategy that is not disconnected from reality. Defining a target view may still be easy enough, but when sufficient structured information down to the operational level is missing, it is impossible to define executable steps that lead to that target or even understand that the target cannot be achieved, inevitably not leading to the desired outcomes.

How do you communicate the value of architecture to your CIO and other Cxo’s?

[Wouters, R. (Rudy)] Talking or reading about it will not do the trick. If that would be true, everyone would be convinced. There is enough lecture on the subject to fill a room. According to me, the difference can be made by the actions of the architects at all layers of the company, from operational to tactical to strategic activities. The architects should always prioritize their activities towards complementing the value of the teams and ensuring stability of the solutions. This added value finds its source in the structured oversight they have and their understanding of how everything relates to the desired outcomes. Architects with this behavior will be communicated about.

Which book recently influenced you ?

[Wouters, R. (Rudy)] There are actually two:

1/ “reinventing organisations” from Frederic Laloux

2/ “Continuous Architecture, sustainable architecture in an agile and cloud-centric world” from Murat Erder and Pierre Pureur

How do you see the challenge of training, keeping your architects?

Given the importance for architects of context and integration with the organisation, there is added value in a stable architecture workforce. How can architects then be convinced to stay with the company while satisfying their desire for new challenges. For this reason, we’re working in a partnership with XPlus on a true architecture training platform. The idea is to allow companies to produce and consume interesting training, dedicated to architects. At the same time, there is an opportunity to bring together architects from non-competing industries, in classical training. When brought together, being presented with similar challenges, they may exchange valuable information with each other but even more, they may ignite new ideas for collaboration across companies. The main idea is to enable companies to create their own architects – you don’t hire an architect, you create one. On the other side, it allows architects to find diversity in their work, without having to switch company.

Verifiable Claims: distributed proof of one or more capabilities

By Patrice Kerremans

What is it?
The official definition from the W3C Credentials Community Group is: A statement made by an entity about a subject; A verifiable claim is a claim that is effectively tamper-proof and whose authorship can be cryptographically verified. Multiple claims may be bundled together into a set of claims.
The (somewhat unspoken) fact is that claims can be distributed and do not require a centralized system, because their verification is a matter of cryptographically verifying them. That is, you don’t need a central server to be up-and-running and accessible at all times for you to be able to verify the claim. This makes the system very sturdy.
Also, the creation of claims is delegated to the issuers, making it even a more distributed system. What is it good for?

Other interesting examples include: proving you’re old enough to (buy a) drink, proving you have the required driver’s license when renting a car.
There’s a complete description of the use cases on the W3C github.
Who are the actors/players?
In order for this to work, you’ll need the following actors:
Issuer
An entity that creates a verifiable claim, associates it with a particular subject, and transmits it to a holder. This can be -for example-
a bank (certifying account ownership), or
a doctor (certifying that you have a certain ailment), or
a government certifying your identity or your birth certificate
a school certifying you’ve successfully achieved a certain degree
Holder
An entity that is in control of one or more verifiable claims. This is typically the subject of the claims. But it can also be a third party that holds on to the claims on behalf of the subject.
Claim
A statement made by an entity about a subject and that is tamper-proof and whose authorship can be cryptographically verified. This means that
when someone fiddles with a claim, this can be detected; rendering the claim useless
but also that when someone tries to counterfeit one this is detectable; also rendering the claim useless
Say that you create a claim that you’ve obtained a degree at the University of Ghent (UoG). Since the claim won’t have been signed with the private (& secret) key of the UoG, the claims digital signature will be incorrect and others will detect this.
Inspector-Verifier
An entity that receives one or more verifiable claims for processing. Examples of inspector-verifiers include employers, security personnel, car rental services, and websites.
Identifier Registry
Mediates the creation and verification of subject identifiers. Examples of identifier registries include corporate employee databases, government ID databases, and distributed ledgers.
In the next post we’ll go into how to implement this…

Book Review: The Phoenix Project

By Frédéric Crabbe &  Hans Dijckmans

Frédéric Crabbe

This is a novel which tries to explain the underlying story of how an organisation can go into crisis because IT and software development form a bottleneck for the business. What I like about this book is that it looks at an IT transformation via DevOps (or agile, or any other buzzword you prefer) and is gradually showing the relevance of IT in the enterprise and how interconnected everything is that makes the business run. So calling this a DevOps book is an understatement. The book takes a broad view of DevOps and shows how it can be used as a way to integrate IT into the business rather than being an under-performing cost-centre (the way business often looks at IT). The underlying idea is to take the lean methodologies from manufacturing, and bring them to IT. It also shows that by promoting system thinking (over local optimization), feedback loops and a continuous learning culture. Of course, automation and continuous delivery are necessary intermediate steps for most traditional IT organisations on that journey.

Hans Dijckmans

The book tells the story of an IT department manager Bill Palmer, being promoted against his will to Vice-President (VP) of IT Operations within the company Parts Unlimited, a manufacturing and retail company. Parts Unlimited is losing market share quickly and is very much dependent on the successful implementation of a strategic project called the “Phoenix project”. But before critical IT resources within the company can focus on that project, there is a lot of other “IT pain” to be resolved. The book describes Bill’s journey in facing these IT challenges, ultimately giving the IT department a new and positive image within the company. As the book is written in novel style, it offers an entertaining story line and tons of deja-vu moments for most of us. The book is overall relatively realistic in its description of difficulties that IT organisations are facing, but the multitude of problems might be a little more than what you will find in one single IT organisation. Nonetheless, the book is very good in its initial objective, which is to apply the theory of constraints to IT and in showing that IT isn’t that much different from manufacturing. In addition, the added-value of ITIL and DevOps are demonstrated. Organisational anti-patterns that commonly impede business and IT cooperation are nicely described. It outlines you ways to escape the vicious circle by keeping things simple, building trust, making objective observations and trying out new approaches.

Microservices and SOA

By Patrice Kerremans
I’ve always had the impression that the microservices movement was trying nothing more than to apply SOA with common sense. Meaning, applying SOA without going overboard with tooling, for instance. And without the militaristic top-down approach. Etc. Martin Fowler put it much more eloquently in his talk during the goto; conference early last year.
And what I did appreciate most in his talk, was his comparison between a monolithic and a microservices approach:
Monoliths have the advantage of supporting: simplicity, consistency, inter-module refactoring
Microservices on the other hand favorably support: partial deploying, high-availability, preserving modularity, multiple platforms.
Just by looking at the advantages of both, it seems almost obvious that one should start by implementing monoliths. Only when it becomes really painful should one start thinking about chopping the monolith up into microservices. Now, if you do properly modularize your monolith and keep it nicely modularized just up to the moment in time where you need to start chopping, moving from a monolith to a microservices architecture should be doable in a short amount of time. So please, after going overboard on SOA, let’s not go overboard on Microservices. Of course, if the past is an indication for the future, five years from now, we’ll probably start applying microservices with common sense (I wonder how we will call it then ? )