Business Continuity and ILM: a layered availability solution.

Although Business Continuity (BC) and Information Lifecycle Management (ILM) are not generally viewed as related disciplines, it is without a doubt that they both have one basic premise in common: ensuring data availability. Add Disaster Recovery (DR)--which, although often discussed in the same context as BC, is different in that it is more often employed in extremes as its name suggests--and you have the tools to provide:

* Users with the highest levels of application data accessibility

* Corporations with economic and government compliant solutions

* Enhanced shareholder value (at a minimum, a corporation must prevent degradation of corporate value due to a perception of risk.)

Balancing the requirements of these disparate constituencies is the primary challenge when considering the right availability solution.

Balancing Availability Requirements

User Application Data Access: IT departments frequently view end-user demands as unreasonable and impossible to satisfy, primarily because complex computing environments are both costly and wrought with unpredictability. This unpredictability is the primary consideration in all BC and DR solutions; it is why they exist. So what makes user demands unreasonable? After all, they simply require:

* No disruption to their day-to-day business operations and tasks

* High performance with no apparent latency between task requests and completion

* No limits on growth regardless of the business value of the information

* Immediate access to that information despite its creation date

Not unreasonable for a handful of users perhaps; but when these demands are multiplied by 100 or 1,000 or 10,000 individuals, the environment becomes difficult to manage and potential issues and problems become impossible to predict. However, breaking down each demand into legitimate requirements can help determine the quality of service (QoS) levels that are truly achievable.

For instance, planned disruption--otherwise known as maintenance--can be scheduled so that only the minimum number of users are affected and, for those affected, off-line techniques can be employed to further reduce this inconvenience (there are many application and data synchronization dependencies implicated by this scenario). To minimize this disruption further, alternative on- and off-site computing resources can be utilized to shift the workload while maintenance is conducted or while unexpected issues are resolved. Therefore this requirement can be summarized and refined to state:

This X-application and X-data is required to be available during this X-period. In the event of an outage, this X-mechanism can be utilized as long as the affected data is synchronized within X-period of time. The maximum period of disruption cannot exceed X-period.

The infrastructure solution that results to support this particular QoS will incorporate load balancing, resource availability to process new tasks and associated data, and mechanisms that can be employed to serve requests for data previously processed and stored. Integrating infrastructure solutions with data policy definitions (e.g., the importance of the application and its data, the time limits associated with data access, and the relative prioritization of the application through downtime tolerance) form the basic tenants required for BC and DR.

Note that ILM requires yet another level of policy definition: Retention. How long data must be kept and what infrastructure is required to make it accessible and usable are important ILM considerations. This last policy definition must take into account the combination of user and corporation requirements, which are in turn driven by the government (e.g., Sarbanes-Oxley regulations).

Corporate Considerations: Unlike end users that generally believe that all data is created equal (i.e., every e-mail sent is important, every document vital), corporations have certain applications and data that are more critical than others based on relative business value. In addition to classifying the data, the corporation must also design, implement and maintain the supporting computing infrastructure.

Many corporations have already defined the applications that are considered critical, and they typically rank customer-related data as one of the most important sets of data. Making these distinctions are the first steps in the development of effective BC and DR plans.

This type of classification process was brought to new levels of importance just before the turn of the century with the implications created by the year 2000 or Y2K. Many corporations did not have any type of methodology, disciplines or mechanisms to determine what applications and data were the most critical, and more importantly, what risk they were incurring if they did not have the application and its associated data ported to compliant platforms. Corporations learned from the Y2K "fire drill," developing basic risk analysis techniques and converting this knowledge into very useful BC and DR plans.

Today, new classification requirements are being driven by the Sarbanes-Oxley regulations imposed by the government. Now in addition to classifying applications and data by level of importance, corporations must develop a disciplined approach for managing the data throughout its lifecycle, the length of which has been extended indeterminately by these regulations. If not compliant with these regulations, corporations face serious legal implications. The new regulations have done much to propel ILM into the spotlight.

