Perhaps wrongly, “DevOps” has been associated with “new” and “that thing for the cool kids” and the “hipster developers”. This is used both as an excuse and as a source of animosity against the movement. But more subtly, I sometimes observe IT departments that acknowledge DevOps as a thing, but claim it wont work for their applications. I always pause and ask: What are the applications they are referring to, and are they correct?

To an outsider, the development world pretty much all looks the same. There are about 20 million developers out there who write “code”, and to most they are just a mystery.  But the fact is that the development market can be dissected in so many ways, by platform, by language, by type of application, by use cases, etc. etc.  The number of permutations is endless and this can cause a lot of confusion when the market at large is using terminology to address the entire lot as a solitary unit.  One of the categories, type of application, is not trivial.  Modern applications consist mostly of mobile and web applications.  But there is another group of applications that might appear to the user as a mobile or web application, but go a little deeper, and they are not similar to modern applications at all. They are called line of business applications ( LOB ).

The LOB application is software that is tied to the daily operation of an organization such as content management, resources management, human resources etc. And while they can be surfaced in modern ways, the core of many of these applications were all developed in the days of agile, or even waterfall.  They are heavy, and seemingly immutable.

These LOB applications also have developers assigned to them.  But the type of work they do might seem foreign to those whose career advanced in the modern dev world.  They are not writing bottom up code.  Rather they are usually finding ways to surface data from these applications to users in better ways, or finding ways to connect one LOB to another.  And to them, delivering their application is not just what they have written it is their code, plus the code of the clunky old LOB, plus all the configurations it runs on.  This is where when someone talks about the concepts of continuous integration and delivery, or even automated QA the teams working with these applications might step back.

How can you expect someone to not only take all the code they have written to interact with the LOB, and the LOB itself, and make it look, feel, and smell like a DevOps type application?  Can LOB be rolled into DevOps?  What happens to LOBs in the DevOps world?

The opinions to this are somewhat vague, and dependent highly on your frame of reference.  It ranges from  the idea that LOBs will always live on an island of their own.  Or that they can be brought into the DevOps world.  Or, and finally my opinion, the LOB applications are themselves changing.  My particular frame of reference is as a former LOB developer turned into the modern dev world.

The problem with thinking that the LOB will never change is that it encourages the entrenchment of those teams, operations, and tools that build in the old way.  “Because we can’t join them lets just focus on what we do and do well”.  Thus it becomes an  excuse not improve on existing processes.  The net result is teams that will inevitably be caught in a lurch and have to adapt or die when the time comes.  Even the oldest enterprises will start to slowly bring on modern development for customer facing mobile and web applications.  That team will start to take over  as they demonstrate an ability to deliver that was before never thought possible.  Or seep into the traditional development teams.

I actually hold strongly the later two points of view.  I believe it is possible, albeit not terribly easy, to make LOBs and all the development around the LOB a fluid moving application that can be folded into DevOps processes and culture.  The key to this is the infrastructure.  Taking the LOB and putting it on infrastructure that can be provisioned quickly, and replicated.  So that the weight of these old systems does not hold back the release of the faster moving integration on top of them.  It’s not an easy thing, but certainly possible.

More interestingly is the fact that DevOps will not kill LOB.  Nor will LOB be on an island of it’s own.  LOB itself is going to change.  We already know that Microsoft for example is on bi-weekly sprints with Office365 which seeks to be THE business productivity app.  There is no doubt in my mind that in the near future they also will be embracing CI and CD.  And other applications like SAP, Dynamics NAV, etc. have moved to the cloud and on the path of DevOps.

What this means for the LOB organizations is that the development to work with these applications will have to move with them.  It implies a shift in the type of code, the way projects are formed and executed on, and the idea that you can deliver new functionality to your users faster with less fear.  So the teams who write code against these applications will suddenly be faced with the need to move from the client/server frameworks state of mind to REST.  And they will have the opportunity to release their integration in a way which was never before possible, and less dependent on where and how the LOB is configured.

The modernization of the LOB cannot come soon enough.  Organizations have suffered with extra long project cycles.  And taking an average of 6 months to go from integration code to the value that integration was supposed to provide.  In the future same, grown up applications, will still exist. But their value can be iterated several times in a day, versus long laborious projects and decision making processes for a single feature.

The biggest suppressor of this shift is the classic security and Cloud arguments, but that is for a later post.