GLUE Disciplines

Yesterday I was writing about starting GLUE, or the vision behind GLUE:

General Process Framework with

Loose Coupling of Process Components using a

Unified Approach for

Engineering in all fields.

I believe there is an underlying pattern in all approaches to engineering. Of course there is different names, methodologies and frameworks. By analysing the flow of information no matter what the documentation approach was some common patterns emerged no matter what is engineered or what framework is used.

“The cobbler should stick to it’s last.”,

Appelles (4th century BC)

The GLUE value stream contains of six disciplines. Each of the discipline as a specific driver and a specific approach on how to deliver. One discipline builds on top of the output of the former discipline.

Do Operation

The core of the GLUE value stream is to do things. The main driver is stability and the main approach is to get things done. For simplicity reasons in most cases people will strive for delivering things in the same or similiar way than the last time.

Describe Intention

If things are done new ideas are emerging. The main driver is to do something different and the main approach is to look at the existing in a different way. Describe Intentions is causing a natural resistance to protect how things are done today against changes and how things could be done.

Develop Solution

To achieve the intention a new solution needs to be developed. The main driver is to change how things are done and the approach is to implement a new solution. Develop Solution is creating a conflict for how things are done today and is usually not fully achieving the intention.

Define Requirement

To manage the conflict between Describe Intention and Develop Solution defining requirements helps. The main driver is to formalize what will be delivered and the approach is to document and agree before developing a solution. Defining Requirements supports the conflict between Describe Intention and Develop Solution by legalizing it and therefore leading to a fact based conflict.

Detect Defect

To prove that the requirements have been delivered by the solution testing is needed to detect potential defects in the solution. The main driver is verification and the approach is testing quality. Detect Defects supports the conflict between Develop Solutions and Do Operations by creating a fact based quality check.

Design Architecture

If the complexity of a solution is growing to much Design Architecture does enable a better structure. The main driver is to organize things and the main approach is to assemble elements. Architecture creates a conflict for Develop Solution by adding boundaries to the solution.

So the value stream of GLUE looks like following:

1. Describe Intention is formalized by Define Requirement
2. Define Requirement is organized by Design Architecture
3. Design Architecture is implemented by Develop Solution
4. Develop Solution is run by Do Operation
5. Do Operations is checked by Detect Defect

Is it that simple? On the one hand I think it is that simple and I will try to look at different methodolgies in future posts and try to map them to GLUE. On the other hand I believe that reality can not be pressed into a one-dimensional apprach, so in future posts I will add more dimensions to GLUE to explain the full picture I have in my mind.

GLUE Vision

2007 I was asked to support an IT process optimization project. I was in the lucky position to have a very knowledgeable manager who was challenging me well on the information I created. While explaining the potential different process alternatives to him and being challenged what that means and supports and what it does not mean and does not support I got carried away by the work and created a generic framework to describe all process flows in the IT organisation.

Apparently the perception was not very well, because it answered a question which was not asked and none was able to relate to.

In the recent weeks I stumbled every now and then over some concepts which reminded me pretty much on my initial work on that generic framework and the evolution it has undergone over time while I applied it. It was somehow easier for me to create my own framework with my own thoughts than just stepping into one of the existing and fully adopting to it. What hit me in the past (and still does today) was the complexity of all the frameworks and the different words they use to describe the very same, be it inside one profession or cross-profession.

“Life is really simple, but we insist on making it complicated.”,
Confucius (551 - 479 BC)

Therefore I created my own vision trying to reduce complexity. It works for me and I named it GLUE:

General Process Framework with
Loose Coupling of Process Components using a
Unified Approach for
Engineering in all fields.

This is hopefully only the first post in a longer series of posts while I restructure GLUE once again to add the in between gained knowledge. I use this also to restart my blogging attempts.