I got an e-mail a little while back from a client that asked a fairly common question and one that I’m sure many consultants get asked. The question as you may have deduced from the title is “Why is it so complicated?” Now that’s a real Pandora’s Box of explanations, but before I dig into things I feel we should add a little more context.
The client was referring to some information he had received regarding an update to a piece of software. The update was a (minor) build release for SAP Org Visualization by Nakisa (SOVN) OrgChart and contained some fixes for some outstanding bugs that had been encountered during testing. The effort to implement the solution was relatively (compared to most SAP projects) small and he was confused as to why just patching the release would be so time consuming (relatively speaking).
For the main part, build updates for Nakisa software are relatively easy to apply. By configuring a Nakisa system you create a set of modified files (the “delta” part of your configuration build) that are held separate to the main/default files. When a build update is applied it overwrites/removes/adds to the default files, but this means that you have to review any file updates against your delta to ensure that any modifications are replicated into your delta files. Sometimes this can be just a case of adding or modifying sections in an XML file, whereas other times there are fundamental changes in how things are done which can require some reworking of the configuration to allow it to continue to meet the client’s requirements.
Whilst SOVN OrgChart is a highly configurable piece of software, there were a number of areas where a “non-trivial” amount of customisation had to be carried out to meet the functionality requirements for this particular client. This meant that the effort for implementing the build was that much more. The requirements were complex, so the solution was complex; and so applying the build was also a little more complex (and time consuming).
Can you not just press a button?
Today most, if not all, of our clients have access to some amazing computing right at their fingertips. Sophisticated mobile applications and cloud driven web services deliver powerful and flexible capabilities right to the palm of their hand. These wonderfully accessible systems also seemingly get updates delivered invisibly or at the tap of a button from their online store.
The super simple, super quick software updates are everywhere. So much so that I think many clients are now having their SMB and Enterprise software update expectations recalibrated to this type of seamless experience … which begs the question why isn’t it that easy just to apply updates?
Well the magical updates they see are just that. Magic. Well more accurately illusion. The reality is that these invisible and seamless updates are processes that require just as much, if not more, effort than many of the updates we might present to our clients. They just don’t see the effort – just the end result.
I believe this is the key to helping clients understand why updates take more effort than their expectations suggest. Before sending them a list of tasks and times for each element of an update I think first we should seek to change their mindset. We should help them re-frame the update so that they are not viewing it as the consumer of the product, but as the owner of the product in their organisation. They need to understand that they are part of the team that does all the work behind the scenes so that the consumers of the system/service out in their organisation see it as this “magical” update.
Less is More
All that being said, we should always be looking for ways to reduce the effort required in all that we do. We should all be lazy. We should look to make things as simple as possible so that we can focus more of our effort on doing even better things. This includes reducing the effort in applying updates.
So how can we do that? Well I’d like to suggest a few things for you to consider.
1. Align & Simplify It
When we’re designing solutions we should take updating into consideration. Long term updates are more cost – both financial and time. I’d expect most designs would incorporate this naturally in any case, but they should ensure that the processes that a system is supporting match with the minimum amount of customisation possible. I’m not advocating making the process fit the system, but when considering all of the factors (legacy systems, strategies, etc.) I think there should be some parity set where some process re-engineering might be a better option than another piece of customisation.
2. Automate It
Many tasks within updates are standard and where possible these should be automated. This could range from installation packages through to standard testing & reporting scripts to even creating custom upgrade utilities. For instance a colleague of mine has developed (and continues to extend) a tool for to allow us to compare Nakisa application builds and help us identify and merge in changes – a job that previously had to be done rather more manually. This actually enabled us to do the analysis for the client mentioned above significantly faster (seconds compared to hours).
It also removes (once you perfect the automation that is) the human risk factor. Humans are incredibly flexible and adaptable, but we’re not all that great at being able to do things repeatedly and precisely.
3. Define It
Whilst not every part of an update process may be able to be automated, the chances are that most of it can be templated in some way. By applying flow charts, check lists and the like we can get a clearer view of the process which builds confidence in the work and generally results in a faster turnaround with fewer issues as people build familiarity with the process. In addition defining the processes can also help co-ordinate efforts and aide communication so that tasks can be carried out in parallel by colleagues further reducing the turnaround time.
4. Share It
Sharing what works, what does not, how we have progressed things and how we get to the position of having good practice is something I believe is key. Complicated updates often have a number of approaches that can be taken and by sharing these with one another in communities both internally (e.g. Jam) and externally (e.g. SCN) we can all save time and effort. One idea can spark off another and so on. Hopefully this blog post might have sparked some off for you.
So why nottake a few minutes to share your experiences and lessons learnt from applying system updates? What approach do you take in helping clients understand where the effort is and why it exists? Do you have any other ideas you can share on how to make applying updates and patches quicker and easier? I look forward to hearing what you have to say.