Introduction
On the 24th and 25th of June the first SAP Innojam event in the Netherlands took place in Den Bosch, the headquarters of SAP NL. In this blog I want to convey how our team did during this fun event, and how we eventually even won. I will first describe the business case we decided to solve, and then go on to describe the several phases that we went through. For an introduction of the Innojam concept, have a look here. For a first impression of this particular Innojam, read Great fun at SAP InnoJam NL blog by jan.penninkhof2/blog (@jpenninkhof), or the Insomnia @ SAP InnoJam 2011 Netherlands: Part 1 of 3 by rui.nogueira/blog (@ruinogueira). You can also have a look at the photo’s, provided by the VNSG and/or the live-streaming, done by Rui himself.
Business Case “De Hoogvliegers” (Google Translate: The high-flyers).
The Dutch organization “Stichting Hoogvliegers” aims to get (chronically and terminally) sick and (physically and mentally) handicapped children (6 to 16) to fly. In order to reach this goal “De Hoogvliegers” recruit pilots, either professional or hobby flyers, who are prepared to take these children with them on a flight.
A problem this organization has (and since we didn’t speak with them before Innojam started, I’m guessing a bit here) is that their data are scattered around (multiple data entry points), which makes it particularly difficult to match available pilots with the patients. A natural solution would be to have one central system, with all patient ánd pilot data available and an application that supports the matching process.
First steps
We started attacking this business case by having a look at the data model and some process steps that at a minimum had to be implemented. Central were of course the flights and the bookings (matchings). We also had to consider the transportation of the patients to the airports, since the children are not able to get there themselves. Further, the flights are mostly circular, and we should be able to match patients as much as possible with pilots flying from an airport in the vicinity. Also, patients are subject to a screening after signing up, to determine whether they really qualify.
The main process steps we identified to implement in our prototype were:
- Registering a pilot/patient: get the master data in the system
- Announcing the availability of a flight: to be executed by the pilot, when he intends to go on a flight and is prepared to take a child with him.
- Matching: we let the patients choose when and where they want to go on a flight that has been declared available.
Reducing the scope
Next thing was to bring back the scope to the very minimum. We quickly decided to leave the mundane details of transportation out, and to focus solely on the matching of pilots and flights. We also dropped the location-angle, and decided to do the matching (in our prototype) only on date and time. The approval-workflow for the patient registration process was also dismissed easily, since we felt we’d allow all children to have a flight ;-).
So that left us with some masterdata (patients and pilots) to be taken care of during registration, and 2 more process steps, announcing a flight (by a pilot), and booking a flight (by a patient).
Solution Architecture
Yes, I do like them big words, but really, this was easy: all of this could be built in a SAP River application. However, we identified the creation of a flight (with a certain number of available seats) as being very suitable for a mobile application: imagine a pilot deciding he wants to go flying: he should be able to make the necessary arrangements and announce this by a mobile app, shouldn’t he?
Besides, one of the objectives of this kind of event is to explore as much new technology as possible, and a River-only application would not give us the opportunity to explore more of the available new tooling/products (we had River, Sybase Unwired Platform and NetWeaver Gateway available, together with the usual suspects like Streamwork and BIOnDemand). Hence we decided to try to combine River with SUP. We wished we could have included Gateway into the architecture but we couldn’t: we really could not think of a natural need to use an SAP backend. In the end this proved a blessing in disguise, as the actual set up (SUP + River) did take all our time to get working properly.
Intermezzo
From the way I’ve described our approach so far one may get the impression we had a smooth process designing our solution. Well, we did indeed! Because we were such a small team, there really wasn’t as much discussion as there would’ve been, had we formed a bigger team. From this point onwards however, the development process started to get more cumbersome.
The hard work
After working on this solution for several hours, it became clear that the integration between SUP and River (which wasn’t done to date!) was the most difficult part. The River part was up and running relatively quick, which goes to show once again the potential of this platform for lightweight applications. Consuming the River REST API from SUP however was certainly not trivial. Meanwhile we’d been working on some programmatic Twitter access, but realized that would have to be done via River, so we decided to leave that out for the moment.
At 01.00 a.m., I decided to go to the hotel to get some sleep, as I wasn’t being very productive anymore. It was not an easy decision, since almost everyone was still hard at work, but I think it was a wise move, since I was much more productive on Saturday (I plan to write another more-evaluation-kind of blog, in which this will certainly come up again!). I was however very happy the next morning to witness this tweet from one of our team members:
The next morning we all got back to work, finishing and testing (!) the application, preparing the demo part, and during the second outage of the partner instance of River (again, I refer to the upcoming evaluation-blog) I even managed to get a good introduction to Javascript from Chris Whealy, explaining how he managed to access NetWeaver Gateway with a little JS-gem. In the end, we rebuilt the River application on the more stable preview instance of River, and managed to get the Twitter integration working. Meanwhile, the SUP-guys were still struggling to get the SUP-River integration stable, in which they succeeded 5 minutes (!) before we were to finish our work and go back to the demo room.
As you can see, even if you get things working the way they should fairly quickly, it doesn’t mean you’re ready for the demo: looking back, I think we spent almost half the time solving recurring integration and availability issues. A small change in River could (and did) mean another 3 hours of work to get the SUP-River integration working again.
Demo time!
This can better be seen than described. Apologies for my substandard presentation skills ;-).
The team
Before I conclude let me introduce the winning team:
- Onno Schoenmakers (@oschoe😞 could ‘only’ attend on Friday, but brought on the business case (essential, I’d say), lead the design phase, and worked on the Twitter integration.
- leon.boeijen (@Muthly) and divya.mahajan/blog: responsible for the SUP-River integration and the (not demo-ed but working) iPad app. As I said: this was the most difficult part, so kudo’s to both of them!
- Jeroen Huttinga (@JHuttinga) and myself: we worked on the River part, and in the end (nice-to have, remember?) realized the River-Twitter integration (will try to post a video later).
Not official team members, but still instrumental in getting everything working: juergen.schmerder aka @schmerdy and martijn.tielen (@MartijnTielen), the experts (on River and SUP resp.) from SAP.
So, how dó you win an Innojam event?
Well, that’s not an easy question to answer. I could say: work really hard for 24 hours, but as all teams did this, it certainly isn’t sufficient. To be honest, I think a certain amount of luck (or randomness) is definitely involved (getting your application to run depends on a lot of sometimes small things, and you can’t be sure all the pieces will be falling into place in time for the demo).
There were however a few factors (for which we really can’t take the credit) which definitely helped us win this event, and which I’ll present here as tips for teams in the next events:
- Keep the team as small as possible. Of course, the way the teams are formed you really don’t control this aspect, but we were (by far) the smallest team and I’m sure it helped us to more easily distribute tasks and keep the discussions manageable and to a minimum. So when the teams are being formed, and you’re still hesitating which team (and business case) to join, take this into account.
- Keep the scope of the business case even smaller than the team. Try to do only the absolute minimum required to get a live demo running, and address all other stuff only if there’s time left. Our business case was kind of ideal in this sense, since we could skip the transportation part (getting the children to the airport is of course non-trivial), and focus solely on registering new pilots + patients, and matching them. The nice-to-have Twitter integration was something we realized in the last couple of hours.
- Make sure you get the help of the experts when needed. They are there to help you out at the moments you’re stuck, and we certainly didn’t hesitate to ask their advice.
To put all this stuff into perspective however: the main lessons to be learnt from this event (irrespective of winning or not, which should always come second place, pun intended):
- Build a team
- Have fun together
- Learn new technology in the best possible way: hands on.
I can’t wait to join the second SAP Innojam NL event next year!
- SAP Managed Tags:
4 Comments
