TEN important steps for ITIL Implementation

Step 1: ITIL Project Preparation

Step 2: Definition of the IT Service Structure

Step 3: Selection of ITIL Roles and Role Owners

Step 4: Analysis of As-Is Processes: ITIL-Assessment

Step 5: Definition of the To-Be Process Structure

Step 6: Definition of Process Interfaces

Step 7: Establishing Process Control

Step 8: Designing the Processes in Detail

Step 9: Selection and Implementation of Application Systems

Step 10: ITIL Process Implementation and Training

Processes in Service Strategy phase for ITIL

The IT service management framework for ITIL® is logically divided into five phases based on what a provider offers, and the IT service that the customer enjoys and values. The other four phases in ITIL® are service design, service transition, service operations and continual service improvement.

The first of the five phases is the service strategy. In this phase, the strategy to implement a service into an IT organization is closely tied to the management approach for that service.

Let’s say a cell phone provider wants to introduce a new service, such as high-speed internet. In the service strategy phase the stakeholders develop the strategy for what to introduce, how to launch, where to source, how to meet demands and manage operations.

Overview of the service strategy phase

In the service strategy phase, the service provider and the customer define the terms of what the service entails, how will it be of value to the customer, and what type of customers (age groups, genders, geography, etc.) are likely to opt for the service.

In this phase, the high-level strategy is laid out and the feasible services will pass to the service design phase where the conceptual services would be given definite form, figure and dimensions. A number of conceptual services get filtered through the sieve as well.

With a good strategic advisory team in place, organizations can hope to meet a number of goals. Some common ones for organizations include branding with innovative and customer-focused services, annulling the competition and showing ROI on their IT investments.

Processes in the service strategy phase

To achieve all that I have mentioned under the strategic management, ITIL® has developed a few processes to aid the aims of a service strategy.

Process 1: Service portfolio management

Service portfolio management ensures that the organization has the right set of services to offer to its customers. It also ensures that customers perceive the offered services as valuable so the organization makes a balanced return on investment.

The service portfolio management process involves researching and identifying the services that can be offered to customer. Here, the riders are the return on investment and the risk appetite. Once a list is drawn up, they track how the service performs, how it’s perceived and check whether the service fits into the overall scheme of things. The service portfolio also consists of the services that once existed but have been retired and/or replaced.

The output of the service portfolio management process is the service portfolio itself, which consists of three components:

  • Existing services
  • Services in pipeline
  • Retired services

The existing services consist of all that is being offered to customers, similar to a menu card that you find in a restaurant. Services in pipeline are those services that are under development. At times, it is important that customers are lured in with the services that they can enjoy in the future. For example, a cell phone service provider can claim that they offer 3G internet service, and within the next 6 months the customer can expect to use the 4G service that’s under testing.

Process 2: Financial Management for IT Services

As the name of the process indicates, the financial management for IT services aids in bringing in the investors, and channeling investments to services that have the most potential.

When a new service is to be introduced, or if an existing service needs an upgrade, this process starts by evaluating the financial impact. This usually involves convincing investors secure the funding for the provision of the services.

Other aspects of finances, such as budgeting for a service, accounting for how money was spent and charges for the customer’s use of services, all fall under the financial management process. Balancing income and outflow and forecasting financial requirements are some of the other activities that are performed in this process.

Process 3: Business Relationship Management

You can own top-notch services, but if you can’t keep your customers loyal to you, then the organization might start looking to close down the shop and consider alternatives. Business relationship management is a new introduction to ITIL® which deals with building customers relationships through value proposition and meeting their business needs.

Many case studies over the years have pointed to the conclusion that it costs a lot more to bring in new customers than to keep existing ones. To keep customers, organizations must hear the pulse of the customer; understand how the customer views your organization and the services you offer. The Business relationship management process looks at all these aspects of retaining customers and more.

The business relationship management process specifically focuses on the customer requirements and working within the organization to meet the customer goals. The process keeps tabs on the customer’s perception towards the IT organization and works to keep it positive.

This process does not deal with the customer at an operational level or on an incident basis, but rather on a level where the governance body is seated. There is a sister process in the service design phase called as service level management, which is responsible for interacting with the customer regularly over the performance of its services and making sure service level agreements are adhered to.

Outflow from Service Strategy

The output from service strategy provides direction to all other phases in the ITIL® framework. People in organizations who form service strategy are generally the board members, CXOs and others with a mature head on their shoulders.

The decisions taken by the board and senior management percolate to various nooks and corners of the organization and bears on how the services are run and what the customers can expect. An organization gifted with a strong strategic team is an organization that focuses on the right credentials to go the distance, and win.

Enterprise Architecture Principles…..

Business Principles

Principle 1:
Primacy of Principles
These principles of information management apply to all organizations within the enterprise.
The only way we can provide a consistent and measurable level of quality information to decision-makers is if all organizations abide by the principles.
  • Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of information.
  • Information management initiatives will not begin until they are examined for compliance with the principles.
  • A conflict with a principle will be resolved by changing the framework of the initiative.
Principle 2:
Maximize Benefit to the Enterprise
Information management decisions are made to provide maximum benefit to the enterprise as a whole.
This principle embodies “service above self”. Decisions made from an enterprise-wide perspective have greater long-term value than decisions made from any particular organizational perspective. Maximum return on investment requires information management decisions to adhere to enterprise-wide drivers and priorities. No minority group will detract from the benefit of the whole. However, this principle will not preclude any minority group from getting its job done.
  • Achieving maximum enterprise-wide benefit will require changes in the way we plan and manage information. Technology alone will not bring about this change.
  • Some organizations may have to concede their own preferences for the greater benefit of the entire enterprise.
  • Application development priorities must be established by the entire enterprise for the entire enterprise.
  • Applications components should be shared across organizational boundaries.
  • Information management initiatives should be conducted in accordance with the enterprise plan. Individual organizations should pursue information management initiatives which conform to the blueprints and priorities established by the enterprise. We will change the plan as we need to.
  • As needs arise, priorities must be adjusted. A forum with comprehensive enterprise representation should make these decisions.
Principle 3:
Information Management is Everybody’s Business
All organizations in the enterprise participate in information management decisions needed to accomplish business objectives.
Information users are the key stakeholders, or customers, in the application of technology to address a business need. In order to ensure information management is aligned with the business, all organizations in the enterprise must be involved in all aspects of the information environment. The business experts from across the enterprise and the technical staff responsible for developing and sustaining the information environment need to come together as a team to jointly define the goals and objectives of IT.
  • To operate as a team, every stakeholder, or customer, will need to accept responsibility for developing the information environment.
  • Commitment of resources will be required to implement this principle.
