Drawing lines and stations

I like the way how this way of drawing emphasizes the importance of an interchange station: the more lines crossing, the bigger the interchange station will be.

The concept of the planet has never been very clear.  The Greece were the first who talked about planets or wandering stars, by which they meant the with the naked eye visible bodies in the sky: Mercury, Venus, Mars, Jupiter, and Saturn. But soon it was also an accepted practice to include the sun and the moon into the planet concept (which were later separated again).

Thanks to the advancing technology it became possible to see more and more different kinds of bodies in the sky. Concepts like natural satellites, minor moons, asteroids, interplanetary and comets emerged. But the boundaries between those different concepts were and still are not always very clear. Now we have the situation that nobody really knows how much planets there really are in our solar system because the answer depends on your education, your awareness about the recent controversy, the new guidelines from the IAU about the planet concept and most important: your personal point of view.  In short: if somebody is telling me a story about planets without telling me what the concept itself is representing I don’t have a clue which real things are the subject of the story.

Another more simple example could be that you read the sentence: Somebody stole my bike! What real things do the concepts somebody and bike represent? That totally depends on the situation in which it is told! Only the mind’s eye of the writer will know that until we receive some factual data.

We need concepts to communicate with each other but the used concepts should be supported, as science does, by some factual data to give the audience some clues about the context of the story… Certainly because “the conceptual analysis  method seems to rely on some sort of definitional structure of concepts, so that one can give necessary and sufficient conditions for the application of the concept.” [Wikipedia: conceptual analysis controversy] In digital architecture with all its  concepts, none of which belongs to one clear definitional structure, it is even more important to supply factual data. Especially when you are trying to define some kind of definitional  structure for analysis purposes.

The goal of architecture is not to change a fuzzy, philosophical representation of the real world, we want to change the real thing itself! This all leads to the equation

Conceptual Architecture + Factual Data = Factual Architecture!

I’m not so fond of the excessive usage of concepts in architecture. But let me first tell you about Kipling’s six servants:

Their names are What and Why and When
And How and Where and Who.

The six servants are often, e.g. in journalism, used as a kind of critical questioning framework to check if a story  is “complete”. But stories are always told in some context defined by place and time. Critical questions are also asked in a certain context defined by place and time.  Both contexts never matches exactly.  The best match will be during reflective writing and sketching.  But after that both contexts will move further and further apart until they will reach a point where concepts valid in the storyteller’s context will be perceived as fuzzy or even invalid in the context of the intended audience. If this point is reached the story has become incomprehensible and unverifiable for the audience and won’t be trusted. The trick for the storyteller is to stay in touch with the context of the audience so that the story will stay comprehensible and verifiable!

To explain my problem with concepts I’ve made a sketch of how I see the relation between the six servants:

If you want to tell a factual story the Who, the intended audience, the How and  the What are the key servants, contained in some context by the Where and the When. The Why is the plot of the story: some kind of shared vision, insight or idea the storyteller want to “sell” to the audience.

(Building & City) Architects in the real world are mostly dealing with the Where, with the structure of spaces. The context in which these architects operate is reasonably clear for their audience. And those architects are well aware of the diversity of their audience, consisting mostly of owners, contractors, builders, regulators and stories are adapted to fit the language of those  subsets depending on the context.

Architects in the digital world are dealing with … everything from infrastructure to the monetary system. Architects in the digital world hardly ever use factual facts to build there stories or critical questioning frameworks, like the six servants, to check there own stories. Also they seem not well aware of the diversity of the subsets in their audience. They are constantly busy with their own internal-focused expert language by defining and changing concepts, concepts about concepts and concepts about concepts about concepts and… well you get the picture.  And worst of all, they present this internal-focused language as the logical truth and the concepts as facts and they use both to tell their stories. But concepts are not real. The language and concepts used by digital architects make their stories so abstract and fuzzy for their intended audience that those stories become unverifiable. Would you trust unverifiable stories when you need to make decisions about important changes?

It is time to go back to the basics and tell stories about, for the audience verifiable, Factual Architectures!

Do you think it is worth the effort to continue this prototyping journey or should I perhaps focus on interactive tubemaps?

But asking the question was really giving the answer because in my mind I already made the decision and I shared this decision in the form of a Skitched sketch on Twitter:

