With somewhat of a heavy heart, we decided to shut down Meistr, our SAP-centric quiz app, in order to focus on other projects. Over an investment of countless evenings and weekends spent thinking, designing, coding, debugging and often struggling with an unfamiliar, all-Javascript stack, we learned a huge amount about building a cloud-native app from the ground up on AWS using CouchDB, Node.js, and Bootstrap.

We also learned that we’re better at designing and building applications than carving out a commercially viable niche for them. But from the very start we realised this would first and foremost be a learning exercise, and here we weren’t disappointed. We learned about npm-hell and the mental contortions Node would demand from people with decades of experience writing apps in Java and ABAP. We learned that CouchDB’s elegant multi-version concurrency control model was really well suited to Meistr’s “Q&A quiz” domain, and underpinned our horizontally-scalable, globally distributed architecture. But it also turned something as simple as a multi-dimensional SQL join into a significant mental exercise, and thus failed the ultimate test of any technology: it did not help the scarce resources (i.e. us and our time) to become more productive and effective. But in the end Meistr showed us how we could build a functional app using static HTML and JS served from a CDN that entirely relied on API servers spread across three continents for all state, logic and persistence.

We would like to thank everyone who contributed content to the public Q&A database, used the app in quiz mode to learn more about SAP technologies, used it in interview mode to ensure they hired the right talent for their teams, or otherwise contributed ideas and feedback.

The Blue T team

Over the years I’ve taken a keen interest in SAP’s twists and turns with its mobile strategy, and I felt it would be a good time to reflect now that SAP has announced an end date (note: The SAP author adjusted their post … the original version is here) for its on-premise mobile platform. With this announcement SAP is staking its mobile future wholly on the SAP cloud platform. If anything, I believe SAP should have moved more aggressively to position its cloud-based mobile platform offering much earlier. I blogged as such almost six years ago. In the intervening years I’ve seen many changes to SAP’s strategy.

The origins of SAP’s on-premise mobile platform lie in the acquisition of the Sybase Mobile Platform back in 2010. At that time it instantly gave SAP a leadership position. As mentioned at the time … “According to the market research experts at Gartner, Sybase is one of the leading providers in the mobile sector”. Looking back I feel SAP faced real challenges with this acquisition. SAP was pitching to customers to purchase a new development platform, whereas historically most customers purchased SAP for its off the shelf applications. Yet SAP was challenged with convincing these same customers to purchase a new development platform, one with which their iOS/Android/Windows developers could build apps on top of SAP. Back then these customers struggled to muster the right ABAP developers with modern skills in core SAP, let alone new mobile app developers with skills in different programming languages across iOS (Objective-C), Android (Java) and Windows (.Net).

In my mind this conundrum lead to several major shifts …

Firstly, SAP’s realization that selling a mobile development platform was not enough led to the subsequent acquisition of another mobile platform Syclo in 2012. Syclo came with pre-delivered apps for mobile asset management and field services functions. SAP seemed more successful with this acquisition insofar as it could sell a ‘mobile applications’ story rather than simply a ‘mobile development platform’ story. But the acquisition did confuse the mobile platform landscape, so SAP sought to address that by combining elements of the Sybase acquisition and the Syclo platform into a unified ‘SAP Mobile Platform’ product. This is the product which now ends its mainstream maintenance in Dec 2020.

A second shift by SAP was the introduction of new HTML5-based offerings in ‘Fiori apps’ leveraging SAP’s HTML5 framework SAPUI5. Whilst this wasn’t purely a mobile-only solution, it did fork in as an option for customers seeking to mobilize their SAP processes and data. This approach reduced the range of skills needed to deploy mobile applications across various mobile devices (with HTML5 you can target iOS, Android and Windows platforms with a single code base). Although even then the need for HTML5/Javascript skills was still too much for many ABAP developers, leading to the advent of third party enablers such as Neptune Software. Over time SAP also introduced its own development productivity enablers for SAPUI5 such as WebIDE and Fiori elements.

In 2014 SAP announced the first incarnation of a cloud-based mobile platform, HCPms (now SAP Cloud Platform mobile services). Back then the platform lacked maturity compared with other cloud offerings. It also added to the confusion for customers seeking to make sense of how to mobilize their SAP processes and data: Do they go with an SAP on-premise mobile platform, the cloud-based mobile platform (which didn’t support the same range of apps as the on-premise edition), an HTML5-based strategy using Fiori, or a combination of these?

Then in 2016 SAP threw another fork in the road with the announcement of a partnership with Apple introducing a Fiori for iOS SDK. This SDK only worked with the SAP cloud platform, giving us the first indication of SAP’s ‘cloud-first’ focus for mobility going forward. It also only worked for iOS devices, bringing back the spectre of customers developing in a device operating system-specific manner (eg. coding in one way for iOS, and another way for Android) which reminds me of the challenges originally faced with the Sybase acquisition. Time will tell whether this approach is successful this time around.

Probably the last change has been SAP’s partnership with Mendix to sell their rapid application development platform capability, whereby you can conceivably build apps with no or minimal (low) code. I’ve yet to deploy an app with Mendix, but I’ve used other such tools such as the excellent GoCanvas offering and absolutely see the merits of this approach for a subset of use cases.

Looking back, clearly there were too many options for customers and SAP would have been seeking to cull some of these from the list to reduce confusion and rationalize the engineering support burden. I can’t help but wonder if the constant shifts in strategy have alienated some customers and developers from blindly following each turn in SAP’s strategy. As one developer who self-funded his training in Sybase and sought to establish a presence on SAP’s app store once told me: “I’m tired of SAP constantly changing their strategy … they need to pick a direction and stick to it”.

So where does that leave us? Customers would do well to take a close look at the SAP Cloud Platform and its mobile offerings. They should also take the opportunity to look at alternatives in the market. I’ve provided input to various customers over the years with their mobile strategies and here are some of the considerations that customers would do well to consider …

Ensure you can cover a vast breadth of use cases with your choice of platform – If embarking on a mobile strategy, it shouldn’t be just an SAP team doing that, because the only scenarios that will be considered will be SAP-related.  I’ve worked with customers that have tackled all sorts of non-SAP scenarios … you want to make sure your technology solution can handle those as well. The true measure of success here is how many apps you can deploy with the single platform, implementing a range of use cases, and connecting to a range of systems (not just SAP).

Ensure you can cover multiple target devices (eg. iOS + Android) with your choice of platform, and with a single code base – For enterprises, it’s not cost effective to manage different code bases for apps deployed to both iOS and Android devices. That’s evident from the lessons of the past when SAP struggled to sell the Sybase offering which demanded this multi-code approach. The common solutions to this are to follow a HTML5-based path (eg. SAPUI5), or if pursuing native-like UX and performance I’ve seen enterprises standardize on solutions such as Microsoft’s Xamarin or Facebook’s open source ReactNative technologies.  These latter approaches provide the ability to code mobile apps which perform better than HTML-5 based apps, using a single language and sharing code across iOS & Android.  I wouldn’t be surprised if SAP embraces this style of mobile development in future years.