Principle 4:
Business Continuity
Enterprise operations are maintained in spite of system interruptions.
As system operations become more pervasive, we become more dependent on them; therefore, we must consider the reliability of such systems throughout their design and use. Business premises throughout the enterprise must be provided with the capability to continue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop enterprise activities. The enterprise business functions must be capable of operating on alternative information delivery mechanisms.
  • Dependency on shared system applications mandates that the risks of business interruption must be established in advance and managed. Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or designing mission-critical services to assure business function continuity through redundant or alternative capabilities.
  • Recoverability, redundancy, and maintainability should be addressed at the time of design.
  • Applications must be assessed for criticality and impact on the enterprise mission, in order to determine what level of continuity is required and what corresponding recovery plan is necessary.
Principle 5:
Common Use Applications
Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization.
Duplicative capability is expensive and proliferates conflicting data.
  • Organizations which depend on a capability which does not serve the entire enterprise must change over to the replacement enterprise-wide capability. This will require establishment of and adherence to a policy requiring this.
  • Organizations will not be allowed to develop capabilities for their own use which are similar/duplicative of enterprise-wide capabilities. In this way, expenditures of scarce resources to develop essentially the same capability in marginally different ways will be reduced.
  • Data and information used to support enterprise decision-making will be standardized to a much greater extent than previously. This is because the smaller, organizational capabilities which produced different data (which was not shared among other organizations) will be replaced by enterprise-wide capabilities. The impetus for adding to the set of enterprise-wide capabilities may well come from an organization making a convincing case for the value of the data/information previously produced by its organizational capability, but the resulting capability will become part of the enterprise-wide system, and the data it produces will be shared across the enterprise.
Principle 6:
Compliance with Law
Enterprise information management processes comply with all relevant laws, policies, and regulations.
Enterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements that lead to changes in policies and regulations.
  • The enterprise must be mindful to comply with laws, regulations, and external policies regarding the collection, retention, and management of data.
  • Education and access to the rules. Efficiency, need, and common sense are not the only drivers. Changes in the law and changes in regulations may drive changes in our processes or applications.
Principle 7:
IT Responsibility
The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user-defined requirements for functionality, service levels, cost, and delivery timing.
Effectively align expectations with capabilities and costs so that all projects are cost-effective. Efficient and effective solutions have reasonable costs and clear benefits.
  • A process must be created to prioritize projects.
  • The IT function must define processes to manage business unit expectations.
  • Data, application, and technology models must be created to enable integrated quality solutions and to maximize results.
Principle 8:
Protection of Intellectual Property
The enterprise’s Intellectual Property (IP) must be protected. This protection must be reflected in the IT architecture, implementation, and governance processes.
A major part of an enterprise’s IP is hosted in the IT domain.
  • While protection of IP assets is everybody’s business, much of the actual protection is implemented in the IT domain. Even trust in non-IT processes can be managed by IT processes (email, mandatory notes, etc.).
  • A security policy, governing human and IT actors, will be required that can substantially improve protection of IP. This must be capable of both avoiding compromises and reducing liabilities.
  • Resources on such policies can be found at the SANS Institute (www.sans.org/newlook/home.php).

Data Principles

Principle 9:
Data is an Asset
Data is an asset that has value to the enterprise and is managed accordingly.
Data is a valuable corporate resource; it has real, measurable value. In simple terms, the purpose of data is to aid decision-making. Accurate, timely data is critical to accurate, timely decisions. Most corporate assets are carefully managed, and data is no exception. Data is the foundation of our decision-making, so we must also carefully manage data to ensure that we know where it is, can rely upon its accuracy, and can obtain it when and where we need it.
  • This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. The implication is that there is an education task to ensure that all organizations within the enterprise understand the relationship between value of data, sharing of data, and accessibility to data.
  • Stewards must have the authority and means to manage the data for which they are accountable.
  • We must make the cultural transition from “data ownership” thinking to “data stewardship” thinking.
  • The role of data steward is critical because obsolete, incorrect, or inconsistent data could be passed to enterprise personnel and adversely affect decisions across the enterprise.
  • Part of the role of data steward, who manages the data, is to ensure data quality. Procedures must be developed and used to prevent and correct errors in the information and to improve those processes that produce flawed information. Data quality will need to be measured and steps taken to improve data quality – it is probable that policy and procedures will need to be developed for this as well.
  • A forum with comprehensive enterprise-wide representation should decide on process changes suggested by the steward.
  • Since data is an asset of value to the entire enterprise, data stewards accountable for properly managing the data must be assigned at the enterprise level.
Principle 10:
Data is Shared
Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations.
Timely access to accurate data is essential to improving the quality and efficiency of enterprise decision-making. It is less costly to maintain timely, accurate data in a single application, and then share it, than it is to maintain duplicative data in multiple applications. The enterprise holds a wealth of data, but it is stored in hundreds of incompatible stovepipe databases. The speed of data collection, creation, transfer, and assimilation is driven by the ability of the organization to efficiently share these islands of data across the organization.Shared data will result in improved decisions since we will rely on fewer (ultimately one virtual) sources of more accurate and timely managed data for all of our decision-making. Electronically shared data will result in increased efficiency when existing data entities can be used, without re-keying, to create new entities.

  • This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. The implication is that there is an education task to ensure that all organizations within the enterprise understand the relationship between value of data, sharing of data, and accessibility to data.
  • To enable data sharing we must develop and abide by a common set of policies, procedures, and standards governing data management and access for both the short and the long term.
  • For the short term, to preserve our significant investment in legacy systems, we must invest in software capable of migrating legacy system data into a shared data environment.
  • We will also need to develop standard data models, data elements, and other metadata that defines this shared environment and develop a repository system for storing this metadata to make it accessible.
  • For the long term, as legacy systems are replaced, we must adopt and enforce common data access policies and guidelines for new application developers to ensure that data in new applications remains available to the shared environment and that data in the shared environment can continue to be used by the new applications.
  • For both the short term and the long term we must adopt common methods and tools for creating, maintaining, and accessing the data shared across the enterprise.
  • Data sharing will require a significant cultural change.
  • This principle of data sharing will continually “bump up against” the principle of data security. Under no circumstances will the data sharing principle cause confidential data to be compromised.
  • Data made available for sharing will have to be relied upon by all users to execute their respective tasks. This will ensure that only the most accurate and timely data is relied upon for decision-making. Shared data will become the enterprise-wide “virtual single source” of data.
