Archive for March, 2014

Once a upon a time in the East (Notes from itSMF Singapore 2014)

March 28, 2014

It was a pleasure being at itSMF Singapore 2014 for speaking on Storytelling.

Presenting Storytelling -itSMF Singapore

Presenting Storytelling at itSMF Singapore 2014

First of all, I thank the organization for great experience and smooth experience there. Rama and Vinay from the board, Joanne and Marco and all good people from itSMF Singapore made this event a joy for me.

I finally met Suresh GP who curated and pushed it all.

My notes on the event follow without further delay!

Ferocious twetting

Even with such timezone difference for other geographies we had sometimes little ITSM haiku, other times a vivid perception on what was happening during the conference. I think this trend for extending the conference reach is excellent.

The Twitter pack for itSMF Singapore 2014

The Twitter pack for itSMF Singapore 2014

The People

Couldn’t attend to all sessions – I did take worthy insights from them all. I’ll share notes on three:

Peter Brooks (excellent meeting THE Peter Brooks – wonderfully accessible and stimulating talks off the sessions)

  • Service Governance is key (Hello top management accountability?)
  • ITIL has tons of excellent material scarcely used
  • We need an ontology, precise meaning for ITSM concepts (Adaptive Service Model initiative)

Peter Hepworth (met for the first time the man leading Axelos)

  • Portrayed Axelos as a startup – coming to Singapore is part of strategy to talk with local stakeholders and he got feedback from them the day before the conference (and from us too)
  • Regarding trainer certifications, there are more than 1000 ATOS, training orgs and affiliates combined. Huge task. So Axelos will be grandfathering the trainers.
  • On cybersecurity, is asked on next step but it’s still soon to reveal what’s under the hood for this hot topic

Matt Fourie (pleasant surprise!)

  • Leadership is about telling the what and let people be responsible for the who (this is deeper and seldom found)
  • If you dont find the solution in a few hours you dont have the right people solving it
  • Manage stakeholders, pursue collaboration with all and carefully pursue requirement analysis

The Conference

I sensed a pattern on people being part of the service management equation. Yes, still ITIL core with one session on transitioning the service (this always reminds me of DevOps approach – which has lots of people in it too), more on empowering the end-users; a trend supported/pushed by vendors.

It was great meeting so many interesting people from Singapore and also from Australia. I had the opportunity to meet Kathryn Heaton from itSMF Australia who gave insight on how service management has an opportunity in an unexpected market due to Australia’s digital initiative at schools.

My session on Storytelling went really well – people were groking the stories on changing, got engaging questions at the end and I had the chance to give away some of my specially drawn for the occasion cartoons.

I was there! cartoon for itSMF Singapore 2014 - A torn cartoon

I was there! cartoon for itSMF Singapore 2014 – One of the cartoons I wanted to give way (torn paper… did a newer version 🙂 )

Hope I come back with more time. Well worth the trip!

DevOps after reading Phoenix

March 7, 2014

I’ve recently finished The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win — a rather good use for a long lonely train  trip.

I got lots of ideas and déjà-vu on the situations depicted, so I am posting thoughts on top of what I read.

The return on DevOps is subtle. That may be the harder thing to grasp on this discipline.

Bringing theory of constraints practices that started in the industry to the IT world changes the mindset and the way things get done. A few distinctive aspects of DevOps:

  • Work becomes visible throughout the whole chain
  • Constraints can be identified and dealt with
  • Everything moves faster – including detecting and working out anything wrong

It’s useful to start with proper context. This picture helps.

DevOps and related disciplines, from CollabNet

DevOps and related disciplines, from CollabNet

The Three Ways

The Three Ways are principles from where you can generate DevOps patterns. The first way is the way of the Flow. It means one knows (for you Heinlein fans the right word would be groks) the way value flows from the business to the customer.

The second way is the way of Feedback, adding communication between Ops and Dev.

The third way is the way of Continual Experimentation and Learning. One can improve because now we have feedback from  every small experiment to validate ideas fast.

Fishing The Three Ways

Fishing The Three Ways

You can read a well written description of The Three Ways by Tim Hunter here.

The Deployment pipeline

A core concept for DevOps is the Deployment pipeline, industrializing and removing all technical risks from the whole development to production cycle.

“A deployment pipeline is a single path to production for all changes to a given system., whether to code, infrastructure and environments, database schemas and reference data, or configuration. The deployment pipeline models your process for building, testing, and deploying your systems and is thus a manifestation of the part of your value stream from check-in to release. Using the deployment pipeline, each change to any system is validated to see if it is fit for release, passing through a comprehensive series of automated tests. If it is successful, it becomes available for push-button deployment (with approvals, if required) to testing, staging, and production environments.”

— Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky

Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky, Cutter IT Journal, August 2011

The Delivery Pipeline from Why Enterprises Must Adopt Devops to Enable Continuous Delivery by Jezz Humble and Joanne Molesky (Cutter IT Journal, August 2011)

Deployments become natural, regular and safe. It allows for inverting the wait. That is, IT waiting for the business. So business gets the chance to see working software sooner and within shorter decision windows.

The role of automation

Automation is key for DevOps because it allows for faster time to market. And this changes the way people work and collaborate. For instance, having the same environment from development right up to live production eliminates errors and rework due to disparate environments. This is so obvious that it hurts to think there are still organizations that don’t do it.

Of course there are no free lunches. For the example above one first need to have all configurations under control (not just code, also the environments themselves), otherwise it’s impossible to automate this.

Now think on the impact this approach has for testing. Maybe you don’t catch all errors but you certainly will significantly reduce errors from the Development to Production process itself which cause delays and unproductivity.

When the release cycle reduces to days or even hours you reap another benefit. Introducing new features is fast. Testing scenarios (even with part of your customer base, using A/B testing) is simple.

A neat side effect of automation for the deployment pipeline is that it makes non-authorized changes really hard to sneak in.

And it forces Ops and Dev guys talking each other frequently – probably the biggest benefit of all.