Focus

I made this sketch when I was reading  Stefan Bucher‘s 344 Questions book. A book I discovered thanks to Ruth Malan. Ruth made also some interesting remarks in her journal regarding my (re)focus question.  I will quote those remarks (in italic) here and give my reaction below each quote.

As I read it, the “itch” or need you’re compelled by is the (exploding!) complexity of organizations and the need for better maps to help make these complex organizational landscapes (and their evolution) at least more simple to depict/represent, to navigate, to explore, to understand and relate and propose and design or improve.

Ruth hits the nail on the head I see models as “thinking devices” and maps as “communication devices”.  Models are helpful when you want to understand the (or better your little part of the) world and the possible consequences of some decisions you must take. Maps helps you to explain how the world looks (in the past, the now, the future or in any combination of those three) without showing unnecessary details.

And, further as I read it, you see tubemapping as a form that would make great contribution in addressing this need.

I don’t know if it will be a “great” contribution but yes I think there is a place for tubemapping in the world of mapmaking.  I now want to try to add a bit more information to the tubemaps:

• add area and hyperlink info so that they can be used as image maps on the internet
• add a little bit more stuff on the tubemap so that they become a bit more richer without disrupting the original simplicity goal

Turning tubemaps into image maps is very easy, making tubemaps richer without disrupting simplicity will be my real new challenge… An example of an Image Tubemap is the following map I’ve made when thinking about the core of the Nespresso Business Model:

This image tubemap links to three different places which give you more info about the Nespresso Ecolaboration program, the Nespresso What Else advertisement and the Nespresso brand image. You can find the links by hovering your mouse over the picture. When your pointer changes into a hand and a pop-up text appears, you can click the area to visit the corresponding place. Which one do you want to visit?

I also will be continuing my Petri Net & CPN Tools prototyping journey but at a slower rate and I won’t share the progress as I did until now. But all this may change if the Next Top Model Language contest between Archimate and Petri Net becomes a reality

The Tool

CPN Tools is working really different than most modeling and mapping tools. this is mainly because its interface is a bit strange. Normally I never read manuals or documentation but in the case of CPN Tools it was mandatory to watch the videos on the Getting Started page and to read about Cloning and Hierarchies.

But after reading the documentation and working a few days with the tool I noticed how optimized this tool is for modeling and how much fun it is to work with it.  It feels if I’m sketching instead of modeling! The tool almost invites the modeler to create a lot of iterations of the model. This is very very helpful to gain a lot of insights very fast.

The Neuron idea

The neuron idea seems to be working out very well. But I still must see if the neuron idea will work well with the way how hierarchies are working in CPN Tools. Biggest advantage of the neuron modeling pattern is that it provides a bit more structure than the standard Petri Net elements do without limiting the creativity of the modeler.  I have to admit that through this “learning by doing” exercise  I had to change the description of the business neuron elements a few times to make its usage more understandable.

Working from the  Business Model Canvas

Before I started it was my idea to keep as close to the Nespresso Business Model Canvas example as possible. That changed and now I use the Business Model Canvas  more as an easy starting point to create my top-level pages in CPN Tools.  The canvas is very useful in the same way as a painter would use sketches before starting with the real painting but it isn’t wise to try to make an exact copy…

Things to remember

• I have to work with information collected from the internet. I don’t am a Nespresso customer myself and have never worked for them. So this prototype only reflects my picture of Nespresso from the outside…
• I just started this journey and it will probably take a lot of more steps to reach the destination which for me is to be able to use simulation to support Enterprise Architecture sense-making & decision-making.

I’m very happy how things are working out until now. And I’m looking forward to the next challenge: dealing with hierarchies

I think that the most important question of all is still missing, namely:

What do you rely on?

Let’s do a Next Top Model Language contest between Archimate and Petri Net!

UPDATE: BiZZDesign asked to wait for an answer until they start with the Archimate series. I look forward to that! My goal is to use the contest as a vehicle to show through a sort of real life example how you can do Enterprise Architecture: formal or more informal. I hope it will be a kind of “learning by seeing doing” experience for other digital architects…

