Fail Fast and Fail Often

Fail fast and fail often is one of my main mantras which I use at least once a day if not more often both towards the people I coach as well as towards me. And I must confess, I failed again. But this time I was stupid enough to not see the signals. In my last post which is quite a while ago I announced that I start something new. And I failed badly for various reasons. It was once again a dialogue with Tom Graves via his blog which made it obvious to me. If you are interested read his interesting post about Starting Friction including all the comments. To be fair I actually already knew it without knowing, but the dialogue helped me to get it on the surface.

I really tried, but it blocked me. It blocked me in a way which made me stop blogging, which made me stop sharing public, which also made me comment less on other sides. The thinking process itself, how to structure, how to write made me fail. Fail badly. Now, during the dialogue with Tom I retweeted a tweet from Bert van Lemoen to Tom:

"@transarchitect: If you want to do something, you’ll find a way; if you don’t, you’ll find an excuse." Very much true @tetradian
— Kai Schlüter (@ChBrain) December 26, 2013

This was not at all meant negative, but perceived that way: 

@ChBrain hmm... feels just a leeeetle bit too much like a put-down - which definitely doesn't help right now, thank you... :-( :-(
— Tom Graves (@tetradian) 26. Dezember 2013

I am sorry for that Tom, but it did enlighten me. Obviously the books are not (yet?) ready for me to start with. There is a lot more urgent and interesting things to do. Therefore I decided to move on and hopefully also find the energy again to share every now and then. Because writing my posts in the past never took long, but all of the sudden I started to think about writing and by that lost all movement. I do not know where this leads me to, but I know for sure that the idea of writing a book is for the moment history. It does not seem to be my medium to transport the message. Furthermore, when I look at my own reading it is quite obvious. Books about Enterprise Architecture never inspired me, Stories do the trick for me, fiction about people, emotions and such topics no matter what media (e.g. books, movies). Good stories make me think different and then I adapt and abstract it towards Enterprise Architecture and create just another (sometimes working) tool.

So, message of the day: Back to my strength.

Simplified My Life - Prepared for Something New

Last week I had the pleasure to speak at the IRM-EAC conference in London about "How To Implement Enterprise Architecture Agile From Scratch". Implementing Enterprise Architecture that way is actually my physical answer to my thoughts on Social Enterprise Architecture. For those of you who follow me on twitter you might already have seen some tweets about my speech. I wasn't very active on my blog lately, because I was occupied in many other topics, but in general I have the plan to keep on putting my knowledge into the blog.

I also met Tom Graves at the conference and we spoke a while about various things. Despite my lack of understanding some specific english terms which are not my standard vocabulary the conversation went quite fine. A couple of times Tom explained me surely cool things where my face must have went blank, because he paused and tried with different words afterwards. I shared a practical story of my daily work with him, where I (mis)used his SCAN Framework in Architecture Shootout Sessions. Obviously he has no obligation.


These ideas happen, because in the daily work we are quite often faced with very difficult problems where we need to give quick answers. I do not know if SCAN is the best framework for doing complexity assessments or not, but I decided to select it, because of its brilliant name. It is sometimes as simple as that. Using such a brilliant acronym to do a Complexity SCAN really helps, because the name sinks in. Due to my thinking about GLUE, where I always try to find the optimal holistic flow I have extended into three dimensions:

1. EPIC SCAN to understand why we are where we are. So very literally the EPIC of the current complexity.
2. WISE SCAN to understand where we want to go. So very literally if it is WISE to go where we think we should go.
3. PACE SCAN to understand at what speed we can change. So again very literally the PACE of the change.

Besides that very intense and interesting (and hopefully relevant) discussion Tom also triggered me (again) to write a book. Wow, tough one. But I thought about it for a while, and I kept on thinking about it. And that triggered something else with me.  All of a sudden I had the urge to reinstall my Notebook, even though it was perfectly working. Actually that is a habbit of mine when I start something new. A new thinking process, a new approach. I leave old boundaries and thoughts behind me. Technically I copy all files into a network backup folder, then I reinstall the operating system and only install software when needed. The backup folder I do not touch or move back but only look into it when I really search for something. After one year of not touching that folder I delete it completley without even trying to look into it. I picked that way of thinking up from "Simplify Your Life".

So now I am ready, but for what. I actually have started two books on LeanPub (Thank you Tom for the recommendation). One book about "GLUE" and another book about "Implementing Social Enterprise Architecture in 100 days". I am not sure about the titles or what I must do in LeanPub and what I should not do. I then learned that I now have to invest a bit of time into Dropbox, because that is the way to work with LeanPub. Actually a tool I had no use for so far. Fair enough, new ideas, new ways of working. Lets give it a try.