Ensure you have the tools and skills to deliver the best possible user experience – Optimizing user experience often means going ‘native’ in appropriate cases with mobile apps, as well as supporting the ability of apps to function with poor or non-existent network connectivity. That ‘native’ argument was reinforced by SAP with the introduction of the Fiori for iOS initiative. It’s also why those technologies Xamarin and ReactNative (described above) are popular with enterprises and developers.

Be sure to protect yourself from indirect licensing risks – SAP has drawn much unwanted attention for legal cases relating to indirect licensing in recent times. Customers need to ensure that whatever the mobile platform solution they adopt, that they comply with appropriate licensing requirements for their underlying SAP systems.

It’s been a wild ride watching SAP’s mobile strategy unfold over time. With the impending demise of the on-premise SAP mobile platform, all of SAP’s hopes and desires will be focused on the SAP Cloud Platform. It will give SAP much more focus in its future R&D for mobile. And that’s a good thing.

Recently I was invited by Eventful Group to facilitate a round table of SAP customers in Melbourne to discuss their perspectives in the world of SAP technology. These round table events involve gathering together around 20 representatives from different SAP customers and industries, and in the course of half a day, teasing out their concerns, challenges and conundrums pertaining to SAP technologies. The Eventful Group cleverly invest in these round tables to help craft the conference agenda for their next SAP technology conference event (which in this case is in March next year in Australia). The idea is to ask as many customers what they want to hear about, what problems they want to solve, and what concerns they want to address – which can be a far cry from what SAP wants to sell them. Think of it as ‘Design Thinking’ for crafting conference agendas. SAP itself is intentionally not represented at these events to ensure it doesn’t become a ‘Sales-fest’. This same process is repeated in other cities and the results painstakingly collated by Eventful Group to derive a prioritised (backlog) list of topics for the conference agenda. It’s this level of investment that helps make the Eventful Group conferences so successful and highly rated.

However this blog isn’t about conferences. It’s about what I learned from the round table which I facilitated. Because something struck me this year …. Compared with the same event five or so years ago, the topics of interest have changed markedly. Whereas five years ago key topics focussed in depth on such things as making the most of Solution Manager, or new features of Web Dynpro ABAP and Floorplan Manager, it felt this year that the participants were grappling with higher level or strategic concerns, such as how to shift SAP workloads to the Cloud, how to shift a team towards Agile / DevOps, and even how to make sense of SAP Licensing (much discussion on this one, but more on that later …). This year Solution Manager (a top ranking topic years ago) didn’t attract any discussion whatsoever.

Eventful Group eventually publish to their website the aggregated and prioritised results across multiple round table events on their website. What I seek to do here however is to elevate a small selection of the questions that were debated with passion at the event I attended, and in some cases adding my own commentary or opinions …

Q: How do you innovate quickly without suffering a big S/4HANA migration?

My Thoughts: This concern talks to the fact that some customers simply don’t have the time, budget, or desire right now to embark on a re-implementation or renewal of their enterprise core foundation. The consensus opinion being that migrating to S/4HANA isn’t a “simple” exercise. Instead some customers have business imperatives to innovate quickly around their existing ECC business suite. For some customers this is fair enough – I’ve seen organisations spend much time and money implementing an enterprise foundation, only to find that after the inevitable cost overruns, little time or money remains to do the cool innovative stuff which consequently gets cut from scope. In that context a strategy to simply jump to the innovation side of things isn’t such a bad idea, if you feel your enterprise core as it currently stands can support your immediate digital initiatives.

Q: How do you accept reduced control with SaaS offerings (eg. SuccessFactors) and at the same time absorb an increased pace of change (regular updates)?

My Thoughts: This is a problem that enterprises in general face, whether it relates to SAP offerings or not. With SaaS offerings, as my son’s kindergarten teacher once said .. “you get what you get and you don’t get upset”. It is a mindset shift however, if customers are used to customisations. This reminds me of another saying that Dennis Howlett once mentioned which speaks to the other side of the coin … “customisations is industrial heroin” – in some cases it might arguably be a good thing that customisations in SaaS are more limited, as it can limit the possibility of unnecessary and costly changes, and force alignment to ‘standard’. Nonetheless, some customers will suffer withdrawal pains from taking on cloud-based software that is less malleable than they had in the past.

Q: How do you make sense of all the different SAP integration offerings now?

My Thoughts: There are a myriad of options for integration which customers need to make sense of. Everything ranging from classic on-premise Process Orchestration, to SCP Cloud Integration, to API management solutions, and so on. Customers at the round table expressed angst that they are simply getting options from SAP, not guidance.

Q: How do you make sense of SAP licensing?

My Thoughts: This was a hotly debated topic, and the general mood about SAP here was less than positive, even though SAP sought to extinguish the angst at SAPPHIRE with announcements around licensing. Some customers are seeking to tackle licensing concerns by purchasing specialised software that automatically audits their SAP usage. I heard that some of these software solutions are quite expensive in their own right, so it speaks to the angst that customers have if they are willing to invest in such solutions. One thing is clear … licensing is one of the topics that is ‘top of mind’ with customers and it was one of the headline topics of discussion – something I’ve never seen previously. It will be interesting to see if Eventful Group manage to persuade an SAP representative at next year’s conference to give a presentation that clarifies licensing. All the customers in the room said such a session would be very well attended. I think the big challenge would be getting an SAP representative willing to deliver it.

Q: How do you use and cement Agile / DevOps practices to support digital transformation programmes? And how do you get traditional teams to work this way?

My Thoughts: It’s interesting that this challenge is now a common theme with many SAP teams at customers. It’s a cultural and mindset shift that some teams will struggle with. Everyone has an opinion on this. Personally I lean to the mindset that any project, however large or long, can benefit from adopting aspects of Agile practices in some shape or form – the business alignment, focus, transparency and team work should always lead to better outcomes. Often project managers that dismiss such practices as being inappropriate for their own project come from a lack of understanding or experience with Agile.

Q: How do you manage a skills shift from being ABAP-centric to including Javascript SAPUI5, WebIDE etc.? How do customers handle the resourcing uplift to support multiple technologies? Should we turn ABAPers into full stack developers – and if so, how do they get there?

My Thoughts: This is not a new challenge for customers. Since the introduction of NetWeaver over a decade ago, SAP technologists have needed to stomach a constant stream of new approaches, techniques, and even languages (remember how Java was going to take over everything?). The big problem however is that whilst SAP is eager to introduce new technologies, it seems very reluctant to remove older ones. Which means your team needs to be capable of implementing and supporting technologies spanning over several decades. I still favour the use of full stack developers at Blue T, but they are getting more difficult to find as more technologies get thrown onto the pile. Right now I spend a session each week (and have done so for months) with my customer’s ABAP team to train them on the use of WebIDE, SAPUI5 and Fiori. The enormity of the task is very clear to me. It’s a challenge every customer will face.

Q: How do you get your ABAP developers to be as cool as your digital developers?

