#SConnect15 – SuccessConnect 2015 Sydney Day 1

I think perhaps my photo taken on the way to the airport this morning sums up today pretty well.

An empty road with a whole bunch of speed bumps. I’m afraid that’s what today felt like. It’s kinda weird starting off a conference without hearing the keynote to set the tone. Even with SAP conferences like TechEd we have “pre-conference” days – thanks ASUG! But today was part of the conference, and it didn’t really feel like it.

An example of the bumpy road was having a session today on the new support model for SuccessFactors, but without mentioning the SFXpert program. It was kinda weird – but apparently Mike Ettling will talk about that in the keynote tomorrow, it’s a little confusing.

Moreover, there weren’t an awful lot of people here. Which in someways is pretty good, it means that we’re able to have comfortable conversations, no running around with microphones to ask questions. But it certainly seems that running a SuccessConnect in Singapore may have reduced the number of Sydney attendees. I’m not sure, perhaps tomorrow will bring more people? It was a big ask to get people to come for a whole day for 3 sessions.

But it was a glorious evening in Sydney:


and we’re keeping on going with the saving of Elephants and Rhinos with the corporate social responsibility thing

Would love to know where we’re at with that total – hopefully we’ve got above a few thousand dollars by now.

So a few bumps, a fairly empty road, but the way ahead looks clear, and the weather is glorious. I look forward to tomorrow. I just hope that the panel session with David Ludlow goes well. 🙂

we shall see.


Further update on SAP Gateway CSRF token farce

So an update on recent rant about CSRF protection that isn’t needed on SAP Gateway.

The folks in the very attentive HCI team have just added functionality into their solution, so if you configure an OData call to an onPrem system via SAP HANA Cloud Connector, it will automatically do the GET with a fetch for the CSRF token for you whenever you configure a data update operation.

That’s kinda cool, but all it does is sweep the offending rubbish under the rug.

https://www.flickr.com/photos/bruce_krasting/7695348682 - Sweep under the rug, credit Bruce Krasting

https://www.flickr.com/photos/bruce_krasting/7695348682 – Sweep under the rug, credit Bruce Krasting

So now we have logic built into an integration platform that is needlessly slowing our integration flow because of a superfluous system requirement. An extra round trip for no reason.

In this case it is truly superfluous, because the original PUT that I was using had the user credentials as part of the header. That alone should make the CSRF token not required.

What this does show, is how SAP Cloud solutions like SAP HCI are able to update and fix stuff far faster than their onPrem partners. Even if it is a work-around to a problem that shouldn’t exist.

Herding cats, or managing GitHub issues – Waffle and HuBoard considered

Today I needed to decide on a tool to use to manage GitHub issues. I’ve got so many of these now-a-days that it has become quite hard to decide which one to work on and also to communicate to others which ones I am working on.

So I turned to some of the simple Kanban board visualisations of GitHub issue tools that I’ve seen. There may well have been others (I’m pretty sure that it’s possible to get Trello to work with GitHub) but I wanted something that was simple.

I ended up comparing waffle.io and huboard.com .


I found that HuBoard had in many areas some cool functionality that could well be something I wanted. In particular it has the ability to mark a task/issue as “ready for next stage” and “blocked”. Blocked issues are particularly important to me – so having this clearly visible is important. Additionally HuBoard claims to have existing integration into Slack – that would be pretty cool, but given I already have GitHub integration into Slack, I’m not sure it’s needed. Would have been nice if the web-site had shown what that integration actually was, as that is something that could really decide me one way or other.

HuBoard has a nicely minimalistic view – more inline with newer design patterns like Android material design, SAP Fiori. Labels on issues are small colour coded lines that appear when you hover over them.

huboard design

It’s quite neat and tidy. It also has a cool “fade away” filter option that just fades out un-selected items rather than removing them (two clicks removes them). However, clicking the same button multiple times to get different affects, I’m not sure that’s really a great idea. I’ve definitely been slapped over the wrist for bad (and not very accessible) UX when I’ve done similar things in the past. But technically and from a usefulness stake (if you understand what you’re doing) that’s a pretty cool feature.

However, I there were some concerns – when I loaded the HuBoard site on my phone it was good to see that it adapted responsively to the space available and listed the items rather than displaying a grid (well, I’m still debating if that was good, but at least it was responsive.) However, when I then clicked on a issue:

mobile huboard issue small

Yuck! that’s not usable.

Edit: NB see note following stuff documented in following section about privacy has been changed.

I then looked at the site to understand what the privacy policy was:

privacy policy from HuBoard missing

The only info on the site was “This Application collects some Personal Data from its Users”.

I’m pretty sure this is because of HuBoard not paying someone for their generated policy:

huboard policy issue


However, I tweeted at HuBoard:

And as at time of writing this post, haven’t had a reply. To me, if I’m going to trust a cloud service, I need to be able to understand what it will and won’t do with my data. A non-working privacy policy page on the main site is a BIG #fail. Then not to respond to someone @ mentioning your twitter handle is a mark of the kind of service that I might expect if I was a customer. Not great.

Edit: so none other than the founder of HuBoard reached out to me. Privacy policy is fixed. It looks pretty good too, most of it is in plain English not legalese. Guess timezones for USA meant they were sleeping. The founder reaching out, that’s pretty good customer service. These guys will hopefully do some great things!



I looked at Waffle.io. Now bizarrely the thing that most scares me about that product is its price – $0. I’ve learnt, if I’m not paying $ for something, then I am the product. I’m not sure if Waffle.io is still in beta/investor funding and is happy running without making any money but perhaps just piling up the company valuation? This whole SaaS valuation model sometime confuses the crap out of me. When you consider that companies the size Workday have profit margins of -24% (I mean WTF ?) It’s quite conceivable that charging money right now doesn’t boost the value of the company as much as having more subscribed users. Still paying nothing for something just makes me want to look for the catch. But I couldn’t really find a catch (I imagine it won’t be free forever and that payment will be required soon, but if it’s in same sort of price point as HuBoard then this shouldn’t be an issue $24 a month to be productive is not that bad!)

Waffle has some feature that I thought were pretty good, but specifically I liked the “size” attribute for an issue. By using this I can ensure that for each stage of the Kanban there aren’t too many issues being dealt with. So it can be fine to have quite a few small issues, but having the same number of large issues could cause a problem.



at the top of each column was a counter showing the number of issues and the total size. Next to my lovely picture was a number showing what I thought the size of this issue was.

This functionality I like, it will help manage all the issues and ensure we’re not going crazy pushing so much to into testing without actually testing it.

It was also nice in Waffle to be able to see the number of comments an issue has – it’s often worth drilling into those issue that have a lot of comments, even if it’s not yet my issue.

However, compared to HuBoard the amount of information shown can result in a quite busy screen – for example from Waffle’s own GitHub repo…



Personally, I didn’t mind the “noise” but others I spoke to thought perhaps the minimal style of HuBoard better. Since I often have so many labels that colour alone is going to be an issue, I think I prefer this layout.

In contrast to HuBoard the mobile interface is not at all responsive, you see the same site but just zoomed out so you can’t read anything. That said, pinch zooming and scrolling around on the phone isn’t hard, and it does give you a better perspective of how the lanes compare. I’m pretty sure that there is probably a better responsive layout that could be adopted. But compared to the rendering mess that happened in HuBoard when accessing from mobile, it was much easier to use the Waffle site.


You can probably see where I’m heading! I decided to go with Waffle for the moment, but I’ll keep an eye out for HuBoard. As with all these SaaS apps, iteration is the name of the game, and I’m sure that feature parity won’t be far off. Neither tool has an Android mobile app, but neither tool is very usable on a phone – so perhaps when one of them makes that leap it will differentiate itself. We shall see.

After I’ve been using Waffle for a while, I’ll perhaps write another post about “real life” experience.




Security in depth – or a bug waiting to happen? – CSRF protection on SAP Gateway

What's that - It's the dragon that guards the locked door, we feed people who ask silly security questions to it

What’s that? – It’s the dragon that guards the locked door, we feed people who ask silly security questions to it.


So I’ve got my knickers in a twist again. Recently I was playing around with sending some OData to my SAP server when it refused me. Now, I didn’t like that, but at least it was kind enough to tell me why. Apparently I hadn’t fed it a CSRF token. OK, so I looked in the headers of the GET that did work, and lo and behold there was a CSRF token there. I fed that into the POST I was doing, and bingo it worked.

Now it seems to me that many many people have hit the same thing and found the same solution. Indeed, I asked around some people I knew and they told me: “Get over it Chris, it’s in the header of your GET, it lasts all session, just use it!” But me being me, no, I wouldn’t accept that!

Slight aside – they also mentioned “Damnit, I remember when that patch came in, it buggered up my custom Gateway app and I had no warning that it was coming, took me ages to figure out why it wasn’t working.”


So I thought – OK? Why? Why do we have CSRF protection in the first place, what on earth is it?

