Bilgi İhtiyaçtır: Relation in Between ITIL, Cobit, Togaf and CMMI

ITIL

When did it become a matter of shame and humiliation not to fully implement ITIL?

I meet many people in the course of a year and have noticed that when you ask the question “How are you progressing with your ITIL implementation?” that the response is often a shameful admission that “we may not be able to implement the whole of ITIL v3”. Since when was implementing the whole of ITIL a mandatory

requirement? What happened to ITIL being a framework and not a methodology? Why not implement a Lite version of ITIL that meets your immediate needs and objectives? There are many organisations that for different reasons cannot or will not be implementing ITIL v3 in its entirety and therefore are taking a Lite approach. ITIL Lite could be described as:

‘ITIL Lite is an approach to implementing key components of ITIL v3 to ensure a sound basis for IT Service Management either as a starting point for full implementation or as a deliverable for those not wishing to fully implement ITILv3’

The objectives of ITIL Lite as described in this article are to provide an approach to selecting the most appropriate ITIL v3 components for ITIL Lite and then preparing a project to implement those components.

One of the most significant claims of earlier versions of ITIL was that they were a ‘framework’ and not a ‘methodology’. For many people this was a major factor for them selecting ITIL. When teaching ITIL v2 it was common for instructors to have a slide stating that ITIL was ‘A framework and not a methodology’. How often were we told that you didn’t have to implement all of the ITIL components or that each component was a guide and not a set of stringent rules? So what is the difference between a framework and a methodology? If in doubt refer to the dictionary which has always been a reliable maxim so here are dictionary definitions of framework and methodology

Methodology - A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods.

Framework – a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality.

Let us look at these definitions to help us decide whether ITIL v3 is a framework or a methodology. The words in the methodology definition are ‘procedures, rules and discipline’. These words do not leave much room for flexibility as they are very much associated with a given set of activities that must be performed in a precise and prescribed manner. Many of us in IT are able to remember Computer Operations procedures that had to followed to the letter. In essence a methodology is a set of inflexible instructions that must be followed to the letter.

On the other hand, referencing a framework is a completely different approach illustrated by the words ‘assumptions, concepts, values and a way of viewing reality’. These are words that advise and guide you towards a solution rather than provide a path that has to be followed. Framework allows you the option of choice and flexibility.

So what is ITIL v3? Is it a methodology or is it a framework?

Maybe we should first look at the history of ITIL by looking at a quote from the Service Delivery book as captured in ITIL Refreshed (or v2 as it is also known):

Best practice framework

The IT Infrastructure Library documents industry best practice guidance. It has proved its value from the very beginning. Initially, OGC collected information on how various organisations addressed Service Management, analysed this and filtered those issues that would prove useful to OGC and to its Customers in UK central government. Other organisations found that the guidance was generally applicable and markets outside of government were very soon created by the service industry.

Being a framework, ITIL describes the contours of organising Service Management. The models show the goals, general activities, inputs and outputs of the various processes, which can be incorporated within IT organisations. ITIL does not cast in stone every action required on a day-to-day basis because that is something which differs from organisation to organisation. Instead it focuses on best practice that can be utilised in different ways according to need.

Thanks to this framework of proven best practice, the IT Infrastructure Library can be used within organisations with existing methods and activities in Service Management. Using ITIL doesn't imply a completely new way of thinking and acting. It provides a framework in which to place existing methods and activities in a structured context, providing a strategic context that improves tactical decision-making and has an aligning influence on the tasks of Service Management. By emphasising the relationships between the processes, any lack of communication and co-operation between various IT functions can be eliminated or minimised.

ITIL provides a proven method for planning common processes, roles and activities with appropriate reference to each other and how the communication lines should exist between them.

The quote is a long but it does make the point that one of the guiding principles for ITIL has been a framework approach. The concept of a framework approach is not lauded so highly in ITIL v3 but a quick look at the components of v3 show that a framework approach is the best policy:

As you can see there are 30 Functions and Processes contained in the ITIL v3 publications and these do not include other components such as: ‘Requirements Engineering’, ‘Data & Information Management’ and ‘Operational Activities in other Lifecycle Phases’. This is a very impressive line-up but in reality many of the players will not get a game. If you remember our dictionary quote included the word ‘procedures, rules and discipline.’ If we applied those words to all of these processes and functions then we would need a lot more than five books. In fact, if the books contained detailed procedures some of the processes would need a book of their own.

What about flexibility? Every IT organisation has a different structure and a different set of deliverables and therefore need to tailor their Service Management resources accordingly, which is why they need guidance and not a methodology. In ITIL terms you need to select the ITIL v3 components that work for you and then tailor them accordingly, which is a mantra that inspired the first two iterations of ITIL.

So why are there so many people seeing ITIL v3 more as a methodology than as a framework? This is a hard question to nail down but part of the reason is that the word framework isn’t in the v3 glossary nor is it referred to in any depth in any of the ITIL v3 core books. Also many of the exponents of v3 have not been exposed in any depth to v2 and therefore do not have the original concepts of ITIL ingrained in their comprehension of ITIL.

In summary, ITIL should be a flexible guide that helps us to build a Service Management facility that is ‘fit for purpose’ and not a rigid set of instructions. This is why ITIL v3 should be seen as a FRAMEWORK and not a methodology. As a framework we should not have to include all of the ITIL v3 components. The key to delivering a Service Management facility that is ‘fit for purpose’ is to select the correct components and installing them with careful planning and not feeling compelled to install ever single component in ITIL v3 exactly as they described in the books. Lose the shame and start being proud that you are using a great best practice to provide the best possible service that you can provide for your customers.

