Skip to Content

Why this blog?

There’s a big trend now days to set KPI’s on SAP Implementations on WRICEF’s or similar numbers.  If you’re a CxO and have bought SAP for your business – one of the business cases is the fact that SAP gives you out of the box best practices with only minor configuration and obviously you want that benefit to reduce errors and overall support costs.

I’m not here to debate how much configuration is actually required; or suggest you get a reporting/integration/mobile/etc strategy in place to minimise the number of reports/interfaces/frameworks/etc required.  I’m here to cover off the preconception I see in the market regularly that all custom development is bad.

Definition of Custom Development

For purposes of this blog – when I refer to custom development, I’m not referring to enhancement points, se38 style reports, interfaces or forms. Sure this is a type of custom development, but it’s what I really think “configuring” SAP really means in many cases.  Yes – some developers “configure” a little too quickly without looking at existing functionality but that’s a different topic altogether from where I’m coming from.

What I’m referring to is large scale development on projects.  Effectively developing new modules or significant functionality.  Or from my perspective, when you’re developing the fun stuff that can really differentiate and make a difference to a standard implementation.

So is Custom Development bad?

Well with my EA hat on – generally Yes! – “buy over build” is a pretty typical principle to stick with and in most cases pays off as a good weighted principle in software decision making.  But there are a few use-cases (aka business scenarios) where I say – bring in your Agile team, do some design-thinking, and let’s make this SAP system ROCK for our end-users.

So what are some of these use-cases?

Occasional User Centric Interfaces

SAP ERP UI’s aren’t for everyone and you can see SAP addressing that through iPad UI’s, non-WebDynpro browser based applications and even new products like SAP SUP and Gateway.  This is especially true for those users who only occasionally need to do something in SAP (who typically also don’t want to touch SAP).

If you really want to get engagement from these types of end-users it may in fact be worth investing in a UI that works for end users.  This could be as simple as what Mentor Graham Robinson spoke about at Mastering Technologies in Sydney where he provided a simple email system using email replys for approval of workflows rather than a dedicated UI (i.e. Some design thinking here).

Alternatively, if a more guiding UI is required, maybe you could be providing an offline HTML5 mobile app that can be deployed to end users that interacts with SAP through Gateway, SUP or directly via the ICF* (* Give us a shout if you want the source code from Al Templeton and my TechEd session where we created a prototype jQueryMobile web offline app based on ICF)?

One point around these interfaces…Look for a fast ROI or a stable business process as if you’re not careful, you could be opening up a very expensive maintenance project with specialised resources.  Also, a caveat that you should get ahead of the game with is to make sure you have an enterprise mobility strategy in place that supports this appropriately.  i.e. Get security (both network and authentication/authorisation) sorted first and know your target mobile market as you don’t want to support “everything” at this point of time.

Whoops – I know I said this wasn’t about strategies, but fundamentals are still required in new areas like mobility, and you should also relate this to non-standard UI’s as there are a lot of potential cross-overs (Gateway and HTML5 may potentially be a common solution).

A Related Gap in Functionality that SAP will never Fulfill

Obviously SAP does a lot but it never will do everything.  So what do you do when you have a piece of required critical business functionality that needs integration with SAP and SAP don’t have anything for you.

  • Sometimes there is an Commercial Off The Shelf (COTS) product with just a little tweaking and development to fit your requirements – perfect. 
  • Though alternatively, sometimes the best COTS product will require significant development and potentially complex integration with SAP.

In this latter scenario, you should consider custom development.

So when you have this custom development option; do you go and build this in .NET or JAVA/CE/Neo and integrate with SAP; do you implement this directly within your ERP system in ABAP; do you build a BPM solution with a CE front end, etc?

Well hold your horses first. Let’s make sure SAP don’t have any plans first – I believe there’s a free service you can get from the SAP’s custom development organisation to give you a quote and inform you the intentions of SAP in this space.  That couldn’t hurt to do first.

Okay, now if you’ve got to develop a solution to fulfill your business needs still; it then depends  on your organisation support structure, available skills, the level of integration required with your ERP/CRM/SRM/etc system, plus many other dimensions. How you exactly build this solution needs careful consideration of your specific circumstances.  Strongly consider developing closest to the system with the most aligned data, and in the samedeveloment tools if you can – provided you’re not seen as innovating the core 🙂

Cross-System Mash-ups

Another quick one to highlight as an example is cross-system mash-ups.  Bringing information together can be very powerful; and bringing this information together in a mash-up that provides the users the information they need to make decisions plus act on these decisions is obviously one of the things that the Business Objects targets with dashboards.  Dashboards are pretty much custom development; and it’s probably worth saying that dashboards are always wanted but rarely get delivered and I believe this is related to my main point below.

