Agile Delivery is not the answer for an Agile Business. Here’s How.

First, let me set the stage correctly. This might sound like I am an anti-agile architect having a rant, but I am not – far from it. I am a fan of agile delivery when done properly and when the delivery model fits the solution it’s trying to deliver. In fact, we develop our solution architecture management and governance product (SAM)completely in an agile delivery model and it works great. So, this is not one of those ‘agile is not working’ posts.

The days of setting the 3 to 5 year business plan and executing the supporting technology strategy seems long gone. Market changes, disruptors and political changes (especially here in Australia where we seem to change PM’s every sprint) force businesses to change direction rapidly. Most organisations have responded to this need by having agile technology delivery capabilities as a primary mechanism. Some organisations have even gone further and converted all their delivery capabilities into agile. This approach works to a point, (depending on the maturity of the organisation) as large, multi-year projects deliver business capabilities in iterations much earlier. However, does agile delivery provide us the complete technology agility crucial for a modern day business?

A true reflection of business agility is not how fast you can deliver something, it is how fast your business can change direction.

A good analogy to this is today’s Formula 1 car. They have tremendous speed, but the fastest straight-line speed does not win the Grand Prix. The downforce from the aerodynamics, clever push-rod suspension, sticky tires, smart locking differentials and a raft of other technologies are leveraged to ensure the car can change direction extremely fast. The car was designed ground up to be able to change direction fast. This applies to how we should construct our technology landscapes.

In order to truly provide the technology landscape to support an agile business, it has to be architected for agility or else the agile delivery will run into its limits. An all agile delivery arm along with an architecture not designed for agility can easily turn the technology landscape into a collection of rapidly developed point solutions. The end result would be a complex and messy ecosystem that will eventually become slower and harder to change.

There are many considerations in creating the right architecture foundation for business agility, but here are three key points to remember:

1. Use an integration layer to isolate logical business function

Using an integration layer allows you to decouple and isolate the IT landscape into logical functions. This enables you to replace or change capabilities fast in a more plug and play manner. Many companies still see integration solutions as a data plumbing mechanism, however, using it to shield and isolate business functions allow the best agility to replace or upgrade a business capability. The decoupling also supports you to apply the right delivery models (agile or otherwise) to ensure the best outcome for the business.

2. Be smart when buying into a vendor’s ecosystem

I have seen many companies fully embracing technology vendor platforms and implementing all or a major part of the business capabilities on one vendor platform. Vendors make this very easy and the agile delivery model allows you to quickly build capabilities into the platform. As a result of this, businesses can easily get locked into the vendors technology roadmap. In extreme cases, the business strategy is solely reliant or even at the mercy of the vendors’ capability. Some vendor platforms are also closed ecosystems where it doesn’t allow or play well with competing products. This again would limit you from adopting new and upcoming technologies to drive business benefits. Therefore, it is crucial that you maintain control of your technology landscape without being dictated to by the vendor.

(credit Dilbert http://dilbert.com/strip/1995-12-08)

3. Understanding when to develop the solution vs purchasing it

Choosing when to develop a solution versus purchasing a commercial off the shelf product to address a business need has to be done carefully. Especially in agile environments, developing a solution from scratch seems to become a default position. This should only be used where appropriate and there is a valid use case for it. Any newly developed software has to go through its maturity curve and sometimes this can take a lot longer than the development sprints would suggest. In some cases, purchasing a product or service where a vendor has matured over time, may deliver the required business capabilities faster. When the decision has been made to develop a solution, it is also important to make sure the right open and widely used technologies are leveraged to ensure future development time and efforts are minimised.

The three points above should get you heading in the right direction, though keep in mind there is no architecture perfection. You have to consider many other business specific factors to make sure you understand the business implications and make informed architecture decisions. It is also equally important you have the right tools and processes in place for proper architecture governance to ensure the agile architecture thinking is upheld. My recommendation is including agility specific architecture principles as part of the governance model. This would then help architects keep business agility high in their list of considerations.

In summary, agile delivery is an extremely valuable delivery option that provides great business benefits. However, it is more important to architect and govern your technology landscape to be agile first. This would then allow you to leverage agile or other delivery models where it makes sense to truly achieve an agile technology landscape and transform into an agile ready business.