How Policy-Based Computing Can Automate Tasks and Reduce Costs
- What Is Policy-Based Computing?
- Summary and Final Thoughts
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Over the last several years, many enterprises have concentrated on making individual business processes more efficient. This work has typically been done within application or line-of-business silos. As we look forward, however, continued improvement in business performance will require a more "horizontal" view, looking across the business and its ecosystem of suppliers, partners, and customers—and even globally. In the not-too-distant future, corporations will use business-based policy management technology to control costs, allocate finite infrastructure resources, manage application access, and police security.
What Is Policy-Based Computing?
The term policy-based computing refers to a software model that incorporates a set of decision-making technologies into its management components in order to simplify and automate the administration of computer systems.
Let's consider an example. Suppose an accounts receivable financial system needs parameters input daily: date of payment, general ledger control numbers, and so on. Some of these parameters are hard coded; others are entered manually by the user. The individual programs in the financial system application then access and use the information at runtime. With policy-based computing, parameters can be set up automatically one time and then used by each application.
Policies are definitions returned from a policy data store and used at runtime by application software. In the past, such information might have consisted of hard-coded parameters embedded within an application program. Sometimes these parameters were placed into configuration files where the settings could be changed by editing the files and restarting the application (or having the application reread the configuration file). Policies generally replace the majority of configuration data in a configuration file, and a policy can provide far more data than a configuration file could. A policy may even refer to additional policies and applications as needed to solve advanced issues or provide for more dynamic applications. To continue with our accounts receivable example, the policies defined within the accounts receivable system need to access the policies defined in the general ledger system: data, files, system totals, and so on. This information needs to be transferred to the general ledger when an accounts receivable run is completed. The policy can define the expected outcomes, even down to security levels.
Figure 1 illustrates a simple model of policy-based computing applied to quality of service, security, or even provisioning and configuration.
)
Figure
1A policy manager creates policies to define how resources or services in the network can or cannot be used. The policy-based management system transforms these policies into configuration changes and applies the changes to the network. The software provides an automated configuration and control solution for specific problems in the network.
Advantages of Policy-Based Systems
Significant simplification is achieved by allowing administrators and operators to specify management operations in terms of objectives or goals, rather than detailed instructions that need to be executed. This setup supports a higher level of abstraction, while permitting dynamic adjustment of the behavior of the running system without changing its implementation.
If you have hundreds of applications that use configuration files, for instance, it's probably difficult to manage all of them, especially if many are related to different versions of application software running at different sites. It's often impossible for one organization even to locate all of these applications, as they tend to be managed by various groups or organizations within different locations. Configuration data in a centralized policy store allows an inventory of the existing configurations to be created and managed.
A set of policies might even be created to support sharing application data among different companies—partnering with other organizations to utilize services that provide synergistic capabilities between companies. By linking through networks, for example, NASA can transmit minute specification changes to its hundreds of thousands of specialist contractors that design and build spacecraft parts, software, circuits, and so on. Such automatic transfer of data based on policies minimizes effort and saves money for NASA and for the contractors.
In the simplest terms, policies operate very much like configuration files—something well understood by programmers, system administrators, and support organizations. This likeness makes it fairly painless to adapt policies to existing technologies and applications. Designers and users of new devices such as VPN servers, routers, Internet appliances, and wireless gadgets need to consider how to utilize policies to deploy their applications. Security policies can be standardized across the enterprise for more effective security.
With policies, network operations are simplified (compared to managing configuration data on dispersed systems). Support becomes more effective because methods and configurations can be made accessible to support organizations. This change should reduce support costs and reduce downtime once issues are detected. Engineering staffs benefit by being able to more easily reuse and expand existing applications. Many parameters can be exposed, allowing for improved support or application tuning.
There are many general benefits of policy-based systems:
Centralized management. Applications can be anywhere, but the operational settings are visible no matter where they are.
Scalability. As you need more processing power, added processors can share one or more dynamic policies.
Flexibility. Policies can hold some things that configuration files can't; for example, serialized Java classes. Different parts of a policy or groups of policies can also be used by different applications at the same time.
Adaptability. Existing programs can be adapted to use a policy rather than a configuration file and join in as a new processing agent to a larger application solution. Any program that can access an LDAP policy store can use or share a policy, and any application can provide dynamic updates to one or more policies.
Reduced IT complexity. More application automation simplifies things for the ever-more-precious IT staff.
Versioning. You can have different policies of the same name available at the same time, allowing applications to roll forward or backward depending on a variety of factors such as special events, work hours/off hours, holidays, and so on.
Specificity. Policies can alter functionality based on application load or particular events such as large, complex conversions or upgrades.
Uniqueness. Different policies can be defined for all operational interfaces. This could mean a unique policy for each unique device, which becomes important when associating XML with specific policies to support a variety of devices (Internet-enabled, wireless, etc.).
Creating applications and supporting business processes across lines of business or organizations requires the ability to use and integrate existing applications and processes. Such flexibility allows businesses to adapt and assemble new applications to support new business requirements. If there was ever an argument for using industry standards, it's being able to quickly integrate processes that weren't built to work together, derived from a variety of vendors. With industry standards, applications don't need to be re-created every time some piece of hardware or software changes, or rewritten to support changes in dependent processes.
Aside from the business flexibility that comes from the ability to integrate people, processes, and information across the business, the IT infrastructure must be made simpler and more manageable—that is, less complex. This need includes support for virtualizing required resources and automating the management and operations of the IT environment.
Policy-Based Systems Versus Service-Level Agreements (SLAs)
Policy-based computing can be compared to the typical end user service-level agreement (SLA) now used extensively throughout the IT world. Service-level agreements are modeled as a contract among two or more parties in a service relationship, designed to create a clear, measurable, common understanding of the role each party plays in the SLA. A party role represents a set of objectives and rules that define the minimum service-level expectations and service-level obligations, deliverables that affect other roles, and constraints. With policy-based computing, the individual system parameters and constraints that set the service levels for each application can be automated—similar to today's SLAs. Policy-based computing will eventually be written into service-level agreements; for example, a policy might specify a vendor's agreement to maintain a specific response time to fix system problems.
NOTE
To be effective, policies must be managed in an automated fashion. Policy management applications need to be created to allow operations staff to properly configure the policy-based applications. Policy viewer applications allow the current status of the policy to be viewed by anyone who needs to see it. Engineering alterations may need to be provided. Engineers, data operations, policy managers—even the applications running against the policies—create operational information, XML DTDs, program logic, and so forth. This topic is quite complex, and beyond the scope of this article.
Downsides of Policy-Based Computing
The following list highlights some of the more difficult aspects of policy-based computing:
Infrastructure must be in place. Policy-based computing will not run on existing infrastructures.
All systems, software, and applications must know how to interact with the policy server.
The datacenter network must be able to support the policy-based applications.
Network delays may affect directory access operations; the design of the applications need to take this issue into account.
With the advent of utility computing as well as computer and storage virtualization, corporate concerns about policy ownership issues have risen to new heights. The major concern is that business-based policy must be end-to-end and be set by corporate management, and then translated into deployment policies within the policy of infrastructure operations: user workflow; network, storage, and server infrastructure; and application software.
The new world of IT, based on utility services, will require a basic rethinking of the way policies are created and managed within the corporation. No longer can policy exist in independent islands, nor can it be in the hands of vendors. This issue is so important that a new corporate executive office is created: the chief policy officer (CPO) tackles the tasks of creating corporate business-based policy practices and procedures, and identifying and integrating policy-island infrastructures. This first step will set the foundation for an implementation that's based on the methodologies required to translate, distribute, administer, monitor, and manage policy end-to-end within the corporation, from the user to the application, in a seamless way rather than piecemeal.