December 3, 2009

Federal Computer Week - Discussion of ITIL and EA

Services listed under ITIL and enterprise architecture models are
different in nature, said Andy Blumenthal, chief technology officer at
the Bureau of Alcohol, Tobacco, Firearms and Explosives, who did not
speak on behalf of the agency.

“When we talk about services in an EA context, we refer to those that
are used for mission and business purposes,” he said. “In contrast,
ITIL-type services are underlying support functions to the customer,
such as problem identification and resolution. An example of an EA
service versus an ITIL service would be a document management solution
versus a help desk or network management function.”

...

“Traditionally, architecture efforts have been notorious for being an
ivory-tower effort that results in shelfware,” Blumenthal said. ITIL
proponents also tend to be squirreled away in data centers and not
inclined to consult with architects.

A cultural shift is necessary, Blumenthal said. Enterprise architects
in particular must become more user-oriented if they’re going to stay
relevant in a changing technology environment, he added.

To read the entire article go to:
http://fcw.com/articles/2009/12/07/comparing-ea-and-itil.aspx


Share/Save/Bookmark

2 comments:

semyon axelrod said...

From my point of view, while relationship between ITIL and EA spaces are not trivial, we can addressed this complex issue in a mutually beneficial for both EA and ITIL communities fashion.
However, there are two crucial points that we need to agree upon before we can arrive at a desired point.
First, we need to acknowledge that EA has four main domains: Business, Information, Application, and Infrastructure. This is hardly a controversy these days; however, in my experience, EA community still struggles to make convert this foundational assertion into robust practice and connect this practice with the daily activities of the workers operating in these four domains (so-called Ivory Tower Architecture) .
Second, ITIL is mainly (if not only) aware and concern about only one of these four domains: Infrastructure.
If we accept the two points above as being true, then the relationship between the two disciplines becomes pretty straightforward. EA covers (at least theoretically) all the aspects of business and IT continuum, including Infrastructure, while ITIL is primary concerned only with the Infrastructure domain. At the same time EA, which favors by its own nature breadth rather then depth, is not very prescriptive about details and in addition to that, still is struggling to arrive at an industry accepted set of common practices. In a sharp contrast to EA, ITIL is very detail, and there is only one universally accepted standard (or best practice) called ITIL.

The real problem, from my point of view is the overlap between the two approaches mainly around a set of processes that span all four main domains of EA but are also called out in ITIL. For example, let’s consider Release Management (RM) process. My ITIL counterparts always struggle with the notion of RM process that actually needs to address issues in Business (Business processes and Requirements) , Information (information models and data models), Application (System Requirements and Application Design) domains. Here is our biggest problem today: ITIL, being infrastructure-centric discipline does NOT and can NOT have a mechanism to cope with the problem of coordination of the RM-related issues in all 4 domains, while EA potentially can address the coordination issue has not provided a robust approach to do that, yet.

Semyon Axelrod
CIO and Chief Architect
SemanticWebEnterprise LLC;

Itsme said...

It is a constant source of amazement to me, the different perspectives people take on complex concepts like ITIL and EA.

Neither Mr. Axelrod or Mr. Perera recognized the possibility that ITIL could be leveraged as the inegrated Service Management Process Architecture, supporting an Enterprise Technology Architecture. Indeed, this is exactly how one branch of the DoD has created their Enterprise Architecture model.

In this forward thinking approach the enterprise architecture provides detailed governance on the infrastructure, application, network, security, all requirements for the technology that underpins the business processes used by this branch of the DoD. This includes the detailed service support and service delivery management processes that must be supported to ensure the technology underpinning business processes are strictly managed as SERVICES; Customer-facing, proactively managed, process centric, and quality capable technology services.

This combined Systems and Service Management architecture addresses the entire spectrum of governance. It documents a detailed linking between the people, the process and the tools/technology necessary to manage technology in support of business processes.

I believe this approach to developing architectures as governance vehicles is the business-facing approach that EA has had difficulty evolving, due to the strictly technology-centric focus of the architects and IT leadership to date.

I am convinced that an EA model that does not have an IT Service Management process architecture (based on the tightly integrated process architecture model documented in the ITIL framework) embedded within, is an outdated, technology centric architecture model, offering limited value as a true Enterprise governance vehicle.

ITIL and current technical-focused EA are complimentery components of a true Enterprise Technology Governance Architecture