Last April Doug Newdick (@dougnewdick) made an interesting comment to Architecture and the Remainder of Design:
I think there is a distinction between “agility” and “agile” that we are both glossing over. Agile architecture (or more properly “agile architecting”) is architecture that takes the “Agile manifesto” seriously. Agile architecture is a (software development) process. Agility is a property of systems or enterprises. You can architect for agility without doing it in an agile fashion, and vice versa. So the process can be agile, and the resulting architecture have no agility. I take it that a key point of any system or enterprise architecture is designing in those points of flexibility that support desires for enterprise agility, and designing in points of inflexibility where the business does not desire agility.
I understand what Doug is hinting to. It is important and something I have not yet addressed. So I’ll give it a try.
I do not think the difference is in the words agile and agility. What I actually notice is that we are confronted with two structures underlying two different systems:
- structure
- structure to structure
“Structure to structure” is the factory, the factory that produces the “structure” which is the product. The factory represents the structuring competence. That competence can be agile or not, independent of the characteristics of the product, as Doug is rightfully arguing.
The “structure to structure” has different facets as it is in fact always a social system, potentially making use of supporting systems. When the product is a social system too, the factory is often part of the product in a recursive way:
For an enterprise, the factory is the competence that develops the enterprise structure, and indeed often part of the product itself. When making this concrete with the example of an agile development competency, the factory structure is what has been institutionalized in a social system, contained within the enterprise, including all the support systems that have been installed for the purpose as well. Nonetheless, the factory can be very unstructured, being the counterpart of craftsmanship that was applied in building the first automobiles more than a century ago.
The factory introduces another interesting question as to how it is positioned with regard to orders of agility. Clearly the factory can be very agile in producing an ineffective product, a fact often forgotten.
The path from thought to the 'dry', 'sec' essence 
I think this is a rather interesting and insight full coment into what architecture in a organizational or business context is all about. Adding structure and platforms to systems that otherwise would be chaotic.
Keep up the good work.
Kind regards,
Peter Flemming Teunissen Sjoelin
http://www.coherencyarchitect.com
Hi Kris,
Nice post. You have hit on something here. While I believe I was right – that either the process or the product can be “agile” – it is definitely true that there is a correlation. An agile process is more likely to give rise to an agile product, and a non-agile process is more likely to give rise to a non-agile product. I believe that this is because of soemthing that we overlook too often in enterprise archtiecture – values. If you value agility (and those core aspects that underly the agile manifesto) then this will show itself in bothe process and the product that you design. And as you say this is even more likely when the product is the enterprise itself.
Cheers,
Doug
Doug, I take another view on agility. I see agility as a property of dynamics, not of structures. So I agree that agile architecture is a process. But you can, in my view, not design an architecture that behaves agile by looking at the structure alone. Therefor you have to look to the dynamics, the behavior under different circumstances, of a system by performing simulations.
Real agility is the result of plasticity: the capability of a system to transform or adapt itself based on sensory information. Like our brain works together with our senses. I just started to record ideas on this subject at http://peterbakker.wordpress.com/the-relationship-platform/the-enterprise-backbone/
Hi Peter,
You are absolutely right that agility is not a property of structures alone but dynamics as well. But stating otherwise was not what this post is about. What I meant is that the act of developing structure, that I call factory, being agile or not, forms a system of its own, with its own structures. This system has hopefully strategy drivers but definitely operations as well as I have described in orders of agility. I also believe that agile development is more about operational agility than structural agility. But that some structure needs to exist as foundation to these agile operations is pretty obvious I think. I admit that I failed in drawing the full picture. I’ll elaborate more on this in the near future.
Hi Kris,
Sorry again for the name swapping, I wasn’t really deep reading this morning and I was confused by the “commented on” tweet :-)
First of all I’m curious if what you call the factory is the same asor similar to what I and SEI (at http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm) call a product line (SEI uses it in a software context but I use it more general)?
Secondly I now took the time to read this post again and your original article which ended with: “Although architecture is “the” prime enabler of agility, architecture itself is that what is inherently not agile.”
I like that statement very much (although I still feel that architecture is the prime enabler of plasticity) because I think that EA is too much preoccupied with the structure alone. Probably because it is looking too much at the way how buildings are designed or to urban design/planning. But enterprises, corporations, business or whatever name is appropriate are becoming more and more like living organisms which must react very quick to changing circumstances to be able to survive. And the way EA is done now is not able to cope with such fast changing situations. So I agree (because I think that is what you are saying) that the architecture process must become more agile but it also must deliver structures that are able to handle (or survive under) fast changing circumstances.
And I’m looking forward to future posts on this subject :-)
Thanks Peter,
Factory can be that but is not necessarily. In fact I am doubting if I should not use another term to avoid the confusion. I will need to think this over again and elaborate.
Personally I find the metaphors of the brain or the organism in relation to the enterprise flawed. I am a supporter of Russell Ackoff’s system types definition that categorizes an organism as an animate system while an enterprise is a social system which is different. An introduction to that classification can be found in On the Mismatch between Systems and their Models.
Kris,
Thanks for the link to Russel Ackoff’s piece which I shall read carefully :-) (and I’m amazed that I didn’t heard of it until now)
I think all metaphors are flawed by definition :-)
But I feel comfortable with the metaphor of the nervous system for several reasons but mostly because I consider myself more of a modeler/model builder or map maker/cartographer than an architect. And the nervous system is the most advanced model/map making system there is
So for me it is the best metaphor I can think of (until this moment?) to tell my story, which is more about modeling an enterprise or making an enterprise legible than designing an enterprise :-)
Kris,
When I was searching for the relation between storytelling and the brain I found this paper called “Social Organization as Applied Neurobiology: The Value of Stories and Story Sharing” which contains this quote:
If you read the paper (and agree with it) then you will see that the metaphor is not flawed at all :-)
Hi Peter,
Thank you very much for the interesting pointer. This paper is an example of literature that seeks all salvation in embracing complexity, through embracing emergence in the form of self-organization, and by simultaneously rejecting the value of order (e.g. hierarchy). I believe that embracing complexity is very important and that self-organisation can add tremendous value but that one should not “throw out the baby with the bath water” with rejecting the value of order. With all the advantages that self-organisation provides, it also brings its disadvantages: unpredictability, unreliability, unrepeatability, hard to scale, etc. With only embracing complexity, one cannot build a viable and sustainable business. Successful business requires the realization of determinism. Any successful enterprise that gains value with applying self-organisation, has therefore also order in place. The most effective order is probably very much aligned with what self-organisation would result into, but is not the same. Just look at how even social animals like chimpanzees definitely have hierarchy in place. The hierarchy develops via self-organisation but once in place with the recognition of a distinct leader, becomes pretty rigid until it is challenged again by new self-organisation.
Self-organisation is great for exploration but pretty poor for exploitation. Apple, the company that many like to admire because of its unprecedented success, has shown an impressive capability with regard to exploration but can hardly be called leaderless.
So it is not one or the other, but both, self-organisation and hierarchy that are necessary: the former for exploration, the latter for exploitation / determinism. The brain methaphor is hardly complete in that regard because animated systems (in Russell Ackoff’s terminology) on their own are not deterministic and therefore highly unpredictable.
Hi Kris,
Perhaps I read the paper somewhat different. It is not written as the truth but more as a question why we value leadership and hierarchic so much. At one point Paul Grobstein writes:
I’ve read the book Steve Jobs by Walter Isaacson and to me it is clear that Steve Jobs life was a life full of continuous negotiation (with himself and with others). I think most people would agree that Steve Jobs and Apple are the most successful business examples of:
And I forgot to mention that maps and models are also by definition flawed :-)
Sources:
Mind the Map!
Click to access Mind_the_Map_Guo_Zhan_2010.pdf
All Models are Wrong: Reflections on Becoming a Systems Scientist http://web.mit.edu/jsterman/www/All_Models.html
Of course, as George E. P.Box’s “All models are wrong, but some are useful” learned us.