This week was tiring in the extreme – but in a good way. And tomorrow morning, we are leaving on vacation to Hawaii. The plan is to switch off work email and phone and just chill with my family.

Last year – we went to another island in Hawaii around the same time. The week before that vacation was also very stressful – but in a bad way. Something that I was working on with all my energy did not come through – and I decided to take a vacation to get over it. We decided on Friday, and we left for Hawaii the next day. It was awesome – and I came back fully refreshed, and the thing that did not materialize before I left, that happened in few weeks.

This time is a little different – we hit the results we wanted with the launch (http://www.saphana.com/community/blogs/blog/2013/09/24/announcing-sap-bw-on-hana-trial-offering-on-sap-hana-marketplace#comment-4174) , with room to spare. And I am leaving it in the capable hands of my main man Ingo Hilgefort while I am away.

As the last meeting of the week got over, I have been thinking through our little side project. What immedeately striked me was that we never bothered to give it a code name. And it never mattered once – we all worked as hard as we could without slogans and call names. I now need to think if this should be the norm going forward for my gang.

We did this with a core team of three – Ingo, Rohit Kamath and me. Ingo acted as the project manager. We had a lot of other things to do in our day jobs – so this was a side project with no formal budget of headcount. We went right ahead – and pulled in colleagues as needed from every corner of the SAP organization globally. And no one hesitated to help – every colleague we asked help, turned around and helped us. Of course some more so than others. But no one turned us down. As it goes – ask and you will be given .

Why did we do this? Because we were in front of a lot of customers and partners across the world in the first six months of the year. We knew first hand that it is painful for ecosystem to do POCs – and people told us versions of the same story in every meeting and event we had. So it was a no brainer for us that this needed to be solved.

It also helped that Vishal challenged us to think of a way to get a POC system up and running in 3 days, instead of the weeks and months it typically takes in many projects.

It was not difficult to arrive at a conclusion that cloud deployment is the best way out. The big question then became – will BW shops use cloud at all? We all had different opinions. So I wrote a blog about it and put a poll inside it to see how the ecosystem percieves BW on Hana on cloud. The data – although a small sample – clearly showed it was a welcome idea. So we went ahead with the plan.

Next up was the question of what is needed for the POC system – and after some back and forth with ecosystem – it was agreed that BW alone didnt make sense, and that we needed BW on Hana with a BI server so that customers can better visualize the awesome capabilities of BW on Hana.

This solved half the problem – the other half was more difficult. How do we ensure that a customer will face minimum fuss in doing a POC? We analyzed further and figured out that it is not enough to provide raw infrastructure – we should also provide connectivity between BW and BI, as well as sample content and data. And for those who need more training – we also decided to provide tutorials. This is the same material we had tested with probably a thousand people before in our enablement sessions in the first half of the year. So we were sure that this was the best way to get someone up to speed.

Then came the actual deployment. We had many options – many different clouds, many different stores, many different integration technologies etc. We decided to make SAP HANA Marketplace as the entry point, make SAP store the transaction engine (record keeping) , SAP CAL (cloud appliance library that does the magic behind the provisioning) as the deployment engine , and AWS as the deployment infrastructure. Together – they offered the best trade offs.

At that point – we needed the best critics we could get to see if our plans hold water. That is where the SAP Mentors threw us some help. They got into a call with us and gave us excellent feedback. And to fill the remaining gaps – I also ran it with Dennis Howlett who also was helpful in his feedback. We listened and we acted – and that is what eventually went into production on September 25th morning.

We only did a soft launch – Ingo and I wrote a blog each, and we tweeted out from our personal handles. It was not exactly a social expiriment – it was a well thought through plan with colleagues in marketing. The results surprised me to no end. Thousands of hits on the blogs, plenty of twitter amplification, and significant traffic to marketplace. Best of all, way more people who reached the market place finished the transaction and got trial systems than we expected. I was skeptical that the numbers were any good – but after seeing comparables from people who do this thing for a living, I think we did pretty well.

You will see a lot more activity from next week to get the word out across all channels. I cannot thank enough everyone who is working hard now to get this in front of as many customers and partners as possible. It is also amazing how many colleagues pinged us directly to ask how they can help. That is what makes it special – where people volunteer to help when it is not their day job.

From the time we launched – we have been staying in close touch on all channels to provide assistance to people using it. Where we cannot help – like for example, there are only a subset of countries where we can legally offer this today – we are updating the marketplace with information about what is available and what is not. I am especially thankful to everyone who tried it out – and then took the trouble to communicate what they were happy with and where we need to do better.

There are some 18000 BW installations today – and BW on Hana is something all of them should try out. This is our first step to make it very easy to do so. Even more important, the feedback we get from this trial is what will drive our plans for what else we can do. Our hope is that data will tell us what they next step is, instead of us guessing what customers need.

It was a learning experience for Rohit, Ingo and I – and probably the 40 or so other colleagues who helped in the extended team. It gave us all a better idea of how many things are interconnected in a big company, and how we can all work together in informal settings to make good things happen. Sure there were many frustrations and crises along the way – but we prevailed as a team and got through it all. I am incredibly proud to be a part of this team and will gladly do it again. We also learned that we have to take turns in calming each other down 🙂

What would I change in how we did this?

1. Now that I know how many people have the kindness of heart at SAP to help – I will crowdsource more, and start involving more people early on. If that needs these things to have code names – so be it :). I should have know this after the success I had with it creating the IBM innovation lab for SAP in a crowdsourced model with Gagan. Good to know this works in all companies.

