Will SAP be completely Hardware Agnostic in future? I am betting it won’t be.


Josh Greenbaum posted this blog making a case for HW independence for SAP. http://insiderprofiles.wispubs.com/article.aspx?iArticleId=6265 .  Josh needs no introduction, and I am a huge fan of the guy. But on this topic, I respectfully disagree with him.

 

I do agree with Josh in that the Apple analogy is not exactly applicable to keep HW and SW integrated for SAP. Jobs had to do it on the front end and hence that was a good option. SAP’s work is in the data center, and not facing the customer. So the customer experience like Apple is not applicable.

 

Hardware agnostic software was a great option when hardware was pricey, many years ago. Hardware does not command such a huge premium anymore. And consequently, software companies need to re-evaluate their strategy on what they will and will not do in their architecture. Being agnostic worked for last 30 years for SAP, but I seriously doubt if it will be the same even for the next 10.  If pushed hard, I might go on a limb and predict that SAP will do something about HW in 3 years or so.

 

SAP was agnostic to databases and operating systems too – and now that they bought Sybase and have invented HANA – is it reasonable to expect them to be agnostic to Databases going forward?  HANA works only on SUSE Linux, and not AIX or Windows or anything else. And Steve Lucas already pronounced that he will get SAP to number 2 position in database world by revenue by 2015 – which is 3 years away. Will that happen by SAP being DB agnostic? no – SAP will go against Oracle, IBM and MS at every opportunity. It is the smart thing to do.

 

Ok back to hardware – if you look at HANA, it is the hardware advances that made HANA possible today, more than software. I have seen jibes thrown along the lines of “throwing hardware at the issue”  as if HW is a bad solution. HW innovations, as I mentioned before, usually keep SW innovations trying to keep up.  If RAM did not become cheaper, and multicore processing did not happen – would HANA have happened?

 

Currently SAP supports multiple vendors for HANA hardware.  For a 1.0 product , it is probably ok to do this since nothing do-or-die will run on HANA today. But as HANA matures, SAP will need to make HANA work extremely efficiently for OLTP loads, and maybe even “real” big data (the petabytes and upwards size). At this point – will SAP try to optimize HANA for seven different vendors? or will it choose one or two? or will it just introduce its own hardware that is more optimized than every one else’s ? I am betting on the latter. SAP might never completely get rid of partnerships with other HW vendors for other reasons – but if HANA is where SAP is betting the farm, then I see no way SAP is going to remain HW agnostic in mid to long term.

 

Also, SAP now wants to be a cloud player – maybe even a leader as time progresses.  Will they buy a lot of HW from IBM and HP for that? or will they do their own HW?  Since all cloud apps are eventually planned to run on HANA – this is an even stronger case for SAP to stop being HW agnostic.

 

I think Oracle is VERY smart in keeping HW and SW integrated. Just because SAP competes with ORCL is not a good reason to say stacks are bad. Oracle is a very good and successful company too.  Going forward, I do expect to see a lot more similarity between ORCL and SAP in how they create solutions.  To retain leadership, these companies will need to lead with both HW and SW.

 

 

 

 

 

 

 

Rapid Implementation – is the promised land finally here ?


Mike Krigsman posted this today morning on his ZDNET blog http://www.zdnet.com/blog/projectfailures/predicting-2012-rapid-implementation-in-focus/ . I tried to post a comment, but somehow that does not seem to have posted. So I thought of posting it here.

 

I am not entirely convinced that Rapid Deployments will bring terrific benefits, but will be watching it closely in 2012.  At the moment , I have apprehensions.

 

1.  If faster implementation is such a big agenda item for Enterprise Software vendors, why do this half way approach of Rapid Implementation? Why not go all the way and offer it as SaaS ? Is the idea to milk perpetual licenses for on-premises software for a bit longer, just by repackaging it?

 

2.  Fixed price is a good thing – but hardly unique. Most ERP projects now are following a fixed price contracting structure. I know no one likes change orders – but change orders happen mostly because of scope definition inaccuracies. Projects are progressive in nature – especially ERP projects. So even in Rapid Deployment, at some point – customers will find out they will need something else on top. Will the software vendors provide such changes for free without a change order? If not – will customers feel happy just by paying a software vendor instead of doing it inhouse or paying consultants to do the work?

 

3. Consumerization of IT – making IT “sexy” and “easy” – is a good thing for the business users. However Rapid depolyments only solve a part of this problem, which is the installation part.  While it is a good start – will customers see enough value with just one part of the puzzle solved?

 

4. Rise of CFO’s office is definitely not a 2012 thing. CFOs have always taken active role in IT (and other) investment decisions.  CIOs very rarely report to CEOs, they either report to CFO or to Chief Procurement Officer.

 