Principle 11:
Data is Accessible
Data is accessible for users to perform their functions.
Wide access to data leads to efficiency and effectiveness in decision-making, and affords timely response to information requests and service delivery. Using information must be considered from an enterprise perspective to allow access by a wide variety of users. Staff time is saved and consistency of data is improved.
  • This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. The implication is that there is an education task to ensure that all organizations within the enterprise understand the relationship between value of data, sharing of data, and accessibility to data.
  • Accessibility involves the ease with which users obtain information.
  • The way information is accessed and displayed must be sufficiently adaptable to meet a wide range of enterprise users and their corresponding methods of access.
  • Access to data does not constitute understanding of the data. Personnel should take caution not to misinterpret information.
  • Access to data does not necessarily grant the user access rights to modify or disclose the data. This will require an education process and a change in the organizational culture, which currently supports a belief in “ownership” of data by functional units.
Principle 12:
Data Trustee
Each data element has a trustee accountable for data quality.
One of the benefits of an architected environment is the ability to share data (e.g., text, video, sound, etc.) across the enterprise. As the degree of data sharing grows and business units rely upon common information, it becomes essential that only the data trustee makes decisions about the content of data. Since data can lose its integrity when it is entered multiple times, the data trustee will have sole responsibility for data entry which eliminates redundant human effort and data storage resources.

A trustee is different than a steward – a trustee is responsible for accuracy and currency of the data, while responsibilities of a steward may be broader and include data standardization and definition tasks.

  • Real trusteeship dissolves the data “ownership” issues and allows the data to be available to meet all users’ needs. This implies that a cultural change from data “ownership” to data “trusteeship” may be required.
  • The data trustee will be responsible for meeting quality requirements levied upon the data for which the trustee is accountable.
  • It is essential that the trustee has the ability to provide user confidence in the data based upon attributes such as “data source”.
  • It is essential to identify the true source of the data in order that the data authority can be assigned this trustee responsibility. This does not mean that classified sources will be revealed nor does it mean the source will be the trustee.
  • Information should be captured electronically once and immediately validated as close to the source as possible. Quality control measures must be implemented to ensure the integrity of the data.
  • As a result of sharing data across the enterprise, the trustee is accountable and responsible for the accuracy and currency of their designated data element(s) and, subsequently, must then recognize the importance of this trusteeship responsibility.
Principle 13:
Common Vocabulary and Data Definitions
Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users.
The data that will be used in the development of applications must have a common definition throughout the Headquarters to enable sharing of data. A common vocabulary will facilitate communications and enable dialogue to be effective. In addition, it is required to interface systems and exchange data.
  • We are lulled into thinking that this issue is adequately addressed because there are people with “data administration” job titles and forums with charters implying responsibility. Significant additional energy and resources must be committed to this task. It is key to the success of efforts to improve the information environment. This is separate from but related to the issue of data element definition, which is addressed by a broad community – this is more like a common vocabulary and definition.
  • The enterprise must establish the initial common vocabulary for the business. The definitions will be used uniformly throughout the enterprise.
  • Whenever a new data definition is required, the definition effort will be co-ordinated and reconciled with the corporate “glossary” of data descriptions. The enterprise data administrator will provide this co-ordination.
  • Ambiguities resulting from multiple parochial definitions of data must give way to accepted enterprise-wide definitions and understanding.
  • Multiple data standardization initiatives need to be co-ordinated.
  • Functional data administration responsibilities must be assigned.
Principle 14:
Data Security
Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, protection of pre-decisional, sensitive, source selection-sensitive, and proprietary information.
Open sharing of information and the release of information via relevant legislation must be balanced against the need to restrict the availability of classified, proprietary, and sensitive information.Existing laws and regulations require the safeguarding of national security and the privacy of data, while permitting free and open access. Pre-decisional (work-in-progress, not yet authorized for release) information must be protected to avoid unwarranted speculation, misinterpretation, and inappropriate use.

  • Aggregation of data, both classified and not, will create a large target requiring review and de-classification procedures to maintain appropriate control. Data owners and/or functional users must determine whether the aggregation results in an increased classification level. We will need appropriate policy and procedures to handle this review and de-classification. Access to information based on a need-to-know policy will force regular reviews of the body of information.
  • The current practice of having separate systems to contain different classifications needs to be rethought. Is there a software solution to separating classified and unclassified data? The current hardware solution is unwieldy, inefficient, and costly. It is more expensive to manage unclassified data on a classified system. Currently, the only way to combine the two is to place the unclassified data on the classified system, where it must remain.
  • In order to adequately provide access to open information while maintaining secure information, security needs must be identified and developed at the data level, not the application level.
  • Data security safeguards can be put in place to restrict access to “view only”, or “never see”. Sensitivity labeling for access to pre-decisional, decisional, classified, sensitive, or proprietary information must be determined.
  • Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies must be protected from unauthorized access and manipulation. Headquarters information must be safeguarded against inadvertent or unauthorized alteration, sabotage, disaster, or disclosure.
  • Need new policies on managing duration of protection for pre-decisional information and other works-in-progress, in consideration of content freshness.

Application Principles

Principle 15:
Technology Independence
Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms.
Independence of applications from the underlying technology allows applications to be developed, upgraded, and operated in the most cost-effective and timely way. Otherwise technology, which is subject to continual obsolescence and vendor dependence, becomes the driver rather than the user requirements themselves.Realizing that every decision made with respect to IT makes us dependent on that technology, the intent of this principle is to ensure that Application Software is not dependent on specific hardware and operating systems software.

  • This principle will require standards which support portability.
  • For Commercial Off-The-Shelf (COTS) and Government Off-The-Shelf (GOTS) applications, there may be limited current choices, as many of these applications are technology and platform-dependent.
  • Application Program Interfaces (APIs) will need to be developed to enable legacy applications to interoperate with applications and operating environments developed under the enterprise architecture.
  • Middleware should be used to decouple applications from specific software solutions.
  • As an example, this principle could lead to use of Java, and future Java-like protocols, which give a high degree of priority to platform-independence.
