Is collapsing layers a good thing? Help me understand please


Vishal Sikka explained in his SAPPHIRE and TECHED keynotes that the general direction for SAP is to collapse the multiple layers that exist today, and move more and more of them natively into HANA. It sounded like a pretty neat idea to me when I heard it, and I did not think more about it for some time. Timo Elliot then mentioned the example of digital photography getting rid of obsolete layers and revolutionizing the industry. In his opinion, HANA will do the same.

Vishal and Timo are two of the most brilliant minds that I admire in the SAP world. But for some reason, a part of me started thinking – is collapsing layers a good idea generally? My education is in mechanical engineering, and not in computer science. So I started thinking along the lines of machine design to see if I can rationalize this somehow. And I failed.
I started an attempt to discuss with Timo about this on twitter, but it is hard to do it 140 characters at a time. And then my flight to PDX started boarding and I had to abruptly end the twitter session and run to the gate. Since I have some time now in the flight to reflect (and type), here goes.

Layers exist for good design reasons. Layers traditionally have been built for some specific purpose, and over time they get very optimized for that one purpose. As technology improves, and smart people get bright ideas – they can replace a given physical layer with something else that is better. But the layer in design time should still remain in most cases. Why? mostly because there are smarter people in every generation who will improve upon this, and Mr Murphy might show up unannounced.

Taking Timo’s example of digital cameras – the physical storage in films got replaced by memory cards. But there is still some storage layer that did not get replaced. Tomorrow something else will come up that is better than these cards, and this layer will further improve. Now – nothing stops a designer from combining thr storage with the body of the camera or the lens or something else. This might be pretty revolutionary – and might outperform other cameras too, and users might love it in short term. But the question is – with this design, can the next generation of designers add on benefits of advancements in each layer that collapsed? To net it out – does performance outweigh the need to maintain and enhance?

Another example is our family car. I love that car – but have had multiple accidents with it in the past. If the manufacturer of the car had decided to collapse layers – my insurance company would have probably paid off the car after the second time it had an accident, and I would have had to cough up more money to buy another car. It just would not have been easy or cost effective to repair it. I would have been pretty mad at this scenario since all but one accident was the other party’s fault. Fellow Indians who moved to the USA might resonate with this – when I grew up in India, we could get everything on my dad’s Ambassador repaired somehow. When the newer cars came up – the concept of repair was mostly rip and replace. It was not affodable for many of us to do this.

In a stable system, it is comprehensible that some layers could be collapsed. Example : BW has aggregates. With HANA, you can aggregate on the fly. So it makes sense to get rid of this layer once BW gets HANA as the DB. But here is the question in my mind – If and when HANA truly becomes big data friendly (petabytes instead of TB), will it help to have a logical definition of an aggregate that will tune the SQL to get a specific aggregation done more efficiently?

We can argue that most of the data in BW is in TB range, and hence this is not needed at this time. But that brings up another question on innovation – is it innovative if you have to constantly tinker with the design? or should innovation stand the test of time? Timo made an excellent point on twitter – innovation does not come in neat buckets. It is hard to argue with that, and I readily agree. But for innovation to be useful – I believe it needs to be moulded into a form that can work for an extended period of time. At a minimum, this should apply to anything that costs customers in the millions.

Even if I somehow convince myself that collapsing layers make sense in a stable system, since we have a good idea of what each layer does and what will happen in foreseable future – can I extend this and believe that this is applicable to newer systems? I am having a hard time convincing myself of this.

HANA is just about a year old or so. Revisions are coming fast and furious to the HANA software. And HANA has an aggressive roadmap to make it work for BW, ECC and so on in a short period of time. It means work needs to be done on many different things that make up HANA (stabiling the core, enhancing the SQL, scaling out and son on). In this scenario – will it be easier for SAP to develop and enhance HANA if more and more layers are brought natively into HANA ? May be it is – I don’t know. I have not worked in software product development. Hopefully some one from that background can explain to me why this is a better idea.

The closest I can relate to is a custom build engagement that I manage, which uses MSFT technologies. The architects followed a multi layered paradigm to build this. It handles mission critical information, and there is very little tolerance for error. We debated many times internally if it was possible to decrease the number of layers to improve coding speed, and performance. My chief architect held firm that each layer has a job to do and it will serve us well if we stuck to it. We agreed on it – and he was right. As soon as first release was done, we had to start on the next one, and there is just no way we would have kept up with enhancements and performance tuning aspects etc if we did not stick to the multi layered architecture.

Sure we could have gained some performance – but in the overall scheme of things, the solution seemed pretty good. But then – this is a project, and not a product. What works in projects might not be the right approach for product development. So I can’t make any firm conclusions based on this experience.

If I knew in my younger days that my career and interests will go this way, I might have skipped my MBA and done a masters in computer science or gone to a design school. Since I did not do that – I guess I have to learn this the hard way by debating this in public, and probably get electronically beaten up 🙂

Gamification Of The Enterprise – post SAP Teched 2011 thoughts and actions


I am a big fan of innojam – despite the pain of sitting through hours of mandatory speeches (after all the sponsors need air time in return for their money and time).  Once we got through the speeches, I had an idea for an enterprise game which I jotted down , and deposited in my pocket. And since I was pretty bored and hungry (ok..and thirsty)  by that time – I looked around, and readily found a bunch of mentors who were ready to go get some dinner. It was the best dinner I ever had at a Teched – and when dinner was over, we were all pretty much psyched enough to go make gamification work.

