7 principles to enable Agile Projects through Enterprise Architecture

Most enterprises will now have experimented with Agile projects. Many projects are a great success and some fail to live up to the limitless hyperbole of Agile. One of observations I have made when working in several enterprises is that the fit between Agile projects and more established Enterprise Architecture function is not fully defined and, in many cases, is mismatched. People want to give Agile projects a chance to succeed, but also want to retain the governance, strategic and dependency management of Enterprise Architecture.

Let’s just back up an minute. What do I mean by Enterprise Architecture? Let’s start by stating some characteristics of enterprises that rely on software systems:

  • Many organisations have the need to develop multiple software systems across multiple teams.
  • Typically each software system will have a lifecycle, from inception through to decommissioning.
  • Within an enterprise, a continuous stream of systems will appear and disappear.
  • Many of these systems will have inter-dependencies.

The strategy, governance and co-ordination of this changing landscape is often referred to as Enterprise Architecture.

At this point you might be wondering there is a way to join Agile projects with EA in perfect harmony. If there is, I haven’t discovered it. What I can offer you is some principles, based upon what has worked in organisations that I have worked with.

  1. Understand that EA has customers. The goal of EA is to make the delivery and support of software systems more predictable, faster and more efficient for business stakeholders and project teams. Looking at EA as an enabler for the business opens you up to looking at it from the customers’ point of view. Customers have needs that can be easily identified. For example, customers will expect each EA function to have a Service Level Agreement (SLA). If a strategic technology choice has to be made, determine how long is reasonable to make the decision. If customers don’t trust the ability of EA to meet reasonable deadlines, necessity will force them over to the dark side – tactical solutions. Meeting SLAs builds trust.
  2. Use the carrot before the stick. Governance is a critical function of EA, but remember that EA should first and foremost be providing guidance and enablement to project teams. Help them to understand and interact with the wider landscape in the most efficient manner. If EA has a preferred technology for project teams to use, that choice should be the easiest and quickest solution for the team. Relating this back to viewing project teams as a customer, we can look how companies sell software. They make it easy to understand and trial their technology. EA could offer a preconfigured VM on the same day as they ask. Offer expertise, template configurations, and tried and tested deployment patterns. In commercial software, a customer reference is a powerful tool. With the enterprise, EA can ofter to introduce the project team to another project that has used the proposed technology. The project team should see the EA’s preferred solution as the carrot, not the stick.
  3. Understand that systems evolve unpredictably. Software development practice and technologies rapidly compared to most industries. Trying to design a system that will be still running a decade from now is difficult. I use what I call ‘Trigger’s Principle’ to enable this. It derived from a plot line in Only Fools and Horses, when a character, Trigger, wins an award for owning the same broom for 20 years. He reveals that it has had 17 new heads and 14 new handles, but insists it is still the same broom. Those of you who are more high-brow might want to look at Theseus’s paradox. What this means for EA is that the primary focus should not be on what technology might still exist 15 years from now, but how EA can design governance processes and de-coupled modular systems that enable incremental change.
  4. Make a plan for innovation. Innovation is essential for organisations to remain efficient, but with innovation comes risk. Embrace and conquer these risks by proactively planning for them. This might entail identifying areas in which risks can be taken and innovations trialled. This might include: smaller projects which can be easily redeveloped upon failure; projects with talented staff who can deal with unknowns; projects without hard deadlines. The principle of fail-fast applies here – ensure that risky projects are monitored and stopped if the experiment failed. Don’t punish the teams for failure if failure was a consequence of the innovation rather than poor execution. Punishing people will guarantee no further innovation happens, and this is not healthy. Ensure that lessons are learned even upon failure.
  5. Aim for the minimum red tape that is required to run the organisation. Control is important, but ensure that the control processes are sufficiently easy to understand and use. It is very easy to develop ever-growing processes, documentation and sets of rules. Remember that “Perfection [in design] is achieved not when there is nothing more to add, but rather when there is nothing more to take away” - Antoine de Saint Exupéry.
  6. Architect is a role, not a person. Try to keep a balance between people who are hands-on and those who paint with broad brush strokes. Rotating people between project roles and EA roles gives people an understanding what is is like to be a customer of EA and a EA provider. Remember that the higher the ivory tower you build, the further it is to fall back down to grass roots development. This might be a challenge for some larger organisations, but rotating roles should be encouraged. Shared understanding builds bridges.
  7. Inform wider decision-making by doing. When faced with nebulous or tough requirements, take the thin end of the wedge and drive it hard into the problem. Get hands-on. This can be through the use of Spikes, Hackathons and Proof of Concepts. You might not crack the problem within these time-boxed activities, but you will find out a lot about the problem. This information can inform planning, estimation and longer term strategy.

I hope these seven points help. I would love to hear other lightweight principles that can guide organisations towards harmony between Agile and EA.

Footnote: a sad co-incidence is that Roger Lloyd Pack who played Trigger in Only Fools and Horses died last Friday. RIP.

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>