7 Principles To Enable Agile Projects Through Enterprise Architecture

January 21, 2014

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 the 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, it 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 a 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 if 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). It is important for these to be met as they can build trust with the customers. If a strategic technology choice has to be made, customers must 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.

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. EA should 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. Companies make the software easy to understand and allow customers to trial their technology. For example, EA could offer a preconfigured VM on the same day as they ask. They 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. However, with innovation comes risk. This might include: smaller projects which can be easily redeveloped upon failure; projects with talented staff who can deal with unknowns or projects without hard deadlines.

Risks can be both embraced and conquered by proactively planning for them. This could be done by identifying areas in which risks can be taken and innovations can be trialled. The principle of fail-fast applies here. The application of this principle will ensure that risky projects are monitored and stopped if the experiment failed.

As previously stated, innovation is key to an organisations performance. Therefore, it is important to avoid punishing 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 it is like to be a customer of EA and an 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.

Image by Paul Downey under CC-BY 2.0