I talk to a lot of CIOs. I met with one in early May who oversees the IT operation of a $6 billion yearly entertainment-related company with about 7,000 employees. This top-notch exec was all about transforming a huge investment in existing IT infrastructure into a new dynamic, extensible and agile platform that would propel the business forward - not hold it back. This guy is busy figuring out how to keep a Boeing 777 up in the air while simultaneously re-fitting aircraft to make it best-in-class.
That's what IT should be all about.
But in some organizations, it's not. Either the message from the top gets lost as it percolates down through the IT organization, or the message from the top isn't the right one to begin with. Either way, for those unfortunate IT organizations, IT is a ball-and-chain that holds the enterprise back, rather than gives it the capability to move forward.
Great Software Comes from True Understanding
About 9 months ago, I wrote an article entitled "Great Software from Great Requirements: A Software Best Practice" on my personal blog. The gist of this article was that great software comes from a true understanding of the needs of the business.
Mr. David Chassels, CEO of UK-based software firm Procession, posted a rather lengthy comment (and series of questions) on this posting. My response to his comments and questions ended up being longer than the original article - at which point I decided "this might as well be a new article." Turns out, my response ended up morphing into TWO articles (I'll publish part 2 tomorrow).
I'd encourage you to read Mr. Chassels' comments - but as I started responding to him in train-of-thought style, and as the number of paragraphs kept growing, it occurred to me that David and I agreed on one key principle.
Why Does IT Exist, Anyways?
When you boil down what I said in my Requirements article and what Mr. Chassels said in his commentary, it comes down to a couple of very simple and common-sense things:
- The very reason IT exists is to support the people who do "business things"
- Anything else that IT does (apart from what is necessary to accomplish #1 above) represents deviation from the "golden path", and is bad.
Focus on the Business
During my discussion earlier this week with the aforementioned CIO, he discussed his major IT challenges. Every single IT priority he brought up was business-related. Things like being able to leverage every bit of new technology to capture new customers, integrating new corporate (i.e., company) acquisitions far faster than before. These are business problems he's solving. His "customer" is the business. He "gets it".
Not even once did he mention ANYTHING along the lines of "I want to drive SOA adoption throughout IT" - or anything that would indicate that he views IT as the customer.
It's not that I dislike SOA. Not at all! I rather like the concept. No hate mail please from the SOA contingent.
I simply wanted to make the point that this particular executive made it clear that his job was to solve business problems - in the best possible way for his particular organization. Other (as in "not this one") executives that I've met with have fallen down that slippery technology slope where they confuse technology goals and initiatives (like SOA adoption) with business needs.
IT Culture Dysfunction
When execs fall down this slippery technology slope, something bad happens: the customer for IT becomes IT - not the "business".
In many such IT organizations, the message percolates down in a powerful fashion from the top through to the directors, managers, architects and developers.
You see an distinct disdain arise in the IT group for "stupid business people." Architects and developers become king. Users are fearful of IT. Lots of application design meetings contain discussions along the lines of "that's a stupid thing to do, we know better." IT ends up doing what IT wants to do - not what the business needs IT to do.
As much as I'm impressed by the intelligence and capabilities of RedMonk (a technology analyst firm), I'm in violent disagreement with one of their key tenets: "We believe that developers are the most important constituency in technology." I believe that the business users are the most important constituency. In pretty much every case, I always come down on the side of the customer.
Getting Back to Chassels' Comments
Mr. Chassels' elegantly wrote about the need to change the way that business software is developed - so that the business person is "in the driving seat", as he put it.
I agree.
As of about a month ago, I started working for Dell as a Software Strategy Director, so I no longer work for my own company doing paid advisory services. However, when I used to do such things, most of the time my recommendations would resemble the following:
- Figure out the business needs (from the business people)
- Focus on "Assembly" rather than "Development" whenever possible. Acquire components, turn existing software investments into components. Connect them together, re-use them. Turn them into a flexible asset.
- Find SaaS software that you can subscribe to that does what you need. If you can't find SaaS Software, find a "software appliance" that does what you need. If you can't find an Appliance, find off-the-shelf On-Premises software to license.
- Connect your existing applications and your new ones (SaaS, Appliance, On-Prem) with "Next-Gen" off-the-shelf Integration solutions that are Cloud-managed like Boomi, InformaticaCloud, Snaplogic, MuleSoft Mule iON, etc., so you can automate your business processes across the multiple application systems.
- Find creative ways to "fill in the gaps" between what you bought/subscribed to and what you need. Create Mashups, extend the SaaS/On-Prem applications, leverage the Integration platform you licensed.
- Do custom development as a last resort. Such custom development will always be necessary, but don't ever go there first. That applies not only for applications, but also (and even more so) for integration.
Procedural vs. Declarative
Mr. Chassels tosses in some quotes from Bill Gates on Procedural vs. Declarative application development. I'm not about to get into a debate with Bill Gates on this topic.
I'm simply going to put "declarative" application development methods in the same bucket that I put off-the-shelf applications as well as off-the-shelf integration stacks.
What I mean by that is that all of the tools I just mentioned serve to minimize the chasm that has traditionally existed between the business user and the IT solution to the business users' problems.
So think Chassels' got it right when he stated that innovative companies "tackle the 'interpretation gap' between IT and business...and business people are becoming the decision makers on IT spend with informed knowledge."
One Area of Strong Disagreement
Chassels' mentioned that "software remains a bit of a mess". I respectfully disagree.
Software remains a LOT of a mess. A really great big giant mess.
The Legacy Application Problem
Sure, the state of NEWLY deployed software is better than ever. But the vast majority of deployed software out there isn't new.
An astonishing amount of pre-Y2K software remains. Great big expanses of old Client/Server code written PowerBuilder and other tools now considered ancient. First generation Web applications on platforms like ColdFusion.
Ancient ERP systems so heavily customized that nobody knows how they work anymore. Mountains of Mainframe and AS/400 application in COBOL, RPG, Natural, etc.
These applications are monolithic, gigantic, brittle, expensive to maintain, nearly impossible to change. They are the anti-thesis of "agile". They represent an enormous ball-and-chain to the enterprise.
They soak up huge amounts of IT budget, leaving little left over for supporting new business initiatives. Almost all large organizations have this problem to one degree or another. These legacy applications are in dire need of "modernization" - broken up into re-usable "rationalized" re-usable components that can be linked together, integrated with other systems via a modern Integration stack.
Organizations will never be able to maximize their ability to address the needs of the business users until they figure out a way to deal with this issue. For some larger organizations, this will take hundreds of millions of dollars (or more) and 3,4,5 or even 10 years.
The issue of legacy applications in need of modernization is the single largest barrier in most large companies to IT truly being able to become an agile, competitive asset to the business.
Legacy Application Modernization - Huge Step Forward
Legacy Application Modernization brings IT and Business Users closer together. Legacy Application Modernization is a huge step forward for large IT shops, and truly helps companies tackle that "interpretation gap", and puts business users in the drivers seat.
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
