erp4it

A new framework for IT management: portfolio lifecycles

Frameworks, frameworks, everywhere... ITIL, CMM, COBIT, etc., etc., ... and yet none of them satisfy. All have nagging gaps and flaws:

- ITIL's weakness with respect to production applications, the primary "service" offered by the modern IT organization...

- CMM's level of abstraction and disregard for operations...

- COBIT's narrow focus on governance and audit...

And all are process based. They focus on activities, not on things. And while activities are indeed important, I have to confess my data centricity. I've always leaned a bit more to nouns than verbs.

The concept of portfolio management is a better fit for me, and indeed ITIL calls for Service Portfolio Management, as an evolution of the original service catalog concept and co-optation of Application Portfolio Management.

A personal matter

On my personal blog.

Three fundamental agility trends, and their source

Regular readers know that I embrace a simple three-perspective approach to enterprise architecture: process, data, and system. All three of these domains are seeing significant trends towards increased agility, at a fundamental level that I think is more than hype.

In the world of process, the most important trend is towards processes that may not be repeatable; that is, each instance of a process may vary dynamically - there cannot be One Process Model to Rule Them All. Towards this end, the OMG has issued an RFI to determine "whether it is appropriate to develop standards at this time for...these dynamically developed processes." This is related to but not the same as some of the debates I've been in recently regarding so-called "value networks" - in my view, much greater precision can be expected if the OMG is involved. Unanswered questions here include the data consequences of variable processes: how do we report? How do we manage by metrics when the process is so variable that metrics are difficult if not impossible to establish?

In the world of data, the most important agility trend is the Semantic Web, which can be seen as a critique of rigid, monolithic, totalizing data architecture (one Data Model to Rule Them All...) Its "open universe" assumptions and fundamental recognition of the ongoing need to reconcile multiple ontologies are the essence of agility.

I was a Semantic Web skeptic for some time, and am still concerned about the talent management implications, but we are starting to see the necessary ecosystem emerge. As far as credibility, I refer you to the pages of Scientific American, where it has had favorable coverage in 2001 and 2007. It's not a vendor-driven fad. What really convinced me was Dave Hay's favorable assessment (Dave being a notable data curmudgeon, not easily impressed by fads), and Wilshire Conferences adding a new conference dedicated to the topic.

In the world of systems, the most important agility trend is virtual appliances, as seen in CohesiveFT's products. The Seybold Group has a good analysis of this trend's importance. Any number of caveats apply, but the essential proposition is that the perpetual desire of IT hosting groups to minimize and standardize the OS and middleware stacks underpinning applications is misguided. Instead of One Technology Stack to Rule Them All, virtualize applications into finely tuned, purpose built combinations of OS + middleware + application code, and stop worrying about consistency. (Security, licensing, and talent management are some unanswered questions here...)

All of these trends have a distinct postmodern feel to them, especially Semantic Web, but the other two as well. Truth and meaning, and in particular the utility we derive from them, are context dependent. There is no grand, totalizing "theory of everything," no universal discourse that can handle all perspectives. Perhaps it is no coincidence that the Communications of the ACM recently published an article on critical theory applied to IS. All of these trends point in the direction of greater diversity and greater specialization, and away from monocultures: operational, semantic, and technical.

The core challenge: will we have the trained human capital able to wring value from this diversity? Integration specialists, those who can wrap their heads around the multiple perspectives and align them as needed, will be in high demand - but such specialists (among whom I would count enterprise architects) need to temper their need for unified frameworks, recognizing that such pursuits are often at best academic and at worst futile.   

A bit of humor for West Wing fans

On my personal blog.

ITPI research on effectiveness of ITSM & SDLC best practices

ITPI has released some credible empirical research here:

http://www.itpi.org/home/white_papers.php

