Enterprise Management has been a somewhat strange market over the years. The problem definitions are really tough but are rewritten to lessen the amount of development needed to achieve something that marketing can spin. Some elements like correlation and root cause analysis have been dumbed down and respun in an effort for many to tout a "me too" to the uninitiated.
Other areas like performance management platforms have become huge report generators. After all, pretty graphs and charts sell. In some systems, it is amazing the amounts of graphs produced, 90% of which may never be looked at.
The other amazing part is that even though a product is evolved and bought out, there comes a point where design decisions of the past dictate what can and cannot be done going forward. And this holds true for not just the older products but some new ones as well. It is incredible to see a product that in its relatively young life cycle that has already mandated the inability to extend the architecture further.
The emerging technologies that have come to light most in the past 3 years or so are
provisioning, configuration management, and workflow automation. This
is especially true in the Cloud realm as Cloud needs standard
configuration items, a way of automating provisioning, and ways to
pre-provision systems overall. After all, virtualization is the
technology and Cloud is the process.
OK - What's Missing?
I
know we've seen all of the sales pitches on performance management
with charts and graphs. And we've been barraged by the constant
pitch for business services management with its dashboards and
service trees. And we've seen the event and alarm lists, the maps,
and even ticketing.
Someone
once said that "a fool with a tool is still a fool".
Effective Enterprise Management
Architectures and implementations have NEVER been about tools. Tools
are the technology and Workflow is the process. Tools do
nothing for the bottom line of an Enterprise or Service
Provider without someone using it. In fact, the tools that are not
used usually become shelfware or junkware. In many cases, you can't
even sell the stuff to some other fool looking for a tool.
One
of the most interesting assessments of emerging technologies is the
Gartner Hype Cycle. Here is the Wikipedia article on the Hype
Cycle.
While
it is not so scientific and not really a cycle per se, it is a way to
describe the subjective nature of a technology and the phases it goes
through. Interestingly, there are five different stages in the
Gartner Hype Cycle. Following is an excerpt from Wikipedia describing
the Hype cycles.
Five phases
Hype cycle for emerging technologies as
of July, 2009
A hype cycle in Gartner's
interpretation comprises five phases:
- "Technology Trigger" — The first phase of a hype cycle is the "technology trigger" or breakthrough, product launch or other event that generates significant press and interest.
- "Peak of Inflated Expectations" — In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.
- "Trough of Disillusionment" — Technologies enter the "trough of disillusionment" because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.
- "Slope of Enlightenment" — Although the press may have stopped covering the technology, some businesses continue through the "slope of enlightenment" and experiment to understand the benefits and practical application of the technology.
- "Plateau of Productivity" — A technology reaches the "plateau of productivity" as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market.
The term is now used more broadly in
the marketing of new technologies.
Now keep in mind, the hype cycle is
very subjective. Dependent upon perspective, one person could place
a given technology in a different category than you would. (This is
why you enlist the expert analysis of the Gartner Analysts.)
Workflow Automation
You
see a significant number of Workflow automation products that are
just now coming into Service Providers and Enterprises. Part of this
is being driven by requirements from cloud services. Cloud Services
NEED to be automated. The services need to be automated and user
driven as much as possible.
Did
we ever get to be ITIL compliant? Or is there such a thing? Maybe
for ticketing systems. But do your organizations reall truly
follow ITIL Incident and problem management to the letter? Can your
organization?
ITIL
defines an Incident as :
--------------------------------
Any
event which is not part of the standard operation of a service and
which causes, or may cause, an interruption to or a reduction in, the
quality of that service. The stated ITIL objective is to restore
normal operations as quickly as possible with the least possible
impact on either the business or the user, at a cost-effective price.-------------------------------
Effective
workflow automation and process optimization begins with a baseline
of the process. If you cannot define the process or measure it, how
will you improve it? In the spirit of getting ITIL Incident
Management to be optimized and effective, one needs to
implement effective business process management techniques.
But
there are psychological and philosophical problems with how processes
are approached and presented. Some of these "issues" include:
- The belief that documenting the process is to train someone else for your job.
- The belief that documenting some technical processes is impossible as it takes into consideration judgement and subjective decisions.
- The belief that documenting processes gets in the way of
actual work.
A
significant amount of this is Fear, Uncertainty, and Doubt or FUD.
But it can block or kill effective process optimization. You
have to manage to and reward process optimization.
Knowledge Management
While you see
segmented implementations of Knowledge Management by various products
or as modules in ticketing systems, rarely do you see somewhat robust
implementations beyond the very large Service Providers.
Knowledge
Management takes knowledge, facts, and references, organizes that
information and makes it available in the various processes as a way
or method of putting the knowledge to work. For example, an event is
presented to a level 1support person that denotes an actionable
event. In the course of this work, knowledge can be presented at
several different aspects to include:
- Notification instructions to contact the customer
- Escalation instructions to the appropriate Triage Team
- Recent histories of the elements in question
- Scheduled actions and maintenance actions
- Recent Configuration changes.
- Checks and validations process data.
Knowledge
Management takes information and creates confidence and situation
awareness in support organizations. The knowledge enables each and
every user or support member to work with common technical terms
regardless of level of expertise. Even simple knowledge management
tasks such as attaching linkages to vendor technical documentation to
configuration records,enables users to be able to reference and
communicate better regarding diagnosis, configuration, or
provisioning.
Collaboration
When take a step
back and look at every application on the market today in the
Enterprise Management realm, the one thing that sticks out profoundly
is the lack of collaboration capabilities and multi-user awareness.
Not one single application has user awareness. For example, you open
a network map. Who else is in that map? When you open a ticket, who
else has that ticket open?
Applications
don't really enable folks to work together. They are more geared
toward individual actions. Then when that person is done, it is
escalated to the next person. And when things move across products,
it is even worse.
Consider the
customer who calls into a service Provider with a problem. The first
level takes down the ticket information, runs through some run book
elements, then escalates the ticket to the next level of support. At
this point,the customer is told they will get a call from the next
tier. So, the customer hangs up and waits on the next call. In this
scenario, who owns the problem? What if Tier 2 doesn't call back for
a long period of time?
While this
scenario is all too common, who is collaborating? The customer is
stuck dealing with a bunch of individual contributors to get their
problem resolved. There is no team. The only way the customer gets
a team is to initiate an escalation to the Service Representative for
the Account and crank up a conference call with all of the Managers.
Effective
customer service and customer support is a TEAM effort that requires
collaboration and socialization. It is not about fielding tickets.
It is about taking care of the customer.
There are
products on the horizon that will empower collaboration as a whole
but still, a significant amount of work needs to be done on each
individual product.
The Hype Cycle
The Gartner folks are much more precise and much better at accurately listing the Hypecycle than I am capable of. However, I like the way it depicts a product or technology lifecycle. I am merely overlaying my opinion on the Gartner definitions. While I know its subjective and only my opinion, here's
where I put these technologies in the Gartner Hype Cycle:
There are a significant number of
product offerings in the industry that do these functions. And
getting more and more each day. While we do see new product
offerings for the same sort of functionality, everyone seems to think
they do it better. Yet many fall short, are too complex to maintain,
or are too expensive.
The big players have purchased many of
the initial workflow automation applications and next generation
applications are in process. Additionally, BPM related systems are
being enhanced to perform more of the workflow automation associated
with Enterprise Management.
Interesting links:
While there are a couple of KM systems offerings, most of the implementations are released as product features or are developed by large service providers for in house use only. For example, there are KM functions in SCOM/SCCM. Additionally, there are KM modules for ticketing systems like Remedy.
What you do see is that larger Service Providers are investing heavily in KM systems. It is done for many reasons, chief among them is driving down the cost of support and leveraging knowledge across multiple customers. Makes sense as these large outsourcing and service providers are usually a training ground for entry level personnel. Implementing KM systems is an accelerator for learning in these environments.
Interesting links:
WiiKno - The company helps organizations put in place Knowledge Management systems and integration.
Microsoft Knowledge Management Architecture paper
BMC Knowledge Management
Collaboration – “Technology Trigger”
There are a couple of emerging technologies here that could very well redefine how IT organizations perform operations and support. You may very well see some older technologies (Like Ticketing) take a back seat to newer collaboration and socialization technologies.
Part of the problem is that ticketing systems rarely capture enough information to do detailed operations analysis and optimization. They are typically too user overbearing to facilitate much of the real time notes that get missed or input after the fact.
When problems are ongoing, do you get the full monte of whats going on? Or do you have to aggregate your own picture? How effective is your post mortem analysis data? Do you see and recognize involvement by different support functions, business units, and the customers?
Interesting links:
MOOGSoft - Check out the guys behind the curtains.
No comments:
Post a Comment