lean4it

The architecture of IT value

Technology criteria for DevOps-participating tools

Moving on with the 2nd in my series of Enterprise Devops posts. 

As I write this, I am listening to this excellent presentation of John Allspaw and Paul Hammond of Flickr, which goes into great detail around the core DevOps problem of writing code and applying continuous integration principles.

However, my intent in this blog has more to do with the problem of "infrastructure as code." As I noted previously, DevOps practices in the enterprise case would need to accomodate a wide variety of tools and middleware beyond Java, RoR, and the LAMP stack.

In general, I view this all as an exercise in element configuration management (discussion of three flavors of configuration management, also element vs. enterprise config).  The question for the enterprise is 

to what degree is your current infrastructure technology portfolio suitable for DevOps practices?

Continue reading "Technology criteria for DevOps-participating tools" »

Posted by alphasong on January 30, 2013 | Permalink | Comments (3) | TrackBack (0)

Defining Enterprise DevOps

I have promises to keep. I've told numerous interested folks over the past few months that I would "soon" have some material out on Enterprise DevOps. So, here is the first in a series of posts on the topic.

To start: Semantics matter. What would we mean by Enterprise DevOps?  And in particular, 

how is "Enterprise DevOps" a value-adding, distinct category within the broader world of DevOps?

Continue reading "Defining Enterprise DevOps" »

Posted by alphasong on January 06, 2013 | Permalink | Comments (7) | TrackBack (0)

What is IT Value?

Every so often, one should tackle a Big Question. 

While the first (2006) edition of my book featured an IT value chain, I realized that I needed to think more deeply about IT value in the second edition. One new set of influences was Lean thinking applied to IT management. I'd read The Goal, other Goldratt books, and much Lean material. In particular, I was thinking about the following classic passage from The Goal, in which the protagonist (Alex Rogo) is asked:

...tell me, what is the goal of your manufacturing organization?" he [Jonah] asks.

"The goal is to produce products as efficiently as we can," I tell him.

"Wrong," says Jonah. "That's not it. What is the real goal?"

Continue reading "What is IT Value?" »

Posted by alphasong on June 05, 2012 | Permalink | Comments (13) | TrackBack (0)

When positive feedback isn't

I've been poking around at systems dynamics for a few years now. Currently studying John Sterman's Business Dynamics. 

One of the first topics covered in all the systems dynamics discussions I've seen is the correct use of the word "feedback." As Sterman states:

In common parlance the term "feedback" has come to serve as a euphemism for criticizing others, as in "the boss gave me feedback on my presentation." This use of feedback is not what we mean in system dynamics. Further, "positive feedback" does not mean "praise" and "negative feedback" does not mean "criticism." Positive feedback denotes a self-reinforcing process, and negative feedback denotes a self-correcting one. Either type of loop can be good or bad, depending on which way it is operating and of course on your values. Reserve the terms positive and negative feedback for self-reinforcing and self-correcting processes, and avoid describing the criticism you give or receive to others as feedback. Telling someone your opinion does not constitute feedback unless they act on your suggestions and thus lead you to revise your view. 

Tonight I tweeted the following: 

Businesses seek to stimulate positive feedback loops. Engineers try mightily to avoid them. Essence of the IT/business divide?

This tweet was asking for trouble, and I got it: 

Continue reading "When positive feedback isn't" »

Posted by alphasong on June 03, 2012 | Permalink | Comments (1) | TrackBack (0)

Three books for the next ten years

I try to keep up on my reading. It’s important.

In the past year or so, I’ve come across three books that I think complement each other nicely, and taken together outline a program for improving IT management. The books are:

How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas Hubbard

The Principles of Product Development Flow: Second Generation Lean Product Development, by Don Reinertsen

Analytical Network and Systems Administration: Managing Human-Computer Systems, by Mark Burgess.

Continue reading "Three books for the next ten years" »

Posted by alphasong on May 18, 2012 | Permalink | Comments (0) | TrackBack (0)

A data mining limerick

Thought you might all appreciate this limerick I wrote today (Merv Adrian said “there must be a limerick in there” and so there was):

My sixteen year old daughter is mild
But the ads she gets lately are wild
I say as her dad
Their computers are mad
Why does Target now think she's with child?

http://www.nytimes.com/2012/02/19/magazine/shopping-habits.html?_r=3&pagewanted=1

Charlie

