It might not seem appropriate to discuss a software development life cycle (SDLC) in the context of an ERP product but it is very relevant for many reasons.
This isn’t purely a technical blog and I’m not going to get into the various software development life cycle scenarios. I think the main thing about an SLDC isn’t the flavor you choose but it’s simply that you have one at all.
We’ve all been in situations where well-meaning programmers make changes that cause an application to crash or cause something that used to work to no longer work. Some of the main reasons for a software development life cycle is to provide separation between the developers and the end users and to package a set up changes into a Version. This requires separating your product development into 3 distinct phases: Development, Testing and Production. You can argue that there should be a Staging phase between Development and Testing and there should be a Release Candidate phase between Testing and Production. I agree with this completely but the principles in this blog more or less apply regardless of how many phases you have in your software.
As a developer of software, Verticalive has an extremely disciplined software development life cycle process but each organization that purchases a mid to upper market ERP product should have an SDLC of their own.
Let’s face it there’s not many situations where a mid-market ERP product is implemented without some level of configuration or customization. The one-size-fits-many scenario may apply at the smaller end of the ERP market but I would argue that this is because most of the nuances associated with any small business can be handled with a spreadsheet or a manual process of some kind. As your business grows these same spreadsheets and manual processes can become bottlenecks and inhibitors to growth. Once a company gets to the mid-market level, they are better off purchasing a mid-market ERP product and customizing it to meet their specific needs.
Licensing issues aside, on premise ERP products can be installed on more than one server. As the ERP product is customized it can be tested on one server and then those changes can be moved or promoted to a production server when all the appropriate quality considerations are met. But how does one do this with a cloud based ERP product where the servers are…. ??
The UA Business Cloud has been built with the concept that ‘customizations are essential’. One aspect of the UA Business Cloud is the Verticalive Design Studio (VDS). The VDS enables the development, testing and deployment of customizations in structured manner and is essentially its own SDLC environment.
Each UA Business Cloud Customer has a Development, a Staging and a Production environment. There is also a prepopulated set of data which can greatly assist in quality assurance testing. Without getting into the details of the VDS (that’s all covered in future blogs) let’s assume that some changes and additions have been made for a specific customer (the nature of these changes is irrelevant). The customer has the ability to gather all of these changes into a Version and publish those change to Staging. When they are comfortable that the changes have passed their quality tests, these same changes can then be published to Production.
The example below illustrates a series of versions, a description of their features and their status.
This type of audit and structure enables the mid-market ERP customer to make changes to their UA Business Cloud product but control the publishing of these changes to their production users. A mini-software development life cycle to provide structure to the reality that customizations to any mid-market ERP product are required in order for the customer to get the most value from the product.
Our next is going to be titled: ‘Transitioning to a Cloud Centric Scenario – User Interface Considerations.’
If you want to add to this blog post, just leave a comment below!