Extending SAP SuccessFactors using SAP Cloud Platform is an excellent idea, but there are many pitfalls. This presentation explains what not to do when creating your own extension project and why sometimes you might not even want to go there.

1. Extending SuccessFactors
in the Cloud - and How Not
to Do It
Chris Paine
Chief HR Geek, Discovery Consulting
SAP Mentor

2. Who amI?
• Chris Paine
• SAP Mentor
• 20 years of SAP HCM consulting experience
• Chief HRGeek @ Discovery Consulting
• @wombling
• Blog: www.wombling.com
( all images in this presentation either my own or sourced CC0 creative commons from Pixabay)

4. I’ll Cover What not to do For:
• What you want MORE than standard? Why?Why
• Setting up for extension developmentInfrastructure
• What to do when the standard isn’t that standardDealing with “Standard”
• Have a mug of cement sweetieIssues to Deal with
• How on earth to support this now?Support
Questions
Key Points to Take Home

5. But first lets work on some definitions

6. The Cloud Computing Stack - SaaS
SaaS – Software as a service

7. The Cloud Computing Stack - IaaS
IaaS – Infrastructure as a service

8. The Cloud Computing Stack - PaaS
PaaS – Platform as a service

9. Dumplings Made at home Bought frozen Takeaway Melbourne Dumpling
House
Cloud Computing Stack
Soy sauce, vinegar & chilli The UX – the “spice”
Plates, dipping bowls, serving dishes The UI and application structure
Chopsticks, napkins (for inevitable
spilt sauce)
Runtime environment &
Debugging/error handling
Steam dumplings Application services
Store dumpling until needed Storage
Fill and wrap dumplings CPU/Execution
Pork, prawn, beef, veggie fillings Infrastructure code
Dumpling dough Underlying hardware
On Prem IaaS PaaS SaaS
Dumplings as a Service
Inspired by Pizza-as-a-Service by Albert Barron

10. Why?
Flexibility Agility Control Cost Flexibility Agility Control Cost
On Premise SaaS
+ Customized to your business
- Expensive, time-consuming to
maintain / update
+ Completely underITcontrol
- “One sizefits all”
- May not work with existing
applications/data
+ Scalable, cost effective
- Limited application configuration
- No control over individual
application capabilities or
hosting environment

11. SaaSenhanced with PaaS
Flexibility Agility Control Cost
+ Configuredtoyourbusiness
+ Easytomaintain/update
+ Integratedwithexisting applications/data
+ Controlover deployedapplications
+ Limitedcontrolover applicationhostingenvironment configurations

12. But really… Whydo we extend?
SAP SuccessFactors limitations –
• Limited permissions control (need to
control access at field level)
• Licence/Subscription restrictions
• Processes that does not exist in SAP
SuccessFactors
• Real time integration into 3rd Party systems
• Filling gaps in integration that need user
interaction

13. To extend or not?Issue
identified
Need to
access in
standard
screen?
“Just”
additional
data?
SAP CP
Extension
MDF
Think again (raise enhancement request
with SAPSF product management)
Yes
No
No
Yes
No Can we
use
MDF?
Yes
Unstructured
data (beyond
attachment)
No
Yes

14. What not to do:
• Re-create an existing SAPSF process
• Achieve desired results at any cost (unless you really have
unlimited funds in which case, please contact me!)
• Build in SAP Cloud Platform what can be done using
SuccessFactors extension (MDF)
• Re-build on-premise solutions (without redesign/re-analysis of
problem)

15. Techygeek out warning!

16. What do we need to build this?
SAP ASE
Document
Service
Portal
Application
Logs
Monitoring
Service
Master Account
Productive Instance
Productive SuccessFactors Extension
Subaccount
Non-Productive SuccessFactors Extension
Subaccount
Document
Service
Application
Logs
Non-Prod Instance
Authorization
& Trust
Management
Java runtime x2
Java runtime x1
OData
APIs
OData
APIs
Debugging
Service

17. • Structured Storage (ASE or HANA)
• Unstructured Storage (documents)
• Computes (Java runtime environments)
• SuccessFactors Extension Subaccount
Run
• SAP Cloud Portal
• SAP UI5 skillsPresent
• Monitoring
• Logging
• Debugging
Support Monitoring
Service
Application
Logs
Portal
User Experience
Debugging
Service
Document
Service
SAP ASE Java
Runtimes
Authorization
& Trust
Management

18. What not to do: Not use extension account
Master Account Productive SuccessFactors Extension
Subaccount
Productive InstanceAuthorization
& Trust
Management
OData
APIs
Portal
Creating an extension account directly from
SuccessFactors provisioning automatically sets up
trust relationships between SAPSF and SAP CP. The
username of the person in SAPSF is the username
passed to Portal, is username passed to application.

