Sorry if this isn't hot news, but sometimes the business really doesn't like the IT group very much. The IT group is seen as "the people who say NO" when the business comes up with a neat new idea. And that is one reason why things like "end user computing", "business process automation" and so on are so popular. It's not the only reason, of course, but bypassing the IT group is often rather attractive.

More (business) agility is certainly worthwhile and past IT practices have often compromised it. To say nothing of the IT groups' occasional(!) arrogance… However, there is often a valid reason for IT "good practice" and there's a danger that useful things like testing, quality management and configuration management are neglected when the business adopts, say, business process automation. And, in the beginning, this may not matter much - as business process automation frequently starts as collaborative prototyping of simple automated processes with extremely supportive software. Automated process develops in an interactive "people centric" way and formal development disciplines such as testing, quality management and configuration management seem irrelevant. However, this situation doesn't last.

Things seldom remain simple as automated process changes and evolves, scales up to larger communities and is rolled out to a wider community. Business rules, to take just one example, can increase exponentially in complexity as new, possibly contradictory, rules are added. If you run your business on business process automation you will need a degree of "good governance" in this area. For example:

• Testing provides assurance that your process automation works reliably as intended and produces the expected business outcomes;
• Regression testing provides assurance that, say, adding a new business rule doesn't cause existing behaviours to break;
• Quality management provides assurance that the automated processes are resilient and reliable, reasonably effective, reasonably performant and reasonably efficient - that they produce desirable business outcomes without waste.
• Configuration Management is the basis for managing change and impact analysis; it provides assurance that an automated process that is known to work can be returned to after a failed change, after a disaster and if regulators question the operation of a past process

What this means is that business process automation tools must increasingly support formal development "good practice" activities - to whatever extent is appropriate (depending on the importance of the business process being automated and the degree of regulation that applies). Nevertheless, care must be taken to introduce "just enough" of this sort of governance, not governance for its own sake, if the increased "agility" that is the real business driver driver behind most business process automation efforts isn't to be compromised.