A policies primer

You may think you won't need them, but you probably will

Common Topics

The second most important policy – if only because it could lead to directors and senior managers ending up in jail – is to provide compliance to the wide range of regulations and legislation that now have a direct impact on enterprise business processes. The policies will need to cover and document the specifics of those business processes, which for many enterprises may seem a straight forward exercise based on the way they currently operate. Upgrading to new applications suites will, however, make it a far simpler exercise to change business processes, quite possibly without realising that such actions could also lead to a breach of compliance.

SAP's Stiles suggested that, with regard to deployment of specific capabilities, there aren't any risks of malicious misuse that he could think of.

"Simply stated, the functionality customers need that is delivered with the application should be deployed based on business needs in the priority order of the customer's business requirements. SOA is a means to the end of being able to deploy this functionality more easily," he wrote.

To some extent, of course, the issue then becomes how great that ability to deploy functionality more easily can point away from the conspiracy theories of malicious use to the cock-up theories of unmanaged misadventure.

Security issues are also important, but Foody indicated that these must cover not only the obvious need to protect the business from external attacks and internal information leakage but also from the wider implications of applications usage itself.

"Security issues are an integral part of a wider set of risk mitigation policies, and that can include the risk implicit in the inappropriate use of new applications suites. It is possible that inappropriate integration of applications – far easier to engineer with the new applications suites – can create situations where an application effectively goes wild."

This could be either through a user's lack of knowledge or understanding about the full impact of interoperation, or the limitations of an old application in a new environment, but either way the result could be the risk of a self-induced Denial of Service attack.

As part of the wider risk mitigation area, there will also be a policy requirement for regular design and security reviews. "The particular issue here is that the new application suites create an issue of applications relationships. Such reviews need to take account of what applications any new application will be working with and what the impact of that new relationship might be. Such policies will therefore need to address this issue of applications relationship management."

Stiles took a more benign view of the situation, however. "Regarding policies for developers," he wrote. "Good IT governance and practices includes policies around integration standards and development techniques (both semantics and tools). Certainly naming conventions, coding approach, documentation, etc all represent areas that should also be addressed for SOA-based approaches, but I do not see this as any different from traditional IT governance/practices around any development or integration work. These practices may be extended to a new class of business process experts (folks who are doing modelling as opposed to programmatic development)."

This does perhaps point to one other policy that such companies should now consider, namely model your business even before any upgrade is considered, and then control how it changes after the upgrade is implemented. ®