Blog

IT Leader – A Week in the Life…

Lots on, but everyone wants more!

Working on the FY17 portfolio plan. We’re moving data centres between now and next April, upgrading SAP and our entire eCommerce estate but that’s just the baseline. Senior stakeholders from across the organisation have their own projects that they want delivered on top of this move and upgrade. We’ve been working out how to maximise the amount of change we can deliver while maintaining an acceptable level of complexity and risk across the portfolio.

 eCommerce

Part of the upgrade activity is to modularise the eCommerce platform – something that will really help the pace and agility of change in the future. So after our Innovation team talk, I get the web experience agile teams – some 50 people – together to announce this change so everyone understands why we’re doing it and what the impacts will be.
From there I’m off to a session to talk about resourcing the search teams. Search is of critical importance to an online business and is an area we are investing in heavily. With over 500,000 products in the range, ensuring that customers find the product they are looking for is our top priority. We’ve recently brought in a number of highly experienced search specialists but our in-house technical team is weighted towards contractors. While there is always a place for contractors in the mix, we want to maintain a healthy balance so that we retain Intellectual Property in house. We spend some time looking at the options the teams have investigated and decide on a balanced approach of selective recruitment and introduce a new supplier into our contractor base. We’ll review it again in a couple of month’s time to see if it’s working.

Incidents and coffee

Nearly missed it – it’s now time for an incident management meeting. We’ve had some database issues on a project that’s in Early Life Support and the team have been working day and night on it for the past 2 weeks. It sounds like we now have a patch from Oracle that might solve the issue but putting it straight into production is a risk. While I’ve been on most of these calls over the past 2 weeks during this one we agree to put the patch live – and 4 hours later it looks like it has worked. We’ll keep monitoring it though as sometimes these intermittent faults come back – and usually it’s at the most inopportune time.
Time for a quick caffeine boost and I bump into the business sponsor for this project in the coffee shop. I tell him what has been done and that things are looking better. I remind him that formal comms will come out from the incident management and project teams – best not to mix messages as this can lead to confusion. I reassure him that we have everyone we need working on it day and night as a top priority and he appreciates the effort that’s going into resolving the issue.

Steering

We then have an hour with the data centre move steering committee. There’s been a lot of work going on here in the past two weeks to ensure everything’s back on track after a slight wobble. It’s looking much better now having brought in a senior member of the 3rd party’s team who led the data centre transition the last time we did it 5 years ago. In the wrap up I observe that during the bid process we all acknowledged that appropriate use of tooling would be critical to delivering the contractual service levels and that while this was not yet on the critical path, it did appear to be slipping. This should be addressed before it becomes an issue.

Agile and Continuous Integration

Over the past couple of years we have matured dramatically in terms of the processes and technology that supports our digital channels. We have 6 agile teams running using scrum, and are in the middle of putting in Continuous Integration tools and processes. Each agile team has a Development / Continuous Integration environment and we are working on building a Release Candidate environment. We have limited automated unit testing at present but are starting to put in place automated static code analysis tooling and better code monitoring in the test and production environments. In short we’re not in a bad place from a continuous integration perspective. However we agree that they will put forward a proposal to look at our maturity in terms of configuration management, release management, estimation and development and operational metrics.

People and DevOps

I manage to grab some quick 121 time with each of my managers in between times. I had to cancel my team meeting due to the incident meeting earlier in the week and I wanted to let them have their bonus letters and hear what’s on their minds. There’s a lot going on at the moment and they’re all getting on with their own challenges but it’s important that they know they can call upon me if needed and to hear how the general mood is in the department.

I then realise that I’m chairing the next IT Leadership Team meeting. We were planning on spending Day 2 working on our process issues. We’re in a period of transition at the moment so I suggest that it would be good for us to spend some time in the new London Office. Also there’s a lot of talk of DevOps at the moment in the wider market – we’ve had some steers from Gartner – but haven’t done much about it yet. I suggest that we spend 2 days at the Enterprise DevOps Summit in London after the team meeting and it is met with wide approval. Let’s build our knowledge and understanding and then debate what it means for us.

…aaaand relax…

That’s about it for the week.  No cutovers this weekend so providing all remains as it should be then I’ll get some downtime with the family.  Who knows what next week will bring…

 

Advertisements

Be succinct!

