Will the SAP – Apple partnership fix enterprise mobility
We just whitnessed what appears to be a gamechanging partnership between two giants in the IT World. SAP and Apple are going to collaborate, to seriously break ground in the Enterprise mobility world. My LinkedIn, Facebook and Twitter feed exploded with likes and shares of the same article. A couple of hours later, the first analyst blog posts started appearing. I particularly liked Gareth Ryan and John Moy ‘s posts.
- Gareth’s post: Will the SAP & Apple partnership really bear fruit?
- John’s post: SAP seeks to rejuvenate its mobile strategy with Apple partnership | Blue T
I figured both of these posts touch on very important topics. When I noticed colleagues, friends, acquaintances and people I don’t know go out in a frenzy on different social media channels, I suddenly felt the urge to answer with some skeptical sounds of my own.
I’ve seen people shouting (from a keyboard that is) “Finally!! We’ll get decent mobile apps!”, “Hurray, all our problems are solved now!”, “I knew it! Apple will save us.”
Okay, I’m slightly exaggerating the reactions, but it’s in the same spirit.
Here’s a little wake-up call for you all:
The issue with Enterprise mobility has never been the front-end
I’ve built my fair share of mobile apps on top of SAP software already and I can tell you one thing for certain: The User interface is not an issue. You can build iOS apps today, with a great user interface. You can build sexy looking Android apps on top of SAP ERP functionality. You can make magnificently square apps on Windows phones. No issue whatsoever!
The biggest hurdle in enterprise mobility is, and always has been, the synchronization layer. SAP ERP is built around record based transactions and client initiated actions. In other words, the client opens up a record, locks it, changes some fields, saves and releases the lock. Now you might think that only those fields are updated in the source record, but in reality, the entire record is updated with the information coming back from the client.
If something concurrently had changed in that record (which shouldn’t happen, as it was locked, but we all know that locks are sometimes forgotten in custom code), it woul dnow be overwritten again.
Let’s be honest here: Apple is not going to solve that issue. They’ll only touch the UI.
You see, things used to be easy in the SAP ERP world. You had one big database and one fat client. If one user opened an object, it would be locked for anyone else. So an update could only come from one user at a time. So SAP never felt the urge to build in a broadcasting mechanism, to update the client(s) with changes that were done from a different client. As a result, business users got used to the idea of “always consolidated”. The data in the system always corresponded to a user’s actions.
With mobility, things are very different. First of all, you have much more users working on possible the same object at the same time.
Secondly, some of these users may be working in an offline mode, and perhaps only synchronize the data at a later time.
So that means you end up in a situation of “eventually consolidated”. Which is a difficult thing to explain to a lot of business users.
Another thing, as John and Gareth had already mentioned, is the trend of BYOD. With the SAP-Apple partnership, people can be easily mislead into thinking that SAP is going to focus on Apple devices and might neglect the other devices. People may also be lead to believe that the HTML5 and hybrid web trend was a mistake. Obviously none of these are the case, but in an overly hyped world, perception is everything.
So in my opinion, all the hoopla around the SAP Apple partnership, is nothing but marketing.
I can understand that it is a necessary hype, seeing as IBM recently made a similar partnership: Business – Mobile Enterprise Apps – Apple
So obviously, SAP couldn’t lag behind. Customers are much too easily dragged along on a hype. But let’s not forget that SAP already had partenrships with Google and Microsoft as well, so it really isn’t anything new.
This new partnership is only scratching the surface, but most business users only see the surface, and not the un-sexy, oily and dirty underlying layer.
So my hope is that while everyone is looking at the Apple partnership, that meanwhile SAP is seriously working on solving the sync principles in the backend.
[edit]
Just because I can, I also published a theoretical model for eventually consolidated webservices: http://scn.sap.com/docs/DOC-72717
That should give you an idea of where the real complexity is with modern landscapes. Hint, it’s not about the color of the submit button
[/edit]
With all the hyper-hyping going on, I believe there's another aspect that is easily forgotten. With (almost) everyone going crazy about simplifying things (partially in order to build UIs that fit on a smartphone screen), people tend to forget that there are two kinds of complexity: Complexity that was introduced due to technical or organizational limitations and that thus can be eliminated, and complexity that is inherent to the business itself. The latter has to be managed, not disregarded. I fear that with the current "simplify everything" hype, that lesson will later have to be re-learned.
That's a try gem of words, Volker. It is really important to keep in mind that one should not oversimplify things. User interface and Fiori are no exception.
If one keeps eyes open pitfall of oversimplifying are all around us at the moment. Just today I noticed another in my day-to-day work.
With Einstein's words:
"Everything Should Be Made as Simple as Possible, But Not Simpler"
I am an optimist. This is a game changer...just wait and see
Timothy Muchena
In which direction?
Because, as pessimist, i can say that even death is a change from sickness, as well recovering 😉
😆 For the good man.
Ofcourse there is going to be challenges and there is still a lot of unanswered questions(still in babyhood stage) but I believe its a +ve move
....
Just wait and see 😉
Sorry, the "just wait and see" doesn't attract me too much 🙂
I like facts and data before to say a thing is good or bad.
I'm not sure what I'm supposed to be waiting for.
The official messages seem to be about the UI.I believe that with the current technological possibilities, the UI isn't the issue. We've made a really nice IOS app using SAP as backend, in 2009.
The issue is with the 40 year old data model in SAP, when there was one backend, and one frontend, and a naive perception that only one person was allowed to work on an object at once.
That's not an issue that a partnership with apple is going to solve. That's an issue SAP must tackle. And I hope that they are doing so.
But unfortunately, wait and see isn't considered a strategy.
What I'm saying is we[at least I] don't have the full context or view of what this partnership means/entail. We dont know what SAP is doing or not doing to address the current issues Its all speculation. At the end of the day its a business decision...doing whats best for business
I continue to wait and see. Thats my strategy in as far as this SAP/Apple partnership is concerned BUT whilst I'm waiting I am educating myself more about this fruit of a company called Apple
I leave you with Sam Yen:
http://www.cio.com/article/3068001/mobile-apps/sap-design-chief-talks-details-of-apple-deal.html
That is a lot more nuanced.
thank you for the clarification
Great blog and nice point of view (thanks alot for linking John and Gareth's posts!).
I'm pretty skeptical about this partnership and under the IoT space i expressed my doubts under the poll Poll: The SAP and Apple partnership is a great ... | SCN
I cannot stop repeating myself: i do not complain new things but i would like to spend my time learning something that it's not thrown out the window just after 3 minutes.
As already pointed out, SAP already can create with Fiori/UI5 iOS-like apps so where is the gain?
Why should I learn swift?
But, even here, it's too early to speak about the future since for the moment we have only the big announcements with trumpets and dancers 🙂
I dont remember SAP or anyone saying they are throwing away Fiori/UI5. Swift is just an enablre alongside Fiori/UI5...I guess...we all still guessing anyway
Buzzword bingo! I saw "gamechanging" here.
However, all joking aside, I think you're right on point here, Tom. First off, there isn't anything about this announcement that says there won't be SAP mobility for other platforms, as some people seem to think it implies. And second, much as we all like to tout how the UI is SAP's weak point, there's much more involved than creating a sexy UI to create a successful mobile strategy around ERP systems. "Eventually consolidated," I like that phrase.
I borrowed that "eventually consolidated" term from the microservices world, eventhough you can hardly call a webservice on SAP a microservice.
But I like the concept of consolidating multiple historical requests on the fly, when needed, to form an aggregated view on an object.
My first idea really, was to not even do updates, but just continually create new change-records (like in the BI world) and then collapse them into the initial object during a read operation. But the current SAP data model is very ill suited for that.
So how does your eventually consolidated model handle.conflict resolution?
BTW SAP implemented "eventually cuonsolidated" models in its early CRM mobile offerings. Highly complex and, given that this has been abandoned and no new model of that nature has been forthcoming, I would presume SAP is of the opinion that the complexity renders the approach unsustainable.
I would also argue that treating a business object as a set of attributes that can be manipulated independently with no negative consequence is taking an overly simplistic view of what a business object is and what rules it should obey.
In any event the challenge is not the sequential nature of modification.This is unquestionably necessary to maintain the integrity of the business object and the rules it must obey and we know from regular operation that this is a relatively rare occurence anyway so I would say that to argue this as being the single biggest challenge facing mobilisation of business processes is a strawman argument.
The only real challenge in my view is with conflict resolution in disconnected operation. And there is no right or wrong way. There are several approaches and each has benefits and drawbacks. If you accept that a business object can only have one valid state at any instant in time and that applying a change to an obsolete state of a business object must invalidate that change then the challenge reduces to (1) ensuring that changes in a disconnected environment are applied to the correct state of the business object at the time the changes are being made and (2) ensuring that the business object correctly reflects it's state over time by applying the changes consistently in the sequence in which they are made provided they are made to the sequentially correct state of the object at the time the change is made.
Since you cannot overcome the first challenge by the very nature of a disconnected environment, there is. No practical possibility of overcoming the second. You then have to accord a priority to the changes, for example, the current state is the back-end state and if that changes before a change is made in the disconnected environment(s) you have no real choice but to discard the changes in the disconnected environment and be required to manually make the changes again on the current state of the object.
Hi Gareth,
Thanks for sparring with me.
It doesn't. I assume that the person who last changes an object also ha the most recent view on it's details and will therefore be correct. If not, it's no longer an IT problem, but a user problem. (in essence, users shouldn't enter lies into the system)
Correct and well aware of that. but the fact that it's abandoned doesn't mean it's solved.
I don't. I consider a business object to be a cluster of data, on which operations are executed. That's why I don't just create change records (I.e. this field changed to that value), but I queue Execution logic, which can be replayed.
There's also still a flaw in there. Some logic can't just be repeated. Example: execute payment. Archive object. create invoice...
I would invite you to a couple of my customers where 20% of objects run into issues.
And that is exactly what I try to fix by queuing the execution logic.
It's also not 100% waterproof, and it's only a theory (although I can't wait to test it), but given the limitations in the current SAP datamodel, it's the best I can come up with.
I welcome any improvements or counter ideas (except for: "Deal with it.")
If we could ignore the limitations of the record based store, and we take column based store + a new data model where a business object is an aggregation of a starting state + all change records and where calculated fields are calculated on the fly, instead of persisted,... Well, that's walhalla for me.
Thanks for challenging me. But I have a counter challenge:
"How would you tackle the sync issue?"
I'm being enlightened here 🙂
How you decided that it's only about UI ?
From the recent news, my take is that the new SDK helps the developers quickly create iOS apps that connects to HCP.
How it helps the developers?
The SDK might have the right APIs and tools in the form of some libraries to interface to iOS language (Xcode or Swift) that gives easy access to HCP.
Regards,
Midhun VP
Let me rephrase:
Apple is not going to fix SAP's datamodel and per consequence not the synchronization.
I don't know if apple will go beyond the UI, although the initial press releases where heavily focused on design, and tools to simplify the creation of an app. There's no mention of API layer, and I don't expect there to be either, because SAP has other initiatives running there.
ps: an app for me is UI. since the functionality must still be defined in the backend.
And by backend, you may mean HCP, potentially being the guy in the whole story who helps tackling sync / locking / consistency challenges. Like Midhun said.
Best regards,
Peter
no, by backend, I mean SAP ERP
HCP is just a stop an go. since no data, nor state is persisted in the cloud (privacy), but only timestamps and delta tokens, HCP doesn't have the full view.
The only, single source of truth, is your SAP ERP system.
(or CRM, if we're in a CRM scenario. The backend, whatever it may be)