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:
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
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.
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.
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 ? )

Building better work relationships

By Frédéric Crabbe
It is strange to think that we spend more time on a daily basis with the people we work with than our own family and friends. When spending so much time at work, it makes sense to invest quite some time in strengthening our relationships with our co-workers. Instead of spending time and energy overcoming the problems associated with negative relationships, we should instead focus on making our work more enjoyable by having good relationships with those around us. By making the effort to get to know the people with whom you work and learn about what skills and abilities they bring to the table, you will be able to build some nice work relationships. These work relationships form often the cornerstone of success and satisfaction within your job and career. Also, people are more likely to go along with decisions that you want to take. Overall, I think we all want to work with people we’re on good terms with. So, building and maintaining good relations with our co-workers sounds like a good plan to me.

Embracing Conway’s law via Agile transformation & new architectural strategies

By Frédéric Crabbe
Conway’s law states that you cannot design architectures that differ much from the organisation’s communication’s structure. Since a few years, organisations have understood this link between organisational structure and the software they create, and are searching for solutions.
Some organisations are embracing new structures in order to achieve the outcome they want. Organisations in which I worked were pursuing an agile transformation. Instead of delegating tasks to employees, they wanted to create ownership by delegating responsibility (creation of self-organised & self-managed teams). In order to make such stories successful, you first need to have the power the ability to actually perform such a change in way of working. And secondly, you must introduce the appropriate constraints (taking into account the strategic business priority and the necessary governance structures).
The other way around is also possible and organisations are more and more investing in certain technologies like Microservices. Classic monolithic developed applications are no longer sufficient as they become too complex and expensive over time to evolve and changes require progressively longer development time. A microservice approach where functionality is developed and deployed independently (within well-defined boundaries) allows organisations much more flexibility in aligning the architecture of their systems to the structure of their teams in order to ensure that Conway’s law is redeemed.

Shadow IT: prepare to the inevitable

By Frédéric Crabbe Shadow IT describes IT systems and solutions created and implemented within organisations without explicit approval or knowledge from the IT department. In the current a high-efficiency workplace, Shadow IT occurs even more. Widespread available cloud-based solutions can and are often used by employees to better manage the increasing demands of their jobs. Often IT departments are also causing their own security issues due to inefficient response times which are forcing employees to find (non-approved) alternatives. Most IT departments react defensively to Shadow IT. However, in order to avoid a “IT vs. Business” mentality, IT should change its attitude towards shadow IT and create a positive, engaged and customer-driven approach. A possible start could be to focus on observing and encouraging social dialogue outside of traditional methods of interaction. Often, the only time the business talks to IT is when something has already been broken. This needs to change. So rather than IT killing all of these business initiatives directly upon discovery, collaborating with the business and bridging the disconnect gap can be a better solution.

The Wearable Bank

By Patrice Kerremans
In a sense a banking app on a mobile phone is already ‘Wearable’. Yet having apps on a Smart Watch or other ‘really’ wearable devices will allow us to do all kinds of new interesting interactions in general and with our banks specifically. Take Google Glasses, imagine them being available in normal looking designs 5 years from now. This is bound to happen and it will offer some serious possibilities. Already today some banks are experimenting with it:
CaixaBank has created an app allowing users to follow stock markets and convert currencies using their Google Glass devices and smartwatches
Westpac has their Cash Tank app on Google Glass apps, allowing users to check their balance and wire money.
Identifying yourself with a Smart Wearable Device, will rid us from the many cards. We’ll be able to do this with our phones as well of course, but still having a ring, glasses or a watch is that tad bit easier. Let’s see if consumers agree… Interesting times ahead.

For a digital transformation that rocks

By Hans Dijckmans  Companies undergoing a digital transformation should start invest much more into relational mechanisms in order to create close bonds between collaborating people and teams. Digital transformation often requires cutting-edge technology, and therefore comes with an important need for new IT skills: e.g. business process engineering, service design and APIs, cloud computing. Very often, professional IT workers need to adopt these skills in a quite short period of time. In addition, digital transformation inherently means shorter feature release cycles with less people. All these factors put quite some stress on the organisation as such, resulting in additional pressure from management on the “IT working bees”. Given these circumstances, a lot of managers tend to end up in incivility where the article “The price of incivility” by Christine Porath and Christine Pearson has clearly shown that such a style of management is very counterproductive for the organisation. Therefore, an organisation needs to arm itself against incivility. First, it needs to bring team workers closer by means of investing into relational mechanisms like offsite team events and regular delivery celebrations, enabling people to get to know each other outside the daily work context. In addition, the organisation should put reporting processes in place that chastise incivility as totally unacceptable behaviour within the company. With these measures, the company’s digital transformation process should be significantly more successful. Companies should also better stop emphasizing their main focus on the perfect design and small-scale implementation of cutting-edge technologies, methodologies or architectural styles. Instead they should better start with getting the complete workforce embracing the new concepts and up to speed on the level of knowledge and skills as soon as possible. Every now and then, a new technology, methodology or architectural style buzz word looms within the organisation. We’ve all heard about SOA, APIs, microservices, cloud computing, SCRUM, agile etc. Very often, a relatively small team within the organisation gets an open mandate to start playing with these new concepts without any clearly defined objectives. Then, they are so much dragged into this new, better world that they often forget about their most important objective: learning about the new concepts and investigating how, in a most efficient way, the rest of the organisation can benefit from the knowledge and skills they obtained. Such teams often end up behaving like scouts being send out to discover, but not coming back to explain what they saw. Organisations should be stricter on the expectations and clearer on the outcomes when proclaiming such an exploration mandate. This approach should offer a higher success rate in getting innovations rolled out throughout the complete organisation. Last, enterprise should put more digital thought leaders in the company’s strategic driving seat. The current market direction towards a digital economy comes with a whole new way of business (process) engineering. Digital transformation is all about adopting cutting-edge technologies and how to govern and manage them by means of a lean operating model using agile (delivery) methodologies. Classical board room members often lack the knowledge and skills to obtain the organisational and operational big picture on how to streamline the consecutive processes up until the delivery of the targeted customer experience and services. That’s where these digital thought leaders come into play to fill this overview gap. They can make the board room understand that serious digital foundation investments are required in order to realise the targeted enterprise benefits. A digital knowledgeable CIO and/or COO, with the help of a mature supporting CIO/COO office consisting of architects, business & technical experts, should be a big step forward in driving the company’s strategy towards a success.