Posted by Roy Eldar
on June 7, 2016 in Service Desk
I was trying to get support from a supplier recently and, after considerable delay in reaching a service desk agent, I was upset to be able to hear the boredom in his voice. It was a routine call perhaps, but I was having a domestic crisis and needed something fixed that day. Why was this guy sounding so uninterested?
In the ITIL®
Service Transition book, the authors made up a term to describe this: “Emergency Room Syndrome”. In that book the term is used to describe the need to remember – as a front-line service agent – that however routine the job and the situations become to you, it is essential to remember that many customers are experiencing disruptive events for the first time. They will be upset, possibly frightened and probably tense and stressed. Good agents will not only be aware of that, but will respond and support that level of crisis, offering calm but interested support and prioritizing in accordance with the customers’ needs, not their vision of routine.
Common to You but Unique to Them
The Service Transition book analogizes this attitude to that needed in a hospital emergency room, where the doctors and nurses have seen it all before but for each patient, it is new and frightening. The service desk agent I spoke to on the phone that day did not act in this way, so I had no choice but to calm down and let his routine approach lead (eventually) to getting my crisis assigned to an engineer….who luckily came and fixed things for me.
Intrigued by the term “Emergency Room Syndrome”, which I hadn’t seen used for a while, I Googled it to see how common it is. To my surprise, it seems different people had each invented the same phrase to mean different things. Even more entertaining was that other meanings also make sense and have value in a service management and customer care situation. So I thought it was worth looking at, and sharing in this blog, as it can help you deliver good service management, just like the kind of Emergency Room Syndrome that ITIL talked about. Here are two uses of the term with lessons for us in IT service management (ITSM).
Talking to Angels
Perhaps the least expected example is found in a book
that is about talking to angels to ask for help. Many people tend not to seek outside salvation until faced with damaging emergencies. But it is an aspect of customer behaviour we are familiar with in service management. Instead of alerting us when things start to look wrong, or while there is time to correct it routinely, we don’t hear until the situation is extreme, when it has to be fixed immediately or cause business damage. Avoiding this, mentioning things early or at the first warning sign can make a major contribution to keeping services going rather than having to react in an emergency – which is rarely efficient, and always risk laden.
Going with the Adrenalin Flow
Another disparate use of the term is featured, among other places, in a professional book
on global health governance
. What the author refers to here is how it seems easier to wait for a crisis and respond than to put effort into preventing a crisis. That is a message close to the heart of every competent availability manager. Amazingly, it seems customers/users are more impressed when we fix things than when we prevent things from going wrong. Skill in the emergency room is more valued than keeping folks healthy, when all logic says we should feel the opposite.
What’s the Message?
Just a bit of fun with words maybe, but it does show some things of value to us:
- Be sure that others have the same understanding as you when you use a phrase.Technical and business jargon, for example, can be a source of misunderstanding. ITIL terms like incident, problem, utility and warranty might have clear meanings to IT staff, but will be used to mean different things by the rest of an organization. The IT department supporting a police force might find the term ‘incident’ has a precise meaning amongst their users – a situation requiring the attendance of a police officer!
- Emergencies have multiple influences on our behaviour.Understanding the diverse impacts of emergencies is, or at least should be, important to us in service management. Planning and agreeing courses of action to take, during an emergency, is sensible preparation. Realizing that things may feel like emergencies to others, even if they don’t to you, is important too.
- Customers have an important role to play in avoiding emergencies by reporting initial symptoms rather than waiting for major issues to manifest.Try to encourage this proactive behaviour by ensuring there is a simple mechanism for communicating concerns, and that customers are not blamed or ridiculed by IT for raising concerns. Adopting the approach used by airlines and air traffic control of reporting and investigating ‘near misses’ is an idea worth considering within many ITSM environments.
Stopping the Fire Is Better than Putting it Out with Style
The lesson for us in ITSM could be as simple as this: avoiding emergencies is better than solving them. When you see emergencies as routine and normal, then you can unconsciously be delivering bad customer service.
Does your organization reward the fire-fighters more than fire preventers? If so, perhaps it’s time to question that.
Posted by Stuart Rance
on May 31, 2016 in General IT
DevOps is currently very fashionable, and so I hear lots of people talking about how their IT organization will be doing DevOps over the next year or so. The trouble is, as soon as I hear this I cringe, because I can’t help thinking about all of the failed improvement projects these same IT organizations have run in the past. Their stories are remarkably similar and they go something like this…
”We Tried That and It Didn’t Work”
When ITIL was the new approach that everyone wanted to use, these organizations decided that they were going to “do ITIL.” This tended to involve devoting lots of resources to a huge, tool-based, monolithic project, with a team of hard working and technically expert consultants who spent many months – sometimes even years – buying tools, creating process documentation, and configuring the tools to match. The IT organization was then tasked with attempting to follow these new processes. All too often they had virtually no understanding of the reasoning that underpinned the new processes, very little focus on their customers, and even less focus on creating value
. The results of these projects were predictable; lots of money was spent but no value was created. These organizations later said, “We tried ITIL a few years ago, and it didn’t work”.
Some of these same organizations next tried to implement COBIT
. As you may know, COBIT
is a framework for the governance of enterprise IT, and like all governance approaches it must be driven from the top down; to ensure that IT is aligned with the rest of the business, it is essential for governance to come from outside the IT organization. Unfortunately, these COBIT projects were often owned and managed by the IT department, and this again resulted in a technical focus that couldn’t deliver. “We tried COBIT and that didn’t work either.”
Now some of these same organizations tell me that they are going to “do DevOps” and I know that in a year or two they will be telling me: “We tried DevOps and it didn’t work.” And they will certainly be right about it not working, but not because there’s something wrong with DevOps.
How You Should Adopt DevOps
What’s wrong is the approach these organizations take to planning improvements. You should never implement a best practice, a framework, or a standard as an end in itself. Things like ITIL, COBIT, and DevOps are resources. They are sources of excellent ideas that you can use to help improve how you deliver service to your customers. But until you understand that the entire purpose of an improvement project is to increase the value of whatever it is you deliver to your customers, your project is bound to fail. A new practice may be fashionable but it’s the way you implement it that decides whether or not it delivers value. And any new practice that doesn’t deliver new, improved or additional value is not worth the effort you expended on it.
So, if you are thinking about whether DevOps is right for you, you should start by thinking about your customers, and how you create value for them. Some of the questions you might think about are:
- How long does it take us to respond when our customers ask for new services or new features?
- How quickly can we test and release software in an emergency, e.g. for a security patch or a regulatory requirement?
- How often do our changes go wrong, either taking too long, costing too much, causing incidents, or simply failing to deliver the expected business value?
If the answers to these questions show that you need to make improvements, then sit down with your customers to talk about what they need. Get a feel for what they would really like from IT if you could deliver everything they dream about. Then agree on a vision, and share it with all your stakeholders.
Once you’ve done that, it’s time to have a look at some of the great DevOps ideas to see how they could fit into your environment and help you deliver what you have agreed you want to achieve. You’ll almost certainly find many ideas you’ll want to use. But don’t try to change everything at once. Think about incremental improvements you can make that will take you towards your vision. Maybe you can automate testing for some of your services, to reduce errors and increase change throughput. Or maybe you can improve collaboration between your developers and your operations teams, so there is less conflict and more success during handover. You should certainly attend some DevOps conferences to get a feeling for what other people are doing, and see if there are any ideas that you could adopt. You should also read this blog
about how the service desk can help you succeed with DevOps.
Just remember that even if your vision is to have a completely integrated set of tools that will automate your entire software delivery pipeline, these tools are not the goal. Don’t be distracted by the shiny toys and forget about value creation and customer experience. And, please, don’t just “do” DevOps!
Posted by Sarah Lahav
on May 24, 2016 in Service Desk
Leading and managing an IT service management
(ITSM) team can be tough. Not only do you need to think about your own performance, how you feel about your job, and your motivation, there are also the perspectives on the team as a whole and of the individual team members.
Team dynamics are an interesting thing – I guess that anything that involves people and the unpredictability of human behavior always is. Even if you’ve handpicked each team member from the crème de la crème
of the ITSM industry there will still be times when day-to-day operations are adversely impacted by personality clashes, personal issues spilling over into work, and general slumps in performance. Sadly, it can be even more difficult in the real world, where your ITSM team might be an “inherited” mixed bag of great people – some brimming with potential but have yet to deliver on it, and maybe the odd one or two who think that they are paid to attend work rather than to actively embrace and participate in work.
So what can you do to make your ITSM team, and its members, work together better and reach their full potential?
1. Allow for Suggestions, Comments, and Complaints
How you encourage, react to, and deal with all feedback makes a big difference to team dynamics, team performance, team motivation, and your standing as the team leader.
Suggestion schemes, especially those that offer rewards for useful suggestions, are a good example. They are often set up to not only seek out the best ideas and improvement opportunities but also to help make team members feel more included in team and business decisions. And they can be great provided they have a transparent and fruitful “backend.”
So if a team member goes to the trouble of putting together a suggestion for how something could be improved, then the least they should expect is a reasoned response, and I don’t mean an auto-reply that the suggestion has been received. Even if the suggestion is completely hair-brained, feedback should be given as to what, if anything, will be done with the suggestion.
In terms of comments and complaints, if they are about how the team is being managed then you really do need to encourage openness and frankness. Regular one-on-one performance review sessions can be a great opportunity to go beyond the team member’s performance to ask questions such as:
- Is there anything making your work harder than it should be?
- Is there anything that I’m doing, or not doing, that you think I should change?
Such questions and how you respond (including how you act) can have a big impact on your relationship with the team member and the overall team dynamics.
2. Set Aside Time to Connect with Your Team
There’s a fair chance that as a team leader you are busy most of the time. And the issue with being the leader of an ITSM team is that it’s likely that the only time you “connect” with your team is when something is wrong.
If you dread seeing a team member at your office door or hovering at the end of your desk, then you are probably not making, and taking, the time to connect with them on the day-to-day things that make them tick. Unfortunately, you have created an environment where the only time you spend time together is when something has “hit the fan”.
This can cause you to feel resentment – because you associate the approach of team members with bad news – which your team may be able to detect, hence making things worse as they will want to approach you only as a last resort. So make time for the individual performance review sessions mentioned earlier, as it’s a great opportunity to learn more about team members and for them to learn about you. Plus, you can better understand what your team enjoys and dislikes about their work. Of course you can always have less formal conversations around the office as, and when, opportunities arise.
3. Make it Clear that Success Is a Team Game
Personality types dictate that you are likely to have (at least) one person in your ITSM team who thinks they’re the star player, and that everyone else is just there to pass the ball so they can score.
However, work is often best done by teams, groups, and collectives; and letting the “team superstar” take the limelight can be extremely damaging to other individuals and the team as a whole. Recognizing and rewarding those who snatch the spotlight can demean the efforts of those who work tirelessly in the background, harmoniously with other team members; this may dissuade these “hidden” stars from continuing on the right path in the future. If you are only seen to recognize and reward the star player, then you’ll most likely end up with a disengaged team. Or, even worse, multiple team members competing for superstar status – which is neither good for team dynamics or achieving team goals.
So make sure that everyone knows that, although each team member might have their individual areas of expertise, there is no one person responsible for the team’s successes, or failures for that matter.
It’s All About Communication
You might have noticed that these three tips all have one thing in common: communication. Open communication can help to build transparency within the team and to create feelings of value and trust between team members. It helps individuals to feel able to express their ideas and to voice their concerns – both of which are vital for a smooth-running and cohesive team.
You don’t want anyone sitting on an idea that could transform the way you do things for the better. Nor do you want festering issues that are likely to get worse in the long run and threaten team stability.
So there you have my three quick tips. What do you do to keep your ITSM team working together?
Are you going to the annual Service Desk and IT Support Show (SITS16) in London? It’s a free-to-attend IT service management (ITSM) and service desk event where not only do you get to see just about every ITSM tool vendor on the planet, and there’s a few, there’s also a wealth of great ITSM and service desk seminar content available to attendees. It’s not too late to register for the event, if you can get to London for the 8th or 9th of June.
I’m very pleased to be attending SITS again this year, it’s a great ITSM event, but the reality of attending has hit me – with so much quality seminar content to choose from, which sessions do you see and which do you sadly have insufficient time to make? At SysAid we call this “Sophie Danby’s choice,” that’s having to forgo quality presenters and topics due to the competing seminar streams. Unfortunately, it’s a common issue across the global ITSM event circuit that we never seem to be able to avoid.
So Who and What Should You Plan to See at SITS16?
If you are a regular visitor to the SysAid and Joe the IT Guyblogs, then you’ll know that I’m not going to spend my 1000 precious blogging words trying to brainwash you into visiting the SysAid stand at SITS (but you are of course more than welcome to come by to say hello, and our swag this year is seriously top-notch!). Instead, I’ll be talking about the seminar presenters and content that stand out for me.
If you know the ITSM industry, and the commonly-seen speakers, well then this blog might just be common sense for you. But, if you are looking for impartial help in selecting sessions at SITS, then please let me offer up a few, okay eight, suggestions based on my previous experiences at industry events.
1. Digital Transformation: How Will It Impact Service Desks?
Time: Wednesday, June 8, 9:30-10:10
Speaker: Andrew White
Andy White is an ITSM industry thoroughbred, so any opportunity to hear him speak needs a good excuse in order to miss it. In this session, Andy will present research findings from 50 CIOs about how their digital transformation journey is progressing and what this meant for IT operations. Andy will specifically talk about the conflicts and disagreement surrounding the CIOs’ strategies, the importance of digitizing core IT operations, not just front-end apps, and what digital transformation ultimately means for the IT service desk.
2. The New YOU – What an ITSM Professional Will Look Like in 2020
Time: Wednesday, June 8, 10:30-11:10
Speaker: Matthew Hooper
What do the next five years hold for ITSM professionals? Matt Hooper, a globally-renowned ITSM thinker and speaker, will tell you what he thinks in just 40 minutes (he might even let you ask questions). So attend Matt’s session to understand how DevOps, Shadow IT, cloud, and other disruptive movements are changing the IT landscape, such that corporate IT in 2020 will bear little resemblance to IT as we currently know it. Matt will also cover the critical skills gap developing and the opportunities this offers to ITSM professionals.
3. What’s Trending in the World of Service Desks?
Time: Wednesday, June 8, 12:30-1:10
Speaker: Ollie O’Donoghue
Ollie is the Service Desk Institute’s (SDI) resident industry analyst, who regularly undertakes the SDI’s member research and writes many of its white papers. In this session, Ollie will talk to the service desk and ITSM trends that SDI members are currently experiencing/expecting, based on the latest SDI research, and what service desk and ITSM professionals should be doing about them.
4. Life on the Service Desk in 2016 (and How to Improve It)
Time: Wednesday, June 8, 2:30-3:10
Speakers: Simon Johnson and Stephen Mann
At the end of 2015, the SDI conducted member-based research into the service desk “state of the nation”. In this session, Simon and Stephen will present the SDI survey results, outline the main causes of service desk concern and friction, and offer up practical ways to tackle the most-common obstacles and issues. This includes the key pain points for service desk analysts, their top frustrations with ITSM tools and vendors, and the top service desk priorities for 2016.
5. Intelligent Disobedience: The Future of Service Management?
Time: Wednesday, June 8, 3:30-4:10
Speaker: Ivor Macfarlane
Firstly, my apologies to my good friend Stuart Rance whose SIT16 session conflicts with Ivor’s – hopefully he knows that his session will be “standing room only” no matter what I blog about.
Here Ivor, an ITSM industry luminary, will talk about the need for “intelligent disobedience” on the service desk. How, as self-service and automation soak up the routine calls, the issues hitting the service desk are increasingly about exceptional conditions – meaning that service desk staff need more innovation and improvisation to deliver solutions and end-user satisfaction. Importantly, Ivor will explain that getting intelligent and committed staff isn’t the biggest challenge – that instead it’s getting managers to create an empowered environment in which service desk staff can flourish.
6. Time to Rethink Your ITSM
Time: Thursday, June 9, 10:30-11:10
Speaker: Patrick Bolger
It’s Patrick Bolger!
If I were braver I’d leave my session description as purely that. I’m not though, so let me tell you that, in this session, Patrick will outline the lessons that corporate IT and support can learn from modern consumer technologies. In particular, how these can be leveraged to provide the service experience that our customers really want, while reducing the demands on busy ITSM teams.
7. The Pros and Cons of Public and Private Cloud
Time: Thursday, June 9, 12:30-1:10
Speaker: Sarah Lahav
Hopefully you aren’t going to think less of me for including my boss’s session in this list :-).
In this session, Sarah will talk about how, even though cloud is now a well-accepted way to host and provision IT services, businesses still struggle with the decision between using public and private cloud. She will compare the pros and cons of each approach, referencing the five key cloud characteristics as laid down by National Institute of Standards and Technology, and using real-world examples to ease the decision making process.
8. Is Change Management Success as Simple as ABC?
Time: Thursday, June 9, 2:30-3:10
Speaker: Paul Wilkinson
If you have never seen Paul Wilkinson present, then you are in for a real treat at SITS16, as he is very animated and funny too!
Paul will tell us how and why 70% of organizations don’t get the hoped-for value from organizational change management, with more than 50% ironically failing because of resistance to change. With ABC (Attitude, Behaviour, Culture) being the number one success or fail factor for ITSM organizational change management, Paul will be offering practical advice for removing the points of resistance that commonly stop businesses from progressing.
So that’s eight SITS16 sessions I recommend. Enjoy the SITS seminars, vendor demos, peer networking, and swag opportunities. Hopefully we will also get to see you at our stand; feel free to pre-schedule a meeting. I promise not to try to sell you anything (unless of course you want me to).
Posted by Joe The IT Guy
on May 10, 2016 in Cloud
In Part 1
of this blog series, I covered what cloud native applications and microservices are – and left you dangling as to what containers are. I also mentioned “bees” but that’s irrelevant. Here, in Part 2, I explain:
- Hybrid and composite clouds
- Software-defined everything
What Are Containers?
The history of containers is almost as long as the history of virtual machines, although people seem to think containers are new. Nope - containers have been around for decades and, in a cloud context, they’ve been used by Google for nearly ten years already. The reason everyone is talking about them now is because they’ve been made easier to use by a company called Docker
. That reminds me, I need a new pair of chinos.
Containers can be thought of as light-weight, operating system-dependent virtual machines. They don’t have the isolation qualities of real virtual machines but they don’t have all the heaviness of virtual machines either, such as the longish boot times and the self-contained operating system.
Containers have mostly been available on Linux and they use operating system features to isolate resources for an application. So an application running inside a container thinks the world is as big as the container and has no idea that it’s “riding on the back of one of four elephants (physical servers), which are on the back of a large turtle (data center) swimming through space.” It’s all sounds very Yellow Submarine
Containers are loved by developers, since Docker solutions went mainstream, because they are easy to configure and lightning fast to use. When you’re a developer having to use multiple systems (test, staging, and production) and running multiple tests each day, then containers compare to virtual machines like a Ferrari Formula 1 car compares to a family estate – yes I’m showing my Italian roots here. Containers aren’t without their downsides though. Microservices aren’t easy to do and they are not always the right answer. In fact, Martin Fowler
recommends starting with a monolithic approach and refactoring an application if it emerges that a microservices approach might be better.
Also, at a technical level, it’s important to note that containers aren’t virtual machines. This means they don’t have the isolation features of virtual machines and so they are less secure. A virtual machine is like a house on a shared estate; a container is like a rented room in a shared house on a shared estate. Containers are stateless, which means that they are built brand new each time. When you turn them on, their configuration decides how the container is built, which includes connecting to services (which might be stateful). There are no persistent disks and the networking is “interesting” in that you can have hundreds or thousands of ephemeral containers popping up and down on your network.
What Are Hybrid and Composite Clouds?
In 2011 NIST defined the cloud using three perspectives:
- The service model (IaaS, PaaS, SaaS, and there are now more)
- The deployment model (public, private, hybrid, and there are now more)
- The five essential characteristics of cloud
The deployment model has generated much industry debate, with the general acceptance now being that this is actually a spectrum of possible models, ranging from “I only do on-premise private cloud” on one-side, all the way across to “I’m all-in on public cloud” on the other. Many people are, in reality, somewhere along the spectrum and still moving – using a combination of the two but generally moving in one direction or the other.
Hybrid, or composite, cloud has been a dominant theme by purveyors of private clouds (think both traditional non-cloud hardware and software vendors). Although recently, some public clouds (think new cloud service providers such as AWS and Microsoft Azure) have embraced the notion of hybrid cloud, but mostly from the perspective of them reaching into your data center to pull your applications and data into their public cloud.
Be warned though, hybrid cloud is the most difficult thing. Ever. It looks great on PowerPoint slides, Visio diagrams, and whiteboards but the reality is much blurrier, and implementation is very varied. Hybrid cloud can be expensive, complex, and difficult. And Gartner recently reported that 95% of private clouds are failing, with 31% blaming the failure to change in the operational model.
If you read vendor marketing you could be forgiven for thinking that you could buy a hybrid cloud with your credit card. You can’t – it’s a “solution” not a product, and it’s a complex solution at that. There’s no universally-agreed idea in the industry of what a hybrid cloud is, and if you look at the online cloud architectures from all the top vendors, you’ll find none of them agree on what a hybrid cloud architecture is. This is because they’ve molded the hybrid cloud solution to fit their product portfolio, rather than the other way around.
Finally, there are definitely situations that make sense to connect on-premise to public clouds if you want to leverage things like cloud storage for backup and archive. You can even connect the other way, from public cloud to on-premise to point cloud-based big data analytics at your on-premise datasets. And to do this, you really don’t have to have complicated hybrid cloud management software.
What Is Software-Defined Everything?
When Marc Andreessen said “Software is eating the world” he was talking about companies like Uber, Airbnb, and others that are using software with cloud, mobile, social, and analytics to disrupt traditional business models. This concept has been picked up by the traditional IT vendors who have moved from calling their products “cloud-ready” to now prefixing their existing products with “software-defined.”
You’ll see this in most IT sectors and in most cases, software-defined means the management or “control plane” has been decoupled from the “data plane” (think storage disk or network port). For example:
- Software-defined storage: Data is still stored on physical media such as flash, disk, and tape, so software-defined refers to the control plane, which was software-defined before but now it might have an API or, more likely, be more distributed or more converged depending on your perspective.
- Software-defined network: The network is still made up of ports and cables. But whereas previously the software was proprietary and ran on an application specific integrated chip (ASIC), the control plane now runs somewhere else, could be open source, probably runs on cheap servers instead of expensive routers, and uses an API.
- Software-defined datacenter: There are now software data centers inside physical datacenters. Think of a virtual datacenter that creates software virtual machines, networks, and storage (on top of real stuff, of course), probably via an API.
The real meaning of software-defined is when it applies to businesses and their processes and operations. And this is what Marc originally meant. It means that a business process, from order to cash, is written in software and uses APIs and cloud services. These companies that software-define their businesses are the ones that are really disrupting and winning markets.
So there you have it, five examples of cloud terminology hopefully demystified by yours truly. Is there anything else I should cover?
Posted by Joe The IT Guy
on May 3, 2016 in Cloud
The cloud is now ten years old, if you view Amazon Web Services (AWS) as kicking off the cloud industry with its inaugural EC2, S3, and SQS services
back in 2006. It’s an industry, and IT offering, which has been through the proverbial hype-cycle to become a mainstream IT solution that’s now used and accepted by enterprises of all sizes, and in all industries, around the world.
However, the general public’s understanding of cloud doesn’t tally with the maturity of the cloud. A recent US survey
revealed that half of Americans think that cloud computing is affected by the weather (and this was before Google data centers were hit by lightning
). In Australia, a quarter of active cloud users didn’t know they were using the cloud
. This is okay though as one of the benefits of cloud is hiding the complexity of the IT.
It’s not just the general public that struggles with cloud. New cloud providers and new cloud services have turned the cloud terminology dial up to eleven
(did you like my Spinal Tap reference?) to make the cloud look like an even more complex place – even for hardened IT professionals like me (Editor: who are you kidding, Joe?). To help, or at least to confirm people’s understanding, this two-part blog demystifies some of the latest cloud terms:
- Cloud native applications
- Hybrid and composite clouds
- Software-defined everything
What Are Cloud Native Applications?
Applications are a combination of programming languages, software architectures, supporting services, and let’s not forget the actual code and data. And there’s a best-practice approach to creating applications in the cloud, which is called “cloud native.” This best practice has reached a level of adoption and standing that it now has its own foundation called the Cloud Native Foundation
It brings to mind an old saying:
“If it looks like a duck, swims like a duck, and quacks like a duck, then it’s probably is a duck.”
So just as a duck has its nature, this best-practice thinking states that a cloud native application’s nature:
- Has a microservices architecture.
- Is made of containers.
- Runs on a cloud platform.
- Is reliable software on unreliable infrastructure.
- Is scalable on-demand.
- Is measurable.
The polar opposite of cloud native applications are 1980’s, monolithic mainframe applications or your 1990’s client-server applications. These could be migrated to the cloud as-is, but the chances of them working are unknown, whereas the missed opportunity of being able to exploit cloud features is known.
What Are Microservices?
Microservices is the name given to a specific software architecture style that is well-explained, and in detail, by Martin Fowler and James Lewis
. They describe microservices as an alternative to monolithic software architecture that is favored by cloud application developers because microservices work well with “the grain” of the cloud.
If monolithic software architecture applications can be imagined as one large, possibly enormous, program, then microservice-architecture software can be imagined as a swarm of single-purpose software components that work together. If this doesn’t help, and all you can now think of is bees, then Wikipedia
describes microservices as:
“…a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.”
Microservices are particularly suited to cloud native applications, and to cloud in general, because of the following:
- A swarm of components can make reliable software on top of unreliable cloud infrastructure.
- Single purpose components can be upgraded and replaced to enable practices such as continuous delivery, which has been proven to improve application quality and value.
- Components can be scaled in response to demand, independent of each other.
- Cloud platforms such as CloudFoundry are designed to make microservices easy by taking on the heavy-lifting of deploying and managing components and services.
- Components can emit metering data to provide rich, system-wide analytics.
Microservices are increasingly being implemented not by virtual machines but instead by containers, which I’ll come back to in Part 2
Well that’s it for Part 1, otherwise this blog would be 1800+ words long. In Part 2, I’ll return to cover: containers, hybrid and composite clouds, and software-defined everything.
Posted by Stuart Rance
on April 27, 2016 in ITIL
We all like to believe we are doing a good job. We all take pride in our achievements. But sometimes those of us who work in IT focus on the wrong things, particularly when the successful completion of technical tasks can be so satisfying that it takes on a life of its own. Clearly, we must be technically proficient. But it may be less obvious that technical proficiency is simply NOT enough. Unless we focus on creating value for our customers, whatever we do simply won’t be good enough.
Why Does It Matter?
One organization that I worked with had an IT configuration manager who was a real expert in his field. He deployed data collection tools to gather all the information that might be needed, and he carried out regular audits to make absolutely sure that the configuration data was complete and accurate. He was very proud of the quality and quantity of information that he maintained. When I asked him who used this information, and what they used it for, he confessed that he really didn’t know. He had never thought to identify who his customers were, or what information they actually needed to do their jobs. I talked to some of the other IT people in the organization and discovered that nobody used this configuration data at all, for anything. The time consuming and painstaking configuration management work had absolutely no value, to anyone!
In an oddly similar manner, relying on superficially straightforward and cost effective measures may prove misguided. One company had an air-conditioning unit that failed during the night. The computer room overheated, but because there was insufficient monitoring nobody noticed. Eventually the servers and storage got so hot that they failed, causing a lot of expensive damage. After all the equipment had been repaired the organization decided to prevent a repeat occurrence. They decided that the monitoring needed was too expensive, particularly as they could simply instruct the building’s overnight security guard to check the air-conditioning unit every hour throughout the night and sign in a book to show that this had been done. During a visit, I noticed that the unit had a red light displayed and I asked what this signified. The facilities manager explained that a resilient component had failed, that the replacement was on order, and the component would be replaced in a few days. That night I asked the security guard what he had done about the red light. “Nothing” was his reply. “Why not?” I asked him, and he replied “Nobody told me to check the lights.” The guard had diligently checked that the air-conditioning unit was still in the computer room once an hour, an activity that delivered no value.
How Can You Improve?
I’m sure we all think that these stories are extreme. This couldn’t possibly happen to us. But they do illustrate a really important point. We must make sure that the work we do contributes to a value chain. When we think about what we do, we should all ask ourselves “Who is my customer?”
and “What value am I creating for them?” If you can’t answer both of these questions then maybe it’s time to go and find out.
Even if you do know who your customer is, and what value they are getting from your work, there is a further step you can take. Find out how the things you do contribute value to the overall organization, and to the people who pay them. If you work in private industry then you should probably be creating financial value for your customers; if you work in the public sector, then the value you create may be a contribution to some social good.
I once had a very wise manager who said to me, “I want you to stop what you’re doing, at least once every day, and ask yourself ‘If the paying customers knew that their money was funding me to do this, what would they think?’ If you are not 100% confident that they would be happy, then stop doing that, and find something more useful to do.” Following this advice enabled me to focus my efforts on the things that create value for my customers, and was probably the biggest factor in helping me to become a service management expert. Moving from a technical focus to a value focus is difficult, but the payback can be enormous in terms of customer satisfaction, as well as your own career progression. I have been following this advice for more than 30 years now, and I heartily commend it to you as a way of ensuring you focus on creating real value for the people who fund your organization.
Posted by Roy Eldar
on April 19, 2016 in Service Desk
If you ask what a service desk is you might get any of these responses:
- IT operations or IT service management (ITSM) team: “The team we give the responsibility of dealing with IT issues.” And the more cynical among them might add “… but little in terms of knowledge or tools.”
- Business users: “The people who can help us with our IT issues … some of the time.”
- Development: “A worthless and unskilled part of IT.”
Okay the last one might be over-the-top cynical but the service desk can struggle to be valued outside of IT operations.
The Role of the Service Desk in DevOps
Thankfully, DevOps can help to change and improve this perspective by using the service desk as the pivot point between Dev, Ops, the business, and suppliers. DevOps is the cultural effort of getting Ops to see into the world of development and project teams, while also providing a mechanism for Dev and the project management office (PMO) to better understand the impact of change on production environments and, more importantly, on the customers.
So the service desk can be the lynchpin for how communication, collaboration, and the enhanced use of automation can enable technology to better support business processes and operations.
Think about what the business wants from IT:
- Better features or products, on a more timely basis
- Deployed in a secure, reliable, and cost effective manner
- Supported 24x7
So it is a lot more than just the delivery of new or improved technology.
Positioning the Service Desk in DevOps – the “First Way”
Referring to the book “The Phoenix Project,” by Gene Kim et al, the authors talk of DevOps enablement through three principles or ways
The First Way
ensures the flow
of technology (people, suppliers, processes, software, and infrastructure) to the business. In my opinion, many DevOps efforts fail because the concentration is on a flow from “idea” to “provided,” but successful DevOps needs to include a longer flow that includes support and review, in order to enhance future use.
The last thing corporate IT organizations want is a dissatisfied stakeholder or customer who looks elsewhere for technology services. But if companies do not consider the entire value stream, then a suitable analogy would be “The operation was a success, but it is a shame that the patient died.” So the service desk can help IT and the business to be prepared for whatever rate of change is going to occur.
The service desk knows what works and what doesn’t, the sort of issues most end users have, and how best to satisfy a customer. Their input early in the design phase can reduce or remove constraints related to non-development issues, such as having the right equipment available to use the new software, addressing licensing, or helping to train users. The flow is now from “idea” to “valued use” of a new feature, product, or service that retains and attracts customers.
Positioning the Service Desk in DevOps – the “Second Way”
The Phoenix Project’s Second Way
and this is where the service desk can excel – as most of the work performed by the service desk results in feedback:
- Gathering information on technology performance and use
- Knowing how customers or end users react to changes
- Contributing to 2nd or 3rd level support requirements
- Capturing customer or end-user requirements or wishes
- Understanding how technology is used on a daily basis
- Acting as the “single point of contact” for training or the creation and maintenance of knowledge artifacts, which can lead to better self-service
- Collating customer complaints
- Using the service desks’ tools and experience to record and track issues across the development to deployment lifecycle
- Facilitating escalations internally or to suppliers
All of this and more can help IT react to issues and, more importantly, to proactively assess whether a new feature or product is worth the effort and cost.
Positioning the Service Desk in DevOps – the “Third Way”
The Third Way
is continuous improvement
, which means that we learn from our efforts and try something new. This step is not a report with actions that no one ever addresses, but is performed daily by all members of IT. Imagine if from the beginning of the “idea” to “go-live” lifecycle, the service desk:
- Captured all issues
- Began to learn how to resolve them
- Ensured that integration, end user, or production-ready tests confirmed that the issue was resolved, or at least that self-healing scripts worked
- Noted when issues came back and escalated correctly
- Assisted with the automation of processes
- Trained users
Letting the service desk learn, create, and improve their capabilities will let the people, who are first to serve, be fully able to perform that function and, where necessary, gather feedback for improvement of the product.
Ultimately, the service desk is not just the “face of IT” – it is also its eyes, ears, and mouth. Everyone in the organization, even IT, uses it to help solve issues or request equipment or software. The service desk therefore knows the “truth” about IT – the good and the bad, from features and products to customers and suppliers – and can add value by sharing this information early in the design lifecycle.
So DevOps and the service desk should be a perfect fit. How is your organization’s DevOps activities involving and exploiting service desk capabilities?
Posted by Sarah Lahav
on April 12, 2016 in Service Desk
Today’s tech-savvy customers are taking their consumer-world IT issues into their own hands, with customers now looking online for answers in preference to calling or emailing the supplier to help them to fix the issue. Welcome to the era of the self-service-empowered customer!
And self-service adoption continues to grow. Forrester Research
has stated that self-service usage has increased from 67% in 2012 to 76% in 2014; and, according to a 2011 Gartner prediction
, by 2020 the customer will manage 85% of the relationship with an enterprise without interacting with a human. It was a bold prediction and we might not fully make it but we probably won’t be too far off as consumer-world self-service continues to gain traction.
But how is employee self-service being encouraged within organizations, especially IT self-service?
Supporting Employee Self-Service
With the rise of the empowered self-service customer outside the organization, logic and common sense says that these customers will expect similar self-service capabilities when they are at work, i.e. as employees or end users.
So how can you build a self-service ecosystem that keeps your end users satisfied?
1. Construct a Knowledge Hub
Get, and keep, your end users using self-service by building a “hub” or knowledge base to house your knowledge – with knowledge articles that allow end users to answer their own IT-related questions.
End users are keener than ever to solve their own issues rather than relying on customer service in their personal lives, so IT organizations can leverage this consumer-world success to give end users “what they want” while potentially saving support costs, increasing support efficiency, and hopefully offering a better customer experience.
This knowledge base will be the Google for end-user IT support issues – deflecting tickets away from the service desk and alleviating support agents from simple, yet time-consuming, tasks such as password reset, such that they can concentrate on higher priority IT issues and requests.
However, it’s crucial that the knowledge base is optimized for a great customer experience. Ensure your knowledge base is user-friendly, accessible, and intuitive to your end users. It should be accessible from most devices, especially mobile. Keep in mind that in the modern workplace end users will move rooms and even locations during the working day and week, and change their preferred contact channel depending on where they are and what they’re doing.
You can find out more about how to get knowledge management right in your organization via this webinar and white paper
by Aprill Allen
2. Keep It Simple
Locating and digesting support information should be easy for end users.
Have you ever tried to shop in a new supermarket where you really need a map to navigate through it? Nothing is where you think it should be. It’s annoying to say the least, when all you want to do is to find and then buy some milk.
Your knowledge content should be simple to navigate. Try mapping out a basic end-user (customer) journey to help you with this process. After initially accessing your knowledge base, the end user will search for their issue, view the resources, read the article or articles, and then resolve their issue.
At any one of these “touch points” you could lose the end user, who will at best call the service desk or at worst will just carry on trying to work around their IT issue . The article they need must never be more than a few clicks away. Ensure that you don’t over complicate the journey as, according to the Harvard Business Review
, after 2-3 consumer-world self-service attempt failures, customers will not try again. There’s no reason why this should be any different for employee self-service, so get a team member to test it out. If they can’t find what they’re searching for quickly, your end users certainty won’t.
As for the knowledge articles, they should be easy to read. Sweep out the “clutter” to ensure that the content is clear and precise, guiding the end user through their issue, step-by-step. Also avoid jargon and overly technical terms – you might understand what the articles mean but end users might not.
3. Continually Refurbish and Renovate
A knowledge base requires ongoing maintenance and development to continue to attract and retain end-user patronage.
It’s important to collect end-user feedback to understand how you can continue to improve your self-service support and to better meet their needs. And the collection isn’t enough – make sure that you act on the feedback.
Allow end users to rate and review the knowledge articles you provide. A simple rating button should be capable of flagging up content that might need simplifying or reworking. The kind of question you should be asking is: “Was this answer / article / information helpful?”
Also, ensure that a review process is in place to check that all content is still current and relevant. Document all the resources held in your knowledge base and periodically evaluate the content to see if any solutions or FAQ answers needs updating. End users won’t appreciate wasting time on outdated information – it’s a surefire way to lose their trust in, and patronage of, the self-service platform.
Don’t be scared of self-service. Remember that end users are familiar with “help yourself” systems in their personal lives. After all, self-service has infiltrated every part of our daily lives, from cash machines to supermarket checkouts, from online appointment booking to airport self-check-in kiosks, and pay-at-the-pump gas stations. The important thing is to get it right by making it easier than using other IT support access and communication channels.
You can find out more about how to succeed with self-service via this webinar and whitepaper
by Stuart Rance
and Stephen Mann
Posted by Dena Wieder-Freiden
on April 5, 2016 in ITSM
is done and dusted, and it’s already time for the second of the year’s IT service management (ITSM) industry’s “grand slam” events – HDI
. Alas, I’ll be missing out on this one too, but it doesn’t stop me from dreaming about who I’d like to hear speak if I were there.
My far-more-famous colleague Joe the IT Guy
will be at HDI 2016, and no doubt he will be using my session suggestions for his post-HDI blog – some guys definitely have all the luck
HDI is a Special ITSM Event
I really like the HDI event, as in line with its previous name – the Help Desk Institute – there’s often a lot of practical content that service desk staff, in particular, can use as soon as they are back in the office.
There’s also a heavy emphasis on customer service
, not just IT support. Thus, some of the HDI content can be ahead of the curve when it comes to the changing dynamics of corporate IT support and the growing expectations of end users (although HDI would deliberately call them customers!)
You’ll see what I mean from my suggestions below, it’s pretty much about all hands-on stuff…
So What Do I Recommend?
Maybe this should be more like “So who do I recommend?” as I’m a firm believer that while it’s good to attend the sessions of people that you know nothing about – in that you might learn something new – it’s also good to have “dependable” sessions where you know the presenter will deliver.
So when you sit down to create your HDI agenda, I strongly recommend that you consider the following sessions and presenters…
Session 107: If Metrics Are the Answer, What Are the Questions? With Roy Atkinson, HDI
Wednesday, April 13, Time:
: Metrics & Measurements
It’s Roy Atkinson, THE Roy Atkinson, need I say more? Well, I suppose I’d better, just in case you have no idea who Roy is.
Metrics are a constant source of heartache and frustration for many IT professionals, service desks, and IT organizations as a whole. In my opinion, there often seems to be a disconnect between the adoption of so-called best practice metrics and the business goals that they should ideally be distilled from.
So spend an hour with Roy to understand how service desk metrics need to be modernized, to be transformed into measurements that are more reflective of business goals and objectives.
If you can’t make this session, or even if you can, look out for two other Roy sessions:
- Session 402: Customer Service Excellence: Consistency Is the New Black
- Session 705: Desktop Support: Increased Demand, Changing Role
And if you are lucky, Roy will do a little singing too!
Session 206: Cultivating a Culture of Quality with Rae Ann Bruno, Business Solutions Training Inc.
Wednesday, April 13, Time:
: Support Center Optimization
As with Roy, in my opinion Rae Ann should be one of the first people on your HDI dance card. I’m led to believe that Rae Ann is always a high scorer in the HDI session feedback stakes and I can believe it – after all, I had the pleasure of seeing it for myself when I attended a few of her sessions at FUSION15
Rae Ann often talks to the people-side of IT support and customer service. Here, she will address one of the most common service desk people issues – that too often, quality monitoring and coaching is put on the back burner due to a lack of time, employee resistance, or other reasons.
Rae Ann will explain how it takes a balance of quantitative and qualitative metrics, and a quality program that continually evolves, to deliver: improved service, engaged employees, and happier customers.
You can also catch Rae Ann for her second session – Session 405: Creating a Proactive Desktop Model: Breaking Out of the Reactive Grind.
Session 404: Is the Traditional IT Department on Its Way Out? With David Cannon, Forrester
Thursday, April 14, Time:
: Service Management Excellence
What is there left to say about David Cannon? He’s a veteran of the ITSM industry (having worked at both HP and BMC, but Sophie Danby
tells me not to hold that against him, is a revered ITIL author, and is now in a strategic role at industry analyst firm Forrester.
David will look at how the changing IT and business landscapes are transforming corporate IT organizations, answering questions such as:
- If the traditional IT department is on its way out, what could possibly replace it?
- If the traditional IT department does disappear, how can we prepare for what’s next?
No doubt, David will be predicting what could happen in the next ten years and identifying what IT professionals can do to help prepare for these eventualities. And as David now works for Forrester, I imagine he will come armed with a lot of insightful research and statistics.
Session 603: Effective Tomorrow, the Service Desk Will No Longer Take Calls with Doug Tedder, Tedder Consulting LLC
Thursday, April 14, Time:
: Executive View
Doug is a SysAid favorite, in fact he is many people’s favorite, so how could I not pick the font of all ITSM knowledge that is the amazing Mr. Tedder.
In his session, Doug will take a deep dive into understanding the true value of a good service desk, and explain some of the positive outcomes that could happen if your organization decides that the service desk will no longer accept calls. This might not be as far-fetched as you think. Doug will talk to the potential resulting opportunities, the value of the service desk beyond being the single point of contact, and what should be done now to enable this future service desk.
Session 802: Two Key Differences When Managing the IT Customer Experience with Ian Clayton, Service Management 101
Friday, April 15, Time:
: The Customer Experience
Another SysAid favorite, and the grand master of all things customer experience and “outside-in.” In fact, I can’t think of anyone else that I’d rather listen to talk about customer experience in the context of IT service delivery and support.
The easiest way to sell Ian’s session is to steal his HDI blurb – it sells itself:
“A service business is only as strong as the relationship it forges with its customers. At the heart of any service relationship is customer satisfaction, which, if achieved, can lead to loyalty and advocacy. As IT is being required to change its operating model and internal culture to better suit the needs of a contemporary enterprise, lessons can be learned from the secrets of the retail customer support model.”
And here’s a cheeky plug for Ian’s latest blog on continual service improvement (CSI)
Finally, Joe the IT Guy and more of my SysAid colleagues will be in the Expo Hall, so please stop by to say hello and grab some quality swag. Feel free to pre-schedule a meeting
at your convenience. They definitely won’t try to sell you anything unless you want them to – they just love to talk ITSM.
If you would like to follow HDI 2016, in real-time on Twitter, then the hashtag is #HDIConf, not #HDI16 or #HDI2016. I know I’ll be following it.