Tag Archives: Extensions

SuccessConnect 2014 – Las Vegas – initial thoughts

Mike Ettling shares SAP/SuccessFactors new commitment to inform customers

(Mike Ettling explains SuccessFactors new commitment to putting customers first)

So I’m in the lounge at LAX – the new OneWorld business lounge – it’s loads better than the old Qantas lounge, they have craft beer on tap for a start, which did lead to rather a few posts:

Which weren’t particularly related to themes I normally post on, but nevertheless probably tell you something, I’ll leave this as an exercise to the reader to speculate on what.

So whilst I’m nice and relaxed after a nice shower and looking forward to heading home, I thought I’d capture a couple of things that happened whilst I was at SuccessConnect this week, and hopefully this will also remind me to expand on them at a later time.

Firstly – customer first

The commitment by SuccessFactors to publish a roadmap to customers is a big win. And It’s not just a win for customers. As a partner it’s much easier to advise a customer when you have a good understanding of what _might_ happen in the near future. By making as much of the solution as possible accessible by the upgrade centre rather than provisioning (an ongoing effort) it removes from customers the need to engage an SI partner for what may well be just an administrative task. Allowing customers to attend the same training that partners can attend is also a great thing – so now there is a real possibility that customers can do some of their support in-house.

Why, you might ask, am I cheering this as a good thing? I am one of those partners who previously customers had to rely on to make these changes. Well, it’s really because I don’t like doing boring stuff. If as an SI all the work I do is very simple, then customers can be a little resentful for paying me as much as I would like to be paid. I see this as an opportunity to get rid of the boring work and instead focus on bringing real value through expertise. We shall see, but I’m hopeful that this is the path SAP envisages as well.

SAP a SuccessFactors company?

With Rob Enslin opening the conference, I got a real feeling of SAP being a full part of the conference, and not it being a SuccessFactors as a separate company anymore. That said, all the “Cloud DNA” was still there and it was interesting to see Lars make a guest appearance. The reaction from the SuccessFactors staff to seeing Lars was remarkable, it was all a surprise, and a nice one for most. However, Fiori making itself felt in the UI development pipeline amongst other “Simple” things shows that the “DNA” exchange isn’t just one way.

Dmitri demoing new features

Phased releases

The public announcement of a phase released of functionality, with updates being released a month earlier on the test instances of a customer is great news. This will help extension developers hugely (although ideally I’d like access to the update another few weeks before the customers get it in their test systems, but can work with this idea!) Customers too have the ability to check out any mandatory (although there are few of those) updates before they get deployed. All in all a great step forward to helping customers manage their solutions – and the spontaneous applause from the audience when it was mentioned shows it’s not just me as a developer that appreciates this.

Righto, that will do for now, Mike Ettling’s flight to Sydney has already left, and mine to Melbourne is going soon. I’ll be catching up with him and the team again for the Sydney version of SuccessConnect, but I’m so glad that I was here this week in Las Vegas, it has been great.

 

Continuous Integration vs Phased Deployment in a SaaS world

I was very interested to read some links that Naomi Bloom posted about how Workday have moved to a continuous integration deployment model rather than a phased release.

As  developer, I love the idea of continuous integration, having a set of tests that can automatically check whether the code I have built will cause an issue in production and then allow me to move it up to prod immediately. It fits with TDD and all the other cool things I want to do. Awesome!

If I were writing code in the internal development teams of Workday or SuccessFactors, I’d want the software to be CI.

However! As a developer of extensions to one of those platforms, I couldn’t think of a worse option! If you look at the “disadvantages” section in the linked Wikipedia article on CI, you’ll notice that one very important thing is to have lots of good automatic test scripts. The problem is, a vendor can only possibly run their own test scripts, they can’t run mine. (Perhaps they could run mine if such an API was built, but could they justify not deploying to prod because a little used partner extension failed a script?) So what if some change that the vendor does breaks a behaviour in my code? Well, that’s bad for me. I’d better hurry up and fix it, because all my customers are now with broken code, and the first I found out about it – when it broke. And likely I’m not going to find out until I have one of my customers complain – unless I have proactively set my test scripts to run every hour and send me a message when something breaks, in which case I’d better be ready to do emergency support 24/7. Yeah, just what I want. NOT!

This would be a huge burden on a extension provider, you wouldn’t have a stable platform to build on.

With SuccessFactors being on a phased release rather than continuously integrated to production, it is much easier for me to join in with the testing of my solution before it hits the market. I know that my customers aren’t going to get a nasty shock because something suddenly breaks/changes behaviour, because I have a window to test that before it impacts them. I also know when that window is going to be, so I can plan around it and allocate my resources. Whilst the solution might be wonderfully cloudy and elastic, my skilled pool of extension developers is definitely less cloudy and more finite and fixed.

Now it might be possible to allow partners to have an early access box, and perhaps delay CI deploys to production by a week or so to allow partners to test their code. But that is one hell of an effort that you’re demanding of your partners to do that. And as one of those potential partners, I can say I’d be thinking very long and hard about the risk you as the vendor are putting me at, and probably would decide not to go there.

I think, that in a world where purchasing 3rd party add-ons for your cloud platform will become the norm (allow me my dreams please). And where the power of the platform is driven by these add-ons/apps, having a phased release makes sense. How cool would an iPhone be without any apps from the AppStore, how good would an S5 be without apps from Google Play? They are both great devices, but they are awesome when enhanced by external developer partners. These mobile solutions have phased releases. It’s not because they couldn’t have constant updates, the tech is easily there for that to happen, but because in order to sustain the applications/application developers that make them so cool they need to provide a stable platform.

I’m really glad that SuccessFactors provides a stable environment for me to build on, as I am convinced that HCM SaaS has a huge potential to be enhanced and extended to the better use and consumption of businesses. It’s a real strength of the solution, and I am very happy to be play a part this story, and that SAP and SuccessFactors are carefully considering the needs of the development partner in this scenario.

All that said, it would be cool to be developing in a continuous integration solution, but just not for the partners building on your solution.