Batman, SIAM and Mean Time Between Ass Kickings: SITS16 Recap

It’s the London Olympia baby! Last week was the 2016 Service Desk & IT Support Show or SITS for short. SITS is a annual, free event in central London dedicated to all things tech support and ITSM related.

 

DevOps Needs Leaders – Daniel Breston

The first session we attended was run by fellow Batman super fan and all round ITSM rockstar Daniel Breston.

 

 

Taking all of 5 seconds to get a Batman reference into his content, this was clearly destined to be my favorite session of the day. Daniel opened by talking about the iceberg of ignorance, in other words, the further away you get from service delivery, the few problems that you see. Daniel continued by discussing how one of the biggest challenges faced by managers is taking the time to improve.

Daniel introduced the ITIL, Agile and Lean triumvirate explaining how it’s not enough to have best practice, we must be responsive to the needs of the business and efficient in the way we deliver enterprise services.

The next part of Daniel’s presentation focused on how DevOps is a way to do better faster safer on a continual basis. Daniel talked about the need to focus on the entire value stream of better faster safer from strategy right through to operations.

Daniel went on to talk about measurements and advocated putting your business reports in a language your company understands for example from zero to we got this! He also introduced a brand new metric which I think our friends at AXELOS towers should be all over in terms of including it in the next ITIL refresh.

The final part of Daniel’s session focused on behavior. As Daniel put it “DevOps starts with management talking to people and finding out what their problem are.” Daniel talked about the 3 ways to manage effectively environment:

  • You built it, you run it
  • Project to product
  • Strangle the complexity – lose the nonsense

His final point? Don’t forget to celebrate your successes along the way, preferably with beer!

The Pros and Cons of Public and Private Cloud – Sarah Lahav, SysAid Technologies

 

Sarah opened her session by talking about the recent LinkedIn hack; asking her audience how many of them were able to understand if their personal data had been compromised from the e-mail response issues by LinkedIn – ie the importance of asking the right questions.

Sarah went on to talk about the public cloud and private cloud and the pros and cons of each approach. Public clouds are typically easy to use, flexible and operated by a third party but may be unreliable and less secure than an in house solution. Private clouds are organisation specific, customisable and more secure but can be more costly and require in house expertise.

The next part of the session looked at how a hybrid model can give organisations the best of both worlds without increasing risk. Sarah went on to talk about case studies of the SysAid product from General Cable. Fluortek and LAN Airlines who has the impressive statistic of being able to handle seven times the number of Incidents since using SysAid.

Sarah concluded by explaining with the evolution of SaaS and cloud, it takes new skills to manage your estate effectively, Sarah’s advice? Every organisation is different so in terms of cloud provision, capture the requirements of your organisation and then plan accordingly.

 

Transforming The Service Desk With SIAM & Lean – Joe Bicknell, ServiceNow

The final session we attended was Joe’s session on Service desk transformation. Joe opened with the frankly terrifying statistic of outside the workplace, 84% of requests are automated, inside the workplace only 33% of requests are automated. The upshot? The average employee spends around 15 hours of their working week faffing about trying to  battle the admin mountain.

 

Joe went on to explain the ServiceNow way of thinking “we believe everyone in your organisation requests something and everyone in your business is a service provider in some way.”

 

Joe used ServiceNow to demonstrate how ITSM can be applied to the entire organisation, streamlining processes and removing silos. His top three takeaways?

 

  • Own IT Service Management in your business; it’s the key link between the front and back office.
  • Change the way you work, don’t use technology to compliment what you do
  • Take the workshop to your organisation and start to take Service outside of IT

 

Did you go to #SITS16? Let us know in the comments!!

 

Image Credit

Guest Post: Practical ways to end the DevOps – IT Service Management Stand-Off

There’s some great dialog in the final standoff between Batman and the Joker in the movie The Dark Knight. It’s no-rules anarchy versus incorruptibility – “this is what happens when an unstoppable force meets an immovable object”- as the Joker maniacally puts it.

6013651966_65c232e9f8_b

