Skip to Content

What Is Timeless Software?

After TechEd 2008 in Berlin I wrote a piece called On Timeless Software: Pace Layering and the SAP Software Architecture based on some ideas in CEO Leo Apotheker’s keynote. My intention was to draw out some important concepts when balancing stability and innovation.The post drew a comment from CTO Vishal Sikka, and some additional commentary from Dennis Howlett and Nick Hortovanyi.

What is Timeless Software?

“The idea behind timeless software, as I understand it, is that different parts of the software architecture need to evolve at different speeds – your ERP backbone should be managed somewhat differently from your user interfaces. Some might say this is to state the obvious, but this is SAP we’re talking about- a company that initially thrived by delivering a monolithic architecture but was later pilloried for it.

Customers license SAP software not despite the vendor’s obsession with the kind of over-engineering which makes absolutely everything bullet proof but because of it.”

 Or put even more simply: 

“We use different materials for each of these layers, and apply different skills. You wouldn’t build a cubicle wall out of concrete, after all, or ask a plasterer to install electrical wiring.”

So what did Vishal have to say about what I had written?

“I have indeed coined the phrase timeless software to refer to our strategy of continuously evolving our software. I believe it addresses the fundamental issue of bringing innovation, including deep technical innovation, in a way that is non-disruptive to customers. With the vast breadth that our solutions cover, without breaking coherence, and given our long-lived relationships with our customers, often decades long, this is a central part of our strategy going forward.”

Dennis came at the issue in a post called Might the SAP Mentors inherit the earth? in which he examines whether SAP can really co-onnovate (at pace!) without more open intellectual property models.

“Even if you’re a dyed-in-the-wool engineer from Walldorf  it must surely be obvious that after 36 years, commodity has come to the big ERP players. Commodity in turn means open source but for good reason. Where would we be on the road to so-called cloud computing without the LAMP stack? “

Which takes me to Nick Hortovanyi and his thoughts on pace layering and effective application interfaces:

“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.”

You must be Logged on to comment or reply to a post.
  • James’ statement “as I understand it” should be taken very seriously. The difficulty with expressions of this kind is that they can be read many different ways.

    When I first heard it, I thought to myself: “I know this one” because it is very similar to statements made several years ago by Agresso. I know because I was involved in the early stages of formulating the ‘message’ that goes with it. In their case, they ware talking about notions of ‘agility.’

    In reality, Leo’s statement and James’ interpretation are a logical development. It reminds me of the session both of us attended at SAPPHIRE where the company talked about 2 speed development with the core moving in parallel but more slowly.

    After all, how many times can you re-invent debit and credit? But on the other hand, you can always make the core more robust. Yet at the same time, companies want innovation and that tends to be much faster paced.

    This will present many challenges at both the business and code layers but it is a move in the right direction at the right time.