CSRF protection – Cross Site Request Forgery protection, according to the websites I read is supposed to protect against the case where unknown to a user a cookie in the browser used for authentication allows a malicious site to alter data on your system. (And in the case of gateway, your SAP system).

So to send a PUT or POST or DELETE (the verbs that can change data) from a browser without user knowing is going to involve 1 of 2 things.

a) An injection of HTML on the page adds either a form that is going to POST some data (typical type of attack  CSRF protects against) or a link e.g. img tag which GETs data.

b) An injection of some script, e.g. JS on page that is going to do the PUT/POST/DELETE

In the case of (a – POST) the payload will be malformed and Gateway isn’t going to accept that as valid OData – so no security worries anyway. And for (a – GET) CSRF protection isn’t even applied.

In the case of (b) well if I can embed JS, I can just as easily embed a GET pull the header and then do an update with the CSRF token. Indeed the sites that advocate for the CSRF token approach make it clear that it cannot protect you in the case you have malicious Javascript.

In the case that the script is running on a page from a different domain, then CORS will kick in and stop the access – but if somehow the injection is on my own domain, I don’t see how we’re protected.

So I was at a loss. What protection does CSRF actually offer Gateway?

I further researched:

There’s a great explanation, which does better than I have at:

Play Framework

It is recommended that you familiarise yourself with CSRF, what the attack vectors are, and what the attack vectors are not. We recommend starting withthis information from OWASP.

Simply put, an attacker can coerce a victims browser to make the following types of requests:

  • All GET requests
  • POST requests with bodies of type application/x-www-form-urlencoded,multipart/form-data and text/plain

An attacker can not:

  • Coerce the browser to use other request methods such as PUT and DELETE
  • Coerce the browser to post other content types, such asapplication/json
  • Coerce the browser to send new cookies, other than those that the server has already set
  • Coerce the browser to set arbitrary headers, other than the normal headers the browser adds to requests

Since GET requests are not meant to be mutative, there is no danger to an application that follows this best practice. So the only requests that need CSRF protection arePOST requests with the above mentioned content types.

Since Gateway does not support POST requests with bodies of type application/x-www-form-urlencoded,multipart/form-data and text/plain (or if it does there’s your problem right there!) there is no need for CSRF protection.

I then had a fun conversation on Twitter with Ethan

The great thing about chatting with Ethan is you always come out having learnt something.

He makes a good point, and I’ll paraphrase him:

“The best security is deep and many layered and protects not only against the things that you know may happen, but also against those that you’re pretty sure won’t.”

I was wrong –  “to send a PUT or POST or DELETE (the verbs that can change data) from a browser without user knowing is going to involve 1 of 2 3 things. With the third being:

An exploitation of a hitherto unknown browser bug that allows it.

So now I’m confused. Is it worthwhile implementing the hassle that is CSRF protection, including the potential slowdown in speed of response from the solution (a paramount concern in a mobile app) for a situation that might happen.

When I’m writing ABAP code, I’m happy to trade away performance of the code for ease of maintenance. I don’t use pointers (field symbols) to loop over data that I do not intend to change, because some fool could come along later and accidentally do just that. If I instead use a work area, there isn’t that risk.

So in some respects I already do work that makes the solution slower to ensure lower risk, so shouldn’t I just do the CSRF thingy?

However, it is the reason for the risk – I don’t trust that the people maintaining the code after I leave will understand what I have done in my implementation of CSRF protection and won’t make a mistake. Even if I’m using UI5 in my application to update my SAP system, will they remember to call the refreshSecurityToken method every time before a PUT, POST or DELETE? Will they test it? Will they let the session expire in the testing so that they actually need to call the refreshSecurityToken method? I really hope so, but I doubt it. I see applications going into error and data not being updated when it should have been, because of “needless” CSRF protection.

weighing Dodgy Code vs Browser Bug risks

weighing Dodgy Code vs Browser Bug risks

So what I see is this: Security in enterprise is paramount, Gateway is enterprise software, it needs to be secure. So SAP made it so, even if it hasn’t really made a big difference or fixed any known security holes. But, “just in case”. However, custom code (and even standard code 😉 ) will have bugs, ones that rely on sessions timing out are particularly hard to test and will get through. The risk to your Gateway based mobile app is greater by having CSRF protection enabled than it is to your data being maliciously hacked through zero-day exploits. But I guess it depends on what that data is 🙂 .


OK, one final bit…