In a well-designed survey of 341 organizations, they identify significant correlations between IT performance and ITSM best practices, but also find some surprising non-correlations. For example, simple Change oversight does not predict performance in their sample, but a strong Release process does. CMDB in and of itself does not predict success, but linking changes to CIs in a CMDB does (which I would argue in turn justifies the CMDB - it's all about what you do with it, not just having it).

The performance measures seem primarily operational (a full list is not available in the summary). That is, "performance" is defined in terms of uptime, successful releases w/o rollbacks, etc  - not in terms of business performance, IT porfolio alignment, etc.

Charles T. Betz
http://www.erp4it.com

Charlie Betz on RunAs Radio

Well, yes, this interview is months old. I plead guilty to blatant non-self-promotion. Too much else to do.

Those of you who think I am an ITIL basher may be surprised.

http://www.runasradio.com/default.aspx?showNum=22

-ctb

An excellent article on discovery tool pros & cons

Michael LaChance of Travelers has hit the nail right on the head:

http://www.itsmwatch.com/itil/article.php/3718406

The only thing I would debate with him is whether we should go "broad or deep." That is, do deep discovery of all the intricacies of a selected few high impact applications - or do comprehensive, but more shallow discovery across the entire infrastructure. Deep is good for high value service management - but if you want to do chargeback, portfolio management, massive server virtualization, or other broad stroke efforts, you need complete visibility across the data center at least for the basic app/host dependencies.

Notice that he also has little use for the vague term "IT Service," focusing on applications and the application boundary problem.

He also touches on the perhaps problematic relationship between BSM and CMDB. They overlap, but are not necessarily the same thing. The CMDB implies a comprehensive scope, but true BSM (instrumented service availability management, using dependency maps) may only have ROI on a subset of applications in the data center.

-ctb

Mike Rosen of Cutter reviews my book

Many thanks to Mike Rosen for this review & to Cutter for reprint permission.

=================================

This review originally appeared in the Nov. 7, 2007 Cutter Consortium Enterprise Architecture Advisory Service's E-Mail Advisor. Reproduced with permission of the publisher, Cutter Consortium (www.cutter.com).

Book Review: Architecture and Patterns for IT Service Management

by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice

At first glance, the title might not sound especially sexy: Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children , by Charles T. Betz. However, this book addresses a little talked about problem that every single enterprise or IT organization has. In any case, if you're an architect, you're going to like this book for the wonderful architectural approach taken by the author. It has breadth, depth, perspectives, concepts, formal metamodels, and patterns -- all tied together in a nice tight bundle.

So, what exactly is the book about? It is about managing the business of IT; of understanding demand and relationships, solutions development, and operations and support. It's more than that as well; as the subtitle implies, it's about applying the tools and techniques (and in particular, architecture) that we normally apply to automating and operating our enterprises and businesses to the tasks of operating IT as a business.

Chapter 1 states the problem and the business case. It's no secret that many IT organizations struggle with costs, quality, and project failures. And while development costs and schedules continue to increase, operating expenses rise even faster, consuming more and more of the limited IT budget. The solutions industry proposes are no secret, either. Ranging from overused clichés like "run IT like a business," to architectures such as SOA or EA, to pass-the-buck approaches like outsourcing or Software-as-a-Service, the list is long and familiar. I particularly like the table the author compiles that lists and compares many of the different proposed solutions.

However, if we're going to "run IT like a business," we need to know what business we're in. That's the topic of Chapter 2, which describes the IT value chain. If you're familiar with business architecture, you'll recognize the techniques used, ranging from Michael Porter's value chain to Rummler and Brache's enterprise feedback models. The value chain plays a key role throughout the book. Betz divides the business of IT into supporting processes such as: architecture, sourcing, risk, security, governance, facility, and operations. Then he identifies the primary, value-adding processes of the IT value chain: demand/relationship management, solutions development, and service support. He further divides the primary value chain into parallel tracks of application, infrastructure, and what he calls the "hosting zone of contention." Each primary and secondary activity is described in detail and decomposed into smaller activities.

Now that we understand the problem, it's time to start understanding the solution. Chapter 3 takes a unique approach and first develops a formal information architecture, or what the book calls a "supporting data model." The model describes the different aspects of the primary and secondary processes, the information required to support them, their relationships, some ITIL-specific information, and some additional general IT concepts. A complete matrix maps the different entities to the different activities. Because the model is so clearly explained and developed, you can almost miss how complete and thorough it is -- that is, until you notice that 100 pages of the book have been devoted to it.

Chapter 4 continues with the analytical approach, this time developing what the book calls a "supporting systems architecture." In this context, systems are processes, functions, tools, and so on. Each primary and supporting activity and subactivity is addressed by some kind of system. Some example systems are: project management system, configuration control system, enterprise architecture system, and capacity planning system. Betz briefly describes each system, but more importantly, he identifies the relationships, gotchas, and overlaps with other systems. Finally, the book ties together all the systems around the concept of a configuration management database (CMDB).

Chapter 5 ties things together with "patterns for IT enablement." This chapter presents patterns for support of the primary and secondary processes of the value chain. Some example patterns are: front-end demand distinction, standard technology stack, security-configuration management synergy. Each pattern is described in detail and linked back to the supporting systems and information developed in the previous chapters.

You've probably guessed by now that I like this book. I'd recommend the book to any architect because it takes a quintessential architectural approach to looking at a problem. First, understanding the problem, then tying the solution to the business. Next, based on that framework, it develops a formal, analytical model of the solution space and proposes patterns for solutions built from the formal models. In doing so, it takes full advantage of the relationships that are evident and possible because of the underlying models. But, I'd also recommend the book to anyone who is involved in IT management, resource planning, or governance. You will have a better understanding of the problems you're dealing with after reading this book; so much so, that you'll wonder how things every worked before. Ah, but that's the catch: how well are they really working?

I welcome your comments on this Advisor and encourage you to send your insights on enterprise architecture strategies and practices in general to me at mrosen@cutter.com.

Sincerely,
Mike Rosen, Director
Enterprise Architecture Practice
E-mail: mrosen@cutter.com

BISM - you (probably) heard it here first

So, in the wake of Nicholas Carr's "IT Doesn't Matter" thesis, I've been playing around in high-concept land, with some of the less precise, more fraught and overloaded terms we all see day to day:

• Data
• Information
• Knowledge
• Technology
• Infrastructure
• Services
• Systems
• Business
• Management

and their standard permutations:

• Information Technology
• Information Technology Infrastructure (Library)
• Information Technology Service Management
• Information Systems
• Management Information Systems
• Data Management
• Knowledge Management
• Business (Intelligence)

and so forth. The following process of elimination has ensued:

First, I never really understood why it was deemed "progress" when Information Technology (IT) replaced Information Systems (IS) - it always seemed a step backwards, because it implicitly prioritized the tool (technology) over what you were doing with it in context (the system). In the wake of Nicholas Carr, I think the word Technology has to go. It is already a commodity, not strategic, and simply not that interesting.

And Infrastructure is a woeful word, worse than Technology in mundane connotations. If IT "doesn't matter," IT infrastructure is even more trivial. Sewers, anyone? So, bye-bye, ITIL.

Likewise, the word Data is too low in the food chain. It means bits and bytes, and is generally understood to be subordinate to Information. Conversely, Knowledge is too high-order and some would say by definition can't be "managed."

Information, however, is term that I think stays. It's at a certain sweet spot of "we know it when we see it, but it's never easily achieved - and often can't be commoditized." Information as a concept connotes value -if it's not useful, it's by definition not information. Today's information is tomorrow's mere data - the concept embodies a continually rising bar of utility, and in this dynamism is highly business aligned and relevant.

System is a glass-box word, one that invites you in -- to examine all its mind-numbing, gory inner workings. Service, on the other hand, has a clear boundary that anyone who enjoys espresso can intuitively grasp. It's not about the details of whether the coffee beans were delivered today or the steam pressure is up to spec; it's about that quality hot java, delivered with a smile. It's not about the network or the server or the OS or the middleware or the DBMS; it's whether the system as experienced by the end user is fit for purpose.

So, down with Information Systems and MIS as well. And down also with Data Management and Information Technology anything, including Infrastructure. An acceptable core term of Information Services starts to emerge. Information... Services. I like it. Information as a service. Not technology as a service; not software as a service. But information - the sensory apparatus and cognition of business. As a service, not a system.

But who provides information, at the highest, most business-relevant level, as a service to inform business strategy? Look no further than your local data warehousing group, aka your "Business Intelligence" capability. They are the people who revolutionized Wal-Mart's supply chain and who provide some of the most valuable computing services in the enterprise. And note that they have the word "Business" embedded front and center...

Business Information Services? Like it. Like it very much.

We can turn it into a discipline: Business Information Services Management. We can turn it into an association, a forum, a library - but wait! There is the Business Information Services Library already! Not that I'm terribly familiar with it; it's mainly a Dutch thing and it doesn't seem to have much of a BI flavor - but it should.

Business Information Services Management. The intersection of Data Management and IT Service Management. The Google search on that string yields all of 8 hits tonight (10/10/2007). Will that number increase?

I think it ought to.

Charlie   

PS. What about ISACA and ITGI? Well, Audit and Control definitely don't sound value-add. Governance? Information Services Governance? Doesn't do a lot for me... But Val-IT is interesting. BIVM? BISVM?

The four pillars of IT Service Management

What does ITSM require?

I propose these four pillars:

1. A service-focused view of IT. This means that the end service as the customer experiences it is paramount. Not the server, not the network, not the database, not the software - no more finger-pointing. This is not a hard concept; technologists can understand it as anologous to contract-specified interfaces on a component. The implementation (or the sourcing) can vary as long as the contract is fulfilled.

2. Process orientation. What are the measurable and repeatable activities? How well do we understand them? Are we continuously re-evaluating them for efficiency and effectiveness? What capabilities and functions must support them? What activities do we have that are not easily measurable, yet still apparently critical?

The above two concepts are broadly accepted as essential to ITSM. I propose two more:

3. Master data management. Just as my business customer understands their systems of record for Products, Customers, Locations, and Accounts, I need to clarify my systems of record for Servers, Databases, Applications, Services, Projects, Programs, Service Requests, Incidents, Problems, and Changes. Do I have multiple systems trying to house essentially the same data, perhaps under differing names? Am I allowing the same data to be updated in multiple locations? Do reports across my IT Service Organization agree?

4. Well-architected internal IT. Do I have outdated or poorly maintained ITSM systems (change, incident, project, portfolio, configuration management, monitoring, service request management)? Spreadsheet-driven processes? Redundant systems? Manual or non-existent integrations across systems that really should be sharing data or services?

There's much to be done in any ITSM initiative but considering it from all four of these dimensions may be useful.

Cheers,

Charlie 

Business of IT ontology, aka ONION

So, did a Google on "ITSM Ontology" and came up with:

Business Of Information Technology Ontology

aka ONION.

Rather under the radar. Guess I'm going to have to get up to date on Semantic Web.

-Charlie

ITIL and eTOM

perhaps a bit outdated but a gem nevertheless.

A nice review of my book on BPTrends

Here.

A process ontology

The value chain/network debate has flared up again over on IT Skeptic. This process ontology here is meant to help clarify things. I continue to hold that the first column is not a paradigm improvement over the second column, which is the claim some people seem to be making. Just two different and very well understood approaches to systems analysis. Thoughts?

Open source configuration management tools

Here are a couple tools that might be of interest if you are looking for open source configuration management and/or CMDB solutions.

http://www.cmdb.info/pd1/html/

http://www.controltier.com/

http://reductivelabs.com/trac/puppet

Update: someone noted that there is already a Wikipedia article on this. So I'll probably not keep this alive.

I'd note that most of these tools appear to be sysadmin element management focused on the most common platforms; no Tandem, iSeries, or mainframe. They do not appear generally to be concerned with enterprise configuration management in the sense of maintaining accurate inventories and interdependencies, nor do I see direct integration with Change, Incident, Problem, and other processes. Not sure if they do much for the DBAs, either.

-ctb

The CMDB dream team

One of the issues dogging the CMDB hype cycle is the steep requirements for architecting and implementing such systems, even when based on vendor products. Expertise from a wide variety of domains is called for. What would a qualifed CMDB dream team look like? 

The evolving domain language of IT... and more on Application versus Service

One of the hallmarks of mature professions is that they have a clear and detailed language - a domain (or universe) of discourse or an ontology.

In the development of a human profession (such as IT), the profession's language is rarely if ever pre-ordained - it is collaboratively and often messily defined, based on real world experience, with major codifications (e.g. GAAP for the profession of accounting) as historical watersheds, and essentially contested concepts as landmines.

Gabriel Morgan's conceptual model of business-IT traceability represents a fairly standard, stripped-down view of a "stack" of concepts showing business-IT traceability, similar to many I have sketched and seen presented by enterprise architects.

Couple of good blogs

Nick Malik (where do I know that name from?) and Gabriel Morgan. Gabriel is taking a swing at business-IT traceability (aka metamodeling), and Nick has posted on Application Portfolio Management (and gotten a Wikipedia article on same going). Non-ITSM folks, both headed into ITSM waters in their lines of inquiry.

-ctb

IBM Systems Journal July 2007 - more ITSM architecture, finally

The current IBM Systems Journal is all about Service Management, including detailed architectural analysis of ITSM. Process, component, data architectures, finely detailed. Some marketing, but quite a bit of substance as well.

It's disappointing however that there is no discussion of how RUP fits into the picture. I also detected over-selling of CMDB discovery.

-Charlie

IT-relevant academia: perhaps not an oxymoron?

I've kept a small agent running in the background of my brain looking for relevant academic fora. These two have bubbled to the top over the past couple years:

ACM Symposium on Applied Computing, Track on Organizational Engineering

"Organizational engineering aggregates multi-disciplinary concepts, methods and technology to model, develop and analyze various aspects of changing organizations. One of its major concerns is to understand the enterprise architecture and the relationships between business strategy, business processes and the business support systems in order to create and keep the alignment between these complementary domains. "

IEEE EQUITY 2007, "the first IEEE Computer Society Conference on Exploring Quantifiable Information Technology Yields" (conference report)

"IEEE EQUITY is a new platform for researchers and practitioners to exchange ideas and results on exploring value creation (or destruction) through information technology.

"In particular, this conference focuses on quantitative methods for measuring, predicting, and understanding the relationship between IT and value. IEEE EQUITY will address the major challenges confronting quantitative approaches towards managing IT."

Any other useful academic work coming to light for anyone?

-ctb

ITIL v3 restores Data and Information Management

My ITIL v3 books arrived a couple days ago, so now I can start posting about this important material. First comment: ITIL has restored Data and Information Management as an element of the Service Design volume. This is not a new topic for ITIL; the ITIL version 1 Data Management volume was (and is) an excellent piece of work. For some reason it got lost in version 2. The v3 treatment is much briefer, but at least it's there.

This makes ITIL more compatible with COBIT; one of the most obvious ITIL v2 gaps was that COBIT calls for defining an information architecture ("Plan and Organize" control objective #2 - very prominent), where ITIL v2 was mute.

It's also a vote of confidence for the data management community (the folks who hang out at dm-discuss, belong to DAMA, and go to the Dama/Wilshire conferences.)

Charlie

More on value chains: Stabell & Fjeldstad

Finally, I have in hand a paper with some theoretical clarity regarding value chains, networks, and shops. That paper is Stabell & Fjeldstad, "Configuring Value for Competitive Advantage: On Chains, Shops, and Networks." (I am not sure how long that link will be valid.)

on the unification power of models

Some of you may wonder from time to time just what I'm going on about with these constant references to metamodeling. Jean Bezivin is a great thinker in this area; I was just reviewing some of his stuff while attempting to answer a question posted to the Yahoo group. Check out The Unification Power of Models. You'll never look at a CMDB the same way...

Charlie

My first ITIL v3 presentation

I attended a training/consulting firm presentation recently on ITIL v3, one of many I anticipate I'll be sitting through. A couple of random thoughts:

The presenter stated that the lifecycle focus of v3 should help those involved in the software development lifecycle to "feel included" in ITIL. My response: do they *want* to feel included? This is how the ITIL v3 advocate risks being heard:

CMDB for lawyers: federal litigation rule changes and IT/Data "maps"

In 2004, I noted the idea of the "Data Map," proactive documentation of IT assets undertaken in the interest of  litigation preparedness. With recent changes to the Federal Rules of Civil Procedure, the concept is crossing my radar repeatedly, sometimes termed "IT Map." See here, here, here and here. There is a distinct sense of urgency emanating from the legal community. So... any lawyers (or their IT discovery clients) reading this, please pay attention here.

ITSM and SOA

The relationship between IT Service Management and Service Oriented Architecture keeps bubbling up to the surface. It is a gold mine of confusion for senior IT executives, whose infrastructure and engineering leadership is talking to them about "Service Management" while their enterprise architecture braintrust goes on about "Business Services" and related SOA terminology.

Configuration management metrics

Like my friend the IT Skeptic, I am interested in getting more emprical in my ITSM approaches. In particular, I want to focus on metrics that indicate results, not just activity. (Results don't have to be financial.)

In the area of configuration management, a variety of operational reports and metrics are suggested by ITIL v2, many of them in the "activity," not "results," category.

An interesting "results" metric to me is requests for change that are not successful.

Another one is the cycle time to reduce incidents/problems.

I have an intuitive sense that a CMDB, in its role as knowledge repository, can "move the needle" on both of these metrics. But can I prove it? What if I implement a CMDB, along with a bunch of other effort, and availability improves. What do I say to the skeptic who challenges, "Prove that your CMDB contributed"?

One means might be a form of post-mortem change/problem analysis in which the contribution (positive or negative) of the CMDB data to specific changes or incidents/problems is assessed. That is, for each change or incident/problem, questions would be asked such as

• Was the CMDB consulted and found to be accurate?
• Did the CMDB data contribute in any way to the success or failure of the change or incident/problem resolution?

This is a difficult and subjective assessment for which we'd need to train the potential assessors in order to achieve any kind of consistency.

Pre-implementation baselining would be especially difficult, because you would have to ask the question in terms of "if we had a CMDB, would it have helped?" - an even harder judgement call for an analyst to make.

But without asking such questions prior to implementation, how do you prove the CMDB really helped? "Because ITIL says it's best practice" is not sufficient, I think...

Very interested in any thoughts.

-ctb

Hydrasight

Liking what I see of the Hydrasight materials via IT-Director.com:

ITIL: It'll get fixed in the next version

My comments: Agree completely that "ITIL version 3 will simply become a more business-aligned IT operations discipline rather than ITO-wide discipline." See this debate on IT Skeptic.

Defining IT governance (before someone does it for you)

Application management remains a misnomer

A correct semantic model is essential to this definition - something I've covered in my book. The critical distinction is between Application in its guise as a service (does someone wear a pager for it?) and in its guise as software (what I call a Technology Product in my Data Architecture for IT Service Management). If you land these two aspects as conceptually distinct entities you can begin to unwind the problems they cite here.

(re)Defining IT Service Management

A question I have also had. My current (unfortunately suspended) investigations into this focused on exactly when and how the concept of "Service Management" entered the business vernacular as a recognized domain of concern; the earliest B-school journal reference I saw I think was sometime in the 1930s. I'm curious who gets credit for first stringing the terms "Information Technology" and "Service Management" together if anyone knows. ITIL v1?

Ex - Meta folks, apparently. Good work, all.

-ctb

Integration Metadata wins Best Case Study at GIS 2007

Had  a great time this week at the Global Integration Summit in Banff. (The Fairmont Banff Springs is truly one of the world's premiere hotels.) Was very honored when the conference determined (through blended vote of peer reviewers and attendee evaluations) that my description of a metadata implementation for an Integration Competency Center was the best case study - had some formidable competition!

You can read the material in a slightly different format here, in the Fundamentals of Integration Metadata series. I'll see about providing the actual PDF but may take some time and substantively there's really not a difference.

CMDB folks: This case study can be seen as advanced topics in configuration management, what you might start doing after you finish with the basics of applications, servers, databases, and so forth.

I get questions from folks who just stop at the first article that are covered subsequently, please read all four if you want to discuss.

-Charlie

COBIT Focus framework analysis

Cobit Focus has an interesting article by Delton Sylvester, The Haze of Frameworks and Standards: Where does COBIT Fit?

One comment is that  (like many others) he makes the mistake of pigenholing ITIL as an operations framework. As I cover in detail in my book and elsewhere on this blog, ITIL is much more ambitious than that. Across all the volumes, it pretty much covers all of the IT value chain (as does COBIT); ITIL's problems are:

• it is not a "mutually exclusive and comprehensive" (ME & C) framework - instead, it is "overlapping tectonic plates" to paraphrase ITIL's own words (an analysis cop-out in my view).
• its disregard for enterprise architecture and poor coverage of IT portfolio management, 
• its occasionally idiosyncratic terminology, and
• its over-generalization of Change and Configuration Management.

ctb

IT Architect cartoon

Nice - although might be confusing to non-IT folks.

http://www.skyscrapr.net/blogs/video/archive/2006/03/10/46.aspx

-ctb

TJX data breach

Quote for the day:

"They didn't know what their sensitive information assets were, and who had access to them, and they didn't have adequate security controls in place," Taneja said. "Unfortunately for TJX, I suspect they are going to become the poster child for poor data security."

How do you secure data?

You must know where it is. It doesn't help to lock the front door if the back door is open.

"Knowing where the data is" is not easy. Databases with no data dictionaries, flat files with no schema documentation - if this describes your IT organization, then you do not know where your data is. Tribal knowlege does not count, at an enterprise scale. "Go ask Bob" does not work, when Bob gets a job with your competition.

So you need a metadata repository, and an understanding of your logical to physical mappings. You can't secure "Customer" data unless you understand that column CSTR_8XY_R7T_N in table GST_N_DT_TB in database GDB0234 actually contains their Social Security Number. (Yes those are made up names, representative of all too much I've seen.)

If you know where your data is, you still need to consider who and what has access to it. In general, any server can expose that data to any other server, whether it is a flat file or a database. So dependency mapping tools can help, but only partly. You need to define what other servers *should* have access to the data on GDB0234, in order for the dependency discovery tools to tell you there might be unauthorized access. This is a job for your enterprise CMDB.

If individuals have access, either directly or via applications, this has to be managed. Their managers need to be queried periodically to re-confirm that access. Obviously, people who leave need to have their access revoked. This seems basic, but in too many companies, it is only done for the major enterprise directory account held by the departing employee - if credentials are managed at the application level, these may not be purged. This is like only taking back the employee's keys to the front door, while letting them keep the keys to the storeroom.

Finally, you need to manage drift on your servers. Has someone installed a backdoor that shouldn't be there? This requires a defined release and provisioning process, preferably with automated tooling, supporting the detection of unauthorized changes. How do you distinguish "unauthorized" changes from "authorized"? No automatic solutions here; you have to have a strong Change Management process with teeth. Detected changes need to be reconciled to the approval process, and there are no silver bullets.  Long term, you go completely "fly by wire" and route *all* server changes through the provisioning tool. Much easier said than done at this time. What servers would be a priority for this level of control? Those containing customer sensitive data - back to the first point above.

Although the vendors still haven't gotten to this point, I continue to advocate my original thesis, that metadata management and configuration management need to converge to solve these sorts of problems.

-Charlie

Business IT Alignment Conference (bITa)

There is more to IT Service Management than ITIL. Check out bITa:

"The Business IT Alignment (bITa) USA Conference 2007 program and workshops will provide you with the practical approaches to the everyday challenges and opportunities you face in and help you developing an alignment strategy. Delivered by industry experts and qualified trainers, our workshops are an enjoyable way to improve your knowledge, understanding, and practice of the relevant domain, framework or model." 

"ASL and BiSL: keeping business applications up and running, up to date and under control ASL (Application Services Library) and BiSL (Business information Services Library) are public domain process frameworks and best practices that are often adopted by organizations as a logical enhancement of ITIL. Where ASL addresses Application Management from an IT perspective, BiSL focusses on the business responsibilities and processes to keep applications up and running, up to date and under control. More information on www.aslfoundation.org and www.bisl.nl."

In addition to ASL and BiSL there are other interesting subjects covered: http://www.bitausaevent.com/conference/conferencegrid.php

Thanks to Mark Smalley for pointing this out.

-ctb

Life is short

Off topic.

I purchased, composed notes for, and signed four condolences cards this weekend. (I probably have signed that many in my life, previously). All unrelated to each other, and to me - distinguished professional colleagues and executives who I know to greater or lesser degrees. (No sympathies necessary to me.)

While I will not discuss any specifics of course, the overall lesson remains top of mind for days now:

life is short. cherish the moments and the loved ones you have.

Charlie

SML submitted to W3C

Service Modeling Language has been submitted to the W3C.

The submission itself looks similar to what I looked at before. Extremely high level; not much there for me to react to yet - they are still wrestling with (from my practitioner's perspective) non value adding meta-meta work. (Yes, I suppose that being able to validate that if an XML type is acyclic then its derivations must also be is important... has to do with the graph-centric nature of internal IT data for those of you who are curious - but man, this is deep foundational work.)

Somebody please wake me when we start seeing some attempts to actually define service semantics.

I'm just sorry they didn't submit this to the OMG instead, but with Microsoft on board no way that was going to happen, and I'm also not sure how interested the OMG would be in this.

All I can say is that I want to model these services once, in a common environment with my software system construction. Is that so much to ask? Now we will need a translation from UML deployment diagrams into SML - no big deal, I suppose - preferably through some DSM workbench that supports both UML and SML. The SML models in turn will feed my release management system and CMDB. 

Would really like some discussion on this one.

Charlie

IT Financial Management Association conference brochure

Got the IT Financial Management Association's fine looking conference brochure today. This conference is June 25-29 in Las Vegas and entitled "The World of IT Financial Management." Not to be confused with the IQPC event.

Since ITFMA is a membership association I'm putting more interest there; I admire anyone with the gumption to make a professional association work.

I'm not going to reprint the description here, and there's no direct link, but anyone interested in application portfolio management should download the conference PDF and check out the Bank of America session on application total cost of ownership. Sounds like they've really done it. I hope to attend.

-ctb

Two days of fun at DAMA/Wilshire

I seemed to cram a lot into just two days this year at the DAMA International Symposium and WILSHIRE Meta-Data Conference. Sold out 30 copies of my book even before we got to my talk on Friday.

• At my 3.5 hr talk (started with 85, ended with 40, which was twice the expected attendance, with great audience participation), I queried the audience on my long-standing questions regarding the proper scope of Change Management and the definition of Service versus Application. The responses were overwhelmingly that Change Management is short lead time and not about project portfolio management, and that Application Management groups and managers in their organizations were *not* about to embrace the terminology of Service Management any time soon for their capabilities (although they might be doing all the pieces).
• Brushes with fame: Had a good laugh with John Zachman over his appearance in ITIL, and discovered that DAMA stalwart Bonnie O'Neil of Westridge Consulting is the mother of child star Chris O'Neil (The Last Mimzy).
• More tragically, found out that the missing Jim Gray of Microsoft was Series Editor for the Morgan Kaufmann Series in Data Management Systems; his Morgan Kaufman publisher Diane Cerra is also my publisher and knew Jim personally.
• Also hooked up with friends from Adaptive, which I consider to be the finest metadata repository out there as well as an EA tool and graphical DSM workbench.
• And of course, attended various and sundry excellent presentations and keynotes, including one by Don Tapscott (Wikinomics). 

DAMA/Wilshire continues to grow; it is a very large conference which sometimes surprises outsiders I think, because the subject matter can seem specialized. Just goes to show how big and diverse the IT community is. 

-Charlie

EAC in New Orleans - debate and discount

I'll be speaking at EAC in New Orleans, facilitating a debate and "audience karaoke" on

"Is Enterprise Architecture over-reaching?"

The propositions for discussion:

• Business analysis and transformation too often fails when seen as externally driven, and EA will be no better received by business partners than any other brand of consultant.
• The true locus of business/IT alignment is in portfolio management and the alignment of IT portfolio management with enterprise architecture is mostly wishful thinking.
• SOA is simply far too technical and attempts to turn it into a form of business architecture are misguided.

Are these my points of view? Before you jump too far to conclusions, please consider that in formal debate and forensics, one must be able to debate either side of a question... at the very least, let's just say I have encountered these points of view... and am interested in how to debate them effectively. Advocating for them in front of a room full of enterprise architects would seem to be one efficient means of gathering material (if perhaps a spot uncomfortable). And if at the end of the day I myself am unconvinced...

If anyone wants to share their points of view on the list - PLEASE do so! Pointers to relevant material much appreciated.    

Also, the conference is offering a one time special of $600 off the standard pricing  ... You can use the code FSWTL33 or register online at EAConference.com or call customer service at 781-995-4740.

Charlie

John Zachman, configuration management guru?

3/10/2007 Followup on this:

I ran into John personally last Thursday morning at the annual DAMA/Wilshire conference; had the ITIL Blue Book with me and showed him the passage. He was quite surprised and we had a good laugh about new career horizons opening up for him....

==========================

I am surprised that this passage from section 8.9.1 of the ITIL v2 Change Management chapter (Service Support volume) never leaped out at me before:

"John Zachman (an American Configuration Management guru) proposed some years ago that, if IT wished to follow the example of Configuration Management experts such as the aviation and engineering domains, then business and IT processes would have to be defined to an excruciating and hitherto unprecedented level of detail in order to be controlled."

It's a most peculiar passage. John Zachman (with whom I have passing acquaintance) is known as the father of Enterprise Architecture. I have never heard his name mentioned in conjunction with Configuration Management. You can see the major articles he has written, or acknowledges as influential, here:

http://www.zifa.com/bibliography.html

Nothing on Configuration Management, under that name.

But the peculiarity may be illuminating. I have read some idiosyncratic materials (can not remember where, and would be indebted for a reference) regarding configuration management, which expressed the view that true configuration management for the enterprise included "managing the configuration" of the business architecture: processes, capabilities, functions, and what have you.

I think that the ITIL change and configuration management chapters must have been written by someone of this persuasion, which (for want of a better term) I will call the "Enterprise Configuration Management" school of thought. Seeing John Zachman as a configuration management expert would be a logical extension of this point of view.

I don't have any philosophical problems with this perspective, just pragmatic and utilitarian concerns - I just don't think that the world is ready for this definition of configuration management, and in fact history is moving in a different direction.

Has anyone else encountered the Enterprise Configuration Management point of view?

Charlie

Application and Service Portfolio Management

A longstanding debate in IT service management is the relationship between Service and Application. Readers of my book and this blog know that I see an Application as a subtype of Service, not as a component of.

The alternative view is well articulated in various ITSM and ITIL materials: Applications are technical and too low level for the customer to care about. A hierarchy is proposed:

Service
depends on
System
depends on
Application

for example.

However, if one examines the reality of Application Portfolio Management: it is targeting a much higher level concept. APM requires information on financials, operational metrics, customer impressions, and so forth. See especially Bob Benson's book and product literature for Prosight and similar products. Also, a chapter from the excellent Handler/Maizlish book on IT portfolio management is available for free here. Note that Handler and Maizlish do not even use the term IT Service.

We would not be managing applications as a portfolio if they were mere subcomponents of something bigger (i.e. Service). We'd be managing the "something bigger."

The capture of customer perception in particular points up the contradiction. In the classic ITIL sense, the Application should be "invisible to the Customer." So why do application portfolio management products focus on customer satisfaction? Because application is a type of IT service - not a purely technical back-end function.

See also What's an Application Manager to Think?

Now, this does not preclude the existence of process-based IT services, such as Customer Credit Authorization, that are essentially transactional and may cross multiple systems.

-ctb

"Configuration": decomposing a troublesome word

Thought for the day:

“Configuration” is used in the sense of:

A configuration item – a discrete object of a given type. The router, the server, the software, the application.

The “configuration” of the item itself - the value of its attributes, parameter settings, etc. The router's IPv6 support is turned off. The server has 6 hard drives, and "Wake on LAN" is turned OFF. The Apache installation is running on port 8080.

The “configuration” of the item with respect to other items: dependencies, associations, feeds, etc. Oracle Financials receives a feed from CA Clarity. Price Lookup at the POS register requires Enterprise Catalog to be on line.

In the real world, these definitions are miles apart. What are you to say when a risk management professional waves COBIT at you and tells you to "manage the configuration." What do they mean?

The ambiguity will drive you crazy unless you are very precise… and as I've stated elsewhere, you need multiple systems to solve the problem in its entirety.

Charlie

IT Financial Management Association

If you are looking for highly detailed, in-depth information on IT financial management, check out the IT Financial Management Association. I have just ordered all four of their books.

Anyone else out there interested in Activity Based Costing as a basis for IT chargeback?

-ctb

Value networks article

Useful article on value networks. I remain unconvinced, but there is some meat there.

-ctb

Value network: a non-value-add critique of the value chain concept

2/18/2007 This article and associated debate is receiving a lot of hits. It's essential for the newcomer at least to read my IT Value Chain (excerpted from my book).

Also of interest may be:

The two faces of demand management

IT value chain from Brazil

-ctb

==========================================================

Recently I've become aware of a value chain critique called "value network." As stated on Wikipedia,

"The value networks model challenges the traditional notion of a value chain. Historically we have been in an industrial age, focused on a linear value model, and have recently begun to switch to a new business style in which there are a web of different resources that work together to create value."

For reasons that will become clear to all of you soon enough, I need to get on the record here. For the purposes of modeling enterprise IT service management, the value network concept adds no value to Porter's classic value chain, and, by obscuring the all-important distinction between primary and supporting processes, actually does harm. In fact, it appears to be a reaction to a caricature of Porter, not a fair reading.

I have Porter's seminal Competitive Advantage here on my desk. In his discussion of the value chain, in no place does he state that each step of the value chain is always sourced by one player, nor does he insist that the value chain be restricted to one firm. In fact, he is clear that the issue is complex, and that firms may achieve their value chain by increasing their scope or by partnering with others. 

His key insight is that - regardless of sourcing - value is derived from a logical sequence of activities. Supplier sourcing precedes manufacturing, which precedes distribution, and so on. The fact that any one of these sub-processes may have one to many parties fulfilling them is not relevant. That is an implementation issue.

What attracted me to the Value Chain concept is the distinction between primary and supporting processes. We struggle with this mightily in enterprise IT: architects versus developers; security staff versus operations. A conceptual framework to help us manage these contradictions is essential, and the Value Chain is the most useful I've seen: it's concise, accurate, and business people relate to it (because most of them have seen it in their MBA programs).

In enterprise IT, a Value Network is an instantiation of a Value Chain. They are not contradictory. Posing the Value Network as an "improvement" on the concept of Value Chain indicates a lack of understanding of the concept of abstraction, and ultimately is a naive critique. Value Chains are abstractions of Value Networks. They are how we understand and analyze Value Networks. To lose the abstraction is to dive back down into the muddy details that the Value Chain theory has started to help us clarify.

It is inevitable, of course, that an academic of the stature of Michael Porter should have attracted his critics. That is the nature of academia.

Yours,

Charlie

Rodrigo Flores blog

This is long overdue - Rodrigo is CTO of Newscale and a real mover and shaker in ITSM, especially in the area of service catalogs and service request management.  http://servicecatalogs.typepad.com/servicecatalogs/

-ctb

The death of computing

Via Slashdot. One of the most sensible recent articles by an academic computer scientist I've seen. Echoes a lot of things I've been thinking.

What he doesn't mention, however, is that the gaping hole he identifies between CS and industry represents highly compensated positions that we in industry are finding very hard to staff. Those positions are (generally speaking) enterprise architecture and related positions. And it's not easy to move into such positions without at least some understanding of CS fundamentals - but those are only necessary, nowhere near sufficient.

Charlie

front matter for my book available

If you want to see the table of contents, preface, and tables of figures for my book, go here:

http://books.elsevier.com/bookscat/samples/9780123705938/Sample_Chapters/01~frontmatter.pdf

-Charlie

The two faces of demand management

As I continue my journey through the terminology difficulties of modern IT management, one issue that keeps coming up (as recently as this week's IQPC IT Governance conference, where I spoke) is the question,

What is Demand Management?

There are actually TWO quite different interpretations:

• Demand for new IT services
• Demand upon existing IT services for (typically) increased transactional or storage capacity.

Consider this illustration, using my IT value chain:

So, where is this non-ITIL definition coming from, you ask? Why bother with it? I know it best from seeing a large outsourcer implement Mercury IT Governance (formerly Kintana, and now Mercury Project and Portfolio Management Center) at a former employer. If you are going to start extracting cash from an outsourcing engagement, one of the most critical things is distinguishing "base" from "incremental" expenditure, and the outsourcing team this firm brought in considered that to be demand management. They had clearly developed a whole set of practices and philosophies around it; it was not a casual usage of the term.

Increased demand for capacity increases existing services (the ITIL interpretation) was considered base and was of less interest to them; I think supporting that was baked into the contract and was not a margin opportunity.

I attended an excellent workshop put on by the folks from Swingtide and they also used demand management in this sense. (Topnotch IT finance folks if you are trying to figure out how to do IT chargeback based on activity based costing... but that's another post.)

ITIL consider this flavor of Demand Management flavor to be Change Management; readers of this weblog will know that I don't care for that definition. We have too many overloaded terms in enterprise IT and I think that disambiguating Change Management is preferable, especially since the project portfolio management vendors are calling it Demand Management. Let's keep Change Management in the data center where it belongs. Or qualify it, e.g. "Organizational Change Management" or "Human Change Management."

Cheers,

Charlie 

What is an appropriate S, G & A for "IT as a business"? Your CMDB budget depends on it...

Last of tonight's triple play (I must be feeling inspired).

Let's consider the "Run IT as a Business" concept. Let's say your IT budget is $250 million for a $25 billion corporation. The accountants probably consider that amount part of your corporation's SG&A (selling, general, and administrative expense). You're a paltry 1 percent of that overall revenue base.

But what if you were your own $250 million firm, managing an IT value chain for your (now separate) client? What if you had your own P & L?

Well, you would have overhead: salaries, rent, heat, lights, and (just like your parent company) you would have IT. What would your IT look like? It would be all the stuff you use to run the ITSM processes:

• Help Desk
• Management Framework
• Portfolio Management
• CMDB
• CASE & architecture tools
• Provisioning system

and the like. (See A simplified ERP for IT architecture )

You would be entitled to your own budget for these tools. I think 1% is a bit paltry - why not say 3%? That would be a healthy budget of $7.5 million per year for your internal IT tooling. Not enough to purchase all of it at once, but certainly enough to implement a sound infrastructure and keep it supported over time.

Are you spending 3% of your organization's overall IT budget on your internal tools? More? Less?

At least it's a baseline thought experiment that may prove useful to some of you if the business is questioning why you need to spend money on a CMDB.

thoughts?

Charlie

The fundamental purpose of Enterprise Configuration Management

Somewhat in response to Ron Palmer's recent CMDB critiques, I want to offer my most recent take on what the fundamental purpose and value proposition is for enterprise configuration management.

Now, before I give you this, you have to accept some premises:

• There is a distinction between enterprise configuration management and element configuration management.
• Dependency management is a fundamental function of enterprise configuration management.

If you accept these two premises (the second is consistent with ITIL; the first is not explicitly recognized by ITIL but is not inconsistent) then the fundamental purpose of enterprise configuration management is clear.

It's not about technology. It's making sure that the right people are talking to each other in IT, especially in the context of Incidents, Problems, and Changes.

How do we make sure the right people are approving the Change? Because we know what is dependent on a given Configuration Item, and who owns it.

How do we make sure the right people are on the 3:45 AM bridgeline to start restoring a service? Because we know that this Configuration Item is dependent on these others, any of which might be causing the interruption. 

There are of course any of a number of other valuable and worthy purposes; well managed data is always an asset. But first and foremost, the CMDB is about enabling effective collaboration among the IT service providers.

Thoughts?

-Charlie