Does IT matter?

It has been more than five years since Nick Carr made his prediction about IT becoming inconsequential. His argument was that IT will become so standardized that it would cease to have competitive advantage. IT would roughly follow a utility provider type of evolutionary path. Since then we have had great strides made in Cloud/Grid computing and it appears IT infrastructure is on its way to become standardised. Though I have made points about capacity issues here and here, except for one major incidence there is no other slip up yet. Many of components (the Intellectual Property of IT), sitting on top of IT infrastructure such as ERP, CRM, BPM too, are standardised to great degree. So are we really going to have a standardized IT environment and hence IT would not matter strategically?

IT was necessary and sufficient for competitive advantage till some time back. But with the standardisation and proliferation of IT, it has become necessary but no longer sufficient for competitive advantage. What that means is just investing in IT will not give companies the strategic advantages. It however does not mean that IT investments can be simply cut back. So enterprises are going for the more bang for the buck thru outsourcing of infrastructure and business as usual activities, and the utilising the savings for transformational initiatives.

The next focus area for competitive advantage will be driving out risk in implementing these standardised capabilities. The enterprise who could implement these capabilities faster and reliably, will get the advantage. In my opinion we are in middle of this phase. This is when enterprise architecture and project management practices are being defined and utilised to its fullest. Over a period, these implementation practices too will be common place.

Then there still may be opportunities to gain competitive advantages thru IT. Unless you believe there are limits to human mind and how much it can innovate - this is a distinct possibility. But the investments needed for such endeavours will be so high that, only outsourcers will invest in innovation and then charge enterprises differently thru differentiated offerings. Once that happens, the utility model will break down and enterprises will start moving to a non-utility model. It does not happen to utilities, because what utility companies distribute is indeed a commodity (well you cannot give more pure water to some of your consumers and charge more, can you?).

We are back to square one, aren't we?

That to me appears to be future of enterprise IT. So IT would continue to be of importance to enterprises, but enterprise would squeeze more value out of IT by using IT as shared utility rather than a captive resource. And this in the end it may result in IT becoming a captive resource again. Well this has happened in past. I wasn't born then, but I have heard stories about IBM Service Bureau and their shared services model.

Agile methods to kill outsourcing? I dont think so.

I hear an industry thought leader vigorously promoting Agile Methods. Nothing wrong with that. Only problem is there is an underlying thought which I dont agree with. The thought being Agile Methods can kill outsourcing. I would like to provide a logical argument to support my opposition to this thought.

For this we need to understand the philosophies behind getting a job done. The two prominent schools of thought are Adam Smith's one and Hammer-Champy one. Adam Smith had proposed a division of labour centric approach. To get any job done, the roles were clearly segregated. Each role needed to have specific skills. The other inputs apart from the skill that particular role needed, were provided by roles above it. The system was made up of a lot of specialists. Each specialist made only those decisions that were confined to its role and sought the decisions beyond their own role to be made outside, irrespective of its effect on the job at hand. (any government office anywhere in the world,is a good example of this approach, so are some public sector banks in India).

It worked fine for lot of years. But like any system, it developed abberations. The big bureaucrocy that these division of labour created started having bad effects on working of systems. Thats when Hammer-Champy came up with their revolutionary ideas on business process re-engineering. They proposed systems with generalists instead of specialists. These generalists were to be supported by enabling tools, such as improved IT systems, better collaboration tools such as fax, telephone, e-mails etc. They made multiple decisions, irresepctive of specilaization they had. They used enabling tools to make those decisions and in rare cases when they could not make those decisions, the job was transferred to actual specialist. This mode of getting job done has caught on and examples are everywhere to see. (Any private bank in India or anywhere in the world is an example of this, where bank teller supports all the functions from opening bank account to withdrawing cash).

This approach works, because it is only rarely one needs services of true specialist, as compared to, a generalist supported by enabling tools. One can see parallel between these and the way software development itself is evolving. The traditional SDLC with BDUF (big design upfront) follows a smithian approach. It expects a lot of specialists to collaborate to develop software. It needs a very heavy process support. That when you have ISO/CMM coming in.

Whereas Agile method appear to follow a Hammer-Champy approach to software development, with a slight variation. It relies on a multi-role specialist, instead of generalist. These multi-role specialists perform multiple roles themsalves. They are specialists in these multiple roles (either because of their training or experience or both), hence they dont need either a big process support or support from a lot of other specialists. The people who think this can kill outsourcing appear to base that conclusion on following logic. Since multi-role specilaists are in short supply and difficult to create, the outsourcers cannot have enough of them. Hence outsourcing will stop. Thats what the logic appears to be.

But as I had discussed in one of my previous posts about innovation shown by outsourcers, this one too can be handled innovatively. One can always replace the multi-role specialist with a generalist supported by enabling tools and achieve same result, as originally envisaged by Hammer-champy. One cannot beat support systems provided for such a genralist by large outsourcing organisations. The large outsourcing organisations have benefits of sharing humungous amount of knowledge, which even multi-role specialists dont have access to. So agile methods should not be viewed as just an antidote for outsourcing.

