Architecting for Delivery

Thanks to Greg Brougham for this interesting article on Architecting for Delivery:

Introduction

The traditional approach to architecture have been aligned with a staged delivery model that allows for requirements gathering, analysis and solutionising. The more iterative approaches to delivery, that are becoming common, give rise to the need to revise this approach. Most organisations look to support iterative delivery models by attempting to address architectural concerns earlier in the delivery cycle so that there is time for solutionising.

The problem that arises with this approach is that there may not be a clear view of what final architecture is needed at that time the initial solution is implemented, as iterative approaches are intended to allow the design to form as part of the interaction between customer and delivery team. This means that the system architecture may not be able to be determined until quite late in the delivery cycle. The other issue that arises is that the architectural aspects of a system, be they application or infrastructure, take time to build. This is typically exacerbated as the focus is on designing the ideal[1] solution and not one that reflects the existing delivery & support capabilities of the organisation or the technology that is available.

The end result is that the final architecture is not reflective of the needs of the project or it adds significant delay or risk to the delivery schedule. What is needed is a more pragmatic approach that reflects what we know and exploits existing technology to avoid adding to schedule and delivery risk.

A Revised Approach

A more suitable approach is one that allows us to evolve and not necessarily design for an unknown future. We still need to understand what direction we are going in; it’s just that we may choose an intermediate goal based on current constraints and the knowledge that we have. As Seneca the Younger said, “If a man does not know what port he is steering for, no wind is favourable to him”. This is both more pragmatic as it reduces delivery risk but also allows us to deliver sooner which is advantageous to the business as a whole.

We can do this by outlining the direction and then engaging in a series of discussions about what could be achieved, what will have most value to the business and what still takes us in the desired direction. What we do is focus on the elements that we can control and avoid the traditional problems of making a large number of assumptions, which may in time turn out to be unrealisable. This also allows us to de-risk delivery as we are relying on current technology used within the organisation.

Where there is a substantiated need for new technology it needs to be taken off the critical path and a proof of concept undertaken (in microstrategy language we are building capability to enable the future). This may be something that can be identified early on and addressed in parallel to the main delivery tasks. What we need to realise is that this is capability building that offers more options in the future and is therefore is not something that should be deferred but something that should be embraced and addressed as part of the project.

The outcome is that we build based on current technology and therefore can be confident of the commitments that we are making. An example would be the use of conventional clustering technology for a database to address availability instead of deploying a version of the database technology that supported horizontal scaling but which there is no current knowledge.  This should be supported by a PoC for the version that offers horizontal scalability to build the capability, which will allow the system to be enhanced in the system in the future when more stringent availability requirements are substantiated.

It should be noted that this is likely to result in more cost as you may rebuild the architecture more than once but this should be more than offset by improved business benefits as the system is delivered earlier. It also accommodates learning as part of the process which means that it can be exploited and not lost. This means that we aren’t reliant on the need to take as many delivery risks because the approach is evolutionary in nature.


[1] This is not to be confused with Ackoff’s Idealised Design for which one of the principles is that the design must be ground in current technology.

Advertisements

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