Post SAPPHIRE NOW musings


SAPPHIRE was way cool – one of the most well-organized ones, and I enjoyed it very much, despite the extreme sleep deprivation that I had to endure. In general, I was quite excited with SAP’s messaging, and analyst commentary. But as soon as I left the convention center, I started thinking more about the messages I heard at SAPPHIRE, and I think I am not as excited as I was a few days ago. It was a mixed bag. Please check my blog I posted when I was on my way to Orlando. http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/19247

Let me start with Sybase. For one – SAP paid a huge premium for Sybase. The only reason I can think of is that SAP fears some one else like ORACLE or HP might be ready to buy Sybase, and in the process put roadblocks to SAP’s way forward on enterprise mobility. SAP claims to have figured out in-memory data bases even before Sybase story came out – and Sybase is nowhere near the top-tier of enterprise DB market. Even in SAP ecosystem, I think Oracle and DB2 have the lion share. So this is not going to help SAP rule the DB market. On Analytics – SAP has BOBJ, which is top of the line. So it is hard to imagine that they need more from Sybase. So mobility is the only reason that is worth SAP paying this premium. But why pay that much when Sybase is already a big partner, and is committed to building SAP specific solutions? 

Where this makes it confusing for me is that on one hand – SAP swears that they are committed to all the partners having an open level playing field. On the other hand – if a client gets a mobility pitch from a partner and Sybase tomorrow – which one will they choose? In today’s world – Sybase solutions are SAP CRM specific from what I know – and there are other partners that do other things. Post acquisition, I am pretty sure Sybase will become the de-facto standard.  This looks like a repeat of BOBJ story in analytics world – it is true that other BI partners can still sell to SAP customers, but what is the long-term value proposition for non SAP BOBJ vendors any more when they sell BI to primarily SAP shops? 

SAP cannot buy every company around – so of course they need partners to build things around their solutions. So I am not surprised that SAP reiterates its commitment to keeping it an open field for every one. But won’t partners now feel a constant fear that after they have invested in SAP solutions for a while, SAP will buy one of them – and leave others by the way side?

Now on to HANA and in-memory. I was super excited to hear that SAP is taking this route, and that they have something that customers can sign up for right away. On the flight back from Orlando, I posted these questions on my SAP blog and there has been some good discussion around it. http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/19339 .  Technical questions apart – SAP is a relative late entrant into this market. So calling it innovative is a stretch. Hasso had this idea a while ago. So what prevented this from getting productized for so long?

It was great to hear that Business By Design is finally ready for prime time. SAP also has a lot of side benefits due to this – they probably figured out how to scale with Agile, something that I am very keen to find out. Please check out the great discussion I had with Enterprise Geeks at http://enterprisegeeks.com/blog/2010/05/19/sapphire-agile-throwdown .Another plus is the use of Silverlight, a Microsoft technology that I think is superior to all the SAP UI tools currently available. I am fully bought in on Vishal Sikka’s position that SAP has way too many UIs to use just one common tool.  but for all the good things – SAP leaders made a statement that sounded like “we do not have a firm target for growth of BBD “. Really? Would you just throw billion dollars at something that you have no real expectations for? Had to swallow that.

I just think it is plain funny when SAP talks about sustainability in these big events like SAPPHIRE. This is an event that makes such a lot of carbon emissions – high energy use for the many display gizmos, the jet setting executives, and many vendors and participants who fly to get there, and the massive air-conditioning that keeps participants alive in Orlando heat and humidity. Al Gore, Powell and the Virgin guy didn’t drive their hybrid cars to get to Orlando, did they? And did the SAP top guns fly commercial between Germany and US to appear at the concurrent events  or did they fly in private jets? So yeah – it is very hard for me to buy into the whole sustainability pitch. It sounds hollow .

SAP is clearly in the top bracket of companies who have figured out how to use social media to its advantage. SCN has 2 million members and the SAP mentor program (of which I am a part) provides excellent input to SAP for free. SAP has a blogger program – which I think pays T&E for bloggers to come to these events, but in no way forces these bloggers to let go of their objectivity.  And twitter helped several of us keep track of the massive event. That is extremely forward thinking and admirable. They are leading from the front – and other companies should watch and learn.

Finally, a couple of things on the leadership front. First and foremost – Hasso is still SAP’s superman. None of the others evoke the kind of passion he delivers. Bill and Jim are a perfect pairing – and I think SAP made a wise decision to do the Co-CEO thing again, especially with these two guys. And Vishal Sikka has all the qualities of a great tech visionary – and like the taste of good wine, his message gets more and more clear to people who follow SAP as time passes. I used to think John Schwarz was the next big leader at SAP – but I was wrong. he left, and probably took some of his trusted guys with him. Now with Sybase comes its CEO John Chen. He is an amazing leader – some one who successfully turned around Sybase and kept it growing despite a terrible economy. Will SAP manage to keep him and his team or will he too leave one day soon after the acquisition? I am very keen to see how that unfolds.