COBIT

1. What is the purpose of COBIT?

The purpose of COBIT is to provide management and business process owners with an information technology (IT) governance model that helps in delivering value from IT and understanding and managing the risks associated with IT. COBIT helps bridge the gaps amongst business requirements, control needs and technical issues. It is a control model to meet the needs of IT governance and ensure the integrity of information and information systems.

2. Who is using COBIT?

COBIT is used globally by those who have the primary responsibilities for business processes and technology, those who depend on technology for relevant and reliable information, and those providing quality, reliability and control of information technology.

3. Who are the process owners?

COBIT is IT process-oriented and, therefore, addresses itself in the first place to the owners of these processes. Referring to Porter's Generic Business Model, core processes (e.g procurement, operations, marketing, sales) are discussed, as well as support processes (e.g human resources, administration, information technology). As a consequence, COBIT is not only to be applied by the IT department, but by the business as a whole.

This approach stems from the fact that in today's enterprises, the process owners are responsible for the performance of their processes, of which IT has become an integral part. In other words, they are empowered but also accountable. As a consequence, business process owners bear the final responsibility for the information technology as deployed within the confines of their business process. Of course, they will make use of services provided by specialized parties such as the traditional IT department or the third-party service provider.

COBIT provides business process owners with a framework, which should enable them to control all the different activities underlying IT deployment. As a result, on this basis they can gain reasonable assurance that IT will contribute to the achievement of their business objectives. Moreover, COBIT provides business process owners with a generic communication framework to facilitate understanding and clarity amongst the different parties involved in the delivery of IT services.

Furthermore, the management guidelines provide management with a set of tools that allow self-assessment to help make choices for control implementation and improvements over IT, and measure the achievement of goals and the proper performance of IT processes. The management guidelines include maturity models; key goals and metrics; and responsible, accountable, consulted and/or informed (RACI) charts to clarify roles and responsibilities to support managerial decision making.

4. Why was the orientation of COBIT focused on the process rather than functions or applications?

The COBIT framework has been structured into 34 IT processes clustering interrelated life cycle activities or interrelated discrete tasks. The process model was preferred for several reasons. First, a process by its nature is results-oriented in the way that it focuses on the final outcome while optimizing the use of resources. The way these resources are physically structured, e.g., people/skills in departments, is less relevant in this perspective. Second, a process, especially its objectives, is more permanent in nature and does not risk change as often as an organizational entity. Third, the deployment of IT cannot be confined to a particular department and involves users and management as well as IT specialists. In this context, the IT process remains, nevertheless, the common denominator.

As far as applications are concerned, they are treated within the COBIT framework as one of the four resource categories. Hence they are to be managed and controlled in such a way as to bring about the required information at the business process level. This way, application systems are an integral part of the COBIT framework and can be addressed specifically through the resource vantage point. In other words, focusing strictly on the resources only, one would automatically get an application view of the COBIT objectives.

5. How robust are the business requirements?

During the review process of COBIT, senior managers and CIOs liked the definition of the business requirements for information, and supported the choices about which requirements were most important in what process. Choices were difficult and entailed considerable debate among the experts during the project. The guiding principle has always been: What really is fundamental for this control objective in this process? Which resource needs special control? Which information requirement needs special attention?

With the development of COBIT 4.1, the understanding of business requirements has been strengthened by the addition of generic business goals and a business-goal-to-IT-goal-to-IT-process cascade. These generic goals, based on extensive industry research, help COBIT users align their business requirements with specific critical processes.

6. What is the overall quality of COBIT, and were any process owners/executives part of the expert review?

To assure the high level of quality of COBIT, several measures have been taken. The most important are:

The whole research process has been overseen by the IT Governance Committee (ITGC), which is responsible for all ITGI research, and directed by the COBIT Steering Committee (CSC). Besides preconceiving the deliverables, the CSC has also been responsible for the final quality of these deliverables.
A CIO panel provides insights and suggestions for further developments.
The detailed research results have been quality-controlled throughout.
The preliminary research involved several COBIT development groups based around the world.
Before being issued, the final texts were distributed to more than 100 specialists, including process owners, business managers and analysts, such as Gartner, to obtain their comments.
Overall, experience shows that the COBIT model appeals to members of business management as a whole; they appreciate the added value of it in view of improving their control over IT. In this regard, ITGI is confident that the required quality level, beyond customer satisfaction, has been achieved, although feedback is always welcomed and considered. Because COBIT development is a continuous improvement process based on real experience by users, there will always be potential improvements to quality and usefulness.

7. What is the future direction of COBIT?

As with any comprehensive and groundbreaking research, COBIT will be updated to a new version approximately every three years, with minor enhancements in between. This will ensure that the model and the framework remain comprehensive and valid. The validation will also entail ensuring that the primary reference materials have not changed, or, if they have, those changes are reflected in the document.

8. How did ISACA/ITGI decide on the list of primary references?

The list of primary references was developed as a collective consensus based on the experience of the professionals who participated in the CSC's research, expert review and quality assurance efforts.

9. Can I use COBIT as a statement of criteria for specific audit conclusions?

