Digital, Agile and Continuous Architecture
The rise of Agile, DevOps and concepts such as Continuous Architecture are increasingly challenging the traditional approach to Enterprise Architecture and the role it plays in business transformation.
The challenge is often expressed in simple, even simplistic, terms. It is claimed that Enterprise Architecture cannot operate at the pace required to meet the needs of agile approaches to the delivery of software systems and thus it adds little value to organizations that adopt agile practices.
Although I appreciate why people are questioning the traditional approach to EA and its ability to bring value to business organizations that adopt agile, my belief is that without EA, agile practices will lead to an increase in entropy of an organization’s IT infrastructure. In the early days of Agile, the need to build architecturally significant elements at the start of the software development process was well recognized. It would seem that more recently Agile has focused more on delivering significant elements of its MVP and as a consequence put less emphasis on dealing with the architectural complexity of the application under development and as a consequence the overall integrity of an organizations IT estate.
The Challenge for Enterprise Architecture
In his 2014 article on the changing nature of Enterprise Architecture Jason Bloomberg (Forbes) stated:
“The writing is on the wall. For all the Miltons (Office Space) in the role of Enterprise Architect, applying frameworks and creating artefacts and generating documentation, the business value they provide is questionable at best. Those EAs who truly embrace change, who work directly with business stakeholders to move their organizations to an increasingly agile state of continuous business transformation – will more likely find themselves adding real value to their enterprises.”
This was written in 2014 but is still so relevant today in our world of digital.
So what really needs to change?
We need to move from the classic EA hierarchies of Enterprise Architect or Solution Architect etc. and move to a new discipline of Enterprise Engineering as a complimentary discipline to Enterprise Architecture.
So what does this look like in practice?
We should tear down many of the existing artificial barriers we have put in place and move to employing multi-skilled individuals capable of driving continuous business transformation. We need much flatter, but also much more comprehensive skills structures within our IT organizations, where multi-skilled individuals prevail and focused roles e.g. Solution Architect have all but disappeared.
There are two key roles in this new world:
This role is about being a change agent, and the key skill is understanding the agents of business and technology change that will steer an integrated organizational strategy.
This role merges the traditional developer, solution architect, agile PM into a single engineering role. Can translate EA principles into a Solution Design that balances tactical and strategic elements to achieve the correct business change.
|Infrastructure Design (Cloud)
|Agile / Scrum Master
There is a common theme that sits across both of the new skill sets and that is designing for change. We have to accept that this is not necessarily designing for MVP in an agile model. It also implies that for the Enterprise Architect has to change significantly if they are to become effective change agents.
Agile is correctly seen as an evolutionary and incremental approach to software development. I think that a true understanding of the impact of the approach through an EA lens is valuable in understanding the issues and potential risks of an agile development approach and its long-term impact on an organization’s IT systems. In particular I think it is helpful to consider the origin of the concept of evolution and its roots in describing the development of natural systems. We will find Natural Selection at the very core of any theory of evolution but:
Natural selection operates like a short-sighted efficiency expert, ferreting out each and every way to maximize reproductive success, even when this becomes detrimental to survival. Selection is not sentient and has no ‘goal’ other than optimizing the use of resources towards immediate successful reproduction.
So if we follow an agile approach, focussed primarily on short term goals, we can expect outcomes not dissimilar to those achieved by natural selection. That is architectures focused on short term objectives can lead to an architecture that may not be resilient to ecosystem shocks (new technologies etc.). The danger is that we find ourselves on the same evolutionary technology branch as the dodo.
Some will argue that this is acceptable because, through the use of agile, we can be quick enough to respond to new challenges as they arise. After all this ability is the primary rationale for adopting agile in the first place. But this only works if we are prepared, and able to throw away solutions in the face of new technologies or capabilities.
How viable is it for us to repeatedly throw away solutions and create new ones from scratch? I believe it is extremely problematic, given the characteristics of digital ecosystems, as defined by Michael Cusumano in his book “Staying Power – Six Enduring Principles for Managing Strategy and Innovation in an Uncertain World”. According to Cusumano, digital ecosystems drive simultaneous Innovation and Commoditization into an organizations business model. Commoditization of products reduces the price that can be charged for them and thus means that you may not have the resource to continually recreate solutions rather than recycle elements of existing solutions. So in practice the continued evolution of products without recourse to the overall cost of delivery is a condition that is unlikely to persist for applications that we build.
It is this dynamic of Innovation and Commodity that should drive any digital application strategy and it highlights another view of software evolution that mirrors the way ecologists are now starting to see evolution.
This whole field of design for change is a new area for architecture and will be the subject of a follow on article.