13 years, 11 months ago

Aligning ITIL V3 Service Design with TOGAF 9

ITIL V3 is structured in 5 modules, one of them being The Service Design book. This book refers to technology-related activities (requirements engineering; data/information management and application management). It also covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. Service Design processes are important because they provide organizations with information that will affect their decisions on designing solutions for new or changed services-

Service Design has five aspects:

  • Design of the service solutions
  • Design of the Service Portfolio (and other supporting systems)
  • Design of the technology architectures and management systems
  • Design of the processes
  • Design of the measurement systems, methods and metrics

Section 3.6.3 on page 35, provides a specific context for the terms “architecture” and “system” which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.

”Architecture” 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.“

”architectural design” 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.”

In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.

Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.

Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.

One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.

Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans.etc.) , making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.

The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:

  • Business Architecture: for Business, organization and enterprise
  • Data Architecture: for data and information, databases
  • Application Architecture: for applications
  • Technology Architecture: for hardware (desktops, mobile devices, servers, and mainframes), network, telephony and software

Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).

Services would be a combination of the four domains.

The Service Design activities and processes covers:

  • Service Level Management
  • Availability Management
  • IT Service Continuity Management
  • Supplier Management
  • Information Security Management
  • Capacity Management
  • Service Catalogue Management

These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).

Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!

14 years, 13 days ago

TOGAF 9 Migration Planning and Project Portfolio Management

Phase F in TOGAF helps to describe how to create a viable implementation and migration plan in co-operation with the portfolio and project managers. Very often companies already have in place a Project Portfolio Management framework and there may be a need to integrate your enterprise architecture with that.

As an example, PMI has introduced a standard for Portfolio Management, and portfolio managers have a resource to help them develop professionally and achieve success for themselves and their enterprise. Within an organization, a portfolio represents a collection of active programs, projects and other work undertaken at a specific point in time to help the organization achieve strategic objectives. In essence, a portfolio reflects the priorities, investments and resource allocations.

Project Portfolio Management (PPM) may be part of an enterprise governance framework. It is a management process designed to help the organization-:

-To ensure that the organization is doing the “right things”, optimally allocating scarce resources toward the enterprise’s objectives
-To acquire and view information about all projects
-To sort and prioritize each project according to certain criteria, such as strategic value, resource impact, cost, and so on.

PPM has several activities which are similar to the objectives of managing a financial portfolio:

-The identification of all the individual demands in the portfolio
-The development of a “big picture” view and a deeper understanding of the collection as a whole
-The sensible sorting, adding, and removing of items from the collection based on their costs, benefits, and alignment with long-term strategies or goals.

In a nutshell, Portfolio Management can help zero in on the projects that are most worth their effort; project management can help execute those projects most efficiently.

These activities can be perfectly integrated with Phase F of TOGAF. Once the work packages, projects and building blocks inventory is created, the enterprise architecture team with the portfolio managers (and other important stakeholders) will examine each project and prioritize it according to established criteria. They will probably assign a business value; conduct a cost business analysis for each project (done in collaboration with business people); identify the risks to the projects.

The overall list of projects is then considered to develop a well-balanced list of supported projects and provide an input for a detailed implementation and migration plan. It will also help to confirm the Transition Architecture defined in the phase E. The use of an Architecture definition increments table is highly recommended to list these projects.

Some projects will be given high priority and extensive support, some will be given moderate priority, and still others will be placed on hold or dropped entirely from the list. This will also help to finalize the Architecture roadmap. Finally, resources will need to be identified and made available.

Other Governance domains may also be to be integrated in the PPM process and Phase F, such as Risk Management (e.g. RiskIT), Project Management (e.g. PMI, PRINCE 2), etc.

Companies who are mature in Portfolio Management activities may integrate their existing work practices easily with TOGAF. This would enforce the relationship between the Enterprise Architecture team and the PMO (or the PPM team).

(You can also refer to another post: Why do we not find yet links between Enterprise Architecture and Project Portfolio Management? )

14 years, 1 month ago

Keep an eye on OneCMDB and the CMDB Federation

OneCMDB Version 2.0 is a real interesting concept and product as this may be one of the first IT Service Management solution developed in an Open Source mode. It will not replace your Service Desk solution but may help companies with limited budget or companies which have a wide diversity of existing catalogs of assets. It is only covering Configuration Management as a process and in some way IT Assets management. For those who are using Nagios, there exist some connectors.

This has been initially developed by Lokomo Systems using Java but I’m not sure how does that fit with the CMDB Federation Group (I wrote a post on the subject in 2007) if it still exists….(I haven’t seen any indication of activity since January 2008 and maybe this is a dead project…).

In any case, keep an eye on both…
14 years, 6 months ago

Video of eXploratory Modelling at ESUG2008 available

Today James Robertson published his video of my talk on eXploratory Modelling at ESUG2008: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=eXploratory_Modeling_at_ESUG_2008&entry=3404625062 Have fun watching it, and please do not hesitate to contact me if you have questions or if any part of the presentation was unintelligible because of the noise or such.The presentation was done without a microphone, and I guess […]

14 years, 6 months ago

Meet WALL•S!

Though not called WALL•S by Michael Haupt who posted this blog, the little NXT robot in the picture immediately reminded me of WALL•E. So meet WALL•S, the first robot that actually speaks and understands Smalltalk! Some of you may know that Smalltalk originally was quite popular in the embedded world. Tektronix for example ran Smalltalk […]

14 years, 8 months ago

Smalltalk on bare metal blog

Nice blog by Cees de Groot about the SqueakNOS project that has been revitalised. This project has my special interest since it clearly demonstrates some features of Smalltalk in the sense of it’s completeness. We are not talking programming language. We are talking system.

15 years, 1 month ago

Wales – land of Great Food, Good Food

http://www.ypolynrestaurant.co.uk/Y Polyn Capel Dewi, Nantgaredig, Carmarthenshire, SA32 7LH Tel 01267 290000 info@ypolyn.co.uk Fabulous food, check out the website.

15 years, 3 months ago

St Davids Day

It seems fitting that my blog should start on St. David’s Day – the beginning of Welsh pride as the year begins, flowing with Daffodils, Cawl Cennin (Leek and Lamb stew), all kinds of goodies for children and the flow of love and kindness towards all.T…

16 years, 1 month ago

ERP for IT

Sometimes it seems like we’ve automated the business but not the IT world. Although some organisations have a plethora of systems and processes to manage the operational environments, governance, portfolios, architecture and projects most do not. …