Lets see if the flow is coming. (I also decided to not reuse any of the content of my blog directly. I will most likely also redraw my images, because it helps me to re-order my thinking. I do not know where this leads and what the outcome will be, but I am very exicited to try it. It could be that I do not finish one of them, it could be that GLUE is only for me to straighten my thinking, it could be that both work out. I do not know, but I'll try my very best.

SCRUM at the center of Enterprise Architecture

A couple of days ago a tweet from John Gøtze cought my attention

EA can be agile and scrummilicious, says @soerenstaun in guest lecture at the IT University of Copenhagen.
— John Gøtze (@gotze) 29. April 2013

And my reaction to it was it should:

"@gotze: EA can be agile and scrummilicious, says @soerenstaun in guest lecture at the IT University of Copenhagen." I say it should!
— Kai Schlüter (@ChBrain) 29. April 2013



(c) Tom Graves

To explore this a bit further now finally this blog post. When I am tasked to implement Enterprise Architecture first time or to improve an existing capability then I put an agile approach in the core, preferable SCRUM. There is various reasons for this. To explain the concept I borrow the SCAN framework from Tom Graves, here in particular the post Sensemaking - modes and disciplines.


In my implementations of Enterprise Architecture activities I focus on the problem space Ambiguous and Not-Known. Ambiguous problems can be quite well solved with SCRUM, where "the whole is greater than the sum of it parts", Aristotle. Agile approaches which do not put the team into the centre of their methodology do not seem to work as well in this problemspace. The identification to which quadrant a problem and the corresponding solution belongs is in my mind always an ambiguous problem, due to the scope of Enterprise Architecture, trying to cover the whole [which is more than the sum of its parts].

Problems which belong to Simple or Complicated I usually hand over as fast as possible to better suited teams or individuals, while the ambiguous problems I keep inside of Enterprise Architecture. The Not-Known space is total different and typically I focus on finding the Innovation which emerges here instead of trying to force it. I believe that Innovation can be easier found peripheral and not really by looking for it centrally.

By implementing SCRUM in the center some key elements needs to be in place to succeed. One of the most crucial elements is the Chief Architect, be it the official announced Chief Architect, or a manager (e.g. CIO) who is filling that role. The Chief Architect is the one who gets the SCRUM role Product Owner assigned. And here typically some effort and attention is needed to secure that the Chief Architect is focussing on delivering into his role as Product Owner instead of doing the actual work. The work should be done by the SCRUM team (or Pigs).

The most important element here is to create an environment in which the team utilizes the strenghts of each other. And here also lies one of the biggest challenges, because most Enterprise Architects have been grown from technical roles and have been survived quite some selection criterias till they have become an Enterprise Architect. Statistically I observe a high amount of heroes or divas, who are quite biased that an Enterprise Architect and especially they themselves are the crown of the evolution. Concepts like the Peter Principle support that thinking even more. :)

The only role which is fairly easy to fill is the SCRUM Master. Just take any good SCRUM Master who is NOT knowing much about Enterprise Architecture (preferred) or willingly not going into the content (sometimes hard, if the SCRUM Master is self biased believing to know better about Enterprise Architecture). So literally someone who only focusses on securing that the process runs.

This is of course not always easy to implement, but it is my main target to achieve. And I continue developing a team towards that target, till it is achieved. And when achieved the speed can be even increased, because then the environmental problems are solved and the focus can be on the delivery of good Enterprise Architecture Services, which is a post I also plan.  SCRUM helps me to deliver to my main objective. Enterprise Architecture and especially my approach GLUE is about People first:



Comments as always more than welcome.

What really matters

I planned for quite a while to write a post (or series of posts to be accurate) but there was always something distracting me. Well, that happens, so no worries. Yesterday and the day before I have been on the Gartner EA Summit which was truly great and enlightening in many different ways, despite my incapability to plan a bit ahead. When I left the hotel today 5:00 in the morning to catch the first flight home I truly planned to write about it, more than one post actually. But then something was brought to my intention, something what really matters. (I might though come back to the Gartner EA Summit and what I learned later).

The flight went fine and I got picked up as planned by the taxi. Perfect service by the way including Internet access and bottled water to drink. As always the travel went smooth and perfect, so I could work my way through a stockpile of email to put some things into context, sort one or the other topic. Basically normal travel type of work. But then, something was brought to my intention. Heavy impact actually.

