Case design

What is a case exactly, anyway?

Nowadays most organizations provide customer centric services. Customer interactions are personalized: emails are started with my name; I get personalized offers; and more. But, how customer centric is this, when the processes, information and cases are the same for all (potential) customers? Are these really customer specific, or can I slap any name on any case? What is a case? Several definitions are available for case: NORA (Dutch Government Architecture Reference): “A coherent amount of work with a well-defined reason and a well-defined end result, of which quality and lead time must be monitored”; Intelligent Information Management Glossary: “A ‘case’ is any project, transaction, service or response that is ‘opened’ and ‘closed’ over a period of time to achieve resolution of a problem, claim, request, proposal, development or other complex activity.

Business modelling

An introduction

Years ago “operational excellence” was the buzz-word. With it came harmonized business processes—all customers have to go through the same process. Now, we’ve moved to “customer intimacy”: adjust the business process dynamically to the specific customer and his request. To fully embrace “customer intimacy” the whole company needs to embrace this paradigm, at all levels, in all aspects. We need to design the business from the “customer intimacy” perspective. That is: from the customer perspective.

Business rule testing

I work in a field where we thrive on supporting professionals with the tasks they need to accomplish. We gather the information and complex logic that is needed to make decisions. Naturally I work a lot with business rules and have a lot of discussion with my customers to implement them and create an application to support the professionals in their work. Due to my focus on execution of business rule and complex logic I regularly work together with companies specializing in rule management.

Liberal and conservative

Liberal conservative or conservative liberal

I was introduced to the principle “Be explicit in what you return, be liberal in what you accept” when I started as a C#-developer about two decades ago. Since, I tried to act accordingly. When developing. When I architect systems. When I design business processes. When I interact with people. In short almost always. In this post I’ll revisit this principle, both in the context programming and business process design.

Radical change

Is a radical paradigm shift possible

I like the talk “The Future of Programming”, given by Bret Victor (view at vimeo or at youtube). Since I first saw it, several years ago now, it resonated with me. The setup, the clothing, the layout and typography of the sheets, the pencils in the pocket of his shirt, it all just made sense. Even his overall theme to learn from the past, break with the status quo and try some new radical ideas did feel just right.

Innovations in Information Technology

A dive into the history of several technologies

Almost a year ago I was discussing innovations in the Information Technology domain and computer sciences in general with a colleague. Or, more specifically, we were discussing the lack of innovations. We couldn’t recall any recent innovations in the Information Technology domain, nor in the—original domain of computing—mathematics.