19. What not to do: Not use SAP Cloud Portal/ UI5
Master Account Productive SuccessFactors Extension
Subaccount
Productive Instance
OData
APIs
Portal
Exposing your SAP CP application as a SAP UI5
application that can be consumed in SAP CP Portal
Service means that SuccessFactors theming specific to
the user can be applied to the application.
Also mean that Portal will seamlessly manage
application time-out. The amount of time you’d spend
building just time-out into app justifies the portal cost
in most cases.

20. What not to do: Directlyuse extension account
Master Account Productive SuccessFactors Extension
Subaccount
Productive InstanceAuthorization
& Trust
Management
OData
APIs
Portal
SAP CP allows for various security roles/authorised
users. However, access is set at sub-account level.
Unless you will only ever use one group of people to
support your applications, consider subscribing to a
separate application runtime sub-account.
Productive Application Subaccount
Document
Service
Application
Logs
Java
Runtime x2
Subscription
to application

21. What not to do: Use HANA, or try to live
without structured persistence
SAP ASE
Document
Service
Master Account
Productive Instance
Productive SuccessFactors Extension
Subaccount
Non-Productive SuccessFactors Extension
Subaccount
Document
Service
Non-Prod Instance
Java
Runtime x2
Java
Runtime x1
OData
APIs
OData
APIs
Some of the largest cost of running an extension on
SAP CP is with the structured storage. SAP CP offers 2
options, HANA and ASE. ASE is cheaper. If I were to
write all application logic in SAP HANA or have a need
for an insanely data heavy calculation then possibly it
would be worthwhile, in 4 years, I’ve seen this once.
On the other hand trying to manage multiple
computes without persistence (scheduling, etc) is hard
(consider using non SAP CP persistence even!) Only
the simplest builds can manage without persistence

22. Adopting standards
• Build applications front end using Fiori standard
• Read data from SAP SuccessFactors with OData APIs
• Use standard build tools like Maven
• Use standard lifecycle management tools like Jenkins
• Use standard code management tools like git

23. Adopting standards – with catches
• Build applications front end using Fiori standard
What not to do:
Fiori is SAP’s standard, but it forces some really silly design
patterns. So put button in footers of screens, because
nothing in SuccessFactors works like that! Users love being
confused!
Remember part of aim of adopting standard is to make
user experience great. If UX is not great – vary from the
“standard”.

24. Adopting standards – with catches
• Read data from SAP SuccessFactors with OData APIs
What not to do:
Assume just because it is OData that API will comply to
standard.
OData is a standard which is beyond SAP. However, the OData v2
APIs provided by SAP SuccessFactors do not necessarily map directly
to the standard. There are many places that you will need to use
“Function Imports” to “upsert” data rather than standard OData
services. You’ll also need to apply “special” filters to query time
based data. Experience is key. N.B. SAPSF Learning uses OData v4.

25. Adopting standards – with catches
• Use standard build tools like Maven
What not to do:
SAP offer a fully web based development environment that they like
to spruik. Attempt to use it, or integrate it into your standard build
tools.
The time to build/deploy/test when using WebIDE is much increased
compared to having a local development environment.
N.B. Setting up a developer PC is a reasonably hard task, ensuring all
the environment variable, libraries etc are correct and up to date
generally means a specially spec’d developer PC, so don’t try to
develop on a locked down corporate laptop.
SAP Web IDE

26. Adopting standards – with catches
• Use standard lifecycle management tools like Jenkins
What not to do:
Deploy your own Jenkins environment to SAP Cloud Platform.
SAP, as of current state, do not provide any build services like Jenkins
on SAP Cloud Platform for Neo based application. It is possible to,
but don’t. Build services like Jenkins only need to be active to do
builds for deployed applications – this may be up to 4 times daily in
very busy period. Reserving an entire virtual machine for this is
rather expensive. Instead consider either local Jenkins setup or
dedicated Jenkins cloud service which has more flexible pricing.

27. Adopting standards – with catches
• Use standard code management tools like git
What not to do:
Use SAP’s git repos to manage your builds.
SAP offer git repositories on SAP Cloud Platform. Do not
use them. Whilst the SAP git works very well as a git repo,
it does not allow for reporting, ease of viewing or any
branch management. Instead look to use other git tools,
Atlassian Bitbucket or Github being the two obvious
options.

28. Dealing with issues
• Sometimes the APIs will not do what you want them to do
What not to do:
Attempt to reverse engineer standard SAPSF screens to
“hack” the APIs.
Eventually it’s gonna back fire. Do, instead, contact SAP
support. Occasionally there is a different means to solve the
same problem and the doco doesn’t make that clear. Worst
case, raise it with SAPSF product management.

29. Dealing with issues
• Sometimes the APIs don’t work according to the online help
What not to do:
Give up.
Do, instead, look carefully at the OData metadata definitions,
sometimes the online doco is wrong/out of date. Log on to SAP
support launchpad and search for doco, sometimes it’s better
than publically available doco.

30. Techy geek-out over,
Normal fluffyHR cloudunicorn
service toresume…

