I find attending conferences and events extremely useful. There is a wealth of experience and knowledge in the shape of industry experts, vendors and people like you and me who have already gone through those pain points we are currently dealing with. All we have to do is listen, take notes and grab handouts.
Useful as conferences are I, like many of you, do not always have the ability to take a day or more out of my working life to attend and as for getting money from the boss to travel to, attend and in some cases stay over at events, well lets just say I’m getting lots of practice at writing business cases with persuasive arguments.
To save you some energy for that impressive and compelling business case here is my list of the events, conferences and experiences for the first half of 2015 that are worth your time and (your bosses) money*.
The first of a new series of Knowledge Exchange seminars sees itSMF UK looking at Service Management today and how industry experts and leaders are dealing with the current big challenges we’re facing and promises to help us prepare for the intense changes ITSM is currently undergoing.
Despite being a trade event SITS has a fantastic amount of useful info you can take away with no less than 36 seminars being held over the two days from the likes of the fabulous Andie Kis who should have a conference all to herself and everyone’s favourite Texan Daniel Breston.
What’s more if you book before Tuesday 2nd June entry is free!
If you are a public sector service desk then this one is for you. SDI events are always well thought out with the mixture of presentations, case studies and interactive activities making for an enjoyable, engaging and worthwhile experience.
At £185 (+VAT) these days are fantastic value for money and are particularly good at focusing on a particular subject or issue.
If these all sound great but you just don’t have the time then there is an alternative…
Every 2 months Conference in a Box send out a package covering a different subject with Metrics, Social IT, Best Practice, Gamification and Kanban being covered so far. In your box you’ll find a collection of learning materials, access to the speakers online and some goodies to ensure you don’t miss out on one of the best bits of trawling the exhibition floor.
Conference boxes are between £29.99 and £59.99 and have the added bonus of you being able to attend in your pajamas!
*All conferences/events etc above have been attended/test driven by either myself or a team member. If you run or know of a conference that you think would be beneficial to the ITSM community please let us know via this link
Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Rae Ann Bruno’spresentation along with some of the key pieces of advice that she presented.
Believe it or not this presentation focused on the well-known chef, Gordon Ramsey. “What on earth can Gordon Ramsey teach us about ITSM?” I hear you all cry! Well as it turns out… a lot. Rae Ann focused on the programme “Ramsey’s Kitchen Nightmares” where Gordon Ramsey takes failing restaurants and turns them into successful ones and how his recipe for success (sorry I couldn’t resist) is the perfect model for IT services.
The Gordon Ramsey approach
The approach that Gordon Ramsey takes in this programme is as follows:
He goes to the restaurants and puts himself through the customer experience (he orders and eats like any other paying customer)
He speaks with other customers, the staff, the owners and the chef to understand different perceptions (helping him to understand the full impact of the problem, gathering data from all sources)
He looks at: process time, wait time, defect rates, root causes and other information that can lead to targeted improvements
He defines the quality required to staff and the chef (trust me, it’s not frozen lasagna)
He gets the team onboard with his plan and remodels the restaurant
He helps bring the team together to communicate better and provide more effective service
Where does ITSM fit in?
Rae Ann explained how this exact approach should be taken for continual service improvement when it comes to ITSM:
Understands customer expectations
Assesses process, people and tools
Ensures adherence to policy and procedures
Manages relationships between teams, people and processes
Verifies communication process
As bizarre as the concept sounded at the start of the presentation, she was right. If you are struggling with your processes or your service then perhaps the first thing you should do is sit down and watch an episode of Gordon Ramsey in action.
The need for service catalog
Rae Ann also continued with her restaurant examples to explain why every organization needs a service catalog. To quote her exactly: “An organization without a service catalog is like a restaurant without a menu”. What would happen in a restaurant if there was no menu? If customers could come in and simply order whatever they fancied?
There would be an inordinate about of waste (because the kitchen would have to be stocked with every ingredient possible, some of which may never actually be required)
The restaurant wouldn’t be able to set any expectations to customers
Assumptions would be made by customers that the chef knows how to cook anything and everything
It would fail. There is no way this model can succeed
The same is equally true of not having a service catalog.
Rae Ann’s presentation was highly entertaining and laden with lots of other common sense advice such as:
Always set customer expectations and ensure that you can deliver a service to match them
Be realistic and honest with your customers and yourself. Don’t try to make things look better than they are
Always follow the continual service model
Ensure that you understand business goals and that your efforts are aligned with them. How can you do your job effectively if you don’t know what you’re working towards?
Sufficient and effective communication is critical to success, far more important than your tool and processes
CSI is not a process. It is never finished, you cannot complete it
All in all, it was an incredibly practical and sensible session. The only downside to this presentation is that I will probably never be able to watch Kitchen Nightmare’s again without thinking about IT service management.
Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Susan Reisinger’s presentation along with some of the key pieces of advice that she presented.
This was an interesting session, not least because it focused on such a huge organization (the US Navy) that operates globally. I would perhaps say that the session focused a little too much on the “what was done” and not enough on the “how you can do this / fit this to your business”, but nevertheless it was a very educating session.
Susan explained how Navy 311 is not a new program, but a new approach to service and support. The US Navy’s IT operations had been complex, with multiple service desks spread across numerous countries with limited communication between them. They needed both an efficient and cost effective way to fix this problem with no available budget (this is the government that we’re talking about here). This was where the 311 model came in.
What is Navy 311?
The 311 model was adopted by the US Navy for all non-emergency services, from a captain on a ship who had a minor problem to a member of the public enquiring whether the ship they had just seen in a port belonged to the Navy or not (hey they were just wondering!). However, Navy 311 comprises of more than just call center support, it has four key capabilities:
Customer interface – ensuring consistency of support from initial service request through to issue resolution
Shore-based infrastructure – a network of authorized service providers and call center professionals as well as the IT assets that support them. Previously if there had been a fault on a ship a technician would have had to have been shipped out to fix it. Now technicians can advise via telephone and people on board can carry out what needs to be done to fix the issue. One technician can now be working on several issues at once, versus previously where they would have had to travel and only been able to deal with one issue/ship at a time. The result? Quicker resolutions and a huge saving on travel expenses
Knowledge management – a repository of all records to enable data mining to identify trends and thereby enable process improvements and total cost ownership (TCO) reduction analysis
Program management – business management functions such as information and systems assurance, program execution and financial accountability. All of which provides transparency to the business.
Susan explained that adopting the 311 approach can work for any organization regardless of size. The key improvements delivered to sailors and the leadership in the US Navy were:
Reactive service delivery
Proactive service delivery
Call center optimization
The presentation with a story
As previously stated it would have been nice to hear more of the “how you can do this” and perhaps a clearer explanation of what the 311 program (adopted by over 400 cities across the globe) is would have been good too. That said, Susan wins the prize for telling my favourite story of the entire conference:
Shortly after the 311 program had been rolled out, when the Iraq war was at its peak, one US Navy call center received a call from a man who was clearly distraught. The man explained that he had heard that the ship his son was deployed on had been struck and that there were numerous injuries and fatalities. He wanted to know if the next of kin had been alerted as he was desperate for news of his son.
The agent explained that she didn’t have the information to hand but she would find out and get back to him as soon as possible. Pre-Navy 311 it might have taken the agent hours, maybe even days, to be able to source the necessary information to get back to that man quickly. However, thanks to the fact that they now operated as a global, multi-functional team with strong communication and transparent operations, that agent was able to quickly reach the closest unit to the attack.
The result? Within 45 minutes of the man contacting the US Navy call center he had a call back from the agent and an email from his son confirming he was safe and well.
Susan finishing on this story, left me in no doubt about the wider impact that IT service can have not just on the business itself, but on external businesses and individuals as well.
Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Andrea Kis’ presentation on “The Beauty & Simplicity Of Common Sense Business Relationship Management”, along with some of the key pieces of advice that she presented.
This was a great presentation because it didn’t matter what part of IT you worked in, or even if you didn’t work in IT at all, the message was still applicable to you (even in our personal lives). Andrea explained the importance and benefits of creating a relationship with everyone that you meet. She also discussed how we MUST stop referring to IT and the business as two separate entities.
Advice from Andrea
Key takeaways and advice from her session included:
Don’t refer to BRM as a process or a job title. It’s neither, it’s a skill
Don’t underestimate how something very small can lead to a much larger problem. One small relationship issue between two colleagues can easily cause much larger issues for your overall service delivery
You can’t implement BRM, it’s something you must practice every day
The focus must always be on the relationship from the viewpoint of the customer. Just because you think the relationship is working smoothly doesn’t necessarily mean that they feel the same
The little things matter. When delivering hard decisions if you have a relationship with the person you are delivering said decisions to it will be easier. They will trust you
Always lead by example
The advice didn’t stop there though, and we will shortly be publishing an article on BRM direct from Andrea herself.
Other points of interest
What I found particularly interesting in this session was that nobody in the room seemed to be aware that BRM was in ITIL v2011. This confirmed my belief that we place too much emphasis on what we have always done (incident and change) and too little on new ideas.
Andrea finished off her session by naming the six competencies of relationship building. How many do you follow?
Establish teams and collaboration
As a piece of bonus advice for anyone reading this, I asked Andrea “if you could only provide one tip when it comes to BRM what would it be?”. Her response was “JUST DO IT. Stop questioning where to start and just do it”.
Think you’re good at relationship management? Did you stop for coffee on the way to work this morning? If so, do you remember what the person who served you your coffee looked like?
Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Gene Kim’s presentation “The Phoenix Project: Lessons Learned in Helping Our Businesses Win”, along with some of the key pieces of advice that he presented.
Gene kicked off the first full day of the conference with his keynote presentation about IT and DevOps. If you’re not familiar with his book then I’ll start by highly recommending that you head over to Amazon to purchase a copy. If my recommendation alone isn’t enough to entice you to part with your hard earned cash, then read this article by Gene first.
Gene’s article provides a good summary of his session (along with some great tips), but the bottom line of the presentation was that (and to quote Gene) “IT is in a downward spiral, it’s trapped in a horror movie that keeps playing over and over again” and DevOps is a way to help try fix this.
Advice from Gene
Some of the advice that was provided during his session included:
Never forget that the best will always get better. Back in 1979 who’d have thought that anything could surpass the amazing Sony Walkman?
In order to win in business we need to out experiment our competitors.
Be fearless in breaking things. Mistakes and errors are a key source of learning
When it comes to DevOps and metrics, measuring lead time (i.e. the time it takes to go from the “raw materials” to “finished goods” is a much more effective metric than measuring deploys per day
When creating a DevOps process it’s important to ensure that you include a “handback” stage. This way, if necessary, fragile services can be returned back to development if operations don’t think that they are up to scratch
Develop smaller changes frequently to avoid painful large scale deployments in the future
Other things we learnt in this session that you might not know:
A survey of the room showed that it took most months, and even quarters, to deploy a change request. Did you know that an effectiveDevOps team can deploy a change request in days, and even hours?
Overall a thought-provoking presentation, and one that I very much enjoyed. Not being a total ‘techie’ I confess to never really, fully understanding the concept of DevOps before. Now thanks to Gene, I think I might even be able to confidently explain the benefits to others.
Last week I had a last minute opportunity to attend the itSMF Norway conference in Oslo, and I have to say the stress of booking a flight, packing a bag and leaving my house within the space of an hour was completely 100% worth it. This was easily one of the best ITSM events that I’ve ever attended, both in terms of quality of content and overall experience, and one that I would highly recommend to others.
It’s also worth noting that I say this without really experiencing the entire event, as there was many sessions in Norwegian that I couldn’t attend (my Norwegian is a little rusty you see) all of which received great praise from the more local attendees. I was particularly sad that I couldn’t attend the session by Henrik Aase as it was literally all anybody was talking about throughout day one. However, the good news is that we are going to work with itSMF Norway to get some of the Norwegian sessions written in English as ITSM Review articles.
I couldn’t pass up on the opportunity to share some of the key takeaways, advice and tips coming out from the event, and so I hereby present to you my summary of some of the sessions that I attended along with general thoughts about the conference.
The conference key messages
Bearing in mind that I didn’t attend all of the sessions (my takeaways may differ to other attendees. However, from the sessions that I attended and my conversations with other delegates I found three key reoccurring messages:
We can’t keep ignoring DevOps. The benefits are too great to miss out on
Be honest in everything that we do, both with ourselves and with our customers
We must work on continual service improvement to maintain success
Interestingly, ITIL barely came up in any of the presentations that I attended, nor was I party to any conversations (bar a quick catch up with AXELOS) discussing ITIL. I know it was discussed during the “future of IT service management” panel at the end of day two, but by that time I’d left for the airport and so I only picked it up on Twitter. I found this particularly refreshing, I can’t remember the last time I didn’t get stuck in a conversation going round and round in circles on the topic of ITIL. In fact, I heard ‘COBIT’ mentioned more often than ‘ITIL’. Perhaps this says something about Norway’s adoption of the best practice framework (but I guess not given that the conference tagline was “ITIL – tell me more, tell me more”), or perhaps I just don’t understand ITIL in Norwegian (although I still question that I understand it in English).
However, a topic that did come up on a number of occasions was one that I’d not personally heard being discussed in a long time. Project and portfolio management (PPM) seemed to be a key focus for many of the delegates that I spoke with, with their primary reason being that it helps them make faster and better business decisions. Again, this could speak more about the country than a new trend, but when I spoke with some of the international delegates they seemed to be in agreement of its new found importance.
To avoid this particular article becoming incredibly long, over the course of this week I will publish supplementary articles of the key takeaways and advice from the following sessions:
Tuesday:Gene Kim, Independent Director – The Phoenix Project: Lessons Learned in Helping Our Businesses Win
Wednesday:Andrea Kis, TCS – The beauty & simplicity of common sense business relationship management (BRM)
We have also invited speakers to write articles based on their presentations, which we hope to publish over the coming weeks.
The conference itself
I could easily write paragraph after paragraph about just how good the itSMF Norway conference was, but for everyone’s sake I will try and summarize my thoughts in bullet points:
The content overall (granted I can’t really speak for the Norwegian sessions, but talk amongst the delegates leads me to believe that my assessment is fair) was far superior to anything that I have seen at any other ITSM event
The atmosphere was much nicer than at any other event I have ever attended. It was relaxed, laid back and fun – there were no stressed out organizers either, they enjoyed every second of the conference just as much as any other delegate
The theme was brilliant (although I don’t know how many more days I can take of continuously having “Summer Nights” stuck in my head) and was consistent throughout the event, from the sessions to the entertainment to the roaming hotdog vendors dressed in full 50s attire.
The organizers were wonderful, in control and most importantly – happy! P.S. Thanks for extending the services of your 50s hair and make up artist to me!
The food was yummy (this is huge praise from me, I never touch the food at conferences) – many will tell me this is irrelevant, but it’s all part of the event experience as far as I am concerned
The entertainment was fantastic (although there were a few groans from some who could understand the Norwegian “dinner entertainer” – i.e. not me – that he wasn’t on par with the standard of previous years). Who knew that dancing to Grease tunes with Tobias Nyberg, Kaimar Karu, Dagfinn Krog, Andrea Kis, Rae Ann Bruno and a bunch of Norwegian people that I don’t know could be so much fun?
My only criticism of the event, which I (and others) have already shared with the organizers, and I am already 100% confident will be fixed for next year, was that for those of us who couldn’t understand Norwegian there were often long periods of time when we were left with no English content (two hours and 15 minutes each day to be exact). Whilst, I wouldn’t expect a Norwegian conference to be delivered 100% in English, as itSMF Norway has become a victim of it’s own success with more international attendees each year (I met with delegates from Finland, UK, USA, Italy, and Germany just to name a few), it would be nice to find a way to ensure that we could still benefit from the Norwegian sessions.
This conference easily has the scope to become one of the biggest itSMF events in Europe. It’s inexpensive to attend compared to other ITSM events (even with flights from long haul destinations) and the quality is of an exceptional standard. To be honest, even with the gaps for non-native speakers I will still be recommending this conference to everyone that I speak to.
If you want to learn, pick up practical advice, meet amazing people, and all whilst having a huge amount of fun then make sure you get your tickets booked to next year’s itSMF Norway conference. I know for a fact there is no way that I intend to miss it.
In my thirteen year journey of studying high performing IT organizations, I’ve started to see a new and unsettling trend. Whenever I mention ITIL and IT Service Management in presentations and briefings, people in the audience snicker. When I ask why, they roll their eyes, and talk about the shrill, hysterical bureaucrats that suck life out of everyone they touch, doing everything they can to slow the business down, preventing everyone from getting work done.
This is simply not true. In fact, every time I’ll argue that ITSM skill sets are ever more important in a world where there is an ever quickening business tempo.
However, an even more troubling trend is that ITSM practitioners will dismiss emerging movements such as “DevOps,” suggesting that it’s a passing fad.
It is my genuine belief that that patterns and processes that emerge from DevOps are the inevitable outcome of applying Lean principles to the IT value stream. It is an inexorable force that will likely change IT in a manner we haven’t seen since the birth of client-server computing in the 1980s.
More importantly though, ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business.
The DevOps Movement fits perfectly with ITSM. My goal is to help you become conversant with DevOps and aid you in recognizing the practices when you see them. I hope this article will illustrate how information practitioners can contribute to this exciting organizational journey.
What Is DevOps?
The term “DevOps” typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e. high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.
Why is it that Development and IT Operations are singled out? Because that is typically the value stream that is between the business (where requirements are defined) and the customer (where value is delivered).
The origins of the DevOps movement is commonly placed around 2009, as the convergence of numerous adjacent and mutually reinforcing movements, most notably the “10 Deploys A Day” presentation given by John Allspaw and Paul Hammond and the Agile system administration movement (Patrick DeBois).
Currently, DevOps is more like a philosophical movement, and does not yet have a precise collection of practices, descriptive or prescriptive (e.g. CMM-I, ITIL, etc.). On the other hand, it is an incredibly vibrant community of practitioners who are interested in replicating the performance outcomes and culture described so vividly by organizations such as Etsy, Amazon, Netflix, Joyent and so forth.
DevOps aims to address a core, chronic conflict that exists in almost every IT organization. It is so powerful that it practically pre-ordains horrible outcomes, if not abject failure. The problem? The VP of Development is typically measured by feature time to market, which motivates as many changes, as quickly as possible. On the other hand, the VP of IT Operations is typically measured by uptime and availability.
Until very recently, it was impossible to get both desired outcomes of fast time to market and sufficient reliability and stability. Because of these diametrically opposed outcomes (“make changes quickly” vs. “make changes very carefully”), Development and IT Operations were in a state of constant inter-tribal warfare, with ITSM practitioners put right in the middle.
Although many people view DevOps as backlash to ITIL (IT Infrastructure Library) or ITSM, I take a different view. ITIL and ITSM still are best codifications of the business processes that underpin IT Operations, and actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream.
I am part of a team who wrote “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”, which codifies the “good to great” transformation we’ve observed these organizations making. Our goal is to create a prescriptive guide that shows how Development, IT Operations and ITSM practitioners can work together to create phenomenal organizational outcomes that none of them could achieve alone.
What are the unpinning principles of DevOps?
In “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” we describe the underpinning principles in which all the DevOps patterns can be derived from as “The Three Ways.” They describe the values and philosophies that frame the processes, procedures, practices, as well as the prescriptive steps.
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
The focus is on all business value streams that are enabled by IT. In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service.
The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming).
The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.
The Third Way is about creating a culture that fosters at two things: continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery.
We need both of these equally. Experimentation and risk taking are what ensure that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone. And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far.
The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.
What Are The Areas Of DevOps?
We divide up the DevOps patterns into four areas:
Area 1: Extend Development into IT Operations:
In this area, we create or extend the continuous integration and release processes from Development into IT Operations, integrating QA and infosec into the work stream, ensuring production readiness of the code and environment, and so forth. The steps include:
Create the single “repository of truth” containing both the code and environments
Create the one-step Dev, Test and Production environment build process
Extend the deployment pipeline processes into production
Define roles and integrate QA, Infosec, Ops/CAB into Dev workstream
First, we put everything needed to rebuild the service into a common repository from scratch, including both the application and the environment (i.e., operating system, databases, virtualization, and all associated configuration settings).
Next, we will make a one-step environment creation process available at the earliest stages of the Development project. By using a common build process and requiring that Development be responsible for ensuring that the code and the environment work together, we’ll have an unprecedented level of production ready, even at the earliest stages of the development project.
This impacts the ITSM process areas of release, change, and configuration management. The ways that ITSM practitioners can actively integrate into the DevOps value stream includes the following:
Find the automated infrastructure project (e.g., puppet, chef) that provisions servers for deployment. We can help that team with our release management readiness checklists, security hardening checklists and so forth, integrating them into the automated build process.
Define pre-authorized changes and deployments, and ensure that production promotions are captured in a trusted system of record that can be reviewed and audited.
Define changes and deployments that require authorization, such as security functionality that is relied upon to secure systems and data (e.g., user authentication modules). The goal is to ensure that changes that could jeopardize the organization (e.g., the infamous 2011 Dropbox failure where customers discovered that authentication was disabled for four hours) never occur.
Area 2: Create IT Operations feedback into Development
The steps in this area ensure that information from IT Operations is radiated to Development and the rest of the organization. IT Operations is where value is created, and this feedback is required in order to make good decisions.
The specific steps in this area include:
Make all infrastructure data visible
Make all application data visible
Modify the incident resolution process and blameless post-mortems
Monitor the health of the deployment pipelines
The first step overlaps with the ITSM process areas of event management, while the second step requires creating the monitoring infrastructure so that there’s no excuse for developers not to add telemetry to their application (e.g., “since it only requires one line of code, even the laziest developer will instrument their code”).
The third step then enables IT Operations and Development to resolve incidents quickly, by ensuring that all relevant information from the entire application stack is at hand to determine what might have caused the incident, and then to restore service.
ITSM practitioners can help by ensuring that the process areas of event management, as well as incident, problem and knowledge management are modified to incorporate Development.
Area 3: Embed Development into IT Operations
According to the Second Way, the goal of steps in this area is to create knowledge and capabilities where we it is needed, and shorten and amplify feedback loops. A delightful quote that frames this comes from Patrick Lightbody, CEO, BrowserMob. He said, “We found that when we woke up developers at 2am, defects got fixed faster than ever.”
To facilitate creating tribal knowledge within IT Operations and shared accountability for uptime and availability with Development, the steps in this area include:
Make Dev initially responsible for their own services
Return problematic services back to Dev
Integrate Dev into the incident management processes
Have Dev cross-train Ops
Area 4: Embed IT Operations into Development
This area is the reciprocal of Area 3, and the goal is to create the service design and delivery equivalent of designing for manufacturing (DFM). In plant engineering, DFM recognizes that the primary customer of engineering is the manufacturing personnel, and therefore one of the engineering goals is to parts are designed for easy assembly, minimizing the likelihood of putting on parts on backwards, over-tightening, being damaged during transit or assembly, and so forth.
Similarly, in addition to ensuring that IT Operations needs are integrated into the daily Development processes of design, requirements specification, development and testing, the product and processes are designed with resiliency in mind.
The steps in this area include:
Embed Ops knowledge and capabilities into Dev
Design for IT Operations
Institutionalize IT Operations knowledge
Break things early and often
This includes embedding or liaising IT Operations resources into Development, creating reusable user stories for the IT Operations staff (including deployment, management of the code in production, etc.), and defining the non-functional requirements that can be used across all projects.
It is my firm belief that ITSM and the DevOps movement are not at odds. Quite to the contrary, they’re a perfect cultural match. As DevOps gains momentum I’m excited by what we can achieve using a winning combination of the two. It is my sincere hope that by reading this article, you’ll better understand what DevOps is, see why it is important and be energized by the possibilities it creates, and generate some ideas of how to put some of these practices into place in the IT organizations you help support.