| 1Introduction | 2Serv. Mgmt. | 3Principles | 4Processes | 5Tech Activities | 6Organization | 7Tech Considerations | 8Implementation | 9Challenges | Appendeces |
| 3.1Goals | 3.2Balance | 3.3Serv Reqmnts | 3.4Fundamentals | 3.5Activities | 3.6Aspects | 3.7Later Activities | 3.8Constraints | 3.9SoA | 3.10Bus.Reqmnts | 3.11Models |
| "See first that the design is wise and just: that ascertained, pursue it resolutely; do not for one repulse forego the purpose that you resolved to effect." William Shakespeare (1564-1616) |
| "The common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams |
|
|
| Figure 3.1 The business change process |
IT Service Design is a part of the overall business change process. This business change process and the role of IT are illustrated in Figure 3.1.
Once accurate information has been obtained on what is required and signed off, with regard to the changed needs of the business, the plan for the delivery of a service to meet the agreed need can be developed.
The role of the Service Design stage within this overall business change process can be defined as:
| 'The design of appropriate and innovative IT services, including their architectures, processes, policies and documentation, to meet current and future agreed business requirements.' |
It is important that the right interfaces and links to the design activities exist. When designing new or changed services, it is vital that the entire Service Lifecycle and ITSM processes are involved from the outset. Often difficulties occur in operations when a newly designed service is handed over for live running at the last minute. The following are actions that need to be undertaken from the outset of a Service Design to ensure that the solution meets the requirements of the business:
|
| Figure 3.2 Service composition |
The composition of a service and its constituent parts is illustrated in Figure 3.2.
Service Design must consider all these aspects when designing service solutions to meet new and evolving business needs:
The design activities must not just consider each of the components above in isolation, but must also consider the relationships between each of the components and their interactions and dependencies on any other components and services, in order to provide an effective and comprehensive solution that meets the business needs.
3.1 Goals
The main goals and objectives of Service DesignR are to:
Supporting Material |
![[To top of Page]](../../../images/up.gif){kind=small}
3.2 Balanced Design
For any new business requirements, the design of services is a delicate balancing act, ensuring that not only the functional requirements but also the performance targets are met. All of this needs to be balanced with regard to the resources available within the required timescale and the costs for the new services. Jim McCarthy, author of Dynamics of Software Development, states: 'As a development manager, you are working with only three things':
These are shown in Figure 3.3.
|
| Figure 3.3 Project elements in a triangulated relationship |
This concept is extremely important to Service Design activities and to the balance between the effort that is spent in the design, development and delivery of services in response to business requirements. Service Design is a delicate balancing act of all three elements and the constant dynamic adjustment of all three to meet changing business needs. Changing one side of the triangle invariably has an impact on at least one of the other sides if not both of them. It is vital therefore that the business drivers and needs are fully understood in order that the most effective business solutions are designed and delivered, using the most appropriate balance of these three elements. It is likely that business drivers and needs will change during design and delivery, due to market pressures. The functionality and resources should be considered for all stages of the Service Lifecycle, so that services are not only designed and developed effectively and efficiently, but that the effectiveness and efficiency of the service is maintained throughout all stages of its lifecycleN.
Due consideration should be given within Service Design to all subsequent stages within the Service Lifecycle. Often designers and architects only consider the development of a new service up to the time of implementation of the service into the live environment. A holistic approach to the design of IT services should be adopted to ensure that a fully comprehensive and integrated solution is designed to meet the agreed requirements of the business. This approach should also ensure that all of the necessary mechanisms and functionality are implemented within the new service so that it can be effectively managed and improved throughout its operational life to achieve all of its agreed service targets. A formal, structured approach should be adopted to ensure that all aspects of the service are addressed and ensure its smooth introduction and operation within the live environment.
The most effective IT service providers integrate all five aspects of designR rather than design them in isolation. This ensures that an integrated Enterprise Architecture is produced, consisting of a set of standards, designs and architectures that satisfy all of the management and operational requirements of services as well as the functionality required by the business. This integrated design ensures that when a new or changed service is implemented, it not only provides the functionality required by the business, but also meets and continues to meet all its service levels and targets in all areas. This ensures that no (or absolute minimum) weaknesses will need to be addressed retrospectively.
In order to achieve this, the overall management of these design activities needs to ensure:
3.3 Identifying Service Requirements
|
| Figure 3.4 The service relationships and dependencies |
Service Design must consider all elements of the service by taking a holistic approach to the design of a new service. This approach should consider the service and its constituent components and their inter-relationships, ensuring that the services delivered meet the functionality and quality of service expected by the business in all areas:
No service can be designed, transitioned and operated in isolation. The relationship of each service to its supporting components and services must be clearly understood and recognized by all people within the service provider organization. It is also essential that all targets contained within supporting agreements, such as OLAs and contracts, underpin those agreed between the service provider and its customers. Some of these concepts are discussed in more detail in later sections of the publication, with respect to the individual aspects of Service Design. However, when an individual aspect of a service is changed, all other areas of the service should also be considered to ensure that any amendments necessary to support the change are included in the overall design. Increasingly, services are complex and are delivered by a number of partner or supplier organizations. Where multiple service providers are involved in delivery of a service, it is vital that a central Service Design authority is established, to ensure services and processes are fully integrated across all parties.
Within the specific area of technology there are four separate technology domains that will need to be addressed, as they are the supporting components of every service and contribute to its overall performance:
3.4 Identifying And Documenting Business Requirements And Drivers
IT must retain accurate information on business requirements and drivers if it is to provide the most appropriate catalogue of services with an acceptable level of service quality that is aligned to business needs. Business drivers are the people, information and tasks that
support the fulfillment of business objectives. This requires that IT develops and maintains close, regular and appropriate relationships and exchange of information in order to understand the operational, tactical and strategic requirements of the business. This information needs to be obtained and agreed in two main areas to maintain service alignment:
This collection of information is the first and most important stage for designing and delivering new services or major changes to existing services. The need for accurate and representative information from the business is paramount. This must be agreed and signed off with senior representatives within the business. If incorrect or misleading information is obtained and used at this stage, then all subsequent stages will be delivering services that do not match the needs of the business. Also, there must be some formal process for the agreement and acceptance of changes to the business requirements, as these will often change and evolve during the Service Lifecycle. The requirements and the design must evolve with the changing business environment to ensure that the business expectations are met. However, this must be a carefully managed process to ensure that the rate of change is kept at an agreed and manageable level, and does not 'swamp' and excessively delay the project or its implementation.
In order to design and deliver IT services that meet the needs of the customers and the business, clear, concise, unambiguous specifications of the requirements must be documented and agreed. Time spent in these activities will prevent issues and discussion from arising later with regard to variances from customer and business expectation. This business requirements stage should consist of:
Where service requirements are concerned, they sometimes come with a price tag (which might not be entirely known at this stage), so there always needs to be a balance between the service achievable and the cost. This may mean that some requirements may be too costly to include and may have to be dropped during the financial assessment involved within the design process.
If this is necessary, all decisions to omit any service requirements from the design of the service must be documented and agreed with the representatives of the business. There is often a difficulty when what the business wants and the budget allocated for the solution do not take into account the full service costs, including the ongoing costs.
Key messageArchitectures and designs should be kept, clear, concise, simple and relevant. All too often, designs and architectures are complex and theoretical and do not relate to the 'real world'. |
The main problem today is that organizations often only focus on the functional requirements. A design or architecture by definition needs to consider all design aspects. It is not a smaller organization that combines these aspects, it is a sensible one.
Design Inputs
|
|
Design Activities
|
|
|
Design Deliverables
|
Supporting Material |
3.6 Design Aspects
An overall, integrated approach should be adopted for the design activities documented in the previous section and should cover the design of:
The key aspect is the design of new or changed service solutions to meet changing business needs. Every time a new service solution is produced, it needs to be checked against each of the other aspects to ensure that it will integrate and interface with all of the other services already in existence. These five aspects of Service Design are covered in more detail in the following sections. The plans produced by Service Design for the design, transition and subsequent operation of these five different aspects should include:
|
| Figure 3.5 Aligning new services to business requirements |
There are many activities that have to be completed within the Service Design stage for a new or changed service. A formal and structured approach is required to produce the new service at the right cost, functionality, quality and within the right time frame. This process and its constituent stages are illustrated in Figure 3.5, together with the other major areas that will need to be involved within the process. This process must be iterative/incremental to ensure that the service delivered meets the evolving and changing needs of the business during the business process development and the IT Service Lifecycle. Additional project managers and project teams may need to be allocated to manage the stages within the lifecycle for the deployment of the new service.
The role of the project team within this activity of delivering new and changing IT services to the business and its relationship to design activities is illustrated in Figure 3.5.
Figure 3.5 shows the lifecycle of a service from the initial or changed business requirement through the design, transition and operation stages of the lifecycle. It is important that there is effective transfer of knowledge at all stages between the operational staff and the project staff to ensure smooth progression through each of the stages illustrated.
The areas that need to be considered within the design of the service solution should include:
See Figure 3.6. Ideally the Service Portfolio should form part of a comprehensive Service Knowledge Management System (SKMS) and registered as a document in the Configuration Management System (CMS). Further information is provided on both the CMS and the SKMS within the Service Transition publication.
Figure 3.6 is a depiction of the relationship of the Service Portfolio with the SKMS.
|
| Figure 3.6 The Service Portfolio - a central repository |
|
| Figure 3.7 The Service Portfolio and its contents |
Once a strategic decision to charter a service is made, this is the stage in the Service Lifecycle when Service Design begins architecting the service, which will eventually become part of the Service Catalogue. The Service Portfolio should contain information relating to every service and its current status within the organization. The options of status within the Service Portfolio should include:
The Service Portfolio would therefore contain details of all services and their status with respect to the current stage within the Service Lifecycle, as illustrated in Figure 3.7.
Customers and users would only be allowed access to those services within the Service Portfolio that were of a status between 'chartered' and 'operational', as illustrated by the box in Figure 3.7, i.e. those services contained within the Service Catalogue. Service Strategy and Service Design personnel would need access to all records within the Service Portfolio, as well as other important areas such as Change Management. Other members of the service provider organization would have access to a permitted subset of the records within the Service Portfolio. Although the Service Portfolio is designed by Service Design, it is owned and managed by Service Strategy within the Service Portfolio Management process. Full details on Service Portfolio Management are discussed in the Service Strategy publication.
The Service Pipeline is a subset of the overall Service Portfolio and contains details of all of the business requirements that have not yet become services released to the live environment. It is used as a basis for the definition, analysis, prioritization and approval, by the ISG and Service Strategy, of all requests for new or changed services, to ensure that new and changed services are aligned to business requirements. It will principally be used as input to the activities of the Service Strategy and Service Design stages of the Service Lifecycle. It also provides valuable input to the activities of the Service Transition stage of the lifecycle in determining the services to be released. The Service Catalogue Management process must ensure that all of the details within the Service Portfolio are accurate and up-to-date as the requirement and its new or changed service is migrated into the live environment. This will involve close liaison with all Service Transition activities.
Various elements of the same service can have different statuses at the same time. Otherwise the Service Portfolio would be unable to support 'incremental and iterative' development. Each organization should carefully design its Service Portfolio, the content and the access allowed to the content. The content should include:
'Architecture' is a term used in many different contexts. In this context it is defined as:
| The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. |
'System' in this definition is used in the most general, not necessarily IT, sense:
| 'a collection of components organized to accomplish a specific function or set of functions'. |
So the system could be, for example, a whole organization, a business function, a product line or an information system. Each of these systems will have an 'architecture' as defined earlier, made up of the components of the system, the relationships between them (such as control interfaces and data exchanges), the relationships between the system and its environment (political, organizational, technological, etc.) and the design principles that inform, guide and constrain its structure and operation, as well as its future development.
In essence, architectural design can be defined as:
| 'The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization.' |
The work of architectural design needs to assess and reconcile many types of needs, some of which may be in conflict with one another. The work should ensure that:
|
| Figure 3.8 Enterprise Architecture |
The architectural design activities should use input from the business, Service Strategy, its plans, designers and planners to develop appropriate designs, plans, architectures and policies for all areas of IT. These designs, plans, architectures and policies should cover all aspects of IT, including roles and responsibilities, services, technology, architecture and frameworks, processes and procedures, partners and suppliers and management methods. The architectural design process must also cover all areas of technology, including the infrastructure, environment, applications and data and be closely linked to the overall business planning and design processes.
Any enterprise is a complex system, with many types of components including its staff, business functions and processes, organizational structure and physical distribution, information resources and information systems, financial and other resources including technology, and the strategies, plans, management, policies and governance structures that drive the enterprise. An Enterprise Architecture should show how all these components (and others) are integrated in order to achieve the business objectives, both now and in the future.
The complete Enterprise Architecture can be large and complex. Here we are interested in those architectures concerned with the business of the organization and the information systems that support it. Each of these architectures calls on distinct architectural disciplines and areas of expertise, as illustrated in Figure 3.8.
Enterprise Architecture is defined by Gartner as:
| 'the process of translating business vision and strategy into effective enterprise change, by creating, communicating and improving key principles and models that describe the enterprise's future states and enable its evolution'. |
There are many proprietary and non-proprietary frameworks for the development of an Enterprise Architecture, as illustrated in Table 3.1.
These frameworks include descriptions of the organizational structure, business processes, planning and control systems, management and governance mechanisms, policies and procedures of the enterprise. They show how these components inter-operate and contribute to the achievement of business goals and objectives, and provide the basis for identifying the requirements for information systems that support these business processes.
| Full Framework Name | Framework acronym |
 Architecture of Integrated Information Systems Framework | ARIS |