My Thoughts: I’m not sure coolness should be your goal here. Getting them to work together should be your goal. Too often they are separated by physical or organisational barriers. In a Scrum team that I currently work with, we have ABAP and digital developers sitting side by side, and that seems to work well.

Q: How have customers dealt with the increased cost of creating their own custom UX. What is the return on investment?

My Thoughts: Here I am referring to custom solutions using technologies such as SAPUI5 or Fiori for iOS SDK. Custom developing user interfaces goes against the philosophy of many past SAP implementations whereby the customer adopted ‘standard SAP’ on the premise that everything about SAP was ‘best practice’. Customers have since been awakened to the fact that when it comes to user experience, SAP is far from ‘best practice’. Nonetheless, investing in designing and building optimum user experiences for your business users is new to many customers, and certainly they will be seeking a return on investment. I’ve seen some great successes in this area, but also heard of some horror stories. The greatest correlation to success from what I’ve observed is in the expertise and capabilities of the people involved, rather than the technology. Design and UX skills are foreign to traditional SAP teams, and need to be sourced appropriately. Also, SAPUI5 / Fiori development is not yet a commoditised skillset, so it’s important to ensure your consultants have solid experience in this area.

Q: How do you unify user experience across SAP’s myriad solutions (on-premise, Concur, Ariba, SuccessFactors etc.)?

My Thoughts: Customers need to lean on SAP to solve this one. Only SAP can truly solve it. Of course implementing technologies such as Fiori Launchpad as a single entry point can assist, but to achieve a consistent user experience ‘in depth’ across all applications we need SAP to deliver this for us. If there is anything customers can do it is to call out cases where inconsistencies cause angst, either through private or public channels – it can help drive priorities for SAP to fix this.

Q: How do we “Run Simple”?

My Thoughts: I expect this term was born from some SAP internal marketing brainstorming session. And I’d presume the people who invented this term weren’t thinking of customer IT departments. Whilst the SAP marketing team might envisage a swan gliding smoothly across a pond, the customer IT team is probably envisaging the swan’s feet kicking madly below the surface to keep it moving forward. And that pretty much sums it up. Right now there is much complexity faced by IT teams in making sense of and wielding SAP technology to keep their businesses moving forward. It’s ironic that during the session one member lamented that the good old days of having a single R/3 system and single graphical user interface are long gone.

Of course, the thoughts I share here are simply my opinion. Everyone has a different perspective. Feel free to share yours in the comments below.

And special thanks to Carolyn and Kim from the Eventful Group for inviting me to facilitate their Melbourne SAP Tech round table. It’s always an enjoyable and rewarding experience.

This blog is about SAP’s Fiori, a term that embodies SAP’s focus on user experience. It isn’t so much a blog about technology, it’s more about faith, belief, and trust: faith that SAP is serious about renewing the user experience of its applications; belief that it will continue to invest in doing so, and trust that it will actually deliver. Why? Because history tells us SAP hasn’t had a positive track record in this arena.

Firstly, let’s turn back the clock …

I remember the late 1990s when SAP sought to reinvigorate customer belief in its user interface with the ‘EnjoySAP’ initiative. Here’s an excerpt from an Infoworld article published in March 1999 about the launch …

Unfortunately adding a new theme, rewriting some SAPGUI transactions and making the formerly horizontal line in the letter ‘A’ in the ‘SAP’ logo bend like a smile (anyone notice that?) didn’t significantly shift the levers of customer satisfaction.

At that time SAP had some clever technology to ‘scrape’ the classic screens into a browser (HTML) format using an Internet Transaction Server, and later that morphed into what we now know as SAPGUI for HTML (more on this later). In fact, I worked as a consultant for SAP in those days, and one of my technology competencies included advising customers on that very approach.

Then in the early 2000s SAP took a sharp turn by declaring that ‘Java is the language for the user interface’ (championed at the time by SAP executive Shai Agassi). With this new mantra we trusted that SAP would build new user interfaces using it’s ‘Web Dynpro’ technology running on a new SAP Java-based platform under the branding of ‘NetWeaver’. And so SAP did, for some time at least.

Then, the mid-2000s saw the ‘return of the ABAPer’ as SAP re-pivoted new user interface efforts towards an ABAP-based variant of ‘Web Dynpro’. This meant that in some areas such as HR, user interfaces were written in Web Dynpro Java then re-written back to Web Dynpro ABAP. This constant retooling heralded what I consider the ‘lost years’ in SAP’s UX evolution (not to mention, the subsequent shift with HR to SuccessFactors, rendering those rewritten user interfaces obsolete). Either way, whether it be new Java-based or ABAP-based user interfaces SAP fell well short of replacing all the original SAPGUI transactions despite an engineering effort that spanned over a decade.

This brings us to the advent of ‘Fiori’ in 2013. The introduction of Fiori was different, because Fiori was not a technology but an ethos, a set of principles focusing on UX (user experience). It was a loud and proud statement of intent by SAP that it understood the customer and their UX needs. Importantly, SAP published Fiori design guidelines to reinforce these principles with practical application in how Fiori apps would and should be designed. And to underpin the focus on UX, Sam Yen was appointed to an executive position as SAP’s global head of design and user experience (UX).  He introduced a new UX strategy and other initiatives such as a focus on ‘Design Thinking’ followed by new UX design tools such as ‘BUILD’. Many of us took a breath, forgave SAP for sins of the past, and backed SAP with our own encouragement and faith.

Now is probably a good time to reiterate the Fiori core design principles …

Whilst Fiori in its purest sense sought to be divorced from any particular technology, SAP did write its original Fiori applications using its new HTML5-based technology, dubbed SAPUI5.   To illustrate how Fiori is a design concept decoupled from the underlying technology, SAP and Apple subsequently announced the Fiori for iOS initiative in 2016. This introduced an iOS SDK (software development kit) conforming to Fiori design principles, built using Apple’s own native Swift language. Interestingly this did raise the question of how an iOS-specific solution would comply with the Fiori principle of being ‘Adaptive’. As per SAP’s own words: ” SAP Fiori enables you to work how and where you want, regardless of the device you use”. Perhaps we should add the suffix ‘…. as long as that device runs iOS’ to the design principle.

And so imagine the reaction a few weeks ago when SAP decided to overload the Fiori Apps Library with thousands of re-themed classic SAPGUI for HTML transactions (under the new ‘visual harmonization’ initiative introduced in Fiori 2.0).

We had seen some classic Web Dynpro apps added to the library earlier, but nothing like the magnitude of what just occurred.  With this we saw the number of apps appearing in the Fiori Apps Library leap overnight from around 1200 apps to a whopping 7500+. Many of us immediately came to the conclusion that the marketing folks at SAP had hijacked the library with the intent to bloat the numbers by adding in all these legacy transactions. That was backed by the fact that the newly added classic transactions also only appeared against S/4HANA systems, giving the impression that implementing an S/4HANA system would deliver substantially more apps.

Key SAP representatives however sought to explain the move, including Michael Falk (SAP Product Manager for User Experience and SAP Fiori) and Sam Yen.