1. All of a sudden the driver had to go into the breaks, not really, but strong enough for me to recognize, so I looked up to see whats up and of course the classical motorway road works traffic jam.
2. I heard some breaks, but nothing really worrying and then suddenly the driver was taking his hands away from the steering wheel and in that very same moment a large truck was blowing his horn and then the noise of metal, plastics and humans screaming.
3. Something bumped also in the car I was sitting in (normally I was sitting always on the front seat, but this time I was sitting in the back to work) and a giant truck was sledging diagonal from the back into my sight field and into the farming field next to the roadway.
4. [total silence]
5. The driver of the truck left his truck within 10 seconds as far as I was able to recognize unharmed and the driver of the taxi I was sitting in just drove 20 meter forward to secure a way for potential emergency cars.
6. Then we left the car, and it was a field of demolition. Apparently a second truck was standing on the emergency lane obviously heavily hit by something in the rear. A small bus for 8 persons was wrecked and standing on his wheels but into the wrong direction (later my driver told me that he has seen that bus doing a rollover), 2 cars have been hit heavily (airbags executed) and bumped into the cars in front of them, one of them obviously hitting us.

Our car and another car almost unharmed, just small scratches in the rear, but have a look at the red truck who litereally was flying in as my driver told me on the rest of the travel more than once.

1. Almost at the very moment 4 people from Johanniter Unfallhilfe came running. I was truly impressed, but in reality it was just luck that they have been driving a couple of cars behind us. So the professionals could take over and did that really great. It was very fast clear that noone was harmed heavily. Everyone involved could walk, talk and was cleary able to response reasonable (despite some really shaking knees and white faces).
2. Shortly afterwards police officers came to secure the area and a helicopter flew in. Impressive speed by the way, I haven't clocked it, but it for sure was well below 10 minutes till the helicopter with the doctor was there.
3. The volunteer fireworkers from that area also arrived with quite some vessels and people.
4. What was obvious in that realm of chaos was high professionalism, but also quite some communication and handovers. From Johanniter to police to doctors to fireworkers. The cars were triple checked (Johanniter, Policemen, Fireworkers) All of the involved professionals spoke to the people involved in the accident, quite some confusion about many things for example insurance (how irrelevant at THAT moment, yet important for some. As far as I recognized it, that insurance concept was at least one thing people understood in that moment).
5. They collected all of us and explained the steps and there was a fairly good atmosphere, because everyone was well aware that things could have been way worse. Personal data was recorded by the police people, the doctors did a short examination and send those from the more heavily impacted cars into hospital, the fireworkers cleaned the street to allow the emergency cars to drive through, lots of pictures were made.
6. Not that I want to make that experience again or wish that anyone, but it was brilliant to see them in action, coming from knowing nothing to full control of the situation in less then 15 minutes.

 

Given all what I learned at the Gartner EA Summit (and other events), why can that story not be told different?

 

1. Preventive
1. A Traffic Jam is signalled back to the following cars (and to traffic control) and warns the drivers (like red alarm in Star Trek if you want) or even better forces the car to slow down, no matter what the driver believes.
2. A car in trouble signals to the other cars (and traffic control) that it is in trouble.
3. Cars are forced to have a relevant safety distance.
4. Cars are forced to not overspeed (yes, there will be people who believe this should not be done, but in that case it would have helped a lot and under worse circumstances it would have saved life).
2. Impact
1. On an impact the car or environment is signalling to other cars as well as to traffic control.
2. Traffic control sends a drone to examine the area and create a 3D model.
3. That 3D model gets send to all potentially involved parties which can use it to plan the operation while already driving to location.
4. Each unit supported by augmented reality updates new information real time into that model, so that everyone involved has the full picture and can therefore act acordingly, e.g. more people, specialized vessels, specialized skills, but also retreat if the impact was less harmful than thought. There could be way more parties involved than in this particular case.
3. Afterwards
1. All the information can be directly fed into the system including the 3D model for reports, insurance, news, whatsoever.

So thank you consumer market for bringing us all these great new potential, but it is only interesting. Relevant is something else, nevertheless, please explore more, because it might be useful somewhere else. Truly relevant. Over to you.

 

P.S.: This was just a quick writing, the accident is less than 8 hours ago and I was doing quite some other things in between, but I believe there could be many stories created out of this and potentially there are already units in the world building this system so that it is usable, easy to use and as cheap as possible. I can only hope for that.

Power, Process, Project, People - The Effect

Finally I find the time to write another post and continue my series about Power, Project, Process and People. As a small summary here a oneliner about each of the three forces:

• Power is about control and authority which limits people.
• Process is about faster, higher and stronger which spins people faster. 
• Project is about moving which changes people.

All three forces together can have a quite severe impact on on people. Literally they force people to change faster and faster while limiting them.

 



So what is the chances to escape? Actually there is three typical ways to escape for each individual person:

• Increase the power by climbing the hierarchy.
• Forcing others to spin faster, higher and stronger by becoming process owner.
• Forcing others to change by executing projects.

The easiest way to escape lies in executing projects, be it as internal or as external. Being good at project execution protects people against being forced to change themselves, because the methodology on how the project was executed can be used again and again and again without adapting much. Furthermore if implementing a specific solution that very same solution with small adaptions can also be implemented many times in a row allowing to not change while those who are affected by the project must change.

