drEAmtime - Bridging the Silos

As I have written in my last post "drEAmtime - Communication" a a great post from Ivo Velitchkov caught my attention and triggered me to think which is now resulting in the second post of a series of yet unknown length.

To quote Ivo:

The EA people instead of building a bridge between the two silos, create a new one. And at certain point they find themselves in the position where neither Business nor IT regards them as a bridge any more. The Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people loose trust to EA as well because they are not sure they understand the Business and if they still remember what was IT. Further, IT managers need support which EA does not have the authority to ensure.

Again well observed. Here is actually way more than one observation. First of all the additional Enterprise Architecture silo. It is emerging when the desire to differentiate is higher than the desire to solve problems. Due to the typical way organizations measure success and failure it is in most situation inevitable happening. The real business people push back the Enterprise Architecture people, because they do not know enough (or the right things) about the business and the IT people push back the Enterprise Architecture people, because they don't know enough (or the right things) about the IT. So literally it is again about communication, in this case collisions between ideas.

As I have put it in my post "Real Enterprise Architecture", there is typically more than one organizational unit doing the conceptual work of Enterprise Architecture. In Ivos example it is business against EA, therefore there is a natural conflict between the (green) business domain and the Enterprise Architecture (blue) domain with a natural overlap (orange).

Conceptually the same conflict exists between IT (white) and Enterprise Architecture (blue), therefore indeed in most situations the emerging new (and scary?) function of Enterprise Architecture does create a new silo with new interfaces (or without).

Another example is the potential deviations inside one domain as I have explained in my post "Tailoring Domains". Here Enterprise Architecture is also supposed to bridge silos, but has a huge potential to be seen as an intruder and therefore being ignored or fought. (What does the (stupid) Enterprise Architect know about my Application?).

For both cases my answer is (once again) the same. I focus on people and try to optimize the information flow. This is (once again) not based on a specific EA framework or method but centered around communication and working with people.

 

Comments as always more than welcome so that I am able to improve my thinking and writing.

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.