As it turns out, SAP’s blog here tells us that S/4HANA customers actually asked for this change. They requested it to help them configure their Launchpad roles and make sense of what was available. In my mind the library has now been re-purposed from being a showcase of all Fiori Apps to being primarily a library of ALL the apps SAP considers are potentially relevant for an S/4HANA implementation. Fiori apps now make up only 15% of all the content in the library.

Whilst SAP has a plausible explanation for this change, the level of reaction I saw from members of the community indicated to me a deep-seated anxiety with SAP when it comes to perceived shifts in UX strategy. Does re-purposing the Fiori Apps Library herald a softening of SAP’s commitments around the renewal process in replacing transaction codes with Fiori Apps? After all, when you trace the historical shifts in SAP’s user interface strategies (described earlier), it’s no wonder that the SAP ecosystem is hyper-sensitive to any moves that might signal yet another turn in direction.

At time of writing (Dec 2016), the Fiori Apps Library holds around 1140 true ‘Fiori’ apps delivered since the announcement of the original 25 apps in May 2013. By my calculations, that translates to a delivery velocity of approximately 27 new apps per month or 324 per year. Interestingly, the addition of ~6500 classic GUI transactions linked to S/4HANA implementations telegraphs to us how much work might be remaining in the ‘renewal’ backlog. We are taught fundamentally that the relationship between old SAP GUI transactions and Fiori apps is NOT one-to-one: one SAP GUI transaction might eventuate in multiple Fiori apps, or in other cases multiple similar SAP GUI transactions might have their capabilities consolidated into a single Fiori app. Using a simplistic calculation, if we assume a one-to-one relationship and the same rate of app creation going forward (a big assumption), this gives us a projection of 20 more years (6500 / 324) for SAP to complete the renewals process. That’s quite a backlog, and it highlights the conundrum facing SAP.

This explains why SAP is in parallel providing tooling for customers to do some of the heavy lifting themselves. Tools such as SAP WebIDE to create new Fiori apps or to extend existing ones. Other tools such as SAP Screen Personas (the roots of which can be traced back to the original internet transaction server technology) which enables customers to simplify the classic user interfaces themselves.

So where to now?

Here’s what I’d like to see from SAP …

• Reaffirm commitment to Fiori and the renewals process. Not just in words, but in actions. We’d all like to see the ratio of Fiori apps in the Fiori Apps Library be much more than 15%.
• For every new underlying user interface technology introduced, please try and deprecate at least two. I know, that is much easier said than done. But the long tail of technologies and technical debt which runs in SAP systems these days must bring a tremendous weight to SAP’s ability to be agile. And its lack of commitment to this in the past explains why SAP has so much renewals work in its backlog for the future.

And advice for customers …

• Understand that whichever S/4HANA system you are implementing, you should consider the potential need for performing some renewals work yourself. Don’t assume that the system will be 100% Fiori. Consider the need for extensions or custom development for targeted scenarios where it makes business sense.
• Ensure that your implementer has the appropriate skills to enhance or build custom Fiori applications, or to refine and simplify classic user interfaces using SAP Screen Personas. This in its own right is a treacherous area, given the lack of available implementers with the necessary experience. I’m already hearing of some poor outcomes at customers where the consultants were not suitably skilled.

Whatever the case, Fiori is clearly a long journey, not (yet) a destination for SAP. Let’s pray we see SAP keeping the faith with Fiori.

Note: Above image via https://experience.sap.com/fiori-design-ios/

A few days ago Apple and SAP made a joint announcement of a partnership to much fanfare.

Here’s an excerpt …

“Apple® and SAP today announced a partnership to revolutionize the mobile work experience for enterprise customers of all sizes, combining powerful native apps for iPhone® and iPad® with the cutting-edge capabilities of the SAP HANA platform.

This joint effort will also deliver a new iOS software development kit (SDK) and training academy so that developers, partners and customers can easily build native iOS apps tailored to their business needs.”

This was then followed up with this post by SAP’s Steve Lucas, in which he adds …

“Specifically, we are developing dozens of new, native iOS industry apps for core business processes, built with Swift, Apple’s modern programming language, which will allow customers to fully leverage the data in their SAP enterprise systems to transform how they run their business anywhere.”

And ….

“In addition to the app goodness, we will provide SAP’s 2.5million+ community of developers with next-generation tools and training – including a SAP HANA Cloud Platform SDK for iOS and an SAP Academy for iOS – to build, extend and run a new class of native iOS apps powered by the HANA Cloud Platform (HCP).”

There are so many angles with which to view and assess this announcement. Here I’ll share a few of these along with my own thoughts and opinions.

Lets deconstruct some of the statements in this announcement …

Ignoring BYOD trends

“… a partnership to revolutionize the mobile work experience for enterprise customers of all sizes, combining powerful native apps for iPhone and iPad ..”

I’ve worked on a number of mobile strategies for customers over the years, and one trend that is unstoppable in the enterprise is that of BYOD (Bring Your Own Device). Even SAP acknowledges this trend. It means that as an enterprise you ultimately want to position yourself to support different mobile client platforms based on personal device choices, such as iOS, Android & Windows. A solution that targets only iOS is, whilst beneficial to Apple’s aspirations to sell more iPhones and iPads in the Enterprise, may not be well suited with an organisation’s ability to support BYOD.

What happened to HTML5?

“… combining powerful native apps …”

This statement is significant on many levels and raises many questions in my mind. When we refer to ‘native’ here we contrast this with other mobile development technologies such as ‘HTML5’ and ‘hybrid’ apps. To refresh your understanding of these concepts and their relative merits you can view the presentation below which I delivered a few years ago.

SAP made a strong foray into building native apps to front-end SAP a few years ago, but then decided to pivot towards a HTML5-based strategy with the birth of Fiori apps. Has SAP rounded back and decided that HTML5 is not the panacea that it hoped it would be? Or like Facebook did SAP bet too much on HTML5? Or am I reading too much into this?

Perhaps this announcement is just one in a long line of mobile SDK announcements of the past such as those with Sencha, Appcelerator and Xamarin. However I feel we should not dismiss this as yet another announcement. Especially when it is delivered by Apple’s CEO Tim Cook and SAP’s CEO Bill McDermott themselves. When you look at the Fiori Design Guidelines site you’ll see that SAP Fiori for iOS has been elevated to a very prominent position.

It leads me to think that perhaps SAP is dead serious about this. And if so, does this foretell fault lines in the strategy to leverage SAPUI5 across all devices? Is the performance of SAPUI5 such a limiting factor in the delivery of UX to mobile devices that SAP have felt the need to re-introduce a native-development option?

Will SAP’s Developers make the grade?

Another excerpt from the announcement, where Tim Cook hopes SAP’s legions of developers will reinvent themselves as iOS Swift developers …

“Through the new SDK, we’re empowering SAP’s more than 2.5 million developers to build powerful native apps that fully leverage SAP HANA Cloud Platform …”

