A contingency plan is an outline of procedures to follow in case of a major event, such as a server crash or building fire. A contingency plan is a written way of saying, that should a problem arise, you have thought of ways to prevent the loss of vital information or reduce the impact to your business. Many quality driven organizations and companies have contingency plans not only for individual systems, but for whole departments.
- Start by setting up a contingency planning committee and chose an individual who will lead this committee. The contingency plan leader provides skills, tools and a knowledge base so that each department can write its own plan.
- List every business process in each department. For example, the payroll department might be listed under the Human Resource department’s plan.
- Sit down with department leads or senior level employees and make a list of all key assumptions in your contingency plan.
- Prioritize each assumption in order and examine the what-ifs and negative impact these assumptions could have on your company. Examine what trends, events or problems that could potentially arise.
- List what you plan to do in the event that something negative does occur. How will you compensate or adjust to these problems and keep your business profitable?
- Structure your contingency plan in a positive manner. Writing your plan is a big task so involve the right amount of people and all the appropriate people because it will require the input of many.
- Go over the plan again. A second review helps find things that were missed the first time.
- You will be able to create contingencies at the proper places once you’ve gone over business functions this way. Sometimes the contingency will be at the department level, many will be at the task level and others might be at the process level.
8. Test your contingency plan. You can make testing manageable and cost-effective by testing in 4 stages. If an area proves to be flawed or conflicts with contingency plans from other departments, you can edit and the retest the plan.
- Test Stage 1-Senior Staff Review. The senior staff chooses an internally public date and time to go over all contingency plans and recognize the people who thoroughly completed their assignment.
- Test Stage 2-Interdepartmental Review. This is where every department reviews another department’s plans. This is the stage that allocates resources and identifies conflicts.
- Test Stage 3-Failures of Critical Systems. This testing stage can be localized within departments. Testing involves the simulation of system and/or vendor failures. You can role play scenarios without having to actually shut down important equipment or processes.
- Test Stage 4-The Real Deal. Here is where you get to fully test out the contingency plan. It involves short-term shutdowns in key areas done in real time.
A Business Continuity Plan (BCP) is the least expensive insurance any company can have (especially for small companies, as it costs virtually nothing to produce). It details how employees will stay in touch and keep doing their jobs in the event of a disaster or emergency, such as a fire at the office. Unfortunately, many companies never take the time to develop such a plan.
Here you will see suggested steps and considerations, in an abbreviated way, for small companies to create a BCP that will improve their chances of continuing operations during or after significant disasters. Development of a BCP for larger companies is not within the scope of this document.
Business Continuity Plans are sometimes referred to as Disaster Recovery Plans (DRP) and the two have much in common. However a DRP should be oriented towards recovering after a disaster whereas a BCP shows how to continue doing business until recovery is accomplished. Both are very important and are often combined into a single document for convenience.
1. Document internal key personnel and backups. These are people who fill positions without which your business absolutely cannot function – make the list as large as necessary but as small as possible.
- Consider which job functions are critically necessary, every day. Think about who fills those positions when the primary job-holder is on vacation.
- Make a list of all those individuals with all contact information including business phone, home phone, cell phone, pager, business email, personal email, and any other possible way of contacting them in an emergency situation where normal communications might be unavailable.
2. Identify who can telecommute. Some people in your company might be perfectly capable of conducting business from a home office. Find out who can and who cannot.
- You might consider assuring that your critical staff (identified in Step 1) can all telecommute if necessary.
3. Document external contacts. If you have critical vendors or contractors, build a special contact list that includes a description of the company (or individual) and any other absolutely critical information about them including key personnel contact information.
- Include in your list people like attorneys, bankers, IT consultants…anyone that you might need to call to assist with various operational issues.
- Don’t forget utility companies, municipal and community offices (police, fire, water, hospitals) and the post office!
4. Document critical equipment. Personal computers often contain critical information (you do have off-site backups, don’t you?).
- Some businesses cannot function even for a few hours without a fax machine. Do you rely heavily on your copy machine? Do you have special printers you absolutely must have?
- Don’t forget software – that would often be considered critical equipment especially if it is specialized software or if it cannot be replaced.
5. Identify critical documents. Articles of incorporation and other legal papers, utility bills, banking information, critical HR documents, building lease papers, tax returns…you need to have everything available that would be necessary to start your business over again.
- Remember, you might be dealing with a total facility loss. Would you know when to pay the loan on your company vehicles? To whom do you send payment for your email services?
6. Identify contingency equipment options. If your company uses trucks, and it is possible the trucks might be damaged in a building fire, where would you rent trucks? Where would you rent computers? Can you use a business service outlet for copies, fax, printing, and other critical functions?
7. Identify your contingency location. This is the place you will conduct business while your primary offices are unavailable.
- It could be a hotel – many of them have very well-equipped business facilities you can use. It might be one of your contractors’ offices, or your attorney’s office.
- Perhaps telecommuting for everyone is a viable option.
- If you do have an identified temporary location, include a map in your BCP. Wherever it is, make sure you have all the appropriate contact information (including people’s names).
8. Make a “How-to”. It should include step-by-step instructions on what to do, who should do it, and how.
- List each responsibility and write down the name of the person assigned to it. Also, do the reverse: For each person, list the responsibilities. That way, if you want to know who is supposed to call the insurance company, you can look up “Insurance.” And if you want to know what Joe Doe is doing, you can look under “Joe” for that information.
9. Put the information together! A BCP is useless if all the information is scattered about in different places. A BCP is a reference document – it should all be kept together in something like a 3-ring binder.
- Make plenty of copies and give one to each of your key personnel.
- Keep several extra copies at an off-site location, at home and/or in a safety-deposit box.
10. Communicate. Make sure everyone in your company knows the BCP.
- Hold mandatory training classes for each and every employee whether they are on the critical list or not. You do not want your non-critical staff driving through an ice storm to get to a building that has been damaged by fire then wondering what to do next.
11. Test the plan! You’ve put really good ideas down, accumulated all your information, identified contingency locations, listed your personnel, contacts and service companies, but can you pull it off?
- Pick a day and let everyone know what’s going to happen (including your customers, contractors and vendors); then on that morning, act as though your office building has been destroyed. Make the calls – go to the contingency site.
- One thing you will definitely learn in the test is that you haven’t gotten it all just exactly right. Don’t wait until disaster strikes to figure out what you should do differently next time. Run the test.
- If you make any major changes, run it again a few months later. Even after you have a solid plan, you should test it annually.
12. Plan to change the plan. No matter how good your plan is, and no matter how smoothly your test runs, it is likely there will be events outside your plan. The hotel you plan to use for your contingency site is hosting a huge convention. You can’t get into the bank because the disaster happened on a banking holiday. The power is out in your house. The copy machine at the business services company is broken. Your IT consultant is on vacation.
- Review and revise. Every time something changes, update all copies of your BCP.
In this blog post I’ll try to cover a new aspect of the vCloud Director for a change into the design journey of a private cloud and how all its pieces come together. It’s going to be very hard to cover every detail in this post, so I will try to focus on the main areas and group them into small sections for easier follow up.
A Holistic Diagram
When it comes to an architecture design, you must have a diagram! In this one I’m mixing between logical and physical layouts. The former being around storage, and the latter will be focused on servers. The reason why I didn’t go with a complete physical design was to reduce the complexity of the diagram. I know that i should be vendor neutral here, but i thought that i need to be as much practical and realistic as possible (specifically in this design subject) for you to follow up easily. Choosing Cisco UCS was just a random selection. I happened to show IBM some love in my previous vSphere design posts, so i thought i would do the same for Cisco this time. Enough said?
If you have already read my previous blog posts on designing vSphere on blades, this part won’t look very different to you. We will follow here nearly the same concept and divide our clusters into one Management cluster and two resource clusters. Let’s take a closer look:
- Management Pod: We will run here all our management and monitoring elements of our private cloud. The cluster consists of 4 blades spanned across two chassis for redundancy.
- Resource Pod: We have here two clusters forming our resources:
- Gold Cluster: We are dedicating here one cluster for this hardware pool. In this cluster we have 12 blades spanned across three chassis with a maximum of 4 blades per each chassis. This will allow us to achieve the maximum high-availability, and also avoid having all our 5 primary HA nodes on a single chassis in case of any unlikely hardware failure.
- Silver & Bronze Cluster: We are having here one cluster on this hardware pool, but we will slice it down into two resource pools. Each RP can be configured as per each customers’ requirement. We will name these two clusters “Silver” and “Bronze”.
The Management Pod
As mentioned earlier, in this cluster we will run all our management and monitoring elements of the cloud. Here are a list of the VMs:
- vCD Cells: It is highly recommended to use at least two cells in your cloud environment to avoid the single point of failures. It’s worth mentioning also that there is no licenses restrictions as to how many cells you have to run.
- Load Balancer: This is typically a physical box sitting outside your virtual/cloud environment (like F5 appliances) but it could be a virtual appliance as well. At the time of writing these lines, there is no special recommendations for the LBs to be used with vCD. In fact, a simple DNS round robin could do the trick to distribute the load across your cells.
- vSM: This is the vShield Manager virtual appliance. I would recommend here to run this VM in FT. From one hand, it will run perfectly well with 1vCPU and it won’t consume any cpu resources from your cluster, and from the other hand you will ensure that you have the required redundancy for this important cloud element.
- The Oracle DB: This is the backend database for our entire private cloud. It’s vital that you have a highly redundant setup for the Oracle database like a RAC setup for example. Your DB admins are typically the ones that will be concerned about this component and they should be the ones designing it. You have to know however what are the databases that will be hosted in this cluster, which can be summarized as follows:
- vCenter Server DB: as per our existing setup, we have to vCenter Servers, consequently we will have two vC databases.
- vCenter UpdateManager DB: same thing holds true here. We will need to vCenter UM databases.
- vCloud Director DB: this is the most critical part of the cloud environment, not just because we store all out cloud related information there, but also for the fact that the DB plays a major role in the cluster heart beating of the Cells (more on this subject in a future blog post).
- vCenter Chargeback: this is the DB that handles all our billing.
- vCenter Servers: As you see in the diagram above, we have two vCenter servers. The first one will be managing the management cluster itself, and the second one will be managing the resource clusters. I haven’t included in the diagram the vCenter Heartbeat product although it would be highly recommended here. You can still leverage the native VMware High-Availability to protect your vCenter VMs, and also enable the VM monitoring to reboot the VM in case of OS crashes. It all boils down to what level of protection and HA you want to ensure in your cloud.
- vCenter Chargeback Servers: Here we have the Chargeback servers. I will talk in details about this subject in a complete blog post very soon.
- NFS Share: You will need the NFS share to store the response files for the cells and also it would be a good practice to store your vCD bits along with the other required software for the cells. Eg. RPMs and dependencies.
We will use here three different types of virtual switches. The first one will be the vNetwork Standard Switch (vSS) and it will be dedicated to the vSphere environment. I personally prefer to use the vSS with MGMT, vMotion & FT networks to avoid the dependencies on vCenter Server. I’ve talked about this point previously in my vSphere design blog posts so you can have a look on them for more info.
The vSphere Networking
As you see in the diagram above, we are using here a typical design for our vNetwork Standard Switch. An Active/Passive configuration for all the three networks, the SC/MGT, vMotion and FT. Each network is active on a dedicated NIC, and standby on another one.
The Cloud Networking
We will use in our cloud networking the vNetwork Distributed Switch (vDS). You can still use the vSS (or Nexus 1000V) in your design here, but please note that this will limit your functionality. With vSS and N1KV you won’t be able to use both the vCloud Network Isolation and VLAN-baked Network Pools. This might be bearable in small to midsized private clouds where your network provisioning will grow slowly and gradually, but in case of large enterprises or service providers (public cloud space) the vDS should be the way to go in order to support the fully automated network provisioning.
In the diagram above, we have here one dedicated vDS for our network pools. All what you need to do is to create one vDS in vSphere and allocate it to your Network Pool inside the vCloud Director resources. Everything will be provisioned automatically by vDC later on whenever you create a new Organization Network and/or vApp Network. You will keep seeing these cryptic dvs.VC### port groups added on the fly as you provision more and more of your cloud networks. Obviously, you will never have to worry about them from a vSphere perspective as all the administration will always be done from your vCD portal.
In the diagram above, we have another vDS for our External Networks. These networks have to be pre-provisioned by the vSphere admin before using/consuming them in vDC. An example for that would be an Internet connection for your organizations. You basically create a new network in vSphere and hook it up with your internet backbone. Another example would be a network hooked up with a VPN tunnel to a different branch/company/partner.
Please note that you can still use one vDS for both the Network Pools and External Networks, but I would recommend separating them for easier management.
Provider Virtual Datacenter
Our Provider vDCs design will be fairly easy. I’m using two examples here to show you how you can map your vSphere clusters to vCloud Director. In the first example, the Gold vDC, we have a 1:1 mapping with the “Gold Cluster” that we created earlier in vSphere. All the resources of this cluster will be “dedicated” to that Gold Provider vDC. In the second example we have one cluster (which contains 4 high-end blades) sliced down into two resource pools. We are then carving out of these two RPs another two Provider vDCs. We will call the first one a “Silver” PvDC, and the second one “Bronze” PvDC.
Although the general recommendation of the server virtual environments is to use the scale out approach (illustrated in the Gold Cluster), there are some customers I’ve seen who prefer the scale-up approach and use high-end monster servers for that. I’m not going to go into the religious war between the two options, it all comes down to customer requirements and design choices. I just need to point out that the resource pools will make much sense in the case of high-end servers because they normally have large compute power (CPU & MEM) that you would need to utilize more efficiently.
Organization Virtual Datacenters
Now that we’ve explained the simple creation of Provider vDCs, it’s time to have a look into the Organization vDCs. The concept here is somehow similar, however, we have what we call “Allocation Models” when we carve out the resources from the PvDCs to Org-vDCs. Let’s have a closer look.
In the “Gold Org vDC” we are using the “Reservation Pool” to reserve/dedicate the compute resources down from the Gold Provider vDC. I’m showing here another 1:1 mapping although you can obviously use the same Gold vDC to allocate down more resources to another Org-vDC. In this example you can think of a very high SLA requirement and security to one of your BUs or departments where you need dedicate all the resources to it. In my case here all these resources are consumed down by the IT Operations department (or “Organization” as we will call it later).
In the second example, the Silver Org-vDC, we are using a second allocation model – the “Allocation Pool”. In this allocation model we are committing only a “percentage” of the resources available in the Provider vDC. Same thing is happening in the second “Staging” Org-vDC. We are committing another percentage of the Silver PvDC and so forth.
In the third and last example, we are using the “Pay-as-you-go” allocation model. The resources are committed here only when you create the vApps. It makes much sense to use it in case of development environment where vApps are created and used for a period of time without much SLA to guarantee.
Last but not least in our cloud environments we have the Organizations. It’s a bit hard to explain this part as it’s quite variant how enterprises do their internal IT (remember, we are exploring here the private cloud). With that said, I’ll use a very simple scenario to keep things as much clear and less complex as possible.
We are having here two Organizations, the IT Ops and IT Dev. The former will act as our operations department that is responsible about the various services in IT, and the latter will be the one providing the internal development in terms of vApps. For various and detailed networking scenarios of the vApp and Organization networks and how they all interact together and relate down to the vSphere networking, you can checkout my diagram here.
There is one part probably missing in the diagram which is the Catalogs. Massimo Re Ferre’ has written a beautiful article on this subject you should check it out for thorough understanding about Catalogs. In our case here we can have two catalogs published by each Org. The first one will be from the IT Ops for the general purpose vApps/ISOs deployed by the whole enterprise, and the second one will be from the IT Dev for the specific internal Apps development (e.g. a SharePoint Intranet/Website or a custom HR application..etc).
In thispart blog post we went through a simple design for a Private Cloud using VMware vCloud Director. It is impossible to show all the capabilities or the design scenarios for this incredibly powerful product, but hopefully you had an idea on the basic building blocks for starting your own deployment. If there is anything major you think that I missed in this article, please drop a comment or an email and I will cover it in future posts.
Source – http://www.hypervizor.com/
COBIT (Control Objectives for Information and Related Technology)
COBIT stands for Control Objectives for Information and Related Technology and is the internationally recognized manual for IT Governance, i.e. for guaranteeing security, quality and compliance in information technology. In this context COBIT does not primarily define how the requirements are to be met but instead concentrates mainly on what has to be implemented.
COBIT was originally developed (1993) by the international Information Systems Audit and Control Association, ISACA. Since the year 2000 the development and updating of COBIT has been the responsibility of the IT Governance Institute, a sister organization of the ISACA. Over the years COBIT has developed from being a tool for IT auditors into a tool for the control of IT from the corporate viewpoint and, amongst other things, is also used as a model for ensuring compliance with statutory requirements. This generally promotes the industrialization of IT.
COBIT was created very much along the lines of the COSO (Committee of Sponsoring Organizations of Tradeway Commission) the framework for internal controls designed to ensure the integration of IT governance within the corporate governance. In this context COBIT is intended to be the link between the control frameworks throughout the company (COSO) and the IT-specific models (e.g. ITIL, ISO17799/27002 etc.). Evidence that COBIT meets this requirement is demonstrated by the fact that COBIT is widely used internationally as a control model by most large companies. It is the premise of ISACA that 95 % of major companies utilize COBIT in whole or in part.
COBIT provides good practices in the form of a domain and process framework and entails activities in a structure which is both logical and easy to use. The good practices contained within COBIT incorporate the views of various experts whose focus is clearly more control than implementation-based. These practices lend support for improving capital investment within the IT environment and ensure service delivery as well as an assessment benchmark in the event of irregularities occurring.
To enable IT to successfully fulfill the business requirements, an internal system of monitoring/controls or an internal framework should be implemented by the management. The COBIT framework provides a help in this context through
- a link with the business requirements,
- the incorporation of IT-related activities into a generally accepted process model,
- the identification of key IT resources to be controlled and
- the definition of the control objectives to be taken into account.
COBIT’s orientation towards the core business consists of a link between corporate objectives and IT objectives, the provision of measurement parameters and maturity models for measuring target attainment and includes identification of the relevant responsibilities both in the technical area and IT.
COBIT’s process orientation is demonstrated by the process model which organizes the IT into 34 processes, subdivided into planning, development, operation and monitoring, establishing an integrated view of the IT. In this context, company-wide architecture models help to identify the key resources for the success of the processes such as e.g. applications, information, infrastructure and personnel.
What is IT Governance?
The ability to meet all business and regulatory requirements at all times requires an integrated management system coordinated throughout all parts of the enterprise. These management principles are also called governance. Corporate governance ensures that fair and transparent bases for decision-making and responsibilities apply throughout the company.
IT governance is one part of this and on the management level includes the responsibilities in respect of management, organizational structure and processes for implementing the corporate strategy via the IT and achieving or even exceeding the targets. Today, various frameworks, models, standard and quality systems are available on the market to facilitate the monitoring and fulfillment of these governance and compliance requirements.
The main objective of IT governance is to understand the requirements of the IT as well as IT’s strategic importance from the viewpoint of the core and management processes in the company in order to ensure that the business operates to optimum effect so as to achieve the corporate objectives and create strategies for the future expansion of the business operation. The purpose of IT governance is to ensure that the expectations demanded of the IT are known and that the IT is also in a position to fulfill these expectations. In this context any potential risks must be reduced. In this sense it would be more accurate to talk about enterprise governance over IT than about IT governance as IT governance does not take place within but outside the IT organization.
The IT Governance essentially creates a balance between two areas:
- the creation of corporate value
- minimizing IT risks
The aims of IT governance are defined by analysts as follows:
- Strategic orientation, focusing on corporate solutions.
- Creation of benefits, focusing on optimizing the tasks and assessing the benefit of the IT.
- Risk management which relates to the protection of the IT assets taking account of disaster recovery and continuation of the corporate processes in the event of a crisis.
- Resource management, optimization of knowledge and infrastructure.
- Performance measurement and consequently the creation of the bases for continual improvement.
The COBIT approach to controlling must essentially be applied on a top-down basis. Corporate objectives form the basis for the definition of IT objectives which in turn influence the IT architecture. In this respect, IT processes which are suitably defined and operated, ensure that information is processed, IT resources managed (personnel, technology, data, applications) and services delivered. Measurement and target parameters are defined respectively for these levels (company-wide basis, IT, process and activities) for the purpose of assessing the results and performance drivers. Target attainment is measured on a bottom-up basis, producing a defined control cycle.
Why a Control Framework?
The demand for an IT governance control framework is increasing all the time. The key influence of information on business success is being recognized increasingly and clearly by the management which is demanding a greater understanding of how the information technology (IT) is being operated and of the potential for using IT to achieve competitive advantages. The company’s governing boards want to know whether information is being managed by the organization in such a way that it can ensure the following:
- Attainment of the targets.
- Ability and flexibility to learn and change.
- Sensible approach to the relevant risks.
- Identification and exploitation of opportunities.
Successful businesses understand the risks, realize the benefits of IT and find a way of
- adapting the IT strategy to the corporate strategy,
- breaking down the IT strategy and targets in the organization,
- establishing organizational structures which enable strategy and objectives to be implemented and achieved,
- pursuing constructive relationships and communication between core business, IT and external partners and
- measuring the performance of IT.
Without the use and implementation of a governance and control framework for the IT, companies cannot effectively fulfill the corporate and governance requirements in order to
- align them with the corporate requirements,
- create transparency of performance in meeting the requirements,
- organizing the activities into a generally accepted process model,
- identifying and effectively utilizing the key resources,
- defining the management control objectives to be pursued.
In addition, governance and control frameworks develop into best practices in the IT management and are a supporting factor in the creation of IT governance and achieving compliance against the background of an ever growing number of regulations.
Best practices in IT are increasingly being followed for various reasons:
- Managers of core business processes and members of controlling committees are demanding an improved return.
- For capital investment in IT, for example by IT having to deliver services which increase value for the stakeholders.
- Uncertainties associated with increasing expenditure for IT.
- The demand from regulatory requirements with regard to IT controls in the area of privacy or financial reporting (e.g. Sarbanes-Oxley Act, Basel II) or in specialized areas such as pharmaceuticals, lending or healthcare.
- The choice of service providers and the management of outsourcing and procurement.
- Increasing complexity of risks associated with IT, such as network security.
- Initiatives in the area of IT governance which provide support for the application of control frameworks and best practices. These provide for the monitoring of and improvement in critical activities for IT in order to increase the contribution to value and reduce business risks.
- The demand for cost optimization by the fact that an increasing number of standardized approaches are being pursued and increasingly fewer developed for specific purposes.
- The increasing level of maturity and subsequent acceptance of recognized frameworks such as COBIT, ITIL, ISO 17799, ISO 9001, CMM and PRINCE2.
- The need to measure the company’s own performance against similar companies and generally accepted standards (benchmarking).
Orientation towards the company is the main theme of COBIT as COBIT was not just created to be read by IT service providers, users and auditors but also – or more specially – as a comprehensive instruction for management and personnel responsible for processes in the core business.
The COBIT framework is based on the following principle: in order to supply the information which is required to achieve the corporate objectives the company must manage and control the IT resources using a structured number of processes that guarantee the delivery of corresponding services.
The COBIT framework supplies support tools for orientation towards the needs of the company. In this context, information criteria, resources and processes are the central components in the COBIT framework.
In order to achieve the corporate objectives the information must reflect specific criteria which is described in COBIT as requirements for information specific to the individual company. Seven individual, partially overlapping information criteria for the broader security requirements from the quality and fiduciary aspects were defined as follows:
- Effectiveness deals with the relevance and suitability of information for the business process as well as its appropriate provision in terms of time, accuracy, consistency and usability.
- Efficiency deals with the supply of information through the optimum (most productive and most efficient) use of resources.
- Confidentiality deals with the protection of sensitive information against unauthorized disclosure.
- Integrity relates to the accuracy and completeness of information as well as its validity in accordance with corporate values and expectations.
- Availability relates to the fact that information is available for the business process now and in the future. It also applies to the protection for necessary resources and their services.
- Compliance deals with the adherence to laws, regulations and contractual agreements which the business process has to take into account, such as e.g. externally imposed criteria or internal guidelines.
- Reliability relates to the appropriate nature of supplied information which is used by the management in order to steer the company and enable it to meet its obligations with regard to good faith and governance.
Corporate objectives and IT objectives
Whilst the information criteria represents a generic method for defining the information requirement, the generic corporate and IT objectives defined in COBIT provide a more specific basis for defining the corporate requirements and in order to develop metrics which enable the fulfillment of these objectives to be measured. Every company utilizes information technology to support business projects; these can be seen as corporate objectives for the IT.
If IT intends to deliver successful services in order to support the corporate strategy then clear responsibilities and standards should be set by the core business (the client) with regard to the requirements, as well as a clear understanding of the demand (WHAT and HOW) to be covered by the IT (the service provider).
These targets should in turn lead to clearly defined targets for the IT itself (IT objectives) which once again in turn define the IT resources and their services (corporate architecture for IT) which are required for successful performance of the tasks derived from the strategy. These objectives should all be expressed in a language which is understood by the client.
Once the aligned objectives have been defined they must be subject to monitoring in order to ensure that the actual service delivery meets the expectations. This is achieved through metrics derived from the objectives and recorded in the IT scorecard in a way that can be understood and followed by the customer and which in turn enables the service provider to focus on the internal targets.
The objective of the IT organization is to deploy the skills of individuals and (technological) infrastructure systems using a clearly defined number of processes so that automated corporate applications can be operated and information processed. Together with the processes these resources form the corporate architecture of the IT.
In order to be capable of responding to the corporate requirements demanded of the IT the company must invest in resources so as to provide appropriate technical facilities (e.g. an Enterprise Resource Planning System) for supporting the company’s capabilities (e.g. implementation of a supply chain) which produce the desired result (e.g. increased sales figures and profits).
The IT resources identified in COBIT are defined as follows:
- Applications are automated applications and manual processes that process information.
- Information is the data in all its forms read, processed or generated by information systems in every form used within the company.
- Infrastructure is the technologies and systems (hardware, operating systems, database management systems, networks, multimedia etc.) as well as the installations that house and support them.
- People are those persons required for planning, organization, procurement, implementation, operation, support, monitoring and evaluation of the information systems and services. These can be internal, outsourced or contractually tied – as required in each case.
COBIT divides IT activities in a generic process model into four domains. These domains are: “Plan and Organize“, “Acquire and Implement”, “Deliver and Support” and “Monitor and Evaluate”. The domains are geared towards the standard responsibilities of planning, constructing, operating and monitoring.
The COBIT framework contains a reference process model and a common language applicable for everyone in the company in order to consider and manage the activities. The introduction of an operating model and a common language for all parties involved is the first and one of the most important steps in achieving good governance. COBIT also contains a framework for measuring and evaluating IT performance, communicating with service providers and integrating best management practices. A process model supports process ownership and provides for the definition of tasks and responsibilities.
In order to effectively control IT it is important to be familiar with the activities and risks within the IT which have to be managed.
Plan and Organise
This domain covers strategy and tactics and relates to the definition of how IT can best contribute towards achieving the corporate objectives.
Furthermore, the implementation of the strategic vision must be planned, communicated and managed according to various viewpoints.
Finally, there needs to be an appropriate organization and technological infrastructure in place. This domain typically answers the following management questions:
- Are IT and company pursuing the same aims?
- Is the company making optimum use of the IT resources?
- Does everyone in the organization understand the IT objectives?
- Are the IT risks understood and being managed?
- Is the quality of the IT systems sufficient to meet the requirements of the business?
Acquire and Implement
IT solutions have to be identified, developed or acquired and implemented and integrated into the business processes in order to implement the IT strategy. This domain also covers modifications to and maintenance of existing systems, ensuring that the solutions continue to reflect the corporate objectives. The domain typically answers the following management questions:
- Do the results of new projects meet the corporate requirements with a high level of probability?
- Are new projects likely to be completed on time and within budget?
- Will the new systems function properly once they have been completed?
- Are changes implemented without their having any unnecessary detrimental effect on the current business processes?
Deliver and Support
This domain deals with the actual delivery of the required services, encompassing service delivery, management of security and continuity, service support for users and management of data and facilities. It typically answers the following management questions:
- Are IT services delivered in accordance with the company’s priorities?
- Are the IT costs optimized?
- Can users utilize the IT systems securely and productively?
- Is the level of confidentiality, integrity and availability appropriate?
Monitor and evaluate
All IT processes must be regularly evaluated in terms of their quality and adherence to monitoring requirements. This domain deals with performance management, monitoring of internal controls, adherence to regulations and guarantee of governance. It typically answers the following management questions:
- Is the performance of IT measured in order to identify problems before it is too late?
- Does the management ensure that internal controls are effective and efficient?
- Can the performance of IT be linked back to the corporate objectives?
- Is risk, control, compliance and performance measured and reports on this produced?
Processes and controls
Controls are defined as those guidelines, procedures, practices and organizational structures which have been developed in order to ensure sufficient security so that the corporate objectives are achieved and undesirable events avoided or identified and corrected. An IT control objective is a statement on the required outcome or the intended purpose which is to be achieved with the implementation of control procedures integrated within certain activities. The COBIT control objectives are minimum requirements for the effective control of any IT process.
The operational management uses processes in order to organize and manage the current IT activities. COBIT provides a generic process model which contains all the processes normally to be found in IT functions and, as such, provides a general reference model which can be understood by the operational IT management and company management.
In order to achieve effective governance controls which are integrated into a control framework defined for all IT processes, controls must be implemented by the operational management. Since the COBIT IT control objectives are categorized according to IT processes, this framework represents a clear link between the requirements of the IT governance, IT processes and IT controls.
Every COBIT IT process contains a superordinate control objective as well as several detailed control objectives. Together these represent the characteristics of processes which are appropriately managed.
In addition to the acceptance of the necessary controls, process owners must understand which inputs are needed from other process owners as well as which outputs these require. COBIT contains generic examples of the key inputs and outputs for each process, including the external requirements. Some outputs are inputs in all other processes and this can be seen by ‘ALL’ in the output table. However, these outputs, such as targets for quality standards and metrics requirements, the IT process framework, documented roles and responsibilities, the company-wide IT control framework, IT guidelines or personal roles and responsibilities are not listed in all processes as their own input.
Understanding the roles and responsibilities of all processes is key to effective control. COBIT contains RACI charts for all processes. These are diagrams which show who is responsible, accountable, consulted and informed. Being accountable means having final responsibility. In other words, this is the person who issues standards or approves activities. Those who have responsibility are to be understood as those who perform the activity. The other two roles ensure that all the necessary participants are integrated and that they support the process.
DIFFERENCES and COMMONALITIES BETWEEN ITIL & COBIT
The tasks of ITIL
ITIL describes a systematic, professional procedure for the management of IT services. The library emphatically puts the emphasis on the importance of meeting the corporate requirements from the commercial aspect.
The necessary prerequisite for this is the unconditional willingness to accept change in respect of a customer and a service-orientated approach. In many companies this requires a change in the existing behavioral culture.
The aim, with the help of ITIL, is to also create a clear world of definitions in the service management area and to consequently simplify the communication.
The tasks of COBIT
The COBIT framework is aimed primarily at compliance and security and, as such, ensures the IT governance for the operation of the IT services.
IT service management under ITIL is geared purely towards customer benefit and efficiency. Achieving the business objectives whilst simultaneously meeting internal and external requirements is fundamental to ensuring a company’s medium and long-term success.
There is now considerably less tolerance of misconduct and negligence amongst the legislators, shareholders and clients. Domestic and foreign regulatory authorities are demanding faultless procedures. They are calling for the transparency and measurability of the IT activities. The management of the operational risks must therefore be carried out in the interest of the company and its stakeholders.
As numerous negative examples from the past show, some companies have not survived due to the lack of or defective control mechanisms. Basel II and the Sarbanes-Oxley Act (SOX) were created not least as a result of the lack of due care in the handling of operational risks.
In this context ever-increasing importance is being attached to COBIT today. This best practice framework supports the controls for all IT processes and is primarily geared towards the auditing aspects and ensuring compliance.
Synergy between COBIT and ITIL: ISO 20000
It is no longer enough purely to implement best practice. The synergy between the two networks now lies in the fact that the more formal control objectives of COBIT are being aligned with the ITIL framework which is orientated towards suitability and flexibility and these must be fulfilled in a way that can be defined.
This link neatly synchronizes the standards for the strategic orientation and increased efficiency of IT service management with the auditing standards.
The two frameworks will continue to develop and increasingly converge, with the bridge for this being created by the international ISO 20000 standard. Based on ITIL the two organizations itSMF and BSI (British Standard Institute) have developed this clearly measurable standard and therefore created the opportunity for certification of the conformity, effectiveness and efficiency of the individual IT service management control objectives.
source : from ITIL Documentation
- Service Management System
- Design and Transition
- Service Delivery Processes
- Relationship Processes
- Resolution Processes
- Control Processes
The aim of the ISO/IEC 20000 standard is to provide a common reference standard for all companies that deliver IT services for internal or external clients. One of its other objectives is to promote a common terminology which makes an important contribution towards communication between service provider, supplier and customer.
The standard will also adopt the integrated process approach from the service management framework of ITIL®. These processes are contained within a process model, forming part of the quality management system and providing an important aid in communication with the customers (users) as well as within the IT. The process model illustrates which processes control, support and continually improve service delivery.
ISO/IEC 20000 is coordinated with the IT Infrastructure Library (ITIL®). ITIL® is a collection of best practices to which a service provider can align itself so it can deliver high quality services. ISO/IEC 20000 represents the quality benchmark. ITIL® therefore supports the service provider along this route.
The ISO/IEC 20000 standard comprises two parts:
ISO/IEC 20000 Part 1: Specification for Service Management
This formal specification defines the requirements of an organization and the management system for delivering managed services at a level of quality acceptable to the customer. In this respect it is irrelevant as to whether this is an internal or external customer.
ISO/IEC 20000 Part 2: Code of Practice for Service Management
This part represents a Code of Practice and describes the optimum experiences achieved with service management processes within the scope of ISO/IEC20000-1. This Code of Practice is useful in particular for organizations who wish to prepare for an audit and the certificate in accordance with ISO/IEC20000-1 or who are planning fundamental improvements in their services.
Service Management System
The first process group of the ISO/IEC 20000 standard defines the bases and principles for successful implementation of the management system. This follows the objective of providing a management system taking into account basic principles and structures in order to facilitate a properly coordinated management and effective implementation of IT services.
One prerequisite for this is a customer and process-orientated method of working in all areas of information technology. This necessary cultural change cannot simply be demanded of the employees but instead must receive the active support and encouragement of the management which must lead by example.
Under ISO 20000 the IT strategy is particularly important for these IT service management disciplines for which the senior management is responsible. In addition, the striving for continual improvement in all IT areas must be decreed as a binding guideline and consistently implemented.
The objective is to embed and therefore secure the responsibilities for implementing the service management system within the service provider’s senior management level.
To enable these obligations to be met the responsibility for the service management system must be delegated to a member of the Management Board is responsible for implementation and has sufficient expertise for this task. Ideally this person will receive support from a management group that will help in the decision-making process. The defined service manager is therefore also the owner of the entire service management system.
The service provider must supply documents and records on the support given to the management process. This is intended to ensure effective planning, operation and monitoring of the service management processes.
A process must be installed for document and record production and management. The documents are the foundation and basis for verification that the service management guidelines are being adhered to.
A fundamental distinction must be drawn between two key elements
- Documents which record the management’s plans and intentions.
- Records that testify to the implementation.
It should be explained that service management exists not only on paper but is also actually practiced in all processes. Proof of this must be provided in an integrated form. It is the responsibility of the management to ensure that the basic principles and all processes are:
- regularly reviewed and
Descriptive documents and corresponding records are required for this purpose.
Expertise and Training
Management and employees must be aware of the relevance and importance of their activities within the service management and understand how they contribute towards achieving the quality targets.
Corresponding expertise and skills must be available in order to ensure that the requirements for new or modified services can be met.
The dynamic, continuing advances in technology require on-going education and further training for the employees who should be managed via coordinated skills management. As part of the annual target agreement discussions and the targets derived from the service management planning, the training requirement for the employees to meet future requirements is determined on the basis of a consistent analysis of any shortfalls and condensed into an annual training plan. The effectiveness of training measures must be reviewed.
In order to determine the specific demand the service provider first defines the specific skills required for each role in the service management. Detailed records must be kept on the education and training courses completed by each employee together with their acquired knowledge and experience.
Planning and Implementation of Service Management – Overview
In the planning and implementation of the service management account must be taken of the decisions made (targets), processes and defined responsibilities. A Quality Management System (QA) forms the basis for this. The development of a QA system is a demanding task and requires understanding of the purpose, guidelines and targets as well as the processes involved. This interrelationship is known as “Planning and Implementation of the Service Management”.
The Deming cycle (Plan-Do-Check-Act) must be embedded within the organization. In this context it is important to document the successful application of this model. The output of each activity simultaneously represents the input for the next activity. The feedback between the processes is presented consistently and in transparent form.
It is important for the service management employees to be well-versed in the basic principles of service quality, the service management processes as well as their own personal contribution. This principle ensures that measures can be taken at any time in order to increase the effectiveness and efficiency of the service delivery.
When implementing and reviewing the service management processes the requirements under this section must be applied not only for the management system as a whole but also for each individual process in the ISO 20000 management system.
Plan, Do, Check & Act
The objective of this process is the planning of the implementation and provision of the service management system.
The successful implementation of these plans requires clear management instructions and documented responsibilities for the review, approval, communication, implementation and updating of the plans.
All plans specific to a process must conform to the superordinate service management plan.
The objective of this process is to embed the service management targets and the service management plan.
Once the service management plan or process plans have been implemented the task then is to concentrate on the operation and continual optimization of the service management processes. We have seen in practice that the employees responsible for implementation need to be replaced by other suitable employees for the task of continuous operation.
The task here is to monitor and measure as well as review the attainment of the service management objectives and service management plan. In this context, reviews must be planned and carried out at regular intervals, at least annually.
The results of the review and testing are used as an input for the next step, “Act”, in the Deming cycle. The aim of this is to achieve an improvement in the service processes.
The management must firmly establish and communicate a basic principle that contains a clear definition of the roles and responsibilities (CSI owner) for improving service activities.
Any aspects that do not conform to the service management plans must be eliminated. A service improvement plan must be drawn up for dealing with all proposed service improvements.
Improvements to the individual processes can be managed by the respective process owner. More extensive improvements – such as for example rectifying non-conformities which extend throughout the company or improvements in more than one process – must be carried out within the framework of one or more projects.
Prior to the implementation of a service improvement plan the service quality and service level must be documented as a baseline. On the basis of this data a comparison with the actual improvements achieved should be carried out.
Planing of New Services
ISO/IEC 20000 has a separate process for the planning and implementation of new or modified services. The aim of this is to ensure that the new and modified services are delivered at the agreed costs and in the desired service quality.
Special account should be taken of the following aspects. All new or modified services are implemented in accordance with the PDCA cycle:
The offer of new or modified services must take into account the impact on costs and profitability and the organizational and technical influences on the service management and service delivery.
The implementation of new or modified services – including the termination of a service – must be planned and formally approved by the Change Management.
The planning and implementation must take appropriate account of financing and resources so the necessary changes for service delivery and service management can be carried out.
Service Delivery Processes
The service delivery core area encompasses the planning and tactical level of IT service management. In this area the actual service levels are defined and agreed and reports submitted on the actual services rendered.
The following processes form part of service delivery:
- Service Level Management
- Service Reporting
- Capacity Management
- Service Continuity & Availability Management
- Information Security Management
- Budgeting & Accounting for IT Services
Service Level Management
The service level management process must ensure that the full scope of the services is agreed and documented.
We recommend a structured procedure in accordance with the documented guideline below for meeting the specifications required of the service level management.
The service level management process should not be performed on a formalistic and rigid basis but instead be flexibly and proactively geared towards changes. It is necessary to ensure that a distinctive customer focus is applied on all levels and in all phases of the service delivery. Customer satisfaction is seen as a subjective assessment and the achievement of the agreed service targets an objective assessment. Corresponding attention must therefore be paid to the way in which the service is perceived by customers and users.
This process regulates the fundamental tasks of the service provider and therefore forms the basis or even in fact the authority for delivering the customer services. The service provider should therefore possess sufficient information in order to have a genuine understanding of the business drivers and the customer’s requirements.
The SLM process must be linked appropriately with the business relationship and supplier management processes.
A clear definition must be provided for all reports as to the intention and purpose of the report, its target groups and, in particular, the data sources. Reporting needs identified from customer requirements must be met.
The success of all service management processes depends upon the utilization of the information from the service reports. The management decisions, together with corrective action, must be based on the results of the service reports and communicated to all relevant parties.
Less is often more. This applies very specifically in the case of service reports. We recommend that reports should only be produced on the basis of agreed and documented customer requirements and those of the internal IT management. In this context, the relationships with both internal as well as external suppliers should also be illustrated to enable the entire service chain to be reviewed.
Service Continuity and Availability
The two processes, availability and service continuity management, must ensure that the agreed objectives of availability and continuity for the customer can be met in every case.
It is vital that all activities and expenditure, as well as the resources assigned for the implementation of the continuity and availability targets, should be coordinated with the requirements of the business.
The availability must be recorded for monitoring the services and historic data sets kept for trend developments in order to identify and document deviations from the defined targets. We also recommend that the effectiveness of improvement measures which have been introduced should then be reviewed.
The availabilities and planned maintenance windows must be forecast in advance and communicated to all those involved. This will enable preventative maintenance to be carried out on a targeted basis.
The service provider must give an undertaking to draw up a strategy for adhering to the service continuity targets. One of the integral parts of this strategy is a risk assessment based on the extent of loss and probability of occurrence which takes into account both service as well as particularly critical operating times.
We recommend that the service provider clearly defines at least the following points with each customer group:
- maximum accepted period without service
- maximum accepted period with reduced service
- accepted reduced service level during a defined recovery period
The service continuity strategy must be reviewed jointly with the business representatives on a continual basis, at least however annually. All changes to the strategy must be formally agreed and implemented within the framework of the change management.
The capacity management ensures that the service provider has sufficient capacities permanently available in order to meet the current and future agreed business resource needs. In this sense efficiency means that provision is made for a high level of resource capacity utilization.
The aim of capacity management is to proactively avoid resource bottlenecks. The following best practice recommendations have become established practiced for meeting the requirements of capacity management:
The service provider must understand the current and future requirements from the business perspective and consequently be able to ascertain the future IT requirement on the basis of the strategic business development.
Derived from the business strategy the demand forecasts and estimates of capacity utilization must be converted into specific requirements for the IT infrastructure and documented. To this end the load response of the corresponding service components for different levels of transaction volumes must be understood from the technical viewpoint.
The data on current and past component and resource capacity utilization levels should be recorded in transparent form and analyzed for the purpose of forecasting capacities.
New or modified services must be assessed in terms of the future capacity demand in the various life phases and corresponding preparations made.
The capacity plan which documents the current performance of the infrastructure and the anticipated requirements must be drawn up to meet the relevant situation, at least however on an annual basis. It should be noted that test and integration environments in particular show a relatively high capacity reserve which is actually rarely utilized.
The purpose of all measures in capacity management is to achieve the agreed service level targets.
Information Security Management
The objective of the information security management is to provide effective control and monitoring of the information security for all service activities. The standard refers to the Code of Practice ISO/IEC 27001 which forms a good basis for implementation of the information security.
Information security is a system of guidelines and procedures for identifying, controlling and protecting information and all operating materials associated with its/their storage, transfer and processing. Best practice recommendations for meeting the requirements demanded of information security management have become established in the following structure:
IT security basic principles
- Identification and classification of information assets
- Security risk assessment
- Controls (monitoring, guidance measures)
- Documents and records as proof
Budgeting and Accounting Management
The aim of budgeting and accounting for IT services is to budget for and provide documentary evidence of the costs for service provision. Experts in the ITIL framework might think that charging has been missed out here. In fact, service charging is not a direct requirement of the ISO/IEC 20000 standard. However, it does make reference to the importance of charging and recommends that it be implemented in accordance with the general basic principles. However, since a large number of organizations do not wish charging to be included for business policy reasons this was left out of the specification.
Budgeting and accounting does not have to be re-defined. Any implementation in this area must be agreed and coordinated with the company’s central accounting department. We recommend that guidelines be drawn up on the handling of the budgeting and accounting processes. This guideline or policy must define the required level of detail as shown below:
- What types of costs have to be proven?
- What is the structure of the allocation code for the overheads?
- What categorization detail of the customer business should be chosen in order to apportion the charging (business unit, department, location)?
- What is the procedure for dealing with deviations from the budget? Are there any dependencies with regard to the size of the deviation? What is the procedure for escalation to the senior management?
- How is this linked with the service level management?
The costs expended for the budgeting and accounting processes must be determined according to customer, service provider and supplier demand. The benefits of recording operational data must justify the expense.
The relationship processes describe the two aspects of business relationship management and supplier management. In this context the standard focuses on the role of the service provider (frequently a company’s IT organization) which is logically positioned between customer and supplier.
Both customers as well as suppliers can be part of the service provider’s organization or external. A fundamental distinction is drawn between the following three levels for the contracts:
The agreements between the customer and service provider are known as service level agreements (SLA).
External support (suppliers) required for the agreed IT services are formalized with underpinning contracts.
Operational level agreements govern the relationships within the IT organization for the service delivery.
In order to create good relationships between the participating parties clear agreements must be in place. In this context, all parties should have the same understanding of the business requirements, service capacity as well as the framework conditions and the respective responsibilities and obligations. This is the only way in which each party can meet its performance obligation.
Business Relationship Management
The aim of business relationship management is to understand the customer and the business process drivers and based on this to establish and maintain a good relationship between the service provider and the customer.
Three key aspects must be anchored within the organization in order to meet the requirements demanded of business relationship management:
- Regular service reviews
- Service complaints procedure
- Measurement of customer satisfaction
The aim of supplier management is to control suppliers in order to ensure a smooth delivery of high quality services.
As a general rule there are a number of suppliers involved. These are often also subdivided into main suppliers and subcontract suppliers. It is therefore necessary to clearly define whether the service provider is to negotiate directly with all suppliers or whether a main supplier is to take over the responsibility for the subcontract suppliers.
The supplier management process must ensure that the supplier understands its obligations to the service provider. The requirements must therefore be clearly defined and agreed. It is also necessary to ensure that all changes to these agreements are monitored by the change management process.
In order to avoid conflicts we recommend that records be created of all official business transactions between all the parties. The services of the supplier must be continually monitored and an appropriate response taken as required.
The resolution processes include the incident and problem management processes. These are standalone processes even if they are closely interlinked. Incident management deals with the restoration of the service for the service user. Problem management by contrast deals with the identification and elimination of root causes in the case of major or repeat disruptions and therefore ensures a permanent and stable service infrastructure.
Setting priorities in dealing with disruptions and problems is based on the two criteria of Impact (negative affect on the service) and urgency (urgency as a result of the current situation). The impact should be based on the extent of the interruption to business whilst the urgency is based on the timescale between the incident or problem occurring and the negative impact on the customer’s business.
Problem management is intended to provide workarounds in order to lend support to the restoration of the service by the incident management or the user. A known error in a service can only be rectified if a correcting change has been successfully implemented or if the known error no longer occurs. Information on workarounds as well as their applicability and effectiveness must be stored and updated in a known error database.
The aim of incident management is to restore the agreed service for the business and respond to service enquiries as quickly as possible.
In order to fulfill the specification requirements it is necessary to ensure that the incident management is designed as a reactive and proactive process that responds to error messages. The process must focus on the restoration of the IT service concerned and consciously not deal with the identification of the root cause.
The incident process (incidents and service requests) comprises receiving calls, recording, prioritization, taking account of security provisions as well as following up on the incident processing status. It should also govern the agreement on fault processing with the customer as well as any escalation procedures. All incidents must be recorded in such a way as to enable the relevant information to rectify the error to be ascertained and analyzed.
The progress of work should be reported to the current and any potential personnel affected. All activities must be fully recorded in the incident ticket.
Wherever possible, customers must be able to continue their business in the appropriate way. Workarounds can also be utilized for this purpose.
The aim of problem management is to minimize the disruption to and impact on the business by proactively identifying and analyzing the root causes of service incidents and by managing problems until these are rectified.
Problem management must identify the root causes of the incidents on a reactive basis and proactively prevent incidents reoccurring. Problems are to be classified as known errors as soon as the root cause of the incident is known and a solution method for avoiding such incidents has been found.
For incident management to receive an optimum supply of information, all known errors and IT services affected must be documented and the associated configuration items identified. Known errors should only be closed once a definitive, successful solution has been found.
Once the root cause has been identified and a decision reached on the solution, this solution must be dealt with by the change management process. Information on the progress, potential workarounds or permanent solutions must be sent to all parties involved.
The closure of problem tickets should always be carried out in accordance with the following reviews:
- Has the solution been precisely documented?
- Has the root cause been categorized in order to provide support for future further analyses?
- Have the customers and support employees affected been informed of the solution?
- Has the customer confirmed that he/she accepts the solution?
- Has the customer been informed if no solution has been found?
The effectiveness of completed solutions to problems must be reviewed. In particular, trends such as for example reoccurring problems and incidents, defects, errors, known errors in planned releases or resource commitments must be identified by employees.
The control processes create the key conditions required for a stable and secure IT operation by maintaining a proper IT inventory and ensuring notified changes in the IT landscape in the form of individual changes or as bundled packages (releases). Change and configuration management form two core processes in the whole process model. These two processes enable a service provider to control the service and infrastructure components and to manage secure information. Precise information is the basic prerequisite for decision-making in the change management process as well as for all other service organization processes.
The aim of configuration management is to define and control the components of the service and infrastructure and to manage precise configuration information.
All key assets and configurations should be assigned to the responsibility of a manager who ensures appropriate security and control. This is intended to guarantee, amongst other things, that approval is obtained before changes to the CI are implemented. The following recommendations for meeting the specifications for the configuration management process have become established practice:
- Planning and implementation
- Configuration identification
- Configuration control
- Proof of status
- Verification and audit
The aim of change management is to ensure that all changes are evaluated, approved, introduced and reviewed using stipulated methods. In this context the focus is on the efficient and prompt implementation with minimal risk to the operational business.
The change management processes and procedures are intended to ensure that changes have a clearly defined and documented scope. Only changes which have an identified business benefit will be authorized. Changes should be planned on the basis of priority and potential risk. Changes to configurations must be verified during the implementation of the change.
The status of the changes and planned dates for implementation form the basis for change and release planning. Information on dates should be communicated to the persons affected by the change.
Whereas change management concentrates on controlling changes, release management prepares the planned changes for distribution. Release management should be integrated into the configuration and change management processes in order to ensure that the releases and implemented changes are coordinated. Release management coordinates the activities of the service provider, suppliers and business cycles. The outcome of this is a plan for the supply of a release to the operational IT environment.
The aim of the release management is to deliver, distribute and monitor one or more changes in a release to the operational environment.
One of the key tasks of release management process is to coordinate all the participating resources in order to hand over a release to a shared environment. In this context good planning and management is a basic prerequisite for packaging releases, their successful distribution as well as for having the associated impact and risks for the business and the IT under control.
We recommend that all aspects of the release be planned in advance with the business. To this end the impact on the associated CIs must be evaluated and both the technical as well as the non-technical aspects be jointly taken into account.
For the purpose of transparency all release elements must be traceable and safeguarded to prevent their being changed. Only tested and approved releases should be accepted within the operational environment.
Seven Design Considerations for a Green Data Centre
IT departments are under increased scrutiny and pressure to deliver environmentally-sound solutions.
Large data centres are one of the most significant energy consumers in an organisation’s IT infrastructure, so any measures that you can take to reduce this consumption (and therefore also carbon dioxide emissions) will have a positive impact on your organisation’s environmental footprint.
Additionally, a report issued by the Environmental Protection Agency in the States indicates that environmental issues have placed IT departments under pressure to develop ‘green’ data centres.
A green data centre is defined as one in which the mechanical, lighting, electrical and computer systems are designed for maximum energy efficiency and minimum environmental impact. The construction and operation of a green data centre involves advanced technologies and strategies. Some examples include:
- Reducing the power consumption of the data centre
- Minimising the footprints of the buildings
- Maximising cooling efficiency
- Using low-emission building materials, carpets and paints
- Installing catalytic converters on backup generators
- Using alternative energy technologies such as photovoltaic electrical heat pumps and evaporative cooling
The consumption of energy is considered the dominant – and often the only – factor in defining whether or not a facility is green. IT executives therefore need to start investigating alternative ways of building energy-efficient data centres.
By following these seven simple steps, IT executives can come closer to achieving their vision of a green data centre
1. Plan to be green
There is worldwide hype around environmentalist issues and a number of vendors are claiming to be gurus in the field of green. The ‘go green’ marketing hype makes it difficult for organisations to understand the real issues and the potential eco-impact on the data centre. A realistic strategy is necessary that takes into consideration the following aspects when planning a data centre:
- The existing utilisation rate of your servers which includes the number of servers in the environment, their average power consumption, the cost to run per hour, the cost to run servers per year, the power consumption and the cooling costs.
- The expected data growth of the data centre, which includes taking into account future business demands (create a scenario of where you’ll need to be to support the business in a few years’ time).
2. Virtualise and consolidate
A virtualisation and consolidation project is often a step in the right direction towards green computing. Research indicates that a server often only utilises between 5 and 15% of its capacity to service one application. With appropriate analysis and consolidation, many of these low utilisation devices can be combined into a single physical server, consuming only a fraction
- of the power of the original devices and saving on costs, as well as taking a step towards a more environmentally friendly data centre environment.
The basic concept of virtualisation is simple: encapsulate computing resources and run on shared physical infrastructure in such a way that each appears to exist in its own separate physical environment. This process is accomplished by treating storage and computing resources as an aggregate pool, from which networks, systems and applications can exploit, on an as-needed basis.
Virtualisation and consolidation projects are complex, but the benefits are compelling.Server consolidation ratio examples include 15:1 or 45:3, and virtualisation results in improved application availability and business continuity independent of hardware and operating systems,among others
3. Design a best practice floor plan
The Uptime Institute* produced a white paper based on a survey of 19 data centres and reported that, on average, only 40 percent of the cold air went directly towards cooling the servers in the room, wasting yet more power in the data centre.
So, whether you are designing a new data centre or upgrading your existing environment, make use of existing best practices in data centre floor plan designs.
Hot aisle/cold aisle layout; Adopting an alternating hot aisle/cold aisle layout is optimal and can correct many cooling problems in a typical data centre.
By implementing a hot/cold aisle layout, equipment is spared from having hot air recirculated and thereby eliminating risk of an outage through device failure. Also, by having a common hot aisle, you have the ability to contain areas where heat density is high, such as racks with blade servers, and deal with the heat in a specific manner. This allows for multiple heat rejection methods to be in use within one data centre.
The distribution of power across racks; Another layout consideration is the distribution of power across racks. All attempts should be made to balance the watts per rack to within a 10-15% variance. This minimises hot-spots and the need for sporadic hot-aisle containment.
Often data centre designers locate servers performing related functions in the same racks, but the benefit of having these servers close together is outweighed by the heat density this may cause.
Minimise or eliminate under-floor cabling; It is imperative for organisations with static pressure cooling to minimise or eliminate under-floor cabling. If you can’t avoid it, use conduit, cable trays, and other structured methods for running cabling. This minimises barriers between computer room air conditioning (CRAC) units and perforated tiles, resulting in more efficient air flow and optimised cooling system efficiency.
Don’t underestimate the importance of the physical design of the data centre when it comes to power and cooling, both for sustainability, costs and environmental impact.
4. Use appropriate technology
In taking a green approach to your data centre, your evaluation of products is no longer just a price versus performance comparison. It is important to incorporate the total costs of the environment into the calculation, which then also includes costs for energy consumption.
Firstly, look for vendors that have power and cooling at the forefront of their research and development strategies.
Secondly, select equipment based on life cycle costs that take into account the energy usage of servers.
An example of a green technology is MAID (massive array of idle disks). This is a storage technology that employs a large group of disk drives in which only those drives in active use are spinning at any given time. This technology can have thousands of individual drives, and offers mass storage at a cost per terabyte roughly equivalent to that of tape.
5. Take a green perspective on ILM
ILM is the optimum allocation of storage resources that support a business. Every element of information in an organisation has a useful lifespan and this can range from a voice conversation to certain legal and medical records. By implementing an ILM strategy, you have the ability to create greater efficiencies in data storage, which in turn lead to greater efficiencies in elements such as power consumption.
ILM is the application of rigour to the often chaotic and unstructured data stores that an organisation maintains. The storage, utlisation, maintenance and destruction of this data can be quite expensive over its lifetime, and what is worse, its lifetime is often much longer than its useful life. The art of ILM is to develop an understanding of an organisation’s information needs, and to develop the infrastructure and processes required to maintain the usefulness of the information, while at the same time creating the discipline to minimise the cost of that maintenance.
Tiered storage is at the heart of an ILM implementation. The value of ILM is the ability to tie the cost of storage to the value of the information on it. The most important data, or the most performance-critical data, should be placed on the highest performance and most expensive storage.
In turn, do not use expensive energy consuming servers to store information for compliance, when a tape will do.
Additionally, knowing the character (age, file type, usage frequency, and business value) of the data in your environment is pivotal for being able to make informed decisions around ILM strategies.
Assessments that Dimension Data has conducted with more than 100 organisations worldwide show an average of more than 40% file duplication* in their environments. With this information, organisations have the knowledge to decide whether to move data to less expensive and energy consuming storage, and to better utilise their existing environment and save storage space.
6. Investigate liquid cooling
To meet the challenges of blade servers and high-density computing, more organisations are realising the need for effective cooling and heat management solutions. Many are welcoming liquid cooling systems into their infrastructures to achieve better cooling efficiency, while others may find it difficult to fathom pipes of running water snaking through the plenums of their data centres.
In essence, liquid cooling systems utilise air or liquid heat exchangers to provide effective cooling and isolate equipment from the existing HVAC (heating, ventilating and air conditioning) system.
There are several approaches to data centre liquid cooling:
- Sidecar heat exchangers – these are closed enclosures that deliver cooling from the side, which keeps the cooling from dissipating into the server room
- Chip-level cooling and bottom mount heat exchangers – these enclosures use a bottom mount heat exchanger which some claim is safer than sidecar enclosures as components won’t be affected in the event of a water leak
- Modular liquid cooling units – these units are used within a fully sealed cabinet and are mounted at the rack base, in a rack sidecar
- Door units – full-door units replace a standard server rack door and contain sealed tubes filled with chilled water
- Integrated rack-based liquid cooling – these systems incorporate a rack-based architecture that integrates UPS power, power distribution and cooling and feature a cooling distribution unit (CDU) that pumps water through aluminum/plastic tubing to cool servers
- Device-mounted liquid cooling – these solutions work at the device level, with coolant routed through sealed plates on the top of a CPU (central processing unit)
7. Utilise greener energy sources
Many energy utilities are now offering greener options for customers, with power
from sustainable sources. For example, in the United States, the U.S. Environmental Protection Agency (EPA) has formed the Green Power Partnership, which encourages and assists organisations to buy green power and reduce their impact on the environment.
There are also some emerging powersaving technologies that are likely to become more commonplace in the data centre in the near future. For example, DC-compatible equipment would have a significant impact on power consumption, but it is costly to configure, it is not widely available and it is also more expensive than equivalent AC options.
At present, data centres perform many conversions between alternating current (AC) and direct current (DC). This wastes energy which is emitted as heat and increases the need for cooling. It would be far more efficient to power servers directly from a central DC supply. The Lawrence Berkeley National Laboratory in the US estimates that an organisation may save 10% to 20% of their energy use by moving to direct current technology.