AXELOS plans, challenges and expanding team (Video)

This interview was filmed at the Pink Elephant Conference and features Kaimar Karu, Head of ITSM and Kelvyn Lien-Hicks, Sales and Marketing Director, discussing their newly appointed roles at AXELOS.

In Summary

In addition to explaining his role as Head of ITSM, Kaimar talks about:

  • ITIL culture differences
  • Changing perceptions of ITIL
  • Training provider challenges
  • Biggest challenges to success for AXELOS
  • Plans for the next 6-12 months

In the second part of this video, Kelvyn explains:

  • What AXELOS will be selling
  • The ITIL and Prince2 value proposition
  • AXELOS partner programme

Please note that owing to this interview being filmed live at the Pink Elephant event, there are some minor volume issues and background noises throughout this video.


About AXELOS

AXELOS is a new joint venture company, created by the Cabinet Office on behalf of Her Majesty’s Government (HMG) in the United Kingdom and Capita plc to run the Best Management Practice portfolio, including the ITIL® and PRINCE2® professional standards. Its goal: to nurture best practice communities, both in the UK and on a truly worldwide scale, establishing an innovative and high quality, continuous learning and development destination that is co-designed by and co-created for those who use it. Visit www.axelos.com for for more information.

About Pink Elephant

A global company with a proud and pioneering 30 year history – the world’s #1 supplier of IT Service Management and ITIL® education, conferences and consulting.Visit www.pinkelephant.com for more information about the company, services and products.

This video was filmed at the 2014 Pink Elephant Conference. The 19th Annual Pink Elephant International IT Service Management Conference and Exhibition will take place at the Bellagio Hotel in Las Vegas, February 15-18 2015. Registration is now open.

Availability, Incident and Problem Management – The New Holy Trinity? (part 2)

7961705128_66733257fb_z

Following on from part one, here are my next seven tips on on how to use availability, incident and problem management to maximise service effectiveness.

Tip 4: If you can’t measure it, you can’t manage it

Ensure that your metrics map all the way back to your process goals via KPIs and CSFs so that when you measure service performance you get clear tangible results rather than a confused set of metrics that no one ever reads let alone takes into account when reviewing operational performance. In simple terms, your service measurements should have a defined flow like the following:

Untitled1

Start with a mission statement so that you have a very clearly defined goal. An example could be something like “to monitor, manage and restore our production environment effectively, efficiently & safely”.

Next come your critical success factors or CSFs. CSFs are the next level down in your reporting hierarchy. They take the information held in the goal statement and break them down into manageable chunks. Example CSFs could be:

  • “To monitor our production environment effectively, efficiently & safely”
  • “To manage our production environment effectively, efficiently & safely”
  • “To restore our production environment effectively, efficiently & safely”

KPIs or key performance indicators are the next step. KPIs provide the level of granularity needed so that you know you are hitting your CSFs. Some example KPIs could be:

  • Over 97% of our production environment is monitored
  • 98% of all alerts are responded to within 5 minutes
  • Over 95% of Calls to the Service Desk are answered within 10 seconds
  • Service A achieves an availability of 99.5% during 9 – 5, Monday – Friday

Ensure that your metrics, KPIs & CSFs map all the way back to your mission statement & process goals so that when you measure service performance you get clear tangible results. If your metrics are linked in a logical fashion, if your performance goes to amber during the month (eg threat of service level breach) you can look at your KPIs and come up with an improvement plan. This will also help you move towards a balanced scorecard model as your process matures.

Tip 5: Attend CAB!

Availability, incident and problem managers should be key and vocal members of the CAB. 70%-80% of incidents can be traced to poorly implemented changes.

Problem management should have a regular agenda item to report on problems encountered and especially where these are caused by changes. Incident management should also attend so that if a plan change does go wrong, they are aware and can respond quickly & effectively. In a very real sense being forewarned is forearmed so if a high risk change has been authorised, having that information can help the service desk manager to forward plan for example having extra analysts on shift the morning of a major release.