Being really strong in one methodology sometimes opens up for the chance to become process owner, which is great, because it allows to let other people spin faster (and higher and stronger), while the own speed more or less remains the same (except if the process owner of process management really makes process managers spin faster).

Rising in the hierarchy is the option in which typically the people are interested most. First of all it is the option which has the highest chance to increase income significant. And it is (and makes) attractive, because it gives direct power over others.

The interesting (and potentially relevant) observation I make in most cases is that one who is advancing either in Project, Process or Power terms is normally picking up the behaviour of who was leading him in respect to that particular force. It takes some time to free up and leave the old approaches behind and actually many who are in the position to control one of the forces never advance.

Power, Process, Project, People - Force Three

I will now continue with my series about Power, Process, Project and People. After touching Power and Process. The next thing I will now explore is Project and to once again repeat the definition of the Oxford Dictionaries: An individual or collaborative enterprise that is carefully planned to achieve a particular aim. There is plenty of material available in various forms defining and framing project management and project as such, but for the moment I stick to this very simple definition.

To change and move one organization from one state into another projects are the most common approach to achieve that transition. In most cases they have a more or less well defined goal which the project aims for. Each and every project is constrained by various aspects (the most famous representation of these constraints is the iron project triangle, which I might return to). Besides the positive effect of moving the organization any given project also carries some negative side effects, because the organizational change the projects cause are changing the basis for the people who are used to work in that context. Professional Change Management approaches try to cover up for that, but it is not always the most easy thing to be successful with.

So how do I utilize GLUE with respect to this? First of all I use the GLUE Divisions:

 

1. Destinations looks at To-Be
2. Discovery looks at the Transition between As-Is and To-Be
3. Defence looks at As-Is

Then I use an adaption of Tom Graves SCAN Framework:

1. EPIC SCAN for Defence
2. WISE SCAN for Destination
3. PACE SCAN for Discovery

And then I analyze the flow of information through the GLUE SPACE with a special focus on the information flow between the GLUE Divisions by adding the GLUE Disciplines and GLUE Decks.

Actually all information which is floating through the GLUE circulatory system belongs to at least one project with the aim to somehow transform the organization. Being a part of the project in one way or the other, somehow related to and working myself deeply inside some of them does to the trick. Getting engaged and walking the talking helps to secure that a given project is moving from As-Is to To-Be in the right speed. The closer I stay to the project the more easy I achieve the goal, but of course there is also ways in securing that others can fulfil the very same role. This is also achieved by transforming them via the GLUE Divisions from one architectural (mental) state to the other. And again the easiest and most successful way for me always was to walk the talk and lead by example and not by documents and orders.

Power, Process, Project, People - Force Two

Recently I have started a series about Power, Process, Project and People. After I have touched Power, I now like to reflect a bit on Process and what I am doing with processes in my daily Enterprise Architecture work. Just to repeat the definition from the Oxford Dictionaries: A systematic series of mechanized or chemical operations that are performed in order to produce something. There of course exist way more definitions to frame what a process is, but I stick to this fairly simple definition.

 

