Archive by Author

Architect, stick to your trade!

In practice, architects are often builders, developers. So then they are butchers who are testing their own meat. Why doesn’t an architect confine himself to his primary role: designing and managing a set of rules and guidelines that contribute to consistent results? That architect can then monitor that those principles are properly followed by the builders and that they achieve the intended result in a responsible manner. Instead, I see many architects drawing up and working out the specifications for the building themselves. If I explain this to an architect, the response is often: there is no one else who follows the principles. But should you then go and build yourself? Isn’t the medicine worse than the disease?

I can well imagine that it takes a lot of self-control to limit yourself to the role of architect. It is simply very tempting for architects to get involved in the execution: that’s where it happens after all… But for centuries, separation of duties has been the most effective intervention for control. By stepping out of his actual role, the architect pulls the rug from under his initial task.

For “enterprise architects,” this is even more true. First of all, 99 percent of these architects are not concerned with enterprise architecture at all but with enterprise information system architecture. In this way, enterprise information system architects hijack an entire field. I could live with that if they set a shining example for architects in other disciplines. But look at how they model the world. From the mid-eighties, a tidal wave of ‘enterprise’ architectural models poured over us, which – with a few exceptions – were mainly characterized by matrix and layer models with aspect axes. These aspects varied with the model. If an author came up with a new aspect, it was added to such an axis, and there you are… yet another model. Just look at PRISM, Zachman, SABSA or TOGAF.

Fortunately, there were also exceptions that did not use aspect axes but structure axes. That started in 1993 with the Strategic Alignment Model (SAM), by Henderson and Venkatraman. This model became the basis for more sustainable architectural models, which also used structural axes. Think of the nine-square model commonly used in the Netherlands: a clear combination of two structural axes.

In that light, it is again surprising to see how the Dutch government presents a matrix model for its reference architectures that nevertheless contains an aspect axis (check the NORA site). This then penetrates into the reference architectures derived from NORA in numerous other disciplines: think of the GEMMA, the ZIRA, the HORA, the CORA, DIZRA and so on. When will we ever learn? Aspects – the playground of many architects – are never the basis for sustainable solutions.

This hurts even more, because it the architect who should have protected us from this all…

 

 

PTO – the new pandemic

We all do it. You do it. Your neighbor does it. Your co-workers do it. Your family does it. Your consultants do it. You even learned it in school from your teacher. PTO – Polishing the Outside. We’ve been doing it for decades. All over the world. You can rightly call it a pandemic.

With the advent of ITIL and other best practice frameworks, we have spent three decades of learning to design our organizations and our daily routines from the practices of others. A great market for suppliers, with only one taste: best practices. Nobody starts on the inside anymore. PTO.

With the arrival of the Enterprise Architecture models, we have learned since the seventies to think mainly in terms of ever-varying aspects, not in terms of sustainable structure. And then varying combinations of aspects, which were in the casual interest of the author of that model, think Zachman or TOGAF. Coming up with a new EA model was then no longer difficult: you just came up with a few other aspects, and – hey – another new model. PTO.

With the advent of business reference architectures, we also learned to take the practice of an industry as our starting point. With the arrival of a new law, a municipality will have to revise all its practices. PTO.

With the advent of improvement techniques such as SixSigma and Lean, we have learned to improve the efficiency of our work – thinking from practice. PTO.

And if we have to write a report or draw up a service agreement, then we will comment, add to, adjust, etc. on the first draft, over and over again until it contains, in the eyes of everyone, everything that is needed… and it has become an unreadable, thick document. PTO. The Dutch government even had to start a national project (‘Directly Clear’) to make the citizens understand what the civil servant actually wanted to say.

So it is a pandemic. One that most people are completely unaware of. You don’t get visibly ill from it after all… The disease even has symptoms that are pleasant for many: you often earn a good living with it. PTO.

So why is it still a disease? Because all that Polishing The Outside doesn’t really contribute to the theme that everyone is talking about nowadays: value creation. We are busy with all kinds of things, but it contributes very little net to the intended goal.

Is there a vaccine? Yes there is. And you can even brew it in your own kitchen. Just don’t polish on the outside, but start at…. The Beginning. The recipe? Taking simple, logical starting points, and then sticking to them consistently so you get efficient and consistent results. It’s called ‘architecture’. It’s based on explicit principles and building blocks. And you can apply it to any management domain. Give it a try. It takes some getting used to, but then you have something.

[Translated from my original column in Dutch, in ICT Magazine]

Framework mapping – a toy for consultants

And here it comes again: a long discussion on LinkedIn on the mapping of practice-based frameworks. Meaningless. Waste of time. A toy for consultants. And never a conclusion.

There’s no dispute on the value of those practice-based frameworks (in this case ITIL4 and COBIT and IT4IT). They all provide valuable inspiration. But the idea that mapping these frameworks would ever deliver anything but just another framework is quite naive.

And yes – it will keep the consultant off the streets, as they will always have some new details to ignorant customers, or some new technologies to incorporate in the framework. But it never delivers a sustainable solution.

The fallacy here is that this mapping only involves two derivatives. And mapping of a derivative is only meaningful if you map it to a source. Mapping 2 derivatives therefore is only meaningful if you map these to the same source.

The whole exercise of mapping ITIL4 to ITIL v3 or to COBIT or to IT4IT or to any other practice-based framework is therefore a waste of time – or a toy for consultants. Have you ever seen a sustainable solution that resulted from such a mapping? I haven’t… it only delivered another framework….

The most revealing comment in the LinkedIn discussion that caught my eye was this one:

“It’s complicated 😉 “

And that’s the only conclusion that I’ve ever seen from this kind of mapping.

Tool selection: blindfolded or new spectacles?

A few days ago, the LinkedIn group [ITIL & ITSM tools] showed an interesting post:

