Skip to Content

Timeless Software: Part 3

The Timeless Software Evolution of Our Products

We’ve seen in the previous two blogs how the dynamics of change lead to the evolution of content, containers, and the evolution in the way change itself is managed. The illustration below shows how our systems will evolve and adapt to new consumers, new technologies, even new languages, how it will be provisioned for a run-time architecture that can optimize across network, state, and processing, and how unified lifecycle management provides a secure foundation for executing change and adopting to new requirements.

Our portfolio of products will continually evolve along these principles.  As the picture above illustrates, we will continue to enhance our massive yet coherent breadth of functionality, to reflect ever increasing business activities across industries, geographies, and roles.  This functionality will be built using an evolving programming model, often in languages that have not yet been invented.  And will be deployed in new ways, in the cloud, as appliances, on-premise, and all of the above.  This functionality will be exposed for wide varieties of consumption, across consumers, business user workplaces, and devices, rendered via our client-side technologies or those of others.  Even technologies that have yet to be invented.  Enterprise SOA was just the beginning of enabling such decoupling, for process-flexibility.  There will be much more.  And yet all of this functionality will be under the same lifecycle frame, the backbone that will support the constant evolution, and constant optimization of our landscape at our customers.  Our products will therefore reflect these principles.  We will continually carve new lanes, and deliver new functionality, even deep new technologies.  The applications will evolve continuously, and piecewise, as nature does: bringing new things, renovating others, adding here and retiring there, and doing so without breaking its essential qualities: reliability, integrity, integration, seamless administration, change and lifecycle management.  Just as every few years we humans shed most of our cells, acquire new memories and lessons, decisions and beliefs, evolve and yet stay essentially who we are, I believe it is possible for software to renovate itself completely, and yet continuously.

So as excited as I am looking ahead to innovations on the horizon and beyond, that there is tons of new technologies, new capabilities, and new functionality to be delivered in our software, it is perhaps most reassuring that none of these will break the essential promises at the heart of timelessness, of reliability, integrity, coherence and continuous evolution.

On that reassuring thought, it is time to press the bed button on my seat and try out the fancy new lie-flat bed to end a day that began already 3 time zones away, 20 hours ago.  And as I browse thru the 80 movies onboard, and notice the flight monitor displaying the plane’s airspeed of 567 miles/hr, things that passengers 40 years ago couldn’t have imagined, I find myself thankful for being in the comfort of a well engineered timeless system.

Download the entire article, “Timeless Software”(PDF 155 KB)

You must be Logged on to comment or reply to a post.
  • Vishal:

    I greatly enjoyed reading your blog series; it is wonderful to get insights into the strategic direction of our partners. I only wish my first SDN blogs had the level of coherency that yours do! I’ve been through them twice, and plan to read them again, as well as sharing within my company.
    As you invited feedback, here are four topics that struck me.

    1. “domain specific languages”
      Defining the term “domain” could be another blog, or series, delving into the evolution of Java, ABAP, Ruby and other languages that are key to SAP software access. I think a term such as “dialect” could be used to differentiate different generations of software compatibility, as newer constructs can’t be used in older installs, while previously acceptable means of communication become deprecated, like the stilted speech of old-timers like myself.
    2. You use the term “runtimes” in the context of application software delivery, as I understand you. I’m not sure if you mean the time it takes to deploy code (like the transport path), or if you mean the time it takes to get code out of developers hands into customers (ramp up projects and release cycles). When I use the term “runtime” in my office, I’m talking about how long a process takes to complete. Improving that speed gives time back to business users. They are also inconvenienced by down times for patches, but on a day-to-day basis, making systems respond quicker matters more.
    3. I’d not seen the phrase “firelaning” before, and in fact, as of this morning, your blog was one of only 3 Google hits; the other 2 referred to actual fire prevention practices. In a former career, I visited scrap tire dumps where fire lanes had been constructed. While this may have helped potential fire fighters, the reality was that it was still a huge pile of waste, just divided into more, smaller piles. I’d submit that the legacy practices of cluster tables, long raw data formats, and similar expediencies of the past have been paved over, or shunted aside, as developers work on more interesting projects. Like rebuilding the infrastructure of water supplies, wastewater disposal, and reengineering our power generation and delivery systems, fixing these underlying instabilities are monumental tasks that can’t be swept under the carpet. But bully for you in bringing this up! I look forward to a huge spike of Google hits for firelaning presently.
    4. “Enterprise support” was a bit of a tossaway near the end of your blog. If we could really “enable[s] a business to lifecycle manage system landscape across their entire business from one console” I’d be thrilled. Being at the pointy end of the stick, rather than at the (literal or figurative) 50,000 foot level, I look forward to improved visibility to all of our business processes, but as a realist, I won’t promise my management that I can deliver a world view on a silver platter.

    Lastly, here are links to the blogs in your series, so readers can more quickly find them.
    Timeless Software: Part 1
    Timeless Software: Part 2
    Timeless Software: Part 3


  • Hi Vishal,

    How do you address the problem of size. Program increase in size every year. Our developments systems are great in adding new program code to it, but fail to delete outdated (old) code. So the repositories grows bigger and bigger  The same applies to databases, the getting bigger and bigger  There are tables in the ERP database, which are never referenced. The programs that used these tables are obsolete many years ago, made by programmers who retired years ago.
    There is a very good reason to keep programs small. The bigger the programs, the more lines of code, the greater  change on errors lines

    Kind regards, Edwin Slee