Can we move from software development to software assembly?

In an article entitled ‘From Software Development to Software Assembly’ (currently accessible w/o login) in the most recent issue of IEEE Software, Harry Sneed and Chris Verhoef argue that increasing software maintenance costs combined with skill shortages mean that organisations have to move from original software development to much more extensive use of pre-packaged, off-the-shelf software. Fewer people are required to maintain such systems and overall costs are reduced.

Now I have been reading articles like this which advocate universal software reuse for at least 30 years and it is so self-evidently sensible that the key question we have to ask is why hasn’t this happened?

Well, to a significant extent it has happened. Fears of a ‘millennium bug’ in 2000 prompted many organisations to ditch their existing software and replace this with packages from companies such as SAP and Oracle. Increased use of these ‘enterprise systems’ has continued . My experience is that in sectors , such as healthcare and education, where software provides an essential service but is not an integral part of business innovation, use of packaged software for new systems is now pretty well universal.

However, the authors are right that there is still a lot of software that COULD be standardised but which is being developed as ‘original programs’ rather than using off-the-shelf packages. Given the benefits of standardisation set out in the IEEE Software article, why does this practice continue?

I think that there are four main reasons for this:

  1. Packaged solutions include embedded assumptions about business processes and organisations have to adapt their processes to fit in with these assumptions. In some case, this adds cost rather than reduces cost. I worked with a project where £10 million was spent on a packaged solution that, after 4 years, delivered less functionality that the systems it replaced. The key problem here was the mismatch between the process assumptions in the software and the processes used. Trying to change the processes used to fit the software was practically impossible as it would have required major regulatory change.
  2. The move towards agile development is not really consistent with ERP system procurement. The message that organisations have picked up from the agile community is that requirements and software to implement these requirements can be developed incrementally. So, there may never be a ‘complete’ requirements specification for the system or, if there is, it isn’t available until the software is finished. This precludes expensive packaged software as it is essential to understand almost everything that the software is required to do before committing to an ERP system. I don’t know how easy it is to use modern ERP systems for agile development but I suspect that agile approaches are not widespread amongst ERP system users.
  3. The short-term model of business where shareholders expect very rapid ROI means that managers, in many businesses, are not rewarded for savings that might take years to accrue. In fact, they resist risky package software because they know they’ll be blamed for cost overruns but will be doing some other job by the time any costs are saved. This has been the principal reason why there has never really been widespread investment in engineering for maintainability.
  4. Increasingly, businesses and other organisations rely on software for innovation. Gaining a competitive edge is harder when everyone is using the same package and it’s easy to replicate what competitor’s have done. Therefore, even if there are long term costs, the ability to create new software that’s different may lead to significant short-term benefits.

There are also other social and political reasons why standardised software is rejected by both developers and managers but I don’t think these are as important as the reasons above.

Will the situation, driven by skills shortage, change as Sneed and Verhoef suggest? Maybe skills shortages will be the catalyst for change but I am not optimistic about this. Software-driven innovations will become increasingly important for all industries and this factor alone means that we’ll be developing and not simply assembling software for many years to come.

2 thoughts on “Can we move from software development to software assembly?

  • October 5, 2016 at 3:04 pm

    I was reading your Software Engineering 10th edition book and enjoyed it. Great information package. I just wanted to leave thanks for it

  • September 6, 2017 at 5:57 pm

    I am very happy to express my sincere thanks to you for the nice presentation of all topics in software engineering. While passing through my academia in all three phases like learn, understand and imparting knowledge to my students, I have gone through your book & found very useful.

    But, I have a suggestion, please do add some example / case study/scenario which suites the context of software engineering phase / context / standard / method for which we may have to refer web / research papers till date. Hope I have expressed my frank opinion neatly.

    Regards / SKM


Leave a Reply

Your email address will not be published. Required fields are marked *