by Gerrit Simon Kazmaier, Vice President and Head of Engineering, SAP Cloud for Planning
In our last blog, Ivo Bauermann asked me about “Why design isn’t just for designers, but also engineers for whom “Code is law.”
We changed the rules when we designed SAP Cloud for Planning. SAP Cloud for Planning is truly a designed application, and I would like to share with you what that means for us.
Design is not a department. It is culture, behavior, attitude, and a key ingredient for an engineering organization. True design is pervasive in the software development process and the software itself. To design an application means to craft software that is tailored to a specific process, a use case, and eventually, a person. However, classical computer science is having its own technical value propositions such as decoupling, abstraction, independence, generalization, and so on. They are, when applied correctly, powerful concepts. But when overused they lead to suboptimal solutions, poor performance, and just-wired applications.
A very interesting characteristic of design is that it is an emerging property of systems. You cannot track it down to a single piece of an application such as a beautiful logon screen, one well-working function or a nice chart. It is the result, or better the symphony, of every piece in an application working together as a whole. In reverse, you cannot destroy a good design by removing one single part. However, when removing too much from it, good design suddenly vanishes. It’s more than the sum of all parts and only emerges when it’s present in every one of them.
Form and Function Meet in New Generation of Planning in the Cloud
Lawrence Lessing coined this famous term “Code is Law” in an essay on liberty in cyberspace. I found this to be very true for business applications as well. When any programmer writes any line of code it reflects his understanding of the subject matter. It precisely defines the laws of how something executes, how it is called and what results it produces. He becomes the lid of how a piece of software can be used.
Ever wondered why an application behaves so weirdly? During my university days I worked for multiple software companies as a programmer. One experience nicely shows this principle. In an ordering system, the first view for customer data was “change customer.” Weird, right?! I expected the common case would be to create a customer and so I asked the responsible developer and got a perfectly logical answer: “I have one customer record. To test new functions I just alter this one, much easier than to create one from scratch”. Code is law, enforced on every single customer…
When you experience odd behavior, bad scaling or performance, most likely something – maybe you – is just violating the laws of the system. I used to be a programmer, and I still am. This doesn’t happen because we are bad guys secretly teaming up to torture users. It happens unconsciously – lack of domain knowledge, systems context, business development (scale issues). But still code is law.
Melvin Conway introduced the “Conway’s Law “in 1968. He stated “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
Conway’s law nicely states a key flaw in many software systems. People create interfaces and abstractions to decouple themselves and foster independence between groups. Often you find vertical departments or teams for the user interface, application logic, database schemas, and so on. The vast majority has a hard cut at the database because its development is not part of the company that develops the application. Exactly these organization-cuts are reflected in the system architecture and are deeply rooted in the reasoning of engineers. And yet this has nothing to do with the problem they are trying to solve.
In addition, they’re having an extreme separation at the database level which mostly ends up in virtualizing data centric functions on top and (consequentially) inhibiting real optimization and scale. Oddly, they are making this an argument – “It runs on any database.” Good marketing… and just so old school. Why should anyone care in a cloud solution? And how will they ever provide you the best possible performance?
SAP Cloud for Planning – The Differences are Key
So what did we do differently for SAP Cloud for Planning that allowed us to build this beautifully designed application?
For SAP Cloud for Planning, we removed all “cuts”. From the graphical designers to the SAP HANA engineers, we were an intermixed cross functional team that sat side-by-side in one big space that we called our “Engineering War Room.” This enabled us to streamline the whole application without any artificial boundaries. Unlike first generation cloud vendors, we didn’t abstract away from the database. In fact, we optimized for SAP HANA to the fullest and decided to stay “native” wherever possible. All planning operators were developed directly as a first level engine in SAP HANA and as an extension of the general calculation engine. This not only gave us maximum performance but also unlocked the direct usage of all other data engines such as analytics, predictive, search ….you name it.
We embraced design thinking when we developed SAP Cloud for Planning. A methodology to enable us to be conscious about the people using the application, their environment, and ultimately their work. We just visited a large company in China and researched how they work, sat in on their daily work, and talked to them. We created prototypes, validated them and re-iterated. Over and over. Everyone is involved in this: every developer, designer, solution expert and manager to establish one common understanding about how we create the biggest value for our users. We have quite a unique setting – one team that brings in core database developers of SAP HANA (which is one of the most disruptive innovations in data management), application experts, user experience and graphical designers. This is one awesome, creative cocktail. It’s wild and challenging but ultimately yields results that are beyond reach for each single group.
We go native and remove all boundaries throughout the entire software stack to create the most streamlined application that brings true value to our users. And yes, it will have kick-ass performance.
Originally published on SAP Analytics, 27 October 2014. Reprinted with permission.