Archive for October, 2011

About Architects, Abstracting and How to Practice the Art of Anti-Abundance

That’s a lot of A’s in this title! Maybe I was a little bit too abundant. But don’t blame me: abundance is quite normal if you work in ICT. More is good. Big is good. Expensive ecosystems give you status. Overdimensioned (eco)systems are very good (never know if you need abundant functions later). Overloaded functional features are good. Risk-averse built-to-last architectures are the way to go. (You don’t really think I mean this do you?) So far for Abundance, now for Abstracting, a task that architects typically need to be able to deal with in their day-to-day work. Look at the pictures below. Inspired by one of my collegues. You can see a model* of The World, Africa, The Desert and a handful of Desert Sand. We could even add more abstraction levels: the Universe, a single grain of sand, the atoms in the grain etc. So we sometimes need different levels of abstraction. The abstraction level depends on what you want to tell and to who you want to tell it. (IT) architects sometimes here people ask: do you have an overview picture of the complete architecture? The people asking think that such a picture exists (it should, shouldn’t it?) and that architects by all means should be able to reproduce that very quickly. That’s what they’re paid for, right?  Well, if that seems to be the case, we could get inspired by modelling our tiny ITC world just like Google Earth: it can zoom-in from the universe, to the world, to a country, to a city, a street and even more details lately, In ICT environments, this still is a very tedious and difficult job. So wWhen will the time come that IT architects can model the (virtual) world they are working in with zoom-in/zoom-out tools comparable to Google Earth??? Or to make things more SIMPEL: should ICT architects just not try to model the world they’re working in but instead limit themselves to modeling the essence of the questions they need to answer? Less is more approach???

* Any model isn’t representative because it allways leaves out certain details, but some models can be useful…


How Learning Organizations, Dalai Lama, Plato’s Cave and the Veil of Forgetfulness can Change Your Life

What do Learning Organizations, Plato’s Cave and the Veil of Forgetfulness have to do with eachother? Let me try to explain a little bit. Every person on this planet has to learn. You can do this roughly two ways: learning by the book (risc avoiding) or learning by making mistakes (risc seeking). If we project this onto Plato’s Case we can see basically two “types” of people in there (sorry for the categorization, just done here to explain the concepts). The ones who look at the illusions and thus only see reflections, they don’t see the real light outside. Maybe they even don’t want to see the real light. If that is the case, better leave them be where they are happy, don’t force them to learn things they don’t want to learn. They’re probably just happy where they are.  And then you have the other “types”  of people, those who want to discover, and who don’t want to live in illusions. These are the people that probably want to ascent to the (sun)light and are probably very open to share their knowledge with anyone.  What they should never forget is to apply the Universal Law of Free Will when trying to share their knowledge to those who are not really open for it. And then finally, there is the Veil of Forgetfulness. What the veil says is that if there is no misunderstanding there will also be no error. So if there is no error, there is no experience. And if there is no experience, there is no spiritual growth in the brain. So people definetely need chances to learn by making errors sometimes. This is what the veil is meant for. And now wrapping it all up: if you want to help an organization or group of people or a culture or a network become a learning organization, never forget to use the Law of Free Will to find people who want to learn from others. Also never forget the Veil of Forgetfulness to help find those people that want to learn by making mistakes. And apply Dalai Lama’s statement  “Life is too short to learn all things yourself by experience” to find those people that are open to learn from others.

Information Power to the People And How You Could Apply The New Filtering

Nowadays many people suffer from information overload. Modern IT technology has made it possible to produce many times more information than we ever are able to consume. So we need some clever filters. I call this The New Filtering. I believe there can never be a better filter than you yourself. So The New Filtering should be implemented from a Filter Your Own Information (FYOI) approach.

This leads to the following architecture principle:

Your information or information meant for you will be consumed by you where you want to consume it, when you want to consume it and how you want to consume it.

This approach helps giving (Information) Power to the People (or you could also call it “Data to the People”). So the filter freedom should be totally up to the information consumer. After all nobody knows better than you yourself what you want to know, right? And in the end, the only thing that really counts is what you don’t know, the rest is probably waste…

How Abstraction Errors Can Lead to Erroneous Distribution of Complexity and How to Avoid that

