Original URL: http://www.theregister.co.uk/2006/11/01/policy_primer/
A policies primer
You may think you won't need them, but you probably will
The suggestion that the next upgrade of the major applications suites such as Oracle and SAP will force users into adopting systems and business management policies that they may not realise are necessary has met with something of a mixed reception.
Companies that sell the technology required to implement and manage such policies see the arrival of the upgrades as the cause of potential problems for users if the issues are not understood and actions taken as a consequence. The applications vendors, however, do not see users facing many issues at all.
The suggestion is that many companies are likely to find IT operations more complex to manage than anticipated with the next upgrades, mainly because these applications suites will provide IT departments with the power and flexibility of SOA capabilities regardless of whether they are needed or have been specified. In such circumstances, these users will face the corollary of having to understand and implement policies that before now they would have considered unnecessary.
The reasoning is straight forward. Up until now the technologies underpinning the traditional applications suites were not designed with third-party applications integration as a primary goal, so it was only ever attempted if the need was absolute. "It was a bit like pulling teeth to integrate different systems together," said Dan Foody, CTO of the Sonic and Actional division of Progress Software.
By comparison, the next upgrades will make it easy to link together applications from a wide and growing range of vendors, so easy that it will not necessarily even need a developer to do it – a reasonably tech-savvy business user will be able to do it in many cases. "The problem is, they will probably do it inadvertently, without realising they may be exposing their company to risk," Foody said.
This is certainly possible with some of the desktop and server tools available from the likes of Microsoft, such as InfoPath. Here is a tool primarily designed for use within a closed, Microsoft environment. But in an SOA-enabled environment, it could be inadvertently used to build inappropriate links between applications and data. It is also not that unusual for such desktop applications to be in use without being under the specific control of the IT department. Indeed, they might not even know such applications are installed and operational.
However, according to Jeff Stiles of SAP's Palo Alto Laboratories, SAP is giving customers the choice to adopt new functionality and Enterprise SOA at their own pace. "For example," he writes, "customers can (move) to a simple technical upgrade from R/3 to mySAP ERP and leverage the same user interface and capabilities without turning on (or) deploying new ones like role-based work centres, self-service, Duet™, composite applications, Interactive Forms, etc. They are able to incrementally deploy these capabilities and leverage the underlying configuration, security, role definitions, etc".
There is still the suggestion, as made by Willy FitzPatrick of Amberpoint, that there a large number of companies which have never thought in terms of implementing SOA will still face a requirement to implement the same types of management policies that are common currency in enterprises that are consciously moving towards SOA, once they have upgraded. At a base level there are not too many policies to consider, but they are now an important part of the mix for all IT departments planning and management work, even if SOA is still not part of 'the plan'.
According to Foody, the single most important policy to implement is one of visibility. "It will be important for the IT department to have a clear and comprehensive view of what is going on within the enterprise, particularly in terms of what applications and/or services are in use and who has access rights to them."
This must also include the applications and tools that are part of every desktop suite, where individual users often load applications or tools of their own.
This means that IT does need to invest in automated systems that provide the agents needed to locate all applications and services and identify all the users associated with them. This will allow IT to identify unauthorised usage – which with the upgraded applications suites is far more likely to be inadvertent than malicious – as well as gain much tighter control over access in the future.
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. ®