Actual software part took very little time – between the group we knew HANA, BI 4.0, ECC and so on. And we had some very creative minds who mocked up data, created facebook pages and so on. And then we went around the room,  giving a hard time to other teams. Despite my thick Indian accent, my team “gamely” put me up to go present in front of the judges. We did ok but did not win. I don’t think any one felt bad – we just had more beer, cheered for the winners and went on to the next fun Teched activity.

Once Teched was offer, I started thinking about the possibility of making gamification work in a real business scenario. Since we had more than 10 applications to choose from the innojam – and since we had it on video, and since the memory is still fresh in my mind – I thought why not use these as examples. So I actively checked with people who had an hour to talk to me. I let them watch the video,  explained in more detail – and asked them if this was in real life, will they do it.  Out of 6 people – 1 consultant, 2 power users, 1 IT manager, 1 Solution Architect  and 1 VP level executive –  I got 4 NO and 2 MAYBE as answer.  I tried to give them all the talking points that the gamification keynote speaker used – but still could not convince them that this is useful.  I will try to do this exercise for another week, and see if I can get 4 or 5 more people to sit down and talk to me .

In short – here are the general themes that came out. I am sure I missed a few since this was not a structured survey or anything.

1. I have real games that I like. Why won’t I just play those like I do today?

2.  I don’t want my employer using this to game me. Is this another way to exploit me?

3. Will this lead my team to have unhealthy competition? or will they get carried away and use it to skew real business results ?

4. What happens when they get bored with this game? will productivity drop? What will it cost to keep building new games etc? Can I measure ROI? Even if it works – is there a big upfront change management investment?

5. How can I define a game? I have colleagues in 4 continents and what appears like a game to me might end up as an insult to one of them. Is it worth the trouble to deal with it?

6. With economy not doing well, aren’t people motivated enough to do a good job now? Why bother tinkering with regular business models now and take a chance? Contrary to what consultants tell me – my business has not actually changed fundamentally. is this a way for you guys to skim more money off my company?

 

There are three possibilities I can think of here

1. I did a poor job explaining gamification to these people – since I only know what was conveyed to me a week ago at Teched.

2. The examples at innojam were not enough to resonate with these people

3. Gamification is just another buzzword, and even if I explained better with nicer examples, people will not buy in.

Till I talk to a few more people, I am not going to make any final judgment for my own case. But the questions that came up are all good ones in my opinion.  As always – I am all ears to hear what you folks think.

What does it take for execution success at SAP?


There is a prevailing thought in the ecosystem that SAP scores high on the strategy and vision, and where they need to focus is on execution. This came up in numerous conversations I had with Teched attendees this week. What is not clear is how exactly SAP is going to enhance execution capabilities. About 50% of all conversations I had in Las Vegas was on this topic.

For what it is worth, here are three thoughts on potential solutions, that were formed as a result of my conversations.

1. Cross-pollinate and learn from people who are good at it.

SAP has customers who make mission critical systems and on a deadline.  Why not request their help? Send developers and managers to watch how they work in their environment, and learn. SAP also has a bunch of SI partners, ISV partners etc who also have a lot of experience in delivery excellence.  Of course there are spectacular failures too from customers and partners – but it is a small percentage. It looks bad because headlines do not look as attractive for good news.  This is an easy route for SAP to enhance their execution capabilities.

Also, nothing stops SAP from hiring people from outside to inject new blood into the execution arm. Conversely I think others will benefit a great deal by getting some experts from SAP  into their teams.  The risk is that if not done properly – this could end up as unhealthy talent poaching which won’t help any one.

2. Include ecosystem in development and testing


Some variation of the APPLE model might work for SAP. SAP technologies have a big fan base. Current licensing models do not allow this really large pool of smart people to contribute to getting more and better SAP applications.  Sure there are legal and financial and infrastructure issues to be dealt with – but those can be dealt with if the leadership at SAP has the conviction and will to get it done.

SAP is quite good at working with customers on getting ideas for what products/features/functions etc are needed next. And they have a ramp up process which is quite good too.  However, there is a missed opportunity in using a vast ecosystem in testing.  And SDN is a great platform to get access to a large number of people who might be able to help with this, probably for free.  Why not allow software to be freely downloaded as trial versions? and if Cloud is the way SAP is going – why not host these and let SCN members play with it?

3. Industrialize innovation

Innovation should matter to the company in some measurable way.  Sure it is fun to do gamification innojams, and a couple of  apps in HANA a year. That will not add $$ to topline or bottom line. For that – innovation needs to be focused, and the process should be industrialized.

A good example is LOB on demand products.  Sales on demand, Career on demand etc are all very good – and have some of the best people at SAP doing their best to make it succeed. But they are too few to make it count. My gut feeling is that each takes couple of years to get to market, and then in another two years or so – they might make $100M or so. I could be wrong – and am glad to stand corrected. But at this scale – how much (and when) will it affect a $15 Billion company’s financials ?

Can SAP take the learning from first 2 or 3 OD apps, and get into  tens of applications being developed in parallel ? Can those be applied to HANA and Mobility applications too in some convergent fashion? I know SAP is big on agile and design thinking and other fancy ideas. Question is – do they scale to an extent that it moves the needle significantly for SAP?

As we recently joked towards the end of the HANA skills podcast with Jon Reed and Harald Reiter, we need some “action leaders”  to balance all the “gurus”, “thought leaders” and “visionaries”.