Evolving IT architectures: It can be hard

This is the second in a series of posts that delves deeper into the questions that IDC’s Mary Johnston Turner and Gary Chen considered in a recent IDC Analyst Connection. The second question asked:

What are the typical challenges that organizations need to address as part of this evolution [to IT that at least includes a strong cloud-native component]?

In their response, Mary and Gary note the challenges associated with “having to integrate with conventional systems can slow down the entire process and work against the agile, continuous integration/continuous delivery methodologies these DevOps teams often employ.” At the same time, this integration can’t be dispensed with; they add that “IDC expects cloud-native and conventional applications to become more connected and interdependent over time.” (Check out the recent webinar discussing this and other topics: Next-generation IT strategies: Mixing conventional and cloud-native infrastructure--based on a recent IDC survey.)

So, where does that leave us? Is traditional IT destined to just be a boat anchor when it’s integrated with cloud-native IT? (And make no mistake, integration is an inevitability.)

Variations of this question also come up as part of critiques to the bimodal or two-speed IT idea.

Bimodal refers to having one group of IT assets and operational approaches that are focused primarily on reliability and stability while another group of assets prioritize innovation and speed. The main point of the bimodal argument is that trying to split the difference between stability and speed will result in IT that is neither stable enough nor nimble enough for the needs of the business. “Avoid the timid middle” is the catchphrase sometimes associated with this point.

A critique I sometimes hear is that the bimodal model therefore serves as a license for CIOs unable or unwilling to transform their entire infrastructure and application portfolio by telling them that it’s OK to ignore the legacy stuff. The problem, one of them anyway, is that said legacy IT will drag down any new initiatives for both organizational and technical reasons. No one wants to work on legacy. And integrations will be tough.

I’d argue that this argument misstates an important element of bimodal IT but also highlights some of the key challenges that have to be overcome in order to evolve IT for a more digital age.

The misstatement lies in the word “legacy” which carries something of a derogatory flavor. In fact, in the bimodal model, traditional IT is neither something to be ignored nor wholesale replaced. Rather it’s IT to be modernized when and where appropriate. This may include infrastructure updates using modern x86 servers, Red Hat Enterprise Linux, and JBoss Enterprise Application Platform. It may include introducing agile and DevOps approaches for targeted application projects. It may include exposing existing data sources and workflows using contemporary business rules management and messaging systems.

As such work progresses, the traditional IT systems will be better able to integrate with new applications and cloud-native infrastructure as well as operating more efficiently.

With respect to challenges, the first is that traditional IT must, in fact, modernize over time. This will often involve picking the right (or at least right enough) focused projects that create wins but which aren’t so large and expensive that they cut off the resources needed for new innovation-focused initiatives.

The second challenge is managing the cultural and organizational aspects of having differing priorities (stability and speed) for traditional and cloud-native environments. One way in which projects needing to move fast and do things in new ways have been dealt with in a range of industries is through creating “skunkworks” groups. When it works, it’s effective. (Kelly Johnson’s team at Lockheed is a famous historical example from the aerospace industry.) At the same time, however, gaining the full advantages of faster and more iterative development practices, for example, ultimately requires evolving those values and that culture beyond a small group--and, indeed, beyond the IT organization into the lines of business.

Finally, a third challenge is to integrate different modes of IT in a way that the needed data and events can flow where they are needed without creating tight interdependencies. In many respects, such an approach reflects modern distributed application design more broadly. Encapsulating services and exposing data and functions through APIs allow implementation changes to take place autonomously. Picking the right functional boundaries for such services is often not obvious. However, such a design allows different parts of the IT infrastructure to evolve at different paces and using different technology sets.

Read part 1 of the series: Does cloud-native have to mean all in?