System Centric Development

In my previous life at SAP, I was first part of the team designing and developing the runtime of the Enterprise Portal product and later I was part of the Java EE Engine (a.k.a. SAP Netweaver/Java) team.

Both systems were initially really simple. Simple in the sense that a runtime developer could typically work on the whole system at once – as far as he or she was concerned at least. It would all fit into one development workspace. If you wanted to test or debug something: No problem. Just check out the whole thing, build it on your machine, and run it.

Life was good.

That changed. Bug reports were coming in for some already (internally) released version. How to find out what was really running on the other side? How to reproduce the bug in your environment? Still you could stretch things somehow. People might allow you to deploy patches and try again. Still somehow manageable. We got used to it.

But then things got more complex. And all the sudden you found yourself not anymore at the more comfortable lower layers but rather sandwiched between some framework you used (that library over here) and users of your code (this complex HR application over there). Add the versioning problem and the mess is complete.

At some point in time setting up a complete environment required some non-trivial installation and tweaking that could easily stop you for half a day. Potentially leading to the devastating outcome that the weekly build of service pack x actually didn’t really have the fix you expected because change list 52304 did not make it into that week’s build. Needless to say that developers rather stayed longer with what they had. Longer than healthy: Integration problems eradicated all deadline fantasies out there.

Was that just lack of discipline? Not really… it was a mix of non-human-manageable complexity and the superhuman forensic instinct required to identify exactly that source code revision made your environment and whose fault it was (in a system of hundreds of components that were last updated at various points in time in various source code repositories with a deep dependency graph). I guess there is a way to set things up so that everything is easily trackable in such complex environments. I doubt that anybody has managed. Not over any significant time. Not with more than a handful of interdependent components that are developed at the same time.

Life was not good anymore.

One day I was working on a Web Service interop and performance test. One side implemented in an ABAP system, the other side implemented on Netweaver/Java.

Something was broken on the ABAP side. Couldn’t get it to work. Called a developer: „Hey, ABC is not working in BYX, any idea why?“, „Hmm.. let’s see… (click, click,…) ah yes, there is that bug XYZ. It’s a trivial fix. Ok. fixed. Can you try again?“. Wow… works!

Something was broken on the Java side. Couldn’t get it to work. Called a developer. „Hey, DEF is not working on my installation. Any idea why?“. „What version do you have?“. „Should be DWI CW34“, „Let’s see… (wait)… I think that bug TFB was fixed in CW42“. „Can you send me a patch?“. „Hmmm…(wait)… you should deploy the latest SDAs (deployables) from here,… but let’s see… they require this and that.. you could try?!“. Well… ok,.. maybe… maybe better not.

That is what System Centric is all about:

Know what is in the system. Be able to modify anything in the system down to the single line level. Allow system-local modification. Be self-contained: Always keep the overall consistency by definition and without dependency on external infrastructure.

In a system centric approach the difference between the source and configuration store vs. the executing runtime is the same as the difference between a blueprint of a house and an actual house. The runtime is nothing more than an actual instance of the system exactly as described and configured in the system’s repository. When looking at the repository you would say “this is the system”, just as when looking at the blueprint of a house you would say “this is the house”. We like to say The source is the system.

Contrast that with a server that is build of a mix of binary components pulled from many different places cobbled together with a number of deployed applications from even more indefinite sources. Phew…

Want more? Go here:

7 thoughts on “System Centric Development

  1. Henning is totally right with regard to what he says about the difference between systems like SAP ABAP and e.g. Java. I would even like to extend this comparism to scripting and non scripting environments. In scripting the source IS the application. At any point in time wherever you face a problem in the running system just go to THE SOURCE and find exactly what is running. Not so with compiled systems like Java … here you have to find the source before you can start finding the bug. And dealing with libs and components from others the source is not even yours.
    Pure darkness. Whatever brings some light into this darkness is a gift. z2 is one of those gifts.


  2. Pingback: Map Reduce Applications w/ z2 – Part 1 | z the world

  3. Pingback: Map Reduce Applications with z2 – Part 1 | z the world

  4. Pingback: ERP People get it | z the world

  5. Pingback: Maven may not solve the problem you thought it solves…. | z the world

  6. Pingback: On integratedness or the math of updates | z the world

Comments are closed.