Start to show the effects of poorly planned and designed change with downtime information to alter mind-sets of implementation teams. If people see the consequences of poor planning or not following the agreed plan, there is a greater incentive to learn from them and by prompting teams to think about quality, change execution will improve, there will be a reduction in related incidents and problems and availability will improve.

Tip 6: Link your information

You must be able to link your information. Working in your own little bubble no longer works, you need to engage with other teams to add value. The best example of this is linking Incidents to problem records to identify trends but it doesn’t stop there. The next step is to look at the trends and look at how they can be fixed. This could be reactive e.g raising a change record to replace a piece of server hardware which has resulted in down time. It could also be proactive for example “ we launched service A and experienced X, Y and Z faults which caused a hit to our availability, we’re now launching service B, what can we do to make sure we don’t make the same mistakes? Different hardware? More resilience? Using the cloud?”

You need to have control over the quality of the information that can be entered. Out of date information is harmful so make sure that validation checks are built in to your process. One way to do this is to do a “deep dive” into your Incident information. Look at the details to ensure a common theme exists and that it is linked to the correct Problem record.

Your information needs to be accessible and easy to read. Your audience sees Google and their expectation is that all search engines work in the same way.

Talk to people! Ask relationship and service delivery managers what keeps them awake at night and if there is know problem record or SIP then raise one.  Ask technical teams what are their top ten tech concerns. I’ve said it before and I’ll say it again. Forewarned it forearmed. If you know there’s an issue or potential for risk you can do something about it, or escalate to the manager or team that can. Ask the customer if there is anything they are worried about. Is there a critical product launch due? Are the auditors coming? This is where you can be proactive and limit risk for example working with change management to implement a change freeze.

Tip 7: Getting the right balance of proactive and reactive activities

It’s important to look at both the proactive and reactive sides of the coin and get a balance between the two. If you focus on reactive activities only, you never fix the root cause or make it better; you’ll just keep putting out the same fires. If you focus on proactive activities only, you will lose focus on the BAU and your service quality could spiral out of control.

Proactive actions could include building new services with availability in mind, working with problem management to identify trends and ensuring that high availability systems have the appropriate maintenance (e.g regular patches, reboots, agreed release schedules) Other activities could include identifying VBFs (more on that later) and SPOFs (single points of failure).

Reactive activities could include working with incident management to analyse service uptime / downtime in more granularity with the expanded incident cycle and acting on lessons learned from previous failures.

Tip 8: Know your VBFs

No, not your very best friends, your vital business functions! Talk to your customers and ask them what they consider to be critical. Don’t assume. That sparkling new CRM system may be sat in the corner gathering dust. That spreadsheet on the other hand, built on an ancient version of excel with tens of nested tables and lots of macros could be a critical business tool for capturing customer information. Go out and talk to people. Use your service catalogue. Once you have a list of things you must protect at all costs you can work through the list and mitigate risk.

Tip 9: Know how to handle downtime

No more hiding under your desk or running screaming from the building! With the best will in the world, things will go wrong so plan accordingly. The ITIL service design book states that “recognising that when services fail, it is still possible to achieve business, customer & user satisfaction and recognition: the way a service provider acts in failure situation has a major influence on customer & user perception & expectation.”

Have a plan for when downtime strikes. Page 1 should have “Don’t Panic” written in bright, bold text – sounds obvious but it’s amazing how many people panic and freeze in the event of a crisis. Work with incident and problem management to come up with the criteria for a major incident that works for your organisation. Build the process and document everything even the blindingly obvious (because you can’t teach common sense). Agree in advance who will coordinate the fix effort (probably Incident management) and who will investigate the root cause (problem management). Link in to your IT service continuity management process. When does an incident become so bad that we need to invoke DR? Have we got the criteria documented? Who makes the call? Who is their back up in case they’re on holiday or off sick? Speak to capacity management – they look at performance – at what point could a performance issue become so bad that the system becomes unusable. Does that count as down time? Who investigates further?