The final piece of the puzzle must now be considered: the computing infrastructure. System administrators know that even if the application (via installable software) and the application's data are available, the correct operating system, computing platform, and data extraction gear must also be available in order to make use of the application and its data. Also, personnel who know how to perform this extraction--or at a minimum have very good processes and procedures to follow--must also be available. The demand for this expertise--especially as it relates to legacy systems--has created great opportunity for knowledgeable IT contractors and outsourcing centers. Taking advantage of this emerging service industry may be the most economical choice for those corporations in the process of developing an ILM strategy.

Satisfying the Stockholder: Until now, the focus has been on what internal users and associated corporations require in order to have high availability for the applications, data, and infrastructure. However, thanks to the widespread publicity generated by companies that have failed to meet government requirements, savvy shareholders today understand the implications this lack of compliance can have on their investments. And a computing infrastructure that isn't "up" is "down," thereby impacting productivity, customer perception and, ultimately, profits.

A corporation is viewed as the sum of all of its processes, tools, data, and personnel. Today, corporations are expected to be able to produce availability metrics--the report must include downtime statistics. To mitigate the loss of confidence associated with a poor report, a corporation must implement effective BC, DR, and ILM processes and tools. Additionally, a direct link must be made between a corporation's IT expenditures and the Return On Investment (ROI) garnered in the pursuit of disaster prevention. By employing these disciplines, a corporation can meet and exceed shareholder expectations.

A Closer Look at BC and DR

BC's Role in Day-to-Day Operations: Fundamentally, the primary difference between BC and DR is the speed of recovery (or return to availability). BC has a recovery speed that can be imperceptible at best, inconvenient at worst. That is, a disruption or interruption can be so brief that an end user doesn't notice that their application failed from one application instance to another, one server to another, one network path or component to another, and/or from one storage array or component to another. In the case of BC, any failed component can be categorically termed a "mini" disaster.

This speed of recovery is enabled through the in-chassis operating system and application instance redundancy, server clusters, traffic management software, redundant paths and network components, redundant arrays and components, and tools that provide continuous backup is a term that implies that data sets are frequently copied and can be restored in a seamless, automated fashion.

Technologies that support continuous backup have only been available for the last few years. The most-reliable and sophisticated of these products incorporate file system and archival techniques, are highly scalable, utilize multiple backup media and devices, and most importantly, provide user and application data as needed without special restore commands or requests.

Typically the expense for a BC solution is rather high and, in extreme cases where high availability must be guaranteed, these infrastructure components are sometimes fully redundant and only allowed to operate at a maximum 50% peak utilization rate. In cases where human life can be at risk, typical configurations are triple-redundant and the relative peak utilization rate is somewhere closer to 33%. In addition, each of these components will also typically have redundant internal components.

BC solutions can be implemented in a local environment (all components within one building or campus) or they can span various geographic distances (metropolitan or geographically dispersed computing centers). Note that the further the distance, the longer the recovery time due to fundamental limitations like the speed of light in fiber optic cabling, for example. Recovery can be dependent upon an application's ability to sustain an interruption at one site and seamlessly take over functions at another site. Applications may also exhibit other limitations like those that result from synchronous processing (as opposed to asynchronous processing where an application does not necessarily wait for an operation or task to complete before it begins another process).

DR Loses Optional Status in Wake of 9-11: Whereas BC strives to provide uninterrupted computing services on a routine basis, DR recovers these services within periods of both planned and unplanned downtime. Once thought of as a "nice to have," DR achieved new status when the consequences of not having a plan in place became more evident following 9-11. The key to an effective DR plan is accounting for the amount of time users can go without data access before business viability is impacted through loss of productivity, customer service disruption, and (longer term) a loss in shareholder confidence.

DR typically focuses on providing an alternative computing environment that may not be a complete duplicate of the original. Frequently, DR plans make a clear distinction of what applications and data must be made available first, second and so forth. In some cases, based upon cost considerations, a secondary site may only provide computing resources for the most critical applications. Additional acquisition plans are then implemented should the primary site take longer to re-enable, repair, or restore.

