Friday, March 21, 2014

Start of Journey

Every journey begins with a desire to go somewhere.


The Beginning

The initial idea was to make use of the very promising Eclipse RAP technology (https://eclipse.org/rap/) in our development, related to Service Adaptation (part of SOA tools). The question was: - Can we build Web-based tooling for Web Services simplification (i.e. enterprise services in SAP language)? Started as a POC and evolved to a TGiF project, the Dirigible first and foremost impressed us ourselves.

The Traction

We were quite happy with the speed of building the tools for Web services management and especially the way of reusing most of what we had already built for Eclipse. After several demonstrations on local events as well as receiving feedback from our colleagues, we realized that bringing the toolkit "as it is" from the desktop to the browser is not bad idea. Developers do not need to learn yet another tooling, a concept very well accepted by the lazy nerds.

The main goal

At this early phase we were already clear about the main distinctive feature - shortest ever turn-around time. By definition, this is the time period between the raw coding and a running program, when you see the result of your amazing algorithm. It turns out that shortening this period is one of the most important productivity features for a development environment. No need to explain what it means to start a build procedure, which takes few minutes several times a day for the poor ADHD guys. How to improve the situation? We decided to go back to the core - ABAP. Of course, it was not so simple, but at least we could use some concepts, which made it one of the most popular environments among business application developers. The combination of the In-System Programming model and the new Cloud Infrastructure was something that was really worth trying out.

The Architecture

We naturally came up with the idea of the central repository and registry, where one can store all the application related artifacts along with the metadata descriptors. This simplifies the discovery (search and browse), transport between landscapes, etc. activities you are usually required for a full life-cycle management. Being a research oriented project we started to integrate and evaluate various frameworks to see how they behave in this environment - eXistDB, Synapse, CXF, ActiveMQ, Camel, OData4j, Rhino, jRuby, Groovy and many more. Some of them still remain as part of the project, others faded. Finally all this resulted into only three major pillars - Repository, IDE and Runtime.

The Focus

The core team was pretty small and the time was very limited. (Surprised?). We had to stick to the "small effort, big impact" paradigm. This helped us to only focus on specific use-cases, i.e. the simplest cloud applications (~20% as variety, but on the other hand ~80% as absolute amount). Target or typical applications became micro-sites for specific product(s) during marketing campaigns, temporary ad-hoc applications, tailored applications for specific department and/or roles, etc. This helped us to define the components to sustain such a target application created with our toolkit, and set the term for it - Dynamic Application. It is considered as atomic bundle of software, which solves a vertical scenario from the data layer, through entities, user interfaces, custom actions, integration services, tests, security and even the documentation (of course the documentation is an integral part of the otherwise self-explanatory stuff we produce).

The Process

The person who acts as a consumer of this project is the on-demand software developer. That means every team member knows exactly what he/she wants to see in the product in the end and how exactly it should work. Isn't it the absolute pull principle? It works quite well indeed. "Bring your own feature" and "bring your own bug fix" mindset drives the prioritization of the issues and the quality itself to unprecedented heights.

The Usage

"Eat your own dog food" principle also was proved several times. Some of the internal LoB applications were developed on test instances by some of our students. They were so dedicated to deliver, what their managers' already promised - not only to show that they can cope with the application development in general, but to develop applications with their own tooling, the one they had created.

The Struggle


 So far everything seems too good to be true? Sure, there was a disturbance in the force. The time came when we had to make a product out of the project. As one of the biggest business software oriented companies, we have lots of standards, that need to be fulfilled and processes, which have to be followed step by step, in order to achieve minimum support of the product after the launch. This took way more efforts and resources than expected, but had to be done. What was the problem? It's clear it had to be done! Is it the "disturbance"? ... Nope, this was still the "same side of the coin". The "other one" was that the high management made a decision - the current focus had been changed and we had to freeze the project. Bad luck?  ...Hmm - But there is always a way! We decided to opensource it and to join the family of SAP HANA Cloud Labs projects at GitHub. It was in the plans whatsoever, but it came ahead of time. No doubt - there are lots of open source supporters and contributors at SAP who helped us to pass through this final internal process.

 We managed to deliver!

The Flight

After a few years of internal development the Dirigible flew into the sky to the clouds - http://www.dirigible.io

The Love

It always makes difference when something is made with love. To see the confidence among the team members that they do the "right things - right", the joyful sights of the colleagues, who immediately start thinking how to join and contribute and the managers' willingness to support (oops - as usual) is a priceless feeling.

Enjoy Programming Like Never Before!

Posted by at
Labels: , , ,

1 comment:

Subscribe to: Post Comments (Atom)