Tip 10: Keep calms and carry on

Your availability, incident and problem management processes will improve and mature over time.  Use any initial “quick wins” to demonstrate the value add and get more buy in. As service levels improve, your processes will gather momentum as its human nature to want to jump on the bandwagon if something is a storming success.

As your process matures, you can look to other standards and framework. Agile and lean can be used to make efficiency savings. COBIT can be used to help you gauge process maturity as well as practical guidance on getting to the next level. PRINCE2 can help with project planning and timescales. You can also review your metrics to reflect greater process maturity for example you could add critical to quality (CTQ) and operational performance indicators (OPIs) to your existing deck of goals, CSFs and KPIs.

Keep talking to others in the service management industry. The itSMF, ISACA and Back2ITSM groups all have some fantastic ideas for implementing and improving ITIL processes so have a look!

Final thoughts

I’d like to conclude by saying that availability, incident and problem management processes are critical to service quality. They add value on their own, but aligning them and running them together will not only drive improvement but will also reduce repeat (boring) incidents, move knowledge closer to the front line and increases service uptime.

In conclusion, having availability, incident and problem management working together as a trio is one of the most important steps in moving an IT department from system management to service management as mind-sets start to change, quality improves and customer satisfaction increases.

Image Credit 

Stop Blaming Release Management!

When releases fail, we often point a finger at the release manager, expecting that person to make the necessary corrections to prevent similar failures in the future.  In doing so, we miss the real target – the service delivery flow.  This flow, with its many inputs, is in disarray in most organizations and the solution seems daunting.  This article proposes that there is a simple, inexpensive, and self-healing approach to improving the flow of service modification.

When a Release Goes Bad

The scene is too familiar.  The service desk, on the verge of panic, is swamped with increasingly irate calls.  The boss is on a bridge line with a host of managers and technicians trying to restore order.  The business units, demanding action, are banging on the CIO’s door and the echoes reverberate throughout IT.

Last night, IT distributed a major release of a critical business application.  Today, users are converging on IT with torches and pitchforks.  The business application update had an enormous impact on productivity and revenue.  The impact continues as the business owner demands that the changes be “backed out” – a request that IT finds exasperatingly difficult to satisfy.

When the dust settles, it is not uncommon to see root cause analysis identify the numerous mistakes made in the “release”.  The list might include:

Table1
Common Issues and Likely Culprits

Who is to blame?  Release management?  Of the 11 mistakes listed, 9 belong to groups outside release management.  Yet, in many cases, release management will still take the heat.  The purpose of this article is not so much to absolve release management but rather to bring understanding to the larger service lifecycle in hopes that the readers can address the true causes of release failures.

Know the River

Release and deployment management is just one part of a much larger lifecycle.  Think of it as a port along a river.  A business service starts out as an empty barge on the business dock.  In ITIL terms, the manager of that dock, Business requirements management (BRM), loads the barge with service requirements.  In the diagram, this is the “Identify” stage.

Service Flow - Stages, Participants, Output
Service Flow – Stages, Participants, Output

The barge makes a number of stops on its way down the river.  Along the way, the manifest of the barge is equivalent to the seldom referenced (but, in some form, always present) service design package of ITIL.

When the barge, stacked with cargo, finally pulls into the release and deployment dock, the only issue should be how to transport the contents of the barge effectively and safely to the appropriate recipients.  One could think of release and deployment as a trucking company.  The truckers did not design or build the cargo.  Nor are they to blame if the item in the package performs poorly.

I recently ordered a manual online.  The package arrived in the expected time frame and was intact.  As I read the manual, I noticed that an entire section was missing.  Should I blame the trucking company?  Of course not.  Likewise, we should not hold the release management responsible for defects over which it has (by design and best practice) no control.

The following table might help to identify the “river ports” where the service barge might be picking up sub-standard cargo.

Service Lifecycle River
Service Lifecycle River

Look Upstream