Restoration of services and applications is very dependent upon the restoration of corresponding data. How important is the timely restoration of data? Unless a company's business makes it easier to replace existing customers with new ones, the answer is obvious.

Leveraging Mutual Requirements: In the description of BC above, each computing resource failure was labeled a "mini" disaster. By its very nature, DR is typically only implemented in the case of a "major" disaster. In either instance, both disciplines must have effective and well-tested data management processes, procedures, and tools. Data sets change, expand, and can grow stale; therefore, corporations must be prepared to handle these various conditions via a flexible BC/DR strategy.

BC, for example, requires continuous data availability, and to meet DR requirements, this same data must be copied and made available via the remote computing site. Both of these disciplines require data handling schema that reflect access and availability requirements, and they both must sustain operations without negative external perception from the customer, the industry, and/or from a corporation's shareholders and investors.

Disasters will happen, but scoping and planning are the keys to an effective, integrated BC/DR strategy. While ILM is not BC or DR, this discipline is definitely molded by these requirements and can in fact take advantage of the data classification that was done in conjunction with BC and DR planning. However, ILM requires a more granular view of data access requirements and associated storage, both from a media and timing (i.e., retention period) perspective.

ILM Fundamentals

Not the New Kid on the Block: ILM is not a new concept; businesses perform basic ILM-related tasks every day (and have been doing so for years) whether they are aware of this or not. ILM-related tasks include organizing, saving, using business data and determining how this data will be effectively and efficiently accessed over time.

What makes ILM different today than say even five years ago (Y2K comes to mind) is the fact that new corporate governmental requirements are dramatically expanding the time associated with the "usefulness" of this data. These regulations were instituted because of the gradual rise in importance of a communication medium that was initially not considered critical: e-mail. The recent abuse of e-mail (i.e., the unethical distribution of sensitive information) by a number of large corporations has forced the U.S. Government to institute information retention and tracking rules like the Sarbanes-Oxley regulations mentioned earlier.

Minimizing Compliance-Driven ILM Headaches: With Sarbanes Oxley regulations in the driver's seat, the difficulties associated with implementing a compliant ILM strategy are more apparent than ever before. Some of the complicating factors include:

* The reality that the government regulations are not "fully-baked." Only when the regulations have been put through the paces associated with real-world litigation will the full ramifications and impact truly be known.

* The fact that data resides in many different media--from laptops to enterprise storage infrastructures to vast archival centers--which further exacerbates the problems resulting from attempts to deliver effective and efficient access over long periods of time.

* The cost involved in retaining data for the required time periods since both infrastructure and personnel requirements must be considered.

That said, new techniques--and new twists to old techniques--are being developed to simplify ILM while reducing costs. Some of the more important developments include a greater focus on leveraging investments in the existing storage infrastructure (re-purposing hardware as newer technology is procured), utilizing "data profiling" to further understand how data is used and what data can be archived to secondary and tertiary storage media (going beyond the BC and DR classifications mentioned earlier; see Table 1), and, a technique whose intrinsic value has not been fully realized, standardization of data types in order to reduce the potential complexity of restoration infrastructures (like using XML as opposed to proprietary e-mail or database formats).

Potentially one of the most effective tools that can be implemented (and probably the one most overlooked) is an end-user education program. In order to adopt the rules that make information retention and tracking feasible, employees must understand and effectively utilize data tagging tools and mechanisms--and be held accountable for the information they exchange. So while a robust infrastructure is important, only through this partnership with the end users will true compliance be realized.

Classifying Data for ILM: The premise that all data is not created equal has already been established; customer data, for instance, is almost always critical to the viability of a corporation whereas e-mail generated by all but the top executives may not be. Creating a methodology to make these distinctions on a formal basis is the next step in developing an effective ILM strategy.