| Bredemeyer Framework | Bredemeyer |
| Business Transformation Enablement Programme Transformation Framework | BTEP |
| Command, Control, Communications, Computers Intelligences Surveillance and Reconnaissance | C41SR |
| CSC Catalyst | Catalyst |
| Computer Integrated Manufacturing Open Systems Architecture | CIMOSA |
| Enterprise Architecture Framework | Gartner |
| Enterprise Architecture Planning | EAP |
| Extended Enterprise Architecture Framework | E2AF |
| FEA Reference Models | FEA |
| Generalized Enterprise Reference Architecture and Methodology | GERAM |
| Integrated Architecture Framework | IAF |
| Pillars of EA | Forrester |
| Reference Model for Open Distributed Processing | RM-ODP |
| Technical Architectural Framework Information Management | TAFIM |
| Treasury Enterprise Architecture Framework | TEAF |
| TOGAF Technical Reference Model | TOGAF |
| Zachman Framework | Zachman |
| Table 3.1 Enterprise Architecture frameworks | |
The Enterprise Architecture should be an integrated element of the Business Architecture and should include the following major areas:
|
| Figure 3.9 Architectural relationships |
Within the framework described earlier, it is possible to identify (at least) three architectural roles. These could all report to a senior 'Enterprise Architect' in the organization:
In some organizations, the roles of Business/Organizational Architect, Information Systems Architect (or possibly separate roles of Applications Architect and Data Architect) and IT Infrastructure Architect will be separate functions. In others, some or all of the roles may be combined. The roles may reside in separate parts of the organization or even outside it. For example:
If architecture design is to be accomplished effectively and economically, the documents, processes and activities of the business and architectural design should be closely coordinated and synchronized. A list of these design documents and their content is contained in Appendices C and D. The individual details of technology included within architectural design are considered in the following sections.
Key messageThe real benefit and ROl of the Enterprise Architecture comes not from the architecture itself, but from the ability of an organization to design and implement projects and solutions in a rapid and consistent manner. |
Architectures need to be developed within the major areas of technology.
Technology Architectures
Architectures are needed in all areas of IT infrastructure. Where relevant they need to be developed in the following areas:
This will result in a hierarchy of architectures, which will need to be dovetailed to construct an integrated set of technology architectures for the organization. The Infrastructure Architecture should aim to provide relatively few standardized platforms for hosting applications. It must also lay down standards for application architectures that are to be hosted in controlled data centres so that these fit in with the standardized operating, monitoring and security requirements.
Management Architectures
IT must manage costs, deliver the right services at the right time, secure information assets, provide dependable service and lead the business in leveraging technologies. This requires automated procedures and management tools in order to achieve this effectively and efficiently. The selection of an appropriate management architecture is key to establishing the required level of control and automation. There are two separate approaches to developing a management architecture:
The challenges for IT management are to coordinate and work in partnership with the business in the building of these management solutions, supporting the appropriate processes and providing the required measurements and metrics. This has to be achieved while reducing or optimizing the costs involved, particularly the annual, ongoing costs. The best way of minimizing costs is to design cleverly and carefully - for example, making best use of capacity so that additional capacity is not unnecessarily bought (with its associated ongoing costs), or designing a backup/recovery solution that doesn't require a complete additional set of infrastructure. Considerable costs can be saved by intelligent and careful design, using technology that is supportable and causes few problems in the operational environment.
The main method of realizing these goals is to design solutions that give a reduction in the overall network management and support costs, while maintaining or even improving the quality of service delivered to the business.
To gain the greatest benefit from the use of the Four Ps, organizations should determine the roles of processes and people, and then implement the tools to automate the processes, facilitating people's roles and tasks. The best way of achieving this is to develop a model or architecture based on these principles. This architecture should facilitate the implementation of a set of integrated tools and processes that support 'end-to-end' management of all areas of the technology used, ensuring that there are no gaps and no 'technical silos'.
However, IT faces a big challenge in developing and maintaining the soft skills required to perform these management roles and processes effectively. In the truly efficient organizations, these roles and processes are aligned to those of the business. This ensures that the business and IT Management processes and information have similar targets and goals. However, all too often, organizations devote insufficient time and effort to the development of the soft skills (for example, interpersonal skills, communication skills, meeting skills) necessary for the processes and the business alignment to be effectively achieved.
There are five areas that need to be considered with regard to the design of a management architecture, as illustrated in Figure 3.10.
|
| Figure 3.10 Integrated business-driven technology management |
The relationships between these architectural perspectives can be seen in the diagram above. The development, documentation and maintenance of business and IT architectures will typically form part of the processes of strategic thinking and strategy development in the organization.
These five management areas to be considered can be briefly defined as:
Such an architecture can be used to design and implement efficient, effective and integrated management solutions that are aligned to the business requirements of the organization and its Business Managers. This management architecture can be applied within an organization to:
These bullet points are also illustrated in Figure 3.10.
The key to the development of a management architecture is to ensure that it is driven by business needs and not developed for IT needs in isolation:
| Management architectures need to be: '... business aligned, NOT technology driven'. |
Within this overall structure, a management architecture is needed that can be applied to all areas of IT Management and not just to individual isolated areas. This can then be implemented in a coordinated programme of inter-working, to provide overall end-to-end Enterprise Management so essential to the effective management of today's IT infrastructure. If only individual areas buy into the architecture, then individual 'islands of excellence' will develop and it will be impossible to provide the complete end-to-end solutions required to support today's e-business solutions.
As well as ensuring that all areas of the IT are integrated, it is vital that the management architecture is developed from the business and service perspective (i.e. 'top down'). Therefore, the key elements to agree and define before developing the management architecture are:
These are the key elements that need to be determined by SLM and IT Management. They provide crucial input to the development of business-focused management architectures. All too often management tools and processes have been focused on components and component management rather than services and business processes. This needs to be changed, with emphasis clearly on the design of management systems, processes and tools that are driven by business needs and are focused on the management of business processes and IT services. If the appropriate management architecture is designed and implemented, this will allow Service Management processes to focus on managing services and service quality and operate from end-to-end across the entire IT enterprise, providing true Enterprise Service Management. This will truly facilitate the management of services to ensure that services and service quality are closely aligned to the needs of the business.
The architectures described suggest that the future of network and systems management will be less focused on the technology and become more integrated with the overall requirements of the business and IT Management. These new systems and processes are already starting to evolve as the management standards for the exchange of management information between tools become more fully defined, by organizations such as the Distributed Management Task Force (DMTF). In essence, management systems will become:
A process is a structured set of activities designed to accomplish a specific objective. A process takes one or more inputs and turns them into defined outputs. A process includes all of the roles, responsibilities, tools and management controls required to reliably deliver the outputs. A process may also define or revise policies, standards, guidelines, activities, processes, procedures and work instructions if they are needed.
Process control can be defined as:
| The activity of planning and regulating a process, with the objective of performing a process in an effective, efficient and consistent manner. |
|
| Figure 3.11 The generic process elements |
Processes, once defined, should be documented and controlled. Once under control, they can be repeated and become manageable. Degrees of control over processes can be defined, and then process measurement and metrics can be built in to the process to control and improve the process, as illustrated in Figure 3.11. The activity of planning and regulating a process, with the objective of performing a process in an effective, efficient and consistent manner.
The generic process elements show data enters the process, is processed, is output and the outcome is measured and reviewed. This very basic description underpins any process description. A process is always organized around a set of objectives. The main outputs from the process should be driven by the objectives and should always include process measurements (metrics), reports and process improvement.
Each process should be owned by a process owner, who should be responsible for the process and its improvement and for ensuring that a process meets its objectives. The objectives of any IT process should be defined in measurable terms and should be expressed in terms of business benefits and underpinning business strategy and goals. Service Design should assist each process owner with the design of processes, in order to ensure that all processes use standard terms and templates, are consistent and integrate with each other to provide end-to-end integration across all areas.
The output produced by a process has to conform to operational norms that are derived from business objectives. If products conform to the set norm, the process can be considered effective (because it can be repeated, measured and managed). If the activities are carried out with a minimum use of resources, the process can also be considered efficient. Process analysis, results and metrics should be incorporated in regular management reports and process improvements.
All these areas should be included within the design of any process. These new ITIL publications have been written around 'sets of processes' that reflect the stages in the lifecycle of a service. The Service Design set of processes detailed in this publication covers the processes principally related to all aspects of design.
Working with defined processes has been the foundation of ITIL from its beginning. By defining what the organization's activities are, which inputs are necessary and which outputs will result from the process, it is possible to work in a more efficient and effective manner. Measuring and steering the activities increases this effectiveness. Finally, by adding norms to the process, it is possible to add quality measures to the output.
This approach underpins the Plan-Do-Check-Act cycle of continual improvement for any quality-management system. Plan the purpose of the process in such a way that process actions can be reviewed, assessed or audited for successful achievement and improved.
Norms define certain conditions that the results should meet. Defining norms introduces quality aspects to the process. Even before starting, it is important to think about what the process outcomes should look like. To discover whether or not process activities are contributing optimally to the business goal and the objectives of the process, aligned to business goals, the effectiveness should be measured on a regular basis. Measuring allows comparison of what has actually been done with what the organization set out to do, and to identify and implement improvements within the process.
Each organization should adopt a formalized approach to the design and implementation of Service Management processes. The objective should not be to design 'perfect processes', but to design practical and appropriate processes with 'in-built' improvement mechanisms, so that the effectiveness and efficiency of the processes are improved in the most suitable manner for the organization. Documentation standards, processes and templates should be used to ensure that the processes are easily adopted throughout the organization. Some example process documentation templates are included in Appendix C.
The goal for now and in the future is to design processes and support these with tools that can provide integration between organizations. This has now become possible because management tools are providing support of open standards, such as the Distributed Management Task Force (DMTF), that support the exchange of information based on ITIL concepts, such as incidents, problems and changes with standard formats and contents. This allows service providers to support efficient and effective process interfaces with their main suppliers with automated exchange of key operational information in real time.
'If you can't measure it then you can't manage it.'
Care should be exercised when selecting measurements and metrics and the methods used to produce them. This is because the metrics and measurements chosen will actually affect and change the behaviour of people working within the activities and processes being measured, particularly where this relates to objectives, personal and team performance and performance-related pay schemes. Therefore, only measurements that encourage progression towards meeting business objectives or desired behavioural change should be selected.
In all the design activities the requirement should be to:
Measurement methods and metrics should reflect these requirements and be designed to measure the ability of design processes to match these requirements. All of the measurements and metrics used should reflect the quality and success of the design processes from the perspective of the business, customers and users. They need to reflect the ability of the delivered solutions to meet the identified and agreed requirements of the business.
The process measurements selected need to be appropriate for the capability and maturity of the processes being measured. Immature processes are not capable of supporting sophisticated measurements, metrics and measurement methods. There are four types of metrics that can be used to measure the capability and performance of processes:
Measurements and metrics should develop and change as the maturity and capability of a process develops. Initially, with immature processes the first two levels of metrics should be used to measure the progress and compliance of the process as it develops in maturity. As the process maturity develops, greater use should be made of effectiveness and efficiency metrics, but not to the detriment of compromising the progress or compliance of the process.
|
| Figure 3.12 The Metrics Tree |
The selection of the metrics, the point of measurement and the methods of measuring, calculating and reporting on the metrics must be carefully designed and planned. The primary metrics should always focus on determining the effectiveness and the quality of the solutions provided. Secondary metrics can then measure the efficiency of the processes used to produce and manage the solution. The priority should always be to ensure that the processes provide the correct results for the business. Therefore, the measurement methods and metrics should always provide this business-focused measurement above all.
The most effective method of measurement is to establish a 'Metrics Tree' or 'KPI tree'. Too many organizations collect measurement in individual areas, but fail to aggregate them together and gain the full benefit of the measurements, and therefore suffer because:
Therefore organizations should attempt to develop automated measurement systems based on a form of 'Metrics Tree' such as that illustrated in Figure 3.12.
The tree in Figure 3.12 is illustrative of an example of a Metrics Tree based on a typical Balanced Scorecard. Balanced Scorecards represent a management system that enables increasing numbers of organizations to clarify their vision and strategy into action. They provide feedback regarding the internal business processes and external outcomes in order continually to improve strategic performance and results. This enables everybody within the organization to get a picture of the performance of the organization at the appropriate level:
This means that within a hierarchical metrics system, each person in the organization can get access to an appropriate level of information and measurement that suits their particular need. It gives senior management the opportunity to monitor a top-level dashboard to ensure that services continue to be delivered to their agreed levels, and it also provides the capability for technical specialists and processes owners to drill down to the detail to analyse variance from agreed service, component or process performance.
Obviously the collection, analysis and presentation of this data can be a very labour-intensive activity and therefore should be automated wherever possible. This can be achieved using analysis tools based on macros, scripts, spreadsheets, or preferably on specific web-based solutions. The measurements at each of the levels should be specifically defined to meet the needs of the business, customers and users of the information.
More detailed information on measurements, metrics and measurement methods are contained in the Continual Service Improvement publication.
Supporting Material |
Careful project management will need to be used to ensure that conflict is avoided and that the compatible components are developed from the various different development activities.
| All design activities operate within many constraints. These constraints come from the business and Service Strategy and cover many different areas, as illustrated in Figure 3.13. This means that designers are not always 'free' to design the most appropriate solution for the business, because it does not fall within the imposed constraints, as illustrated in Figure 3.13. The most obvious constraint is the financial one. There may be insufficient budget available for the most appropriate solution, therefore a cheaper alternative service would have to be identified and agreed with the business. The designer can only provide the solution that fits within all of the currently known constraints, or else try lifting or renegotiating some of the constraints - for instance, by obtaining a bigger budget. In Figure 3.13, not only will more budget need to be obtained to implement the desired solution, but it would also be non-compliant with some of the relevant standards and regulations. So in this case an alternative, cheaper compliant solution would be probably be required. So the Service Design processes must recognize the fact that they are free to design solutions, but they are working in an environment where many external factors can influence the design. |
|
| Figure 3.14 External influences on solution design |
Many of these external influences are from the need for good corporate and IT governance, and others are from the requirement for compliance with regulations, legislation and international standards, as illustrated in Figure 3.14. It is essential, therefore, that all designers recognize these and ensure that the designs and solutions they produce have all of the necessary controls and capability within them.
3.9 Service Oriented Architecture
Business process and solutions should be designed and developed using a Service Oriented Architecture (SOA) approach. The SOA approach is considered best practice and is used by many organizations to improve their effectiveness and efficiency in the provision of IT services.
SOA is defined by OASIS as:
| 'A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.' |
OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. SOA brings value and agility to an organization by encouraging the development of 'self-contained' services that are re-usable. This, in turn, promotes a flexible and modular approach to the development of 'shared services' that can be used in many different areas of the business. More and more organizations are converting business processes to common 'packaged services' that can be used and shared by many areas of the business.
Wherever possible, IT service provider organizations should use the SOA and principles to develop flexible, re-usable IT services that are common and can be shared and exploited across many different areas of the business. When this approach is used, it is essential that IT:
When SOA principles are used by the IT service provider organization, it is critical that an accurate Service Catalogue is maintained as part of an overall Service Portfolio and Configuration Management System (CMS). Adopting this approach can significantly reduce the time taken to deliver new solutions to the business and to move towards a Business Service Management (BSM) capability. The Service Catalogue will also show the relationship between services and applications. A single application could be part of more than one service, and a single service could utilize more than one application.
3.10 Business Service Management
| Business Service Management (BSM) is a strategy and an approach to enable IT components to be linked to the goals of the business. This way the impact of technology on the business and how business change may impact technology can both be predicted. The creation of a totally integrated Service Catalogue - including business units, processes and services, and their relationships and dependencies on IT services, technology and components - is crucial to increasing the IT service provider's capability to deliver BSM. All aspects of Service Design are vital elements in supporting and enhancing the Business Service Management capability of the IT service provider, particularly the design of the Service Portfolio, the Service Catalogue and the individual IT services. All of these activities will also improve the alignment of IT service provision with business and its evolving needs. See Figure 3.15.
BSM enables an IT service provider organization to:
|
3.11 Service Design Models
The model selected for the design of IT services will depend mainly on the model selected for the delivery of IT services. Before adopting a design model for a major new service, a review of the current capability and provisions with respect to all aspects of the delivery of IT services should be conducted. This review should consider all aspects of the new service, including the:
This review/assessment provides a structured mechanism for determining an organization's capabilities and state of readiness for delivering new or revised services in support of defined business drivers and requirements. The information obtained from such an assessment can be used in determining the delivery strategy for a particular IT service or IT system. The delivery strategy is the approach taken to move an organization from a known state, based on the readiness assessment, to a desired state, determined by the business drivers and needs. There are many ways to prepare an organization for deploying a new service. The method and strategy selected should be based on the solution the organization chooses for fulfilling its key business drivers, as well as the capabilities of the IT organization and its partners. The scale of options available is quite large, and not every option needs be considered in every case. However, keeping all the options available for consideration is key for designing and operating innovative solutions to the most difficult business challenges. In the end, this may be the difference between a failed project - or even a failed company - and a successful one.
These two models, for the design and delivery of IT services, are closely related and are considered in the following two sections.
Table 3.2 highlights a key point: the set of delivery strategies varies widely and ranges from a relatively straightforward situation, solely managed within the boundaries of a company, all the way to a full KPO situation. This broad range of alternatives provides significant flexibility, but often with added complexity, and in some cases additional risk. The advantages and disadvantages of each type of delivery strategy are discussed in Table 3.3 below.
All of the above arrangements can be provided in both an off-shore or on-shore situation. In the on-shore case, both organizations are based within the same country/ continent, whereas in the off-shore situation the organizations are in different countries/continents. Very complex sourcing arrangements exist within the IT industry and it is impossible to cover all combinations and their implications here. ITIL Service Management Practice Complementary Series will provide additional guidance on sourcing strategies.
Mergers and acquisitions can also complicate the issues. These situations occur when one company acquires or merges with another company for cash and/or equity swaps of the company's stock. Again, this occurs generally in response to industry consolidations, market expansion, or in direct response to competitive pressures. If companies that have different service delivery strategies are acquired or merge, a period of review and consolidation is often required to determine the most appropriate sourcing strategy for the newly merged organization. However, mergers and acquisitions can often provide organizations with the opportunity to consolidate the best practice from each organization, thereby improving the overall service capability and achieving synergies across the organization. Opportunities will also exist to provide improved career development options to Service Management personnel and to consolidate supplier contract for services.
| Delivery strategy | Description |
| Insourcing | This approach relies on utilizing internal organizational resources in the design, development, transition, maintenance, operation and/or support of new, changed or revised services or data centre operations |
| Outsourcing | This approach utilizes the resources of an external organization or organizations in a formal arrangement to provide a well defined portion of a service's design, development, maintenance, operations and/or support. This includes the consumption of services from Application Service Providers (ASPS) described below |
| Co-sourcing | Often a combination of insourcing and outsourcing, using a number of outsourcing organizations working together to co source key elements within the lifecycle. This generally involves using a number of external organizations working together to design, develop, transition, maintain, operate and/or support a portion of a service |
| Partnership or multi-sourcing | Formal arrangements between two or more organizations to work together to design, develop, transition, maintain, operate and/or support IT service(s). The focus here tends to be on strategic partnerships that leverage critical expertise or market opportunities. |
| Business Process Outsourcing (BPO) | The increasing trend of relocating entire business functions using formal arrangements between organizations where one organization provides and manages the other organization's entire business process(es) or functions(s) in a low-cost location. Common examples are accounting, payroll and call centre operations |
| Application Service Provision | Involves formal arrangements with an Application Service Provider (ASP) organization that will provide shared computer based services to customer organizations over a network. Applications offered in this way are also sometimes referred to as on-demand software/applications. Through ASPs, the complexities and costs of such shared software can be reduced and provided to organizations that could otherwise not justify the investment |
| Knowledge | Process Outsourcing (KPO) The newest form of outsourcing, KPO is a step ahead of BPO in one respect. KPO organizations provide domain-based processes and business expertise rather than just process expertise, and require advanced analytical and specialized skills from the outsourcing organization |
| Table 3.2 Main service delivery strategies | |
| Delivery strategy | Advantages | Disadvantages |
| Insourcing | Direct control Freedom of choice Rapid prototyping of leading-edge services Familiar policies and processes Company-specific knowledge | Scale limitations Cost and time to market for services readily available outside Dependent on internal resources and their skills and competencies |
| Outsourcing | Economies of scale Purchased expertise Supports focus on company core competencies Support for transient needs Test drive/trial of new services | Less direct control Exit barriers Solvency risk of suppliers Unknown supplier skills and competencies More challenging business process integration Increased governance and verification |
| Co-sourcing | Time to market Leveraged expertise ControlUse of specialized providers | Project complexity Intellectual property and copyright protection Culture clash between companies |
| Partnership or multi-sourcing | Time to market Market expansion/entrance Competitive response Leveraged expertise Trust, alignment and mutual benefit 'Risk and reward' agreements | Project complexity Intellectual property and copyright protection Culture clash between companies |
| Business Process Outsourcing (BPO) | Single point of responsibility One-stop shop' Access to specialist skills Risk transferred to the outsource Low-cost location | Culture clash between companies Loss of business knowledge Loss of relationship with the business |
| Application Service Provision | Access to expensive and complex solutions Low-cost location Support and upgrades included Security and ITSCM options included | Culture clash between
companies Access to facilities only, not knowledge Often usage-based charging models |
| Knowledge Process Outsourcing (KPO) | Access to specialist skills, knowledge and expertise Low-cost location Significant cost savings | Culture clash between companies Loss of internal expertise Loss of relationship with the business |
| Table 3.3 Advantages and disadvantages of service delivery strategies | ||
ExampleA medium size bank merged with another bank that had a complementary product portfolio. Therefore the integration of applications was simple. However, the two banks felt that consolidation of operations would be beneficial, but could not leverage the economies of scale to a sufficient extent. Outsourcing was also an option, but instead the two banks chose to partner with an outsourcing company. The banks provided the bank-specific knowledge to make their IT services organization an attractive data centre for smaller banks. The outsourcing partner provided the necessary technology expertise and new clients to benefit from the economies of scale. |
So how does an organization determine the optimum delivery strategy? There is no single or simple answer to this question. It is too dependent on the unique and specific situation under consideration. For this reason, the most appropriate guidance that can be provided is to describe key advantages and disadvantages of each delivery strategy. This, in turn, can be used as a checklist to determine which delivery approach should be evaluated further and most benefit the specific project or business initiative. Table 3.3 lists each strategy and its key advantages and disadvantages for the delivery of an application or IT service.
The strategy selected will depend on the capability and needs of the specific organization, its business and people - culture and capabilities. Whichever strategy is selected, its success and operation should be measured and regularly reviewed for effectiveness and efficiency and adapted to fit the changing business needs. The selection adopted with regard to IT service provision can often be influenced by the overall business culture and its approach to outsourcing and partnering.
There is more detail on SDLC in Chapter 5.
These approaches, which by default address a single system (and related services) only, can be supplemented by architectural approaches, such as those based on component-based re-use (see the section on architecture for further discussion).
The application lifecycle model described in the section on Applications Management (section 5.1.3) can be viewed as an example of linear or 'waterfall' (or 'V' model) based approach, and will not be discussed in further detail here, other than for comparison purposes with other approaches.
The main feature of RAD is the introduction of increments and iterations in the development process for the management of the risks associated with uncertainty and changing requirements. Traditional approaches have assumed that a complete set of requirements could be defined early in the lifecycle and that development costs could be controlled by managing change. However, discouraging change can mean being unresponsive to business conditions. RAD approaches accept that change is inevitable and attempt to minimize the costs of responding to them while still retaining the required quality.
The use of increments implies that a service is developed piece by piece, where every piece could support one of the business functions that the entire service needs. Incremental delivery could result in shorter time to market for specific business functions. The development of every increment requires traversal of all lifecycle stages. Iterative development implies that the lifecycle will be traversed more than once, by design. Techniques such as prototyping are used to get a better understanding of the requirements (by testing functional, management and operational activities and through communication with users).
Combinations of iterative and incremental approaches are possible. It is possible to start with the specification of requirements for the entire service, followed by the design and development of the application incrementally. RAD development methods, including the Unified Process and Dynamic Systems Development Method (DSDM) are seen as a response to business expectations, with the goal of reducing the cost of change throughout a development project. DSDM utilizes continuous user involvement in an iterative development and incremental approach, which is responsive to changing requirements, to develop a software system that satisfies the business requirements on time and on budget. Another example, Extreme Programming (XP), calls for developers to:
Use basic disciplines such as reviews, configuration and change management to keep control. To make good use of an incremental approach, the design process needs to be based on a separation of concerns, by grouping functions within increments in such a way that their interdependence is minimized.
In general terms, accelerated application development methods adopt a three-phase lifecycle model: accelerated analysis and design, time-boxed development and production and implementation. The methods are usually underpinned by software engineering technology, and rely on joint (IT-user) working and prototyping to quickly define requirements and create a working prototype.
From a business perspective, the use of incremental development and delivery by developers means that a valid, distinct part of the overall service can be delivered before the development team is in a position to complete the whole project. This approach offers early benefits to the business, and provides an opportunity for both the business and development team to discover emergent service properties and learn from their experience. However, it is often difficult to find a sufficiently small first increment that can provide a meaningful service to business.
RAD methods embodying iteration and incremental delivery can be used to reduce both development and implementation risks. The actual projects may not necessarily be easier to manage, but they can facilitate implementation and acceptance. They offer more options for contingency and enable developers to deal with changing business requirements and environmental conditions. They also provide both milestones and decision points for project control purposes. These methods can additionally be used to:
Important Rapid Application Development (RAD) constraints or Critical Success Factors (CSFs) include:
The use of RAD approaches requires skilled, multi-disciplinary teams, who are able to advise on when to apply such approaches.
| Category | Conventional development | Accelerated development |
| General approach | Sequential phases | Evolutionary |
| User resource commitment | ±15% throughout the project | 100% throughout project for project sponsor, ±30% for selected others |
| Risk | Higher - longer-term project problems may not emerge until well into the development project | Lower - problems surface early in the development process, requiring quick resolution |
| Executive sponsorship | Has approval authority, but not actively involved | High participation - sets scope, reviews progress and resolves issues |
| Use of joint session, iteration and prototyping techniques | Optional | Required |
| Developer skills | Specialists, some with limited experience acceptable | Highly experienced, mufti-skilled professionals required |
| Use of process support technology, e.g. CASE tools | Optional | Required |
| Team structure | Usually large with speclalized skill sets | Usually small with general skill sets, supplemented by specialists as needed |
| Rigorous scope management | Necessary | Critical |
| Phase structure | 4-5 phases | 3 phases |
| Individual accountability | Difficult to assess | Precise accountability |
| Table 3.4 Comparison between conventional ('waterfall') and RAD approaches | ||
Detailed standards will be needed on:
Additionally, procedures for evaluating and comparing competing packages in terms of customization/integration requirements are needed and should include:
Standards for documenting requirements prior to package market investigation should include ones specifically showing:
When evaluating COTS solutions, consider the following three ways in which a requirement can be fulfilled:
Supporting Material
|
|
|
