Business rules the software development arena

Software development technology has evolved to the point where it allows business to call the shots about how applications will work, says Travis Bulford, chief software architect at Red Man Technologies.

Software development tools based on business rules now free up skilled developers to focus on specialised niche issues and let business people with basic `IT nous` shape applications to fit their needs.

The seedbed for this evolution was the fraught days of the 1980s and 1990s when PCs gave end-users the first taste of computing power at their fingertips, which led to frustration with the IT professionals - analysts, developers and programmers - who knew almost nothing about how business operated. There was a critical disconnect between what business wanted from IT and what IT decided it was feasible to give business.

"For so long applications fell short of serving business adequately, but now software development technology has evolved to eliminate more and more of the gaps between what business needs and what software developers understand about the business." Bulford says.

Technology tools have been created to allow the business to make changes to systems without needing the specific skills of developers - or, at least, as few developers as possible.

In the process, developers have been freed up to play to their technical strengths in the niche areas in which they specialise, while people with combined business and IT experience have been called on to orchestrate the niche players in response to business requirements and to reduce the time to productivity.

Bulford stresses that the only realistic way to make this happen coherently is through the use of software development tools that are based on business rules.

"An enterprise services bus (ESB) is a case in point - though a more talked about capability right now is services orientated architecture (SOA). They both work on the same principle: the re-use of elements of software in different parts of a system," he says.

"SOA works with any services. ESB, on the other hand, is a suitable place in your system to publish your business rules, such as how the system decides how to rate an application for a loan and who in the organisation is involved in the process of approving the loan."

The underlying processes and infrastructure don`t change, he insists. But the criteria applied to the rating and the approval workflow must be able to if they are to accommodate changes to the way the business wants, or is obliged, to operate.

These criteria are stored in the company`s ESB and accessed by development tools to create new software that ensures continuity of the essential business style while allowing it to be refined.

"The point being that the rating and approval processes are both business decisions, not IT decisions, so there really should be no need to get software developers to rewrite code.

"It is much easier, faster, and more error-free to let business people make their changes using software tools designed specifically to let them do that. These are tools such as a business process manager or a business rules engine that use the ESB as the platform on which they work."

This means, he adds, that your technical structure shouldn`t have to change so the business can become more flexible.

"The benefits of using software development tools are obvious. Business integrators can do more for their customers using fewer resources and less time. Developers can build progressively deeper specialisations, creating the opportunity for more killer applications to surface.

"Businesses can become truly agile and adapt to new strategies and market demands more or less at will. And importantly, the time to opportunity, time to productivity, time to market and time to benefit all shrink geometrically."

These are compelling reasons, Bulford believes, to dispense with the old style of software development and use new technology tools to develop business-driven applications.