Principle 16:
Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.
The more a user has to understand the underlying technology, the less productive that user is. Ease-of-use is a positive incentive for use of applications. It encourages users to work within the integrated information environment instead of developing isolated systems to accomplish the task outside of the enterprise’s integrated information environment. Most of the knowledge required to operate one system will be similar to others. Training is kept to a minimum, and the risk of using a system improperly is low.Using an application should be as intuitive as driving a different car.

  • Applications will be required to have a common “look and feel” and support ergonomic requirements. Hence, the common look and feel standard must be designed and usability test criteria must be developed.
  • Guidelines for user interfaces should not be constrained by narrow assumptions about user location, language, systems training, or physical capability. Factors such as linguistics, customer physical infirmities (visual acuity, ability to use keyboard/mouse), and proficiency in the use of technology have broad ramifications in determining the ease-of-use of an application.

Technology Principles

Principle 17:
Requirements-Based Change
Only in response to business needs are changes to applications and technology made.
This principle will foster an atmosphere where the information environment changes in response to the needs of the business, rather than having the business change in response to IT changes. This is to ensure that the purpose of the information support – the transaction of business – is the basis for any proposed change. Unintended effects on business due to IT changes will be minimized. A change in technology may provide an opportunity to improve the business process and, hence, change business needs.
  • Changes in implementation will follow full examination of the proposed changes using the enterprise architecture.
  • We don’t fund a technical improvement or system development unless a documented business need exists.
  • Change management processes conforming to this principle will be developed and implemented.
  • This principle may bump up against the responsive change principle. We must ensure the requirements documentation process does not hinder responsive change to meet legitimate business needs. The purpose of this principle is to keep us focused on business, not technology needs – responsive change is also a business need.
Principle 18:
Responsive Change Management
Changes to the enterprise information environment are implemented in a timely manner.
If people are to be expected to work within the enterprise information environment, that information environment must be responsive to their needs.
  • We have to develop processes for managing and implementing change that do not create delays.
  • A user who feels a need for change will need to connect with a “business expert” to facilitate explanation and implementation of that need.
  • If we are going to make changes, we must keep the architectures updated.
  • Adopting this principle might require additional resources.
  • This will conflict with other principles (e.g., maximum enterprise-wide benefit, enterprise-wide applications, etc.).
Principle 19:
Control Technical Diversity
Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments.
There is a real, non-trivial cost of infrastructure required to support alternative technologies for processing environments. There are further infrastructure costs incurred to keep multiple processor constructs interconnected and maintained.Limiting the number of supported components will simplify maintainability and reduce costs.

The business advantages of minimum technical diversity include: standard packaging of components; predictable implementation impact; predictable valuations and returns; redefined testing; utility status; and increased flexibility to accommodate technological advancements. Common technology across the enterprise brings the benefits of economies of scale to the enterprise. Technical administration and support costs are better controlled when limited resources can focus on this shared set of technology.

  • Policies, standards, and procedures that govern acquisition of technology must be tied directly to this principle.
  • Technology choices will be constrained by the choices available within the technology blueprint. Procedures for augmenting the acceptable technology set to meet evolving requirements will have to be developed and emplaced.
  • We are not freezing our technology baseline. We welcome technology advances and will change the technology blueprint when compatibility with the current infrastructure, improvement in operational efficiency, or a required capability has been demonstrated.
Principle 20:
Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology.
Standards help ensure consistency, thus improving the ability to manage systems and improve user satisfaction, and protect existing IT investments, thus maximizing return on investment and reducing costs. Standards for interoperability additionally help ensure support from multiple vendors for their products, and facilitate supply chain integration.
  • Interoperability standards and industry standards will be followed unless there is a compelling business reason to implement a non-standard solution.
  • A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established.
  • The existing IT platforms must be identified and documented.


What is ISO 27001?

ISO/IEC 27001 formally specifies a management system that is intended to bring information security under explicit management control. Being a formal specification means that it mandates specific requirements. Organisations that claim to have adopted ISO/IEC 27001 can therefore be formally audited and certified compliant with the standard. ISO/IEC 27001 requires that management:

  • Systematically examines the organisation’s information security risks, taking account of the threats, vulnerabilities, and impacts.
  • Designs and implements a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable.
  • Adopts an overarching management process to ensure that the information security controls continue to meet the organisation’s information security needs on an on-going basis.

Why is ISO 27001 so important and what business benefits does it offer?

The business benefits from ISO 27001 certification are considerable. Not only do the standards help ensure that a business’ security risks are managed cost-effectively, but the adherence to the recognised standards sends a valuable and important message to customers and business partners: this business does things the correct way. ISO 27001 is invaluable for monitoring, reviewing, maintaining and improving a company’s information security management system and will unquestionably give partner organisations and customers greater confidence in the way they interact with your business.

The benefits

  • ISO 27001 is the de facto international standard for Information Security Management
  • It demonstrates a clear commitment to Information Security Management to third parties and stakeholders
  • It can provide a framework to ensure the fulfilment of commercial, contractual and legal responsibilities
  • It provides a significant competitive advantage, and can effectively be a license to trade with companies in certain regulated sectors
  • It provides for inter-operability between organisations or groups within an organisation
  • It can provide compliance with, or certification against, a recognised external standard which can often be used by management to demonstrate due diligence.

Tips for Implementing ITIL

ITIL is a widely accepted approach to IT service management and provides a set of best practices drawn from the public and private sectors internationally. Here’s how to make it work for you.

Short for IT Infrastructure Library, ITIL is an infrastructure library, initially developed in the U.K. ITIL is a widely accepted approach to IT service management and provides a cohesive set of best practices drawn from the public and private sectors internationally. It’s supported by a comprehensive qualifications scheme, accredited training organizations, and implementation and assessment tools.

The management and control of the IT infrastructure is a critical function and improved service delivery and service support processes will increase the efficiency and effectiveness of operational delivery.  The Information Technology Infrastructure Library (ITIL) is a widely accepted industry framework that adopts a process driven approach to developing operationally excellent IT service support and service delivery processes. The benefits of implementing globally consistent, ITIL-based processes include:

  • Improved availability, reliability and security of IT services.
  • Increased IT project delivery efficiency.
  • Reduced TCO of IT infrastructure assets and IT applications.
  • Improved resource utilization including decreased levels of rework and elimination of redundant activities.
  • Provisioning of services that meet business, customer and user demands, with justifiable costs of service quality.
  • More effective and better third-party relationships and contracts

While ITIL process improvement and standardization promises to greatly upgrade service and yield cost savings, success is not guaranteed. There are, in fact, some common misconceptions or myths that could lead an organization astray.

Since the ITIL framework provides only the necessary guidance on process structure, many CIOs are not seeing the improvements they expected — despite heavy investment in ITIL. ITIL deployment should be set within the context of a business or IT change program and as such, is more than a simple set of processes that can be rolled out and uncompromisingly followed. Any IT change program will encompass organizational, process and technology elements.