2. A small core team is the reason why we could move in an agile fashion. I will keep that philosophy. Rigid structures kill initiative in smart people.

3. Social is definitely the way to go to push the message and get feedback. I think we will do way more social interactions in next project. Not just more social – we will start doing this sooner too.

4. Start setting up measurement systems sooner in the project – even if it is informal projects. Sooner the better.

That is pretty much it . Couple more hours to finish the day off – and then get busy packing. I have promised my wife and daughter that I will not think of work when we are on vacation. Let me see how much I can keep that promise.

Ingo and Rohit – you guys rock ! Cant say enough thanks to you – and all the other colleagues who helped and continue to help. Also a very special thanks to Amit Sinha , Jonathan Becher, Steve Lucas, Prakash Darji and Vishal Sikka (and their teams of course). We could not have done it without you.

Hope that by the time I return to work – I will see a lot more people using the trial. If not – we will go back to more analysis and fix it. Long complex POCs suffering from complexity of IT systems is a problem the world doesnt need – we will fix it some how, no matter what.

I didn’t get a lot of sleep past night – maybe 4 hours . And as I am on to my third cup of coffee this morning , I had a short twitter conversation on the ever green topic of strategy and execution . I couldn’t help post a few random thoughts

I did learn some strategy stuff in business school. It was ultra boring then – and it is ultra boring now . I am only dinging how it is taught – not the idea of having a strategy itself . Countless hours were spent debating mission, vision, strategy, and the like in those two years . None of that helped me one bit – heavily academic stuff .

The first time I started having a sense of strategy and execution being aligned was when I had to hit a hard target in IBM . One year of doing that taught me more than all those books and debates till then. It is quite simple – the best and most viable strategy is execution .

My conspiracy theory on the reason of this misalignment is as follows

A big reason people can’t deal with execution is because they get rewarded in early school life for the steps they take to get a solution for a given problem . If those steps appear to be right – you get a pass , even if the final answer is wrong . The other lesson from school – which is more recent , and it was not the case for my time in school – is that “everyone is a winner”. After 12 years of this indoctrination – I wonder how anyone can survive in corporate world .

Real life seldom rewards the steps – only the outcome matters . My teams past and present have yelled and screamed at me for saying effort doesn’t matter, only results do . And almost everyone of them have thanked me for taking that stance consistently . Hard work that doesn’t lead to desired outcome does not come with a pleasant prize . Same deal with “everyone is a winner” – what a bunch of bull . Every one is not a winner – in sports or in life . Get over it the soonest you can .

There is no such thing as “Strategy was awesome , but execution sucked “. That can also be said as “that was an awful strategy set by people who had no idea how the world works”. Strategy and execution are distinct only because of the time dimension – you need a strategy in most cases before you execute. But the moment the execution starts – there is no distinction , and these two things should converge . Based on feedback from execution, strategy should evolve . And when they converge this way – there is just execution .