5. Who supports Rapid implementation solutions after the vendor walks out of the door? Will there be enough skills in the market for outsourcing companies to provide such support?

 

6. What about integration costs? Stand alone systems always cost more in the long term. Once the rapid implementation goes through enhancements and integration with existing systems – will it offer any benefits beyond other on-premises solutions from the same vendors? And if you enhance a prepackaged solution – will a vendor still provide standard support ?

 

Happy New Year !

 

SAP Mobility solutions – Should SI’s play or stay on sidelines?


As many of you know – all my professional life, I have worked for System Integrators – both big and small. And as a result, every time there is something new in enterprise software, I am curious to see if SIs have any role to play , or whether they should just sit it out.  Of everything SAP has come out with in recent past – HANA is the one that got the most air time from SAP and the analyst/blogger community , but I think mobility is the one that will drive the most revenue for the ecosystem in short to medium term. It does not need a lot of convincing to do to get a customer to agree that mobile solutions are the future.

From the consumer side of the world – most mobility apps have typically been built by independent developers, and not by big IT houses.  For Enterprise side – especially for SAP – we need to think through if that is the model that will work exactly that way.  I am a big fan of SAP opening up platforms to developers – as long as developers can do cost effective development, protect their IP and make some decent money out of it.  And along with a bunch of similar minded people – I have been trying to push this message for some time at the highest levels at SAP.

But is there something here for SIs ? I think there is plenty of the mobility pie to go around. Here, I will ignore  the obvious stuff that SIs will do – the mobility strategy, device management , security and so on.  Those are important, but  don’t need added color.

For building and reselling apps – it is hard for SIs to compete on cost with independent developers if the platform is inexpensive.  BUT – Platform access is not inexpensive now – so SIs have an upper hand temporarily till SAP gets its act together. But I can’t imagine SAP not changing this in 2012.

But for the cost to work in SIs favor – they will need to find a killer app that can be resold many times over.  This usually needs the SI to create a few with the idea that some will click, and some will not. This is not consistent with existing SI business models. SIs have a big opportunity cost to consider – every hour spent developing such an asset is an hour they are not doing billable work. So it remains to be seen how many will jump in with both feet.  The bigger SIs probably will do ok – since they have significant abilities to invest, and can wait for longer pay back periods. But in general – I don’t see large number of SIs playing seriously on building such apps.  In everyone’s best interest – this is best done by independent developers, in my opinion.

For SAP systems – a big problem for building generic horizontal applications is that most backend systems are heavily customized.  A consistent abstraction to the outside world for non-SAP developers to use is not always possible.  So, even if a developer creates a generic enough mobile app – in most cases,  there will be a need to do some back end plumbing to get it all working in a useful fashion. This is the model I see evolving in the market from maybe 2013 onwards. Independent developers building the front end apps, may be even contracted by SIs to do so – and existing SIs doing the integration to backend.

Where I see big and small SIs both having a great advantage is building end-to-end mobility solutions for a specific client, especially where the SI has long standing experience.  Ideally – these should be vertical for an industry, and can be leveraged across many projects. This needs a large set of skills to come together – deep industry and sub-industry knowledge,  business process design, UX design, development in multiple technologies, basis, security, industrial strength testing and so on.  This is totally a sweet spot for SIs – and I would expect them to be all over this. And the beauty of this is that there is a production support opportunity right after the implementation, which is again a sweet spot for many SIs. The trick here is that this can and should be done for specific only very high value usecases – something where customer realizes significant value.

Now – for all this goodness to happen, there are a few things SAP need to play well too.

1. Make it easy for regular developers to use SAP platforms to build apps – not just the development, but the whole lifecycle of IP protection,  testing, certification, monetizing, maintenance, support and all that good stuff

2. Keep SAP Education on the front, and not the back of innovation. Unless the ecosystem comes up to speed on the latest greatest technology – it does not matter how cool the innovation is in the labs. Maybe even throw in some inexpensive education for select ecosystem partners. Basically – do what it takes to get partners/developers to trust SUP is the way to go, and get them away from everything else they are using today. This includes ironing out any wrinkles from existing software, and educating developers on roadmap for future.

3. Actively partner with SIs – and I expect this to be totally opportunistic depending on lay of the land – to push mobility solutions at the thousands of clients world over.  For significant mobility sales – the attitude of “Business gets it, IT doesn’t ” should be left checked at the door. IT gets it alright – and usually have valid concerns on security, scalability etc. Work with IT to address their concerns and gain their confidence.

4. By SAPPHIRE Orlando in 2012, have several customers come up and talk about their mobility solutions to the world.

5. Make sure licensing for customer is scalable and not a total rip off.

6. Try not to drown the mobility message with HANA and others