To find an answer to my GLUE Vision I have developed over my last posts the GLUE Space, which is the intersection of the three GLUE Dimensions.
“Divide and Conquer.”,
Julius Caesar (100BC - 44BC)
Julius Caesar (100BC - 44BC)
I use the GLUE Space myself to map and understand frameworks, methodologies or approaches. To support the mapping I use the concept of the GLUE Domain. Each Domain is a part of the GLUE Space with defined boundaries.
EA - Enterprise Architecture
The basic assumption is that all Architecture Activities are covered by Enterprise Architecture. Therefore the whole Design Discipline in all Decks and all Divisions must be covered.
Business
The assumption is that running the existing organisation, setting the new destination, transforming and finally running the changed organisation is the ownership of the Business Organisation.
Conflict between EA and Business
By mapping the responsibilities of EA and Business into the GLUE Space the conflict between EA and Business becomes transparent. Both Enterprise Architecture and Business claim the same responsibility to design or architect the Business. This conflict creates friction which I hope to explore in another post in the future. I think that Conway's Law is one of the best descriptions of what happens there.
EITA - Enterprise Information Technology Architecture
To avoid the friction between Enterprise Architecture and Business quite often Enterprise Architecture is only focussing on EITA, the IT part of the Enterprise Architecture. The pushback and the reasoning behind can easily be observed in many forums where evangelists of all methodologies discuss literally endless about the boundaries between the different professions. For me it is quite simple by using GLUE: There is overlaps, so please get over the conflict and start collaborating (work together towards the same vision) if possible or at least cooperate (clear interfaces, roles and responsibilities). Non cooperation (mine, yours, bugger off) is not really helping to solve the situation at hand. Tom Graves was exploring that issue greatly on one of his last posts.
Application Life Cycle Management
Application Lifecycle Management is a typical responsibility of an Application Owner. This is a function which can mostly be found inside of IT and some interesting potential conflicts (similar as the example above) to run departments where definitions of first, second and third level support try to create clarity (and pity enough fail often).
Test Execution
Similar issues exist arround Test Factories. For simplicity I have only shown the domain Test Execution here which covers all activities to execute tests in the whole Enterprise. Here potentially a lot of conflicts exist with some interesting questions to be answered.
In future posts I hope to find the right words to touch Matrix Organisations as well as some specific answers from the market to specific problems. I will try to use GLUE to explain that but most likely the next post is about Roles and Responsibilities.
Feel free to comment and guide me towards topics you like to be explored by GLUE (if there is any). The more input I get the easier it is for me to explore it.
No comments:
Post a Comment