On Timeless Software

Sitting in Australia, I often wonder what it would be like to attend some of the key ICT events that occur in Europe or the US. At some point I’m sure that I’ll attend some in person. In the meantime, I gain great insight through reading blog entries from leading analysts like James Governor of Redmonk. His recent blog entry – "On Timeless Software: Pace Layering and the SAP Software Architecture" intrigued me on three fronts:

  • Pace Layering – an interesting concept that appears to have been introduced by Stewart Brand (he of Whole Earth Catalog and Long Now fame) in a seminal presentation at IA2003 (this is from James’s blog entry) and is now being applied in context of the software world;
  • Timeless Architecture – to me, this is the real area of abstraction that is timeless, not manifested software programs; and
  • Commoditisation – this key point seemed to be missing in James’ discussion.

Let me explain each in more detail.

Pace Layering

This is an extremely interesting notion, showing that different areas of abstraction progress with change at different rates. It’s the first time I’ve come across it. In a building scenario, the analogy really is that the foundations are built to last the tyranny of time, but the fixtures may last just for the life of the current tenant.

In a software scenario, different layers of the architecture manifested in a particular programming language evolve at different rates. That is to say the expectations of the presentation tier evolution by end users are more rapid then other tiers such as core transactions related to the production say of Management Accounts reporting.

In particular myself, I’ve tended to not work on core transactions that have been solid in a business for a number of years. For me if a transaction is supplied by SAP, then all likelihood it is not something that is going to give the organisation that I’m working for any real long term advantage over its competitors. The areas, that I’ve worked on, and for that matter the majority of where my associates have is in the those areas where custom software development is warranted to give a competitive advantage or to meet other unique organisations requirements or constraints.

Timeless Architecture

People see a good timeless architecture, in software through the experience they have. Its this notion of the Software Architecture that can be manifested over time in many evolutions that meet the intent of the architecture. Over time as the capability of technology matures, the design and implementation decisions that may have constrained that architecture are also altered to allow potential that may now have more Pace.

However, the cost to implement a new manifestation of the said timeless architecture may be prohibitive in comparison to the advantages gained. Its always a trade off decision, and its the internal struggle that a gifted support programmer is fighting – do I alter the existing or re implement. I know in my early years as a programmer, I was constantly told, not to rewrite programs. In the end I realised it was easier to rewrite a fair majority of them, but keep the name the same (my boss at the time was none the wiser).

The pattern I’m seeing now, is the mechanism to ensure this Timeless Architecture, is to have clearly defined interfaces, at the correct level of granularity, that act as contracts for others to engage with. Where ever there are these contracts it defines the point that controls the rate of change or indeed potentially a pace layer if they are logically grouped at the boundary of a tier, with similar granularity.


Yet, the key point for me, is that the output from a large number of these transactions in a SAP manisfested implementation do not offer a significant advantage for one company over another. That is, they have become a commoditised component, where the defining characteristic is price and how quickly can it be implemented.

A new term I heard regarding SAP the other day, was Suck All Profits. From my perspective, this is going to be the key driver for SAP, how to get the price point down, whilst allowing the other faster moving layers to access the commoditised components in the architecture securely and effectively.

By freeing up budget, it will allow more focus on innovation that differentiates the organisation to allow them to gain a competitive advantage for a period of time over their competitors.


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