Technical people often want to drown their audience in detail.  Bear in mind that boards are (generally) fairly smart.  You therefore don’t need to spoon feed them every detail.  Prove that you’ve done the work with details in the appendix or attachment.
Take the time to distill your message.

Mark Twain received this telegram from a publisher:
NEED 2-PAGE SHORT STORY TWO DAYS.
Twain replied:
NO CAN DO 2 PAGES TWO DAYS. CAN DO 30 PAGES 2 DAYS. NEED 30 DAYS TO DO 2 PAGES.

Don’t waste your audience’s time – Be succinct!

BiModal IT vs DevOps

    BiModal IT is seen by many as the best response to the demand for better, faster, cheaper IT change. However there’s an alternative: DevOps.  Coming from digitally born organisations, DevOps aims to achieve the same faster, better, cheaper result via a different route. So what’s all the fuss about and which operating model should you choose…?

    Bimodal IT

    Bimodal IT is a model put forward by Gartner. The basic principles behind the bimodal IT model is effectively to establish two different streams of change delivered via different operating models.
    The first operating model focuses on front-end, customer facing, differentiating systems, often the digital e-commerce channels. It usually uses agile delivery methodologies such as scrum and has the primary purpose of delivering fast pace of change while accepting the increased risk this change creates. The second model focuses on the so-called engine room systems that generally need to change at a slower pace. Here the focus is on waterfall based delivery methodologies, stability and reliability of change. 

    One view is that the bimodal IT model is a response from traditional IT to deal with the desire of businesses to move at the same pace as digitally born businesses. In essence if you come at the “digital “problem from a traditional IT mindset the response/the answer is bimodal IT. There is an alternative view emerging – that of DevOps. 

    DevOps

    There are many different definitions of DevOps. My version is simply to consider DevOps as the combination of Change and Run. Now before I get flamed by the DevOps evangelists, I get that DevOps is more of a culture change, a mindset shift and an approach that is different to anything we’ve seen before…but for now let’s go with my definition. 

    I would argue that if you come at the “digital problem” from a digital/eCommerce perspective your response is more likely to be something like DevOps. 

    Now there are some out there that would argue that DevOps is not suitable for everything. Some would draw the line at ERP systems like SAP and state that SAP is monolithic in nature and not suitable for agile or a DevOps operating model. I disagree and I will explore this elsewhere in this blog. I would however agree that there are some systems in which a DevOps model is overkill – for example in some commodity services such as email. 

    So, in summary, traditional IT’s response to “digital” is BiModal IT whereas a digital response to traditional IT is DevOps. As always there is likely to be a middle ground which achieves the best of both worlds but this has yet to emerge and mature. 

    As always I’d love to hear your views. Please post your thoughts in the comments below…

    CIO, CDO or CTO

    Chief Information Officer, Chief Digital Officer or Chief Technology Officer. They all have one thing in common – they all use technology to drive competitive advantage. The difference is the lens each applies to that remit.

    The CIO approaches the technology problem from a business perspective. It is the historic role to which a CEO would look to for technology direction. In my view there is still very much a place for CIOs at the board table however in some instances the role of the CIO has been fragmented into other roles, each having a specific focus.

    A CTO will pay much more attention to the technology. They will often come from a technology background and will have a primary focus on how technology can be used within the enterprise. If you want to understand how to take your business into the cloud ask a CTO but beware you may get a technical answer. The CTO role is the one that the majority of IT technologists look to for direction.

    The new kid on the block is the CDO – Chief Digital Officer.  Some might say this role has been created due to a lack of leadership by CIOs who are too busy dealing with BAU to help the board ‘get’ and leverage technology.  Businesses have become frustrated with the time and cost of technology and yet many realise that there’s an even bigger technology wave coming.  The CDO is sometimes brought in to oversee the transition that this wave will drive.  Sometimes the CDO comes from a commercial background focusing on aspects of eCommerce and digital marketing. Sometimes they will be a change agent, pushing the organisation to take on the new challenges.  In all cases the role needs to work closely with other technology leaders to get the job done.

    It has been my pleasure to work with many and varied CIO’s, CDO’s and CTO’s over the years. Obviously each brings his or her own style to the role and above all else all have been strong leaders.
    So that’s my view of the differences between the roles. In all cases strong leadership, commercial business skills and board level stakeholder engagement skills are the key to success.  If you don’t have these, you can forget the technology.
    Got a different view? I’d love to hear it. Please add your comments below…