Service Design

1Introduction 2Serv. Mgmt. 3Principles 4Processes 5Tech Activities 6Organization 7Tech Considerations 8Implementation 9Challenges Appendeces

3. Service Design Principles

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
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
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
  1. Video - Service Design Goals and Objectives

[To top of Page]

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:

[To top of Page]

3.3 Identifying Service Requirements

Figure 3.4 The service relationships and dependencies
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:

The relationships and dependencies between these elements are illustrated in Figure 3.4.

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:

[To top of Page]

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.

Supporting Material
  1. CMMI - Engineering: Obtain an Understanding of Requirements
  2. CMMI - Engineering: Obtain Commitment to Requirements
  3. CMMI - Engineering: Manage Requirements Changes
  4. CMMI - Engineering: Maintain Bi-directional Traceability of Requirements
  5. CMMI - Identify Inconsistencies between Project Work and Requirements

[To top of Page]

3.5 Design Activities

All design activities are triggered by changes in business needs or service improvements. A structured and holistic approach to the design activities should be adopted, so that all available information is considered to ensure consistency and integration is achieved throughout the IT service provider organization, within all design activities.

Key message
Architectures 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
  • Corporate visions, strategies, objectives, policies and plans, business visions, strategies, objectives and plans, including Business Continuity Plans (BCPs)
  • Constraints and requirements for compliance with legislated standards and regulations
  • IT strategies and strategic documents (from Service Strategy):
    • All IT strategies, policies and strategic plans
    • Details of business requirements
    • All constraints, financial budgets and plans
    • The Service Portfolio
    • Service Management visions, strategies, policies, objectives and plans
    • IT and Service Management processes, risks and issues registers
    • Service Transition plans (Change, Configuration and Release and Deployment Management Plans)
    • Security policies, handbooks and plans
    • The procurement and contract policy, supplier strategy and Supplier Management processes
    • The current staff knowledge, skills and capability
    • IT business plans, Business and IT Quality Plans and policies
    • Service Management plans, including Service Level Management Plans, SLAs and SLRs, Service Improvement Plan (SIP), Capacity Plans, Availability Plans, IT Service Continuity Plans.
  • Measurement tools and techniques.
Design Activities
  • Requirements collection, analysis and engineering to ensure that business requirements are clearly documented and agreed
  • Design of appropriate services, technology, processes, information and process measurements to meet business requirements
  • Review and revision of all processes and documents involved in Service Design, including designs, plans, architectures and policies
  • Liaison with all other design and planning activities and roles, e.g. solution design
  • Production and maintenance of IT policies and design documents, including designs, plans, architectures and policies
  • Revision of all design documents, and planning for the deployment and implementation of IT strategies using 'roadmaps', programmes and project plans
  • Risk assessment and management of all design processes and deliverables
  • Ensuring alignment with all corporate and IT strategies and policies.

Design Deliverables
  • Suggested revisions to IT strategies and policies
  • Revised designs, plans and technology and management architectures, including:
    • The IT infrastructure and infrastructure management and environmental strategy, designs, plans, architectures and policies
    • The applications and data strategies, designs, plans, architectures and policies
  • Designs for new or changed services, processes and technologies
  • Process review and analysis reports, with revised and improved processes and procedures
  • Revised measurement methods and processes
  • Managed levels of risk, and risk assessment and management reports  Business cases and feasibility studies, together with Statements of Requirements (SORs) and Invitations to Tender (ITTs)
  • Comments and feedback on all other plans
  • Business benefit and realization reviews and reports.

Supporting Material
  1. Service Design ICOM

[To top of Page]

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:

3.6.1 Designing Service Solutions
Figure 3.5 Aligning new services to business requirements
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:

3.6.2 Designing Supporting Systems, Especially The Service Portfolio
The most effective way of managing all aspects of services through their lifecycle is by using appropriate management systems and tools to support and automate efficient processes. The Service Portfolio is the most critical management system used to support all processes and describes a provider's services in terms of business value. It articulates business needs and the provider's response to those needs. By definition, business value terms correspond to market terms, providing a means for comparing service competitiveness across alternative providers. By acting as the basis of a decision framework, a service portfolio either clarifies or helps to clarify the following strategic questions:

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.