“I am looking to replace the existing ITSM tool being used in my organization. Looking forward for some suggestions.”

As can be expected, several group members came up with the usual response. They named their favorite product. Except for two comments, everyone seemed to ‘just answer’ the question – as usual. This is exactly the reason why organizations want to replace their tools again and again. They think about the problem “from the tool” instead of “from the goal”. Even the two commenters that asked for the requirements – instead of just naming a product – were at risk of falling for the same trap. Imho, these answers will not really help the issue of the organization, which (I hope) is “finding a sustainable solution for supporting our daily work in delivering our services”.

It’s not about the tool!

A more sustainable answer might take a different approach because the tool itself is far less important than the management system that it is supposed to support. Without the information about that management system, any answer would simply miss the point.

Navigating blindfolded

Unfortunately, most organizations are rather unaware of this: they do not have an explicit management system at all, so they’re just ‘doing their best’. Most likely, they use guidance from best practices as their main strategy. These organizations are doomed to work ineffectively and inefficiently, never reaching a high level of maturity. It’s like they select their tooling blindfolded.

New spectacles

Organizations that do understand what their management system looks like, can easily find a simple and cheap solution for the initial tooling question. They see clearly what support is needed, and what the product requirements actually are. They can avoid the pitfalls of the usual offering from tool suppliers (i.e. complexity based on a modular offering) and create a simple and cheap solution.

Organizations that are not already fully aware of their management system’s role, may want to use some new spectacles, so they see more clearly and avoid the usual pitfalls. With new spectacles, they can learn that their service management tool should not require more than 2 modules, supporting only 8 standard workflows, to deliver the actual support they need. Seeing through these new spectacles could save them a lot of effort, time, and money, but above all: it could seriously improve employee satisfaction.

New thinking

These new spectacles are based on the new thinking of USM – the Unified Service Management method. USM is complementary to the usual approach of adopting and adapting best practices from popular frameworks. USM is based on principles, offering an organization the opportunity to lay down a solid and sustainable fundament below all the practices they select, adopt, and (hopefully) adapt to fit their management system…

Following that approach is opposite to what happened in the LinkedIn group. With USM, you think first and act later, a strategy that seems to have been lost throughout the tooling industry, or at best – is largely limited to thinking about a set of technical requirements.

New spectacles for a better future

If you want to try and see how these new spectacles also fit your organization, you may start with attending a free online introduction: a 2-hour workshop, demonstrating how the new thinking of USM simplifies your challenges and provides you with a simple but very effective management system. Once you’ve done that, you may find your way into the free resources that the SURVUZ Foundation makes available for user organizations, providers, trainers, and education institutes, and you may see your future much clearer.

Why user errors are not incidents

Case 1: A user reports “I lost my password, can you reset it for me?”

Case 2: A user reports “I lost the key to my locker, can you get me a new one?”

Case 3: A user reports “I made an incorrect entry in application X, and now my data is corrupted, can you fix that?”

Numerous internal and external service providers treat these cases as incidents, as failure reports. They perform the required actions, register the request as a failure, and report on it neatly in service reporting.

Why is this wrong? The failure is fixed, right?

The fallacy

Every request from a customer/user can be traced back to a wish, an RFC, an incident, or a service request (or it is communication within a previous call). The nature of the request determines the interaction type, within the context of the agreed service.

The assumption to handle the above cases as incidents is based on the perception:

  1. that the customer is entitled to support
  2. that there is a failure in the functioning of the facilities made available
  3. that there is, therefore, a shortcoming in the actions of the service provider
  4. that the service provider must therefore repair the situation at his own expense

In all three cases, point 1 will be answered positively, otherwise, the service provider should not have taken action at all. In all three cases, however, point 2 fails, and as a consequence also points 3 and 4 fail.

After all, there is no failing of a facility: on the contrary, they function as agreed. The user cannot get into the secured application or the locker – and that is exactly the intention. In case 1 and case 2, the service agreement apparently contains an agreement about security. Unauthorized users are not allowed to access secured resources (the application, the locker). Thus, the facility is functioning correctly and therefore there cannot be a failure.

Both cases are therefore examples of user errors, as is case 3.

The Solution

In all three cases, the user wants to be supported. To ensure that this happens, the right to this support must first be agreed upon. This is done in the service agreement, the SLA.

As soon as it is agreed in the SLA that a facility will be secured (cases 1 and 2), the customer and supplier must also agree on what happens if the user makes an error (i.e. losing the key). The solution is simple: the supplier should provide additional actions (“provide additional password/key”). The costs for these extra actions should then be laid down in the SLA. Logically, the customer will have to pay extra because the customer causes the extra actions.

The same applies to all other user errors. Customers and providers must agree in the SLA which support the provider will provide if the customer makes an error that leads to extra effort and how the extra costs will be settled.

Practice shows that numerous user errors are registered and handled as incidents. Those situations detract from a proper customer-provider relationship and lead to errors in the provider’s performance evaluation and in service agreements.

Those who follow the simple logic of the USM management system can easily discuss those situations in service negotiations, and then handle them easily and correctly.

If you want to learn more about a simple, systematic, and methodical way of solving issues like these, you’re invited to a free online workshop. The SURVUZ Foundation now provides these workshops on a regular basis (2 per week), to cope with the overwhelming interest for the new thinking of USM for Service Management Architecture, and for Enterprise Service Management. A workshop takes 2 hours and is a very intensive activity. Starting times will be alternating 09:00 CET (to accommodate the eastern hemisphere) and 15:30 CET (to accommodate the western hemisphere).

If you want to catch up on what you didn’t learn at school, 2021 is the year to do so. As we aim for small groups to foster discussion in the interactive workshops, registration is required. You can register at the USM Portal.