Traditionally, when companies send out tenders for replacing or building applications, they use a spreadsheet document that lists their requirements next to a generic description of what the application is supposed to do.
However, trying to design a structured application based on unstructured spreadsheet-like requirements is very hard to do. Not only is this approach to designing an application time-consuming and complex, but it rarely leads to an application that the company is actually satisfied with.
My view is that requirements should be based, and described, on the processes the application needs to facilitate. It will give the solution architects and developers much better insight into what is required, and it will give the company a better, more structured understanding of the processes. This will also ensure that any inconsistencies between the different requirements are brought back to almost zero.
It is my experience that this approach can save up to 50% on design time, for both the company and the organization it is working with to build the application. The entire process is impacted, including design, development, unit testing, user-acceptance testing and deployment phases.
Process-oriented design will ensure that development of the application is both quicker and more efficient, as everybody involved – business owner, IT department, supplier sales, supplier development team – knows exactly what is required for the business. In practice I’ve seen 50% quicker time to market compared to modern code-based development and up to 75% quicker time to market compared to conservative coding.
In addition to the development phase, run and maintain will also improve as the same rules apply.
With a quicker response to the market, a process-driven design approach will give an organization the ability to react to changing demands more rapidly.
By Albert Verhoeven, Re-engineering Offering Director