Here are ten tips CIOs and program directors can use to approach effective ITIL implementation with confidence:


1.  Approach ITIL implementation as part of the IT-wide strategy, and use it to guide all other strategic initiatives.
ITIL process implementation has significant IT-wide impacts; it is not an isolated initiative. To avoid both resource and programming constraints, implementation must be aligned with other global and regional programs, IT initiatives and sourcing or supplier initiatives.  A portfolio management approach should be taken to understand the alignment and priorities of all initiatives in addition to the overall benefits to the organization.

2.  Consider the post-ITIL organization before completing the process design.
Introducing ITIL-based processes generates requirements for new functions and roles, which could impact the current service management structure. Prior to completing process design, understand the roles and functions required to support the processes; giving specific consideration to the supplier/internal resource split.  Consideration must also be given to the governance structure needed to guide and support the new IT organization. Establishing a transformation program ensures that the structure from which to hang ITIL is secured and operational prior to process implementation.

3.  Engage, engage, engage. Continuous communication is required at all levels of the organization.
Implementing ITIL impacts the full spectrum of the organization’s employees. Because of this, it is critical to understand the impact at each level within the organization and the value each brings to the program. Subsequently, engagement, communications and training are absolutely key to success; from the initial engagement of senior stakeholders to the manager-level ITIL training of new global process owners.

4.  Set realistic expectations about benefits realization and establish a baseline from which to monitor improvements.
Change within any organization takes time to be accepted and implementing ITIL is no different. Implementation of ITIL focuses on improving customer service and as the processes mature the subsequent ROI will be recognized.

To determine the end result, focus the strategy and focus communications on improving service quality and establishing an early baseline of key performance indicators (KPIs) from which to monitor improvements. The chosen KPIs and their associated benefits should be business-focused and clearly understood so that effort is not wasted on measuring and interpreting superfluous data.

5.  Engage existing suppliers early.
Existing suppliers and any subsequent SLAs will be affected by the implementation of ITIL. The strategy for handling third-party engagement and establishing a robust communications plan must be clearly defined, with priorities focused on the desired supplier landscape.

Early engagement with procurement and legal departments will help to support and address the ripple effect that occurs right through to existing contracts and SLAs upon implementing the new processes. An end-to-end SLA will also be ultimately required to support the operation of the new processes.


6.  Identify and deliver the quick wins.
It’s “old” advice, but it remains fundamentally important to ensure that the organization achieves, communicates (and celebrates) early successes. Such an approach buys time for the process implementation and will help to gain the much-needed stakeholder engagement across the organization. Experience suggests that failure to achieve these successes will typically double the resistance to the change and halve the support within six months.

7.  Maximum benefit can be only achieved if the impact each process has on another is understood.
The ITIL framework is comprised of ten service management processes and one service management function. Every ITIL process supports, interfaces and integrates with at least one other process.

For effective development and deployment the relationship, impact and interdependencies across the ITIL framework must be clearly defined and understood. The close integration and understanding of the processes allows for the continual flow of up-to-date, critical and accurate information that in turn enables management to drill down and identify target areas for service improvement.

8. Prioritize process selection based on current maturity; don’t bite off more than you can chew.
It’s important to take a holistic view to ITIL implementation, however. It’s not imperative to implement all processes concurrently in order to realize operational improvements and a significant ROI.  Implementation of individual processes or the prescribed combination of processes can deliver the desired operational improvements. Processes should be selected based on the benefits sought by the organization and the ones that drive the most business value.

9.  Use success as a springboard for further improvement.
Implementing ITIL is a strategic commitment and will take many months to fully implement. During this time many different parts of the IT organization will be required to change.

In this sort of environment, it’s important to also implement a program of continuous improvement (e.g. a “plan, do, check, react” cycle). First this will ensure that improvement is actually delivered as expected and, second, it will help to build further improvement rather than assuming the job is done and risk slipping back in to old behaviors.


10. Combine process and tool activities from day one as part of a single solution approach.
Implementing a service management tool will support the streamlined processes, automate tasks and manage and distribute information. Knowledge management (e.g., the re-use and integration of information) is a critical component of the service management tool. Integrating data control processes with the tool will ensure that information is current and continues to add value to the service management processes.

Implementing ITIL is not just about evaluating and revising processes, it’s about change: changing the way people work and are rewarded; changing technology platforms; and changing behaviors across an entire organization.


Ref: www.webopedia.com

To TOGAF or not to TOGAF…

TOGAF 9 can be a great starting point to increase the awareness within an organization and to more explicitly acknowledge the need for enterprise-wide investments in architecture. There are, however, also pitfalls to be aware of. Three important pitfalls to avoid stepping in are:

  • Keep TOGAF in the ivory tower. When reading TOGAF and following it to the letter, it is certainly possible, maybe even tempting, to just execute every phase, deliver each artifact and create all repositories. This in itself does not have to be wrong, but please note that TOGAF also emphasizes, albeit in between the lines, that making selections, and tailoring the framework to the context at hand (which includes the business) is key. This prevents that TOGAF will just keeps a bunch of expensive architects busy for several months or years, without generating real business value.
  • Exclude development processes from the scope of architecture. TOGAF’s architecture development method (ADM) reasons solely from the perspective of the architect. Actual software development takes place somewhere during or after the Implementation governance phase of the ADM, but no concrete guidance is offered on how architects should guarantee that the right software (solution building blocks in TOGAF) is developed. This is probably a gap in TOGAF that you should be aware of. Fortunately, there is plenty of good software architecture literature written that does focus around this intricate relationship with requirements engineering, design, and implementation.
  • Make the tools, artifacts and languages leading. When reading TOGAF one often get the feeling that it is very technical-minded, focused on deliverable (which almost all have quite fancy names in the TOGAF world) and rather model-driven. Although architects need models, technology, instruments, languages, and deliverable, to effectively communicate with stakeholders, one should be aware that using them should never become a goal in itself. The Architecture Content Framework (ACF) in TOGAF 9, including the core meta model, and its extensions, is a helpful start to think of a common frame of reference to use in your organization, but please adapt your tone and language to your stakeholders and their interests and concerns. Many of TOGAF’s artifacts are borrowed from UML and this will definitely help in communicating about architecture to developers and other technical stakeholders.

Referred from: Rick Farenhorst blog

How to develop Enterprise architecture / framework and IT strategy

