5 technology challenges that interfere with digital transformation
CIO and IT leaders love and hate it when technology terms catch on in the media and become overused nomenclature by executives. On the one hand, we love well-understood jargon because it establishes a context with business leaders around the need to invest in new technologies, change business processes, better understand emerging technologies, or innovate in competitive areas. On the other hand, some technical terms become overly generalized and eventually outdated to the point where it can easily detract from more mature and progressive ways of managing and winning with technology.
After speaking at many events this year and meeting hundreds of technology executives, I tested out the overall sentiments on which terms and concepts are dated and what ideas are replacing them. We also chatted about how these outdated concepts can doom and derail digital transformation programs.
1. Bimodal IT has evolved into a DevOps culture
Gartner introduced bimodal IT in 2014 as a way for organizations to manage the speed and agility of new technologies and application development (mode 2) versus the stability, compliance, and reliability large scale enterprise systems demanded (mode 1).
Bimodal IT might have been a necessary transition for large IT organizations to better deliver new customer experiences and begin the adoption of agile practices. But it didn’t take long for many to realize that digital disruption leaves no room for bimodal IT and that it is a recipe for disaster. Organizations that successfully transitioned to bimodal IT soon realized that it was not good enough to drive transformation and that they struggled to retain employees demoralized by being stuck supporting mode 1 platforms.
Progressive organizations that must align agile delivery with operational stability are electing to mature devops practices and culture. Practices like test automation, CI/CD, and centralized monitoring ensure that applications deploy reliably and incidents resolved quickly. The approach better unifies IT under a modern set of principles grounded in agile practices, site reliability, and automation rather than bimodal IT’s approach which splits IT into two operating models.
2. Lift and shift challenged by cloud architectures and economics
Migrating to the cloud without rethinking application architectures and addressing technical debt may seem appealing to CIOs that need to quickly achieve the cloud’s infrastructure agility and potential cost savings. Many CIOs supported by cloud vendors and systems integrators attempt lift and shift strategies with the belief that existing workloads can be migrated to the cloud quickly and then rearchitected over a longer timeframe.
But this strategy is ripe with stumbling blocks and risks depending on the network topology, security posture, and technical debt embodied in legacy applications and public cloud vendors like AWS suggest reconsidering this approach. Also, CIOs may find that legacy applications that ran on large-scale systems connected to massive storage arrays may cost more and perform poorer if migrated to the equivalent cloud architectures.
Cloud computing offers real benefits, but many are only attainable after rearchitecting applications and infrastructure and automating system configuration. CIOs should consider multiple paths to become cloud-optimized because assuming a lift and shift strategy can be costly and take a lot longer than forecasted.
3. Waterfall planning replaced by agile, continuous planning
While many organizations have adopted agile development and may have scaled the practice to multiple teams, longer-term strategic planning often remains driven by the CFO and aligned with financial reporting cycles. Budgets are submitted yearly, and most CIO must report progress and forecast deliverables on quarterly and sometimes more frequent intervals.
It’s one of the more significant disconnects between digital IT that’s transforming the business and iteratively adjusting priorities based on market and customer feedback. This divide between legacy and agile thinking can create significant organizational dysfunction as IT leaders attempt to recast agile backlogs with financial reporting cycles and requirements.
Alignment is possible and it requires scaling to an enterprise-wide agile transformation where planning is an ongoing, continuous practice. Agile planning is a process I detail in my book Driving Digital that requires agile teams to plan features and write stories every sprint in parallel to their work completing stories and fulfilling releases. When CIOs mature planning practices and establish reporting tools, they achieve a more reliable forecast that can more easily communicate status as required by financial reporting cycles.
4. Build versus buy is replaced by low code architectures
Many organizations still debate “build versus buy” when investing in new business applications. The paradigm has evolved somewhat as many businesses also consider SaaS options even though many of these platforms are highly configurable. Similarly, there are shades of grey to building applications as most proprietary software is developed using a mix of open source and commercial frameworks and libraries.
Still, there is an often-overlooked middle ground of low code, no code, and citizen development platforms that enable businesses to develop proprietary business applications, data integrations, analytics dashboards, and mobile experiences without having to take on the complexities of lower-level software development. These platforms not only enable rapid application delivery, but they often yield more maintainable, open applications that can be built and extended with either less skilled developers or business users that have technology skills.
5. Mobile-first bested by API and microservices first
When mobile usage became mainstream, app stores provided mechanisms to distribute mobile apps to end users, and mobile device management platforms enable IT to secure mobile devices, many developers and designers declared to develop applications for mobile first and web second. This directed software developers to optimize the application end user experience for smaller screens, lower bandwidth devices, and simplified navigation because mobile application usage surpassed PC web experiences.
That was back in 2014, and today, organizations must optimize applications for multiple devices and experiences and can do this using a myriad of approaches and development platforms. But the underlying assumption is that developers have already built APIs and ideally microservices first. APIs not only enable the development of device, workflow, and user persona specific applications, but they also allow application and data integrations. Developers and designers driving mobile-first without architecting APIs may box their organizations into a new legacy of monolithic applications.
Reading the tea leaves and knowing when to pivot IT practices
One of the hardest things for IT leaders to determine is to know which paradigms are essential, for how long, and what to do with investments developed on legacy constructs. If your organization has developed a successful mobile application on a monolithic architecture when does refactoring it to deliver APIs provide business value? Should CIO look to transition off dated practices like waterfall project management and bimodal IT to agile methods and devops culture? When should low platforms be considered instead of standardized software development practices?
Technology is evolving quickly, and entire industries are being disrupted. The simple answer is, the status quo is no longer an option for most businesses.
See how CenturyLink can help create the best IT strategy for your organization.
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.