Click for video presentation
Figure 3.6 The Service Portfolio - a central repository

Figure 3.7 The Service Portfolio and its contents
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:

The Service Portfolio is the main source of information on the requirements and services and needs to be very carefully designed to meet all the needs of all its users. The design of the Service Portfolio needs to be considered in the same way as the design of any other IT service to ensure that it meets all of these needs. This approach should also be used for all of the other Service Management information systems, including the:

3.6.3 Designing Technology Architectures
The architectural design activities within an IT organization are concerned with providing the overall strategic 'blueprints' for the development and deployment of an IT infrastructure - a set of applications and data that satisfy the current and future needs of the business. Although these aspects underpin the delivery of quality IT services, they alone cannot deliver quality IT services, and it is essential that the people, process and partner/supplier aspects surrounding these technological components (products) are also considered.

'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 NameFramework acronym
Access Wikipedia definition for termArchitecture of Integrated Information Systems FrameworkARIS
Bredemeyer FrameworkBredemeyer
Business Transformation Enablement Programme Transformation FrameworkBTEP
Command, Control, Communications, Computers Intelligences Surveillance and ReconnaissanceC41SR
CSC CatalystCatalyst
Computer Integrated Manufacturing Open Systems ArchitectureCIMOSA
Enterprise Architecture FrameworkGartner
Enterprise Architecture PlanningEAP
Extended Enterprise Architecture FrameworkE2AF
FEA Reference ModelsFEA
Generalized Enterprise Reference Architecture and MethodologyGERAM
Access Wikipedia definition for termIntegrated Architecture FrameworkIAF
Pillars of EAForrester
Access Wikipedia definition for termReference Model for Open Distributed ProcessingRM-ODP
Access Wikipedia definition for term Technical Architectural Framework Information ManagementTAFIM
Treasury Enterprise Architecture FrameworkTEAF
Access Wikipedia definition for term TOGAF Technical Reference ModelTOGAF
Access Wikipedia definition for term Zachman FrameworkZachman
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
Figure 3.9 Architectural relationships

The relationships between these architectural perspectives can be seen in Figure 3.9. 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.

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 the necessary architectures are in place, then the role of Service Design is affected in the following ways:

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 message
The 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. Technology Management
A strategic approach should be adopted with regard to the planning of an information technology and its management. This implies creating 'architectures' or 'blueprints' for the long-term framework of the technology used and planned. IT planners, designers and architects need to understand the business, the requirements and the current technology in order to develop appropriate IT architectures for the short, medium and long term. Technology design also needs to take account of the likely IT services that it will underpin, or at least the types of service from an understanding of the business and its future direction, because the business will demand IT services, and they will need an appropriate technology to provide and deliver those services. If it is possible to provide a longer-term technology, which can underpin a number of IT services, then taking a strategic approach will provide benefit in the longer term.

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
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:

3.6.4 Designing Processes
This section provides a general introduction to process theory and practice, which is the basis for the design of ITIL processes that are used in the Service Lifecycle. A process model enables understanding and helps to articulate the distinctive features of a process.

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
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.

