Author: Brian Johnson
This whitepaper does not attempt to cover the A to Z of methods, frameworks and standards that can be used in combination with BiSL® Next (or with any of the frameworks included here). It is a brief summary of some of the more popular and widely used frameworks that have an impact on business information management (for better or worse).
1 TOGAF®
The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF proponents often use the framework to examine the architectural issues and because it provides intelligent guidance regarding how to monitor the development and implementation, though once more be aware it is not an agile development method or a project management method such as PRINCE2® or PMI®. It does not help you to design or manage the information needed in software applications, how it should be maintained or used or retrieved or stored.
TOGAF emphasizes modularization and standardization, both of which are excellent aspirational concepts that apply well to information services design too. Indeed, the more modular and standard things become, the easier it is to automate; the reality however is that many aspects of information service design, particularly at stakeholder level, are random and cannot be standardized. As the service design progresses information sources might be open to standardization (think name and address information) and as software is developed code can be standardized (and reused). Elements of ITIL®-type processes (in other words, procedures) will also be open to mechanization but feel free to ignore anyone who tells you that, for example, incident management can be fully automated. As soon as someone calls a service desk to speak to a support engineer, that claim falls flat. Furthermore, in the emergency services Incident management is invoked as the result of a 999 (911 in the USA, 112 in what’s left of Europe) call.
The same is true of capacity management, financial management or any other major process. Until Artificial Intelligence is available that we all trust (do you really want a self- driving vehicle when it will take years to get the older vehicles either off the roads or segregated?), then such claims are at best spurious and at worst deliberately misleading.
Figure 1 The TOGAF ADM model
Architecture Development Model (ADM)
TOGAF then, utilizes an architecture development model (ADM). A reproduction of this TOGAF model found everywhere on the web is shown in Figure 1.
The high level diagram has ten circles, though ADM is described as a four step process;
• Tailor TOGAF to suit your enterprise need: prior to adoption of TOGAF it is strongly emphasized that this once only activity is done before you start adopting TOGAF for the
enterprise. The recommendation is made to ensure that no one assumes the ‘once size fits all’ mentality
• Define the scope of work for which you intend to use the framework and prepare a plan for rollout (TOGAF describes six steps for this process)
• Oversee development and implementation: the mechanics of how the actual development and implementation is undertaken is not within the scope of TOGAF (see earlier that TOGAF is not a project management method)
• Manage post-implementation change: any major change will trigger off another cycle of Architectural Development Management
Most enterprises using TOGAF have multiple ADM cycles in progress at the same time for different projects running within your organization. The projects need not be in synchronization from a TOGAF
point of view, though from a programme and project management perspective they will need to be in step.
Requirement Management and central knowledge repository
The circle at the center of Figure 1 represents a knowledge repository. TOGAF has specific recommendations on how to organize the repository. Their recommendations are valuable, though KM is a good practice of itself and TOGAF should not be considered the key good practice for KM; Whitepaper ‘Knowledge Management’ summarizes a number of KM good practices.
Architecture as defined in TOGAF
The definition of ‘architecture’ as used in TOGAF is not always accepted. Quoting directly from the TOGAF study guide, it makes the explicit statements that…
…”architecture” has two meanings depending upon the context:
• A formal description of a system, or a detailed plan of the system at a component level to guide its implementation
• The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
A number of commentators have pointed out that there is a contradiction between detailed planning, on the one hand and evolution of time on the other. Keep in mind this is not a formal method for project management and has been designed from a technical perspective (irrespective of claims to the contrary). That does not mean it is a ‘bad’ design or that it should not be used. ITIL and COBIT also have been designed from IT perspectives, which is seen as a kiss-of-death, so inevitably adherents claim that their favorite framework is a ‘business and IT alignment framework’. It is not.
A particularly useful facility of TOGAF is that as a self –described enterprise architecture model, it is possible to tailor ‘their’ model for your enterprise, for example where enterprises have merged and IT is to be integrated. The supporting IT services (to be specific, generic IT services) such as billing systems, SAP, service desks and so on will differ and must be integrated. Otherwise the internal support and external customer facing activities will appear schizophrenic. Mergers and acquisitions involve complex technological, process and people ‘improvements’. An enterprise architecture starting point can be very helpful, but it is far from a ‘business and IT alignment model’ or good practice.
3. COBIT®
COBIT aims “to research, develop, publish and promote an authoritative, up-to-date, international set of generally accepted information technology control objectives for day-to-day use by business manager’s IT professionals and assurance professionals“. It is a framework that defines a set of generic processes that can be used to manage processes in IT. One of the official COBIT5 models is shown at Figure 3.
The business orientation of COBIT consists of linking business goals to IT goals, providing metrics and maturity models to measure their achievement, and identifying the associated responsibilities of business and IT process owners. It can thus act as an audit framework.
The process focus of COBIT is illustrated by a process model that subdivides IT into four domains (Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate) and 34 processes in line with the responsibility areas of plan, build, run and monitor. It is positioned at a high level and claims to have been aligned and harmonized with other, more detailed, IT standards and good practices such as COSO, BiSL Next (of course), ITIL, ISO/IEC 27000, and TOGAF. It is claimed that COBIT acts as an integrator of these different guidance materials, summarizing key objectives under one umbrella framework that link the good practice models with governance and business requirements.
Figure 3 COBIT®5
The framework defines each process together with process inputs and outputs, key process activities, process objectives, performance measures and provides a rudimentary maturity model. In many respects it is similar to ITIL and over many years various versions of ITIL have been mapped to various versions of COBIT and to capability maturity models. These efforts are well researched, detailed and mostly a waste of effort. Mapping (whatever that means) enables the cartographer or the reader of the map, to identify where (for example) ITIL describes availability and what ITIL claims it to be; the differences or similarities with COBIT are then made clear. The use of both frameworks however is in their instantiation and use (true also of BiSL next of course….) and a pedantic and academic ‘implementation’ of either or both is not useful, practical or even possible.
4. BABOK®
The Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the globally recognized standard for the practice of business analysis. The BABOK® Guide represents the collective knowledge of the business analysis community and accumulates the most widely accepted business analysis practices.
The BABOK® Guide recognizes and reflects that fact business analysis is continually evolving and is practised in a wide variety of forms in disparate environments. It defines the skills and knowledge that people who work with and employ business analysts should expect a skilled practitioner to demonstrate.
The BABOK® Guide is a framework that describes the business analysis tasks that must be performed to deliver a solution that will provide value to the sponsoring organization. Each business analysis task contributes to this overall goal directly or indirectly. Many elements of a task may vary, including the form those tasks take, the order they are performed in, or the relative importance of the tasks.
The BABOK® Guide describes the skills, knowledge, and competencies required to perform business analysis effectively. It does not describe the processes that people will follow to do business analysis.
According to advice provided about Capability Maturity Model integration, organizations interested in process improvement need to adopt industry standards from Business Analysis Body of Knowledge (and of course from other reference sources) to lift their project delivery from the ad hoc to the managed level. Of course your definition of ad hoc may be Agile….
A knowledge area within BABOK defines a group of tasks and techniques which are related. BABOK is not a definition of methodology, BABOK sketches parameters for knowledge, tasks and activities which a business analyst would need to know. The BoK does not instruct. Figure 4 is one of the official BABOK illustrations.
Figure 4 BABOK
However, the knowledge areas (summarized and listed below) do provide information about what a business analyst would need to know in order to use a certain methodology. The knowledge areas do seem to follow a progressive sequence; this should not be taken as an indication that it should be used as a step-by-step guide to performing the job of a business analyst.
BABOK Knowledge areas
1. Business Analysis Planning and Monitoring
2. Requirements Management and
3. Enterprise Analysis
4. Elicitation
5. Requirements Analysis
6. Solution Assessment and Validation
7. Underlying Competencies.
5. ITIL®
So much has been written about ITIL that adding more seems a redundant exercise. We have mentioned in the new BiSL book that much of the material in ’the first BiSL’ that pertained to what
was then called the ‘Use’ domain and a significant portion of the Change and Transition management activities was inspired by ITIL (One of the official ITIL models for version 3 and ITIL 2011 is reproduced at Figure 5.
Figure 5 ITIL model (V3 and ITIL 2011)
What is important is that where services such as incident or change management do not exist, or where a service desk fails to offer adequate support, BIM identifies improvements or requirements and ensures that ITIL or a similar framework is employed to build outline processes and procedures and that these are then tailored specifically for information service support.
A Help Desk provides a day-to-day contact point between customers and IT Services. It is responsible for dealing with customer queries and problems with IT services, for overseeing the restoration of normal service on the customers’ behalf following incidents, and for disseminating day-to-day information about changes and service developments to customers.
Effective customer liaison means building relationships with customers, and assisting customers to make the best possible use of IT services available to them. The Help Desk can make an important contribution to effective liaison.
Help Desk and customer liaison staff must work closely together, and both may be part of an overall Customer Services function within IT Services. Service level management is the process of managing the quality of delivered information services in the face of changing business needs and customer requirements (most often laid out in a service level agreement between customers and supplier).
Properly established, a SLA sets out customer expectations, customer and supplier obligations and forms a common basis for measuring the quality of customer support over and above that provided by change management personnel.
Both change management staff and customer liaison staff may be part of a Customer Services function within an IT Service Management team, and both may either be duplicated for BIM or cross trained in all aspects of information service and IT support.
In ITIL, Capacity Management is concerned with the provision and management of business and technical capacity to ensure required service levels can be achieved. Projections of business volumes and customer requirements provide an important input to capacity plans, and must come from the customer, usually via the Service Level Manager. Customer liaison staff make customers aware of the capacity implications of changing business operations and may arrange to have them evaluated. It is not just about performance management for hardware.
From the basic information above you can discern the value of locating and befriending your local ITIL expert (just make sure they are not one of the disciples that believe ITIL is Lord of the Frameworks!).
6 Gateway TM
Originating in the private sector, adopted and adapted by initially the UK OGC and then by the Dutch government, ‘Gateway’ is a method used to identify and better manage programmes that are both expensive and high risk. A significant challenge at executive level, particularly in the government sector is the need to reduce the number of programmes and projects that either fail, or fail to meet needs, or worse fail to meet need and value. Governance should focus on enterprise wide solutions being less of a risk, the issue is ensuring everyone understands the complexity of major changes and has responsibility to ensure success. Robust service design and robust management is the only way
that success can be assured, and irrespective of the pressure ‘to be agile’, some significant planning and architectural design must be governed.
Gateway is extensively used in government to ‘de-risk’ major programmes of work by ensuring that a business case is in existence and is relevant and useful, that all financial issues have been discussed and that funds are available and that resources will be available to complete the work. Gateway goes on to consider even the ‘end game’ what happens when the product or service (or building such as a hospital….) is no longer required. In many respects it is a need and value method.
The Gateway Process defines review gates or points throughout the lifecycle of acquisition and/or implementation of products and/or services. Gateways are undertaken for all levels of procurement projects, as defined by the Project Profile Model. Requests for Gateway Reviews are initiated by Senior Responsible Owners/Project Owners.
More information
More information about the alignment of popular frameworks and BiSL1 can be found on the ASL BiSL Foundation website.
Relevant reading
Title: BiSL® Next
ISBN: 9789401800396
Author: Brian Johnson, Gerard Wijers, Lucille van der Hagen
Price: € 42.35
Trademark notices
ASL® and BiSL® are registered trademarks of ASL BiSL Foundation BABOK® is a registered trademark of IIBA.COBIT® is a registered trademark of ISACA. GatewayTM is a registered trademark of OGC.
ITIL® , P3O®, MSP® and PRINCE2® are registered trademarks of AXELOS Limited. TOGAF® is a registered trademark of The Open Group.