As outlined in one of my earlier posts, both these approaches (viz. agile and traditionla SDLC) are valid and are valuable in different contexts. The IT leaders need to choose appropriate methods based on their needs. As an Enterprise Architect, its my worry to provide appropriate governance controls in an uniform framework which works for both these approaches. It is of vital importance that I put these governance controls in place so that the roles make only those decisions they are empowered to make. Because it is very easy to confuse role boundaries in these two drastically different approaches.

No stereotyping please!

Long time ago I was a starry eyed (bit of exaggeration here) entrant into world of IT, when the IT revolution in India was about to begin. I was part of elite 'tools group', using translator technologies to build home grown tools for various projects that used to come our organisation's way. Amidst all those small projects a big depository from western world developed enough faith in us. It asked us to develop their complete software solution. The visionaries from my organisation did not do it in normal run-of-the-mill way. They decided to build home grown code generators, to insure consistent quality and created a factory model of development. I was one of the juniormost member of the team which built and maintained those tools.

Then while working for another project for large british telecom company (oops! could not hide the name), another visionary from my organisation did put this factory model in practice, in a geographically seperate way and delivered tremendous cost savings. That was the first truely offshored project done by my organisation. The tools we had developed helped a lot, in sending the requirements offshore - in model form and getting code back, to be tested onsite. We provided consistent quality and on time delivery. Needless to say it was a huge success and more business came our way. Mind you, it was much before Y2K made Indian outsourcers a big hit.

During my days in tools group I had good fortune to attend a seminar by Prof. K. V. Nori. His speciality is Translator Technologies and he taught at CMU. He exahaulted us, to 'Generate the generator!' Coming from compiler building background, it was natural for him to say 'Generate the generator!' But for me it was like 11th commandment. It captivated me. We did try to generate the generator. During my MasterCraft days, I convinced two of my senior colleagues and together we designed a language called 'specL'. 'specL' now has become the basis of our efforts on 'MOF Model to Text standard' under OMG's initiative. This is a testimony to the fact that we are not just cheap labour suppliers. We are good enough to be thought leaders within global IT.

It was not all cheap labour that helped us succeed in outsourcing business. It was also innovation, grit and determination. Thats why it pains me when somebody stereotypes Indian outsourcers as 'sub-optimal' or India as 'sub-optimal' location. Firstly, I dont like stereotyping and secondly its a wrong stereotype. One can have a position opposing outsourcing, offshoring, what have you. There are enough arguments against outsourcing, but please dont denigrate a group as sub-optimal.

And if I am going to be stereotyped anyway, then please include me in a group of "all men who are six feet tall, handsome, left handed, father of cute four year old". Then I may not feel as bad, being called sub-optimal. (Well, handsome and left handed are aspirational adjectives distant from reality).

Demand supply mismatch in IT shops

Demand management in enterprise IT shops is a perennial problem. The problem is actually of demand supply mismatch. There is a gap in the demand of qualified IT professional and supply, to serve the ever increasing IT demand from enterprises. This assertion is based on personal experience and I dont have any data right now. My observation is that, many big enterprises I have worked with, invariably have a big IT backlog.

Enterprises have tried various options, including outsourcing to tide over these issues. Outsourcing orgnisations have bigger resource pool of qualified professionals, and other enablers to help match demand. But there are situations where even outsourcing does not help in handling demand supply mismatch.

If lack of skilled professional for a particular skill is a reason for demand-supply mismatch,outsourcing can help here. Whereas,if lack of smoothening of demand for an entity within IT, making that entity a bottleneck is the reason for backlog then steady state outsourcing does not help. Which in turn gives rise to more of demand supply mismatch. Mind you this is not some fixed entity within IT shop. Any entity can be sucked into this situation based on its role within various IT projects that are going on. If your IT shop is organised on basis of SDLC roles then that entity can be pool of senior designers, system testers, even enterprise architects. Or if your IT shop is organised based on architetcural layers, then it can be front-end , business logic unit or database unit. Or if your IT shop is organised based on functional component then it can be any of the functional component.

It might so happen that large number of projects starting now, are going to hit that particular entity around the same time causing the demand surge.

What can be done to handle such situations?

One obvious solution that comes to mind, is dont start all the projects at once. But the problem is one cannot predict future demands and the situation can still arise even if you deliberately defer the projects, some other project might crop up in future which will have other imperatives (like business or regulatory) to start and cause the deamnd surge. Also the project budgeting and planning of IT shops happens periodically, which does not help. Well one cannot really have these activities aperiodically, so whats the solution?

Solution again is outsourcing. What we have seen earlier is a case of pro-active outsourcing, which does take care of some problems. For the problems arising out of demand surge, can be handled by re-active outsourcing. Outsourcing does offer an advantage, in terms of making IT expenditure 'variable cost', thus committing and withdrawing resources is easy. So IT shops can work out deals with outsourcing companies on a contingency basis, commiting some resources permanently to this continegency resource pool and an agreement to ramp this pool up in case of demand surge, ramp it down when demand ebbs. The advantage being

1. Outsourcing companies do have resource pool which can absorb these demand surges.
2. Outsourcing coupled with offshoring makes this otherwise dead investment, economically viable.

Outsourcing companies will have global knowledge, and can work out deals (billing rates, utilisation etc.) to their advantage. Its a win-win proposal.

And as an EA it makes me happy, because none of my strategic projects will be derailed because of demand-supply mismatch.