In some ways it’s analogous to the friction existing between development and IT service management (ITSM) – especially how each group views DevOps. If you ask each team what DevOps means to them you’ll probably get two different answers. On the one hand, developers may stress freedom of action and faster releases, while on the other, ITSM practitioners might say DevOps changes nothing. After all, processes and controls painstakingly developed over many years is the ‘tough love’ needed to ensure regulatory compliance and address many other governance related issues.

Unstoppable force meets immovable object

Some ‘modernists’ will of course argue that old-style ITSM can be excluded from DevOps initiatives. After all, it’s a set of practices designed for a style of business computing where risk tolerance was low. So armed with new terms like lean, agile and fail-fast, it’s a case of get with the program or get out of the way. Well good luck with that, because without recalibration, those traditional incident, problem, change and release management contact points between development and ITSM will become even more abrasive. So enrolling the support of existing ITSM roles and practices is critical; turning naysayers and opponents into advocates. But this isn’t going to be easy and requires some deft organizational footwork. If everything remains equal nothing will change In order to remove friction, DevOps leaders should start by clearly communicating why it’s necessary to change. Care should be taken to avoid over hyping DevOps; preferring instead concise explanations as to why the change is occurring in the context of business impact and outcomes. During this early stage it’s also important to set a collaborative foundation; giving strong consideration to temporarily seconding key ITSM influencers to the DevOps program so as to build trust.

In many industries, computing controls, especially in areas such as change and release management, exist to ensure compliance with regulatory mandates. To development these appear cumbersome, but have been specifically designed to mitigate risk – even if that means slowing down processing. Furthermore, these controls deliver auditable proof that compliance procedures are being followed. The problem is that many of these controls might be too rigid to support development projects where risk tolerance is higher, so it’s critical for teams to optimize or right-size sets of controls for specific use cases. Here, care should be taken not to abrogate risk responsibilities by simply passing control ownership (for example, enabling development managers to approve changes but still carry all auditing responsibilities), since that might lead to increased friction and resistance to change – where you least want it – within the development group itself.

In terms of optimizing existing (but necessary) controls, this could involve enacting faster and more reliable ways to meet compliance requirements. For example, employing automated test suites during the actual development process – versus having auditing ‘gatekeepers’ come in at the end of the process and discover the system isn’t compliant.

In God we Trust – everyone else brings data!

Organizations have usually made a significant investment in IT service management tools. These tools, especially the knowledge bases supporting processes like incident, problem and change management can provide teams rich sets of information to drive DevOps improvements. Change records correlated with performance-related incidents and problems could help teams focus on non-functional aspects of development and testing requiring attention. Additionally, emergency change procedures could be reviewed to determine their applicability in supporting business-critical or urgent software updates. In all cases, however, teams should ensure flexibility doesn’t increase business risk – for example – by teams choosing the path of least resistance to avoid governance scrutiny. There are many other ITSM contact points teams can review to reduce friction. In incident management developers often complain that it takes too long for them to be notified of problems related to their code – only after lengthy level 1 and level 2 operations review. This causes friction because developers might be taken off projects to fire-fight problems that due to time delays have become more complex to diagnose and remediate.

To address this, teams should carefully review notification procedures; perhaps even changing the first point of escalation to be the development group responsible for the application or service – even after hours. Expect push-back where you least expect it. Developers may resist mandated on-call support. Therefore it’s important to impress how their early involvement in incident response is critical to drive improvements. It’s also a good idea to equip them with analytic tools and proactive methods that help them resolve complex and emerging issues. Finally, an important, but often understated bi-product of this ‘skin in the game’ approach is developers working to improve the ongoing supportability of applications. For example, it could result in improving documentation and fault logging so they only need to be called in when absolutely necessary.

Ignoring the points of friction between DevOps and older (but still important) ITSM processes will cause initiatives to stall or fail. The only way to ensure success is when teams put all governance and risk-versus-speed and agility concerns on the collective table and enact improvements in the context of required business outcomes. Always consider that without constant engagement, staff on both sides will revert to sub-optimal practices – the ones that stifle innovation or carry huge risk.

PW

This article was contributed by Peter Waterhouse, Senior Strategist, CA Technologies

Image Credit