People who consider strategy as key and execution as stuff beneath them in organizations needs to think why the big boss is called “Chief Executive Officer” and not “Chief Strategy Officer”.

This is how I view it – Strategy people get direction from the CEO. The non-PC way of saying this is – execution rules, strategy drools .

Dennis Howlett posted this today and was the first thing I read today morning.
http://diginomica.com/2013/09/25/user-experience-trumps-technical-excellence-gartner-bi-reports/
He and I also had a quick google hangout on this topic – and I thought I might as well add a few comments here.

First – Customer Experience and Technology Excellence should not be looked up on as mutually exclusive things.
For short term, they can be mutually exclusive – but certainly not for mid to long term.
They are both needed for a viable solution – BI or otherwise.

Second – I have no arguments that new generation BI tools focussed heavily on CX and were amply rewarded for that by customers directly, and by investment community indirectly. Valuation of these companies are many multiples above incumbent vendors – as a ratio of market cap to revenue. And rightfully so – they opened up a new battlefront and used that advantage to the fullest. I applaud them.

Third – For a second, I don’t believe that this is detrimental to incumbents. The big companies have work to do to up their innovation game – and from what I see, that is being taken care of already. Even better, at least where I work – there are serious product plans on leapfrogging over the new competitors and disrupting their game. of course it all depends on execution – but I am betting on good execution this time.

Big companies have many things going for them – large footprint of loyal customers and partners, steady revenue (yes, including maintenance ), large R&D and sales force and so on. Smaller companies don’t have these luxuries. But on the other hand – these keeps the smaller vendors very focused on execution.

Four – although there are a few cases where new vendors are replacing existing vendors, in most customers the new solutions are strictly additive. They continue to use their classic systems because they are rock solid – and for the last mile usecases, they resort to the new tools. Large vendors of course would like to get a part of this action too – and have their work cut out.

Five – Analyst reports like Gartner MQ use aggregate data. With larger vendors, there is always the risk of the older technology being the larger part of their footprint. When customers on older versions get interviewed, they can only answer based on what they have. What was great CX last decade probably sucks this year. And this will skew the data in awkward ways for the larger vendors. No on-premises company can force upgrades down a customer’s throat. SaaS vendors have a definite advantage on this front.

There are a few more, but time is up and I have to run to my day job and make a cool new announcement 🙂

My introduction to SQL was learning Oracle 8.x around 1996 or 97. And since that time, I have heard about Larry Ellison. Interestingly – that is around the first time I heard of Hasso Plattner too . Till then I only knew of 5 IBM engineers being the founders of SAP. I have deep respect for both the gents – they have a lot in common, despite having such different personalities. Of course I have only seen Hasso at close quarters, not Larry. Having worked at IBM for many years, I also have the greatest respect for the DB engineers and researchers there.

When SAP entered DB market seriously with Hana – my first thought was that it was a terrible idea. DB is the stickiest part of the stack at customers. I also remembered being tutored in IBM by the sales leaders that if you own the lowest levels of the stack – like HW, OS , DB and middleware, you own the account for ever. What I did not know at that time was that SAP’s plan was not to be yet another DB vendor – they wanted to change how DB works fundamentally. SAP wanted to play offense in a game that had moved on to heavy defense as the winning strategy. That is not just a sales and marketing thing – it needed a level of engineering that is extremely sophisticated. I was sufficiently convinced that SAP had a real chance of changing the market – and I bet my livelihood on it.

IBM is a great place to get trained in enterprise software. I learned from my first year there that all competitors have to be respected, but none should ever be feared. Competition is the best thing about this industry – keeps everyone on their productive best. Few months ago, IBM came up with DB2 BLU and now ORACLE has come out with 12c. I think both are good moves and both companies will use it to try and negate the impact of SAP Hana. And this is great validation of SAP’s strategy to change how DB should work. What is also not too surprising is that Oracle and IBM chose incremental steps to find some common ground with Hana – rather than go all out. For one – this fits well with their strong defensive strategy of protecting existing instal base, and two it needs a level of engineering that takes more time than what they had since they realized SAP made the right bets. But all things said and done – still a good move that is positive for the enterprise software market.

