Agile development and Enterprise Architecture practice – Can they coexist


Your reaction to the title is probably one of the following:

  1. Why should it be a challenge?
  2. Co-existence would be impossible.
  3. There will be difficulties but it can be done.

Why should this be a challenge?

After all, EA is agnostic to software development methodologies. Irrespective of which EA definition is accepted, no direct link with any software development methodology exists. Therefore, you would argue, that there would be no conflict between any Enterprise Architecture practice and adoption of agile development methodology. (If you want a quick premier on what EA is then have a look at: A Comparison of the Top Four Enterprise-Architecture Methodologies).

If you are thinking along these lines then I think most Enterprise Architects will agree with you.

Co-existence would be impossible

EA and Agile comes from different mindset and different world view. The challenge of co-existence is nicely captured by Dave Nicolette. This is what he has to say about it (see this):

“…the mission, scope, tools, mentality, culture, and personality types of enterprise architects and agilists are so radically different …. 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 …”

In EA you start with a business goal and from the goal work out what needs to change (people, process, technology, application, data …). As the next step you spell out in complete detail, how the changed scenario will look like. This is to be followed by an implementation plan, execution of the plan and proper governance. The approach is top-down, structured and planned.

In Agile, though you have a business goal in sight, the approach is always evolutionary. You take one step at a time, delivering working solution and reorienting you plan as learning from that step. You create the environment for the team and empower them so that they can self-organize and be more productive.

If this was your answer then most agilists will agree with you.

There will be difficulties but it can be done

Since there happens to be a common ground – both EA and Agile believes that delivering business value is the key – it should be possible for them to co-exist. Not only can they co-exist, they can also complement each other. It is explained succinctly by Ronald van Luttikhuizen (see this):

“…enterprise architecture (top-down), works toward a long-range vision … (agile – bottom-up) addresses questions coming out of projects right now – questions that should be answered quickly … but if either the top-down or bottom-up architecture is missing, you’re not going to end up in the situation you want…”

As stated earlier, in EA you always start with a future business scenario work out what you need to do to achieve that. Similarly, the first two of the 12 principles of Agile Manifesto talks about “…delivery of valuable software…” and “…the customer’s competitive advantage…”.

If you are thinking like this then you are in the august company of Scot Ambler who is the Chief Methodologist for Agile and Lean within IBM Rational. Here is what he has to say (see this for detail)

“…when project teams work under the assumption that they can do anything that they want … chaos typically results … although each individual project may be very successful, as a portfolio they may have serious challenges…”

Now let me add a variant to this thought. I am sure I will invite the wrath of both enterprise architect community as well as the agile community for saying this but I think both EA and Agile have a UTOPIAN world view. In the real world you have to find a middle ground.

Neither emergence nor up-front design can be the right answer to all problems. A middle ground, a HYBRID approach is what is needed.

Imposed structure may be right in some situation; self-organizing team may perform better in other. It is important to be ADAPTABLE so that you can judge which way is better for a given team.

I am sure if you are a realist who understands the dynamics of a large enterprise, you will agree with me.

About these ads
Comments
3 Responses to “Agile development and Enterprise Architecture practice – Can they coexist”
  1. Fabrice Le Doeuff says:

    I agree with Dave Agility and EA is compatible. Problem i see is that EA arrive too late on process and not delivered Target architecture on good timeframe, then Agility will be a problem when EA onboard in a agility project and delivre target on the project. Good way for that : having a good target , make a high road map of project on it , update road map and target one time / year. After Application Team make agility on the respect of target , probably make tactical step to arrive step by step on the target but communicate with business owner. On the other hand if you make project without agility and wait perfect target it will be probably too late for business requirement and strategy when you built it :-)

  2. Dave Nicolette says:

    Udayan,

    I don’t think the difficulties are inevitable. First, a bit of clarification. The quote of mine you cite had to do with the way in which management treats employees; it was not about any intrinsic differences between EA work and application work. Central IT functions such as EA, security, SOA development, data architecture, etc. tend to attract certain personality types more than others. At the same time, business application development and COTS customization in the direct service of a line of business tends to attract a different set of personality types. When management attempts to treat both types of people in the same way – measuring their performance in the same way, offering the same sorts of rewards as incentives, etc. – they often miss the mark, resulting in dissatisfied employees. In another part of the cited comment, I wrote “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.”

    Another point I intended to make with that comment is that agile methods such as XP or Scrum don’t seem to be a good fit for EA work. That in itself doesn’t mean an EA group has no way to work effectively with agile application teams. I think one of the reasons that very large-scale architectural initiatives fail to bear fruit in many cases is that enterprise architects want to create a “perfect” environment before they allow any application teams to make use of the infrastructure. This results in very long lead times before application teams can make use of new infrastructure capabilities. Some application teams work around the lack of infrastructure support by rolling their own tactical solutions, leading to needless technical complication in the environment. Meanwhile, some EA initiatives fizzle over time because the projects are of such long duration that senior management changes direction or managers move on to other jobs and the projects lose continuity of budget and leadership.

    These are a needless impediments to business agility that can be overcome. To ensure the infrastructure supports the real needs of applications that are going into production in the near term, the EA group can build and deliver functionality incrementally to support the features, APIs, and third-party products that are requested by application delivery projects as those projects are scheduled. To avoid the problem of long-running initiatives breaking down over time, EA groups can decompose their large initiatives into smaller ones that can be delivered independently of one another.

    In a loose sense, this is a sort of “pull” system in which business stakeholders pull features from application delivery teams, and application delivery teams pull infrastructure capabilities from the EA group. Thinking of it in this way, EA work becomes fully compatible with contemporary methods drawn from agile and/or lean thinking without losing any of its traditional value or its traditional engineering rigor.

    The only impediment to adjusting the EA workflow in this way is the mentality of the enterprise architects themselves. There are no technical or intrinsic procedural barriers.

Trackbacks
Check out what others are saying...
  1. […] 7. Agile Development and Enterprise Architecture Practice – Can They Coexist […]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,004 other followers

%d bloggers like this: