Enterprise Architecture in An Agile World

In fact, your own ability to keep up with the latest trends have suffered because only you know how to keep things working. To help manage time, you have implemented universal standards and tried to funnel requests to architecture review boards or other planned meetings. Developers routinely work around the system, complaining that process holds them back, but you know that these things are there for the good of the company so you reinforce the policy to try to keep control.

Kevin Hickey

This is a good general description of several EA groups I’ve worked with in past companies. The EA is often far away from the day to day of development and looks to keep control by implementing layers of controls. Not much different then change control boards that attempt to stop change by adding a meeting/paperwork tax to any request. This is where so many EAs fail to add any value and end up becoming another impediment to producing working software. I hope this is changing as Agile has moved to the mainstream, but I fear it is not the case.

Why No One Wants To Grow Up to Be an Enterprise Architect

I recently attended a meetup for Enterprise Architects. I had to deal with the EA world years ago when I was reorganized into managing a brand new Enterprise Architecture Department. I remember trying to make the best of it and even being hopeful that EA and Agile could be combined. I only stayed in the position about 9 months before moving onto another Application Development Manager at a new company.

I ended up leaving the meetup quite early after the discussion veered heavily into consulting, no one listening to the EAs, enterprise data models, and governance. When the topic of coding was brought up the consensus was EAs don’t code. At that point I realized I was in an alien environment and it was time to exit.

Architects and Enterprise Architects are widely disliked by many developers. The reasons are numerous:

  • Enterprise Architects are often very siloed and rarely interact with the rest of the developers.
  • EAs sometimes take pride in statement’s about not coding, but insist on choosing development tools and platforms for the organization.
  • Governance is used as a stick to force developers to only use approved technologies
  • Documentation and EA Frameworks are valued over making progress on solutions.

Having transitioned back to software based companies I can’t see ever stepping back into a company that actually has an EA department.

Continuous Integration and Enterprise Architecture Governance

Continuous Integration can be a great place to do governance. With good reason developers get the shakes when someone mentions we need more governance. Past history has taught them governance often means someone above them says no.

Continuous integration allows you to inject good development practices and ensure some governance without having to always be the bad cop. Let the build box be the bad cop.

If you’re a Java or .NET shop you can add all sorts of checkpoints to the build and tell at a glance where projects are at and dig into the details. The sorts of things you can do include:

  • Requiring every active project have a build script and be setup on the build box.
  • The code must checkout completely and compile successfully.
  • There must be tests and all tests must pass.
  • Unit test coverage must meet a target number or the build fails. (We use 70% currently)
  • Coding conventions must be followed or the build fails if you have more than say 20 violations. We use Checkstyle to enforce this.
  • The code passes the CRAP metric.
  • The code passes other static analysis checks like Findbugs or PMD.
  • Package dependency analysis using thing like JDepend.
  • Security static analyzers to prove code meets security standards. (I haven’t tried any of these yet.)

All of these steps help you promote good practices, ensure transparency, and give you governance over day to day coding instead of just a review or two at the beginning and end of a project.

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.