Yes, basing the IT Assurance Guide firmly on the control objectives takes the auditor's opinion out of the audit conclusion, replacing it with authoritative criteria. COBIT is based on more than 40 standards and best practices documents for information technology from standards-setting bodies (public and private) worldwide. These include documents from Europe, Canada, Australia, Japan and the United States. Because COBIT contains all pertinent worldwide standards identifiable at the time of publication, it is all-inclusive with respect to IT controls standards. As a result, COBIT can be used as an authoritative source reference document, providing IT controls criteria on audits.

10. Are the control objectives meant to be a minimum level of control or best practice?

IT control objectives are statements of managerial actions to achieve necessary outcomes or purposes to control risk and add value within a particular IT process. They are written as short, action-oriented management practices and expressed wherever possible in a life cycle sequence. Control objectives are complemented by COBIT Control Practices, Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition, which describe a set of management actions designed to attain the outcomes described in the control objective.

Management makes choices relative to control objectives:

Selecting those that are applicable in the enterprise's setting
Determining the cost-benefit ratio of adopting the control objective, including acceptance of the risk of not implementing a control objective
Deciding on the actual control practices and implementing them or choosing alternative management actions to achieve the similar outcomes
Choosing how to implement (frequency, span, resourcing, automation, etc.)

11. What about the absence of platform-specific controls?

The COBIT control objectives are generic in nature and address activities or tasks within IT processes. This way they are platform-independent. However, they are the overall structure wherein more specific platform-related controls are to be defined. In fact, the general control objectives should remain valid regardless of whether one is controlling, for example, a mainframe platform or an office automation platform. It is obvious that certain aspects will require more emphasis in a given environment.

12. Where are the application controls?

The application controls were originally fully integrated in the COBIT model. This option had been taken considering that COBIT is business-process-oriented and that at this level application controls are merely part of the overall controls to be exercised over information systems and related technology. In most cases, however, this part cannot be outsourced. Hence, the question is of prime importance.

Before the publication of COBIT 4.0, there was one process, Manage data, where the traditional transactions and file controls could be found. In COBIT 4.0 the application controls were taken out of DS10 and made part of the COBIT framework using the ACn prefix, because it was decided that they had become accepted as being owned by business process owners and not part of an IT process. With COBIT 4.1, they have been simplified to six key application control objectives, AC1 to 6.

13. Why is there overlap within the control objectives?

Overlap in the control objectives, although not occurring often, was intentional. Some control objectives transcend domains and processes and, therefore, must be repeated to ensure that they exist in each domain or process. Some control objectives are meant to be cross-checks of one another and, therefore, must be repeated to ensure consistent application in more than one domain or process. Thus, although potentially perceived as overlapping, COBIT intentionally repeats some control objectives to ensure appropriate coverage of these IT controls.

14. Are the control objectives linked to the IT Assurance Guide and to what degree?

Objectives have been developed from a process orientation because management is looking for proactive advice on how to address the issue of keeping IT under control. Balancing cost and risk is the next issue to address (i.e., making a conscious choice of how and whether to implement each control objective). The link is the process. The control objectives help management establish control over the process. The IT Assurance Guide testing steps assist the auditor or assessor by providing assurance that the process is actually under control, such that the information requirements necessary to achieve business objectives will be satisfied. In reference to the control framework represented by the waterfall model, the testing steps can be seen as providing the feedback from the control processes back to the business objectives. The control objectives are the guide going down the waterfall to get the IT process under control. The IT Assurance Guide testing steps are the guide for going back up the waterfall with the question: ‘Is there assurance that the business objective will be achieved?'; The 2007 IT Assurance Guide provides specific tests at the process and control objective level, whereas the previous Audit Guidelines provided tests at only the process level.

15. Why are there no risk statements with the control objectives?

The provision of risk statements was seriously considered and investigated during the research and review phase of the initial COBIT project, but not retained because management preferred the proactive approach (objects are to be achieved) over the reactive approach (risks are to be mitigated). The risk approach comes in at the end of the IT Assurance Guide when the risk of not implementing the controls is substantiated. In the application of COBIT, the risk approach is certainly useful when management decides which controls to implement or when auditors decide which control objectives to review. Both of these decisions depend entirely on the risk environment. In the management guidelines the goals and metrics can be used as risk indicators by considering their absence or lack of positive outcomes. Also, the control practices provide risk and value statements at the control objective level, indicating the risks of not implementing a control objective and the value of improving the control.

16. What training is available for the use of COBIT?

ISACA has developed and is continually enhancing it education and training portfolio supporting COBIT.

Online offerings at www.isaca.org/elearning:

COBIT Foundation Course™ (to be launched mid April 2010)
COBIT Foundation Examination™

Classroom offerings:

COBIT Foundation Course™ with associated COBIT Foundation Examination™ at www.isaca.org/cobittraining
Implementing IT Governance using COBIT™ and Val IT (previously titled “COBIT Implementation Course”) at www.isaca.org/cobittraining
COBIT training is also available through the ISACA On-site Training program at www.isaca.org/onsitetraining
ISACA’s Training Week program includes the COBIT Strategies for Implementing IT Governance course. For more information go to www.isaca.org/trainingweek

17. Who in my organization should go to the training?

COBIT training should be attended by management, IS and audit managers, IT professionals, business process managers, and quality assurance and audit professionals.

18. What is the level of training required?

The amount and level of training necessary is a function of how comfortable one feels with the product; however, practical experience has shown that successful implementation is directly related to the amount of COBIT knowledge acquired. Therefore, training is considered to be very important but the training also has to be properly and correctly provided, which is why ISACA developed a portfolio of courses. The IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition, and the IT Assurance Guide provide valuable support following attendance at training courses.