Processes are found a lot in organizations when there are attempts to reuse a successful approach. In most cases they are somehow standardized and formalized by some form of documentation, be it very document centric or a more modern approach by using a business process management suite. Typically the structure of the information is Input > Process > Output with Roles and Responsibilities on the Process and references to other processes. It typically forces People to spin faster and faster and faster (work harder, not smarter) over time, because the Process Performance Indicators are supposed to increase year after year. Every now and then there usually is a massive process restructuring which allows to work smarter (or more accurate aligns Process to more or less strictly follow Power. Quite often process changes (no matter if it work harder or work smarter) lead to massive problems, especially if the people are forgotten in the process change.

So what am I doing with support of GLUE? First of all I am using the GLUE Disciplines to formulate a basic Process.

 

In the combination with the GLUE Decks and the GLUE Divisions the Disciplines form the GLUE Space. In that GLUE Space the flow of the Disciplines leads to the circulatory system.

When I now look at any given change initiative I analyze how it fits into the GLUE circulatory system and my main focus is to secure that the information circles as fast as possible through the whole system to secure that information is available to everyone involved and can be interpreted and transformed  therefore by everyone. The more it is a circulatory system the better, the more it is a one way road the worse. The product of this circulatory system is by that defined by all involved stakeholders and not just pushed (by power) down to the system or emerged pure to no other choice.

The main reason why I work like this is lies in the nature of the problems I work with. For really simple problems there might be one perfect answer, but in most cases the complexity prevents this: neither the problem at hand is truly simple nor the solution selected can be perfectly simple. A very simple approach would be to package one solution and implement it (or sell it) unchanged as often as possible. By not looking at the greater context this is indeed an approach which makes sense (and most likely generates quite some money). The damage created by this approach is quite often very high, even though due to the friction it also generates quite some innovative ideas (by accident). As always it is a matter of perspective. I do not know where this will lead me to in the future, but at the moment I mainly focus on people. For whatever reason it is the approach with the greatest rate of success so far, even though I constantly try other approaches, nothing has ever been close to beat my current approach. Collaboration with (many) others is by far the best tool for me.

As always comments more than welcome.

No Power for Enterprise Architects

Some time ago I have written about The Enterprise Architecture Matrix, where I used a small sequence from the movie Matrix to explain my line of thinking for Enterprise Architecture. This time I use the scene from Lord Of The Ring where Frodo is looking into Galadriels mirror to see the future.But see yourself:



Frodo is the Solution Architect, who is trying to solve a problem at hand and Galadriel is the Enterprise Architect(EA) who provides the Solution Architect (SA) with tools (the mirror) and advice.
 
The Enterprise sleeps, and when the Enterprise Architect explains, only the Solution Architect listens.

EA : "Will you look into the mirror?"
SA : "What will I see?"
EA : "Not even the wisest can say, for the mirror shows many things. Things that are, things that were, and some things that have not yet come to pass."

SA looks into the mirror, and sees Legolas, Merry and Pippin, then Sam. The Shire as it was, then the Shire ravaged, overrun with orcs, and Sam in chains.



Then the Eye appears, and the Task grows heavier, trying to pull itself down into the mirror. SA snatches it away, falls backward onto the ground.

EA : "I know what it is you have seen, for it is also in my mind. It is what will come to pass if you should fail. The Fellowship is breaking. Already it has begun. He will try to take the ring. You know of whom I speak. One by one, it will destroy them all."

SA : 'If you ask it of me, I will give you the One Task.'



EA : "You offer it to me freely. I do not deny that my heart has greatly desired this."
A dark light comes over her as she touches the power of the Task.
EA : "Instead of a Dark Lord, you would have a queen, not dark but beautiful and terrible as the dawn! Tempestuous as the sea, and stronger than the foundations of the earth! All shall love me and despair!"




EA backs away from the Task, ut for a moment, she looks old, and it seems to bring her no joy to have done the right thing.
EA : "I passed the test. I will diminish, and go into the west, and remain Galadriel."




SA : "I cannot do this alone."




EA : "You are a Ringbearer, Frodo. To bear a architecture task is to be alone. This task was appointed to you, and if you do not find a way, no one will."




Frodo : "Then, I know what I must do. It's just I am afraid to do it."
Galadriel : "Even the smallest person can change the course of the future."

I try to allow all ideas to influence my thinking about Enterprise Architecture. Sometimes it works perfect, sometimes not at all, but I truly hope that I try. I personally believe that an Enterprise Architect should stay away from the power and if he decides to take the power stay away from Enterprise Architecture. There is a high risk that an Enterprise Architect with power abuses that to build just another empire no-one needs. Instead of building this empire focus on repair GLUE Diseases and fix the flows in the GLUE Circulatory System.

 

Feedback as always more than welcome.

Power, Process, Project, People - Force One

In my last post I have started a series about Power, Process, Project and People. In this post I like to reflect a bit on power and what I am doing with respect to power in my daily Enterprise Architecture life. Just to repeat the definition from the Oxford Dictionaries: Power is the ability or official capacity to exercise control; authority. There is of course a lot of other definitions or deeper explanations of this concept. As a starter I recommend to read the Manifesto reference-sheet from power and response-ability from Tom Graves. For simplicity reasons I here stick to the very simple above mentioned Oxford Dictionaries definition.

Power is most obviously found in organizations by just looking at the organizational chart. In most cases it is formed like a pyramid with one on the top and some below, which have each some below them again. This can potentially be a very high structure (e.g. CEO > CxO Board > Divisions > Departments > Groups > Employees), even though there is some companies who run a flat hierarchy. In most cases these structures are self defending (GLUE Division Defence). It is very uncommon to see an Employee who has a higher salary than his manager. Also concepts like a technical career path typically only worsen the situation, because now the employees themselves are organized in a pyramid. And it can all be summed up by the concept of Julius Caesar: Divide and Conquer, which I have used to introduce the concept of the GLUE Domains. What I observe most it that it is limiting and framing people into something way smaller than they could be.

The typical advice I hear and read in various Enterprise Architecture Frameworks (e.g. TOGAF 9) is to place Enterprise Architecture in the governance structure close to the CxO level, preferable reporting direct to the CIO (Enterprise IT Architecture) or to the CEO (Enterprise Architecture). There is also the idea to put it below the CMO (?Enterprise Marketing Architecture?). Even though I have seen a lot of value created at that level I also see a fair amount of disconnect to the employee level and Ivory tower behaviour. The balance between strategy, tactics and operational work is not always easy to keep. And if an Enterprise Architect works only in his power structure then the result will be biased towards exactly that structure, heavily influenced and by that imbalanced due to only staying inside the frames given by it.

So what am I doing different? I am actually using the GLUE Domains in the GLUE Space to identify and map the power structures. The amount of GLUE Decks very  much depends on the context. For the blog I use four to explain the concept, but it can easily go way higher (or lower).

Typically these Domains are in conflict with each other with respect to Roles and Responsibilities. For example the responsibility of an Application Owner in the processes of Application Lifecycle Management who owns every aspect of his Application:

And Test Execution, which is typically owned by Test Management. Here two Empires are potentially in conflict.

The (theoretically) simple answer for Enterprise Architecture is now to work close to the decision makers (in this case most likely the CIO) and guide the CIO to take the right decisions. The basic (and I think wrong) assumption behind that is, that the CIO decides and forces it in. Following the basic idea of the power then this is indeed the case and especially and heavy command & control liking environments there is a high likelihood that  this will indeed be forced in, because the managers on those structures want to know everything what their people know. I personally believe that this is in most cases causing more damage than it is repairing, therefore I do work different. (Seth Godin touches this problem in his post destabilizing the bullying power structure.

I do not need only a strong connection to the decision makers, but I do need to be connected also to the lower levels of the organization. Therefore no framework and no formal governance is enabling me to be an enterprise architect, but knowing that I am one helps a lot! So instead of relying on pure power structures I go to the people who have the conflict and challenges at hand, and then I am doing Enterprise Architecture work by helping them to connect to the holistic Enterprise (repairing GLUE Diseases), no matter how deep or high they are on the ladder of power. That of course requires that I have to earn trust first, which is most easily achieved by walking the talking, especially when the advice is beyond the scope of the power structure.

Feedback as always more than welcome.

Power, Process, Project, People

I keep writing about People, because I strongly believe that in the end the only thing which really matters is people, like in the Agile Manifesto: Individuals and Interactions over Processes and Tools.

In the past days I have seen plenty of interesting posts putting various concepts in the focus. One caught my attention and is very much worth to read:

RT @davidsprott: The shape of the next generation EA framework. t.co/dolaKQtb #CIO #ecosystem #services #entarch
— Tom Graves (@tetradian) 18. Februar 2013

This post followed some back and forth twittering and it was a very enjoyable discussion. It triggered some thinking I wanted to reflect already for a while, because every now and then I see an interesting tendency to market something as the one and only way on how to look at the world or solutions, be it IT or non IT.

Coming back to people I want to reflect on three forces especially which I observe every day and what I do to work with them or what I see in the typical Enterprise Architecture approaches. The three forces are (for each one definition from Oxford Dictionaries):

• Power - The ability or official capacity to exercise control; authority.
• Project - An individual or collaborative enterprise that is carefully planned to achieve a particular aim.
• Process - A systematic series of mechanized or chemical operations that are performed in order to produce something. 

The definition of process and project is sometimes confusing if compared, so for simplification I typically differentiate by using project in the context of unique deliveries and process if the deliveries are repeatable. These three forces have a different effect on people, and each and every person has a different opinion what type of force he prefers, but in typical organizations all three forces exist in co-existence and influence each other. The key to all these three powers in the end is the People though and interesting enough they get quite often forgotten.

This is only the first post in a series, otherwise it is getting too long. The next post will be about power. If you have any input to give straight away then I am happy to read or hear from you.

Enterprise Life Forms

In my last post "Details vs Context" I have touched the challenge to find the right balance between getting lost in the details and getting lost in the context. The frequent readers of my blog should by now know that my personal take on Enterprise Architecture is very much focusing on people without blending out the building blocks of the flow:

An interesting and relevant observation of mine is now that each and every company has its very own soul, the true essence of that company. Of course on the surface they all (at least the big ones) seem to have the same functions, same processes, same good practices applied, but if you just manage to see one level deeper it all of a sudden is total different between the companies and has its very own beauty. The soul of a company has some aspects which seem to be generic patterns:

• It is deeply rooted in the old guard people (GLUE Defence).
• New people sooner or later tend to adopt to it.
• It is embedded in the structural, process, project and especially in the informal organization.
• It can not be easily changed.
• It has self healing effects which protect the system against damages inflicted by external sources or careless management / leadership attempts and forces the whole environment back into the pre-change attempt.

One of the first things when I work in or with a company for  me is to try to identify the soul of it. Because it seems to be unique and very special. I have not seen two different companies with an identical soul and that is actually something which I personally find very interesting and relevant to create fit-to-purpose architectures, not to mention that the soul of the company has its very own unique beauty which is as far as I see it worth to be protected.

Details vs Context

In my last post I was writing about walking the talking, which is based on my experience one of the key elements for success. Some time ago I have written about the need to remember the larger context which is also reflected in my WISE SCAN post (E stands for Environment). So it is essential to connect a solution in the context to secure sustainable success and not rely on random luck. The saying: "To not see the wood for the trees" is also based on that line of thinking.

The interesting challenge now is to not get lost in the greater context and by that forgetting to chop the trees. I have seen many Enterprise Architects loosing contact to reality and connecting literally everything to a problem or solution at hand but totally forgot to deliver the solution. The intellectual discussion with them was actually truly great and I learned a lot (this happened many many times), but pity enough it wasn't very relevant.
I believe it carries the very same danger to not deliver than getting lost in the details, but does contain an additional problem. Those who get lost in the context loose credit due to not delivering, while those who get lost in the details are typically valued for their great knowledge, but questioned about their communication skills.

So my advice (and I try to live up to that every day) is: deliver while connecting, connect while delivering. Don't think something fully through, but connect it good enough. Fail often and fail fast. And secure that the whole environment is setup to support that. If not, then fix the information flow, fix the GLUE Circulatory Flow, so that information flows free, is easy accessible, enriched fast and supports collision of ideas.

And in most cases the answer lies in the people who are operating in the GLUE Circulatory System. They are the elements which needs to be worked on to secure information flow. Technology can be a catalyzer or facilitator but is typically not the key element to secure optimal information flow. Balancing details and context is an ongoing challenging task which mainly operates on people and their ability to connect details with context. Various Enterprise Architecture tools help here a lot, but what is most successful is finding the right words for the right people to connect the details and the context via an emotional holistic story touching all senses. Tough one, but there is moments of perfect flow in life. And those moments are the reason why I deeply love my job.

Walk the Talk

My last posts have been very much focused and following a red line, so now I am trying to pick up some loose ends. There is one thing which bugs me quite often when I am doing Enterprise Architecture work. There is way to much focus on talking about Enterprise Architecture. Something which is also reflected by following twitter post:

I suspect that the primary job role of Enterprise Architects is to argue with other EAs about what #entarch is. Prove me wrong, people.
— Kevin Brennan (@bakevin) 7. Februar 2013

My personal observation is that Architects actually discuss about Enterprise Architecture, but do in most cases not argue. This is a differentiation I find very important, because an argumentation chain would at least provide a red line why one approach is chosen over the other. By looking at the pure amount of frameworks and tools in the market and the amount of new players entering that space it is quite obvious that Enterprise Architecture is at the moment in a hype or fever situation. This can easily lead to total irrational decisions. On this topic I recommend to take a closer look at the Tulip Mania, some of the behaviours might also be seen in more recent crises.

Here (as mentioned before) I use GLUE as mapping tool for me. The real most interesting (and relevant) question for me always is: Where is a person stuck in the GLUE circulatory system.

And then I try to go into that position, placing myself onto the seat of that particular person to understand where the missing links are. If I manage to understand a portion of it I try to show the traces by using whatever terminology is approbiate for that particular person. Not GLUE, not a specific framework, but whatever language element helps. Sometimes indirect communication by others is the only way to succeed, sometimes I need to play over time. Invest today, harvest in a couple of month when a small trigger has grown into something powerful.

In most cases showing the connections to other information streams (in the circulatory system) allows the person at hand to see some possible answers to concrete problems which have not been solveable before. And there is one thing I know, then it is that I do not know anything, but what I know is that I am an Enterprise Architect. So in most cases I have literally no chance to give a correct concrete answer even though I am fairly often asked to give one, but I am able to help the information flow, to unblock the thinking, to link elements. There is my focus and that enables others to bring their great knowledge to the game and solve problems I would not have dreamt of being solved.

drEAmtime - summary

This is my final post in a long series of posts where I used the great post from Ivo Velitchkov as a red line to explain my thinking. Following posts did I create so far:

1. drEAmtime - Communication
2. drEAmtime - Bridging the Silo
3. drEAmtime - Capability Cemetery
4. drEAmtime - EPIC SCAN
5. drEAmtime - Archetypes
6. drEAmtime - WISE SCAN
7. drEAmtime - PACE SCAN 
8. drEAmtime - Frameworks
9. drEAmtime - modelling

So it is time to summarize the whole series and once again I like to use a quote from Ivo: 

In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying reduce the IT spending, it in fact makes no change or increases them. When trying to deal with complexity,  it’s just pathetic

I completely share Ivos line of thinking here. The first observation ("When contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it") is actually the main reason that started my work on GLUE. I was facing a situation where multiple software supplier and various integrators including a fairly diversified internal IT process structure had to deliver towards 4 releases every year without sharing any common knowledge and understanding, but all of them tried to teach introduce their approaches. So, I have to confess, in my first line of thinking, GLUE was just another stupid approach to create a common language to try to bring them all on the same page.

After working some weeks on the concepts I proudly presented it and was astonished that my brightness (GLUE) was not obvious to everyone. What I faced (and most of the feedback I collected over several years afterwards) was (of course) full misunderstanding. Everyone was all in for the idea of aligning to language to a single common one, as long as it is the one already used to protect the own way of thinking (tribe). So I totally failed and out of frustration I parked GLUE for a couple of years. Looking back the main problem was that I was so full of being right that I did not listen to those I wanted to follow my line of thinking.

Since then I have my changed my focus and live more up to the concept of being a ChickenBrain. I changed the focus from GLUE being the ultimate truth which everyone has to obey towards a pure mapping tool to identify GLUE diseases. Whatever approach or framework in an engineering context I face I immediately map it into GLUE to double check my understanding of the framework at hand (and to ask sense making questions if needed).

Ivos second observation ("When trying to bridge the silos, it creates new silos instead.") is also something I observed more than once, most inside corporations where the Head of Enterprise Architecture tried to create or defend his very own Empire. That empire (or tribe) thinking is of course typically creating or defending an Enterprise Architecture silo. It can easily go worse if the Architecture Domains are split into several teams which have to argue their existence and easily spend more time on defending their existence than in providing real value. And it typically it does not matter how they are split, as long as they are split roles and responsibilities will be defined and some sort of open or hidden fighting is typically the result.

Ivos third observation ("When trying reduce the IT spending, it in fact makes no change or increases them.") and fourth observation ("When trying to deal with complexity,  it’s just pathetic.") are connected and has typically many root causes. For example information flow problems or how I name them a GLUE disease, lack of analyzing the To-Be Architecture where the WISE SCAN of the GLUE Division Destination helps and quite often just bad implementations, where the PACE SCAN of the GLUE Division Discovery helps. The various root causes of unneeded complexity can be analyzed with the help of the EPIC SCAN.

I like to thank Ivo for his great inspirational post and I am happy that I finished to follow that red line. Comments and feedback is as always more than welcome (and new inspirational posts as well).

 

drEAmtime - modelling

Finally I can see the end of the red line created by the great post from Ivo Velitchkov. So far I have created following posts:

1. drEAmtime - Communication
2. drEAmtime - Bridging the Silo
3. drEAmtime - Capability Cemetery
4. drEAmtime - EPIC SCAN
5. drEAmtime - Archetypes
6. drEAmtime - WISE SCAN
7. drEAmtime - PACE SCAN 
8. drEAmtime - Frameworks

Two more posts to go, this one and another final one. To quote Ivo: 

Then of course modelling itself is believed to help in dealing with complexity. But what kind of modelling? A very complicated architecture diagram does not show complexity. It just shows a lot of effort spent in denial of it.
 

Actually I personally believe that modelling is a great tool and support communication quite a lot, if applied correctly. I also have a couple of models here in my blog which help me to explain and visualize what I think. Looking at them isolated they are most likely confusing and difficult to understand, which makes it sometimes indeed difficult to use them alone. But in the support of the whole storyline, be it as part of a blog post or as part of a presentation the model helps to align the thinking. The one I refer to most here in the blog is actually the circulatory GLUE system:

 

Just a cube with lots of confusing lines. Only by working through my GLUE thinking and GLUE posts it hopefully gets meaningful. Which reminds me that I need to label my posts a bit more organized, otherwise it gets difficult to find information. Or I need to put all of it together, reorganize it and write it again in a more structured way, more like a book? Maybe a project worth to go, maybe not. If you have feedback here you are more than welcome.

 



Coming back to Ivos post there is jokes circulating around me: "When have you last time had a meeting with Kai without him using the whiteboard?" or "We are trained to sit so that we have free view towards the whiteboard." Scott Ambler has heavily influenced my thinking with his great website about Agile Modeling besides a lot of great colleagues I had over the years who showed skilled approaches in supporting their line of argumentation with the right model at the right moment. I also liked his Whiteboard Warrior concept, but he has put it offline from his website. There is some traces left in the web though.

One of my key approaches is to draw while I speak. Many words (and I say and write a lot) are more often confusing than enlighting, while a single diagram just shows it. Finding those is not always easy, but the more I model the easier it is to create the right drawing at the moment when it is needed. So my advise is: draw to support your line of thinking, explain in pictures, add a story and the whole gets  its own life. Which most likely will return back to you one day, grown over time, transformed and morphed, but beautiful. I try to show Enterprise Architecture and the elements which are delivered via Enterprise Architecture in their full beauty, sometimes I fail, sometimes I succeed.


And a model which is beautiful will carry the story way longer and way more emotional than any dry facts. If Dennis Dutton is right with his assumption than it is rooted in human beeings. I found the success in this approach by try and error. Feedback and comments as always more than welcome.