- Governance “ensures that enterprise objectives are achieved by evaluating stakeholder needs, conditions and options; setting direction through prioritisation and decision making; and monitoring performance, compliance and progress against agreed-on direction and objectives” (Evaluate-Direct-Monitor=EDM).
- Management “plans, builds, runs and monitors activities in alignment with the direction set by the governance body to achieve the enterprise objectives” (Plan-Build-Run-Monitor=PBRM).
COBIT 5 takes the classic choice in distinguishing between governance and management (“board” and “CEO”) – it literally puts boxes around them – and applies this on enterprise IT. Corporate governance pioneer Bob Tricker points out that governance is concerned with “doing the right thing” (direction) and management is concerned with “doing things right” (run the enterprise). In today’s fast-paced environment, this causes many challenges. The old Plan-Build-Run approach is challenged. Regardless of how much Monitoring is done.
COBIT 5 states that “stakeholder needs have to be transformed into an enterprise’s actionable strategy”. The COBIT 5 goals cascade is the mechanism to “translate” stakeholder needs into specific, actionable and customised enterprise goals, IT-related goals and enabler goals.
This translation allows setting specific goals at every level and in every area of the enterprise in support of the overall goals and stakeholder requirements, and thus effectively supports alignment between enterprise needs and IT solutions and services.
Accoding to COBIT5, the goals cascade is important because:
it allows the definition of priorities for implementation, improvement and assurance of governance of enterprise IT based on (strategic) objectives of the enterprise and the related risk.
The four arrows express four steps:
Step 1. Stakeholder Drivers Influence Stakeholder Needs. Stakeholder needs are influenced by strategy changes, the business/regulatory environment, new technologies, etc.
Step 2. Stakeholder Needs Cascade to Enterprise Goals. Stakeholder needs can be related to a set of enterprise goals. The COBIT5 goals cascade nicely organizes these into the four balanced scorecard dimensions, with 17 generic goals that can also be easily mapped to specific organizational goals.
Step 3. Enterprise Goals Cascade to IT Related Goals. Often, enterprise goals can only be achieved if the IT-related goals are met (where IT stands for Information AND Technology). In the goals cascade, each of the 17 enterprise goals are mapped to a number of relevant IT-related goals. There are 17 IT-related goals and they are also organized into the four balanced scorecard dimensions.
Step 4. IT-related Goals Cascade to Enabler Goals. In order to achieve IT-related goals, a number of enablers must be successfully applied. One of these enablers is processes. Similar to earlier steps in this cascade, each IT-related goal is then mapped to one or more processes. The COBIT 5 framework has 37 processes.
The cascading goals are as presented by COBIT5 entrenched in a classic “command-and-control” thinking. COBIT5 offers little in terms of how the cascading goals are managed in the real world where complexity rules and change is the only constant.
CoE recommends practitioners to take note of the fundamental idea in the cascading goals – that “everything is related”.
COBIT 5 Enabler: Services, Infrastructure and Applications (APPENDIX G)
Service capabilities refer to resources such as applications and infrastructures that are leveraged in the delivery of IT-related services. The specifics for the service capabilities enabler compared to the generic enabler description are shown below.
The services, infrastructure and applications model shows:
- Stakeholders—Service capabilities (the combined term for services, infrastructure and applications) stakeholders can be internal and external. Services can be delivered by internal or external parties—internal IT departments, operations managers, outsourcing providers. Users of services can also be internal— business users—and external to the enterprise—partners, clients, suppliers. The stakes of each of the stakeholders need to be identified and will either be focussed on delivering adequate services or on receiving requested services from providers.
- Goals—Goals of the service level capability will be expressed in terms of services—applications, infrastructure, technology—and service levels, considering which services and service levels are most economical for the enterprise. Again, goals will relate to the services and how they are provided, as well as their outcomes, i.e., contribution towards successfully supported business processes.
- Life cycle—Service capabilities have a life cycle. The future or planned service capabilities are typically described in a target architecture. It covers the building blocks, such as future applications and the target infrastructure model, and also describes the linkages and relationships amongst these building blocks.
The current service capabilities that are used or operated to deliver current IT services are described in a baseline architecture. Depending on the time frame of the target architecture, a transition architecture may also be defined, which shows the enterprise at incremental states between the target and baseline architectures.
Good practices—Good practice for service capabilities includes:
- Definition of architecture principles—Architecture principles are overall guidelines that govern the implementation and use of IT-related resources within the enterprise. Examples of potential architecture principles are:
- Reuse—Common components of the architecture should be used when designing and implementing solutions as part of the target or transition architectures.
- Buy vs. build—Solutions should be purchased unless there is an approved rationale for developing them internally.
- Simplicity—The enterprise architecture should be designed and maintained to be as simple as possible while still meeting enterprise requirements.
- Agility—The enterprise architecture should incorporate agility to meet changing business needs in an effective and efficient manner.
- Openness—The enterprise architecture should leverage open industry standards.
- The enterprise’s definition of the most appropriate architecture viewpoints to meet the needs of different stakeholders. These are the models, catalogues and matrices used to describe the baseline, target or transition architectures; for example, an application architecture could be described through an application interface diagram, which shows the applications in use (or planned) and the interfaces amongst them.
- Having an architecture repository, which can be used to store different types of architectural outputs, including architecture principles and standards, architecture reference models, and other architecture deliverables, and which defines the building blocks of services such as:
- Applications, providing business functionality
- Technology infrastructure, including hardware, system software and networking infrastructure
- Physical infrastructure
- Service levels that need to be defined and achieved by the service providers
External good practice for architecture frameworks and service capabilities exist. These are guidelines, templates or standards that could be used to fast-track the creation of architecture deliverables. Examples are:
- TOGAF provides a Technical Reference Model and an Integrated Information Infrastructure Reference Model.
- ITIL provides comprehensive guidance on how to design and operate services.
Mappings
A mapping of various frameworks into COBIT5 is offered in this figure:
ISACA and COBIT5s authors obviously regards EA as a narrowly scoped discipline. Since TOGAF is used to represent EA, this is an understandable assertion. But an unfortunate one. Enterprise architects today must work “out of the box”, and at least also work with the EDM, APO and MEA processes. With the IT-centricity of COBIT5, it could be argued that COBIT5 is “just a box” within the wide scope of EA.