In order to effectively manage and improve the delivery of a release, we need to focus on three major points:

  • Transition review
  • Service delivery package
  • Project charter
Feeding the Transition Review
Feeding the Transition Review

Transition Review

The objective of the transition review (post implementation review) is simple: Learn from your mistakes.  When an organization first commits to regular PIRs, they may be a bit disorganized.  As inputs and outputs become better defined, so will the overall process.   The transition review is the spawning ground for improvement of this lifecycle.

Service Design Package

Although few enterprises seem to understand the concept of the SDP, it is, in my opinion, a brilliant addition to ITIL v3 2011.  When organizations address the output of Transition Reviews, they inevitably make adjustments to the SDP because it is the mechanism for improving consistency, governance, and effectiveness for the service modification lifecycle.

Project Charter

In most shops, the service modification lifecycle begins around a table of senior managers.  The beginning of a project needs to be less about hierarchy and more about process because this is not a hand-off; this is a flow.  Four players are critical to the project charter.

  • Business relationship manager – understands business requirements.
  • Service portfolio manager – understands the pipeline and service catalog.
  • Service level manager – understands issues that might impact service levels and process.
  • IT architecture – understands the importance of a consistent framework.
Deming's PDCA Organic Flow
Deming’s PDCA Organic Flow

With these, the organization understands business requirements, process, and infrastructure within the context of service delivery.

Completing the Circle

With the project charter, service design package, and Transition Review, we have completed the deming circle (Plan, Do, Check, Act).

Most shops fall short in planning and checking because these activities are poorly governed and too loosely integrated into the overall flow.  As Yoda would say, “Without plan, no do; without check, no act.”

Start Small but Start Smart

When a release fails (especially when it fails in a spectacular way), the fault generally lies in the process.  If, as I assume, this is common knowledge, why do these broken processes persist?  Because most enterprises perceive that process optimization costs too much money, takes too much time and does not meet more immediate business objectives.This reticence is understandable given the typical consulting approach.  A consulting firm will probably suggest starting with a comprehensive assessment that forms the basis for a massive proposal that drains resources from business-critical initiatives.

Instead, insist that any partner (consultancy) starts simply.

Enable the Flow to Manage the Activities

The degree to which this lifecycle is managed is inversely proportional to the likelihood of failure.  The simplest way to manage a lifecycle is shown above in the Deming diagram.  The idea is to implement the organic lifecycle flow and let the flow improve the subordinate activities.To accomplish this, we need to implement the flow with the associated roles.

Step 1 – Establish and Empower the BRM Role

The business relationship manager role usually exists in some tainted form.  We need to plug this role into the organic flow.  This role seeks to understand the needs of the business but, just as important, collaborates on those requirements throughout the service lifecycle.  As mentioned above, the BRM is critical to project initiation.

Step 2 – Establish and Empower the Enterprise Design Coordinator Role

The enterprise design coordinator is really the key to success.  There are three main tasks for this role.  Aside from coordinating design and build activities at a high level (not an application development manager), this role also a) ensures that the input from the BRM is adequate and b) ensures that the service design package is complete and accurate.

Step 3 – Establish Policies and Procedures for Transition Review

The release manager (hopefully already in place) will collaborate with the BRM, design coordinator and stakeholders to create policies and procedures for transition review.  The guiding principle for transition review should be that it examines service transition output (incidents, issue logs, metrics) to identify opportunities for process improvement.

Step 4 – Establish SIP Procedures

The output from the transition review will sometimes include a service improvement plan.  The organization needs a standardized procedure for initiating and implementing an SIP.

Step 5 – Do it and Keep Doing it

We have created the organic flow.  We only need to execute it.  Each SIP will improve the effectiveness of the service modification lifecycle.

Note on Change Management

Change management, from an enterprise perspective, plays a significant role in controlling the flow of the service lifecycle.  Most organizations perceive change management from an operational rather than an enterprise perspective – an outgrowth of legacy implementations of IT change requests.  This narrow focus deprives the organization of the true power of this governance process.  I would have enjoyed weaving into this article the benefits that a cohesive and integrated change management process could provide but it deserves a separate piece.