19. In what way can I suggest to IT management that it use COBIT?

Because COBIT is business-oriented, using it to understand IT control objectives to deliver IT value and manage IT-related business risks is straightforward:

Start with business objectives in the framework.
Select the IT processes and control objectives appropriate to the enterprise from the control objectives.
Operate from the business plan.
Assess the status of the organization, identify critical activities leading to success and measure performance in reaching enterprise goals with the management guidelines.
Assess procedures and results with the IT Assurance Guide.

20. Is the COBIT framework superior to the other accepted control models?

Most senior managers are aware of the importance of the general control frameworks with respect to their fiduciary responsibility, such as COSO, Cadbury, CoCo or King II; however, they may not necessarily be aware of the details of each. In addition, management is increasingly aware of the more technical security guidance such as ISO 17799, and service delivery guidance such as ITIL. Although the aforementioned models emphasize business control and IT security and service issues, only COBIT attempts to deal with IT-specific control issues from a business perspective. It should be noted that COSO was used as source material for the business model and ISO 17799 and ITIL, amongst many others, were used to develop the control objectives. COBIT is not meant to replace any of these control models. It is intended to emphasize what control is required in the IT environment while working with and building on the strengths of these other control models.

21. What is the quickest and best way to sell COBIT to IT managers?

As we all know, there is no cavalry to come to the rescue. As the rest of the implementation tools point out, the organizational culture is vitally important. A proactive culture will be more receptive than one that is not. However, consider emphasizing the business aspects and the fact that COBIT does not get lost in technical terminology. Furthermore, point out that COBIT was designed the way an IT manager thinks, and one of its greatest benefits is that everything is documented in one place.

With the addition of the management guidelines, COBIT provides management with new capabilities to support self-assessment of organizational status, comparison with industry good practices, alignment with enterprise objectives, implementation decision making and performance monitoring. The maturity models, key goal indicators and key performance indicators provided in these guidelines can assist management in better aligning IT with the overall enterprise strategy by ensuring that IT is an enabler of the enterprise goals.

22. Since COBIT currently does not address associated business risks, but rather the more proactive control statements to be achieved, is there any consideration being given to address the perceived need of risk identification?

Risk is addressed in a pervasive manner throughout COBIT and even more so with the advent of the management guidelines. A major driver of the control and assurance processes is the IT governance model that is now covered extensively in COBIT and the management guidelines framework.

IT governance refers to the generic enterprise objectives of measuring benefits and managing risk. The same idea, risk management as an enterprise objective, was nevertheless already captured by COBIT earlier, because COBIT states that IT needs to provide information to the enterprise that must have the required characteristics to enable the achievement of enterprise objectives. While the security-related criteria of availability, integrity and confidentiality may be more readily associated with risk, not achieving enterprise objectives or not providing the required criteria is a risk that the enterprise needs to control.

Specific examples have been provided in the 'substantiating'; section of the IT Assurance Guide. The objective of that section is to document for management what can or has happened as a result of not having effective control in place. More practically, one entire process was defined to cover the assessment of risk. (See PO9 Assess and manage IT risks.)

Risk is addressed in the framework in a proactive manner, i.e., by focusing on objectives, because the primary risk that needs to be managed is that of not achieving the objectives. The section on documenting the impact of control weaknesses of the IT Assurance Guide provides examples of these risks for each process. This provides for the risk information for which the control and assurance professional is looking. A whole IT process is dedicated to the assessment of risk in the overall set of IT objectives.

23. Has the COBIT framework been accepted by CIOs?

Yes, it has been accepted in many organizations globally, and new cases continue to be documented. However, it should not surprise anyone that in those entities where the CIO has embraced COBIT as a usable IT framework, this has come as a direct consequence of one or more COBIT champions within the audit and/or IT department(s). Even more important than acceptance by the CIO is acceptance by the board and executive management. Successful implementation of IT governance using COBIT depends greatly on the commitment of top management.

The addition of the management guidelines should also increase the acceptance of COBIT by enterprise and IT management. The emphasis on alignment of IT with enterprise goals, self-assessment and performance measurement will ensure that COBIT is seen not only as a control framework, but also as providing a set of tools for improving the effectiveness of information and IT resources. The integration of the management guidelines with the COBIT framework and control objectives provide additional emphasis for management to use COBIT as the authoritative, up-to-date and established model for IT control and governance.

24. How are the management guidelines integrated into the COBIT framework?

Starting with the COBIT framework, the application of international standards and guidelines and research into good practices led to the development of the control objectives. Management needed a similar application of the framework to allow self-assessment and choices to be made for control implementation and improvements over its information and related technology.

The management guidelines provide the tools to accomplish this. They were developed for each of the 34 IT processes, with a management and performance measurement perspective. Maturity models, goals and metrics, and roles and responsibilities (RACI) charts are provided by the guidelines to support management decision-making processes.

With COBIT 4.0 the management guidelines were integrated and positioned together with the control objectives in one complete publication, to give users a single complete source.

25. The COBIT framework states that the COBIT maturity models are derived from the SEI Capability Maturity Model (CMM). What is the actual relationship between COBIT and CMM?

The maturity models (MMs) in COBIT were first created in 2000 and at that time were designed based on the original CMM scale with the addition of an extra level (0) as shown below:

Level 0: Non-existent
Level 1: Initial/ad hoc
Level 2: Repeatable but Intuitive
Level 3: Defined Process
Level 4: Managed and Measurable
Level 5: Optimized

