Skip to Content

Architecting for disposable code

An enormous amount of time and money is invested in change management and training when a new project is rolled out.  In my experience, change impact is inversely proportional to the quality of user experience delivered in the new solution.

This user experience can be significantly enhanced by customising screens and transactions for specific user functions.  If the user gets a better-than-now experience, adoption and rollout becomes much easier.

However, customising transactions and screens has often been expensive.  It is not hard to generate thousands of lines of code to implement a relatively straight forward dynpro.  And integration to other platforms introduces an additional magnitude of complexity as multiple parties are required to collaborate at every point.

Why can’t we architect solutions that delight our users without compromising budgets or maintainability?

The answer is to include “light” front-ends for processes that cause the greatest change impact.  That is, the processes that offer the worst user experiences.  If the idea that 20% of processes account for 80% of screen time resonates in your project, invest a little in the quality of that screen time.  Keeping it light means:

  • minimal governance
  • opportunity for agile development in collaboration with end users
  • short life-span – expect pay back in less than 2 years
  • focus on “sizzle”
  • NO built-in business logic or data – well governed services behind the front-end take care of that
  • ok to use alternative platforms – mobile, .NET, Flex, Portal
  • disposable – as requirements change, expect to ditch existing front ends a build new ones
  • investing in SAP Platform User Licenses across the business

Where it makes sense, train super users on standard GUI transactions for maximum power and flexibility.  But where the standard user experience is not working out, build beautiful, customised, disposable user interfaces utilising all the technologies at your disposal. 

The key to success with this approach is to focus investment and governance on the functions and services that sit below the user interface.  For example, don’t let your .NET programmers start building business logic into their code stack, because no matter how much easier it may be to bypass collaboartion, the .NET front end becomes core rather than disposable.

But for that front end, cut out the middleman as far as possible and let your crack developers work closely with end users to craft exactly the interfaces they need for now.  You will easily pay for it with the savings from training and change management.  Your users will buy into it, and your best developers will be thrilled to spend less time on documentation and more time on their creations.  Keep it light and sexy, and you can easily replace it when your business grows out of it.

You must be Logged on to comment or reply to a post.
  • The problem with calling something “disposible” is that to many people it means it has no value. It also annoys the user community when the look and feel they have grown used to suddenly changes for no apparently valid reason. Consistency in areas such as layout are very important for occasional users and they need to be accomodated in the front end design.
    • I guess the annoyance you speak of is experienced by occasional users when told they have to use SAP now for something that used to be easy…  A little bit of custom front end can help a lot.  My point is to architect this in a way that vital business logic does not diffuse into something that could be tactical.