I have strong opinions on this one. Yes SAP has more than 2.5 million developers. But I’m familiar enough with this ecosystem of (primarily) ABAP developers to know that only a fraction are making the leap to HTML5/Javascript with SAPUI5, and to then expect a further leap into native iOS development using Swift is wildly optimistic. That said, I believe there would be a strong case to open up the existing community of iOS developers out there – giving those developers the opportunity to build front-ends for SAP using the technologies with which they know and love is one way of attracting new talent into the SAP ecosystem.

Platform Dependencies

Then there’s the other part of the above quote …

“… that fully leverage SAP HANA Cloud Platform …”.

Oh. Do I read into this that the new SDK is hardwired to SAP’s HANA Cloud Platform (HCP)? If so, customers who want to leverage this will need to license use of HCP.

Different Perspectives

In Steve Lucas’ post he posits that …

“The objectives of the partnership are to enable newer, faster ways to perform a task, access data, and do your job”

 

• From an SAP perspective, I’d expect an underlying motivation to drive more sales and adoption of HANA Cloud Platform mobile services (HCPms) along with complimentary services such as Mobile Secure.
• From an Apple perspective, I’d expect a motivation to elevate their penetration into the enterprise and presumably uplift sales of iPhones and iPads.
• From a traditional SAP developers’ perspective, this adds the burden of yet another technology with which to build some competency in, when so much time is being spent building competency in SAPUI5 etc. However from an iOS Swift developers’ perspective, it creates an opportunity to bring their craft into the SAP ecosystem.
• From a customer IT perspective, this adds burden to the IT skillsets which may need to be supported in-house and the associated people-cost, as well as the need to license middleware such as HANA Cloud Platform.
• From an end user and customer line of business perspective, I think it’s great that SAP is seeking to uplift the mobile user experience with the possibility of native apps with Fiori design elements, albeit here for iOS. And if we think that end user experience (UX) IS THE MOST IMPORTANT focus of our times, then I would suggest that this alone underlines the importance of this announcement.

Do I think this announcement is a good thing? Yes for sure. With native development there is an opportunity for SAP or customers to delivery truly outstanding applications unencumbered with the performance restrictions we might see with some HTML5 approaches. But that will be at a cost of development targeting only iOS devices. Do I wish this solution were available to SAP customers without the requirement for HANA Cloud Platform? Yes absolutely, especially if SAP wishes to fuel rapid adoption.

One thing is for sure, SAP’s twists and turns in mobile strategy and announcements over the years continue to keep SAP customers and partners on their toes. But perhaps that’s the world of mobility in general.

So there we have it. My thoughts and opinions. Feel free to add yours in the comments below.

Many of you know I am passionate about finding the optimum way of delivering a better UX for SAP customers. It’s reflected for instance in my presentation on Pragmatic Paths to optimise your SAP User Experience which I delivered at a local SAP User Group Conference last year.

The other day I stumbled across an interesting slide (below) from SAP depicting the valid UI clients for a S/4HANA implementation.  Of course this slide is subject to the usual SAP disclaimers that it reflects the ‘current state of planning and may be changed by SAP at any time’.

This slide raised for me some very interesting questions. What User Interface (UI) clients would people out there in the Twitterverse advocate implementing for a greenfields on-premise S/4HANA implementation?  Looking at the slide above it seems SAP is promoting two options.

I have my own opinions on this, but I thought I would first test my thinking without telegraphing my opinions by releasing a Twitter poll.

Here are the results ….

Firstly, if you are not familiar with the technologies described, you can find more comprehensive descriptions from SAP at these links …

SAP Fiori Launchpad (abbreviated as Fiori Lpad in the poll) – link here.

SAP Enterprise Portal (abbreviated as Portal in the poll) – link here.

SAPGUI for Windows (abbreviated as GUI or GUI Win in the poll) – link here.

SAP Business Client (formerly NWBC, abbreviated as Bus Client 6 in the poll) – link here.

Secondly, if you think the options should have been more descriptive, or there should have been more options, I was restricted by character limits imposed by Twitter and a limit of only four options for a poll.

Finally a voting sample of 75 votes from Twitter is good, but just a drop in the ocean compared with the overall SAP ecosystem. Consider that when interpreting these results.

Lets share my opinions on each of these results. Note that these are opinions only, and I would be interested in hearing your own in the comments.

Option 1: Fiori Launchpad + SAP Portal + SAPGUI for Windows

Fiori Launchpad is of course the strategic mechanism to deliver Fiori apps. Fiori represents SAP’s new user experience and the go forward approach for solutions such as S/4HANA.   The sticking point is that SAP has yet to provide the full suite of Fiori apps that would negate needing to ever use any of its hundreds of thousands of older SAP GUI and even Web Dynpro screens. Therein lies the conundrum. How do you surface those older technologies? Via Fiori Launchpad you can in fact launch Web Dynpro applications, as well as SAPGUI transations surfaced within the browser using SAPGUI for HTML technology. But SAPGUI for HTML has existed now for over a decade, yet when given the choice, SAP customers have preferred the more performant SAPGUI for Windows client.

Here, when referencing SAP Portal I am referring to the on-premise installation of SAP Portal, not the cloud portal offering on HANA Cloud Platform that is something altogether different. SAP boasts over 10,000 implementations of SAP Portal, so I can imagine there is quite a following in relation to skillsets and consultants (heck, I myself was once a certified SAP Portal consultant). I can’t help but think that some proportion of the votes for this option was swayed by SAP Portal consultants wishing to ‘go with what they know’ – just my opinion, I could be completely wrong here. The interesting question is whether you would justify standing-up a new on-premise SAP Portal for a greenfields implementation of S/4HANA.

Pros

• If you are looking to make use of broader features offered by SAP Portal (such as collaboration features or mashing SAP with non-SAP content), you might consider this. That said, many existing customers already have a solution to deliver intranet and collaboration features in their landscape (eg. using Sharepoint) and only run an SAP Portal to serve as an applications portal (to surface SAP applications in a role-based manner). Where that is the case their needs may be met solely with SAP Fiori Launchpad.
• You will possibly need a Java server to run services such as ADS (Adobe Document Services) to support Adobe-based form printing, and arguably an SAP Portal has traditionally provided the platform for just that. However for the ADS scenario you now can alternatively utilise a cloud-based service instead, using SAP Forms as a Service on HCP .

Cons

• Assuming you are delivering the Fiori Launchpad within SAP Portal, this increases the payload to be deployed to the client. I personally view Fiori Launchpad as being something akin to the next generation ‘applications portal’ for SAP, and in embedding this with SAP Portal we end up with a ‘portal in a portal’ scenario – along with the associated impacts to network usage and time to render for the user.
• You are running and supporting additional infrastructure associated with the SAP Portal.
• You now have potentially three entry channels for users …. Fiori Launchpad (unless it is embedded within SAP Portal, which I mention above is not my favored approach), SAP Portal, and native SAPGUI for Windows. That’s ludicrous in an age where we are striving for simplicity for end users.
• This is not listed as an option in the SAP slide at the top of this post.

Option 2: Fiori Launchpad only (incorporating SAPGUI for HTML, Web Dynpro etc.)

This option advocates for what SAP’s strategic direction is … a fully browser-based (zero client installation) approach.  In fact when you look at the SAP slide above this is the only option for customers implementing S/4HANA Cloud Edition.