The use of this scale is the only relationship to CMM, as it was felt that the CMM approach, designed for rigorous software development environments, was not appropriate for COBIT where the approach is at a strategic level and focused on high-level IT management processes.

The purpose of the COBIT MMs is to provide a management tool enabling benchmarking and targeting of desired process maturity levels and to encourage process improvement via gap analysis. Although concepts of the CMM approach were followed, the COBIT implementation differs considerably from the original CMM, which was oriented toward software product engineering principles, organizations striving for excellence in these areas and formal appraisal of maturity levels so that software developers could be ‘certified';

A generic definition was created for the COBIT MM scale, which is similar to CMM but interpreted for the nature of COBIT's processes. A specific model was then developed from this generic scale for each of COBIT's 34 processes. A maturity attribute generic scale was also developed, using six attributes. This scale was not based on any CMM concepts but was created by the COBIT expert development team.

Since 2000, the COBIT MMs and maturity attributes have been refined and adjusted based on experience and feedback. The SEI discontinued the original CMM and replaced it with a new model called CMMI. CMMI has not been used in the development of the COBIT MMs.

26. Do I need to meet an exact level when assessing a process using COBIT's maturity models, and does this differ from the original CMM approach?

The main purpose of the COBIT maturity models is to give management a tool to help them better understand the current capability of IT management processes, do benchmarking, gap analysis and improvement planning.

With COBIT's maturity models, unlike the original SEI CMM approach, there is no intention to measure levels precisely or try to certify that a level has exactly been met. It is also not strictly true in COBIT that a lower level must be fully complied with before higher levels of maturity can be reached, as in CMM. A COBIT maturity assessment is likely to result in a profile where conditions relevant to several maturity levels will be met, as shown in figure 1.

This is because when assessing maturity is often the case that some implementation is in place at different levels even if it is not complete or sufficient. These strengths can be built on to further improve maturity. For example, some parts of the process can be well defined and, even if the process is incomplete, it would be misleading to say the process is not defined at all.

Furthermore, if the six generic maturity attributes defined in COBIT are also assessed to give a more detailed analysis, it is quite likely that each attribute may be at a different level, too (e.g., policies, standards and procedures may be defined, but goal setting and measurement may be ad hoc).

It is, therefore, best to choose a level based on the "closest fit," while appreciating and understanding the positive things that have been implemented as well as the gaps that need to be improved. In the example, the process would be said to be at level 3. It would also be misleading and imply an unreal level of precision to describe the process as being at, say, level 2.9.

In COBIT the important objective is to understand what level is appropriate for a given process, based on business requirements, and to understand the nature of any gaps, so that any significant weaknesses in the process can be identified and improved. Guidance on this approach is provided in the IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition.

27. COBIT has three dimensions of maturity. What do they mean?

The three dimensions, as explained in the COBIT framework, are capability, performance and control. They can be used to be more precise when assessing maturity for a given IT process in a specific situation. The application of these dimensions is left to the COBIT user to decide depending on how detailed and precise the maturity assessment needs to be and the scope of the assessment target area.

Capability is the level of maturity required in the process to meet business requirements (ideally driven by clearly defined business and IT goals). The COBIT maturity models focus on capability and help an enterprise recognize the capability that best fits specific process requirements.

Coverage is a measure of performance, i.e., how and where the capability needs to be deployed based on business need, and investment decisions based on costs and benefits. For example, a high level of security may have to be focused upon only for the most critical enterprise systems.

Control is a measure of actual control and execution of the process, in managing risks and delivering the value expected in line with business requirements and risk appetite. A process may appear to be at the right capability level with the right management characteristics, but still fail because of an inadequate control design. This is an assessment against the COBIT control objectives considered necessary for the process. COBIT provides a generic maturity model for internal control, and processes PO6 and ME2 help institutionalize the need for good controls.

Given the above, it is possible to use all of these dimensions to carry out a detailed assessment of maturity for a specific critical area, for example, security of a banking application, or the overall change management process. At a high level they can also be used to provide an overall and thorough assessment of the maturity of a process by considering all three dimensions in the context of the overall business requirement.

28. How do you perform a COBIT-based maturity assessment?

The reality is that probably no two COBIT maturity assessments are performed in exactly the same manner. COBIT provides some tools and techniques, and the COBIT user will follow an approach based on specific enterprise needs. The assessments can be high-level, often in a workshop discussion, or detailed with careful gap analysis.

Generically, the following common principles usually apply:

The maturity requirements should be driven by business requirements ideally expressed as business and IT goals.
The requirements depend on the scope being considered and can be very specific for a particular scope or high-level if the scope is for the enterprise as a whole.
The maturity models help assess capability (defined in COBIT to mean how well the process is being managed in comparison to the COBIT maturity models and attributes).
The maturity attributes can be used to analyze current maturity levels in detail and are required to do a proper gap analysis.
COBIT's control objectives provide a way to measure how well the process addresses key controls needed to minimize risk and deliver value.
COBIT's control practices can be used to help design improved processes and to increase process maturity, together with other industry standards and best practices.
It is recommended that that the maturity attributes be used to assess at a detailed level and to carry out a gap analysis, so that the root causes of immaturity can be identified and business decisions can be taken on where to invest to improve maturity for least cost and maximum benefit. IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition, provides a road map that includes guidance on the above steps.

29. How prescriptive are the COBIT maturity models and supporting guidance, and how does this compare to the CMM/CMMI approach?

