Enterprise Architecture and Agile

Dave Nicholette argued recently that Enterprise Architecture and Agile are not compatible partners:

The mission, scope, tools, mentality, culture, and personality types of enterprise architects and agilists are so radically different that (in my view) they call for separate administrative subdivisions in the enterprise. Not only is the nature of their work different, but the management styles, employment incentives, and career path options that work with one group don’t work with the other. The staid working conditions and deliberate pace of progress of enterprise architecture work would bore and frustrate an agilist. Conversely, the intensity and unpredictability of agile development would stress out the type of person who tends to prefer things standardized and repeatable.

I’m taking a little different tack on the meshing of Enterprise Architecture and Agile. Enterprise Architecture is a holistic attempt to define systems, processes, and tools across the entire organization though much of the focus ends up on the IT functions. Agile is a process within this and as it facilities better projects and faster ROI it lines up well with the goal of Enterprise Architecture. The central goal of Enterprise Architecture is to simplify IT.

Architecture within an Agile project is continuously evolved, but with the end goal that it should remain as flexible as possible while delivering at each iteration. You want the system to be as lean as possible, you shouldn’t be writing speculative code that might be used in the future.

Traditional ‘Ivory Tower’ style Enterprise Architecture does clash with Agile as it assumes a command and control culture with a heavy focus on governance. I see no reason Enterprise Architecture can’t be done in an Agile fashion. Even analyst firms like Gartner agree that defining a future architecture and then sticking it on a shelf never to be revisited is a recipe for failure. My belief is Enterprise Architecture efforts are only going to be successful through collaboration with developers, testers, business analysts, PMs/Scrum Masters, and business customers. And the critical cycle of ‘inspect and adapt’ on Agile projects is just as crucial to Enterprise Architecture.

My suspicion is with Agile and Lean ‘crossing the chasm’ lately we’re likely to see big changes in the approaches to Enterprise Architecture in many shops.

2 responses to “Enterprise Architecture and Agile”

  1. johnwu says:

    EA was initiated to overcome the challenge of stovepipe solution and enable simplicity and agility. The limited success of business transformation is not due to lack of good design, rather it is due to lack of agile solution.

    Light Enterprise Architecture (www.liteea.com) suggests that EA is the effort to enable simple and agile information age solution. To achieve this goal, Enterprise Architect has to see the enterprise big picture, understand how it work and learn experience of the others in the same line of business. These are the means to achieve the goal of simplify and agility. Unfortunately, the means is bittern known than the goal and shown in the suggestion that EA is irrelevant to agility.

    For more information, please read


  2. When you talk about architecture “within a project” it makes me think of application architecture rather than enterprise architecture. “Within a project” we aren’t going to simplify the IT infrastructure enterprise-wide. Instead, we ought to follow the guidelines and use the technologies specified by the enterprise architecture group.

    Agile doesn’t seem to fit the enterprise architecture function as well as it does the customer-facing business application development function in an enterprise. That’s why I think the two are different jobs – not that they are incompatible or that they aren’t “partners”. Of course, that’s not to say agile/lean thinking can’t help enterprise architects achieve good results; especially the core concepts of focusing on value and reducing waste.

    Enterprise architects are trying to define a robust technical infrastructure the organization can support and that provides the -ilities to the business applications that reside in the infrastructure. Their customers are the teams that build business applications for the enterprise.

    This is quite different from the mission of business application development teams. Their work focuses on one business unit at a time, one business process at a time, and consistency with other applications elsewhere in the enterprise isn’t usually a high priority.

    The two are definitely compatible and definitely “partners”. A good enterprise technical environment will include common assets like a data warehouse, a business rules engine, an integration platform, and many other facilities that business applications can plug into. It will also handle most of the usual operational issues like backup/recovery and scaling in a way that relieves most business application development teams of building that functionality into every app individually.

    It’s a great partnership! But the two jobs are totally different. When we get into the cultural differences, it becomes clear that the same sort of person who thrives in one environment is likely to hate the other. All the more reason to go ahead and officially treat the two as different jobs.