I am now back from the Business Rules Forum, after a long delay in Denver, and catching up on my blog posts. First session on Thursday morning was Hugh Taylor talking about Agile Compliance. It was very early and Hugh tells us that he was thrown up all over on the plane down! The room was hot too…
Hugh starts by discussing business agility, a term he feels is used confusingly. The common definition is the ability to make moves quickly to take advantage of an event or trend. He feels there is strategic agility – mergers and acquisitions, alliances for instance – operational agility and functional agility. His definition therefore includes the whole process – perceiving the situation accurately, react and plan, execute, assess and repeat – as well as these three types of agility. Agility, Hugh says, is a relative process – agility is doing this better and faster than your competitors. This means that the time frame is also relative. You need to make more of the right changes for less money in less time than others.
If agility is this process of awareness and response, how is it impacted by compliance? Compliance can be externally driven but can also be about internal rules about systems or processes. The net effect of this is that compliance acts as a drag on agility. Reporting and restrictions tend to make agility harder. If your three levers for improving project agility you can reduce scope or add staff to reduce time then compliance can act as an additional set of steps or overhead that counteracts this. A recent McKinsey study found that more agile organizations push decision making further down the organization but compliance makes this complex. Knowledge sharing was another key criteria but also has compliance issues as many rules are about data access.
Agile compliance is the desired state. Need to be able to make moves that enable agility but don’t disrupt compliance and reduce the costs of the change cycle repeatably – reduce the drag compliance applies to agility. Agile compliance involves organizational issues as both business and IT must collaborate on prioritization as well as getting more familiar with the compliance/agility issues that both sides have. Empathy and a sense of joint ownership, in the context of the software development lifecycle and in terms of portfolio management.
Hugh made the point that the architectural decisions you make are key to agility. Using SOA as the basic architectural approach helps isolate changes and standardize interfaces. This makes agility more practical as it helps with swapping out pieces, changing the behavior of one service is easier to control and so on. This does require good SOA governance just as the use of rules requires good rules governance.
I think that business rules can help with agile compliance as both sides are hopefully getting experience managing the same systems and the use of rules makes it easier to make changes and verify them. The use of SOA to isolate decisions into decision services also helps.