The MMs in COBIT , like all the COBIT guidance, are intended to be tailored and developed to suit the specific needs of the enterprise. The guidance is also at a high level with the intention that it provides generic guidance, not specific, detailed criteria. In particular, the maturity attributes are very generic and high-level, intended to be a simple guide for any process. When performing a COBIT maturity assessment, specific attribute details will need to be identified for the process under review, and compared to COBIT's control objectives, control practices, and goals and metrics to the desired level of detail. COBIT does not prescribe the assessment approach, which is a management decision, ranging from a high-level workshop discussion to an in-depth analysis, as appropriate, driven by business needs.

In CMM/CMMI, although the guidance would always need to be tailored for a given appraisal situation, the standard guidance is much more specific and detailed, due to its much narrower focus on software product delivery and more formal appraisal/assessment procedure.

30. The CMMI maturity levels appear to be different to the COBIT maturity levels. Is this true?

Yes, CMMI uses the following scale:

Level 0: Incomplete
Level 1: Performed
Level 2: Managed
Level 3: Defined
Level 4: Quantitatively Managed
Level 5: Optimizing

COBIT's scale differs:

Level 0: Non-existent

Level 1: Initial/ad hoc
Level 2: Repeatable but Intuitive
Level 3: Defined Process
Level 4: Managed and Measurable
Level 5: Optimized

