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.
As pixelcharmer puts it
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?
Brand photo credit to curious lee