I give Oracle full marks on messaging – I thought it was absolutely brilliant to say “don’t need to change anything, just flip a switch and reap the benefits of in-memory DB”. That is a simple and elegant message. And it is not trivial to come up with such good messages. It is very easy to understand and appreciate at a high level. Nicely done.

Ellison did say many things in his keynote that Hasso and Vishal from SAP have been saying for years – why RAM is faster, why columnar DBs work better and all of that. All of which are good statements, and he has the credibility to say these things about databases. He definitely was in his elements talking about databases – and I enjoyed watching it. It was also a nice change of pace from the opening act from Fujitsu.

SAP Hana is fast and it is in memory, and it is column based – and looks like 12c does all of this too in some way. But that is just a fraction of what makes Hana special. SAP views Databases very differently from Oracle. HANA is a full fledged platform – which supports all types of processing with one copy of data . Not only does it store data in memory and in columns, it pushes down processing closer to data – and reduces the number of physical layers needed traditionally in an application. It has built in libraries for predictive and statistical functions. It has built in app server and web server. HANA can seamlessly integrate with other big data systems like Hadoop. That is a long winded way of saying – a database can and should be so much more. SAP showed it can be done in one system without needing to club together many different applications – at multiple productive customer projects, not in some proof of concept labs environment.

Oracle could have done a lot more – but chose to just do only very little. I am sure they have the engineering brilliance to do more, and a sales force who could have made use of such innovation. That is disappointing for the techie in me – and I hope they do way more in future and push the envelope on what a DB can do.

I was also kind of confused on why Oracle chose to do Column and row stores with multiple copies of data (unless I misunderstood what Larry said in the keynote). Enterprises already can’t deal with the many redundant copies of data – why would you add to that problem with a “modern” solution?

I have more questions – why is OLTP faster now ? What is the behavior of the system when it starts up ? What happens when there is not enough memory – will it use disk ? What happens when an app needs data in rows and columns ? How much of DBA effort is needed – how smart is the system in deciding what goes into memory and what does not? how much does this “switch” cost a customer? and many more. I am hoping that more details will be available through the conference, or in the weeks that follow. I am hoping there are good logical answers to all of these details.

There were two general types of questions on twitter after the keynote – will be now see a Hana vs Oracle bake off on speed ? and will 12c slow down hana deals and put pricing pressure on hana ? I think both are genuine questions worth asking .

If 100X performance is all 12c is capable of, then we probably won’t need to do any bake offs. There are enough customers who have way more performance gains with Hana than 100X. In any case – raw speed is only one part. What you do with that speed is what happens – and Hana has applications purpose built to exploit the speed – using the other capabilities in Hana like predictive and geospatial cpabilities for example. And given the head start Hana has over 12c, it is hard to imagine Oracle catching up in incremental steps like it seems to be doing.

On slowing down deals and pricing pressure – I have no idea given I don’t work in sales. Nor do I make sales or pricing decisions for SAP. However, from past sales experience – I think this is a factor of how well Oracle and SAP can educate their customers on the technology options. I will definitely be curious to see how it plays out in market. Customers do not buy on technology merit alone – I know that well. Given Hana grew pretty fast and has thousands of customers in last 2 years, I doubt customers will have any issues in seeing its value proposition.

Oracle is a great competitor and will not just sit back and watch hana eat its lunch – as an engineer, I just hope that they bring in some serious innovation to database technology, to back up its messaging. I will be the first to stand up and applaud if they do that. And for SAP, I am sure the intention is to continue to try as hard as we can to maintain and increase the lead on innovation front.

Between telecons today, I was glancing through twitter and had a brief chat there with Ben Haines, the CIO of Box.
See below.

Just reminded me of a few phone calls I have had from the expense police in past life

Expense Police :Can you explain why you tipped $10 more than 15% at dinner ?
Moi : err- because the client loved the service at the dinner I took him to and let me get away with a missed milestone which would have cost the company a few thousand dollars

Expense Police : I need a daily exchange rate breakup for your claims for Germany trip last month. If you can’t respond in 2 hrs , I will deny the claim and you have to raise a new claim later
Moi : sure – let me step out of this stupid negotiation with CIO for a $30M deal right away and go find the exchange rates for you for my $5000 claim

