Is Agile the future of EA?

Agile principles and methodologies have been around for a while now and Enterprise Architecture for even longer. Although it took about 10-12 years each to reach the early adopters stage of the technology adoption life cycle, as any technology, method or approach having similar maturity level, both practices have their devoted supporters and fierce critics.

The Agile Manifesto* has been published in 2001. Few years before, I attended a conference given by Martin Fowler who presented many forward thinking and inspiring principles and approaches that certainly inspired the manifesto authors (whom he was part of). At the time, I was leading a small team of developers and I slowly started to introduce them to few of these principles. Some were well accepted and brought immediate tangible returns while others were difficult to comply in the context we were in at this time. Henceforth, for as long as I was committed to software development (2009), I always worked with an iterative approach and used development methods that were aligned with the values and principles of the manifesto.

Since then, my professional path evolved into becoming a solution and enterprise architect. Thus, I have learned the difference between strictly delivering software and, delivering a complete software solution or a software driven business transformation. This experience allowed me to widen my vision on the process and impacts of the change/introduction of new enterprise applications in a business and work environment. However, these projects were planned and managed in a more traditional waterfall approach with, what I considered, a very debatable efficiency. This experience did not weakened my trust in an agile approach on how these transformations could be realized... quite the contrary.

One important critic of agile methodologies is that they don't scale to meet the enterprise requirements. This critic has it's merits as most agile formal methodologies address exclusively the software delivery cycle and speak nothing about incorporating the concerns related to an enterprise context. For instance, it is true that the architecture regarding the internals of an application can emerge from a group of developers but, without external guidance, that architecture could be at odd with the best practices and overall architecture of the organization (ex: common source of information, integration standards, technology constraints, evolution, maintenance, etc.).

However, even if formal methodologies fail to address the enterprise concerns, it doesn't mean that the agile values and principles cannot be applied to a wider scope than software delivery. Many authors have researched the subjects and wrote about it. Dean Leffingwell with Agile Software Requirements (2011, Addison Wesley), is proposing a scalable and iterative approach to requirements management that blends well with agile concepts and methods (Scrum or Lean) as well as with the imperatives dictated by the enterprises concerns (program and portfolio management). The year after, Scott Ambler and Mark Lines published the Disciplined Agile Delivery (2012, IBM Press) which describes a decision framework to tailor almost any agile methodology by, among other things, providing many focus and scaling alternatives at the team level. Moreover, it is important to stress that in both cases, the alignment to the agile values and principles remained intact. As an enterprise architect, I happily welcome these developments as they will help us increase our efficiency and grow our profession.

As stated at the beginning, EA also faces critics. The most compelling being it's incapacity to timely deliver tangible value to both the business and IT sides of the house. Lots of "Top X reasons for..." and few more serious analysis are available when Googling about it. They can mostly be summarized as being critical about the exclusiveness of the methods used by EA practitioners and the lack of awareness of the purpose of the EA practice within the organization; obviously, both are people oriented problem.

This is quite worrisome as it is fundamental that EA maintains clear and open channels with the business as for one, business being their primary sponsor and two, EA's major responsibility is to keep IT aligned with business. As for IT, EA should be a facilitator by providing timely and actionable guidance to developers and technical specialists regarding the enterprise architectural principles, standards and best practices as well as the current and future architectural context in which their application or technology will be deployed and used. Moreover, EA should actively collaborate with the same IT members to develop and evolve such architecture, standards and best practices.

Looking at new research and adaptations of the agile concepts, it is quite obvious that agile value is on the rise. Practitioners like it because it recognizes and values their talent and competence while business like it because, in most cases, it delivers. Conversely, EA's value perception has become dubious and, in many cases, has isolated practices from the rest of the organization. The common denominator of both situation is their respective approach toward people.

Agile values and principles are mainly about people... not technology, not frameworks, not tools... simply people. EA's success depends on people from both business and IT that, without hesitation, will assess that EA is a definite contributor to the success of their organization. No matter how, agility has become a quality many EA practices should spare no effort to acquire and apply in their methods. Such evolution will demonstrates that EA is not only able to realize enterprise transformation but also, is able to realize it's own transformation.

As always, I welcome comments and suggestions.

Jacques

* http://www.agilemanifesto.org/