Ever seen a stereogram? Shown in the left there’s an example. It contains hidden (abstracted) visuals. Now try looking to your organization (which might very well be a complex social system) as if it were a stereogram. Now imagine that you are the architect that thinks remodeling or redesigning this organization is a fairly easy job, right? That’s because you abstracted out all social complexity (you didn’t see the real picture in the stereogram). What then remains is a cold, rational model of a lifeless organization. Now that’s very easy to remodel. After all, social aspects are not your problem to solve, right? Well, I don’t agree. Architects should model or design organizations built for human beings first, and not only for organizational models that are mathematically or economically correct. Architecture that was designed for human beings should after all  work the best of all. So if you in your architecture work are abstracting out a certain unavoidable complexity (for example social complexity, especially in larger organizations), chances are that your design will be lousy because you distributed complexity in a wrong area (abstracted it “away”) instead of coping with it in your design. By coping with it in your design, you leeave the design complexity to yourself instead of to your customers.

If Anything Should Be Common, It Is Sense and Why You Should be Careful When Trying to Centralize Something

One of the famous quotes of Voltaire (a French author, humanist, rationalist, and satirist who lived from 1694 – 1778) was: Common Sense is not so Common. Now what did he mean by that? And is there a relation with Garret Hardin’s Tragedy of the Commons? Possibly. The way I look at it is that we tend to simplify complex matters by first making them “common”. And then we say to each other that what we have simplified is just common sense, isn’t it? This is in fact an abstraction strategy which can be dangerous. By trying to abstract the dirty details to a level that they seem invisible or not relevant anymore, it’s easy to sell your change as if it were something common, and what we should change to is just common sense, right? So we have integrated some of the unwanted details into some kind of common concept by leaving them out (after all, it’s not our job to look at the details, right?) This is where change or transformational strategies sometimes go wrong, simply because the theoretical abstraction you have developed, is not at all that easy to realize. So we forgot to look at the impact of the details because we abstracted them out, leave the dirty details for later. To explain this line of thinking a little further, you might also read the post: Culture eats Strategy for Breakfast (and how to eat breakfast). So you see now, Common Sense is not so Common at all and you should be very careful by implementing Tragedy of the Commons concepts, strategies or architectures without a good analysis of the impact.

Culture eats Strategy for Breakfast (and how to eat breakfast)

Ofcourse you know everything about deliberate strategies or architectures (the ones you designed yourself).  And ofcourse you know everything about emergent strategy or architecture, the one that your organization realizes in reality. It’s all hidden in the golden word “real”.  So the real difference is that reality realizes real strategies, and that’s just exactly why culture eats strategy for breakfast. So next time you design a strategy (or architecture for that fact), first check with the realists in your company if it is realizable. This approach is also very good in line with Asby’s Law that states that the controlling system (“the strategy” in this example) must be equally complex or complexer than the controlled system (“the organization” in this example). So if you really want to eat breakfast next time, first ask the cooks how it should be prepared (they might give you some clues…).  Final quote: if your realists say it’s realizable then reality realizes real strategies.

About the Declaration of (In)dependence, Tightly Coupled Architectures and When not to use Swiss-Army-Knives

Who doesn’t know about the famous Declaration of Independence? Stolen by Nicolas Cage in the movie National Treasure. What is the relation with this post? And why did I title it the declaration of (In)dependence? It’s because I want to make clear that traditional (ICT) architectural choices we still design nowadays in fact have very little to do with independence but everything with dependence! Many of these architectures are in fact tightly coupled which makes it very difficult for customers of these architectures to change them. There just are too much dependencies built in. Many of the architectures behave as if they were swiss-army-knives. Overloaded with tons of possible future features. Because they were designed to fit almost any (future) scenario they have become needlessly complex. The more complex, the more unstable such an architecture becomes over time. Because all of the swiss-army-knive individual components are “glued” together using a common backbone (platform infrastructure) you cannot easily get rid of it. It seems the only sensible way of overcoming this needless complexity, overprovisioning, inflexibility and overloading of features is by building partial, simpler, fit-for-purpose architectures around it.

Tag Cloud

%d bloggers like this: