To effectively prepare for Dynamics Development’s future, we must first understand its history. Only then can we build on the core principles that have always underpinned progress and success, while avoiding the mistakes that have too often held companies back.
Customisation Without Control
At first, finance systems were highly standardised and offered limited functionality. For companies selling small numbers of basic products this was largely sufficient, but for more complex organisations the ‘one size fits all’ approach presented a major problem. They required a system that could adapt to the particular characteristics of their company and industry, and they were willing to pay for it.
Consequently, solution providers began customising their systems, offering enhanced functionality and usability to meet customer needs. At first, this looked like significant progress, but gradually became apparent that it had introduced a new set of challenges.
With this constant cycle of modifications, core functionality became confused and diluted. Each stakeholder wanted something different from the system and each change chipped away at overall usability.
The Documentation Deficit
Where documentation had once been straightforward, this growing trend of customisation meant documentation quickly became out of date and inaccurate. It was viewed as a “nice to have” rather than essential, and with developers frantically bolting on the next item of functionality, there was less time than ever for these administrative considerations.
As such, system architectures existed almost entirely in the minds of the developers. And any documentation that did exist was mostly retrospective and exposed differences between the competing visions of developer and customer.
The Code: C/AL and C/SIDE in Navision
Navision utilised C/AL (C/SIDE) as its primary programming language. C/AL, a declarative language within the C/SIDE (Client/Server Integrated Development Environment), enabled developers to define system elements’ logic and behaviour. In Navision, business entities and processes were coded as objects, each with a defined purpose. Triggers, auto-executing code segments upon specific actions, and C/SIDE’s graphical interface facilitated object design and modification, C/AL coding, and overall application management.
Developers employed C/AL for data access and manipulation within the system, including record creation and modification in tables, data validations, and managing inter-entity data relationships. One of Navision’s strengths, its customisability, allowed developers to use C/AL for system adaptations or new object creation, tailoring it to specific business requirements.
Spiralling Costs
Another effect of the persistent customisation was on the bottom line. Project scoping became increasingly complicated, with unexpected costs emerging at late stage – some accepted by the customer and others absorbed by the provider. The net result was a situation where both parties felt out of pocket and out of patience.
For the customer, things were about to get worse – with so much customisation, the customer was effectively locked into their provider, irrespective of their satisfaction with the system or the service.
Yet things weren’t much better for the provider themselves. Many of their hours went uncharged and throughout all of it they were paying top end rates to senior developers, as demand for such skills massively outstripped supply.
