The Human Centered IT Architect

Architects nowadays are way too technical and backend-focused. Let’s focus a little bit more on the user. We tend to forget it. Even if we build applications with a UI.

I have written a blog post for Capgemini about this topic:

Wenn man schwarz-weiß sehen möchte, gibt es in der IT-Welt zwei verschiedene Architekten: Auf der einen Seite den Enterprise Architect und auf der anderen den Solutions- oder auch Applications-Architekt. Der Unterschied zwischen beiden ist die Flughöhe: Wenn man Gebäude als Analogie nimmt, dann kümmert sich ein Enterprise Architekt um die Stadtplanung und ein Solutions/Applications-Architekt um die Gebäudeplanung – beide begleiten natürlich auch die Umsetzung. Was beide jedoch gemeinsam haben ist ein starker Backend-Fokus: Zwar kümmern sich beide auch um Strategiethemen und fachliche Anforderungen, wenn es jedoch um die IT und ihre Umsetzung geht, dann sind beide in der sehr technischen Backend-Welt zwischen Schnittstellen, 3-Schichten-Modell und Datenbanken zuhause. Das kenne ich sowohl von der Ausbildung im Studium als auch von der gelebten Rolle und deren Verständnis in verschiedensten Unternehmen. Was hier jedoch vergessen wird, ist der wichtigste Faktor überhaupt: Der User.

UX is sexy, UI is hot

I have shared some further thoughts about how to create applications to love. Most people think you only need to add a little UX and a little UI and the outcome is an awesome app to love. That’s not the case. What else you need to consider is described in my blog post @ the Capgemini blog:

[…] Was ich auf Kundenseite auch sehe ist oft der Gedanke, dass, wenn man geliebte Applikationen bauen möchte, einfach am Anfang ein wenig User Experience (UX) und User Interface (UI) oder beides streuen muss und der Rest wächst von ganz allein. Das ist leider nicht so. User Experience, die sich gut anfühlt und ein User Interface, das gut aussieht sind wichtige Bausteine, aber lange nicht alles. Für Entwicklungsleiter, Projektleiter, Architekten und CTOs unverzichtbares Wissen. Jedoch auch für ambitionierte und interessierte Entwickler. Meine fünf Tipps für Applikationen die die Anwender lieben werden. […]

UX ist sexy, UI ist hot, aber sie allein sind kein Erfolgsrezept für Applikationen die man liebt @ Capgemini Blog

RESTful Resource URI/URL Naming – the missing piece

There are a lot of tutorials on the internet about RESTful URI/URL naming conventions – a good example is this one. If you are building modern web apps (which might make use of REST) you should build modern URLs. Bad URLs not only look ugly, they are definitely not useful in regards to search engine optimization.

Nevertheless all of them (didn’t find a single one which has it) have a missing piece which is needed and I have often seen done wrong. On the one hand it is not directly about REST on the other hand it is required to build all of this. But first a quick summary what you can find everywhere:

You are building the website example.tld which has customers. Customers can be viewed/read, added, edited/updated and deleted. So you are needing those URLs and requests:

Adding: POST example.tld/customers

Viewing/reading: GET example.tld/customers/1234 (1234 represents the customer id)

Editing/updating: PUT example.tld/customers/1234

Deleting: DELETE example.tld/customers/1234

This can be also done with some kind of hierarchy: example.tld/customers/1234/orders/5678

I think this makes the naming convention clear. The ids can also be exchanged with a unique readable URL for SEO friendliness:


Or better combining both versions like stackoverflow does it:


This gives you the advantage to only have the id as an internal identifier, plus a readable url, but this URL can be easily exchanged and doesn’t have to be unique.

What is the missing piece? The URL under which the user can add a new customer or edit an existing one.

What I often see and you should not do is something like this:

GET example.tld/addcustomers

GET example.tld/edit_customers/1234

GET example.tld/customers_add

This kills the complete convention you’re following.

What you should do instead:

GET example.tld/customers/add

GET example.tld/customers/1234/edit

Like this the URL convention is not broken, it makes totally sense and does not mess anything up.

How the public sector can profit from the blockchain via Java and IBM Bluemix

Wonderful colleagues and I wrote a brand new article for the current JavaSPEKTRUM 03/2017: “Kontrolle ist gut, Vertrauen ist besser – So könnte der öffentliche Sektor von Blockchain profitieren” (article extract link).

First, we look at possible use cases for Blockchain in the public sector and walk through them. Then we will tell how to decide wheter a use case is suitable or not. In the end we will describe how to implement it using Java and IBM Bluemix – of course with code snippets.

If you have questions or want to discuss about it – send me a message via email or Twitter.

Make elections sexy again: How the blockchain can digitalize our elections

For my company – Capgemini – I wrote a guest article for the IT-Trends Blog. It is about how we can use the blockchain technology to improve our elections. To digitalize them, make them more transparent and securer and: sexy.

Read it and tell me what you think. I will gladly discuss it with you: Capgemini IT-Trends Blog Artikle “Blockchain: Die Wundertechnologie für Wahlen?”

Reference Architecture Aviation in cooperation with Lufthansa

Over the past months wonderful colleagues and I were working on a reference architecture for the aviation sector. We did this in cooperation with Lufthansa working after TOGAF.

Almost before handing it over to The Open Group we released a article in the current NEWSolutions magazine about our work. There we described how we created this reference architecture and gave examples from the work output.

NEWSolutions Cover 2016 Nr 6

