Data and Media Center of Excellence

team lib

There are three high-level layers of the data and media COE: conceptual (policy), physical (infrastructure), and operations (operational). Each of these three is a superset comprised of multiple functional and subfunctional elements. Each of the functions within each category and associated job titles (suggested) are detailed as follows and serve as a guideline for functional and organizational structure.

It is also important to note that, although many of these functional categories exist in the mainframe environment, simply having mainframe personnel responsible for all systems is not necessarily appropriate. There must be a balance of people, processes, and technology to create an effective COE, and the technologies are often quite different between mainframe and non-mainframe environments. Nonetheless, COEs should be viewed holistically and include the following.

Policy

Policies offer the highest-level view of storage management, dictate the required infrastructure to meet policy mandates , and should be governed by a storage policy director (SPD). These policies, which are interdependent and should be viewed holistically, include the following:

  • Service portfolios and service-level agreements SPDs should determine what service packages they will offer to business units, as well as the associated cost/service tradeoffs, based on the needs of the business units.

  • Data protection strategies Not all data is created equal, and the data protection mechanisms should be aligned with the service portfolio.

  • Vendor selection strategies ITOs should determine, as a matter of policy, whether to pursue a best-of-breed multivendor strategy (albeit rationalized and not a vendor du jour strategy), or a one throat to choke single-vendor strategy. This will vary from one category to another, but should be done with an eye toward strategic objectives, which are not always mutually exclusive. Either way, rigorous interoperability mandates should be a prerequisite for consideration to enable maximum deployment flexibility.

Infrastructure

After the overall storage policies have been determined, a storage infrastructure architect should be responsible for designing and implementing the components needed to achieve the service goals. This will include device and network management (at the functional level) as well as a multitude of subfunctions, including the following:

  • Physical topology design In most organizations, it will be necessary to use and integrate SAN, NAS, and direct-attached storage either for optimum performance or for security requirements and data protection. The ability of vendors to not only function/coexist, but also support (via customer and professional services expertise) these advanced heterogeneous environments (multiprotocol, multivendor, multifunction , cross-organizational, and cross- regional) will determine the most appropriate platforms (both hardware and software) on which to base infrastructure for the flexibility to adapt, as subelements of technology evolve over time.

  • Performance modeling and monitoring The storage infrastructure architect should be responsible for not only designing sufficient resources, but also for ensuring that service levels are met. This includes storage components (for example, disk arrays) as well as storage networks (such as FC fabrics ) and working with IP networking personnel, in the case of NAS.

  • Security Security is an underaddressed area in storage management, due mostly to the current lack of capability, but should be made the responsibility of the storage infrastructure architect working in conjunction with the enterprise security architect.

Other subfunctional tasks may include physical subsystem and tape library design, fault and performance management, virtualization, SAN management, and enterprise planning/design/procurement.

Operations

Operational procedures will not vary greatly from current practices, but should be managed by dedicated storage administrators. Functionally, traditional systems management should remain within the systems management group , and the key is to begin separating the storage operations from systems, database, and application management. To what degree will certainly be dependent on each organization, but the three main functional disciplines are:

  • Performance management This consists of performance modeling and management (including FC-based networks), asset management, chargeback , and billing by application of business unit.

  • Resource management This involves resource allocation or provisioningthe actual assignment of storage (for example, LUNs, data zones, volumes ) according to architectural/application requirements, as well as quota management, usage management (for instance, by application or individual user ), metering, and capacity planning.

  • Availability management This deals with backup/recovery operations. Backup/recovery should be included with storage management, not systems management. This includes backup/recovery scheduling, media management, and problem resolution. High-availability server clustering management (in conjunction with systems management), hierarchical storage management (where applicable ), and replication (for example, remote replication for business continuity) are also of consideration.

Similar to balancing the handoffs with enterprise architects , infrastructure, operations, and lines of business, the data and media COE is no different. As can be seen, some of the functions and subfunctions transcend the policy, infrastructure, and operations categories. Communication among groups is a key element for a successful storage infrastructure that is adaptable to change and is measurable.

 
team lib


Storage Networks
Storage Networks: The Complete Reference
ISBN: 0072224762
EAN: 2147483647
Year: 2003
Pages: 192

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net