Tag: dagelijks leven (Pagina 2 van 2)

Is it wrong to come up with results that are not perfect?

In my field of work, the IT architects seem to be the guys in an ivory tower preoccupied with the perfect solutions, never implemented. Do they take other people and reality seriously?

Old school versus executable architecture

The main difference between old school IT architecture and executable IT architecture is whether architects let themselves be influenced by the business: old school architecture is not influenced by the business. Let me explain that with a story.

Lovely carrot pastries

An organization has its own bakery to service the employees during lunch-break. The bakery sells carrot cake and carrot bread and carrot cookies. Is it a problem when these lovely products remain unsold? There is no problem for the baker: as a expert he appreciates the most wonderful, nutritious, CO2 neutral pastries he has created. It is a shame that nobody wants to buy these products, but the baker is happy about his products and will not be fired by his management: he is not depending on sales numbers. The management runs business, sees the need for healthy food and lacks the expertise and urge to decide on these food matters. It is annoying for the baker that he is requested by the other employees to advise on their lunch components: what would be healthy, nutritious, crispy, sweet or sour?
What would you do if you were the baker? Would you

1. carry on with carrot products or
2. will you complain about lacking management support or
3. could you develop new products that are fun to make and fun to eat based on the wishes of your potential customers?

Carrying on with carrot products results eventually in a existence-issue: do we really need an own bakery selling products no one really wants to buy? That is not a viable option. And the second option? Well, I have been in an organization where management ordered everyone to buy the carrot products. Luckily our carrot products were of high quality. The customers were not delighted and were eager to find an escape route. But if you lack this support, how would you try to get that support of both management and employees? Do you need that support?

Void perfection

For most Enterprise Architects this is all a no-brainer: their work and products are important and of high quality. Sometimes they deliver not in time but that it because they have to do too many things for which they by principle should not be responsible, like advise or second-opinion or third level support on issues normal administration is uncertain about. Their role is like the Muppets Show’s character Sam the American Eagle: of highly moral standards completely out of order with their context. “The quality of my products is second to none” and everybody continues with business as usual.

First steps on a journey

For someone who wants to do executable architecture this context is the start of a journey, accompanied by questions like:

• Can I understand what my customers want and understand as healthy?
• Can I translate that in viable and usable products?
• Can I understand what my potential customers do not like about buying and consuming my products or services?
• Can I motivate my customers to change their minds on food habits?
• What would be the hookup to correlate with them?
• What are my and their constraints? In communication, producing and consuming?

These questions are related to the third option: not carrying on with “this is how we always have done it” nor requesting management support, but turning towards customers and have fun in creating products that will be sold. Still, too many architects are convinced they ask those questions already and have answered them consistently, by themselves. They have answered the questions without really listening to management and customers. Could it be that architects are highly intelligent and cooperative people that are themselves the roadblocks for progress? The conflict with their context becomes even greater when employees are absent because their unhealthy food habits and business -the object of management- is thus endangered: what is the point of an own bakery when it does not improve the average health? What went wrong, how can we improve this situation? Why can’t we have the baker put extra sugar in his products, perhaps that is not 100% healthy but always better than the present unhealthy food our employees consume?

You cannot answer the question whether or not architecturing is necessary and how to judge, use and evaluate archtecture by just creating another architecture as if that is a self-explanatory concept, clear to your readers and audience. The present history has shows that architecture is so untangible that continuing to do-your-thing is missing the point of the questions we, managers and customers are confronted with.

Executable architecture

Executable architecture aims at goals just like old school architecture but does so by solving present customers’ problems with solutions that aim at further rather general goals. The problems come first and out of the solutions we create directions, directives and goals are abstracted and defined. We should solve issues in such a way that we can leverage the solution in other cases as well. That is completely different from pondering in peace and come up with a principle  a long time after the solution was needed.

In general it all depends on the acceptance of the imperfect, in work and private, and the improvement in small steps.

These thoughts are influenced by

• work on agility, architecture and provisioning of capabilties by Nanette Brown, and
• killer questions, by Phil McKinney, and
• wabi-sabi, the appreciation of the imperfect, like http://www.utne.com/mind-and-body/wabi-sabi.aspx http://seekeronline.info/journals/y2002/oct02.html

Image origins (unchanged usage):

• Thomas Quine, https://www.flickr.com/photos/quinet/70870461/
• http://www.huffingtonpost.com/2007/07/31/sam-the-american-eagle-do_n_58533.html