Pros

• This is the simplest deployment approach and least costly to support.  The entry point for all applications is via Fiori Launchpad and there is no need to rollout a thick client to desktops.  All you need is for users to access the URL in a browser.
• This single Fiori Launchpad client can be supported across various devices and form factors (although the underlying technologies differ in support – whilst SAP Fiori apps generally can run on desktops, tablets and mobiles, SAPGUI for HTML and Web Dynpro ABAP technologies tend to be supported only on desktops)
• Since Fiori Launchpad is SAP’s strategic direction, it is likely that SAP’s near term investment in integrating and aligning new cloud acquisitions such as SuccessFactors, Ariba etc. will be focussed on Fiori Launchpad.
• SAP is seeking to implement ‘visual harmonization’ such that SAPGUI for HTML screens will be themed in future to look more like Fiori applications.

Cons

• Use of SAPGUI for HTML scenarios may be inferior in performance (and thereby UX) terms than the native SAPGUI for Windows. For casual users this may not be of any concern, but for users who spend most of their day in the system this might make a difference.
• It is still unclear how Fiori Launchpad alone will effectively surface a large number of applications to any given end user.  I’ve worked with customers where some key roles needed 100 – 200 menu options.  That translates to many tiles in Fiori Launchpad.  That being said, I’m hoping the Fiori 2.0 design concepts might help to alleviate this concern.  This blog by Jakob Marius Kjaer nicely articulates the problem.

Option 3: Fiori Launchpad + GUI Windows

In some ways this option is similar to the SAP Portal + GUI Windows combination that many customers have implemented in the past.

Pros

• It is likely you will use SAPGUI for Windows within your project team anyway. For instance I can’t see Basis administrators using anything else. And as one Twitter respondent mentioned you need it to use some developer tools such as ADT (Eclipse based ABAP Developer Tools). But the question is would you also deploy the SAPGUI for Windows to end users? And if so where would you draw the line? – all users or only so-called expert users? And if justifying the need for SAPGUI for Windows why not go for option 4 which delivers Business Client 6 with SAPGUI for Windows embedded?

Cons

• This implies you will be deploying a client installation (SAPGUI for Windows) to the desktops of some or all of your end users.
• SAPGUI for Windows is not supported on tablets or smartphones.
• This breaks the user experience because users may need to open Fiori Launchpad to access some functions whilst opening SAPGUI for Windows to open other functions.
• This combination isn’t even mentioned in SAP’s slide above. And don’t forget for my poll the question was framed around a greenfields customer (one that hasn’t used SAP before). Putting SAPGUI for Windows in front of new end users (even if they might be expert users) isn’t really in my mind the path to success in this day and age.

Option 4: Fiori Launchpad + Business Client 6 (embeds SAPGUI for Windows)

Here when we mention Business Client 6 we are referring to the thick client Business Client 6 desktop edition, which also comes with SAPGUI for Windows embedded (with a unified installation).

Pros

• You have a number of options here. The important thing is that Business Client 6 provides a modern conduit to surface a native SAPGUI for Windows experience alongside the Fiori launchpad experience. Tiles in Fiori launchpad can be configured to launch native transaction codes in SAPGUI for Windows. It is for this reason that Business Client 6 is recognised in the SAP slide.
• You can deliver role-based access to both casual and expert users alike. Both Fiori Launchpad and Business Client 6 incorporate role-based concepts, whether you are using the tile-based approaches in Fiori Launchpad or the classic accordian menu index page in Business Client 6, or unifying the two by launching the Fiori Launchpad within Business Client 6.
• Certainly Business Client 6 offers some advantages to the previous option 3 (SAPGUI for Windows only) because it delivers some nice usability advantages such as good support for role-based access, easy transaction discovery (via search), and side panel assistance. Whilst at the same time you can still deliver when needed a native SAPGUI for Windows experience.

Cons

• This implies you will be deploying a client installation to the desktops / laptops of some or all of your users. Of course SAP offers a unified installer for Business Client 6 with SAPGUI so this is not dissimilar to option 3 above. But similar to option 3 above, would you deploy this to all users or only expert users?
• You need to setup and configure potentially two clients, which is additional work.
• SAP Business Client is not supported on tablets or smartphones, nor is it supported on non-Windows environments such as Macs, so you will need to support those channels via Fiori Launchpad alone.
• Business Client mandates the use of (currently) Internet Explorer when surfacing web applications. However SAP’s new Fiori apps are optimised for Chrome.   So you lose some flexibility in your browser choice when surfacing Fiori apps via Business Client.

Other Thoughts

It is important to note that for S/4HANA Cloud Edition customers, SAP only supports the use of Fiori Launchpad standalone in the browser. That means that when any traditional SAPGUI user interfaces need to be accessed, these will be via SAPGUI for HTML embedded in Fiori Launchpad. If you believe in SAP’s cloud story and it’s success in the near to medium term, then I would have expected you to vote for option 2, because why should the thinking for an on-premise deployment be any different? Yet the smallest proportion (17%) of respondents in the Twitter poll voted for option 2.

Instead the majority of respondents (40%) interestingly voted for option 4 – a combination of Fiori Launchpad and Business Client 6. What’s not clear is how respondents would prefer to deploy that combination. In that regard, here is a plausible option from my perspective …

• Deploy Fiori Launchpad via browser to casual and general users across desktops / tablets / smartphones. For smartphones potentially leverage optimisation approaches such as SAP Fiori Client app or similar.
• Deploy Business Client (with embedded SAPGUI for Windows) in a unified installation as a limited deployment to expert users on their desktops. Expert users to be defined based on role (eg. roles generally requiring use of SAPGUI transactions in the system for over 2 hours per day). If you find very few expert users fall into this category, then it might make sense to revert to option 2.  Apply some basic role-based filtering concepts to deliver role-based menus with minimal effort.

The choice of including Business Client in the mix in the Twitter poll results is interesting as it telegraphs a nervousness amongst respondents about the ability of SAP to fully replace SAPGUI transactions anytime soon. Business Client is effectively a technology that provides a smoother transition from the traditional SAPGUI for Windows technology towards web-based applications such as SAP Fiori as it supports both approaches within a single shell. Many of you will know that I have blogged about the benefits of Business Client in the past. If however all applications were SAP Fiori apps (SAP’s vision), there would arguably be no need for Business Client.

SAP consultants have traditionally not been ‘user centric’. Rather they have been function centric, or delivery centric. As long as a function can be delivered and the requirement ticked off (however unusable it may be) that’s long been the approach for SAP implementations. But times are changing, user demands are changing, and we all also need to change the way we see and deliver SAP UX to our customers. The big question is how willing the ecosystem of SAP implementers and consultants is to let go of older approaches and make way for the new.

The other day I stumbled across this quote in a blog by Gant Laborde, which whilst generic in context is easily applicable to the world of SAP …

“Software keeps evolving, and so should we; no-one got into software to watch the world pass them by”

– Gant Laborde

