Potential challenges of adopting bimodal IT


Gartner described bimodal IT as "the need to operate the safe and reliable traditional IT systems while cultivating a more fluid IT that takes advantage of the digital world and its continuous flow from moment to moment". IT organisations are investigating the opportunities presented by disruptive techniques and technologies such as agile and devops, and so it comes as no surprise that the option to adopt bimodal IT is also explored. 

In this post, I attempt to outline some potential challenges and questions for an organisation if it adopts a bimodal (twin speed) IT model. I shall label the two speeds: fluid IT and traditional IT. The potential challenges are presented from the following perspectives: Customer, Culture, People, Process, and Technology.

Customer

Fluid IT customers may have different customer experiences with IT than the other lines of business who use traditional IT. It may also be inconsistent depending on which IT team they interact with.

Success of fluid IT may breed a new set of challenges. There is a growing trend for non-IT business units to run their own IT. Connelly (2014) states currently 38% of IT spend outside of IT, growing to 50% by 2017 which may appear an attractive proposition to the business if traditional IT cannot manage expectations. 

Inadequate stakeholder management (e.g. regulatory and legislative bodies) may present unexpected challenges if they are not confident that the IT organisation cannot effectively deliver on both speeds. 

Culture

There could be potential tension between the IT teams who work at the different speeds. To be successful, an organisation IT may need to ensure that the right people are assigned to the right speed. I suggest the encouragement of a Continuous Delivery/Agile aligned culture across all IT. Typically the culture should balance the need for faster value delivery within the business’s risk appetite.

Does IT and business encourage a ‘safe to fail’ environment? Are staff and leaders willing to share their experiences, including failures or lessons learnt across both speeds?

Change fatigue and aversion to change. Does the organisation have a healthy success rate with past change initiatives? Is there a sense of urgency or need to change and adopt both modes of IT?


People

Fluid IT may need IT people with new perspectives and skill sets. Will these skills be acquired externally or developed with the existing staff?

Will fluid IT have dedicated resources or shared resourcing with traditional IT? Shared resources may be prioritised to other work or constantly challenged with other priorities, inducing context switching and as a result, induce poor delivery from one or both modes of IT.

I suggest appropriate time allocation for staff to learn and develop in the new IT operating model. Not just for the fluid IT staff but for traditional IT as well.


Process

For an IT department to cater for two (2) operating modes, effort may be required for:
  • ·         defining clear roles & responsibilities;
  • ·         defining clear scope of services/applications; and
  • ·         defining the services/applications’ risk appetite and desired level of agility, security, availability, reliability including the business desire of change/stability.

A low level of maturity in continuous delivery/agile may present more challenges.

Does the organisation use third parties to support their applications or their underpinning infrastructure? If so, the third parties become an important stakeholder in the transition and implementation.

Measuring success may require a new set of metrics, potentially two sets. 


Technology

Will an organisation be using public cloud computing to underpin fluid IT? If so, another set of potential challenges may arise which are well covered in other forums/blogs.

Are the fluid IT applications/products integrating with the traditional IT platforms? How will these integration points be managed?

Potential need for other tools if the traditional IT tool sets do not support fluid IT model. They may require tools to support the continuous delivery life cycle including:
  • ·         Configuration management
  • ·         Cloud infrastructure management
  • ·         Version control
  • ·         Code review
  • ·         Continuous integration
  • ·         Team collaboration
  • ·         Request or Issue management, and
  • ·         Monitoring.


In this post, I have attempted to provide some potential challenges & considerations that an IT organisation may encounter if it adopts bimodal IT. I am not against bimodal IT, and hope to reduce the potential negative impact of it by early identification of potential blockers to success.  



References:
Gartner. (2014).Retrieved February 22, 2015 from http://gartnernews.com/how-to-innovate-with-bimodal-it/ 
Connelly. B. (2014). Retrieved February 22, 2015 from http://www.cio.com.au/article/556790/gartner-says-38-spend-already-outside-it               
               

                


Comments

Post a Comment

Popular posts from this blog

Continuous Improvement with Agile, ITIL & Lean.

In this article, I'll lightly explore continuous improvement using Agile, ITIL and Lean. Continuous improvement with Agile Agile is more than just a modern software development process, it is having an agile mindset (or to demonstrate agility for your customers' dynamic needs). While the Agile Manifesto outlines four (4) values, it is principle 12 that highlights Agile's focus on continuous improvement. Principle 12 states " At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly " (Principles behind the Agile Manifesto, n.d.).  Retrospectives are one instrument that Agile provides to check the health of your service delivery and identify improvement opportunities. Held at the end of a sprint (time boxed interval of enhanced product delivery), the retrospective gives stakeholders an opportunity to reflect on: - what went well for the sprint (to repeat it again), - what didn't go well (to ...
Read more

Using the Lean Canvas for an IT solution proof of concept

Image
I was assisting a client with sourcing some new IT solutions. For one particular IT need, the client had shortlisted a potential solution with a trusted vendor but they needed to explore the potential solution further to understand its capabilities in more detail. They were unclear as to whether they should directly source with this vendor or go to the wider market (with a Request for Proposal (RFP)) to address this particular need. Further to this, it was unclear how long this project would run for so it was important to understand the time and effort that may be involved without consuming too many resources.  The client was seeking to employ a specific approach for this potential solution, where a “fail fast” lean Proof of Concept (PoC) would be conducted to rapidly test whether the potential solution was fit for purpose without spending unnecessary time and effort required to conduct a RFP. To start, we confirmed the following principles to guide the PoC: Do no...
Read more

Applying Scaled Agile Framework (SAFe) to IT Service Management and IT Operations

Image
As an IT Service Management (ITSM) leader with a strong preference to leveraging Agile, Scrum and Lean (including LeanIT) to effectively and efficiently deliver IT operations, I became quite interested in the concept of the Scaled Agile Framework by Dean Leffingwell and his associates. The Scaled Agile Framework ® (pronounced SAFe™) is “an interactive knowledge base for implementing agile practices at enterprise scale”. In the SAFe website, Leffingwell states that “this model of agile adoption has been elaborated primarily in my books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and my scalingsoftwareagilityblog.com . It has been successfully applied in programs of only 50-100 people, and in enterprises employing thousands of software developers.” SAFe has four (4) core values: 1. Code Quality (because you can’t scale crappy code); 2. Program ...
Read more