Given that I might not actually be using my Gateway for a UI app but for machine to machine transactions, would it PLEASE be possible that if I provide a valid authentication header in the PUT/POST/DELETE that we ignore the CSRF thingy? If I can somehow come up with a valid auth header, then we aren’t protecting anything with a CSRF token, we’re just making transactions slower by requiring multiple round trips that shouldn’t be needed.


I feel better now. 🙂


Read how this discussion unfolds over at SCN…


P.S. my last post from SCN comment thread as I think it’s an important summary:

The thing is, by not implementing CSRF protection, we aren’t making our services insecure. There are no known ways to use CSRF against Gateway currently.

There is the case of protection against unknown attacks, but is that worth the cost, risk, effort?

Not using CSRF protection does not mean you are making your service insecure. It just trading “just in case” against real life complexity, risk and cost.

Depending on the data concerned, that “just in case” might be worth it. It won’t always be.

Architects have a responsibility to their companies to balance these risks and decide. We have the responsibility to inform them clearly and not just pretend that security is the only and overwhelming factor to consider.

Sometimes we put security on a pedestal and everything has to be done to address it. But we should remember that everything should have a risk/reward curve and sometimes NOT coding for a security risk is actually less risk than coding for it.



End the annual performance review: APIs to your social influence

Ok, I know, I’ve been writing about ending annual performance review for ages, and people are still doing them.

I actually had a very interesting sit down with Steve Hunt, SVP customer value at SAP where we talked about our differing – but somewhat similar views. I want to do that chat justice with a “proper” blog, today is just a quick response to something else.

My fellow SAP Mentor  posted an interesting piece about some extracts that he’s been using to explain the impact of his social networking and how it is an effective performance indicator for use in his annual review.


One of his comments got me thinking – wouldn’t it be great if not in an annual review, but just in a dashboard we could see something like performance via api

We could visualise the areas of influence in our team, and how much they were spreading that influence. Would this be a help for me as a manager to help understand if the strategies I’m putting in place make my team more effective as doing their job? We could take these feeds from any tool, from email, from Jam, from public social media, obviously with employee consent!

Now you could argue that my team doesn’t need to influence, that isn’t part of their role, but I’d have to disagree. Even if my team worked at the checkout counters of a local supermarket, I want them sharing what and how they do things best. Any team which is not spreading news about what they are capable of doing, and doesn’t share with others is a team which is not reaching its potential.

Perhaps in many situations it will be hard to find APIs that can express how knowledge sharing is happening, how influence is being generated, noting who is chatting about what over the lunch table and turning that into a graph seems a bit of overkill. But where it is possible, this is definitely something I think we should be grasping firmly. Let’s start building this into our talent management solutions, who knows, we might actually start finding out who is “talent” in our organisations and nurture them, rather than waiting annually to see if anyone has been innovative enough to try to capture this info. No more annual review, a constant monitoring and performance enhancement process. I dream, I know, I’ll write about it more in full later.

Right, back to writing Christmas cards and eating mince pies 🙂

Multitenant Spring Data JPA with EclipseLink on SAP HANA Cloud Platform

Just a quick post here today, and hopefully I flesh out a more detailed post on SCN later:

OEM model

There are probably two ways to make money developing apps on the HANA Cloud Platform:

1) be incredibly good at it, such that you can build truly awesome stuff that customers aren’t going to care about platform costs and still pay you bucket-loads

2) use the OEM model and build very efficient apps that solve a little problem for lots of people. Keep costs low, and sell to lots and lots of people.

3) be big consult, wine & dine the people with the money, put loadsa people on simple projects bill lots.

I’m aiming for a mix of 1 and 2 to just get into the sweet spot, of course that’s hard work. But this evening I made a step in the right direction by enabling multi-tenant access to one of my apps that auto-magically put the tenant key in all DB accesses in my app – without me having to do any work to specifically write that into the queries.

for reference the magic happens with a custom implementation/extension of JpaRepositoryFactory, JpaRepositoryFactoryBean and SimpleJpaRepository and one line in my Spring xml:

<jpa:repositories base-package=”com.wombling.blah.blah.dao ”
factory-class=”com.wombling.blah.blah.multitenancy.MultiTenantJpaRepositoryFactoryBean” />

my custom tenancy resolver:

public class CurrentTenantResolverImpl implements CurrentTenantResolver<String> {

