The last four days in Berlin have been very exciting and I learned a lot. For me the most important things has been networking – and of course chatting with all those great alpha-geeks. I had a great time and great discussion about innovation, agility, ABAP, semantic web and many more. I think I got so much inspiration and even that was worth being there. There is so much to tell, so many blogs to write so let’s get started.
The Future of ABAP and ABAP Applications
Now we could see that ABAP reached the 21st century. The IDE got better, the new “flash islands” are awesome but there is lot more and most of features shipped within enhancement packages at releases 7.01, 7.02 and so on. So the ABAP language guys really did there best.
But what about us? Now we have a modern language and modern IDE, we can expose everything as Web Applications and Web Services – but will this lead automatically to success? I mean no. The reason is that living in a heterogeneous and service oriented world means that we have stable core processes and a good software structure. Like Thorsten explained in his lecture “How to Expose Your ABAP Applications to the World of SOA, Java, and Web 2.0” the definition of services sometimes is to hard because of wrong granularity of our backend applications: functionality is too fine-grained or too monolithic or laden with pre-and post-conditions so that master data or customizing is required or we have unwanted side effects like workflows are started after errors or unwanted data are sent to reporting systems and so on.
I discussed such problem from a different point of view in my ABAP Software Architecture - Modularization and Composition of Huge Applications at SDN Day. I think that it would have been better if I would have made to sessions: at first an introduction into the ABAP package concept and then its applications in business programming. But I promise we didn’t make this mistake within thebook. There’s a whole chapter that explains concepts architecture as well as every detail of the package concept.
The reason for defining packages as well as package interfaces is this is the way to distinguish between “public” and “private” parts of your software. Of course this is crucial for any successful programming (and of course SOA) because you need stable interfaces but you must be able to change implementation details. If within a software component everyone accesses anything it’s difficult to make changes because of unwanted side effects and cost for software support will explode.
ABAP as a Service?
I think the last point just hits the point but, but we have to see this in a more general context. The costs to install, customize and run an ABAP backend are much too high. So the challenge for SAP and the whole SAP ecosystem should be to reduce the costs for running those applications. I know this is a hard task but why shouldn’t do the first steps? Thorsten told it “ABAP as a service” some months ago and I like the term. So every time we design applications we should ask the questions “Are the easy to install, to administrate and to run? Could we even put it in a cloud?”
Of course creating Composites and Flex-Dashboards for administrators and power users is a first step for a better system-administration, but we should try to find best practices, do’s and don’ts for ABAP programming, too.
Demo Jam Review – My Favourites Did not Win
Demo Jam is about innovation. Everything we saw was awesome but my favourites have been ABAP Ninja and ESME – and I will tell you why. Last TechEd we saw a completely new approach to GUI with Widgets and Web 2.0 user interfaces. But as for me today there are more important things: like I explained before we have to reduce costs and if we can do by using tools like ABAP Ninja we should do this. These tools help us to analyse software and dependencies within – a hard and error prone task that has to be done manually before.
But reducing cost is not everything like Léo Apotheker explained in his keynote: Currently there’s a transformation from “linear” business structures into business networks. And this is exactly what ESME is for: It’s a tool to communicate within in company or user groups but also “bots” can use it and I’m convinced that we will use it for communication within business networks. So for me it was cutting edge technology with an extremely high business value.
Let me get more into detail: When I said bots can use it I mean that we can use it to reduce administration costs, too. A report that runs periodically tells about system dumpy, table space issues in database tables, if the remaining NRIV-numbers in ABAP get low and so on. Now this has to be checked by administrators manually – but why shouldn’t the system tell it us? ESME is the right platform because those messages are tagged and a rule engine and filters guarantee that a messages reaches the right group of people – and no more and no less compared to outdated techniques like email who are not able to filter “noise”.
I think could write for ages about ESME because a community-driven Open Source project just established a completely new shift in communication paradigm in different ways.
But now I’ll use the rest of my time to visit Berlin. I fact I spent the first 12 years of my life here and I love to come here to see what changed. Good bye TechEd - Berlin, here I come!
