This week IgniteSAP will be discussing cloud application development, “Continuous Integration and Delivery”, and the associated implications for users of SAP and SAP-based IT consultants.
SAP’s long-term plan, along with the majority of software companies in the market, is to encourage users to adopt cloud-based software. The SAP customer base is on the whole aware that it is necessary for them to move to cloud-based provision of software as well as implementing S/4 HANA and fully intends to do so but “not yet”. This reticence is understandable but time is running out.
The benefits for the customer (and those producing and maintaining the software) in transferring to cloud-based provision of applications have been covered elsewhere so we will not be concentrating on that but instead we will take a look at the implications for SAP customers and those professionals contracted to implement and maintain SAP systems.
Of particular interest is the industry trend (popularised initially by Google and Facebook development teams) of continuous development schedules.
In the beginning of commercial and mass-produced software, updates to purchased software would occur several times over the course of a few years before a new instalment of that software was released. In the intervening period the development team responsible for the new version of the software would have collected as many bug reports, crash reports and common errors as possible and addressed these by allocating the problem to smaller groups of developers to fix and then compiled these into a “new and improved” version which could be bought at full price, or the owner of the previous version could get an upgrade at a reduced rate.
This inevitably led to another cycle of the same process of logging problems unforeseen by the previous development team before another iteration of the software was released. In fairness to this hypothetical development team it was usually due to changes to operating systems and commercial environments outside of their control. In fact there was some motivation for software companies to perpetuate this state of affairs as it ensured to some extent a cohort of customers to whom they could resell what was essentially the same product every few years.
The problem for the customer, apart from the fact they were continuously buying the same product or paying over and again for corrections to what could be seen essentially as “mistakes” with the initial software, was that if a clear fault was revealed by daily use of the software by thousands of users in what was implicitly an extension of the Beta-testing process then they had to wait for at least a year before this problem was addressed.
The current consensus among software providers on scheduling for “updates” (or as they might be termed “corrections”) is once every quarter. Some suggest that this is a good compromise between collecting as many changes as possible before interrupting user behaviour with an update or fatiguing a user with daily updates: nobody wants to sit down at their desk every day and have to watch an update process before starting their urgent assignments.
However, with the advent of cloud-based computing the functionality of the software can be changed on a daily, if not hourly, schedule as needed without interrupting the user of that software. This is because the user is remotely accessing the software residing on a server and so the functionality within the software that they have access to will be “updated” next time the user starts the connection to the software from their device: which by now is rapidly becoming a universal interface rather than a data processing device.
“Continuous Development”, or as SAP describes it “Continuous Integration and Continuous Delivery” clearly has benefits for development teams and users of software but speeds up the schedule for the impending doomsday at which date legacy systems will be not supported. Legacy support is possible but is considered a distraction for developers and a temporary solution at best for end-users of the software, as eventually even the operating system and the hardware used to run it will be outdated.
The new customer expectation for Continuous Development is also a monumental responsibility for developers and as such this new workload is likely to fuel further jobs markets for software developers, and by extension for IT consultants as well. The pace of change in the software industry is reaching an event horizon which can only be addressed with a far greater workforce to put in the hours required, and careful delegation of tasks within that hierarchy to resolve bugs and errors on a daily schedule. Also, the sheer number of lines of code must be reduced and simplified by teams of programmers to ensure the smooth running of the infrastructure used to support the software.
The cascade effect of these changes will result in a greater need for expertise in the IT sector and so these new demands on the knowledge base will lead to extensive training requirements. Lifelong learning will be essential for IT consultants in order to keep up with the pace of change, beyond certification schemes for individual software packages produced by companies. Even daily users who are not specifically IT professionals will require companies like SAP to dramatically step up their efforts to re-educate the customer base regarding the new functionality of the software as it becomes available.
An article appearing this week in SAP News by SAP’s executive vice president and head of Customer Solution Support and Innovation for SAP Product Engineeringaddressed some of these issues with typical optimism and is worth highlighting as it indicates that SAP is looking at overhauling the process of software development itself through continuous interaction with customers. It perhaps overemphasises the benefits of daily development but is a great insight into the culture driving the changes we expect to see taking place over the next few years.
“Daily delivery of new software functionalities and upgrades removes the risk of difficult-to-resolve surprises that often happen with on-premise software. SAP customers… can submit a note immediately through the software, detailing where a feature may not work as well, a dashboard could be improved, or an interface could be more seamless. SAP’s development team receives this information in real time, assesses the request, and assigns the appropriate developer to resolve it.
This design-thinking mindset gives SAP space to listen to customers carefully, understand their needs thoroughly, and deliver on expectations quickly. This methodology prevents the investment of time, money, and resources on features or upgrades that are not used or relevant to customers.”
What is evident is that the burden of responsibility lies somewhat outside of SAP’s control in that customers are required to engage diligently with this process in order to complete the feedback loop. Because SAP developers spend their working lives creating the tools, and not necessarily implementing or using them in countless potential real-world contexts, then they are dependent to a great extent on IT consultants and other users to not only flag up problems as they come across them but to provide clear descriptions of the problem and its context for the benefit of developers. No amount of customer surveys will provide a comparable level of necessary interaction between makers and users of these products and so customers, and those who implement SAP solutions will have to give a little of the time required to close the loop. Customers will have to view this effort as a philanthropic act for the common good, and IgniteSAP advocates such behaviour. The current economic climate requires that everyone make a small amount of effort for the good of everyone else in order that businesses as a group may bounce back under conditions of stress. The benefits of the cloud will trickle down to everyone on the planet eventually through the increased efficiency of energy and resources used to support the worldwide economic infrastructure, and users or SAP and other ERP software solutions will benefit more directly by daily improvements to the product they use.
Let us return to the point we made above about the benefits to the industry of innovation. Yes, there is an added burden of education (to SAP and other cloud application providers and users), in the adoption of this new technology but the benefits were unimaginable a few years ago. Hypothetically speaking, if a user of a piece of software discovers something is inconsistent or just plain irritating about the way that the software that they use works, then it is possible to not only point this out directly to those that create the software but also look to their peers and ask them to do the same: democratically instigating a process that will drive an army of developers to fix that fault, potentially within days.
Also, we should reiterate that these “problems” of improvements in software applications and the way that they develop are in fact one of the key drivers of employment in the industry. As long as we get on board and keep up to date with these developments then we will make ourselves invaluable to those who can’t or won’t. That is the nature of our skill driven economy and the reason why early adopters often find opportunities that lift them above their competitors.
