RFI and RFP

At this year`s IASA Conference, I sat on a panel discussing legacy modernization.  Nothing new there, but a fellow panelist made a comment about the state of the IT department that got me thinking about . . . the state of the universe.

In the 1950s a great debate raged in physics and astronomy about the state and fate of the universe.  The default position, supported by Albert Einstein, the colossus of 20th century physics, was that the universe was in a steady state. 

Recent evidence cited by Edwin Hubble (for whom the telescope is named) showed that the universe was expanding and doing so rapidly.  The genesis of this expansion, it was posited was the Big Bang, surely the most stupendously counter-intuitive idea since the notion of a spherical planet earth. 

Obvious questions followed: If the universe is expanding, what is it expanding into?  If the expansion was fueled by the Big Bang why is it still happening 14 billion years later? When will the remaining energy powering the expansion be overwhelmed by gravitational attraction causing the universe to first stabilize and then contract in on itself in a Big Collapse?  What is the fate of the universe?  How long have we got? (Let me reassure you there is plenty time enough to finish that seemingly interminable legacy replacement project.) 

But in the meantime, and more comfortably, let`s get back to IASA and the state and fate of the IT department.  Similar questions arise. Is IT expanding? Is it contracting? What is its future?  And (one question only philosophers ask about the universe) what is ITs function and purpose?

In the Beginning

The IT department has evolved in some obvious ways.  When I started in IT (about seven billion years ago in cosmic space/time) the IT shop was essentially a group of coders who wrote tactical, in-house systems.  The different disciplines of project management, business analysis, system design, development, quality assurance, and delivery were not well defined or differentiated. 

This was “back in the day” when a dilatant with a degree in psychology and philosophy could score a real job and learn some useful and marketable skills. This was before the rise of the barista as the liberal arts graduate career of choice.  There were few if any “package” software vendors so a company had to build its own systems.   

Look around your IT department and you will see, just as cosmologists discovered with background radiation, remnants of those days; for example that addled looking, semi-retired hippy dude in the corner who is the only guy who knows how stat reporting works.

Packages 

About 35 years ago, a new and increasingly important part of the IT universe come into being and ultimately changed what and how we do insurance IT—package software vendors.  The early vendors were commonly born from insurance IT departments that housed a rogue entrepreneur (there were few places other than the regular work force for entrepreneurs to earn a living at the time; there was not “an app for that”) with the drive and vision to convince management to spin off a new venture. 

The early insurance software vendors came from inside the industry and knew insurance first and software second.  These vendors took in-house written core insurance assets and generalized them into commercial offerings which were rapidly adopted by insurance IT departments as superior and cost-effective alternatives to building core systems in-house.  In a short time all but the largest IT shops evolved from being mostly coders to being system implementers and system integrators. 

Unfortunately, the implementation portion of the task often involved significant base-code modification, which lea to major maintenance and upgrade problems.  In terms of integration, it was still necessary to write the code that knit these new systems into the legacy environment for data and function sharing.

Configuration and Wide Adoption

The next major evolutionary turn happened about 10 to 15 years ago with the rise of configurable software.  Configurable software addressed the issue of how to more “easily” bridge the delta between the package`s base business functionality and what the insurer required.  This further decreased the pure programming role of the IT shop in favor of a more hybrid business analyst/configurator type of function. 

Over the next 10 years the promise of configuration, which is a highly-customized solution based on a package implementation, began to attract the largest insurance carriers leading to a recent and ongoing, industry-wide adoption of third-party software solutions as the default acquisition method for core insurance software.

System Integrators

A parallel evolution happened with the appearance in the marketplace of system integrators; companies dedicated to the delivery of a broad range of IT services from program management through business analysis, configuration and programming, integration, testing, deployment, and maintenance. 

Until recently, these service vendors worked mostly for large insurance carriers on very large projects.  But today they have become commonplace participants in legacy replacement projects for lower tier carriers, providing specialist skills in vendor software as well as structured offerings for specific project components such as QA or conversion.

The IT Shop Today

And this, if you will, is where this story started.  With a CIO from a smallish regional carrier saying, “If you are going to succeed at legacy replacement it`s not just the software, you have to choose a suitable SI partner.”  Which raises the obvious question: What the heck is the IT department actually doing anymore? 

IT doesn`t code the system anymore, the software vendor does that.  Now, increasingly, IT no longer does the configuration, implementation or integration of the new system, the SI does that, or at least the majority of it.  IT departments aren`t getting any smaller as measured by headcount and budget, in fact they are growing slowly, and yet their purpose appears to be shrinking in significant ways.

Several trends explain this.  The first, as we have noted often in the past, is the sheer size and complexity of core system modernization projects.  An IT shop that has been doing mostly maintenance for 20 years has neither the skills nor the head count to pull off such an undertaking.  We all become what we repeatedly do. 

Second, the insurance world, like the rest of the world, is an increasingly complicated place.  The IT department is dealing with issues and supports applications that didn`t exist 20 years ago.  The list is obvious, just look at the headlines in the trade press.  Security.  Cloud computing. The Internet of all things.  Social media.  Mobile apps.  Big data.  In this regard the remit of the IT department has expanded enormously and continues to do so. 

Third there is specialization. There are vendors that specialize in core systems development and delivery.  There are systems integrators that specialize in the myriad aspects of system implementation.  There are advisory firms like my company, CastleBay Consulting, that specialize in helping insurance companies select those software vendors and SIs. 

Specialization is generally a good thing and tends to lead to higher quality results.   But what does the IT department specialize in and what should it specialize in?  Currently, the IT department must at least have special knowledge of the business and its wants and needs, and knowledge of the legacy systems and their data.  Increasingly, as we have seen, the IT department also needs to become a specialist at selecting and orchestrating the vendors, which are retained for their specialist skills, knowledge, and products.  There is, of course, and always will be, the generalist role of doing everything else that falls within the purview of IT.  

The IT Shop Tomorrow

What is the fate of the IT department?  The industry had a major flirtation with IT outsourcing about 30 years ago, which had a lot of disappointing and unfortunate results, so it`s unlikely that we will try that again, at least in that form, for a while.   Given the growing recognition of the central role of IT in any significant business initiative, it`s hard to see an informed CEO trying to get rid of IT for the narrow purpose of saving money. 

So if IT is to persist what will it look like in the coming decade?  The trends we see now will probably continue.  Internal IT will always have internal company business and technical knowledge.  In combination with internal knowledge I think the IT differentiator in the future will be the selector/orchestrator role mentioned above.   In a world of specialization no other entity is better placed to know the business needs and how best to source them. 

There should also be a structural shift within IT.  If configurable systems deliver on their promise, maintenance, as a portion of the IT budget, should fall significantly, presumably releasing funds for other more innovative uses.  Fewer staff members will be shackled to system maintenance.  More focus will be placed on data-based initiatives as IT moves from “keeping the trains running” to becoming an information generator, aggregator, and broker.

The Prognosis for all Things?

 Planet Earth will continue to spin around her Sun for longer than any of us can possibly imagine.  Our solar system will persist as a pin-point within the vast and beautiful Milky Way, our spiral galaxy home.  The Milky Way will continue to pin-wheel away from its neighboring galaxies into whatever it is expanding into.  These things we know.  But all those legacy replacement projects and the IT departments that support them?  Who`s to say?