For instance, how is the value of the data determined? How does the value change with time and/or classification? Is the value taken into consideration with respect to where the data is physically stored? The answers lead to the ILM policies and the supporting data management methods, processes and procedures, and, finally, to the specific procurement requirements for effective management tools. Table 1 represents a data classification and data placement profile according to sample corporate priorities.

Guidelines to Developing an ILM Strategy to Meet Compliance Requirements

Data Availability and Management Audit: The relative maturity of the current environment may dictate the level of effort needed to achieve compliance. A determination of effort can be made by taking the following steps:

* Determine user interaction and success against the current policies, processes, procedures, and tools that are used to protect data.

* Highlight the challenges and document mitigation methods (unless the current environment is at extreme risk, delay changes until an ILM strategy is defined and consider and plan for how requirements associated with this strategy can help "fill in" potential data protection holes).

* Similarly, audit BC and DR plans and mechanisms, document current risks, and incorporate mitigation plans into the new ILM strategy.

Note that the ILM strategy seems to provide a centralization point for various critical data availability disciplines (i.e., BC and DR). In fact, ILM helps to improve these other disciplines but does not replace any of them.

When to Say "No": Mitigating Risk against Compliance and Expense: It was stated earlier that computing environment that require high levels of availability are already very expensive (keep in mind that expense doesn't automatically translate into higher availability). Adding ILM to the list of data management requirements can drive the infrastructure cost to levels that would bankrupt most companies. Therefore, a reasonable approach must be implemented that utilizes data classification and accessibility requirements (see Table 1) plus a methodology that can be utilized to perform a thorough business analysis (Table 2).

Efforts to "normalize" data formats are also getting more emphasis as a result of the costs associated with having to guarantee long-term access to data. The Extensible Markup Language (XML) has emerged as a de facto standard for exchanging information between disparate processes, applications, and data types. XML uses a "universal" text-based format that allows the original source and level of priority to remain associated with the data, provided these criteria have been defined, even when scheduled to be "vaulted" (Table 1). Although this method of normalizing the data in the form of text files does not represent the most efficient database structure, it does provide access and use without requiring the retention of the infrastructure (and resultant cost) that originally produced the data.

When it comes to government-driven compliance requirements, saying "No" is not an option. However, as described above, there are cost-effective ways to retain data, make it reasonably accessible, and ultimately usable.

ILM Development Methodology

Relative cost can only be determined based upon each corporation's business analysis. Using the ILM Development Methodology, this analysis can be conducted in six basic steps: Understanding ILM, ILM Business Require-ments *, ILM Impact *, ILM Planning, ILM Roll-out, and ILM Maintenance *.

By just reviewing the phases and sub-phases of the approach outlined below, it is clear that ILM is much broader in benefit, impact, and scope than what industry pundits might claim today. It also becomes fairly obvious that an ILM strategy is not based solely on an infrastructure solution alone (it is important to note that infrastructure isn't even considered until Phase 4, ILM Planning).

In essence, an ILM strategy must include the effort and time required to involve customers, suppliers, partners, and internal personnel, thereby incorporating requirements from any and all producers and consumers of information and the data that this information is based upon, in order to overcome the challenges of ILM.

The Planning Horizon: Thus far, this discussion has focused upon implementing ILM for data residing on an existing infrastructure. Clearly, as new and modified applications and corresponding data emerge, additional ILM requirements must be applied proactively.

Corporations typically use a combination of business, technical and operational criteria to help define requirements for a new application. These requirements may be formally captured in associated documents like Product Requirements Documents, Request For Proposals, or Change Request Documents, to name a few. Adding ILM requirements to these documents and sticking to existing planning timeframes helps to preserve the corporate culture. Representatives from the various corporate groups that get involved in requirements planning will now have a greater stake in the success of the new data management environment and are thereby encouraged to engage end users in the education process sooner.

Leveraging Customer Investments: Key to a successful ILM strategy implementation will be the ability to cause as little disruption to the current data protection schema and mechanisms in place as possible. This requires that current data protection processes (availability, backup, restore, etc.), procedures, and tool implementations be audited, as described above, but more importantly, that the workflow of the current environment be understood. ILM mechanisms should not, at a minimum, create or exacerbate single points of failure, but instead attempt to utilize existing infrastructure components to a greater extent.

For example, once data value is known, retention periods identified, and meta-data records kept, the next step is to place data according to these requirements. Access and availability requirements help to determine the rating that each storage media and device will be assigned. This begins to identify what may be called a "storage media cascade" that allows corporations to repurpose hardware according to its relative availability rating. This new classification then extends to how these various cascade groups and individual devices can be managed.

[ILLUSTRATION OMITTED]

Heterogeneous Management: Management of the integrated BC/DR/ILM environment requires an end-to-end approach and tools that will last as long as the data. Although it would be ideal to manage only one vendors' products, many computing environments are designed so that even the vendors selected are "redundant." That is, solutions that provide near-parity capabilities can be procured from two or more vendors. Given this, it becomes extremely important that BC/DR/ILM technologies and products, and their relative management, be selected based upon adherence to industry standards whenever possible. Exceptions to this are inevitable, of course, either because standards are not yet defined or the standard is not extensive enough to adhere to the availability requirements stipulated above. For example, it is counter-productive to implement a fully redundant BC solution if this redundancy doesn't extend to how it is managed.

Therefore, based upon "dual vendor" environments, heterogeneous management becomes a base requirement. For vendors that do not provide these types of end-to-end tools, a "manager of managers" approach must be employed. This type of management schema has been implemented by enterprise management vendors for many years based upon de-facto standards like the Simple Network Management Protocol (SNMP). Although standards from organizations like the Storage Network Industry Association (SNIA) are emerging, they have not yet incorporated U.S. Government compliance requirements into their published specifications.

As a last note, it was mentioned that a vendor's tools must "last as long as the data;" this has two connotations: the longevity of the technology itself and the viability of the vendor. When addressing the longevity of the technology, the product must have an effective backwards compatibility capability for each new release and a fairly far-reaching road map. The roadmap and revenue of course speaks to a vendor's plans for the future, both technically and financially, and forms the basis for the vendor's longevity.

Putting It All Together

Linking BC, DR and ILM for Faster Execution, Lower Costs: Time is the common link between BC, DR, and ILM disciplines: delivering 100% uptime, mitigating the risks associated with planned and unplanned downtime, and guaranteeing data access and usability over time, respectively. This continuum creates the perfect foundation for determining what is available today, what the next steps must be, and when they need to be taken.

Luckily, most corporations have invested significant amounts of time, resources, and capital into BC and DR strategies and implementations. Many corporations have extended their "business boundaries" to include their suppliers and consumers, ensuring that the entire supply-chain can sustain interruptions. All of this planning, as well as the investment in the existing infrastructure, can now be leveraged when adding ILM requirements, resulting in speedier execution at a lower cost. A look at the relationship between BC, DR and ILM is provided in Table 3.

Comparing BC, DR and ILM: Using the guidelines described above and Table 3 provides a starting point for corporations that want to begin the journey toward defining an integrated BC/DR/ILM strategy.

Summarizing the Layered Approach to Availability

The following summary provides a quick look at the steps that can be taken to leverage BC and DR planning in the development of an integrated ILM strategy designed to achieve compliance with emerging government regulations.

Data Classification: From BC and DR policies, note statements that indicate "this application and data is very important, important, not as important ..."

User Interaction: Retention and retention procedures and tools are hidden from your users (applies to corporate data); retention and retention procedures and tools are not hidden from your users because they must decide how important their data is and how quickly they need to access it (applies to new government regulations).

Infrastructure: When already invested in BC and DR infrastructures, leverage it by first analyzing the holes between availability, accessibility, and compliance.

Data Linkages: Make certain that the DR strategy can also support ILM compliance requirements (extend and expand "data labeling" techniques from BC and DR to ILM).

Supply Chain Considerations: If the BC and DR scope includes business suppliers and consumers, include them in the ILM strategy development as well.

Vendor Compliance: Government regulations apply to all businesses in the U.S. Are your vendors compliant? Do they have applicable certifications or are they members of industry associations involved in the creation of ILM standards? (i.e., how much skin have they got in the game?)

Additional Considerations:

Auditing: Conduct independent audits

Testing: Integrate the testing process to span all three disciplines (BC/DR/ILM)

Expertise: ILM is still nascent (is any consultant today truly an expert?)

Tools: What you need today may not be available

Mitigating Risk: Treat this as the Y2K of the mid-2000s; form corporate user groups to better define your requirements within and in support of your specific industry

Changing the corporate culture: Educate all of your users that this is inevitable

Implementation: It is not "all or nothing;" you can implement an ILM strategy in phases as long as you keep one important consideration in mind: anything you do must be government compliant

A Final Word on implementing an ILM Strategy

While true that government compliance regulations are still emerging, make no mistake: waiting to implement your strategy is okay, waiting to plan it could be disastrous.

Table 1: Data classification example

Priority      Category         Sub-Category    Cached  Online  Nearline

   1       Business Value    Customer            *       *        *
                             Applications &
                             Data

                             Customer Support    *       *        *
                             Applications &
                             Data

                             Operations                  *        *
                             Applications &
                             Data

                             Legal                                *
                             Applications &
                             Data

                             Internal                    *        *
                             Applications &
                             Data

   2      Access Frequently  Daily               *       *        *

                             Monthly                              *

                             Periodically
                             within or at
                             yearly intervals

                             Longer than 1
                             year

   3         Cost & Risk     Utilize current     *       *
                             infrastructure
                             (leverage
                             investment in
                             HW/SW/
                             personnel;risk
                             is over-taxing
                             resources)

                             Outsourced                  *
                             infrastructure
                             (includes
                             over-taxing and
                             access security
                             risks)

                             Shared                      *
                             Responsibility
                             (supply chain
                             partners; same
                             risks as above)

   4      Retention Period/  Daily               *       *        *
          Compliance Policy

                             Monthly                     *        *

                             Periodically
                             within or at
                             yearly intervals

                             1,3,5, ... year
                             increments

Priority      Category       Nearline  Offline   Offline
                             Archived  Archived  Vaulted

   1       Business Value       *         *         *

                                *         *         *

                                *         *

                                *         *         *

                                *         *         *

   2      Access Frequently     *

                                *         *         *

                                *         *         *

                                                    *

   3         Cost & Risk                            *

                                                    *

                                                    *
   4      Retention Period/     *
          Compliance Policy


                                *                   *

                                *         *         *

                                          *         *

Table 2: ILM development methodology

    Phased Approach      Phase Sub-task            Requirements

                      --Your definition     --"Own" your definition
1  Understanding ILM  --Your customer's     --Establish level of
                        definition            importance
                      --Your industry's     --Create differentiation
                        definition

                      --Determine how you   --CRM, ERP, Customer
                        use data              Service, etc.
2    ILM Business     --Classifying data    --Critical, Important, etc.
     Requirements       value               --Establish ROI
                      --Capture formal
                        requirements

                      --Executive buy-in    --"Own" the vision
3     ILM Impact      --ILM Champions       --"Own" the mission
                      --Corporate culture   --Permeates daily
                                              operations

                      --Internal/External   --Marketing/PR, processes,
                        preparation           infrastructure
4    ILM Planning     --Partners and        --Data suppliers/consumers
                        consultants         --Address government and
                      --Project plans         industry deadlines

                      --Pilots and          --Critical operations and
                        evaluations           high R0I
5    ILM Roll-out     --Create metrics of   --Set realistic
                        success               expectations
                      --Phased roll-out     --Start small (non-critical
                                              data)

                      --Develop processes   --Refinement
                        and procedures      --Dedicated and timely
6   ILM Maintenance   --Metric gathering    --"Spread the word!"
                        and reporting
                      --Business unit and
                        executive
                        evaluations

    Phased Approach          Critical Dependencies

                              Must apply to You
1  Understanding ILM          Must apply to Them
                               Don't lose focus

2    ILM Business          Input/Output, timeframes
     Requirements          What if it isn't there?
                           Must fit into the culture

                             Make this very visible
3     ILM Impact      Make this a rotating responsibility
                               Use "dashboards"

                          Many touch points/resources
4    ILM Planning             "Skin in the Game"
                              Driving or driven?

                           Go/No Go, non-production
                                 environments
5    ILM Roll-out         All metrics must have ROI
                           Be nimble, expect issues

                           Shouldn't be "brand new"
6   ILM Maintenance      Reflect reality, not fantasy
                               Always reinforce

Table 3: Comparing BC, DR and ILM

                        BC                            DR
    Driver        Characteristics               Characteristics

 Availability   No downtime                    Prescribed

    Access      Defined, secure                Defined, secured

  Economics     High cost                      Med-to-high cost

     Risk       Risk mitigated                 Risk mitigated

    Value       Defined                        Defined

  Retention     Audits required                Audits required

Infrastructure  End-to-end redundancy          Most critical
                                               applications and data,
                                               then acquisition plans

  Government    HIPAA and SEC requirements     HIPAA and SEC
 Regulations                                   requirements

   Reports      Internal, real-time            Internal, near
                                               real-time, post DR

   Testing      Testing of each component      Simulated DR failovers
                must be executed during        conducted periodically
                off-time                       (quarterly)

    Audits      Non-disruptive review of       Non-disruptive review
                policies, processes,           of policies, processes,
                procedures, reporting          procedures, reporting

     ROI        Survey customer and customer   Survey customer and
                support organizations on       customer support
                relative impact versus         organizations on
                availability; break-even and   relative impact versus
                productivity analysis          availability;
                required                       break-even and
                                               productivity analysis
                                               required
                       ILM
    Driver        Characteristics          How they relate ...

 Availability   Combination              Dependent on data valuation

    Access      Not well defined         May require security policy
                                         modifications

  Economics     Cost today is high       Requires analysis and tools

     Risk       Not well defined         Requires government standards

    Value       Not well defined         BC and DR provide basis for
                                         value; government requirements
                                         and education needed

  Retention     New policies required    Modifications of current
                                         policies may be needed; minimum
                                         of meta-data overlay to
                                         identify data location

Infrastructure  First generation data    Leverage investment with little
                tagging will be manual,  modifications of current
                next gen use XML?        implementation; use XML data
                                         types to comply

  Government    Add retention and data   Privacy and financial reporting
 Regulations    tagging                  information sensitivity must be
                                         taken into account for new
                                         policies

   Reports      Roll-up reports on data  Meta-data reports must be
                location with brief      generated on an ad-hoc basis
                description

   Testing      Should be included as    Critical testing for ILM: meta
                part of both BC and DR   data reporting data location,
                testing                  physical storage cascade
                                         testing

    Audits      Non-disruptive review    Audits are driven by corporate
                of policies, process,    policies; these policies must
                procedures, reporting    be kept up to date re what is
                                         business critical

     ROI        Leverage BC and DR       ROI will ultimately be driven
                investments; break-even  by revenue, cost and profit
                versus risk analysis     analysis and comparisons;
                for non-compliance       "best-in-class" implementations
                required                 gain intangible benefit from
                                         good PR (could become
                                         competitive differentiation)

www.sun.com

[* These are the most critical steps toward mitigating the risk associated with overspending. Requirements establish what data sets are the most critical (classification); Impact scopes the problem in terms of "what if" scenarios (access, options, cause and effect), and Maintenance mechanisms enforce the priorities that were initially established over prescribed retention timeframes.]

Adam Mendoza is director of strategic alliances for data services at Sun Microsystems Inc.--Network Storage (Santa Clara, CA)