With this quote, and as this year marks my 20^th in the SAP ecosystem, I reflected on a contentious blog that I wrote over 5 years ago on the SAP community network titled ‘Can we reinvent the grey haired ABAPer?’.

For SAP developers, it has been a tumultuous journey. In the glory days of the 1990s SAP development was somewhat restricted to a limited set of development practices – primarily screens, function modules, reports, enhancements in the form of user exits. I remember the early 2000s when SAP’s technology head at the time Shai Agassi proclaimed that ‘Java is the language for the user interface’ as SAP sought to redevelop new user interfaces using the NetWeaver Java platform. I saw the fear in some developer’s faces at having to pivot their skillset to an entirely new language set and object oriented development. Indeed only a small proportion made the leap. Some developers were left behind. Of course years later SAP circled back to standardize on WebDynpro for ABAP and Floorplan Manager for the user interface. It introduced other concepts such as Personal Object Worklists, CHIPs, and so on. More developers were left behind. These days with SAP embracing Fiori and HANA technologies, SAP developers are expected to stretch their skillsets to optimising code for HANA’s columnar storage, exposing OData services using NetWeaver Gateway, and via SAPUI5 developing in Javascript (no, not Java) for the user interface along with having a good understanding of HTML5 and related concepts. And most recently SAP expects developers to pursue extensions to SAP solutions in the cloud via SAP HANA Cloud Platform (HCP). More developers will be left behind. Add to this the critical skills of understanding specific industries and business processes (which comes with experience), the expectations of a modern day SAP developer have never been more demanding.

Those of us in the know understand the depth of knowledge expected from a fully rounded SAP developer these days (and I’m sure many of you can add many more technologies, acronyms and so forth that I’ve not mentioned here).   But it does telegraph one important thing … that the concept of a generic SAP developer is a myth. In reality, each developer is unique, and has evolved to a certain level along a multi-dimensional continuum of skillsets and technologies.

Looking at the above diagram, we could argue about what technologies should be listed and when they were introduced. But the point is this … the skills challenge is getting increasingly more difficult as SAP continues to evolve with new technologies without deprecating the older ones (think SAPScript etc). Even looking at SAP’s S/4HANA release, it seems that many older technologies are still running alongside newer approaches. Which means an SAP developer is expected to stretch their capability across a widening breadth of technologies and approaches. Or projects are expected to double up on resources to achieve this coverage of skills.

Now more than ever, it’s important to curate the right individuals for your development team. Don’t treat them as generic commodities. Think of your development team as the engine room via which you can build innovative solutions (eg. mobile apps) on your SAP digital core. Finding the right ones can help to propel you forward and keep your systems relevant.

It’s why myself and those I work with see good developers as enablers and respected consultants, not commoditized order takers. That ethos is enshrined in our manifesto. But when I say ‘developers’, I do mean the ‘right developers’. Those that seek to evolve. To move beyond your SAP GUI. The ones that don’t wish to ‘watch the world pass them by’. This blog is dedicated to them.

This month I was invited to present at a SAP Australia User Group (SAUG) conference in Melbourne on the topic of optimising SAP user experience (UX). The reality for the primarily on-premise ERP customers in the SAP ecosystem is a far cry from where SAP would like them to be. Whilst SAP senior executives enchant customers with demonstrations of its new ‘Fiori’ user experience, many will return to their workplaces and log into an old SAP GUI experience which dates back to the 1990s. Indeed, some customers may well be implementing a new SAP solution right now, using that very same SAP GUI experience.
The challenge I see for the SAP ecosystem is that, whilst SAP itself may endeavor to reinvent it’s technology foundations and push solutions to the next generation, there is a level of inertia in skills, attitudes and mindsets that prevents SAP systems from evolving. That is essentially the theme of this presentation. The challenges which the SAP ecosystem faces are less about tools and technology, and more about people and mindsets.

Click on the image above to view the presentation.

Perhaps this is a bit off-topic, or perhaps this is the start of a little blog series on the tools we find useful in running Blue T as a business. Being a small company without support staff, we always look for ways to do things more efficiently. Usually this means running our servers in the cloud, or using SaaS applications wherever possible. But it also means using Uber to go to client meetings or the airport because we find their services far superior to normal taxis.

While scrolling through my trip history on the mobile app to support my proselytizing, I noticed an odd trip one evening during the (very excellent) SAP Developer & Architect Summit this past November in Sydney. Admittedly this was late in the evening coming home to my Airbnb apartment from a nice craft beer venue, yet I didn’t remember asking for the scenic route.

I do remember the driver being very courteous and driving a fairly nice dark Mercedes sedan, hence I would have given him the usual 5-star rating. However seeing the map did leave a bad taste in my mouth but with the rating now firmly locked into place, a dispute via customer service would be the only option. This trip being over 3 months old I didn’t have high expectations but anyways submitted a dispute via the app just to see what would happen.

Come Monday I received an email from Jenny apologising for the situation and confirming Uber had refunded the difference between what I paid and their trip estimate, thus reducing the charge by $14.

If I had taken a normal taxi, I certainly wouldn’t have arrived at this outcome. As only an occasional visitor to Sydney, I would have been clueless of the fact I’d been ripped off in the first place were it not for Uber’s GPS tracking. And even then, lodging a complaint with the Taxi Directorate would make Kafka weep – without the taxi’s license number, the driver’s ID number, the exact time, date and location, the phase of the moon and whether Venus was at the time ascendant in the house of Virgo, I wouldn’t have stood a chance.

One more reason why we use Uber for a lot of our travels! And if you’re not a convert yet, sign up and get $10 credit.

In recent times I’ve noticed heightened interest by SAP customers in the potential of deploying SAP NetWeaver Business Client (NWBC) to enhance the user experience for SAP end users.  This is a good thing, because in my opinion NWBC (or more specifically NWBC 4.0 onwards) is one of the under appreciated gems in SAP’s usability offerings. The focus has shifted to SAP Fiori, but whilst Fiori can spearhead your usability strategy to deliver a highly attractive web user experience for smartphones, tablets, and desktops, you can simultaneously upgrade the user experience for native SAPGUI users by encapsulating SAPGUI in NWBC, and at the same time surfacing alongside it the hundreds of potential web dynpros and list views (POWLs) etc. that SAP has delivered over the past decade in various enhancement packages.

How might you position NWBC in your UI strategy?   In the past a common pattern for customers was to deliver web user interfaces to casual users via the SAP Portal, and to deliver SAP GUI to professional users.

Now we see SAP making a heavy investment into SAP Fiori as the next generation user interface for end-users.  However when you take into account the platform dependencies for SAP Fiori, and that SAP will likely never convert every existing function to Fiori, many on-premise customers will be waiting awhile before they see a strong Fiori footprint in their landscape.  Until then any Fiori deployments may be limited to basic casual user functions such as time entry, approvals, leave requests etc.   Right now, SAP customers have the opportunity to enrich the user interface for professional users using NWBC.  With NWBC (desktop edition) you have the opportunities to still offer your users a purely native SAPGUI experience for SAPGUI transactions, whilst at the same time unlocking many of the out of box Web Dynpro / POWL and other scenarios that SAP has invested in delivering over the past decade but which many customers have yet to take advantage of.   Here is a potential modern-day pattern for delivery of user interfaces for SAP on-premise customers …

