drEAmtime - Communication

I read a great post from Ivo Velitchkov about drEAmtime which i recommend to read. I will try to pickup Ivos observations and explore how I handle the things he mentioned. He put in a great way what I am also observing and where I therefore use a different approach, even though I am in the end just another Enterprise Architect.

To quote Ivo:

The strong IT smell of the EA language decreases the chance of the Business to believe that they would benefit from learning it and that explains the low motivation and buy-in. Even though the cognitive load for IT is much lower, seeing the willingness of the Business to ‘improve’ its literacy, IT people find better things to be busy with. And another funny point. When there is some buy-in by the Business, EA is put under IT, not between business and IT. Then EA people complain they can’t do much from there. But may be they are put there just because they can’t do much.

Well observed if you ask me. So what am I doing to handle this? First of all I focus on people:

That is easy to say and write, but what does it actually mean? Well, I invest in the interesting to reveal the relevant. And I do that by using the "normal" language, so no special words, no special approach and for sure nothing based on any given EA framework. Just nothing, plain talking in a well proven language. (This does of course work only if it is one of the two languages I mastered good enough so far. I am trying hard to add a third one, but it seems to be a long and difficult journey to success).

From an communication point of view I indeed believe that I should operate between IT and Business, but this is not based on having the title Enterprise Architect, but based on my interest in operating in two domains at the same moment in time. That allows me actually to love to talk IT talk and business talk. I have literally no demand to force IT and business into speaking the same language or force them through a very rigid process, because I stopped thinking to be an Enterprise Architect and started to know that I am. Therefore I operate between business and IT, even though from an organizational point of view I am at the moment located in IT.

So I just focus on repairing the information flow, which then allows to find better solutions, some of them supported by IT solutions, some of them not supported. Reality is though that most EA approaches (frameworks as much as people owning the title Enterprise Architect) I have seen so far are indeed not aiding and simplifying the communication but do add an enormous amount of cognitive load, which is literally impossible to understand for anyone not fully familiar with the various methods. I might find the time to explore the benefit of acting like that later, but for the moment the key message is: optimize the information flow by utilizing communication.

 

Comments as always more than welcome. It helps me to improve my thinking and understanding.

Context of Architecture Roles

Today I was triggered by some posts where there was some opinions on where the line between Architecture and Design is.

One discussion was around an interesting blog post from Mark Wilson: "Where's the line between [IT] Architecture and Design". From my point of view Chris Potts answered it in a great way:

No line. An architect designs. | RT @martinhowitt: The line between architecture & design? By @markwilsonit markwilson.co.uk/blog/2013/01/w… #entarch
— Chris Potts (@chrisdpotts) Januar 23, 2013

There was a second Twitter post which caught my attention:

Architecture stops when detailed design begins. #TOGAF #EntArch
— Glen McCallum (@mccallumg) Januar 23, 2013

For both ideas I have the tendency to answer them very similar to Chris Potts: The Architect Designs, as I have also put it in my blog post GLUE Roles and Responsibilities. The [Role] Architect does deliver the [GLUE Discipline] Design. Nevertheless there is an enormous amount of specialized Architecture Titles. And it is in the nature of the discussions between the people who own the title to create clearly defined empires, so that there is preferable no overlap. Reality (for real Enterprise Architecture) is that there is always overlaps. And the good news is that the tension and friction created due to the overlap have a good chance to enforce creation of new (hopefully great) ideas.

So, don't think you are an [xxx] Architect, but know you are, then you do not have to seek for a perfect definition. (There might be no chance to find the perfect answer, but just a working one. One that works for you only). The key message though is, that it is not a title, but a role. A role which will be fulfilled in any given context, because [Enterprise] Architecture inevitable happens, no matter if the people who perform it are titled in the right way or not.

Invest in the Interesting to Reveal the Relevant

Every now and then I touch the domain of interesting and relevant (e.g. Glue Governance, Enterprise Architecting Past, Future or Present, A Matter of Perspective or Don't Panic). I want to look a bit deeper into it here, therefore as an appetizer first some definitions from merriam webster:

• interesting
• holding the attention : arousing interest
• relevant
• having significant and demonstrable bearing on the matter at hand
• affording evidence tending to prove or disprove the matter at issue or under discussion
• having social relevance 
• proportional, relative

The focus for many people (and yes, I focus on people as mentioned more than once) is typically more on the interesting topics, mainly because they are, well, interesting. It is easy to observe in many meetings, no matter of the business relevance, where specific triggers create potentially very long sidetracks which attract the people way more than the facts given. A way to counter these sidetracks is to stick strongly and tough to an agenda and execute it. The drawback of this approach is fairly often am negative perception of the meeting. Even though the structure is valued, it is kind of anaemic and does not allow the participant to connect emotional.

And emotional connection (also a thought of Tom Graves in his blog) is one of the key aspects to stop thinking to be an Enterprise Architect, but start knowing to be one. Therefore my suggestion (and my daily action) is to invest into the interesting. And of course I do not invest into what others find interesting, but I consider to be boring. That would be even worse than sticking all the time to the agenda. But those topics I and others find interesting are worth to explore. Even though they are complete sidetracks they generate an enormous connection. That connection utilizes fairly often, because all of sudden, being connected to other people, the pure relevant facts are more easily exchanged. On top of that those sidetracks always carry quite often a relevant insight in themselves, just hidden between the lines. So my advice is: sidetrack, invest into the lengthy non relevant  sidetrack, explore wherever the communication flows goes and you will find gems. Gems you will not find if you stick to the facts only.

GLUE Framework - Fixed Circulatory GLUE Cube

In my last post Glue Journeys - Obvious Missed Take 2 I fixed a small but very relevant diagram mistake in my circulatory GLUE Cube.

I found this mistake while exploring the need for Enterprise Architecture Domains.Therefore here also the updated version of the diagram for the complete GLUE Framework:

• People fulfill one or many Roles in an Enterprise
• A Role has responsibilities with respect to a Delivery.
• A Delivery delivers a Deliverable (what a sentence).
• A Domain groups Deliveries.
• The Circulatory System contains all (relevant) Domains. (And here I need some time in the future to create the whole storyline without the errors. Maybe not in a blog but in a different format. I do not know how yet though.)

So to translate this into other words:

• The Domains are nothing else than the Empires (and yes, sometimes there are relevant conflicts between Domains, which I then try to fix by optimizing the information flow).
• The People are nothing else than the members of the tribes and typically grouped by the Roles and Responsibilities on the Deliverables.

So is it possible to run this in a truly different way? Or are the so called other ways in reality just a different representation of the very same concept? I need to explore this deeper to become a better Enterprise Architect. Comments as always more than welcome.

GLUE Journeys - Obvious missed take 2

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 the flow in the Division Destination is correctly displayed. The other two Divisions Discovery and Defence are missing a flow between the Discipline Describe and Define. So here is the new updated diagram covering the idea now more complete. If you find any mistake in my thinking or like to discuss my thoughts and the way I represent them please feel free to contact me.

Update: And then I made another mistake a couple of weeks later by deleting the wrong files. :)

Enterprise Architecture Domains

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.