I think that — sort of by accident (as is so often the case) — a big outcome of Peter’s enterprise backbone architecture post is the invention of a new hybrid — the “emergent blog post: learning and improving through community interaction and iterative and incremental development.”

The relationship platform has to change not in technical terms, in this case, but in terms of the social norms to allow this invention to work. The traditional expectation for blogs that emerged early was that a blog would remain stable as posted, so that commentary on the blog and across the blogosphere would have a stable post to react to. Any modifications had to be clearly marked, generally in an addendum, etc. An emergent post requires a change in expectation set and normative behavior — no dinging Peter for editing, changing, extending his post. So, unwittingly, Peter has demonstrated the interaction between the technical elements of the relationship platform and the cultural and social elements.   [I'm not suggesting that social networks == relationship platform but only that social networks are part of it.]

Um, historical note: As inventions go, naturally I have been doing my own version of this in my Trace for a long time — see “conversations” with Charlie Alfred early on. The comment feature on my blog was barelyused and the spam burden far, far, far outweighed the (potential but not in fact used) benefits, so I haven’t added a comment feature to my journal.

It is an interesting observation because I never have been a real blogger. I have this blog for a number of years and another one before this but I’ve always used the blogs as sketchbooks. Messy and deleting stuff when I thought it has become irrelevant. Guess there must be a few links on the internet which are pointing to pages that were deleted long ago…

But reading this observation by Ruth I realize that not I’m the only one who puts effort in my blog. You, my dear audience, also has to put a lot of effort in it because I don’t tell an easy to digest story.  I throw just a bunch of somewhat loose ideas in your direction which you must help transform into something comprehensible. I can only say that together we can make the pieces fall into their place and that solving the puzzle can lead us to new ways  of doing digital architecture. But I don’t guarantee anything…

Therefore I end with this quote from Alex Noble:

A journey is best measured in friends rather than miles

And for me this is a great journey already

Service-oriented architectures (SOA) and models oversimplify the world into:

or at best into:

Although I agree that SOA is at least a threesome, I think that the third party is much more than just a simple service registry:

And the backbone service can manifest itself through many different patterns, like:

You can only influence the shape of the company by playing with interaction costs if you are well-aware of the different backbone patterns and their interaction costs. Also be aware of the fact that backbone services are not only made out of technology…

I received the following comment from Stuart Boardman at the time that this info was part of the The Enterprise Backbone page:

So arguably the backbone is actually a collection of services, each delivering its own, totally independent part of the whole. And that independence (decoupling, loose coupling, whatever you prefer) is fundamental to how the whole thing works. Which by the way, Peter, is why I disgree with your contention that the SOA model is oversimplified. Not because the backbone isn’t relevant but because the model allows provider and consumer to negotiate which backbone they want to use at the time of use. There’s a difference between a specification model and a delivery model. SOAP/WSDL supports that explictly, although some will argue that that is exactly makes it so overweight.

My original reply to Stuarts’s point was:

I still think that my remark is valid. In my daily experience I’ve never seen providers and consumers negotiate which backbone they want to use at the time of use. On the contrary, the backbone which is being used is always mentioned in models and documentation.Because I still think that my remark is valid. In my daily experience I’ve never seen providers and consumers negotiate which backbone they want to use at the time of use. On the contrary, the backbone which is being used is always mentioned in models and documentation. I will say more about this on that promised separate page.

The environment which I refer to has two ESB‘s and multiple technologies for sending files from application to application. And besides these several other A2A communication protocols are supported. In such an environment it is not enough to just model and document the service provider, the service consumers and the connection between them. And the service registry is only useful for managed connections but not for unmanaged connections like e.g. MQ.

Important note: the backbone which I mention here is not the same as the Enterprise Backbone. It is best to consider the backbones here as pathways that are part of the Enterprise Backbone.

Progressive disclosure is about revealing information as needed, step by step, just enough and just in time. Instead of fighting the fog of war with more and more information progressive disclosure uses the fog of war to create a comprehensible model of the world you need to see (and nothing more) so that you can stay focussed and take the right decisions at the right moment to reach your goal.

A good example of a decision making support system that uses progressive disclosure is a car navigation system. Wouldn’t you like to have some kind of company navigation system that gives you the right directions at the right time when you are trying to reach your goal?

How would your favorite company navigation system look like?