Posted by alphasong on March 13, 2012 | Permalink | Comments (0) | TrackBack (0)

Business intelligence for IT White Paper

Quick cross-post - I am very pleased with how this report on an IT data warehousing product turned out:

http://h10124.www1.hp.com/campaigns/downloads/EMA_HP-ITPS-1011_WP.pdf

-Charlie

Posted by alphasong on January 03, 2012 | Permalink | Comments (1) | TrackBack (0)

Kindle confusion and other Amazon woes

I've been telling everybody and their sister that the Kindle version of my 2nd edition was only $9.99.

Boy, was I wrong. That's the price only for the 1st edition. (Why, oh why, do I so often believe things  too good to be true?) The price for the 2nd edition Kindle was not released until today, and it is a much steeper $42.67.

Not only that, it's really confusing to get the Kindle 2nd edition. If you first go to Amazon you get this (click for larger):

  Amazon

Disregard the $9.99. That's the first edition. You don't want that (unless you're a scholar interested in what I changed between editions). Trust me, the 2nd edition is better.

Notice the tiny little "+" icon I've circled on the screenshot above. Click that:

Amazon2(click for larger)

There's the real 2nd edition Kindle, with the price circled. Sorry for the price misinformation. Really not sure why they are burying it that way.

On another topic, if you do the "Click to LOOK INSIDE" you'll get this surprising result:

Amazon3(click for larger)

Bet you didn't know I was also an expert in the oil and gas industry! And only that cover is wrong, if you scroll down you'll see my book.

We're trying to get this straightened out, needless to say. But the interactions between my publisher and Amazon are a bit opaque to me. 

Anyways, what matters is you can get the book. Please let me know how you like it.

Charlie

 

Posted by alphasong on October 07, 2011 | Permalink | Comments (7) | TrackBack (0)

Second edition of Architecture and Patterns for IT

cover

This week marked an event I’ve been anticipating for a long time: the general availability of the revised edition of my book, Architecture and Patterns for IT: Service Management, Portfolio Management, and Governance (Making Shoes for the Cobbler’s Children).

(Amazon is now live, including the Kindle version of BOTH editions) - but see my clarifying post.

Continue reading "Second edition of Architecture and Patterns for IT" »

Posted by alphasong on October 05, 2011 | Permalink | Comments (0) | TrackBack (0)

Leave the "IT" in "ITSM"

Ada Lovelace
Ada Lovelace, Image via Wikipedia

A recurring idea in IT management discussions is that we need to lose the “IT” ("Information Technology") in "IT Service Management." Or maybe just the “T” or just the “I” -- I’ve heard all variations. The argument goes something like this:

“The IT label is killing us! They think we’re a bunch of geeks that don’t understand The Business! They are outsourcing us! They don’t understand us! We’re just a cost center! We have to kill the IT label and then they will think we are a Strategic Partner!"

That, in a nutshell, is the argument I’ve been hearing for years. I have some concerns. I think it is a negation of our fundamental identity as computing professionals.

Continue reading "Leave the "IT" in "ITSM"" »

Posted by alphasong on May 24, 2011 | Permalink | Comments (3) | TrackBack (0)

A career update, and the future of erp4it.com

As many of you may know, I have accepted a position with Enterprise Management Associates as Research Director for IT Portfolio Management.

I have a blog site there where I will be posting frequently, especially with regard to industry and vendor trends. That site is where I will talk specifically about companies and their software offerings.

I will keep this blog. It will remain more theoretical and postings here are likely to be less frequent and more essay-like. So, no real change, but if you want to hear from me more often, subscribe to my new blog's RSS feed.

-Charlie

 

Posted by alphasong on May 17, 2011 | Permalink | Comments (0) | TrackBack (0)

Chapter abstracts

Here are the draft abstracts for the major Second Edition chapters:

Chapter 1. IT in a world of continuous improvement

Abstract: Discussions of IT management struggle when they are not grounded in fundamental principles. This chapter sets forth working definitions of “Information Technology,” “IT Service,” “Lean,” and “Lean IT.” Basics of Lean and related continuous improvement are presented, with cautions as to their applicability in an IT services context. Proposed is the concept of two axes of IT value (product versus transactional). Establishing a correct analogy between IT and manufacturing operation is discussed, and the equation of IT transactional delivery with an assembly line is proposed and contrasted with the failed concept of software assembly line. Quality management in IT is summarized from a Lean perspective, and IT waste is discussed. Current trends in IT management are examined from a Lean light and a “TPS house” for IT is proposed. The Lean concepts of flow, small batches, kanban, and other terminology is presented.

Chapter 2. Architecture approach

Abstract: A generic enterprise architecture analysis approach is presented at an IT generalist level, based on the concepts of catalogs, matrices, and diagrams. The catalogs are enumerated, mutually exclusive and comprehensive lists of value streams, processes, functions, data entities, and IT management systems. Practical basics of IT transactional value are presented within an overall context informed by value chain and process management theory. Using entity lifecycle analysis, the IT value chain is decomposed into four major value streams: application service, infrastructure service, asset, and technology product. Also based on the entity analysis, nine cross cutting processes are proposed: demand, project, release, change, request, transaction, restore, improve, retire. Grounded in principles of functional and data architecture, forty IT functions and twenty-nine IT conceptual entities are defined. MRP and ERP origins, value, and challenges are discussed with reference to industrial literature, the idea of “ERP for IT” is introduced, and nineteen major classes of IT management systems are defined. Finally, each major catalog is matrixed to each other to show interactions.

Chapter 3. Patterns for the IT processes

Abstract: The concept of design patterns is introduced: named nuggets of insight addressing particular recurring problems in large scale IT management. The patterns in this book focus greatly on questions of integration and enabling processes and lifecycles to flow across the functions, via shared data. In this chapter, patterns for each of the nine major IT processes are discussed. Examples include Understand Aggregate Demand, Clarify Service Entry Points, Integrate Project Management, Integrated Release Management, Justify Change, Integrate Drift Management, Clarify Service Semantics, Integrated Continuous Improvement, Integrated Service Retirement and more. Extensive discussion of patterns surrounding Configuration Management is presented, including Distinguish between Element and Enterprise Configuration Management, Capture CMS Data at Appropriate Level, Mature the Configuration Management System Iteratively, and more.

Chapter 4. Patterns for the IT Lifecycles

Abstract: Continuing with the discussion of design patterns, this chapter focuses on the longest lived IT concepts, the multi-year lifecycles of application service, infrastructure service, asset, and technology product. The challenges of identifying these concepts are covered in detail, and overall lifecycles are examined in depth, with attention to data, function, and enabling systems. Patterns include Identify applications in the portfolio, Application semantics in detail, Integrate Application Portfolio and Configuration Management, Integrate Metadata Management; Applications, Infrastructure, and the ‘Hosting Zone of Contention;’ Solve the Vendor/Product Master Data Problem, Technology Product Lifecycle as Demand, Distinguish IT Asset Management from Configuration Management, Establish Traceability via Overlapping Identifiers, Portfolio Management Overview, and more.

 

 

Posted by alphasong on April 22, 2011 | Permalink | Comments (1) | TrackBack (0)

Wordle just for fun

Wordle of my book manuscript (all 139,000 words)

Click to enlarge

Wordle
 

 

Posted by alphasong on April 13, 2011 | Permalink | Comments (2) | TrackBack (0)

Generalizing the "Improve Service" process: emergent idea?

Alert readers may have have noticed in my overall process architecture the idea of a generic process "Improve Service," and corresponding concepts of Improvement Opportunity in the data architecture and Continuous Improvement System in the systems architecture.

This is the outcome of a long standing conundrum in considering ITIL as a process architecture: I can count Changes and Incidents, but I cannot count Capacities or Availabilities. And if I have initiatives to improve capacity or availability, those initiatives compete for the same resources answering service requests and resolving incidents, and prioritization across these activities is typically ad-hoc and local. Service improvements (under which I also include process improvements) can take many forms, and be driven from many uncoordinated directions in the enterprise.

These are important themes in the new edition, which goes into the problem of cross-queue prioritization in the large IT shop from a few different angles.

Continue reading "Generalizing the "Improve Service" process: emergent idea?" »

Posted by alphasong on April 02, 2011 | Permalink | Comments (2) | TrackBack (0)

A new preface

I'm struggling with a new preface and introduction for my 2nd edition. So here goes with new writing. Comments greatly appreciated. If you read the passage below, would you buy the book?

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

Around 2003, when I was leading an application team at Best Buy, I met a senior business executive. The conversation went something like this:

Exec: "So, what do you do?"

Me: "I'm building a metadata repository."

Exec: "Boy, that sounds like a business we shouldn't be in."

Demoralizing! Yet this interaction, and others like it, sowed the seeds of this book.

Continue reading "A new preface" »

Posted by alphasong on April 02, 2011 | Permalink | Comments (2) | TrackBack (0)

The “business of IT”...?

Some excerpts from my 2nd edition, relevant to current debates

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

[excerpt 1]

IT service development activities parallel those of commercial R&D organizations. IT service delivery and operations activities parallel those of corporate manufacturing and customer service departments. IT governance activities parallel corporate governance activities. IT is dynamic, but so are other disciplines, such as finance and logistics. IT is complex and uncertain, but no more complex or uncertain than engineering and demand forecasting. Get over IT! In concept, the fundamental management principles of all the disciplines are identical. We just need to do a little translation.[i]

                                                                                                                Jeff Kaplan

A well known thought experiment (dating back to at least 1971) in discussions of IT management is “run IT like a business.”[ii] Pragmatically, IT as a management domain can be viewed as a complex system of sustained economic activity, thus “a business” in significant respects. As implied by the excellent Jeff Kaplan quote at the start of the section, large IT organizations are subject to emergent dynamics that can be understood using tools from finance, operations research and industrial theory.

The idea is that if an IT organization (even one run as an internal “shared service” cost center) is managed “as if” it were a profit making entity, more disciplined and optimal allocation of IT resources will result.

Weaker forms of this concept also exist. Less emphasis may be placed on cost accounting and recovery, with more focus on operational issues. 

 

For example, IT portfolio management draws inspiration from portfolio theory in financial management. Demand management, a critical concern in manufacturing supply chains, is emerging as a prominent concept in IT project portfolio discussions. Infrastructure service provisioning bears similarity to Make to Order production processes.  And so forth.

However, the concept can be problematic. “IT like a business” may raise unintended red flags if perceptions are not carefully managed.

Captive cost centers may be in fact prohibited from attempting to become profit centers; such assumptions are typically fundamental to the enterprise business model. This does not preclude “running as a business” if the intent is to increase efficiency and effectiveness.

Other criticisms may arise in viewing internal IT service sponsors as “customers.” The customer is the person walking into the store with money in their pocket, the viewpoint goes, and any other use of the term is problematic.

 

Despite these concerns, this book relies on this thought experiment. As Terence Quinlan of the IT Financial Management association notes, “Managing lS financially as a business does not require a profit center structure. lS can remain a cost center.”[iii] Womack and Jones note that enterprise value streams often contain miniature versions of themselves, that is, they are fractal, an insight that also supports the “IT as a business” model.[iv]

It is difficult to reason about large scale IT, including the application of Lean concepts, outside of an “IT as a business” framework. Concepts in this book such as IT Value Chain and IT Value Stream rely on this foundation. “Customer-provider” relationships are found throughout the discussion, regardless of money changing hands. If this bothers you, substitute the term “sponsor,” “requestor,” or “user” as appropriate.

[excerpt 2]....claiming any “value” as “IT value” may be problematic. A claim to value is a political statement and often the managers of profit centers (or line managers more generally, e.g. program managers in a not for profit) compete for who receives credit for any increases in organization results (financial or non-financial).

IT, as a back office cost center, is in general not competitive in this fray, any more than peers in HR or Operations. Any claims to “value” from the IT organization may not be well received. And yet, there seems little choice in the matter, as IT is called on to account for its never-ending high costs. Such is the IT manager’s dilemma.



[i] (Kaplan 2005), p. 12

[ii] The concept of considering IT as a business within a business was conceived as early as (Ditri, Shaw et al. 1971) and (IBM Corporation 1981).  See also (Van Schaik 1985; Cunningham 1992; Curley 2004; Lientz and Larssen 2004; Lutchen 2004; Hunter and Westerman 2009; Ryan and Raducha-Grace 2010)

[iii] (Quinlan and Quinlan 2003), p.6

[iv] (Womack and Jones 2003), p. 322.

Curley, M. (2004). Managing Information Technology for Business Value, IT Best Practices Series. Hillsboro, OR, Intel Press.

Ditri, A. E., J. C. Shaw, et al. (1971). Managing the EDP function, The Touche Ross Management Series. N.Y., McGraw-Hill.

Hunter, R. and G. Westerman (2009). The real business of IT : how CIOs create and communicate business value. Boston, Mass., Harvard Business School Press ; London : McGraw-Hill [distributor].

Lientz, B. P. and L. Larssen (2004). Manage IT as a business : how to achieve alignment and add value to the company. Amsterdam ; Boston, Elsevier Butterworth Heinemann.

Kaplan, J. D. (2005). Strategic IT portfolio management : governing enterprise transformation. United States, Pittiglio Rabin Todd & McGrath Inc.

IBM Corporation (1981). A Management System for the Information Business, Volume I, Management Overview, 2nd ed. A Management System for the Information Business. White Plains, NY.

Lutchen, M. (2004). Managing IT as a business : a survival guide for CEOs. Hoboken, N.J., J. Wiley.

Quinlan, T. A. and S. J. Quinlan (2003). Readings in IT Financial Management. Santa Barbara, CA, IT Financial Management Association.

Ryan, R. and T. Raducha-Grace (2010). The business of IT : how to improve service and lower costs. Upper Saddle River, NJ, IBM Press.

Van Schaik, E. A. (1985). A management system for the information business : organizational analysis. Englewood Cliffs ; London, Prentice-Hall.

Womack, J. P. and D. T. Jones (2003). Lean thinking : banish waste and create wealth in your corporation. New York, Free Press.

 

 See also (Van Schaik 1985; Cunningham 1992; Curley 2004; Lientz and Larssen 2004; Lutchen 2004; Hunter and Westerman 2009; Ryan and Raducha-Grace 2010)

Posted by alphasong on March 13, 2011 | Permalink | Comments (1) | TrackBack (0)

IT as a business: a 40 year old thought experiment

Reacting to some debate over at IT Skeptic:

"Run IT as a business". What a mantra. It is of course rubbish.

Well....

Just going through some references on the "IT as a business" topic. It is a thought experiment with a long pedigree and has less to do with the Wallys of the world fantasizing, Walter Mitty-like about their little kingdoms, and more to do with attacking IT exceptionalism and obfuscation.

While Cary King notes that Dean Myer (www.fullcost.org) has been using it for about a decade, the history goes way back... the earliest cite I can find is from 1971:

DATA PROCESSING AS A BUSINESS ENTERPRISE
In management terms, the EDP function can be looked at as a cross section of the business as a whole. Definite parallels can be drawn between the medium-to-large-sized EDP organization and an overall company. This book will cite several examples comparing the EDP function as a business-in-miniature with comparable functions in a typical manufacturing company. However, it should be stressed that similar comparisons exist and can be made between the EDP function and virtually any type of business organization. To illustrate:

■ The computer as a unit of production equipment parallels large machine tools or other units of factory equipment.
■ Systems analysis and engineering are comparable skills.
■ Programming and drafting are functions of similar position within and importance to the overall processes of which they are a part.
■ Technical services for EDP and manufacturing engineering are parallel functions.
■ Scheduling, line supervision, personnel, payroll, budgeting, and accounting functions all have direct counterparts between the EDP function and a manufacturing business as a whole.

In management terms, then, the EDP function is a business-in-miniature.

Ditri, A. E., J. C. Shaw, et al. (1971). Managing the EDP function, The Touche Ross Management Series. N.Y., McGraw-Hill.

Similarly from 1981:

We believe that the solution to this "image" problem lies in the disciplined application to data processing of the same general management principles that have been used successfully for many years in the management of other similar business operations in, for instance, the manufacturing and processing industries. In other words, a management system needs to be established that provides a sound basis for control of the data processing operation, provides a proper mechanism for effective communication between all parties concerned with data processing, and encourages a businesslike attitude in the individuals involved.

To emphasize this business approach, we will expand the traditional view of data processing into an Information Systems (i/s) business within the overall enterprises business environment. This business within a business concept will allow us to identify the role of corporate and user management in guiding and monitoring this l/s business.

IBM Corporation (1981). A Management System for the Information Business, Volume I, Management Overview, 2nd ed. A Management System for the Information Business. White Plains, NY. (Famous "Yellow Book" series)

And my favorite quote:

IT service development activities parallel those of commercial R&D organizations. IT service delivery and operations activities parallel those of corporate manufacturing and customer service departments. IT governance activities parallel corporate governance activities. IT is dynamic, but so are other disciplines, such as finance and logistics. IT is complex and uncertain, but no more complex or uncertain than engineering and demand forecasting. Get over IT! In concept, the fundamental management principles of all the disciplines are identical. We just need to do a little translation.

Kaplan, J. D. (2005). Strategic IT portfolio management : governing enterprise transformation. United States, Pittiglio Rabin Todd & McGrath Inc.

Other citations along these lines, either with a title clearly indicating the "IT as a business" meme or significant internal content discussing it:

Van Schaik, E. A. (1985). A management system for the information business : organizational analysis. Englewood Cliffs ; London, Prentice-Hall.

Curley, M. (2004). Managing Information Technology for Business Value, IT Best Practices Series. Hillsboro, OR, Intel Press.

Lientz, B. P. and L. Larssen (2004). Manage IT as a business : how to achieve alignment and add value to the company. Amsterdam ; Boston, Elsevier Butterworth Heinemann.

Lutchen, M. (2004). Managing IT as a business : a survival guide for CEOs. Hoboken, N.J., J. Wiley.

Hunter, R. and G. Westerman (2009). The real business of IT : how CIOs create and communicate business value. Boston, Mass., Harvard Business School Press ; London : McGraw-Hill [distributor].

Ryan, R. and T. Raducha-Grace (2010). The business of IT : how to improve service and lower costs. Upper Saddle River, NJ, IBM Press.

Finally, if one chooses to disregard the IT authors, then there are still Womack & Jones to consider, in Lean Thinking:

Finally, we've discovered that these value stream and product line managers, like so much in the lean world, are 'fractal'.

That is, a product line manager overseeing an entire product may work with a number of value stream managers at lower levels taking responsibility for different courses of the value stream. For example, a chief engineer (to use Toyota's term for a product line manager overseeing an entire automotive platform) works with a development leader in design, a value stream manager in the assembly plant, and value stream managers in each of the component plants working on major items assembled into the finished product. Each manager is essentially doing the same job but with varying scope—wide at the top and narrow at the bottom.

Womack, J. P. and D. T. Jones (2003). Lean thinking : banish waste and create wealth in your corporation. New York, Free Press.

I think such approaches represent a valuable and necessary thought experiment, fundamental to my own writings as well. I also think it scales to IT problems in the small as well as large. Certainly, it doesn't imply turning IT into a profit center.

So, I guess my question is whether someone wants to attempt a more systematic statement, e.g. "'IT as a business' considered harmful." I think that debunking the concept will take a little more than invoking Wally. Are all these authors misguided?

 Updated: some relevant excerpts from my book on the next post.

 

Posted by alphasong on March 12, 2011 | Permalink | Comments (1) | TrackBack (0)

Integrated Service Request Management

Service Request integrations

There are many possible integrations for a Service Request Management system. Figure 66 is presented as a reference model with a number of possibilities to consider.

  • The core of a service request system can be decomposed into the catalog – the means for publishing the services – and the fulfillment mechanisms.
  • There may be multiple fulfillment mechanisms, depending on the requirements of what is being done. General purpose BPM engines are common in service request management tools, but may also be found in problem domains such as Access Management.
  • Depending on how Demand Management is structured, some service requests may originate there.
  • As previously discussed, the Change Management system may generate Service Requests as work orders. (This may in turn be driven by Release Management.)
  • A common form of Service Request is for software installation and in mature environments this is aligned with Software Asset Management so that entitlements are correctly managed.
  • Access Management may be a common Service Request and (as above) is actually a key link between the Application Portfolio and the Service Catalog.
  • Element Management systems may interact in various ways with service requests and their fulfillment systems. For example, in the new forms of dynamic provisioning architectures, a virtualized development environment might be offered and requested, with a BPM engine actually interacting with the virtual server manager to create the new resource.
  • The Configuration Management system may be updated as a result of Element Management activity, and may also provide various inventories of CIs to the Service Request management system against which people can file requests.
  • Incident Management of course must be tightly integrated with Service Request Management, due to the basic ambiguity of “is it an Incident or a Service Request” – a question which the requestor may not understand when initiating Service Desk contact.
  • Projects may rely heavily on Service Requests. Project identifiers may be used as funding channels and valid IDs in such cases are required to flow from the Project Management system to the Service Request system.
  • Finally, the IT Data Warehouse should receive summary and perhaps detail information on service request traffic and performance, for integration with other IT management data.

 

(click for larger)

 

Posted by alphasong on January 30, 2011 | Permalink | Comments (3) | TrackBack (0)

A simple failure demand metric for the Service Desk

British management consultant John Seddon emphasizes the centrality of understanding “Failure Demand” for services organizations. Failure Demand is when Service Requests or Incidents (or perhaps other processes) are repeated due to the fact that they weren’t done right the first time.

For example, a user calls in a request for Microsoft Excel to be installed, which is done. The user then has to call back however because the Excel PowerPack extensions were not installed, which the user requires to do their job.

Or the user calls in an incident but then is ill for a couple of days, and unable to respond to Service Desk queries. Because the Service Desk is incented on closing tickets quickly, the user’s incident is closed out and they must re-open the ticket when they come back into work.

A simple design pattern for addressing this: instead of reporting only on the Service Request and/or Incident ticket closure durations, also report the average and peak #s of tickets called in by each user. Slightly more formally, frame a query thus:

For each user calling in at least one Incident or Service request, how many called in more than one within a four week period?

Recurring incidents or service requests for particular users is a clear and relatively tamper-proof means of identifying failure demand. Certainly, complaint-prone users, or new employees with multiple needs, also show up in these metrics, but they would still be useful.

Thoughts? Anyone doing this?

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

further thoughts: This of course seems similiar to the well understood concept of First Call Resolution. But scanning some references, I'm concerned exactly *how* FCR is asserted... is it too prone to self serving interpretation by Help Desk analysts? Similarly, % of tickets re-opened is sometimes tracked, but that assumes that the help desk allows/encourages re-opening of tickets - some don't, in my experience. One study of typical help desk metrics.

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

8/4/2011 Even more - after I wrote this, I then encountered this HBR article, counterintuitively titled "Stop Trying to Delight Your Customers." Don't let the title turn you off, it's all about the issues here.

Posted by alphasong on January 30, 2011 | Permalink | Comments (0) | TrackBack (0)

Release management integration pattern - seeking devops comments

IntegrateRelease
 (click for larger)

The above shows a comprehensive reference integration for release management, suitable for large environments and based on a combination of ITIL, Dev/Ops, data center automation, and event management . The above component diagram supports the following sequence and variations:

  1. The software checked into source control is built, and tests (automated and/or manual) applied.
  2. Passing the tests, the software is checked into the definitive software library.
  3. The Release Management system registers a Change with the Change Management System.
  4. The deployment system pulls it and associated configurations from the definitive software library and passes it to the data center automation tool (a special class of Business Process Management system optimized for interacting with element management systems).
  5. The Data Center Automation tool raises events as appropriate as it feeds code and configuration files to element managers for application to production.
  6. The Element Management systems notify the Configuration Management System of updated CIs and dependencies, as appropriate.
  7. (Failure scenario) The element managers (in particular their monitoring components) raise events indicating errors or performance issues to the event management system. If unexpected behavior is violating defined thresholds (SLAs or internal limits, including dynamically managed thresholds), the event management system automatically contacts the automation system for rollback of the change. The event manager and change management system are notified of the rollback.

Would really appreciate feedback from you devops folks.

Posted by alphasong on January 25, 2011 | Permalink | Comments (7) | TrackBack (0)

Next »

Search

Recent Comments

  • Brandon on Defining Enterprise DevOps
  • alphasong on Technology criteria for DevOps-participating tools
  • alphasong on Kindle confusion and other Amazon woes
  • cwalker on Kindle confusion and other Amazon woes
  • alphasong on Technology criteria for DevOps-participating tools
  • Niek Bartholomeus on Technology criteria for DevOps-participating tools
  • Solomon Norman on Software development is product development
  • Susan Ryan on Defining Enterprise DevOps
  • alphasong on Defining Enterprise DevOps
  • Peter Kretzman on Defining Enterprise DevOps

Recent Posts

  • Technology criteria for DevOps-participating tools
  • Defining Enterprise DevOps
  • What is IT Value?
  • When positive feedback isn't
  • Three books for the next ten years
  • A data mining limerick
  • Business intelligence for IT White Paper
  • Kindle confusion and other Amazon woes
  • Second edition of Architecture and Patterns for IT
  • Leave the "IT" in "ITSM"

The Book

  • At last!

About

Subscribe to this blog's feed
Tweets by @CharlesTBetz