Senior IT execs Melbourne discussing how business rules automation is reshaping their application development lifecycle.
For most organisations, the pressure to build and release new applications to the market is more intense than ever. Today’s competitive business environment demands that software development processes are as streamlined and automated as possible to ensure product and service innovations are released on time.
It is therefore vital that businesses model and test the integrity of business rules to reduce application cycles and give internal and external customers – who simply don’t care about backend change management processes – the products and services they need when they need them.
Senior IT execs gathered in Melbourne recently to discuss how business rules automation is reshaping their application development lifecycle to give their organisations a competitive advantage. The luncheon was sponsored by Progress.
Alex Watson, GM, IT applications at financial market intelligence and investment services firm Lonsec, says a common theme for organisations today is to provide better customer service and be more responsive to change. In response, he says, many software development teams focus on finding better ways to deliver new systems or features.
“This sometimes misses the most important point which is, ‘can we find better ways to deliver existing systems or features?’ he asks.
Watson points out that all business systems contain business rules that tailor the solution to the current needs of the business. Yet many organisations tend to “bake” these business rules into their systems, he says.
“What this means is that developers tend to assume that business rules are fixed and won’t change and they implement these same assumptions in many different systems, modules and components.
“When these business rules change – and they can be changed by competitive pressures, opportunity, operational efficiency, regulation, and organisational restructures – it can be very time-consuming for developers to find change all of the places where they made these assumptions,” he says.
“The effort required to change business rules is often viewed as BAU (business-as-usual) work, and is seen as a necessary overhead for managing a system.”
Lonsec replaced a legacy system that had become overwhelmingly complex and unwieldy due to many years of baked-in business logic and assumptions, said Watson.
The key principle behind the new platform was for business rules and logic to be separated from the core software as much as possible so these rules could be defined by configuration.
This made is easier for Lonsec to review and understand business logic that was implemented, which reduced maintenance and UAT times. Many projects can also be commenced – and even delivered – when the business is still trying to finalise the correct business rules. This results in less project delays.
Change to business rules and logic could usually be made and deployed independently of standard software release cycles; and many business rules could be changed directly by the business without IT involvement.
Finally, the cost of change was much lower – many common business rules changes did not require modifications to software or re-testing of components, says Watson.
Separating business logic from application code makes for a massive decrease in software development cycles, adds Bill Swale, senior account executive at Progress.
“This is especially true when rules can be modelled and integrity tested in a no-coding BRMS studio. Errors in logic are uncovered and corrected in minutes rather than months later during user acceptance testing. This significantly reduces delivery times and frees up resources to respond to the next market shift,” he says.
Clinton Ross, head of IT projects at Aurecon, says some of the consulting engineering firm’s business rules are built into the code base but not in a consistent fashion across all applications.
“This could be improved for us through standardised use cases to simplify the business rules, which would also drive efficiencies in the development cycle,” he says.
Meanwhile, Roger Fredman, director, court processes and systems at County Court of Victoria, says more modern BPM-enabled case management frameworks allow the organisation to create requirements which self-generate a system configuration and ‘spit out’ a visual business process.
“This rapid requirement-to-deployment method allows the traditional software development cycle to be exponentially shrunk and changed,” says Fredman.
“The move away from coding to configuring has happened and arduous waterfall or lengthy development cycles are a thing of the past if you’re really serious about accelerating your business,” he says.
Fredman says business rules are managed through government legislation but also through the department’s continuous improvement culture. This is why platforms that allow visualisation of business processes, providing a thorough understanding and the ability to change, are critical for profit driven, citizen-centric services.
Increased regulation prompting automation
As industries become more regulated, some organisations are under pressure to automate more of their business processes.
Progress’ Swale says as regulatory oversight increases whether it be for Basel risk models, greenhouse gases or welfare service delivery, the auditing and compliance overhead for any organisation also increases.
“This narrows the time available for core business activities so automating the compliance process frees up time for productive activities. Moreover, when these activities are carried out in real time, rather than at the end of the financial or reporting period, immediate corrective action can be taken to enhance customer service delivery,” Swale says.
Aurecon’s Ross adds that increased regulation isn’t really impacting the organisation but digital disruption is forcing it to mature rapidly. Legacy systems that have been customised restrict the company’s ability to drive change as the business rules are not clearly defined or sit in someone’s head, Ross says.
“We are finding that as business rules are being updated from the business side, it is harder to understand the extent of the changes needed,” he says.
The regulatory environment at Lonsec has been fairly stable for several years so changes to regulations has not been a driving force for automation, says Watson.
Read more: 'What do we get for our IT spending?': A CIO's response
“However, the existing overhead of some regulatory requirements were minimised by the automation of some key processes, which supported the operational efficiency benefits of the automation,” he says.
For County Court’s Fredman, complying with regulations is not a choice, it’s a requirement.
“If we cannot adjust our technology platform accordingly, we have to implement intensively manually processes until the development cycle is complete. This is ridden with risk and potential quality pitfalls,” he said.
Letting go of control
Attendees agreed that there is a need for IT to let go of control over business rules and allow knowledgeable people to implement change.
Business rules exist to generate value to the organisation, and they should not be controlled by IT, says Aurecon’s Ross. IT owes the business a high degree of transparency in how those business rules are applied with and across systems. This allows business process owners greater freedom to drive and own change, he says.
Progress’ Swale says he’s seeing a change in the market where IT people are now looking to provide staff with control and encouraging the business to manage its own process and make changes.
“This is because the BRMS tools are now available to enable the business to modify and run ‘what if’ testing independent of IT so this makes both parties happy. The IT department is free to concentrate on core system development and the business can implement change without being tied to the IT project schedule,” Swale says.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.