Agile at scale: Architecture in the Age of Complexity

In Enterprise Architecture by IRM UKLeave a Comment

Print Friendly, PDF & Email

There is no doubt that the agile trend is having a profound effect on software development practices, as well as on the organization of IT departments and beyond. The enterprise architecture discipline itself is deeply challenged. Reading the agile manifesto1 sounds like an admonition to architects:

Antoine Lonjon, Chief Innovation Officer, MEGA International.
This article was previously published here.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

Individuals and their interactions … over processes and tools!“: venerable EA frameworks and methods such as SADT and its successors such as ArchiMate are shaken to their very foundations, not to mention TOGAF in its 9.x versions. This trend is not specific to IT and shares common ground with the Lean Management and Design thinking mindset. All share the idea that smaller is better whether it enables agile delivery, persistent improvement, or solution thinking. This idea of smallness within bigness is not new and has already been coined a couple of decades ago by F. Schumacher2 under the catchphrase small is beautiful. Schumacher argues that “when it comes to action, we obviously need small units, because action is a highly personal affair, and one cannot be in touch with more than a very limited number of persons at any one time”. It is no coincidence that Schumacher wrote his book in 1973 when the energy crisis was spreading on an international scale, as an emergence of globalization. At a larger scale, he acknowledges the need to bridge freedom to order, which can only be reached by linking local purposes to global purposes.

Indeed, making small-is-beautiful real, leads towards autonomous and self-organized teams which are empowered and given purposeful missions. The key for success is to work at a scale of activity where people matter. As Dan Pink says in his book Drive, “people Work for Purpose, Autonomy and Mastery3”.

Dan Pink Trilogy.png
Figure 1- Dan Pink’s trilogy on purpose driven autonomy

This approach manifests a shift of focus from the traditional command and control organization of work, to the organization of purposes. As stated by Conway’s law4 , the structure of products reflects the structure of organizations which produced them. Hence hierarchical organizations lead to monolithic products, One of the core challenges of modern architecture is to account for this parallel split of units of purpose and units of work. As such, if small is beautiful, how do you manage decomposition at the level of the enterprise? Additionally, how do you scale from local purposes to common purposes and ensure decentralized, sustainable business models?

For the architecture discipline to address these challenges, we need to revisit some of its core concepts: what do we mean by purpose? what do we mean by value? what do we mean by being product centric? As stated by Russel L. Akcoff5 , definitions are like surgical instruments: they become dull with use and require frequent sharpening and, eventually, replacement.

In our next post, we will address the challenging concepts of product and service. At the core of agile is the notion of product owner. But what do we mean by products and services?

Antoine Lonjon is Chief Innovation Officer at MEGA International. He has contributed to the foundation of the HOPEX enterprise architecture toolset and is also involved in standard organizations, such as the OMG and the Open Group

Copyright Antoine Lonjon, Chief Innovation Officer, MEGA International


1- Manifesto for agile software development:
2 – F. Schumacher :
3 – Daniel H. Pink, Drive : the Surprising Truth About What Motivates Us (Penguin, 2011)
4 – Cownay’s law: Conway’s law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967.[1] It states that  “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
5 – Russel L. Ackoff: Towards a system of systems concepts.

Leave a Comment