Conclusion

Release and deployment relies, for its success, on a number of upstream processes.  Business relationship management and design coordination, both new to ITIL v3 2011, are key to managing the upstream service lifecycle.  Though they may seem unfamiliar, everyone has implemented these processes to some degree but few have implemented them effectively.  This oversight poses a risk because any enterprise that does not consistently manage the entire lifecycle does not control the operational outcome.  In other words, every release is a roll of the dice.

Feeling lucky?

The Kitchen Nightmare Approach to Continual Service Improvement

Gordon Ramsey
Gordon Ramsey

Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Rae Ann Bruno’s presentation 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
  • Defines services
  • Assesses process, people and tools
  • Defines quality
  • 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.

Additional advice

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.

Image credit

Navy 311: Reinventing service and support

7979352304_687c7a6094_k

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.

The improvements

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
  • Predictive analysis
  • Metrics
  • 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.

Image credit

The Beauty & Simplicity Of Common Sense Business Relationship Management

itSMF 2014

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?

  1. Inspire
  2. Influence
  3. Develop (relationships)
  4. Initiate change
  5. Manage conflict
  6. 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?

What I learned about IT and DevOps from Gene Kim

Gene Kim presents at itSMF Norway
Gene Kim presents at itSMF Norway

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

Bonus learning

Other things we learnt in this session that you might not know:

  • 95% of all capital projects have an IT component
  • 50% of all capital spending is technology-related
  • The value of DevOps is even greater than anyone can imagine. Some of the companies doing DevOps include: Spotify, Google, Amazon, Bank of America, H&M, US Department of Homeland Security, Twitter, Gap (and a long list of others).
  • A survey of the room showed that it took most months, and even quarters, to deploy a change request. Did you know that an effective DevOps 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.

To learn more about the entire itSMF Norway conference please read: The itSMF Norway Conference: it’s the one that I want!

The itSMF Norway conference – it’s the one that I want!

DSC_0022
itSMF Norway Conference

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.

Other messages

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:

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.

Security after Snowden – what do I need to do?

securityThe implications of the revelations of ex-NSA employee Edward Snowden have been much discussed and many people who were not previously concerned with cyber-security are now wondering what they should be doing. This is a good thing – but the danger has not changed, only the perception of it. Most of the ideas outlined here were well known, at least in broad terms, before this, but those who argued for them were considered paranoid.

If you’ve been asked to put a presentation together; maybe your Board is suddenly wanting to know what can be done. Then this, I hope, will be just the article for you. It is intended to be a quick, high-level guide to exactly that. The solution is not all, or even mainly, technical, the solution is actually a matter of sound service governance, as I’ll describe. So, what to do?

First; don’t panic! There is not very much that can be done in the short term – rushing about trying to fix firewalls is likely to make things worse, a worthwhile solution must be thought out properly.

Secondly; do you need to do anything at all? Maybe not. It is only worth spending money to address a risk if the risk is credible and, if it happens, will have a large impact. If the worst happened and your most important competitor and all your customers and suppliers, were to see all your corporate information, in detail, would your business suffer? For a good many businesses, the answer is ‘no, not really, not much’. If that is the genuine answer, then there is no need to waste money on expensive security measures. Many companies, on the other hand, would go out of business quite quickly in this situation – for them, it is essential, for good governance, to be certain that a proper cyber-security policy is in place, and then put into action.

What is the threat? Exactly the scenario outlined above. If somebody can access your information through a secret trapdoor in your firewalls, your applications, or your operating systems, then, in principle, anybody can.

Governance and Cyber-Security

The biggest risk to security isn’t technical at all. Anybody in your organisation can, if disgruntled, take what they’re allowed to have access to and share it with your competitor, the regulators or a foreign government. This is always the biggest risk.

