The theme that spoke to me most directly during SAP CEO Leo Apotheker’s keynote on Tuesday morning at TechEd 2008 was a new concept he introduced called 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. Arguably it was Shai Agassi’s failure to truly understand this dynamic which led to his departure from the firm.

Leo Apotheker is the first SAP CEO to come from a sales rather than an development background, which may explain the profoundly pragmatic notion at the heart of timeless software. For “adaptive user interfaces” read “insert other people’s stuff here”. For “semantic layer” read “we know you’re not going to buy every application from us but we’ll do our best to help you manage Oracle-based data models too.”

Why did the notion of timeless software strike me so clearly? Because its an issue I have spent time thinking pretty deeply about. In a seminal presentation at IA2003 Stewart Brand (he of Whole Earth Catalog and Long Now fame) introduced the notion of pace layering. Some of the core concepts were based on building and architecture and then applied to issues such as governance and fashion aspects of getting things done but they are tremendously relevant to software too.

The location was there long before the building itself, and will remain there long after our cities are so much dust. The foundations of a building are built to last a couple of hundred years. At the other extreme – the internal walls may change every 20 years or so – from rigidly structured personal offices to open plan and back again.

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.

Don’t embed services in structure, otherwise you have to tear the house down to fix them when they break. A design welcomes change or fights it.”

So why insist that ABAP or any other programming language is the only language in which to build software? Not invented here is a luxury that few if any software companies can afford, which is why its good to see SAP investing in dynamic scripting languages such as PHP and Ruby On Rails, cajoled by change agents such as the inestimable Craig Cmehil.

The core is mySAP, surrounding that is NetWeaver, the information glue is Business Objects, fast muscle twitch fibre might come from another third party such as ESME.

To ignore software built elsewhere is to be economically hamstrung.

The rise of the Eclipse ecosystem is perhaps the best example of the new economics of the software industry. There are those in the commentariat that argue open source no longer matters in the face of cloud computing. But that is to ignore the fact most cloud providers make extensive use of open source. Is open source a business model? Do bears shit in the woods? I must confess to surprise my colleagues didn’t push back harder recently when asked the business model question recently. Open source changes the economics of our industry – that’s what new business models do. Perhaps it is the success and utter dominance of open source that has closed our eyes to the obvious – the new software industry business model is deeply and profoundly based on co-innovation.

Which brings us back to SAP, which has recently taken to flagging co-innovation as a core element of its strategy. Hang on though- not so fast… Co-innovation and joint engineering only make most sense in the context of open intellectual property, and SAP still has some way to go in this regard. Not invented here is alive and well at SAP, although it is under increasing, pressure.

The recent acquisition of Business Objects didn’t just bring customers, and an end to end information management story – it also introduced a desire for agility and immediate gratification. Business users don’t wait around for vendors to provide the perfect business intelligence support tool- they’ll just buy from someone else. The era of the situational application and the mashup is upon us.

That means pace layering. One of the under-remarked aspects of the mashups is that many them are not bidirectional. Adobe Flex data grids based on information sucked in from Microsoft Excel spreadsheets, for example, are one way. Analysing data is not the same as carrying out a transaction. You may need to roll back a transaction, but not the data the decision was based on.

Adobe plays an intriguing role in the emerging SAP pace layering story. SAP now resells both Flex and LiveCycle (called Forms Lifecycle Manager when sold by SAP). Both Flex and LiveCycle provide the means to create rich forms based applications which are far more responsive for users than the usual SAP UI techniques.

Adobe is particularly notable from an enterprise pace layering perspective because unlike many other technologies that fall under the heading Service Oriented Architecture (SOA), Adobe has focused on delivering service oriented front ends that can be integrated with back end services with a minimum of fuss and code. This is loose coupling – of distributed components.

In a roundtable at TechEd Herve Couterier, a Business Objects alumni, and now the most powerful man in SAP’s product group (he even has responsibility for SAP’s NetWeaver platform) made an interesting observation.

“The industry is becoming more component based. Client adaptation happens faster than with other components. Coming from business objects into SAP,” he said, “we had a different software development culture”.

Indeed – SAP would be well advised to cherish the injection of pace into its portfolio. Layers evolve at different speeds. Some components rarely change, while others may evolve on a daily basis. A one speed SOA is doomed to failure.

I would argue that timeless software is an idea whose time has come: keep the base stable but innovate at the edges. The most successful businesses are those that best manage the balance between unstructured and structured process innovation. What is evolution, after all, if not an exercise in pace layering?

James, I was pleasantly surprised to read your thoughts and to see that you immediately got its significance. 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.

As you observed, we see constant and furious change across all layers of the technology stack: from the fabric of processors, memory and network that grows non-linearly, to the ever accelerating changes that businesses go through, from UI technologies that frequently appear (roughly twice a year) to dazzle end-users, to even programming languages (a major new language shows up every 10 years or so, minor ones more frequently, less time than a mature application lives at a customer), change is the only constant. Timeless Software ensures that we continually bring innovation without disruption. SOA was the first step in doing so, our CRM is showing the way with decoupled UI and mobile experiences on top. BIA is showing elastic data management and more is on the way.”

I absolutely loved your post, and have very similar thoughts about software time scales.

At Software AG, we have the ADABAS database system that is chunking away doing billions of transactions over decades. So the time scales are very important, the issues related to the “Clock of the long now” become relevant including data formatting and standards over these time scales.

But what strikes me about this discussion is exactly what was raised by Vishal.. the amazing architectural construct of evolvability.

when you look at DNA evolution, you see highly conserved regions but areas of high variability as well. Architecturally speaking it’s important to establish evolvability which I would argue is dependent on interface abstraction “cleaving planes”, which tend to bear weight and collapse over time.

So this means you need reliability, scalability, maintanability but you also need to be strategic. This is reminiscent of the relationshp between SOA, the stable platform of reusable services representing the DNA layer and the more “protean” layers of BPM, Business rules, composite applications, user interfaces, EDA, CEP, Web 2.0, Social networking and utilization patterns–but all on the surface without disrupting the fundamental understructure.

Virtualizing the understructure will be a phenomenally transformative aspect, but the key architectural issues relate to “correct abstraction and virtualization” aka what stays the same and what changes, keeping the hot side hot and the cool side cool

Continuing the Discussion

[…] the world of co-innovation (read collaboration) that SAP has been espousing for the last 18 months. As fellow Irregular James Governor said: Co-innovation and joint engineering only make most sense in the context of open intellectual […]

[…] whizzing around the outside and wondering how SAP will square the circle. It’s something James Governor dubs ‘pace layering.’ This year, SAP ‘came out’ on that one with Jim Hagemann Snabe invoking the 15th century […]

[…] business, turning it into a virtue. In contrast it is easy to see how SAP is conflicted with its pace layered approach to software development. Meanwhile, the Enterprise 2.0 mavens throw people into the mix reminding us that it is people who […]

[…] Moving the Giant I would argue that timeless software is an idea whose time has come: keep the base stable but innovate at the edges. The most successful businesses are those that best manage the balance between unstructured and structured process innovation. What is evolution, after all, if not an exercise in pace layering? –James Governor on applying Pace Layering to SAP […]