Software companies , Innovation and On-premise


You cannot walk on the street, or browse on internet, these days without some one screaming “innovation” on your face.  Software companies lead the pack here – not only do they use the word “innovation” ad-nauseum, they also take time to explain why their competition is not using “innovation”.

Read this excellent blog by Dennis Howlett  http://www.zdnet.com/blog/howlett/saps-innojagd-dont-laugh-this-is-real/2059 . Dennis is known to give software companies, including SAP (He, I and Craig who is mentioned in the blog, are all SAP Mentors), a hard time on the incessant use of the word “innovation”. After reading his blog, I wanted to put in my 2 cents as well.

When do we call something innovative? I would think that, it is innovative when something changes for the better – in a significant fashion.

When you are working on a project – your aim is to make something better. But you don’t know if it is better or innovative, till your customer uses it and acknowledges it as better than status quo. So does that mean all projects are innovative? I would say no. It is an after the fact issue – a lagging indicator.

I don’t think it makes sense to say “I am working on an innovation project”. Every one is working on projects that can claim to be innovative – but only the ones that make a meaningful result at the end can claim to be innovative.

I read somewhere that Edison had to do few thousand prototypes before light bulb was invented. Do we say that Edison worked on 2000 innovation projects that failed? or do we give him credit for one great innovation?

So in my mind – I would consider it a total marketing buzzword till such time as software companies can say something like ” here is how this product was when it came out, here is what we changed 3 years ago, and over the last 3 years – our customers gained 20% cost benefits due to this. And we have several such cases which we can demonstrate value-add measured by independent sources.  This proves we are known for innovation, and you can trust us to make better and better stuff for you as time passes”.

A closing comment on “On Premise” – as in “On premise vs On demand”. I am told this die was cast and it won’t change – but doesn’t premise mean something like an assumption or a hypothesis? And hence shouldn’t these people start saying “On Premises” or even “On the premises” to denote a system that is local as opposed to, say somewhere on the cloud.  I am not a native english speaker, so I will gladly stand corrected if my premise is wrong 🙂 

So what do you think about this? I am very keen to hear your take on it.

South beach diet didn’t work for me, and neither did Agile development.


Normally, I would write this in my SCN blog – but this is not about just SAP projects, I am going to do it here. As always, these are strictly my personal opinions – not that of my employer.

Some of you have seen me  – at work, at some tech conference, dog show or at an airport. I doubt if “Agile” was the word that came to your mind when you met me. I could easily lose 20 pounds and have some one ask me “hey, why are you not doing something about your weight?”. You get the idea. I have tried many a weight loss / excercise plan – and have  come to the firm conclusion that the magic bullet for weight loss is to eat less of everything I like (Rice, red meat, fried food) and excercise more.

In parallel, I was going through a similar excercise at work – trying to find an optimum way of managing the projects I get to run. I have read and tried several different things over the years in a variety of projects. Over the last couple of years, I have been fascinated with Agile development and hence I have been reading, talking to others, and trying it out in teams I manage – and again, I have  come to the firm conclusion that, just like the various dieting schemes – Agile also does not work for me.

This is not to say Agile does not work for others . South beach diet must have worked for others, and I am sure Agile would too. For me – no sir, I will pass. That being said, let me explain why it does not work for me.

Would you pay an Agile contractor to build your deck?

I need a deck built, and I don’t know how to build one. So I hire some one else to do that. And this dude tells me he can do it one of two ways. 1. I can discuss with him on how a basic deck has to be built, and he can give me an estimate. Or 2. I can give him a rough idea, and he will start building the deck, and every day or two – he and I can get together to see how it is going and what changes I want, and I can pay him for work that he has done every day. Of course in the second option, he cannot tell me how much the deck will cost me or how long it will take him to build me one – but I can see progress every day. I don’t know about you – but I know what option I will go for.  Same thing with my clients – if the work and schedule are not predictable – it is hard for them to just pay as I go.

Global and Agile are like Oil and Water – They don’t mix.

I forgot the last time I had all the IT and Business guys and gals working in the same location.  Most often – we have people working on a project from all over the globe. It is seldom possible to get teams from Japan, India, Germany and US to be on a conference call. And even if you do – without a written document explaining the problem and/or solution – it is hard to get anything done. 

