Friday, September 14, 2012

Fixing Flows

In my last post I was writing about GLUE or Architecture Diseases and apparently one of these diseases hit me recently. I was tasked to work on Application Lifecycle Management and in our Architecture Community we had some really great discussion on how to tackle it in the specific context. With respect to GLUE and especially the GLUE Decks we have been looking at the two lower Decks of my example:
 

 
For two sessions in a row we couldn't get a good drawing, because the (many) existing process drawings in the market are mainly tool specific, but for sure not fitting directly into the context of my current assignment. (which is a very typical problem and lead me to creating GLUE).
 


 
So i used my GLUE thinking to stay focused to the problem at hand and not getting distracted by all the specialities you always find. Furthermore it helped me once again to stay vendor agnostic, so that no existing tool in the market confuses the discussion about the wanted To-Be Architecture. Having said that I of course know, that the reality will look different than what we have created, but a certain investment into the future is needed to ensure that an adoption can take place.
 
The really interesting thing though was, that it did not work out in the beginning. The solution emerged by utilizing the knowledge of people inside the Application and Software Deck and by combining a presentation with the power of the whiteboard. By sending the presentation to apear on the whiteboard we have been able to draw our process ideas directly into existing process models in an fast and agile way and a new way to represent the idea emerged. Once more it was obvious that strictly following one way to represent a process as typically enforced by the various tools (and there is many in the market) would not have brought us to our desired target.
 
So fixing the flow and ensure that the GLUE Journey can continue was the key here to be able to get to a solution and I did not use many Architecture skills, but mainly communication approaches. I highly recommend that you spend some time on Agile Modeling from Scott Ambler.
 
 
 

No comments:

Post a Comment