Define current enterprise systems inventory. 
The first step is to identify the systems you have in place, which can be difficult to do if you are a larger or more complex organization. Companies that have grown quickly and/or acquired one or more other companies are more likely to have a hodgepodge of ERP systems, spreadsheets, and other business software to run their operations. We often see companies with several hundred enterprise systems running their business, including a number of unauthorized “black market” systems that your IT department isn’t even aware of. It is hard to determine a logical path forward without first understanding where you’re starting.
Rationalize current systems. 
Once the systems have been inventoried, attention then needs to turn to which ones are core to the business or are providing competitive advantage to the organization. It is also important to assess each system’s maintenance costs, pain points, flexibility, and scalability for future growth. It is also important to evaluate the opportunity costs associated with business benefits that are lost due to poor systems. Once the systems have been evaluated using these and other key criteria, you can then move on to identifying what to do with each of them.
Identify low-hanging fruit. 
This is where the real fun begins. Once you have the quantitative assessment of each of the IT systems in your portfolio, you can then start prioritizing which systems can or should be consolidated, upgraded, or replaced. Typically there is significant “low hanging fruit,” or systems that can have an immediate and measurable impact by improving or replacing them. In addition to identifying the projects that may have immediate value, you will also want to prioritize the non-low-hanging-fruit.
Identify your applications strategy. 
Once you have your priorities in place, your attention should then turn to your overall applications strategy. Based on your priorities, you will want to consider whether to pursue a single, consolidated ERP system, a best-of-breed solution, or a hybrid of both. This applications strategy should take not only your highest and most immediate priorities into consideration, but also the more intermediate and long-term priorities as well. Another key consideration is your hosting strategy: will you pursue Software as a Service (SaaS) or cloud solutions, on-premise software, or a combination of both? Single or multiple instance?
Develop an IT strategy road-map. 
The above four steps will be crucial to developing your overall IT strategy road-map. These inputs will help you identify a three- to five-year plan for improving your enterprise systems infrastructure. In most cases, the plan will entail evaluation of potential ERP systems or other enterprise applications. In addition, the plan should identify how new systems will integrate to legacy systems, data consolidation and strategy, infrastructure upgrade requirements to support the new strategy, and organizational change management activities to support the new plan forward.


What is TOGAF?

TOGAF is The Open Group Architecture Framework. It is a popular framework for developing and managing enterprise architecture.


What is Enterprise Architecture?

Enterprise Architecture is a method of envisioning (a) an organization as it exists in its present state, (b) that same organization as it would be in a future (better) state, and (c) a road map to enable the organization to progress from current (as-is) state to future (to-be) state. Enterprise Architecture’s greatest value lies in its ability to help the organization align its business framework with the data/information needed to conduct business, and the technology needed to process the data/information. This results in lowered systems costs, reduced redundancy, and enhanced systems efficiency and effectiveness.


Why Do I need a framework for enterprise architecture?

Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.

Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to “de-mystify” the architecture development process, enabling to build genuinely open systems-based solutions for business requirements.


Why do I need enterprise architecture?

The primary reason for developing enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy.

Effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. Enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Furthermore, good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it assures the needs of the organization for an integrated IT strategy, permitting the closest possible synergy across the extended enterprise. The technical advantages that result from a good enterprise architecture bring important business benefits, which are clearly visible in the bottom line:

A more efficient IT operation:

  • Lower software development, support, and maintenance costs
  • Increased portability of applications
  • Improved inter-operability and easier system and network management
  • Improved ability to address critical enterprise-wide issues like security
  • Easier upgrade and exchange of system components

Better return on existing investment, reduced risk for future investment:

  • Reduced complexity in IT infrastructure
  • Maximum return on investment in existing IT infrastructure
  • The flexibility to make, buy, or out-source IT solutions
  • Reduced risk overall in new investment, and the costs of IT ownership

Faster, simpler, and cheaper procurement:

  • Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan.
  • The procurement process is faster – maximizing procurement speed and flexibility without sacrificing architectural coherence.

Why is this important?

Customers who do not invest in enterprise architecture typically find themselves pushed inexorably to single-supplier solutions in order to ensure an integrated solution. At that point, no matter how ostensibly “open” any single supplier’s products may be in terms of adherence to standards, the customer will be unable to realize the potential benefits of truly heterogeneous, multi-vendor open systems.


What specifically would prompt me to develop architecture?

Typically, architecture is developed because key people have concerns that need to be addressed by the IT systems within the organization. Such people are commonly referred to as the “stakeholders” in the system. The role of the architect is to address these concerns, by identifying and refining the requirements that the stakeholders have, developing views of the architecture that show how the concerns and the requirements are going to be addressed, and by showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders.

Without the architecture, it is highly unlikely that all the concerns and requirements will be considered and met.


What kind of architecture does TOGAF deal with?

There are four types of architecture that are commonly accepted as subsets of overall enterprise architecture, all of which TOGAF is designed to support:

A Business (or Business Process) Architecture – this defines the business strategy, governance, organization, and key business processes.
A Data Architecture – this describes the structure of an organization’s logical and physical data assets and data management resources.
An Applications Architecture – this kind of architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
A Technology Architecture – this describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.


Who would benefit from using TOGAF?

Any organization undertaking, or planning to undertake, the design and implementation of enterprise architecture for the support of mission-critical business applications, using open systems building blocks.

Customers who design and implement enterprise architectures using TOGAF are ensured of a design and a procurement specification that will greatly facilitate open systems implementation, and will enable the benefits of open systems to accrue to their organizations with reduced risk.


What is The Open Group?

The Open Group is the organization that designed and manages TOGAF, periodically reviews and revises TOGAF, accredits TOGAF training sources, and certifies TOGAF enterprise architects.


Do I need to pay for a license to use TOGAF?

No. There is no cost associated with using TOGAF.


Do I need to join The Open Group to use TOGAF?

No. Joining The Open Group is totally voluntary and in no way affects your ability to use TOGAF in your organization.


I already use another EA framework. Why should I switch to TOGAF?

TOGAF has several advantages over other architecture frameworks. For example, the TOGAF Architecture Development Method provides a robust, step-by-step approach to developing enterprise architecture to align an organization’s business, data/information, and technology. Other components of TOGAF (e.g., the repositories, metamodels, etc.) can enhance the organization’s Knowledge Management, Project/Program/Portfolio Management, and other processes. TOGAF also aligns and integrates with organizational management, assessment, and improvement models such as the Baldrige Criteria for Performance Excellence, and organizational change models like Kotter’s eight-step process. That said, TOGAF can be used in concert with other architecture frameworks, so there is no need for an across-the-board changeover to TOGAF.