3. Expense Police : I am denying the $2K air ticket because you didn’t attach a manager approval note

Moi : sorry – I made the assumption that the General Manager 3 levels above my boss had the authority to approve the travel and only attached his approval . Let me call and yell at him for aiding and abetting a willful negligence of company policy by me

4. Expense Police : I will let the first 3 things slide this time based on your explanation. But this is the last time and I will have to notify your manager

Moi : Much appreciated. I will let my manager know so that he can prepare his manager for his call with you for his own expenses

5. Expense Police : Remember I told you I will pass your claims this time? Well, we cannot do that. The system does not allow us to do that. So I am denying the claim.

Moi : OK – I am sure the system has good reasons to do it, given it is more intelligent than both of us. Does the system accept thank you notes or flowers that I can send to mark my appreciation?

I will stop here – there are a dozen more along these lines .

I would be hard pressed to find an application that is more universally loathed than expense apps .
Why is it so ?

Mostly because the fundamental thinking behind corporate expenses is. “Trust no one”. Everyone from CEO to Janitor are out there to cheat the company on expense reports apparently . Put as many obstacles in the way – and we can find that one bad guy amongst the thousands of employees and contractors.

Second , legal frame work is stuck in the 1950s . There are places where you can claim electronically with a nice iPhone app but you need to mail in receipts . A paradigm of productivity and efficiency , eh ?

Last, apps get built by people who don’t travel and hence have limited knowledge of how traveling employees live and pay .

I know many including me wanted job promotions in past strictly because then you can offload expense reports to an assistant . But every time I give a bunch of receipts to my EA , I feel rather sorry for her . I hope she doesn’t get as many calls from the expense police .

Some of you might know this – I trained to be a mechanical engineer, and then did an MBA thinking I wanted to be an investment banker. But right out of business school – I figured what I REALLY wanted to be was a developer. So I took a developer job and stayed a developer for many years, before moving on to management and other more mundane things.

I still code at every opportunity I get, and I introduce myself as a programmer most of the time when I meet strangers. I don’t think I am an ace developer – I used to think that way, but learned along the way that I over estimated my abilities. But in a pinch – I can design and code to save my life. So that is the background based on which I am making these comments – an ex-developer, who moved on to management along the way. And I am fairly sure that if I ever succumb to the temptation to get out of management – I will consider being a developer as my first option.

Please don’t take this as the views of my present or past employers – I am not representing them here. These are just MY personal views. If I ever start a technology company (as opposed to an Indian restaurant), this is how I plan to engage with developers.

1. Align developer strategy with company’s stated objectives – or don’t have a developer strategy at all

This is the first step – and it is a mandatory step. I would NEVER want to have a developer strategy if I cannot figure out how to align it with company goals. If I need to make a certain revenue, or profit or whatever – I should know how developers can make that happen. If I cannot do that – I won’t waste my time or developers’ time . No strategy is better than a terribly articulated strategy.

Why? because if such a connection with business goals does not exist to justify it – developer strategy will become disjointed over time, and it will never have top management support when times get hard. Then developers will turn neutral (or even negative) and kick start that dreaded accelerated trip downhill for the company’s technology.

2, Don’t just evangelize to developers – have the periodic sermon to keep them faithful

Lets take a leaf out of religion. Evangelists will make larger than life statements to get the attention of the people who have another faith and try their best at mass conversion. But then the evangelist will move on and come back only periodically to reinforce the belief. However, someone else needs to keep the conversation going so that the converted do not go back to their old faith, or worse yet – fall for another evangelist’s promises. The latter needs to be more low key, since people will get bored if there is no change of pace in the message. Eventually, the social needs of the faithful to talk to others will take center stage, and once that happens – faith is on strong foundation.

Developer strategy in many organizations fail because all they do is evangelize. No one keeps the conversation going. And since the community feeling does not kick in, developers will drop off and move on to the next thing. I know I will if that happens to me.

3. Fire the person who comes up with a “one size fits all” developer strategy

