Packaged applications deliver long-term value

Contrary to popular belief, line-of-business applications do not have to be developed in-house to deliver a competitive advantage.

Packaged applications can deliver precisely such advantage; in addition, using a packaged application does not imply having to adapt corporate business processes to the software.

This is the word from JC Oberholzer, software architect at SDT Financial Software Solutions, a company in the JSE-listed SilverBridge Holdings group.

Oberholzer says most business decision-makers view buying packaged applications as an 80/20 purchase in which they will use only 20% of the features on offer. Moreover, they believe the company will also have to make do without any functionality unique to the organisation, or they will have to have it specifically developed at additional cost.

Because of this, many businesses opt to develop systems themselves at a lower initial cost than a packaged solution, but including all the functionality required. While these companies can obtain quicker and cheaper results, they run the risk of immediately creating a legacy application that limits the future developmental options of the concern.

"Applying the appropriate design and architectural principles, and including the appropriate planning for future maintenance and changes, will give the application a longer lifespan," says Oberholzer. "However, choosing a packaged application that has been designed from a single code base according to rule and event-based principles will ensure a more flexible solution that is adaptable enough to keep pace with changes in the organisation for over a decade or more.

Creating an application that will be sold to multiple customers is a complex task, as every customer will have some unique needs. Packaged software developers need to ensure their software architecture caters for this and that they do not need to change their software for every customer, thereby having multiple versions that all need to be maintained and updated. The most efficient way to do this is to ensure there is a single code base that all customers use.

This code base must include a variety of functions that cater for all customers` needs. This is made possible in the design phase, where the core of the application is created and protected from any alterations and tweaking, while the periphery of the solution is fashioned to allow for easy changes and additions to be implemented. Moreover, Oberholzer advises that the periphery be specifically designed to allow rule or event-based customisation to allow customers to tailor the system to their unique requirements.

"There will always be certain functionality that everyone needs, such as a general ledger and cashbook," Oberholzer notes. "However, in a competitive field such as the financial industry, each company enhances its offerings with value-added functionality in an attempt to give them a boost over their rivals."

A rule-based system provides the basics and then permits users to create additional functionality by selecting parameterised components already within the system and fashion it into the required functionality. The developer can add various reusable components to the periphery of the application and allow customers to develop their own processes through a rules configuration interface.

"A rule and event-based system provides for large-scale reuse on a business process, technical and functional level," adds Oberholzer. "This, of course, is only possible through the appropriate application of good architecture and design principles from the start."

With this re-use scenario, developers can deploy the same code base in multiple scenarios. This means a single version to maintain and upgrade, which means more reliable and useful upgrades for customers.

Oberholzer concedes there is a catch. "Domain knowledge is critical to building such a system. A rule and event-based system cannot be created by a team that happens to have good development skills; it needs experience in developing software for the specific industry as well as the business fluency that only comes from time spent working in the sector."

In the engineering field, different qualifications equip people for different jobs. A civil engineer builds bridges, for example, while an electrical engineer focuses on electronics. In the software engineering field, a developer is seen as having the appropriate skills to design any business solutions. This is clearly a mistake.

"You can`t send someone on a quick training course to teach them to speak the same language as the people in industry they will be developing an application for," says Oberholzer. "This is a skill gained from dealing with the real issues people in the industry have to deal with on a daily basis."

Taking a development team with the appropriate domain knowledge and building a rule and event-based application according to the appropriate architecture and design principles will result in a system that can be deployed in multiple locations. All customers will be able to make use of the basic functionality everyone in that industry requires, while they will also easily be able to construct their own rule or event-based solutions to provide themselves with a unique solution.

"The trick is to ensure the application is built for this purpose from the ground up, using proven principles of architecture and design, as well as a development team that knows the industry they are working for very well."