Supporting Material
  1. Video - Value of Process and It's Characteristics
  2. Video - Designing Processes
  3. CMMI - Process Management: Establish Organizational Process Needs
  4. CMMI - Process Management: Appraise the Organization’s Processes
  5. CMMI - Process Management: Identify the Organization's Process Improvements
  6. CMMI - Process Management: Establish Process Action Plans
  7. CMMI - Process Management: Implement Process Action Plans
  8. CMMI - Process Management: Deploy Organizational Process Assets
  9. CMMI - Process Management: Incorporate Process-Related Experiences into the Organizational Process Assets
  10. CMMI - Process Management: Establish Standard Processes
  11. CMMI - Process Management: Establish Life-Cycle Model Descriptions
  12. CMMI - Process Management: Establish Tailoring Criteria and Guidelines
  13. CMMI - Process Management: Establish the Measurement Repository
  14. CMMI - Process Management: Establish the Process Asset Library
  15. CMMI - Process Management: Select Processes for Performance
  16. CMMI - Process Management: Establish Process Performance Measures
  17. CMMI - Process Management: Establish Quality and Process-Performance Objectives
  18. CMMI - Process Management: Establish Process Performance Baselines
  19. CMMI - Process Management: Establish Process Performance Models
  20. CMMI - Process Management: Collect and Analyze Process/Technology Improvement Proposals
  21. CMMI - Process Management: Collect and Establish Process Performance Models
  22. CMMI - Process Management: Collect and Identify and Analyze Innovations
  23. CMMI - Process Management: Pilot Improvements
  24. CMMI - Process Management: Select Improvements for Deployment
  25. CMMI - Process Management: Plan the Deployment
  26. CMMI - Process Management: Manage the Deployment
  27. CMMI - Process Management: Measure Improvement Effects
  28. Aspiratonal SKMS - User Commentary

3.6.5 Design Of Measurement Systems and Metrics

'If you can't measure it then you can't manage it.'

In order to manage and control the design processes, they have to be monitored and measured. This is true for all aspects of the design processes. Measurements and metrics are covered in detail in the Continual Service Improvement publication. This section covers those aspects that are particularly relevant and appropriate to measuring the quality of the design processes and their deliverables.

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.

Click for larger display
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
  1. Video - The Five Service Design Aspects
  2. Service Design - The SKMS

[To top of Page]

3.7 The Subsequent Design Activities

Once the desired service solution has been designed, then the subsequent activities must also be completed with the Service Design stage before the solution passes into the Service Transition stage.

3.7.1 Evaluation Of Alternative Solutions
An additional evaluation stage may be necessary if external supplier services and solutions are involved. This consists of the following:

3.7.2 Procurement of the preferred solution
It is possible that no external elements will be required for the solution. However, this is unusual as suppliers of software at least are highly likely to be involved. Where external suppliers are involved in the preferred solution, the stages consist of:

3.7.3 Develop The Service Solution
The development stage consists of translating the Service Design into a plan for the development, re-use or redevelopment of the components required to deliver the service and the subsequent implementation of the developed service. It may need to be developed into a programme of plans, if this is a major service change. Each plan or project within the programme will be responsible for delivering one or more components of the service and will include:

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.

Supporting Material
  1. CMMI Engineering - Select Product-Component Solutions
  2. CMMI Engineering - Develop Alternative Solutions and Selection Criteria
  3. CMMI Engineering - Develop Develop Detailed Alternative Solutions and Selection Criteria
  4. CMMI Engineering - Develop Evolve Operational Concepts and Scenarios
  5. CMMI Engineering - Select Product-Component Solutions
  6. CMMI Engineering - Design the Product or Product Component
  7. CMMI Engineering - Establish a Technical Data Package
  8. CMMI Engineering - Establish Interface Descriptions
  9. CMMI Engineering - Design Interfaces Using Criteria
  10. CMMI Engineering - Perform Make, Buy, or Reuse Analyses
  11. CMMI Engineering - Implement the Design
  12. CMMI Engineering - Develop Product Support Documentation
  13. CobIT - PO02: Architecture Services
  14. CobIT - AI01: Solutions Development
  15. CobIT -Application SW Acquisition & Maintenance

[To top of Page]

3.8 Design Constraints

Figure 3.13 Design constraints driven by strategy

  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
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.

[To top of Page]

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.

[To top of Page]

3.10 Business Service Management