That will be a “shoot first, don’t ask” thing for me. There are many types of developers – and there is no one strategy that works for all of them. What excited me to take up C programming in 80s is not what excites me today about Python. If the person evangelizing to me does not get that – I will tune out in a hurry. I might even say uncharitable things to their face. So don’t be fooled into having one strategy for all developers.

Based on many factors – age, experience, geography and many others, you need to find out what makes developers tick. You will do that routinely for customers and vendors – because that is part of your corporate strategy. Do the same for developers – do some good segmentation, and refuse to cave in to lowest common denominator. As you can see – this is why I said before that if developer strategy does not align to corporate strategy don’t bother having one at all.

4. Don’t treat external and internal developers significantly different from each other

That would just be utterly silly if you had different messages for each group. If internal developers won’t buy your message on new technology – see what is wrong and fix it before you preach at scale externally. Remember – they are internal when they work for you in office – more often that not, if they are any good, they will be on other forums doing other things outside work if they don’t care for your technology – although that is what pays their bills. And everyone talks in this day and age – the world of developers was social before social was fashionable.

5. Don’t just listen – act !

Listening to developers – internal and external, is table stakes today. That is the minimum expectation. Act on it – that is what differentiates the good companies from the also rans. No one will give you serious feedback a second and third time if you don’t show them that not only did you listen, but you also acted. Act does not mean you agree with the feedback – “act” might just be telling the developers you heard it loud and clear, but for some logical reason, you have to take a decision that is not along the lines of what they wanted you to do. If you are genuine – they will be ok with that and respect you. If you fake – they will call you on it.

To act – you need authority. And this again goes back to aligning developer strategy to company objectives. If the highest levels of the company does not think this feedback needs to be acted on, who ever faces developers will just get stuck between a rock and a hard place.

6. What is in it for the company and developers ?

For long term commitment on both sides – there should be some benefit for both sides. I chose to become a developer because I clearly saw in the mid 90s that I could pay my bills and have a career being a developer. If I did not think so – I would have become an investment banker who might have coded now and then for fun. Money and career might not be what motivates other developers – it might be peer recognition, thrill of learning something new and so on. Whatever it is – the strategy should cater to it. And in reverse – the technology provider should know what they expect from developers. May be it is to harden the code base, may be it is to make better product decisions, may be it is better testing – or something else totally. But know what you want – and don’t be generic.

A strategy is only as good as your ability to execute. So don’t make sweeping statements about goals that you have no chance of achieving. It will only make you look bad before developers. If your business strategy is to have 1000 customers use your technology in 5 years – and each customer at the most is expected to use 5 applications at the most, you have no reason to target 100,000 developers to begin with. Maybe 10,000 itself is more than enough. However, if your strategy is to reach 10 billion users in 5 years – maybe you do need a billion developers to build on your technology. In the latter case – if you aim to have 10,000 developers, you will look pretty stupid.

7. Every one should carry the message – but leave execution to one team

Everyone in the company should know why and how developers matter ( or not matter if that is the business strategy). The benefits are obvious – if you look at customers as an equivalent case. Everyone from finance to HR to Procurement to legal to product management will bend over backwards if there is a customer angle to the problem they are solving. Why? because they know how customers impact the business. But that is seldom the case with developer issues. If these folks knew how developers impact the company’s goal, they can prioritize better and save a lot of time in getting decisions made.

While everyone should get the memo – it is also equally important to not dilute execution by having multiple internal teams trying to have their own strategy for developers. It is not such a difficult thing to understand – even if product managers and finance have a view on how to sell, end of the day – there is a team that is tasked with sales, and it is their call and everyone else should defer to them for that final decision. Same deal with developers – have someone with sufficient authority lead the charge. Everyone can provide feedback and help, but execution decisions should be left to that person and team. Hold them accountable by all means. There is a reason why cars have one steering and one driver’s seat.

This is not just an internal issue. Ecosystem of developers should know who they can talk to and get help. If they don’t know that – they won’t keep trying for ever to find out. They will move on to someone else who will listen and act. That is how it goes.

There are a few more things – probably MANY more things – but I am going to stop typing at this point. Weekend is over, and I need some sleep before the email flood gate opens on Monday morning. Let me know what you folks think.

Happy Onam to you all the developers out there – ok ok, non developers too 🙂