What are the benefits of using TOGAF?

The primary benefit of using TOGAF is that it enables an organization to build an architecture that aligns and integrates business concerns (people, processes, technologies, and infrastructures), information systems architectures (data and applications), and information technology architecture in an elegant, robust manner. TOGAF provides a step-by-step approach to doing this. Also, TOGAF can be tailored to address the unique needs of specific organizations. Finally, TOGAF can be used in conjunction with other architecture frameworks, standards, and management approaches.


What are the drawbacks of using TOGAF?

TOGAF can be difficult to learn and apply in a vacuum. TOGAF should be learned in a training course conducted by an organization that has been accredited by The Open Group.


Can I use TOGAF with my current EA framework without going through a wholesale changeover to TOGAF?

Yes. TOGAF can be used in conjunction with other architecture frameworks.


TOGAF looks very complex. Do I have to use all features?

No. The complexity of TOGAF allows it to be implemented and used within large, complex organizations. Smaller, less complex enterprises use only those parts of TOGAF that create or add immediate value to the organization.


Can I tailor TOGAF to meet the needs of my unique [small] organization?

Yes. TOGAF can be used in its entirety, or various components may be used alone, depending on the unique needs of the specific organization.


How can I learn about TOGAF?

The best way to learn TOGAF is by taking a TOGAF training course conducted by a training organization that has been accredited by The Open Group.


What will I learn?

Depending on the training you attend (level 1, Level 2, or Consolidated Level 1 and Level 2), you will learn either the foundational concepts of TOGAF (Level 1), detailed material regarding the concepts of TOGAF (Level 2), or both (Consolidated Level 1 and Level 2).


What do “Level 1” and “Level 2” mean?

Level 1 and Level 2 refer to the two certification levels of TOGAF.. Level 1 is also known as the “Foundation” Level; Level 2 is also known as the “Certified” Level. When used in connection with a TOGAF training course, Level 1 and Level 2 refer to the focus of the training.


Who conducts the training?

TOGAF training courses are conducted world-wide by a number of training organizations. Search on internet for traning providers in your area.


How much does TOGAF training cost?

The basic cost for the four-days or five days training program at Level 1 and Level 2 varies from country to country.


Will I receive a certification?

Upon request, everyone attending the training can be issued a Course Completion Certificate. You will not receive a TOGAF certification by simply attending a TOGAF training course. To achieve certification, you must purchase an examination voucher, schedule the examination at a local examination center, and pass the examination. You must do this for each Level for which you seek certification.


What are the available certifications?

TOGAF 9 Foundation (Level 1) – to provide validation that the candidate has gained knowledge of the terminology and basic concepts of TOGAF 9 and Understands the core principles of Enterprise Architecture and TOGAF. TOGAF 9 Certified (Level 2) – to provide validation that in addition to knowledge and comprehension, the candidate is able to analyze and apply knowledge of TOGAF.


What is the retake policy if I fail an examination?

Candidates who fail an examination are not allowed to re-set ANY TOGAF examination again for a period of one (1) month. A result received before one month will be VOID.


What are the four types of TOGAF examinations?

TOGAF 9 Part 1 – Pass mark 55% (22 or more points out of a maximum of 40)
This exam comprises 40 questions in simple multiple choice format, covering the Level 1 learning outcomes. Each correct answer scores a single point.

TOGAF 9 Part 2 – Pass mark 60% (24 or more points out of a maximum of 40)

This exam comprises 8 complex scenario questions, with gradient scoring. This exam is open book and covers the complete Level 2 learning outcomes. The correct answer scores 5 points, the second best answer 3 points, the third best answer 1 point. The distracter scores zero points.

TOGAF 9 Combined Part 1 and 2 – This is a combined TOGAF 9 Part 1 and Part 2 examination for candidates who want to achieve Level 2 certification directly in a single examination. It consists of two sections, with pass marks as per the TOGAF 9 Part 1 and 2 examinations described above. Each section must be passed in order to obtain an overall pass mark. If you fail a section then no certification is awarded, however you only need retake the Examination(s) corresponding to the failed section(s).

TOGAF 8 – 9 Advanced Bridge – Two sections, each with a pass mark 60%, and each has to be passed in order to obtain an overall pass. The first section is 20 simple multiple choice questions covering the Level 1 learning outcomes. To obtain a pass for this section requires 12 or more points out of a maximum of 20.

Implementing ISO27001: tips and controls

According to the website iso27001certificates.com there are now over 6,000 organisations worldwide that have attained certification against the ISO27001:2005 Information Security Standard. So what are the real business benefits these organisations have seen as a result of implementing ISO27001? Have there been any other benefits apart from those directly associated with information security that have arisen as a result of these projects? And what should others consider before embarking on the journey to implement the ISO27001:2005 information security standard?


What are the key changes in the ISO 27001: 2013 revision, as well as the benefits?

The key benefit of this new ISO 27001 is that it can be more easily implemented in smaller companies – a greater degree of flexibility is allowed, and a smaller number of mandatory documents is needed. For instance, the risk assessment process is simplified, and there are no more requirements to document procedures like internal audit or corrective action.

What are the new security controls and how does the 2013 revision deal with new risks?

First of all, the number of suggested controls in the 2013 revision has actually decreased from 133 to 114 – therefore, it is easier now to find the controls that are really needed for a particular risk. The new controls are these: A.6.1.5 Information security in project management, A.14.2.1 Secure development policy, A.14.2.5 Secure system engineering principles, A.14.2.6 Secure development environment, A.14.2.8 System security testing, A.16.1.4 Assessment of and decision on information security events, and A.17.2.1 Availability of information processing facilities.

How much new mandatory documentation is there, and for certified companies is there lots of work involved in implementing these?

There is actually less documentation required. If a company is already certified against the old 2005 revision of ISO 27001, only about 10-20% of the existing documents will need to be changed, and some of the documents may now be deleted. Therefore, the effort to make this transition to the 2013 revision won’t be too big.

Let’s say you’re talking to a company that hasn’t implemented ISO 27001; how would you explain the benefits of this standard, the implementation program, and how this can help them in the long term?

The most important thing is to make the decision makers (i.e. the top management) interested in this project, because they are the ones who will approve the project or reject it. And to do this you have to find which business benefits could be achieved by implementing information security in your company.

