The Restaurant at the End of the Internet

When looking back on my blog entries over the past two months, you might notice that some have a more theoretical nature, while others have a more practical and/or societal nature. This mix reflects my dual role in industry and academia. I've been discussing this with some people. An obvious strategy would be to move the more theoretical entries to a separate blog. After some reflection I decided that I really shouldn't do so, but rather ensure I present the more theoretical topics in a way that is appealing to a wider audience. Actually, I consider this to be one of my personal challenges. As discussed in one of my previous postings, I think we should move to towards slow science . I think part of that should include more the communication of scientific ideas to a wider audience, e.g. in terms of blogs,. I feel dearly about the scientific topics I have blogged about earlier. I think these topics deserve a fundamental approach. At the same time, the relevance of these topics to...

I was planning to write a blog entry on "Science 2.0". Increasingly, scientists make use of blogs to communicate about their research, in addition to traditional forms of publishing. I think this is really a positive sign in the sense that it may indicate a move back to more open scientific debates . I intended to discuss how science may have to change its trades in the sense that over the past 40 to 50 years, the scientific debate has made way for a competitive trade of producing ever more papers and even more citations to one's work. Meanwhile, the focus on measuring scientific production instead of fostering scientific debate has produced several, documented , negative side-effects. Sure! Quality of academic research is an issue, but reducing it to paper-counting is likely not to be the answer. What is known as bean-counting in industry has been supplemented by paper-counting in academia. That was my plan. But then, I wrote my two previous entries on From "th...

Reflecting more on my previous post, i realised that balancing between "think unless" and "act unless" should really be thought of as an attitude issue, and not some technique. Just as well as Zen is not just a technique, but something deeper, an attitude, a spiritual way of being, balancing the think/act principles requires more than applying a technique. The balance requires a continuous awareness of the tensions at play: Have we done enough thinking? Aren't we stalling to much, before really acting? In the context of business and IT transformations, my playing ground, we really need more of this balance. Especially in terms of a change of attitude . Business management, program managers, enterprise architects, IT architects, project leaders and engineers, all should do some critical introspection to see if they strike the right balance between thinking and acting. Especially in the current crises. Should we panic? Should we blindly cut costs? Or should we ca...

There is this old issue of "analysis paralysis". In other words, spending lots of time on analysing a problem at hand, studying several potential solutions, all the while not solving the actual problem as it exists in the real world. This has resulted in several caricatures of analysts and designers losing themselves in "model space", while enjoying large quantities of coffee in their ivory towers. Meanwhile, at the other extreme, we find the pushy project manager who only has sight for the project deadlines, as well as the eager, hyped on coca-cola, engineer who already has "the solution" and looks in total amazement at those analysts who still haven't found "the solution". Then there are cases where one makes hasty decisions during analysis and design, bravely referring to "pragmatism", where this is really used as an excuse to not think. " Well, you know how it works in practice, we have to be pragmatic ". More often...

Just a short blog this weekend. Well. If you actually count carefully, you will see that I am lagging behind in my new year's resolution to post one entry per week. One of my colleagues ( Ron Tolido ) keeps telling me to write shorter blogs anyway. We live in a day and age where access to the internet is almost ubiquitous. Fair enough. This only applies to the so-called Western world. When disgracefully limiting our view to the Western part of the world, internet access is everywhere. The invisible infostructure is neigh. In whichever city you are, places like Starbucks provide you with free internet access. But wait. What happens if you travel around? I've noticed that when I'm traveling around, the cheaper hotels quite often provide free or really cheap WiFi access, while the more expensive hotels tend not to. At the top end hotels you end up paying 15 to 20 Euro a day to get WiFi access. In the age of the invisible infostructure , I think this is almost like having t...

Building further on one of my previous blogs on model-based enterprise engineering I came to the conclusion that model-based enterprise engineering really is an application of what I would like to call " model assisted problem solving in multi-actor environments ". This may sound as an over-the-top generalisation, but it think it also signifies the core competency of enterprise engineers and enterprise architects. And at a time of crises I think it is wise to better understand the core competency of our profession. Note that the word "problem" should be interpreted in a broad sense. Moving from e.g. a formulated business strategy to a plan for its actual execution can be regarded as a "problem". When moving from a "problem" to a "solution", one will go through the earlier discussed assess/aim/act processes: During the assess process, models are used to capture knowledge about the problem, its context, and what should be done about it...

In the context of enterprise architecture, IT architecture, (software) system development, et cetera, we use several models. Some models have a descriptive nature (e.g. UML, ArchiMate and DEMO models) and some have a prescriptive nature (e.g. sets of business rules and architecture principles). All of these models are created for many different purposes. At the same time, the creation of these models takes time and effort. In other words, they cost money. This raises the question of how these investments can be put to good use? How to increase the return on investments put into models? In other words, how to achieve return on modelling effort (RoME)? Since a year or two, my research group at the University of Nijmegen has been using the return on modelling effort question as one of the drivers in its research activities. Below I'll venture out and explore some potential returns of modelling efforts. Knowing beforehand what the expected return of modelling effort for a given model...