Agile EA has been a topic for some time, with Scott Ambler being a notable pioneer. Various authors advocate that practices like iteration, Scrum, incremental delivery, and DevOps be combined with enterprise architecture, but I think more can be said about EA objectives in terms of:
- Reinertsen's and Ries' views on product development
- human visual processing and
- the concept of the OODA (Observe/Orient/Decide/Act) loop
Reinertsen & Ries
The work of Don Reinertsen (Principles of Product Development Flow) and Eric Ries (Lean Startup) is rich in insight for EA and merits a longer piece. Reinertsen views product development as essentially the production of information, a powerful insight. Ries states that we generate information through the process of hypothesis and falsification. Reinertsen further emphasizes the need for an economic framework to guide all decisions, one especially attentive to Cost of Delay. EA must support these principles.
An EA future state diagram is nothing more than an hypothesis, and EA needs to be alert and adaptive to its falsification. Waterfall and command-and-control EA is inconsistent with this principle and therefore harmful.
However, the way information is generated in product development is through the "pruning" of unprofitable avenues - falsification and "failing fast." EA can play an important role here, as architects are tasked with understanding broad dynamics and cross-system interactions. EA also seeks to reduce variability and waste in the operating environment. These concerns are grounded in Lean and to the extent that the EA group is effectively performing them, they are adding value.
In order to deliver value in this way, the EA team needs to match the cadence of the Agile teams. This is a central challenge.
There are many other EA insights to be drawn from these authors; see note at the end of this piece.
EA draws pictures. Architects in general don't write code; instead the most visible aspect of their work takes the form of diagrams -- abstract graphical representations of complex systems. This has been problematic in the Agile community as some IT professionals, including perhaps some of the most skilled software engineers, find little use in diagrams. (See Martin Fowler's Is Design Dead?)
However, Dan Moody, in his seminal paper The Physics of Notations, observes that:
Visual representations are effective because they tap into the capabilities of the powerful and highly parallel human visual system. We like receiving information in visual form and can process it very efficiently: around a quarter of our brains are devoted to vision, more than all our other senses combined ... diagrams can convey information more concisely and precisely than ordinary language [8, 68]. Information represented visually is also more likely to be remembered due to the picture superiority effect...
...Visual representations are also processed differently: according to dual channel theory , the human mind has separate systems for processing pictorial and verbal material. Visual representations are processed in parallel by the visual system, while textual representations are processed serially by the auditory system...
Because diagrams are more readily processed, they are often used to represent high level system interactions - how a given service, product or application is related to peer systems and services. Building such depictions can be helpful to fostering a shared mental model of the overall system objectives and context, crucial to orienting teams in complex environments. Making these visualizations easily available and re-usable is a critical objective.
Humans go through a defined process in building their mental model of complex and dynamic situations. This has been formalized in the concept of the OODA loop, popular of late in the Agile community. Standing for:
the OODA loop is a concept deriving from US Air Force doctrine, in particular the work of John Boyd who broke down the mental processes of Korean War fighter pilots into the OODA cycle. He and others have extended this concept into various other domains including business strategy.
Especially in complex enterprise environments, it is essential for people to quickly ground their individual observations in a broader shared mental model. A well represented and easily accessible enterprise architecture should help people understand the purpose and relationships of any arbitrary IT resource in their environment. Therefore a conjecture: Enterprise Architecture provides value in the Orienting phase of OODA.
I think there is much to guide EA in applying these ideas, but I also think there is much to support the continued existence of EA as a coordination and governance function. If we understand EA in terms of its underlying motivations, we can better create truly agile EA.
I am working on a longer paper on these ideas - if you are interested seeing it please drop me a line.