Systems Integration v/s Management complexity

In response to my question why systems integration has not seen the same level of automation as systems management, Bill Higgins of IBM posted this response on Nick Carr's blog

"I think the short answer is because systems integration is a much harder problem than systems management. In the world of systems management we're talking about well-defined concepts like nodes, network addresses, memory, and storage. In the world of systems integration we're talking about amorphous concepts like "what constitutes a customer, an account, an order, etc." across different development teams, different intra-company lines of business, and across enterprises. Throw into this mix older systems whose source code is written in a legacy dialect that not too many people use anymore or has been lost entirely. Throw into this mix the constant desire to enhance or fix the applications that are the end points in the systems integration effort, resulting in an unstable base.

Now I know the normal IBM consultant response to this is "service-oriented architecture" is the answer, and, hype aside, it does help with some of these problems by hiding the underlying nastiness of custom applications behind well-defined service definitions. Now the big unstated assumption in the previous sentence was "well-defined service definition". Quality service definition takes real skill, and this is where you need an experienced designer - whether in Boston or Bangalore - and experienced designers don't grow on trees. If companies think that SOA is the way to go, they'll have to hire a few savvy service designers, whether as a regular employee or as a high-end consultant from firms like IBM Business Consulting Services, Accenture, Thoughtworks, etc.

Re: waiting again for stiffer competition from Bangalore. I don't really agree with your characterization since IBM's made sizable investments in our own services and R&D labs in lower-cost countries like Brazil, China, and India over the past 5-10 years."

My response:

Sorry, Bill, my view is much of systems integration is blocking and tackling. If it was not Accenture would not have grown with pyramids of young programmers or even PwC' that IBM acquired (where I was an SI myself). If you apply the 80/20 rule, with some variations there are reasonably common customer masters, vendor masters, charts of accounts etc. After thousands of SAP, Oracle and verticalized projects if IBM cannot find commonality and automate conversion scripts, test plans, interfaces - again 80% of project artifacts - it never will. The problem partly is the business model. IBM's SI/outsourcing groups do not think like its software group. They want to sell more bodies, not automation. If they allowed the same software team which is working on self-healing systems management to work on SI automation, I would be willing to bet they could develop significant labor saving tools.

As far as its offshore factories - IBM has definitely grown them...but few of their customers have seen the impact in lower pricing (at least in recent SI deals I have helped CIOs review). It has mostly gone to its margins.

So either through automation or through lower cost delivery, IBM can achieve significant SI productivity - the question is IBM (and other SIs) really ready to eat their services children?

Comments

[Tom Foydel]

Your observations on SIs is right on the money. I also agree that part of the problem is the SI business model and the need to always sell more bodies. But that cannot be the sole cause; in a fiercely competitive market no one SI has been able to stand out with better rates and more automation. That's a pretty sobering thought. So what else causes the SI lack of automation?

First there are several false assumptions that must be addressed. For example, since the legacy systems, the business model and the new application mix changes at every engagement the SI team and, more importantly, the client believe that they're 'special'. Throw in the belief that there business processes are also seen as different from everyone elses and you have enough fuel for a very long fire.

Second, there's this huge problem with human beings. Following the 80/20 rule, my experience tells me that 80% of the time on an engagement is the very wasteful effort required to get human beings moving forward in a new direction with a different drummer. Most of the actual work is done in 20% of the time. The significant fact here is that the employees of large companies are incredibly, poorly positioned for membership on a team that needs to perform some very radical IT surgery. I have found in my more recent travels that employees at small and medium sized companies, where change is commonplace and where everyone wears several hats, are more adaptable and flexible than large company employees.

Word of advice to CIOs: Before you start your project make sure to assemble a team with good work habits, little or no aversion to risk and ambiguity and a general disinclination toward passive rigidity. Rabble rousers are a good bet. In other words, train them to be SIs, and understand, and let them understand, that you are asking them to perform surgery, so no one should be surprised when you see a little blood.

[vinnie mirchandani]

Tom, agree with you about big companies and inertia. Also about change management....

but most workplans I see change mgt at 15-20% of effort. what I am talking about here is automation of repeatable testing, conversion, documentation, integration, training tasks. I can understand high level, complex tasks like change mgt being mostly manual (and even there I would argue SIs can prepare their exec sponsors better) but much of the rest can be automated...

[jl]

It is probably a good bet that there are savings to be made there - activities at the further end of the delivery cycle easily comprise 50% of the overall effort.

I suspect part of the problem is that productivity improvement in software industry have traditionally focused more on the front-end of the software lifecycle.

I tend to think it may be a cultural problem not own to SIs but to industry in general. The problem is as follows. Jobs at the further end of a system lifecycle tend to be more reactive. This translates into higher than the average accumulation of people with reactive working habits. This in turn means that the innovation you are calling for is much harder to achieve than innovation in the front-end of the process, where people tend to be less reactive.

If you want to change it design contracts in such a way that they give service supplier incentives to change that.

[vinnie mirchandani]

thanks for commenting/

On being "reactive". One productivity theme I have recommended to SIs in past was to set up shared service - testing, convesrion, training labs - where specialists could (mostly) remotely help on those phases across multiple projects. In the current mode the same team goes from planning to design to construction etc. The specialists would not be "reactive" to your point?