This will helps the aviation sector to standardize products with vendors and interested people or students to study how an architecture in the aviation sector looks like. Check it out.

The correct usage of Blockchain to avoid any hype usage

Blockchain is a hype technology nowadays. The financial sector is shaking and fearing the last years of their existance and what comes with every hype technology is hype use cases which were created by companies in order to sell it to customers who do not understand the technology but somehow want to be “up-to-date”.

To get a better knowledge about Blockchain you have to dive deep into it to truly understand it. It is not an easy technology to get within seconds. My thoughts: Most of the videos and articles google gives you can not describe what Blockchain is.

Simplifying it: Blockchain is a sort of a database. It can store data in a special “Blockchain-way”. And this is where it gets tricky: Just to store data, it is easier to store data in a SQL database, NoSQL database or other. They are faster and get stuff easier done.

A good use case for Blockchain is one where data needs to get verified by peers. So the only reason to use Blockchain to save data is to gain trust.

Three use cases:

Use case one is a bank. By transfering x money from one bank account to another, the bank takes care that one side has x money less and the other side has x money more. And they might be charging you for it or it takes some time (maybe a day or two or even more). Technology can leverage this by minimizing costs and doing it almost just in time. A bank here is some sort of a trust center. Both parties trust their bank to do this in the right way. To eliminate the third party – everybody needs to trust the technology.

Use case two is an election. Ultimatively the counting of votes are done by the government. But who takes care that they do it right? Who can observe it? With technology the counting can be automated and investigated by everyone afterwards. Trust again is the major driver.

Use case three is notary. Buying a house in Germany needs a notary to verify it. Technology can verify it too and everyone can check who owns this house or property. This speeds processes up and minimizes costs.

All of this is done with the decentralization of datasets which are connected. Not one person, organization or similar holds the data sovereignty, but as many people can save this data when they just want to do it. If someone manipulates a dataset in one blockchain on their local environment, all the other peers have an unmanipulated version of it and can therefore prove what is wrong and what is right.

Just to store data in a modern way, Blockchain is not a solution. There are way better options which are simpler and faster.

Blockchain is for gaining trust where normally a third party will guarantee trust. This third party trust costs and the process is slower and more complicated. Blockchain is not just for saving data.

Social media is challenged by traditional media responsibilities

The case of Trump winning the US election is surprising. No polling institute could have predicted this result. There are many articles with attemps to explain how this could happen. And the felt truth is that if you search long enough you will find every reason, from it was Hillarys fault, over Trump using “the art of war” principles (not kidding), up to a systematic failure of social media.

Nowadays, social media is playing a major role. This was the case in the last two Obama elections, it was the case in this election and it will be more and more in the future. What is new, is the discussion about how a failure in the system of social media could lead to a “wrong” outcome. More specifically: How can fake news influence voters in thinking wrong statements are fact and therefore voting for a wrong candidate they never wanted to vote for.

I think about this almost everytime I am using Spotify. Based on what it thinks I like, it will recommend me and show me music I should like. I hate it. I want to discover new music and just hear random songs which I do not know and find out if I like it. Maybe I like Schranz but I would never discover it if Spotify just shows me what it thinks I like based on what I hear? (Spoiler: I do not like it)

Without actively countersteering against these algorithms, it will be a neverending circle downwards in what the algorithm thinks you like, but you do only to a certain degree. And you get tired countersteering against it. After a while you just let it happen, because the algorithm never gets tired. And this is how “news” showing up works on Facebook.

It is easy to let Facebook influence you in only one direction. And you pull friends into it, too. Additionally it is very easy to just isolate yourself against other opinions. In the past this was not even possible. Reading news without seeing other headlines is almost impossible. Also talking and discussing about events and opinions is mostly enrichened by a even just a few other opinions. To block those opinions was not that easy. It is now. Just a few clicks ahead.

An opinion should not only base on one opinion or one side of the medal. But actually on hearing every side, thinking about what is right for yourself and then decide what your opinion really is. With social media this is not the case. What it lacks is an editor service like traditional newspapers have. Give readers a distinguished picture of what happens, what “facts” are right and wrong and also expose lies and wrong stories.

Facebook has seen itself for many years as just a platform where people can share content. But to only distancing itself from the responsibility of what is shared is not an option. Facebook realized this by making a decision of not showing nipples on the platform, they realized it by having lawsuits against themselfes in Germany because of demagoguery and they realized it now. What lacks is a solution to the problem. And firing all human editors and trusting only AI is maybe not the right solution, because there is often a large context to consider. Is a nipple porn? What about breast cancer awareness campaign? (Fun fact: In Germany there is a fixed degree a penis can stand without being porn (I think it was 45°))

For Spotify and Amazon this decision is an easy one. They add the degree of showing products which they think the user likely likes and compares it with an A/B-test based on usage and revenue. For Facebook it is more complicated – it is not just about how much revenue they generate and how long users stay on facebook, it is about how much they care about their users and about how much they care about them, that they get fact-checked distinguished opinions to make their own decisions.

“On the dark art of software estimation”

Found a great article about software estimation. Something in software development that still bothers me somehow. Nevertheless we all know it is somehow essential.

Love this one:

Let’s take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach. I’ll whip out my map and draw our route down the coast … The line is about 400 miles long; we can walk 4 miles per hour for 10 hours per day, so we’ll be there in 10 days. We call our friends and book dinner for next Sunday night, when we will roll in triumphantly at 6 p.m.

On the dark art of software estimation