How do you mitigate this one? Staff Satisfaction. If you have good governance, so that, as an organisation, you have fair policies, you are a good corporate citizen, so you help your community and you look after your staff by treating them fairly, giving them opportunities for advancement and training them, then you will have satisfied staff who will be loyal to you and won’t wish to let you down by revealing your corporate secrets to competitors.

So the first firewall you need to build is a wall of trust between your organisation and your staff – the same applies to suppliers and customers, you need to make sure that they also are part of your circle of trust so they don’t reveal things that could damage the organisation.

It helps too, because good governance ensures that the organisation is behaving ethically, so there are no skeletons in the cupboard waiting to be revealed by whistle-blowers.

Beyond that, you can make sure that your infrastructure is safe from cyber-criminals, spies (both genuine spies and industrial spies), hackers and so forth. This is not as easy as it seems, so it is worth considering technical solutions to cyber-security in a bit more detail.

Firewalls

The most obvious danger highlighted by the Snowdon’s revelations was how vulnerable organisations are to closed source solutions. In the past the simple-minded solution many people saw to security was to put everything behind a firewall. This has three problems:

  1. The firewall can be breached through any trap doors in its firmware and this breach will be undetectable
  2. Even if the firewall isn’t breached, closed-source operating systems can communicate back to the ‘mother ship’ through the firewall through their trap doors
  3. Even if your closed operating systems and closed firewalls are not letting anybody in, your closed applications can be.

On that last point, if you’re running Microsoft Office products on your computer, have a look at the activity monitor. Even if you’ve not used word, say, for many hours, you’ll see it has clocked up lots of activity. What is it doing? It’s connecting back to Microsoft to check that your license is OK – that’s it, you’re paying for it to do this several times a day, on your CPU. If Microsoft wanted it to send other information back, would you have any way of knowing?

Can you trust any closed-source firewalls, Operating Systems or Applications? Snowdon has shown that you can’t. It makes sense for anybody wanting to spy to put their bugs (in the sense of listening devices) as close to you as they can – and putting secret trapdoors into these devices simply makes sense (to a spy).

Why is open source any different?

It is still possible to put trapdoors into open source software. The difference is that you can get somebody to check the software and cut out anything in it that you don’t need, or looks suspicious – and you can get open source software to log what it is doing honestly. Closed source software can put what it wants to into a log, if it leaves out certain things it doesn’t want you to see it is doing, you can’t even know that they are missing.

If you look on the market, you will find that there are no open source firewalls, at least not hardware boxes. There is an open source operating system, though, Linux (let’s hope that in future there will be more, and better ones), open source word processing and spreadsheet software and other open source applications.

To reduce the risk, where possible, remove proprietary closed-source devices and replace them with open source ones. It would be expensive overkill to throw out everything proprietary at once. Rather, produce a service portfolio and concentrate on the services that are most important to the organisation and replace them with open source solutions first.

If you have a firewall made in China, and a firewall made in the US, you could try putting one firewall inside the other – that way you’re banking on the Chinese firewall blocking the US secret trapdoor and vice versa. Even if this worked, though, you still have the problem with operating system and application trapdoors.

A better solution is to shut down your firewalls. That seems a bit extreme, but, if you have physical boxes as firewalls, you can’t do anything about the firmware they are running, so don’t. Make a Linux box your firewall with a software firewall. It might be a bit slower, but it will be safer.

What can be done in the long term?

If you have closed source solutions, see if your supplier can give you, or sell you, the source code. Then you can check that for trap doors and remove anything you think suspicious or unnecessary.

Invest in open source development. There is no reason why an ‘open source’ router or firewall can’t be developed, where the hardware and firmware are all revealed and can be tested to see they have no trapdoors. This takes money, so organisations interested in long-term solutions need to invest in such efforts.

If you are going to have firewalls, make sure that they are governed properly. Do you actually know what the rules are on your firewalls at the moment? Probably not. Usually the rules are written in ‘techie-speak’ and only a few experts know what they are. This is bad governance. Invest in rule-based firewalls where the rules can be set by the policy you have for each service in a way that is understandable to non-technical people.