So What’s with the bad wrap for Customer Solutions?

Custom development is an art – UI, Design, Getting the real requirements and not the perceived requirements, etc. Again, I am not talking about development that takes place in usual implementations of SAP or on small scale .NET database applications.  I feel that typically custom development, and especially custom development within SAP doesn’t benefit enough from best practices from the Software Development industry.  This is not to say it’s always like that but it is something to consider.

I’ve seen both implementations and massive module custom development within SAP and they are world’s apart in terms of the approach.  For example, I often harp on modelling techniques like taking use-cases through high-level sequence modelling before starting a single line of code; and mocking up UI’s for the stakeholder understanding of the solution as part of the blueprint.  I’d love to see this type of activity on implementations, but that’s not the style of most implementations as flexibility is less preferred when compared to custom development..

On that, another thing not to forget is to be prepared for change as custom development does promote a more flexible approach with the stakeholders than implementations.  Expecting a fixed price custom build solution for anything more than 3 months of work, will dangerously give you whatever is written in the requirements and will have a higher risk of failure since the flexibility to alter scope is not there. 

Also, agile techniques work great with custom development; but require a different approach to managing requirements than implementation teams are used to.  I always throw out the concepts introduced by RUP which looks at stability, priority and architectural significance of requirements which allow you to tailor your iterations to align both with customer expectations, and the needs of building a stable foundation. I’ve had numerous successes with this approach, and it’s not quite as extreme when you look at this way as SCRUM might be in your organisation (though this is not a SCRUM versus RUP versus Waterfall discussion).

Finally, it’s easy to build a solution that no one can support except the custom development team; so building a solution based on the underlying support organisation is critical.  Even if it means not leveraging all the latest technologies that could be used 🙁

So in essence, custom development has it’s place, but custom development is a different set-up that can be established, but should not be assumed to be within your organisation unless you’ve made sure it exists.

Happy Coding!

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Mark Teichmann
    I would like to have a look at the sources of your prototype jQueryMobile web offline app based on ICF (and also on the slides if they are available) 🙂

    Thanks, 

    Mark

    (0) 
  2. Susan Keohan
    Hi Matt,
    I was considering blogging a question recently – what’s the difference between an innovative solution and a hack?’ but that’s for another time.
    By all means, we can try to limit our customization, but not at the expense of what the business truly needs.  If it’s customizing screens, reports, or entire applications – of course we must all do the due diligence – of sussing out what is really asked for, and what is really available.  But no, not all custom development is bad.
    Cheers,
    Sue
    (0) 
  3. Graham Robinson
    Hi Matt,

    great topic for a blog – long overdue.

    I, of course, agree that there is a place for custom development. After all without it I am out of a job. 🙂

    You touch on a few things that I see as critical for successful custom build projects.

    Firstly a different way of thinking to traditional SAP developments. Whether it comes under design thinking, requirements gathering, mock-ups, agile methodologies, etc. these all need to become part of every developers kitbag. The old ways of doing things no longer apply and as developers we need to leave them behind before we are.

    Secondly there needs to be better understanding of design paradigms, technology, industry trends, etc. so that architects and developers can make well informed decisions before launching into customer development projects. The SAP view of the world, and the SAP toolsets, are one of literally hundreds of options that could be part of a solution – we need to be prepared to consider them all. Too many times I have seen poor developments because the key people that designed and built them were not aware of tools or design patterns that could have transformed what they delivered.

    Cheers
    Graham Robbo

    (0) 
  4. Matt Harding Post author
    Firstly, for those who shouted out to me – here’s a link to the source code and presentation from TechEd – use at your own risk – though there’s some good ideas there IMO (i.e. Think about using manifest file even for online apps for great performance)

    Sue – Thanks for the comment and looking forward to your blog – That’s a very good question that is obviously open to interpretation.

    Roberti – It’s good to know this message resonates  and I just hope due diligence for custom development gets a better focus going forward.

    Robbo – You hit on the reason for Atlantis, and while Atlantis is possibly not visible right now; it will definitely make a resurfacing next year to attempt to address these concerns.

    And thanks for the tweets those who tweeted too..

    (0) 
  5. Michelle Crapo
    Now, I love what you wrote.  But another thing to consider is a third party solution.  (Or did you say that “buy over build”) If someone else has already been there and done that, there is no real reason to create the code.

    Maintenance is usually a higher cost than you think.

    Note:  I am an ABAP developer and do not want to write myself out of a job.

    Michelle

    (0) 

Leave a Reply