Aggregated enterprise architecture wisdom
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 pre…
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 pre…
It is a while ago since I was exploring the GLUE Journeys and found a diagram and explanation mistake and fixed it in my post GLUE Journeys – Obvious Missed. And of course, there is more mistakes and in the very same diagram I made another mistake.Only…
It has been a while since I posted last time, because I was pretty much occupied in my job to deliver some interesting projects on the edge between 2012 and 2013. Lucky enough I was able to deliver. 🙂 On top of that there was a portion of Christmas preparation and a new private project with a Iceland Dog.
So now it is time for the first post in 2013. I was triggered today by a tweet from Keith Flanagan: “Enterprise Architecture is about people. Not domains!”. I do not know what triggered the statement for him, but I am sure that he is right as tried to put it more than once in my own blog here, e.g. People in GLUE. My primary focus in my Enterprise Architecture work is clearly the people.
Nevertheless, I do believe that people and Domains (could be GLUE Domains, could be other Domains) are pretty much related. I believe most if not all Domains (and the resulting Domain Models) do exist to somehow create an area of responsibility or an empire. The thinking behind the GLUE Decks is also based on Domain thinking.
The Deck System of Systems can easily be split into several Domains for grouping purposes or to create a silo or an (as much as possible) area of responsibility. I think the Domains exist in the typical Enterprise and should therefore be identified, named and analyzed. I furthermore believe that in most cases there is a fairly clear hierarchy between the Domain and the Applications in that Domain. And quite often conflicts exist exactly where that hierarchy is not clear, where an Application belongs or should belong to more than one Domain. And I think what can be observed here is once again Conway’s Law.
I therefore have to explore Nick Maliks tweet deeper: “Autonomy is a necessary intrinsic motivator. EA must replace “empire building” with different autonomous goals.” I am not sure if that is correct or not. I personally typically accept the given domains and work more as a mediator (or GLUE) between the various domains by looking for GLUE Diseases and trying to fix them. And as far as I remember it was always about people and always about communication, but maybe I have done it wrong or not used the full potential. Therefore I am happy to hear comments and ideas how to shift away from the standard empire building or tribe thinking towards something more holistic. I am not sure if that is truly possible.
Comments are more than welcome.
I have read an interesting Blog Post from Paul Wallis about Asset failure and flow wich focusses on the physical elements. I really enjoyed reading the post and I can only encourage you to also read it with care. It furthermore triggered me to think and write again about the flow of events through an Enterprise. I will pick up quotes from the mentioned blog post and reflect on them by creating a collision of ideas to my social EA thinking.
When key flows – water, electricity, natural gas or sewage – are interrupted in an urban area, our lives become very difficult, very quickly. Interruptions to these critical flows will often cause knock-on interruptions to dependent secondary flows, impacting things like flows of people, flows of vehicles, or flows of goods through supply chains. Flows of data are no less vulnerable to interruption caused by unexpected interactions with other types of flow.
As I have written in GLUE Disease one of my main approaches is to look at the key flow (of knowledge) and especially into dysfunctions of that flow. If I find a dysfunctions I try to optimize the flow of knowledge direct or indirect depending on the given situation. If I am successful the achieved better flow of knowledge through the Enterprise will lead to better decisions.
But in today’s digital world, risk lies not only in the failure of IT assets that directly enable data to flow, but also in the failure of other less obvious business assets: a leaky door, a de-pressurised cable, a failed valve or a broken pump.
As I have written in People in GLUE what really matters are the people. They make the difference and they in the end form the real flow of events. Processes and Methods do help, but what really makes the difference are the people.
If the people fail there is no process and method available (at least for EA not) to secure the success and an optimal information flow. Therefore I personally focus on the people first. Of course there is a certain amount of processes and methods needed (to help the people working better), but as written in the agile manifesto: Individuals and interactions over processes and tools. Of all the assets available, people are the biggest and therefore should be threated according to that.
Today I had some great discussions at Sapphire TechEd in Madrid. Despite all the very interesting content driven discussions I really enjoyed a discussion around Enterprise Architecture. Even though I heard mostly Enterprise IT Architecture, there was …
In the last days a great blog post of Gerben Wierda was brought via various channels to my attention which contains a very good video about Enterprise (IT) Architecture: I do not want to add much to the tribal war between Enterprise Architecture and En…
In my last post I have written about the concept to compare Enterprise Architecture with the Matrix. In short: free your mind and open up for all the possibilities. There is no reason to stay inside the boundaries provided by the various frameworks and…
The key aspect behind this thinking can be found in my way of tackling complexity:
I like to use the analogy of walking:
Therefore to move the Architecture from one state to the other (As-Is -> Transition Architectures -> To-Be Architecture) the whole system gets out of balance all the time, because it is the only way to move. The whole GLUE Division Discovery is completely dedicated to out-of-balance behaviour, so the same flow as walking with GLUE terminology:
In a perfectly running GLUE the next To-Be is close to automatic (or at least very fast), which translates into a system where the change between balance and non-balance is done so fast and automatic that everything is perfectly in flow. In most cases I find (or throw myself at) systems where the flow is out of balance, but the system stable (and unwilling to change). Here I give up my own balance (entering willingly Not-Known) to create a momentum to change.
And I do not know why, but this flow of events is kind of a Zen feeling for me: things happen unpredictable and real time around, with and due to me while I try to categorize (EPIC SCAN) them, set a direction (WISE SCAN) and support the execution (PACE SCAN). In most cases this require to be very flexible with the methods and tools and therefore I apply most of the time (80%) agile techniques. And here the technical tool I use is a whiteboard and markers.
In my lasts posts I was exploring complexity and how I tackle the problem of complexity by applying my GLUE thinking to it. Therefore here a short summary so that my thinking about complexity up to now is collected in one place. I am using the SCAN fra…
In my last posts I explored the world of complexity and started with Don’t Panic. An advice which does not only work for GLUE and Enterprise Architecture but is generally a fairly good advice. The some ideas collided in my head (which reminds me of the…
In my last post I was writing about EPIC SCAN, a combination of two great sources of knowledge including a reflection on how I use it. Emergent, Perverse, Irreducible and Contrived existing Complexity is SCANned for how complex it really is. According …
