ITIL
TOGAF and ITIL, while of separate origins, have commonalities that justify their wide acceptance as best-practice frameworks. As with all good frameworks, they apply focus on an orgnisation's business and its use of ICT to serve business puposes. They are both cyclical and incorporate change as an underpinning theme and, being generic they are perfectly complementary.
Any functional ICT practice will fully appreciate the symbiosis and interdependencies between Enterprise Architecture and Cross Functional Services - particularly the Service Management aspects, and will deploy both in a way that is properly integrated. Cross Functional Services could be considered to be a part of an EA's reference models or metamodel.
Service Stratgey
"Service Strategy provides guidance on how to design, develop, implement and maintain Service Management. Service Management is not only seen as an organisational capability but is also considered to be of strategic value. In Service Strategy, it is stated that it addresses the principles guiding the development of policies, guidelines and processes. TOGAF in the Preliminary Phase performs more or less the same role regarding Enterprise Architecture. Whereas Service Strategy is concerned with prerequisites for building a Service Management system, TOGAF performs the same role for building an architecture management system. Furthermore, as both frameworks are converging, they are at least partially building the same management system.
"Both management systems take into account what the requirements of the business are and how value can be added from either the architecture or service perspective."
TOGAF9 and ITILV3 Two Frameworks Whitepaper, Tom van Sante and Jeroen Ermers, Getronics Consulting.
Whereas TOGAF has a higher priority on strategic outcomes and ITIL is more operationally focused, it should not need to be stated that ITIL's Service Strategy and TOGAF's Preliminary, Architecture Vision and Business Architecure phases should be fully compatible when deployed for the same organisation.
Service Design
The obvious cross-over point between TOGAF and ITIL; Enterprise Architecture and Service Management.
The integration of EA and Service Management is the important point. Whether an organisation has mature deployments of both frameworks, has variations of one or both for its own circumstances or has immature or non-existant practices, it is critical that, while the respective processes are applied from different perspectives, any application of the frameworks should be properly integrated.
While both frameworks acknowledge the other, neither covers how the practitioners should work together. Some Enterprise Architecture models address this aspect to some extent, as is the case with DODAF, MODAF and AUSDAF Viewpoints. These provide a mechanism to set out the support requirements in line with the functions of any system
Another important point in integrating EA and Service Management is that EA is proactive in its engagement with the organisation and it is not simply one stage in the Service Management cycle. Because EA is more strategically focused and aligned with the business it should typically drive Service Management and not be constrained by any limitations in existing Service Management practices. The development of new or changed Service Management required to support a new or changed system is a part of the practice of Enterprise Architecture.
Service Design should be initiated by a Request For Architecture Work - in ITIL terms, a Request For Change or RFC. Such a request would be subject to assessment via an Architecture Board (EA) or Change Advisory Board (CAB in ITILese). Such entities could be the same thing, or be comprised of varying particiapants depending upon the nature of the change. CABs typically would assess changes that did not require architecture effort while Architecture Boards would assess more complex requirements at a greater level of detail.
Architecture Principles are the set of rules to guide business, information and technology decisions. They apply to the initial solution design, and across the lifecycle of any Service and its components through incorporation into change procedures.
Regardless of naming conventions and structure, the governance arrangements should clearly set out the roles, accountabilities and responsibilities.
Service Transition
Standard changes not requiring architecture work would be subject to the Service Transition process as Installs, Moves, Adds and Changes (IMACS). The implementation of any significant change to an architecture, or any new architecture, would be defined as a project. That project could be undertaken, in ITIL terms, in the Service Transition phase using a Project Management methodology such as PRINCE2 or PMBOK.
Project Management is separately high-lighted within this classification of Cross Functional Services given its importance in effectively implementing significant changes and because of its project-specific practices.
Transitional State architecture applies as an interim state when new services are required to be phased in. In such circumstances the Transitional State architecture is a primary input to the Service Transition, and specifically any project planning.
Service Operations
TOGAF pays only lip service to Service Operations by stating that the development of IT operating models and implementing IT service delivery are activities carried out within TOGAF but without providing any further guidance. While Service Management is oriented towards operational aspects of ICT, Enterprise Architecture commonly needs to consider operations. New architctures typically need new or revised support resources that can include tools, expertise, facilities and logistics.
Reference models that can provide guidance include:
- ITIL Service Operations
- The Microsoft Operating Framework (MOF)
- IBM's ITUP
- eTOM
- ISO20000
- The Skills Framework for the Information Age (SFIA) - which applies to all aspects of Service Management and architecting
Operational resources and their deployment to support systems are, whether already in place or not, components of that system's architecture and therefore considerations for architecture development.
Continual Service Improvement
The ITSMF's ITIL collateral deals with the minutiae of Continual Service Improvement, so let us rather consider the merits of an holistic approach to improve the deployment, configuration, use and support of ICT in an ongoing manner.
Service levels set out the metrics for acceptable standards of service. Service levels should apply to those aspects of a service that are important to the business functions of an organisation, and should be weighted in accordance with their relative importance.Unnecessary service levels impose unnecessary costs. Service levels form a key input to network design.
A Performance Framework captures how service levels are applied to encourage over-achievement, and to ensure any areas of under-achievement are addressed and rectified. A Performance Framework provides an Enterprise Architect with guidance on the relative design priorities linked to business priorities and identifies the components of a service that need to be monitored. The framework should set out minimum and desired service levels to encourage ongoing improvement initiatives, including the consideration of alternative designs, configurations or even technologies as they arise over time.
Monitoring needs to identfy any areas of under achievement, but also to provide for assessment of potential improvement even where service levels are met.
A Future State architecture also establishes a roadmap whereby potential improvements can be tested as a key contribution by Enterprise Architecture to innovation and Continual Improvement.