31. Communication,
Communication,
Communication….
• Different people will explain and understand different
things from the same discussion!
What not to do:
Expect that everything you say is understood by everyone
you communicate with.

32. Interesting Interesting
English
Not Great Ok Good Awesome EpicCalifornian
Yeah, Nah Nah Yeah Nah, Yeah
Australian
Red Amber Green
Project Manager
Red Amber Green
Conference Timer
Pakaru Yeah, nah bro You’re all good Choice, bro
New Zealand

33. Dealing with issues
• How to structure project?
What not to do:
Expect to be able to run an extension build in parallel with a
SuccessFactors implementation.
There is usually a LOT more work in reaching first iteration of
an extension build than there is first iteration of SAPSF
implementation. No processes exist, they need to be created.
The phases can overlap but likelihood is you will have start one
earlier/add artificial gaps into other.

34. Dealing with issues
• How to resource from business side?
What not to do:
Expect that SMEs who could answer and make decisions on structured
questions about HR processes for SAPSF implementation can do same
when options are infinite.
Due to the inherent flexibility of solution, the SME/decision maker in the
business needs to be able to envisage the multitude of possibilities and
the implications of these. It’s a higher level of function. Don’t under-
estimate the complexity and the creativity needed.

35. Dealing with issues
• How to resource from business side?
What not to do:
Expect that SMEs who are heavily involved in a process will focus
on the business benefits rather than what they are going to have
to deliver once the system is live.
It is really hard to “put on the enterprise hat” for someone that you
have chosen as a SME because the depth of business understanding
they have. For them to put aside their own worries and concentrate
on what is best for business can be very challenging. Ensure your
SME isn’t afraid to make the hard calls!

36. Dealing with issues
• How to resource a team to implement?
What not to do:
Expect that just because you have technical resources that
understand Java and UI5 and OData that you are good to go.
The right skills to implement a successful extension are a mixed bag of
technical know how, learning ability, business process architecture,
solution architecture, communication skills and experience. Without the
experience it is still very possible to get a good result, it will just take
longer.

37. Dealing with issues
• How to test?
What not to do:
Assume developers will test everything.
Your developers will very likely test something the first time
they build it. They may even write some code based tests for
automatic testing. The problems come when something else is
changed that has domino effect. Ensure development team
has “functional” testers in there too.

38. Dealing with issues
• How to budget?
What not to do:
Try to go fixed price without knowing what you’re getting.
Fixed price delivery is a standard for SAPSF implementation. But there
you know what it is (to a certain extent) that you’ll get before you sign up
for fixed price. With extensions it is incredibly hard to fix how solution
should look/behave before starting any work. If you have to fix prices,
aim for perhaps 2 fixed price bundles, one to ensure scope is prototyped
and the other to deliver that prototype.

39. Technical
• SAP CP Application Logs
• SAP SuccessFactors OData
Audit logs
• Managing SAP CP accounts/
databases
System Administrators
• Custom built solutions to allow
access to audits of solution
efficiency, errors, etc.
HR Administrators
• First line of support,
• Masters of the QRG
• Actually find out how people
are using the system and
shortcutting it.
Support
Beyond Technical
• Debugging
• Add new functionality
• Quantum vortex
manipulation

40. Technical
• Assume that everything about SAP
Cloud Platform is intuitive and
managed by SAP.
• It is not set and forget, these people will
need training.
System Administrators
• Under spec the sys-admin functions of
your extension .
• Your administrators will be able to solve
the huge majority of problems before
needing to refer to tech support, but
only if they have the tools to see what’s
wrong
HR Administrators
• Save project time by not on building
and reviewing documentation to
support the new processes.
• Embed documentation directly into the
solution as well as putting it wherever
you normally put reference doco. You
have flexibility – use it!
What not to do : Support
SI Support
• Hope to never
see these folk again
• Do organise ongoing
support contract,
experience can’t be
handed over

41. Support
• How to budget?
What not to do:
Try to go fixed price without knowing what you’re getting.
Kind of a repeat, but truth is there is huge range of capability out there.
One of the better options I’ve seen is to shift the whole responsibility of
application and solution maintenance onto the implementation team,
Dev-Ops, but outsourced. Don’t buy a PaaS and a bunch of development,
buy really flexible SaaS.

42. Do not Build something complex when you don’t need to
Do not Recreate on-premise solutions in cloud, without reanalysing problem/redesign
Do not Underestimate the skills of the team you’ll need. Creative analytic thinkers are needed
Do not Think that SAP SuccessFactors OData APIs are “standard”, experience is important.
Do not Buy everything that SAP sells you, just because it is there you do not need to buy it.
Do Think positively – there are amazing things you can do with SAP CP Extensions and SuccessFactors!
Key Points To Take Home

43. How to Connect with Me
E: chris.paine@discoveryconsulting.com.au
M: +61 417247427
Li: linkedin.com/in/chrispainewombling
@wombling
blog: www.wombling.com