Enterprise Apps – Change the rules, or they will change you


Everyone and his neighbor is convinced – including me – that future of enterprise software is in apps. However that does not mean the world will change tomorrow to a happy place. Here are half a dozen things that rush to my mind, in no particular order. It is a Sunday morning, and I only had one coffee so far and I have the flu. So take this with a pound of salt.

 

1. Apps will have really short lifecycles as we go forward. 

 

So we need a foundational architecture that allows people to create apps with bare minimum effort and cost. “Create” does not mean just dev and test – the whole app life cycle management including security, device management etc needs an industrial strength foundation that is easy to use and is affordable.

 

In short-medium term – we might have 1 to 2 year useful life. But as time progresses, this might become use and throw. And that might mean users can create their own apps, instead of a developer creating for them.

 

2. Backward compatibility is a must in enterprise world

 

Consumer side has one big advantage. Facebook can add and remove as they please – ok, not exactly, but easier than say SAP or ORCL.  Enterprise side does not have that luxury. So again, a paradigm needs to evolve that balances this reality against the ease of upgrades etc.

 

3. No one vendor can develop enough apps

 

So a huge ecosystem is needed. This means, on top of an architecture that makes it easy for developers – we also need a licensing paradigm that goes with it. This is not easy for companies new to this game. My favorite poet in Malayalam, Kumaran Ashan famously sang “change the rules, or they will change you” . He was referring to the social injustices prevalent at the time though.

 

4. HTML5 might not be the answer to world hunger

 

Apps are not all about mobility probably, but mobility is probably the leading horse in this race. This whole HTML5 vs native debate will probably end in hybrid scenarios, more than any one side winning by a margin.  Device makers don’t have a lot to gain from HTML5, and consequently native functionality will keep improving at a steady pace. And of course apps will follow the trend – since it is more or less a binary world in mobility. Either app gets used or it won’t – not a lot of middle ground.

 

5. Horses for Courses – Not all parts of Enterprise are app friendly, and not all users like apps

 

Whatever is the future architecture and licensing model – we should not fool ourselves in thinking that everything needs to be an app. Some processes are best left alone – along the lines of “everything must be expressed in as simple a manner as possible, but no simpler”, and not all users need or like apps.  Users should be allowed to choose whatever makes them more productive.

 

6  Why buy/build when you can beg/borrow/steal ?

 

A lot of functionality that enterprises need are also needed for you and me as consumers – things like file sharing, collaboration and so on. What enterprise needs is added layers of security, scale etc. It might be easier to let the consumer side take a lead on these, rather than re-invent and duplicate all of this. Who knows, one day consumer side can get something back in return too.  Or as standards evolve – there might be a possibility to put a layer around consumer apps that make it enterprise grade.

 

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.