If you do invest in open source development, the most promising area for fast, easily configured and effective cyber-security is using the same machines that are currently being used for bit-coin mining. They are getting cheaper all the time and are very, very fast. They are seen to be difficult to programme though, and, again, only experts know what they are doing.

There is a solution, though, which is to invest in open source development in Ada for these boxes (FPGA, or field-programmable gate arrays – to give the jargon). Ada is a language invented by the US DoD to be reliable. It is very fast, it is proven to be faster to write and faster to execute than assembler. It is possible to produce secure routers and firewalls with no trapdoors that can be configured at the service level (so the rules are understandable in business terms) using Ada – but a number of companies need to put up the investment capital to achieve this.

What can I do about it now?

Here is a short checklist of actions that should lead towards a more secure organisation. Not every organisation will need to do all of them, and not all will need to start with them at once, but this is the basis:

Short Term:

  • Audit your staff satisfaction
  • Audit your customer satisfaction
  • Audit your business and technical infrastructure
  • Identify the greatest risks from weaknesses in the above
  • Produce a plan to address these

Medium & Long Term:

  • Fund a programme to govern services.
  • Establish a service portfolio to enable the board to understand which business services deliver most value, what they cost, what risks they are exposed to and how to mitigate those risks.
  • Use this portfolio to prioritise the requirements for the organisation into a corporate requirements register.
  • Design a set of solutions to address these requirements
  • Build business cases for these solutions
  • Execute the plans from the most appropriate business cases

Conclusion

Security has never been a truly technical matter. The best security in the world can be circumvented in a few seconds by a whistle-blower. The correct response is not to panic, but to put in place a set of well thought-out policies and then, through well-designed procedures and processes, make sure that these policies are complied with. It takes time and money, but it is the only route to reaching a tolerable level of security. If you use a modern governance framework, such as that proposed by the King III commission, it will ensure that you act to be a good corporate citizen – which will reduce the risk of whistle-blowers by achieving satisfied staff, customers and suppliers.

It is worthwhile establishing service governance as the organisation’s main governance tool because it enables and improves all business processes, delivering value to stakeholders by ensuring, along with many other things, a proper balance between risk and investment in cyber-security. Decisions to invest in an aspect of security should be based on the appropriate requirements of each particular service and its stakeholders.

Much needs to be done to develop the secure infrastructure that can be used to implement the cyber-security policy. In an ideal world, companies exposed to the risk would invest collaboratively in producing components for secure infrastructure.

Why not suggest to your board, as part of good corporate citizenship (an important part of governance) investing in a secure open source project?

Image Credit

Enterprise Mobility Management: Concepts in Endpoint Management

Roberto_Casetta_5343
Robert Casetta

The following article has been contributed by Roberto Casetta, Vice President EMEA, at FrontRange.

Empowering a mobile workforce is essential in any modern enterprise to meet business goals and remain competitive.  Mobility increases end user productivity, agility and job satisfaction, resulting in improved business performance.  Although workforce mobility is most often associated with the adoption of portable devices (i.e. smartphones and tablets), the topic is actually more applicable to the portability of IT services.  The core goal of mobility is to enable users to access business resources – including applications, data and other services (such as email, messaging and databases) – from any device at any location at any time.

Ironically, most end users have already embraced mobility concepts and incorporated them into their regular work experience.  In fact, according to research by industry analyst firm Enterprise Management Associates (EMA), roughly 58% of mobile device users and 29% of laptop users actually purchased the devices themselves and brought them into their workplace.

No longer content with being chained to an office environment, workers are demanding unprecedented mobile access to business IT resources.  In many cases, IT managers have been caught unprepared to support the influx of new requirements for supporting mobility. Introducing enterprise mobility is therefore primarily a challenge for IT operations to accept changes to its processes that will foster improved workforce productivity.

