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.