Figure 3.15 The IT management continuum
Figure 3.15 The IT management continuum

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:

  • Align IT service provision with business goals and objectives
  • Prioritize all IT activities on business impact and urgency, ensuring critical business processes and services receive the most attention
  • Increase business productivity and profitability through the increased efficiency and effectiveness of IT processes
  • Support the requirements for corporate governance with appropriate IT governance and controls
  • Create competitive advantage through the exploitation and innovation of IT infrastructure as a whole
  • Improve service quality, customer satisfaction and user perception
  • Ensure regulatory and legislative compliance
  • Ensure appropriate levels of protection on all IT and information assets
  • Ensure that IT services are aligned and continue to be aligned with changing business needs.

Figure 3.15 illustrates the relationship of service activities and Service Management, and the reach and range they offer in value to the business and IT.

[To top of Page]

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.

3.11.1 Delivery Model Options
Although the readiness assessment determines the gap between the current and desired capabilities, an IT organization should not necessarily try to bridge that gap by itself. There are many different delivery strategies that can be used. Each one has its own set of advantages and disadvantages, but all require some level of adaptation and customization for the situation at hand. Table 3.2 lists the main categories of sourcing strategies with a short abstract for each. Delivery practices tend to fall into one of these categories or some variant of them.

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 strategyDescription
InsourcingThis 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
OutsourcingThis 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-sourcingOften 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-sourcingFormal 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 ProvisionInvolves 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
KnowledgeProcess 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

3.11.2 Design And Development Options
The delivery strategies are relevant to both the design and transition stages of the Service Lifecycle as well as the operation stage. Extreme care must be taken when selecting different strategies for different stages of the lifecycle to ensure that all organizations involved clearly understand their individual roles and responsibilities, and also every other organization's role and responsibility to ensure acceptance and handover processes are clearly defined, agreed and accepted.

Delivery strategyAdvantagesDisadvantages
InsourcingDirect 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
OutsourcingEconomies 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-sourcingTime to market
Leveraged expertise
ControlUse of specialized providers
Project complexity
Intellectual property and copyright protection
Culture clash between companies
Partnership or multi-sourcingTime 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 ProvisionAccess 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

A 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.

3.11.3 Design And Development Approaches
It is also important to understand the current generic lifecycle types, methods and approaches to IT service development, in order to decide on standards for the Service Design stage of the lifecycle. To achieve this, a good understanding is needed of the following aspects of the various Service Development Life Cycle (SDLC) approaches:

There is more detail on SDLC in Chapter 5. Rapid Application Development
It is necessary to understand the differences between object-oriented and structured systems development, the basic principles of the 'Agile' (Rapid Application Development (RAD) or accelerated development are other terms used in this area) movement and to recognize how a commitment to a software package solution changes the structure of the approach.

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.
CategoryConventional developmentAccelerated development
General approachSequential phasesEvolutionary
User resource commitment±15% throughout the project100% throughout project for project sponsor, ±30% for selected others
RiskHigher - longer-term project problems may not emerge until well into the development projectLower - problems surface early in the development process, requiring quick resolution
Executive sponsorshipHas approval authority, but not actively involvedHigh participation - sets scope, reviews progress and resolves issues
Use of joint session, iteration and prototyping techniquesOptionalRequired
Developer skillsSpecialists, some with limited experience acceptableHighly experienced, mufti-skilled professionals required
Use of process support technology, e.g. CASE toolsOptionalRequired
Team structureUsually large with speclalized skill setsUsually small with general skill sets, supplemented by specialists as needed
Rigorous scope managementNecessaryCritical
Phase structure4-5 phases3 phases
Individual accountabilityDifficult to assessPrecise accountability
Table 3.4 Comparison between conventional ('waterfall') and RAD approaches Off-the-shelf Solutions
Many organizations now choose to fulfill their IT service requirements through purchasing and implementing commercial off-the-shelf (COTS) software package solutions. A framework for selecting, customizing and implementing these off-the-shelf packaged solutions is needed and includes the need to:

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:

Related Material

Supporting Material
  1. CMMI Development Version 1.2 (see pages 463-482)
  2. CMMI Services Version 1.2 (see pages 437-462)

[To top of Page]


Visit my web site