Note that the above assumes you don’t require an SAP Portal in your landscape to deliver extended capability such as intranet, knowledge management or collaboration-style functions, federation, or consumption of non-SAP content.  For many customers, that is the case because they might use for instance a Sharepoint environment for collaboration functions and simply use their SAP Portal to deliver ESS/MSS application access.

Benefits

After working through a real-world NWBC implementation, here are some of the benefits I’ve noticed that can be unlocked for end-users

• UI technology unification.  You can surface your native SAPGUI, Web Dynpro, UI5, BSP, and Analytics scenarios through a single user interface.   I emphasize here the ability to deliver a native SAPGUI user experience with the desktop edition of NWBC. For many professional users a native SAPGUI experience is always preferred to the SAPGUI for HTML (also known as WebGUI) user experience.  SAP Fiori launchpad offers the ability to launch SAPGUI for HTML, but in my opinion professional back-office users will still want a native SAPGUI experience where possible.  NWBC (desktop edition) provides that.

• UI enrichment via side panels.  The side panel in NWBC (desktop edition) allows you to unlock additional SAP-provided content, as well as to deliver some of your own value-added additions such as context sensitive help.   You may well already be licensed to consume that additional content (of course check with your SAP account executive), so why not actually make use of it?

• High speed menu traversal and discovery.  Once your NWBC menus are propagated to your client (desktop) for the desktop edition, menu navigation and local menu search can be extremely fast.  This is because traversing your menu is client-side, as opposed to traversing the menu in a SAP Portal or SAPGUI which depends upon round-trips to the server.  And once downloaded your menus are cached on your desktop (there is an elegant process by which NWBC detects whether the menus need to be refreshed, which I will not go into here).  The benefits of this are not to be underestimated.  I once worked at a site years ago where the customer deployed and maintained half a dozen portals around the world just so that the portal navigation response time to end users was marginally faster.  With NWBC (desktop edition) the architecture is such that it is like having a high performance menu server running locally on your computer.  Because of this, it also supports a high-speed type-ahead (Google-like) search mechanism when searching for items in your menu by description or even transaction code.

• Role-based access.  NWBC offers the ability for users to be delivered role-based menus (similar to SAP Portal).  This means users should only see what they need to see based on their role in the organisation.  It can dramatically cut down the number of menu options that they need to traverse and thereby improve usability.  And it also means users shouldn’t see the dreaded ‘no authorisation to execute this transaction’ error.  Compare this with the classic approach in SAP GUI of delivering the colossal SAP menu hierarchy and leaving it to end users to find the right functions, even when they have no authorisation to execute the majority of them.

• Landscape rationalisation.  If you currently utilise SAP Portal only as an ‘applications’ portal for SAP scenarios such as ESS/MSS (ie. you don’t make any real use of collaboration and knowledge management functions), then you may have an opportunity to decommission your portal and surface the equivalent functions using NWBC (HTML edition).  Note that NWBC server-side technology is embedded in your ABAP server (eg. ECC System) … you don’t need a separate server.  Even better, if you currently utilise another portal technology such as Sharepoint for your intranet and collaboration functions, SAP offers you the ability to embed NWBC (HTML edition) scenarios into that 3^rd party portal technology.  Note however that you may still require a Java stack to run services such as Adobe Document Services.

• Skills rationalisation.  At the same time that you may be able to decommission (or avoid implementing) an SAP Portal, you similarly won’t need specialist consulting expertise in this area.  Building menu structures in SAP Portal is a specialized skillset (I know because I did that for some years), whereas building menu structures in NWBC simply requires knowledge of the transaction code PFCG and is a much simpler process.

• Old school navigation support.  So you have some users who have been using your system for years, who couldn’t be bothered with hand-crafted navigation menus for themselves, who can remember the 100 transaction codes that they typically use, and just prefer to use the old techniques to launch SAPGUI transactions (ie. /n, /o etc)?   Well, they still work in NWBC if you want them to.

Challenges

That said, implementing NWBC is not without its challenges.  Here are some of them …

• Inertia.  Some consultants still seem to be more comfortable implementing yesterday’s SAP, not tomorrow’s SAP.   They can tend to be more comfortable with what they know, which is SAP GUI and SAP Portal.  In my opinion, this is why there are still new customers implementing just SAP GUI / SAP Portal.  I have seen for instance a SAP portal consultant recommend implementing SAP Portal over NWBC, simply because that is all they were familiar with (in fact they were unaware you could surface ESS/MSS in NWBC).

• Authentication.  NWBC authentication begins with an ICM (installed with an ABAP web application server) interaction.  Whatever mechanism you can use to authenticate into your ABAP system via web channels, you can use for NWBC.  This can include for instance standard basic authentication (using username and password), SAP login cookie authentication (using a ticket issuer, such as a SAP Java server), SAML authentication, and x.509 client certificate-based authentication.  Additionally, if you are consuming user interfaces from multiple backend SAP systems into NWBC, you will need to designate one as your hub (typically ECC) and establish trust relationships with the others.  Setting up authentication for NWBC can be easy, or difficult, depending upon whether your team has leveraged the available authentication approaches in the past.

• Menu construction.  Constructing the information architecture (menu hierarchy) for your end users can be time consuming.  And bear in mind that if you want to unlock the benefits of role-based menus, you will need to construct different menu structures for however many different roles you wish to support in your organisation.  An example role might be ‘Accounts Payable officer’.   This needs to be a focussed piece of work and can benefit from some user experience analysis to structure menus in the manner that your users might wish to see them.  Note that SAP offers the ability for menus to be ‘merged’ (eg. ESS menu + Accounts Payable officer menu) when delivered to an end-user, allowing you the ability to componetize your menu definitions into sub-menus.

• Desktop deployment. Deploying the desktop edition of NWBC obviously entails an installation on your user’s machines.  This is however not unlike SAPGUI.  And for those concerned that NWBC (desktop edition) is a separate installation from SAP GUI, the upcoming next major release of NWBC (hopefully by end 2014) will offer a unified installation package of NWBC with SAPGUI built-in.  It should be noted that the desktop edition of NWBC offers real performance benefits when compared with the HTML edition of NWBC, including a native SAPGUI experience.

It is important to note that NWBC does not solve all your usability concerns …

• Unlike SAP Fiori, NWBC does not provide real support for use through different channels such as mobiles.   That’s why I see the future of NWBC in the professional user space on the desktop, for those users still needing to access native SAPGUI transactions.

• NWBC does not solve any usability issues with what you see within the underlying applications that it surfaces (apart from the ability to enrich the information available via side panels, and providing theme alignment using the Corbu theme).  It does not for instance re-model the layout of your SAPGUI transaction.  That’s when you might need to overlay other solutions such as SAP Personas.

So, if you are seeking to uplift the user experience for your SAP end users, consider the benefits of NWBC alongside Fiori.