Skip to main content Skip to Footer


August 17, 2016
Abstraction is not obsoletion—abstraction is survival
By: Mark Rendell

Successfully delivering enterprise IT is a complicated, probably even complex problem. What’s surprising, is that as an industry, many of us are still comfortable accepting so much of the problem as our own to manage.

Let’s consider a very simplified and arguably imprecise view of the “full stack”:

  • Physical electrical characteristics of materials (e.g. copper / p-type silicon, …)

  • Electronic components (resistor, capacitor, transistor)

  • Integrated circuits

  • CPUs and storage

  • Hardware devices

  • Operating systems

  • Assembly language

  • Modern software languages

  • Middleware software

  • Business software systems

  • Business logic

When you examine this view, hopefully (irrespective of what you think about what’s included or missing and the order) it is clear that when we do “IT” we are already extremely comfortable being abstracted from detail. We are already fully ready to use things which we do not and may never understand. When we build an eCommerce platform, an ERP or CRM system, little thought is given to electronic components for example.

My challenge to the industry as a whole is to recognize more openly the immense benefit of abstraction[1] for which we are already entirely dependent and to embrace it even more urgently!

Here is my thinking:

  • Electrons are hard—we take them for granted.

  • Integrated circuits are hard—so we take them for granted.

  • Hardware devices (servers for example) are hard—so why are so many enterprises still buying and managing them?

  • The software that it takes to make servers useful for hosting an application is hard—so why are we still doing this by default?

For solutions that still involve writing code, the most extreme example of abstraction I’ve experienced so far is the Lambda service from AWS. Some seem to have started calling such things serverless computing.

With Lambda you write your software functions and upload them ready for AWS to run for you. Then you configure the triggering event that would cause your function to run. Then you sit back and pay for the privilege while enjoying the benefits. Obviously, if the benefits outweigh the cost for the service, you are making money.

Let’s take a mobile example. Anyone with enough time and dedication can sit at home on a laptop and start writing mobile applications. If they write it as a purely standalone, offline application and charge a small fee for it, theoretically, they can make enough money to retire on. But in practice most applications (even if they just rely on application adverts) require network-enabled services. But for this our application developer still doesn’t need to spell server, they just need to use the API of the online add company, e.g., Adwords, and their application will start generating advertising revenue. Next perhaps the application relies on persisting data off the device or notifications to be pushed to it. The developer still only needs to use another API to do this, for example, Parse can provide that to you all as a programming service. You just use the software development kit and are completely abstracted from servers.

So why are so many enterprises still exposing themselves to so much of the “full stack” above? I wonder how much inertia there was to integrated circuits in the 1950s and how many people argued against abstraction from transistors.

To survive is to embrace abstraction!

[1] Abstraction in a general computer science sense not a mathematical one (as used by Joel Spolsky in his excellent Law of Leaky Abstractions blog.)

Popular Tags

    More blogs on this topic



        COMMENTS (0)




        Your Data Privacy

        By providing your e-mail address, you agree to the terms
        outlined in our privacy statement associated with
        commenting on the site. Your e-mail address will not be
        used for promotional marketing purposes.

        Change the CAPTCHA codeSpeak the CAPTCHA code