There is no direct relationship between these two scales. The COBIT scale was based on the original CMM scale and has remained the same since the first version of the COBIT maturity models were released in 2000. There was never any intention to align the models exactly with CMM or CMMI when it was introduced, or to try to maintain any such alignment, as COBIT's maturity modeling approach is based on different objectives to the Software Engineering Institute's (SEI's) objectives.

COBIT's models provide management with a self-assessment tool for positioning IT process capability in comparison to business requirements, and as a tool for gap analysis and improvement planning, taking into account the required capability driven by business requirements (business and IT goals), control requirements (control objectives) and performance (how much and where to implement, driven by costs and benefits).

CMMI provides a rigorous, objective and repeatable assessment, and fulfils the needs of organizations requiring certifications to meet contractual needs, or needing to demonstrate development engineering capabilities of a high maturity for customers where software development is critical.

31. Is it really possible to benchmark my maturity levels with other organizations if the maturity assessments are not very precisely measured?

Yes, even though COBIT's maturity levels are not intended to be measured precisely, the levels give a good guide to management. Even when an approximate assessment is carried out, for example, in a management workshop, the level selected is usually a sound reflection of the actual level. Benchmark comparisons provided in COBIT Online from user input and from surveys are helpful to managers for comparing their organization to others. The data collected have also empirically validated the broad nature of the actual measures—there are few "unusual" scores, IT processes even in large and significant enterprises are generally not well developed in most IT functions, and most organizations have COBIT-defined process maturity that is relatively low, i.e., between levels 2 and 3.

32. Are COBIT's maturity models useful to organizations that have already adopted CMMI?

Yes, even though the approaches are different, an enterprise that has already adopted and applied CMMI can use COBIT to cover areas not addressed by CMMI, and will be able to use the CMMI experience to apply COBIT's models to whatever formal level they require, in areas not covered by the scope that was defined for the CMMI assessment. For example, an advanced software development shop could broaden its maturity assessment to apply it to their entire IT function, including other important COBIT IT processes. The mapping publication, available from the ITGI, showing how COBIT compares to CMMI, would be a very helpful resource, but the enterprise would need to devise its own CMMI-like assessment approach using COBIT's generic guidance as a starting point, or follow the suggested approach in the ITGI publication—IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition. In time, it is expected that the CMMI guidance will broaden into other areas such as service management, which would be equivalent to the ITIL processes and principally the COBIT DS domain.

33. Since the four COBIT resource types (applications, information, infrastructure and people) apply to each of the COBIT processes, why are some indicated and others not in the Process Descriptions?

COBIT identifies the most important resources the process owner should focus on in terms of control, management and governance. Of course somewhere every process relates to all resources but then we would have to mark every resource for every process, and then we would not add value.

TOGAF

What is "TOGAF Certification" About?

The Open Group has introduced a certification program for TOGAF, presently Versions 8.1 - its industry standard architecture framework and method.

TOGAF Certification is for both individuals and organizations. Individuals can become certified by demonstrating their knowledge of TOGAF either by attending a training course or passing an examination test. Organizations can have their products (TOGAF Tools or Training Courses), and services certified.

Customers who wish to base their IT architecture work on the open, industry standard TOGAF method can now procure tools, training, and the services of consultants (individuals and integrators) on the basis of certified conformance with TOGAF standards.

Why is This Important?

IT Architecture is acquiring increasing recognition as a necessary discipline for ensuring that the design and implementation of enterprise-wide IT properly addresses and supports the needs of the business. TOGAF is an open, industry standard framework and method for IT Architecture, developed and continuously evolved since the mid-90's by representatives of some of the world's leading IT customer and vendor organizations.

The introduction of a certification program for TOGAF enables large organizations (both private and public sector) to standardize on this open method for IT Architecture, and so avoid lock-in to the proprietary methods of major consultancies.

It is an important step in making IT Architecture a well-recognized discipline, and in introducing rigor into the procurement of tools and services for IT Architecture.

Why Become Certified?

The TOGAF certification program licenses the use of the term "TOGAF 8" together with The Open Group Certification Mark in association with Certified Offerings. This provides the necessary legal framework to maintain the value of TOGAF to enterprise customers. The value to licensees is the ability to use the term "TOGAF " together with The Open Group Certification Mark in association with products and/or services that support the TOGAF framework and its Architecture Development Method.

In addition, The Open Group publishes and publicizes the definitive register of TOGAF certified offerings, and issues certificates that can be used by the vendor in promotion.

Individuals are also entitled to membership of the Association of Enterprise Architects (AEA) at no additional cost

What Does this Mean for IT Users?

The value to customers is the knowledge that the vendor has made a legally binding warranty of conformance with the Product Standards referenced in the Certification Program - a warranty that requires compliance not only at the time of registration, but throughout the lifetime of the product or service offering, for as long as it remains registered.

Customers can therefore procure TOGAF based product and service offerings safe in the knowledge that the vendors concerned have taken a professional and commercially responsible approach to the supply of these offerings to the market; and furthermore, have completed a detailed Statement of Conformance, which the procurer can access freely and compare with those of other certified vendors, if they wish.

How does This Tie in with the Objectives of The Open Group?

IT Architecture is regarded by The Open Group as a key discipline for organizations to use in realizing the Boundaryless Information Flow vision, the enablement of which is The Open Group's mission.

How long does Certification Last?

It lasts for up to 24 months. In some cases, for classes of certification dependent on an annual Commercial TOGAF license then the initial certification will be synchronized with the license renewal date.

How do I get TOGAF Certified as an Individual?

There are two routes for TOGAF 8.1 . Either by passing an examination, or by attending a qualifying training course.

Registering to take the TOGAF Examination

Prometric administers the TOGAF 8 Certification exam (OG0-081). The exam is available at any authorized Prometric testing center around the world. If calling within North America, contact Prometric at (800) 755-EXAM (755-3926). Outside the United States and Canada, contact your local Prometric

What is the format of the TOGAF Examination?

The exam comprises 101 multiple-choice questions which must be completed within 2 hours. .

The 6 Topic Areas covered by the examination together with the approximate percentage of the number of questions in the exam follows:

1. TOGAF8 Architecture Development Method (ADM) - Process (50%)

2. TOGAF8 Architecture Development Method (ADM) - Information Sets (25%)

3. TOGAF Foundation Architecture (5%)

4. The Enterprise Continuum (8%)

5. TOGAF and Other Architectures / Frameworks (4%)

6. Architecture Governance (8%)

What do I need to bring with me to take the Exam?

Check the requirements with Prometric.

How much does it cost to take the Examination?

Certification exams are priced according to currency values in specific countries and regions. The TOGAF 8 certification exam costs $400 US per exam. Certification exam prices are subject to change. In some countries and regions, additional taxes may apply. Contact your test registration center for exact pricing.

Can I refer to materials while i take the exam?

No its a closed book examination.

How long after taking the exam does it take to get the result?

You will be informed by Prometric at the time of completing the examination.

Can I find out my score?

Yes, this is part of the test report supplied by Prometric.

Will I get a certificate?

Yes, once you have passed the examination, Prometric will send your details to The Open Group, who will then contact you by electronic mail with account information to login to The Open Group web server to complete your certification. Once you accept the logo usage agreement you become certified and will be able to download your certificate and certified logos, and have an entry on the certification register.

If I Fail how soon can I resit?

An individual who has failed an examination will not be allowed to retake the

Are there materials available to help prepare for the Exam?

Yes as well as the syllabus, The Open Group has a version of TOGAF 8.1 and a Study Guide available for purchase, and there are a number of third party organizations who offer training see the Certification Register for more details.

How long does the certification process take?

For course attendance the minimum duration is 4 days or 28 hours of study for distance learning. The examination takes 2 hours.

Assuming a complete submission the certification authority has the following service level targets to complete 80% of complete and correct submissions as follows:

TOGAF Certified - 6 Working Days
Other Classes - 10 Working Days

100% of all complete and correct submissions will be processed within 12 working days. If an incomplete or incorrect submission is received, the clock is suspended until the missing or corrected parts are received.

I've changed my contact details and affiliation, who should I notify?

You should notify the TOGAF Certification Authority team (togaf-cert-admin(at)opengroup.org.

Why do I need to renew my certification?

Continued rights to use the TOGAF Certified logo.

Conitinued Entitlement to membership of the Association of Open Group Enterprise Architects (AOGEA) at no additional cost (www.aogea.org); AOGEA is the professional association for Enterprise Architects.

Continued inclusion in the register of certified practitioners. Employers are increasingly seeking TOGAF certified practitioners and will check the register for proof.

How do I renew my certification?

You have a choice regarding how you renew: as an individual, through your employer or through a TOGAF(tm) certified training provider.

Renewal is for a further two year period. You can renew early or in the 30 day grace period, in either case the additional certification period will be added to the date on which your certification would have expired.

In all cases you will be contacted by The Open Group at about 60 days before renewal is due. You will also be contacted again within 30 days of renewal and once more within 30 days after renewal was due. For this reason its important you notify the Certification Authority of any changes to your email address.

Renewal by an Individual:

In order to renew your TOGAF Certified as an individual for a further two year period you are required to pay a $300 fee. You will be emailed at 60 days and 30 days in advance. A URL will be provided for you to do so. This allows you to pay your renewal fee online. Once payment is complete you will receive a receipt, and typically within 3 working days your status will be renewed and notification sent to you of where to download your latest certificate.

Renewal through your Employer:

If your employer wishes to pay for renewal of a batch of two or more certified individuals, please have your company administrator contact the TOGAF Certification Authority as soon as possible. The fee bands for batch renewals are detailed on the Fee Schedule at http://www.opengroup.org/togaf/cert/Fee_Schedule.html and are based on the total number of certified individuals your employer has on the register at renewal time. Payment must be received before the first renewal date in the batch. The minimum batch size is two individuals.

Renewal through a Certified Training Provider:

If you wish to have your renewal handled by a certified training provider, then they will need to contact The Open Group and pay for your renewal before the first renewal date in the batch. The fee bands for batch renewals through a Certified Trainer are detailed on the Fee Schedule at http://www.opengroup.org/togaf/cert/Fee_Schedule.html The fee for this case is dependent on the number in the batch that the training provider submits to The Open Group at one time. A batch has to have a minimum of two individuals. You should contact your training provider for more information.

CMMI

The Capability Maturity Model Integration, or CMMI, is a process model that provides a clear definition of what an organization should do to promote behaviors that lead to improved performance. With five “Maturity Levels” or three “Capability Levels,” the CMMI defines the most important elements that are required to build great products, or deliver great services, and wraps them all up in a comprehensive model.

The CMMI helps us understand the answer to the question “how do we know?”

· How do we know what we are good at?

· How do we know if we’re improving?

· How do we know if the process we use is working well?

· How do we know if our requirements change process is useful?

· How do we know if our products are as good as they can be?

The CMMI also helps us identify and achieve measurable business goals, build better products, keep customers happier, and ensure that we are working as efficiently as possible.

CMMI is comprised of a set of “Process Areas.” Each Process Area is intended be adapted to the culture and behaviors of your own company. The CMMI is not a process, it is a book of “whats” not a book of “hows,” and does not define how your company should behave. More accurately, it defines what behaviors need to be defined. In this way, CMMI is a “behavioral model” and well as a “process model.”

Organizations can be “Rated” at a Capability or Maturity Level based on over 300 discreet “Specific” and “Generic” Practices. Intended to be broadly interpreted, the CMMI is not a “Standard” (ala ISO), so achieving a “Level” of CMMI is not a certification, but a “rating.”

Background

The CMMI was developed at the Software Engineering Institute at Carnegie Mellon University with representation from defense, industry, government, and academia, and is now operated and maintained by the, an operating unit of CMU. It is the successor of the popular Software CMM, or SW-CMM. The are multiple “flavors” of the CMMI, called “Constellations,” that include CMMI for Development (CMMI-DEV), CMMI for Services (CMMI-SVC), and CMMI for Acquisition (CMMI-ACQ). The three Constellations share a core set of sixteen Process Areas. There is also a “People CMM,” or P-CMM, that exists outside of the three CMMI Constellations.

CMMI-DEV commands the largest market share, followed by CMMI-SVC, and then CMMI-ACQ.

There are five Maturity Levels in the CMMI

Appraisals

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the appraisal method that is employed by a Certified SCAMPI Lead Appraiser to help your team “achieve a level.” There are three different types of appraisals, called “Classes” and they are SCAMPI A, SCAMPI B, or SCAMPI C. The SCAMPI A is the only appraisal method that results in a Maturity or Capability Level Rating. A SCAMPI C is typically used as a gap analysis and data collection tool, and the SCAMPI B is often employed as a User Acceptance or “test” appraisal. The results of a SCAMPI A Appraisal are published on the CMMI Institute Website known as “PARS” and is available for viewing by the public. Only a Certified SCAMPI Lead Appraiser can conduct a SCAMPI A Appraisal.

There are three classes of Appraisals - only the "Class A" results in a "Rating"

CMMI Architecture

The CMMI for Development has twenty-two process areas, and the CMMI for Services has twenty-four. The CMMI can be used in either the “staged” or “continuous” representation. The staged representation, which groups process areas into five “maturity levels,” is the most common choice, but an organization can also pick and choose the Process Areas that make the most sense for them to work on by using the “continuous representation.”

There is no difference in content between these two representations. When choosing “Staged” an organization follows a pre-defined pattern of process areas that are organized by “Maturity Level.” When choosing continuous, they pick process areas based on their interest in improving only specific areas. In the Continuous representation, Process Areas are organized by “Category.”

Within the Process Areas in the CMMI, there are multiple “Specific Goals (SGs)” and Specific Practices (SPs).” These practices define the expected behaviors of projects and organizations.

There are also twelve “Generic Practices (GPs)” that provide guidance for organizational excellence including behaviors such as setting expectations, training, measuring quality, monitoring process performance, and evaluating compliance.

CMMI and SCAMPI are registered Servicemarks by Carnegie Mellon University

The are twenty-two Process Areas in the CMMI for Development

Organizational Progression

While every organization is different, it is typical to start your CMMI and performance improvement journey with a gap analysis, or “SCAMPI C” Appraisal. The SCAMPI C will give you a practice-by-practice analysis of the entire scope of CMMI, and a set of observations and recommendations for addressing any weaknesses.

This is often followed by “Introduction to CMMI” training, or other training for key individuals, followed by some level of effort to write, modify, align, adopt, or remove process assets. These organizational assets may include process definitions, templates, work instructions, newsletters, reports, training, policies, methods, tools, and more.

When your team is ready to proceed, one or more formal appraisals are conducted – ultimately culminating in a “SCAMPI A” Appraisal and a successful CMMI Rating!

To learn more about CMMI, visit our Amazon Author’s Page to download our eBooks on the CMMI or agile, or contact us today!