Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture

Posted by Sadek Drobi on Sep 12, 2008 03:53 PM

Community

Architecture

Topics

Business ,

Enterprise Architecture

Tags

Design Guideline

What is the duration of architectural life span? To which extent this should be taken into consideration? And how may it impact your business? To answer these questions, Dan Pritchett introduces the concept of “architectural shelf life” that he defines as “the duration that a collection of patterns and technology are applicable when starting a new system design”. He believes that architectural shelf life lasts for around 5 years and after two or three generations of it, any architecture has to be changed at least partially. Otherwise, it becomes obsolete and provokes increased costs when it needs to be adapted to business needs evolution. Based on that, Pritchett suggests that “architecture typically has a 10, to at most 15 year useful life”. To support his arguments he provides a series of examples of technology and architecture evolution that have occurred since 1990.

Pritchett argues that failing to update the architecture at the end of its life span may have important implications for business. He acknowledges, though, that making a major architectural shift induces important costs especially when “you have a well established customer base and a overflow of business features in the pipeline”. It can be rather disruptive as it was highlighted by several authors in an opinion exchange about architecture rewrite. However, Pritchett argues that the non-adoption of new patterns and technologies can be ever more costly. They most often help to improve developers’ efficiency and to lower costs of deployment. Renouncing to exploit this potential competitive advantage equals leaving competitors the initiative to do it and this can be fatal for business:

What is missed is that the new patterns and platforms can be used to disrupt your business anyway. If you have a successful business, many others want a share. And technology becomes the tool they can use to go after your business. And the disruption they can cause by offering your services at lower cost or with more compelling features is far greater than any disruption that will be incurred for internal architectural shifts.

In his follow-up to the first article, Pritchett brings some nuances to the inevitability of major architectural shift as new patterns and technologies emerge. Having already said that the life span of architecture depends on its ability to be easily extended to the evolving business needs, he translates it into technical terms as ability “to be refreshed with new technologies in an incremental fashion.” This ability can be increased by “following standard architectural principles of good component design with the loosest possible coupling between components” so that they can be implemented and evolve independently from each other. Based on common mistakes that he could identify, Pritchett extracts some principles to adopt in order to build more long-lasting architecture:

1. Decoupling of interface protocols from an implementation strategy. This increases the “flexibility for migrating components to alternate implementation technologies”. As a way to achieve that, Pritchett suggests building text based interfaces between components, such as for instance XML or JSON.

2. Respecting separation of concerns, even if initial size of the two concerns is rather unequal. This allows avoiding situations when a new feature is added to an existing component and as this feature grows bigger, you end up with two components implemented as one, badly coupled, intertwined and extremely difficult to uncouple especially since “customers have come to expect a behavior that will be hard to maintain if you decouple”.

3. Avoiding unintentional vendor lock which requires deep understanding of the behavior of vendor's products, their impacts on the architecture and its implications.

4. Minimizing persistence binding in order to avoid database lock. Only the primary access path to any entity should be via primary key and all other access paths should be separated in the resource tier so that the alternate paths can be managed in other forms of persistence in the future.

Following these rules to minimize coupling allows building flexible architecture that can rather easily integrate new technologies and patterns, thus reducing the cost of changes and increasing architecture’s life span.

• Older >