There are only so many super stars in this world

In any given team, the norm is to have a few super stars, several average performers and a few below average ones. This has a direct effect on pulling off delivery in an agile fashion. Not every one can go away with minimal instructions and come back with the right solution, and right questions to ask for next day. 

It can be argued that Agile needs less programmers, and hence you can keep just the super stars and let go of every one else. This argument works only if the scope is small.  The day still has only 24 hours – and even super stars  cannot work 24X7  all the time to get everything done.

Most projects do not have dedicated business users.

The whole idea of Agile is to get something back to business users faster than in a waterfall model, and keep them informed of progress frequently. This is very good – except it won’t happen in most projects. Most companies find it hard to dedicate full-time business people to a project. More often, business users have to do project work on the side. So – even if the tech  team wants constant face time , the chance of that working out is low.

A few product companies have tried out Agile successfully. However, in the couple of cases where I got a chance to talk to people from the team – it seems, the customer was almost never present in the scrum meetings. Instead, the product manager assumed the role of being the customer voice. If that is the case, I would have to wonder aloud “so what is new?”.  Product manager is not the one who has to live with the product after it is out – it is the customer.

What works for you –  people over process? or process over people?

This is what it boils down to – Agile manifest claims the superiority of people over process. And traditional waterfall puts process over people. For me – as a manager of big teams, with a deadline and budget that seldom cuts me any slack – I would trust a good process to compensate for the human errors most of the time. I think it is a high risk for me to trust that every one in the team will perform to the same high standards. Having a disciplined process helps me get the best out my team, despite not every one being a super star. 

Would you build a mission critical solution using Agile?

I don’t know – but I keep wondering if NASA would use Agile for designing systems for their next space mission? I somehow can’t see any application that is very important and deals with life and death, or dealing with large amounts of money – like air traffic control or stock market transactions –  to use Agile.

I hope every one knows about 3C. This was the big Chrysler project that was the poster child for XP (Extreme programming). Well, guess what – that didn’t quite work out. Check this out http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System  or just google and you will find several interesting takes on it.

Building a car and building a software solution have similarities in design. However, there are significant differences too. Just as it is impossible to build a car without knowing what exactly needs to be built – we cannot build a good software solution without knowing what the heck we are building. Otherwise, even if you follow Toyota manufacturing Process to build a Camry – you could end up with a Chevy Malibu.

Is Agile really good for long-term stability of a solution?

Most software is built by first putting a framework in place, and then building on top of it. It is the rough equivalent of putting a good foundation for your house. If you know that you will have a house with 2 floors – you will probably put a certain amount of concrete in your foundation. Now that you have finished the house – and for some reason, you now want one more floor – would you put one more floor without also doing some additional foundation work? And if you build by constantly messing with your foundation – I am definitely not going to buy that house or rent it for living.  Same thing with software – the way sprints happen from what I have seen, I doubt if it is possible to put a solid foundation in place.

It is fun, but is that good enough for customer to pay?

One thing I really like about Agile is that every one involved in it usually has more fun than in a waterfall project. This improves team morale and all the good stuff – temporarily. When you cannot get user involvement, or if a blame game starts – where there is no documentation to go back and clarify what every one agreed to, this fun does not always last. And fun for the development team, while important in a project, is not the sole reason why some one pays for a solution.

Waterfall is not such a terrible thing to do, as its opponents make it to be. And it is a big exaggeration to say the team does a very long design up front, and that user gets to see things only at the end. That is not how most projects run. Waterfall can also have users involved more frequently. Also, you can build in plenty of  feedback options and test driven development in a waterfall project. Also there are very strong visualization tools that can give the users a taste of the solution very early in the process.  For example – iRise is a great tool to use for that. Do try it out, and your whole perspective will change. Also, once you have a good change control process established, changing requirements can be handled very effectively.

So, when do I think Agile would work?

Despite all these points above, I am not an extremist when I think of methodologies.  In my opinion, Agile is going through a hype cycle exactly like how it happened with SOA.  Once the hype died down a little, we mostly figured out what is possible with SOA and what is not. SOA is great for several use cases, and terrible for others. Same is the deal with Agile.  Just because Agile possibly has the issues I called out above, it should not be inferred that Agile should not be used. If you have a bunch of highly skilled people, where the team has a clear vision of the end product, and/or where time to market is not such a big deal – all these challenges will vanish. Such a team can probably come out with a great solution using Agile. But in the type of projects I am dealing with – I don’t think Agile can succeed. 

Rather than take an extreme view of either/or – it is probably best that we let individual projects decide the methodology they want to follow.