However, introducing process changes to support mobility is not a trivial matter. IT administrators are already exceptionally busy meeting existing server and desktop support requirements and service level agreements, while meeting security and compliance objectives.  Typically, IT administrators spend the bulk of their time on reactionary “firefighting,” often requiring an inordinate amount of out-of-hours support.  This leaves little time to implement new procedures for extending support to an additional set of mobile devices and operating systems.

Further resistance to supporting enterprise mobility comes from the fact that IT administrators are used to having complete control of the endpoints they support and are often reluctant to allow end users the freedom to select and use devices without restrictions.

To be effective in supporting workforce mobility, IT administrators must focus on the secure delivery of services, rather than maintaining control over the endpoints.  Devices also still need to be managed, but just to ensure they are optimally configured to perform business tasks, rather than fully governed by IT operations. This can be a difficult concept for IT administrators to accept as they must let end users take some or all responsibility for their own devices.

Enterprise mobility management processes shift the role of IT administrators to focus primarily on the secure and reliable delivery of business IT resources in order to empower end users with the flexibility to perform business tasks on any device with which they will be most effective.

Transitioning IT Operations to Support Workforce Mobility

In order for IT administrators to successfully enable enterprise mobility, management processes must be adopted that effectively reduce administrative efforts and costs while enabling broad but secure end user access to business IT resources.  Methods for achieving this can be logically segmented into three key areas.

Consolidate Management Processes and Resources

All user devices used to perform business tasks – including smartphones, tablets, laptops and desktop – should be monitored and managed from a single unified console.  Begin by discovering configuration and status details on all devices and recording them in a consolidated asset data repository.  This enables a holistic view across the support stack to facilitate a rapid identification of issues and provides administrators with the strategic information necessary to make informed decisions on optimal configurations and proactive improvements.

Business applications, data, and services should also be consolidated onto enterprise servers (rather than distributed on endpoints) and then delivered to remote devices as a services. This creates a single point of management for business resources, greatly simplifying tasks such as patching, updating, and configuring.  By shifting the primary management focus towards securing and delivering IT resources (rather than physical devices) administrators are able to address business-facing challenges while reducing support efforts.  Additionally, delivering business resources as services allows end users to provision them on any device they wish.

Isolate Business Resources from Users’ Personal Resources

To ensure users have the freedom to employ their devices (whether employee or business-owned) in any capacity they choose, only the business resources that are served to the endpoints should be subject to enterprise restrictions.  To enable this, business resources must be isolated from personal applications and data.  The most common processes for achieving this include ‘containerisation’, virtualisation, and application wrapping.  Regardless of which method is employed, the ability to move between business and personal resources should be simple and intuitive to the end users to ensure they remain productive.  In this way IT administrators can enforce business requirements on the isolated resources without impacting or diminishing the users’ ability to perform personal tasks on the devices.

Enable End User Self-Service

End users should have the ability to provision their own devices with little or no interaction with IT operations.  This can be accomplished with a consolidated application delivery system, such as a mobile AppStore, that provides a “one stop shopping” experience for accessing all business applications, including static applications, virtual applications, and web applications.  Similarly, data can be stored and distributed via a secure share or other centralised and commonly accessed repository.  All provisioning procedures should include approval and authentication processes to ensure resources are only accessed by authorised personnel.

In Summary

At the core of enterprise mobility management is the need to enable a secure, user-focused delivery of IT resources and services.  However, this cannot be effectively implemented unless it also includes processes for minimising administrative efforts.  By not trying to “drink the ocean” in supporting everything installed on every device employed by every user, and instead focusing on the secure delivery of business IT resources as a service, administrator time is used more efficiently – the number of user requests are greatly reduced, management complexities are minimised, and the need for out-of-hours support becomes a rare event.  In reducing requirements, administrators are freed up to implement new and enhanced business-facing IT services and transform the delivery of endpoint management services into being proactive, rather than reactive.

This article was contributed by Roberto Casetta, Vice President EMEA, at FrontRange.