Benefits: (1) compliance – by implementing ISO 27001, a company will comply with all the information security legislation, but also with contractual requirements that clients are enforcing more and more; (2) marketing advantage – companies with this certificate might get some new clients who are looking for this kind of guarantee for the security of their information; (3) decreasing the costs – by implementing ISO 27001, many security incidents will be prevented, and the investment in implementing this standard is usually far less than the cost of remediation of the incidents; and (4) optimizing the business processes – since the standard requires defining exactly who needs to do what, when and how, this means that employees will be spending less time searching for ways to perform their tasks.

Unfortunately, too many IT and security professionals focus on IT benefits instead of focusing on business benefits – but by presenting the benefits like “We will be more secure,” or even worse, “We will have a nice secondary location,” this doesn’t really say anything to the top management on how it will increase their profits, decrease costs, achieve their strategic goals, or limit their business risks.

It sounds like once the initial work is complete, the rules and procedures ISO 27001 puts in place can reduce mistakes and make the IT department’s job easier?

Exactly! The problem is that very often IT professionals see this standard as unnecessary bureaucracy; but in reality, if the rules for using the information technology are clear for everyone in the company, the number of problems related to IT will decrease. This means IT departments will be dealing less with resolving the problems like “Why don’t I see this icon anymore,” and can focus on more strategic things.

What are the benefits of implementing ISO 27001 with other management standards?

If a company has already implemented, e.g., ISO 9001, it will decrease the time required for ISO 27001 implementation by 30% – this is because these two standards have a lot in common and, for instance, some of the documentation written for ISO 9001 can be used for ISO 27001 as well.

But there is one standard that is even more compatible with ISO 27001: the business continuity standard ISO 22301. When implementing ISO 27001, with 10% additional effort a company can implement ISO 22301 too, because these two standards are highly compatible and about 60% of their requirements are the same.


What is “The Open Group Architecture Framework”?

The Open Group Architecture Framework (TOGAF) is a framework – a detailed method and a set of supporting tools – for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization (see Conditions of Use).

TOGAF is developed and maintained by members of The Open Group, working within the Architecture Forum (refer to www.opengroup.org/architecture). The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment.

Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF and published each one on The Open Group public web site.

If you are new to the field of enterprise architecture and/or TOGAF, you are recommended to read the Executive Overview (refer to Executive Overview), where you will find answers to questions such as:

  • What is enterprise architecture?
  • Why do I need an enterprise architecture?
  • Why do I need TOGAF as a framework for enterprise architecture?

Structure of the TOGAF Document

The structure of the TOGAF documentation reflects the structure and content of an architecture capability within an enterprise, as shown in Structure of the TOGAF Document .



There are seven main parts to the TOGAF document:

(Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF.
(Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an enterprise architecture.
(ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
(Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.
(Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
(TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).
(Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

The intention of dividing the TOGAF specification into these independent parts is to allow for different areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a whole, it is also feasible to select particular parts for adoption whilst excluding others. For example, an organization may wish to adopt the ADM process, but elect not to use any of the materials relating to architecture capability.

As an open framework, such use is encouraged, particularly in the following situations:

  • Organizations that are new to TOGAF and wish to incrementally adopt TOGAF concepts are expected to focus on particular parts of the specification for initial adoption, with other areas tabled for later consideration.
  • Organizations that have already deployed architecture frameworks may choose to merge these frameworks with aspects of the TOGAF specification.

Executive Overview

According to The Open Group Business Executive’s Guide to IT Architecture:1

“An effective enterprise architecture is critical to business survival and success and is the indispensable means to achieving competitive advantage through IT.”

This section provides an executive overview of enterprise architecture, the basic concepts of what it is (not just another name for IT Architecture), and why it is needed. It provides a summary of the benefits of establishing an enterprise architecture and adopting TOGAF to achieve that.

What is an enterprise? What is enterprise architecture?

TOGAF defines “enterprise” as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The term “enterprise” in the context of “enterprise architecture” can be used to denote both an entire enterprise – encompassing all of its information and technology services, processes, and infrastructure – and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

Confusion often arises from the evolving nature of the term “enterprise”. An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.

The business operating model concept is useful to determine the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there is often much in common about the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.

Why do I need an enterprise architecture?

The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

Today’s CEOs know that the effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it ensures the needs of the organization for an integrated IT strategy are met, permitting the closest possible synergy across the extended enterprise.

The advantages that result from a good enterprise architecture bring important business benefits, which are clearly visible in the net profit or loss of a company or organization:

  • A more efficient IT operation:
    • Lower software development, support, and maintenance costs
    • Increased portability of applications
    • Improved interoperability and easier system and network management
    • Improved ability to address critical enterprise-wide issues like security
    • Easier upgrade and exchange of system components
  • Better return on existing investment, reduced risk for future investment:
    • Reduced complexity in IT infrastructure
    • Maximum return on investment in existing IT infrastructure
    • The flexibility to make, buy, or out-source IT solutions
    • Reduced risk overall in new investment, and the costs of IT ownership
  • Faster, simpler, and cheaper procurement:
    • Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan.
    • The procurement process is faster – maximizing procurement speed and flexibility without sacrificing architectural coherence.
    • The ability to procure heterogeneous, multi-vendor open systems.
What specifically would prompt me to develop an enterprise architecture?

Typically, an enterprise architecture is developed because key people have concerns that need to be addressed by the IT systems within the organization. Such people are commonly referred to as the “stakeholders” in the system. The role of the architect is to address these concerns, by identifying and refining the requirements that the stakeholders have, developing views of the architecture that show how the concerns and the requirements are going to be addressed, and by showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders.

Without the enterprise architecture, it is highly unlikely that all the concerns and requirements will be considered and met.

What is an architecture framework?

An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

Why do I need TOGAF as a framework for enterprise architecture?

TOGAF has been developed through the collaborative efforts of 300 Architecture Forum member companies from some of the world’s leading IT customers and vendors and represents best practice in architecture development. Using TOGAF as the architecture framework will allow architectures to be developed that are consistent, reflect the needs of stakeholders, employ best practice, and give due consideration both to current requirements and to the likely future needs of the business.

Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to “de-mystify” and de-risk the architecture development process. TOGAF provides a platform for adding value, and enables users to build genuinely open systems-based solutions to address their business issues and needs.

Who would benefit from using TOGAF?

Any organization undertaking, or planning to undertake, the design and implementation of an enterprise architecture for the support of mission-critical business applications will benefit from use of TOGAF.

Organizations seeking Boundaryless Information Flow can use TOGAF to define and implement the structures and processes to enable access to integrated information within and between enterprises.

Organizations that design and implement enterprise architectures using TOGAF are assured of a design and a procurement specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with reduced risk.