	public String getCurrentTenantId() {

		InitialContext ctx;
		try {
			ctx = new InitialContext();

			Context envCtx = (Context) ctx.lookup("java:comp/env");
			TenantContext tenantContext = (TenantContext) envCtx.lookup("TenantContext");

			return tenantContext.getTenantId();
		} catch (NamingException e) {
			return "NOT_CURRENTLY_RUNNING_MULTI_-_TENANT"; // 36 chars as per real tenant id


is called each time a DB query is made (which is already pretty invisible due to “magic” of Spring data and JPA.)

I have to give a huge shout out to   from Slovakia who posted up most of the code I reused. Thanks dude!


I’ll get back to you with some more HR type stuff later.


iOS – not quite the Enterprise developers’ best choice

I was recently at a conference where there was a big cheer from the audience when the vendor announced that they were moving away from a model of updating all the customer’s development/test and production systems 4 times a year, to a model of still doing quarterly updates, but updating the dev/test environment one month earlier. The crowd cheered. Wow! (The conference was SuccessConnect, the product SuccessFactors and the vendor SAP, but that is irrelevant for this particular post).

So why on earth would people want to get their software updated later? And why would such a change cause them to cheer? It’s quite simple really! Risk reduction.

risk reducer


Reducing Risk

To quote Donald Rumsfeld “there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know”. Whilst it’s blinking difficult to deal with the third category of “unknown, unknowns”, it’s much easier to deal with the known unknowns. In our case of software upgrades, we know that there are likely to be changes, but we aren’t sure exactly what. So having a early release in a system that isn’t critical for the running of our business, means we have the possibility to make those known unknowns into known knowns and deal with them. (hmm perhaps I shouldn’t have quoted Donald, this is getting a bit confusing! – but hopefully you get the point!)

Basically what was being offered was a risk mitigation strategy, and the enterprise just LOOOOOOVES that.

Back to Mobile apps

OK, so what’s this got to do with mobile applications? We’ll basically for mobile applications in the enterprise space we should be able to offer the same thing. I’m not talking here about applications that companies develop internally and deploy to all their staff, but applications found in application marketplaces (app stores if you will) that are used by enterprises.

Say there is this great app out there that allows you to track the driving speed and location of all your delivery truck drivers. It’s great because the same functionality just a few years ago cost thousands of dollars per truck and had to be downloaded manually each night. Now, you have it instantly and at a subscription cost of $20 per user per year, with awesome real-time reporting and everything! Great! But the reason it is so cheap is the developer is selling this software in a SaaS model. They have a multi-tenant architecture and when they make an update they update all customers at once. Now what happens if they push out an “improvement” in the user interface of the solution? Well 90% of your users will probably adjust, but 10% (or more) are suddenly going to be referring back to that print-out of the training material that you sent them getting very confused, phoning the help desk and generally finding an excuse for not doing work. Bad!

But had you known that a change was coming, what could you have done? Well, you could have updated the training material, sent comms explaining the wonderful new feature, etc.

So how could you have know this change was coming? Well the company that you’re subscribing to could have sent you some details about the change. But what if they thought that the change was so insignificant it didn’t need any comms? And  what if it’s just the particular way that your workforce use the app that means that it might need explaining? Then you are going to need another plan.

Another plan

chrome beta

In the Android application marketplace (Google Play) there is allowed the concept of a Beta version of application. Many popular applications (for example Chrome and Firefox) have beta versions of their software that showcase and test out new versions of UI and functionality.

This allows companies to test out new versions of software before their major install base start using it. And because the software is flagged BETA people know that there might be things different. It is a risk reduction strategy for not only the consumers of the software but also the developers. Win-Win!

Apple however in their app store submission guidelines: https://developer.apple.com/app-store/review/guidelines/#functionality

2.9  Apps that are “demo”, “trial”, or “test” versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines

and from the TestFlight guidelines: https://developer.apple.com/app-store/Testflight/

External Testers (Coming Soon)

Once you’re ready, you can invite up to 1,000 users who are not part of your development organization to beta test an app that you intend for public release on the App Store.

So instead of making a publicly available Beta version they are going to restrict to a maximum of 1000 Beta testers. Not so good for that SaaS developer with over 1000 customers is it? And even then – that functionality isn’t even release to the market yet! The whole TestFlight thing was only announced a few days ago!

In summary

So back to my title – if you’re a SaaS developer and you want to help your customers by reducing your risk and theirs in the mobile application deployment space, build for Android, not Apple. If you care about enterprise, then be aware that risk mitigation is a big thing. The reality is that as an enterprise developer we need to deliver for both Android and Apple devices, but one of them is clearly more enterprise friendly in one particular respect.

Would be great for Apple to take this on-board and offer a unrestricted “TestFlight” program for enterprise software developers… We can cross our fingers and hope!

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.