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.