Exploring a new world - Raspberry PI

It has been quite a while since I last posted here and I am very sorry for that. There is so much I want to do and share with the Enterprise Archtecture community which just piles up on a long (very long, indeed) list of things. Among quite some posts there is three books I planned to write (not knowing if I ever manage to finish one of them, nor knowing if anyone is interested in reading them).

Nevertheless, as a christmas gift to myself I bought my very first Raspberry PI which is a quite cool device. There is so much written already on the internet, that I am not sure if I can contribute anything further to the community, but its quite obvious a device with some potential to disrupt and I will use it to teach my kids Linux (Rasbian) and programming.

In just no time (granted, I do have some Linux administration background) I was able to setup a local RAID 1 NAS where te whole family can share files of any kind (at the moment up to the limit of 1.5TB). Thanks to dynamic DNS approaches I can also access the files from remote locations (assuming I am interested in that).

My first Raspberry PI steps are already providing:

1. Raid 1 (Raspberry PI as raid server
2. Private Family Cloud (ownCloud)

Next steps could include (if I want to):

1. Remote Family Cloud (Two DNS)
2. User & File Management (Samba)
3. Mail Server (Postfix, Devocot, Squirrelmail, Spamassassin and Sieve)

There is quite some other ideas out there in which I am interested. Lets see if I find the time to realize them and the time to blog about them.

Intended (Good Architecture) vs Actual (Real Architecture)

I just stumbled by accident accross a nice video: RSA Animate - The Internet in Society: Empowering or Censoring Citizens?

And there is one key take-away for me in that video: Never confuse the intended use of technology (good architecture) with the actual use (real architecture). To use that stress field for designing an even better solution (good architecture) which is then also used (real architecture) it is worth spending time on the conflicts between good and real architecture. A classical Fit/Gap Analysis might help from a mechanical point of view here, but in general that area of conflict is of special interest, because as high energy areas it might be the place where new innovation is born (despite all the waste which is most likely also generated). So look beyond the obvious and use the daily applied stupidity to find brilliant innovation ideas.

Good luck.

Evolution of IT - Stage 1 - The Developer

I failed to write the book (actually two) which I planned to do as mentioned in an old blog post. It almost killed my blogging, because I put my writing energy into the book, but never really managed to get something to paper (or leanpub to be more precise). In fact it pretty much felt like Gerhard Polts "Der Gedanke". If you are interested a link to a audio file on youtube (in german).
 

 

 

So instead of continue to failing with the book I plan to write more blog posts again and I will use some of the thoughts I had for the book in a series of posts. I will try to share my mental model (inspired by Tom Graves and his great and interesting post "How do you think?"). My conclusion is total different than his, but that is something I reserve for another post. You might have read about my thoughts behind GLUE, and this is what I will try to re-explain in a total different way. My working title for the moment is Evolution of IT and I will start with Stage 1 - The Developer.

 

Unce upon a time a person was facing a a truly challenging problem. This person had an idea how to overcome the problem, an idea which was most likely based on collision of other ideas, as Steven Johnson puts it so great in his book Where Good Ideas Come From. To solve the challenge this person developed a solution and was therefore the first Developer of a new tribe.

As I have put in an old post of mine, this is the only value adding activity of IT (the new tribe) and therefore it is brilliant that the developer is all alone and can therefore contribute with 100% of his time to value adding activities. The other good news is that there is plenty of new tribes founded all over the place. Many of them are rooted in so called shadow IT or based on hairball architecture. As I have put in an older post of mine hail the hairball architecture, because there innovation is born. (There is of course also quite some negative aspects in hairball architecture (e.g. the loss of transparency and the wasteful approach to resources), but I will come to that aspect in later posts of this series.

In my next post I will write about the first contact between the Developer and another person from another tribe and how that has changed the life of the developer.

Running and Scaling Virtual Enterprise Architecture in the Digital Age

It has been a while since my last post, but I do plan to get back into a more regular posting mode. The main reason is actually selfish. During the time when I wrote a lot here on my blogs my thoughts became more clear and it was easier for me to drive ideas and decisions. I somewhat forgot to use the cleansing effect of the blog. Every now and then I also got some feedback. That feedback was of course also helping a lot, but the head cleansing effect is by far bigger (that should not discourage you to give me feedback).

I have written every now and then about People, especially in my small series Power, Process, Project, People, a topic which I was happy to share on the Gartner EA Summit 2013 in London. I am invited again to host a roundtable and this time I have chosen the topic "Running and Scaling Virtual Enterprise Architecture in the Digital Age" which is mainly about having a purely virtual Enterprise Architecture team and no dedicated resources in a Power based structure. I plan to blog a bit about that topic over the course of my next posts. Given the fact that the event is hosted by Gartner we talk Enterprise IT Architecture of course. If you happen to be there I am happy to discuss with you, be it on that roundtable or in another place. Just contact me.

The process implementation is a vanilla SCRUM implementation to organize the core team which has a decent amount of time on Architecture topics with an Kanban based add on to manage all other people and their architecture activities. Potentially the whole organization could participate and the target is to increase the usage of the Kanban flow to secure an optimal realization of architecture topics.

The Chief Enterprise Architect (or as my official title is: Director of Enterprise IT Architecture) is taking the SCRUM Role Product Owner. One person is dedicated to the Role SCRUM Master and the core team is the classical SCRUM Team. All other people who are working on Architecture topics get triggered by the core team, so that always a core team member stays on top of the content to secure alignment in the total SCRUM team. Adding and removing people, especially in the Kanban flows, is now a fairly easy task, provided that they do understand the way we document and model.

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.