- Development (17)
- Duurzaamheid (4)
- Enterprise Architecture (60)
- General (76)
- Uncategorized (111)
Tagsagile agile IT organisatie agile organisatie Agile project management agilization application management architecture CI Cloud Transformation collaboration Compliance customer intelligence Customer Management Customer Value efficiency emergence enterprise collaboration future proof Holland Heineken House innovatie Insight Klantbehoud Klantgerichtheid Kosten besparen kostenbesparing Legacy London2012 MDA MDD model driven development Modernization motivation Move ICT offshore onderzoek product innovatie productivity quality Scrum Simplicity software development software factory Sourcing Visualization wendbaarheid
The Four Laws of Simplicity, and How to Apply Them to Life
Last week I came across an article with the above title. While reading, it crossed my mind what would happen if we would substitute the last word for Enterprise Architecture. First let me give you an idea of the article.
Four rules for a simple life
1. Collect everything in one place.
2. Choose the essential.
3. Eliminate the rest.
4. Organize the remaining stuff neatly and nicely.
Sounds simple? Let’s give a small example from the article to illustrate.
” Do you really need 40 T-shirts? Or 40 pairs of shoes? How many jeans do you actually wear? One drawer or section of your closet at a time, put everything on your bed in a pile, choose the clothes you really love and actually wear on a regular basis, donate the rest, and put the ones you love back in your drawers or closet. Leave space around the clothes — don’t stuff your drawers full.”
To run this example, you need two essential skills:
■ You should be able to select (what clothes do you want?) and
■ You should be able to eliminate (what clothes do you dispose off?).
And now, enterprise architecture, Select and Eliminate
In enterprise architecture, I draw a parallel with the execution of a technology innovation in a company. A company wants to know the impact for a future, company-wide deployment of new technology. The approach is to perform an impact analysis and a first step is often an inventory of the current IT landscape (rule 1). In these studies you will sometimes find hundreds to thousands of applications. For some of the applications you doubt the usefulness. How do you find out which applications are really necessary?
In analogy to the example above, we must look at the usage of these applications. Based on usage statistics, we can see which applications are widely used. But low usage does not always mean low value. To measure the value of an application we must look at how well it supports a business processes. Based on usage, value and other discriminators (e.g. knowledge) we can decide what applications are impacted by the technology adaptation (rule 2). So far nothing new, it seems that we have mastered the select skill quite well.
But I see things going wrong with the eliminate skill. After the applications have been mapped, we quickly give attention to the design and implementation of projects for the change at hand (rule 4). We take too little time to dispose of the applications that we no longer need (rule 3). You must have heard one of these lines before:
■ we cannot put the old system down, because there is still data in it,
■ department X will not go over to the new system because they don’t want to learn a new system,
■ there is no budget to finance the dismissal of system Y.
Elimination is a skill and it should be given attention in project plans. Only focusing on creation and not on destruction will make the landscape complex and expensive. For a simple enterprise architecture, it is imperative that we throw away more.