No off-the-shelf software will ever completely fit the unique requirements of an organisation, writes Carlo Gunter, COO at e.com institute.
Businesses need to assess the impact and risk of having commercially available or off-the-shelf systems that don't provide a 100% fit. It can safely be said that in many instances a 100% business fit will not have a major impact and that the business value can be received from off-the-shelf solutions.
However, in the event that an absolute fit is required, customized or bespoke development will be necessary. Business operations and processes must continuously adjust to dynamically changing markets and economic conditions – and so must the applications used to enable these processes.
Software development thus remains a necessity. However, it often develops into a nightmare when an ad hoc approach is taken.
There are two application development methodologies that are commonly used: Build, Operate, Transfer (BOT) or Built to Order (BTO). A BOT environment is gaining favour as technology moves towards SOA/Web services and ICT decision-makers realize that a single box cannot fill all their requirements. Whatever the methodology employed, however, the primary challenge in South Africa remains the failure to adopt best practices in the development of software solutions.
Efficient execution and management of the software development lifecycle (SDLC) lowers the cost and time needed for development. An SDLC methodically details the best practice requirements for the various phases of software application development, from initial scoping of the solution to re-engineering, ensuring an efficient development cycle and accurate fit.
Ad-hoc development, in contrast, results in large amounts of money being spent on development. With no set standards and procedures, errors occur in the application and, since development is not documented (or poorly documented), time, effort and expenses skyrocket.
The first step in improving this situation is for software developers to understand the business requirement. This means an understanding of the business environment must be gained and the right skills applied at the appropriate time.
Where software development is approached from a technology perspective rather than a business perspective, the technology can become a runaway train that is not aligned with overall business goals and objectives.
Companies also try to short cut the process by having a technology specialist alone develop the solution. However, the skill set required by a business analysis and system analysis is different – one looks at function and resolving business challenges and requirements and the other at technology design. While having both allocated to a project increases the cost, neither can be eliminated if the project is to succeed.
Solution design is critical and a process needs to be followed if it is to be successful. Too many developers jump right into software design, adding features and functions that are not linked to actual requirements and environments. Prototype development and modeling are crucial and will reduce costs in the long run.
This will also help limit 'scope creep' – one of the biggest challenges any software developer that is trying to please a customer will face if an application is not prototyped or modeled.
Scope creep happens when a customer establishes new requirements and then requests changes mid-way into development. It might be a minor modification or two, but this is all that is needed to completely derail the process. In this scenario a good analogy is the following: a customer initially requests a Mini and then decides a Rolls Royce may do the job better, so the developer tries to fit new Rolls Royce functionality around the Mini design. This is a clear recipe for disaster that makes it crucial to document the acceptance of the work order in detail and get it signed off by the customer.
A typical project will take into consideration the flexibility and scalability that must be accommodated in the development phases from version one to version 10 of a solution. While a functionality wish list may well exist, once the specified business and technical requirements of the solution have been met, developers should freeze further development work, start testing and not add anything until successful.
Many organisations that need software application development services think that if a person/company can write code, they qualify — they don't understand or appreciate application development cycles.
The way software is designed is very important. For instance, it is preferable not to 'hard code', which can be done quickly based on customer specifications. Hard coding makes a solution inflexible, however, and it has to be redeveloped every time a change is required. This is especially the case where business logic is embedded in the front end or in the database of an application.
By doing an immediate hard code solution, developers cut out modeling, testing, piloting, integration testing and change management. In essence, this code is merely a piece of software, not a solution. Many corporates are hoodwinked in this manner. Their systems and applications are developed with hard code and when they require further application development, it is difficult to do since developers must now work with a rigid application.
It is thus advisable to create a dynamic layer where common changes, such as a change in users, can be made with ease. This way, if one rule changes, the business logic still works and it is easy to manage and implement change without calling in the lab guys in white coats.
Applying all the actions required in a software development lifecycle process can reduce actual software development time to 45% or more of the total project. A logical development model will have a multi-level approach, addressing:
* The front end where users capture info;
* Interface layer for other systems integration;
* The business logic and rules; and
* The database.
If best practices are applied, and software development companies ensure their customers comply with development lifecycle needs, hard coding is unnecessary. More importantly, following a best practice SDL approach reduces ongoing cost and total cost of ownership, as well as enhances flexibility.