During
SAP Virtualization and Cloud Week 2011, prompted particularly by the session “TRND20 - SAP Virtual Landscape Management and Virtual Appliance Factory (VLM / VAF)”,
Chris Kernaghan and I had a lengthy discussion via Twitter about the pros and cons of automating the building of SAP systems and landscapes. I’ve captured the Twitter debate
here, for posterity:-) The correct thing to do after that was to continue the discussion in the bar over a beer or three. Sadly, While Chris was in Palo Alto for the conference I was watching from the comfort of my own lounge in the UK so a discussion in person was not possible.
Chris has since written up his take on the issues
Automation or Abdication - #DevOps Series. If you haven’t already, please go and read that first. It is an excellent summary and I agree with everything Chris has said. He is right to be worried about where these new technologies are leading us. “Here be Dragons”, as they used to say on the unexplored sections of old maps. However, there is at least one area of technology where similar techniques have been used successfully. More than that, they have been used to allow us to do things that would be impractical or impossible otherwise. That is the field of programming (or development, if you prefer).
The CPUs in all computers only understand 1s and 0s. In the good old days computer programs had to be written in those same 1s and 0s. Before long people realised that writing programs that way was hard work and designed programming languages that were more understandable to humans. That way we got Fortran, Algol, Pascal, BASIC, C, C++, Java, ABAP and so many more. Writing large software systems is these languages is still a difficult task, but it is at least possible. Can you imagine writing something like R/3 in binary or assembler? Can you imagine having to maintain it afterwards? Assembler is often called a write-only language, and for good reason!
These programming languages provide a level of abstraction from the underlying hardware (or sometimes two levels - both ABAP and Java run in a virtual machine which is itself a program written in another programming language). This level of abstraction hides many details of the operation of the CPU itself. Not having to worry about those details makes the code simpler. Sometimes, though, programs in high-level languages can have lower performance than you’d expect and at that point you need somebody who understands the low level details to figure out what’s going on. Most programmers don’t need to know those details, but some do.
The layers of abstraction don’t stop there, though. Most programming languages come with libraries of standard functions. Things that many or most programmers would need for most tasks, so they are written once to avoid everyone having to build them themselves. Then there are libraries that provide specialist functions that are hard to get right, or are hard to make efficient. Library writers can put a lot of work into these libraries so that most programmers don’t have to think about them. UI toolkits are a good example of libraries that need specialist knowledge to write. Many programmers, me included, are not UI experts. UI design is hard. Really hard. But using a well designed UI toolkit all programmers can produce nice looking, easy to use applications with next to no UI knowledge.
These libraries are absolutely not a silver bullet. Sometimes they don’t work the way you’d expect. Either the functionality is wrong, or the performance is bad, and you need somebody with a deep understanding of the various libraries in use to figure out what’s going wrong. Even if everything is working as it should, each of these layers of abstraction adds extra overhead. Today we tend to have enough CPU power at our disposal to not worry about the inefficiencies of the abstraction layers, but they are there and can come back to bite us. Java’s garbage collection is a good example of this.
In summary, then, in the world of the developer there are many layers of abstraction protecting the programmer from needing knowledge of the low level hardware on which their code runs. These layers of abstraction need to be designed carefully - compiler writers and library designers are a special breed - or things can go badly wrong, or slowly, or both. When done well, though, they enable programmers to achieve many things that would be impossible without them. Specialists are still needed, but not all programmers need to be specialists in everything.
This is the model that I had in mind as I looked excitedly at the presentation about the Virtual Landscape Manager and the Virtual Appliance Factory. I’ve done SAP system installs, debugged them, tuned them. But I’m actually more excited by higher level issues these days. If somebody more expert than I is prepared to build template systems I can just deploy, I’m happy to let them. I just don’t find sapinst that exciting any more:-) I can concentrate on mapping business processes to system components safe in the knowledge that those components have been configured carefully and properly. Sure there are dangers here, just as in the developer context. The templates will be designed with particular usages in mind and I need to make sure I use them appropriately. If not, I may hit problems.
What does this mean for the SAP NetWeaver/Basis role? This I haven’t really thought through yet. We are just at the start of this journey - we’re designing Fortran not C++ or Java. We’re a long way from having templates that customers can deploy without help and advice, especially for production environments. But we seem to be moving that way and I can see huge benefits from it. The roles of technical people inside SAP, in partners and at customers will change as the technology is developed. We shouldn’t be scared by this, but clearly the most important thing is the robustness and reliability of the systems we deploy to support our businesses and we shouldn’t do anything to jeopardise that. There’s a careful path to tread, but tread it we should. I'm excited by it, even if I think there are many years of work left...
