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.

Evolution of an IT worker

IT folks, early in their life think, technology has solutions for all the ills within enterprise IT departments. There is technology solution for every problem. Something does not work, use that tool, automate this, do straight thru processing.

After a while they realizes no amount of technology is going to help unless there are proper processes. This is second stage of evolution, now with technology, processes are deemed necessary. Our IT pro is on process building spree. He may even build processes to define processes. And then after toying with technologies and processes for a while, he realizes it is not really having desired effect on enterprise IT scenario.

Thats when he realizes importance of people. Empowered people, who has bought into your ideas can make things happen. This is the next stage of evolution. Everything is achievable by right kind of people, we dont need any technology and/or processes.

And then when this people only approach fails miserably then our IT pro achieves his nirvana by recognizing that it is the judicious mix of right amount of technology, effective processes and efficient people is what makes IT work for an enterprise.

It is very important for an enterprise architect to bear in mind, this evolution. For he has to deal with folks at different level of evolution. He will have to work with many technology task masters, a few process pundits, fewer people's politicians and even fewer who have achieved IT nirvana. To keep delivering right enterprise arcitecture and sustain it, he has to take all these people on board and make use of their enthusiasm and leanings properly. Within themsalves they present right mix of people to define, build and govern an efficient enterprise architecture organisation.

Needless to say an enterprise architect must have reached this IT nirvana himself, to realize this.

Enterprise architect, solution architect, whats the difference?

I see most architecture practices have progression marked from solution Architect to enterprise architect.So what does it take to make this progression?Is it, for example, that once you have been solution architect for 'n' projects you are qualified to become enterprise architect? or is it if you have been solution architect for 'n' types of project hence you can become an enterprise architect. Or is it analogus to a caterpiller becoming a butterfly? Is there a moment of Zen, when a solution architect becomes enterprise architect? Can an enterprise architect descend to become a solution architect? Is it really a descent?
Let me attempt to answer these questions per my understanding.To me a solution architect provides a framework so that a sound solution can be designed and implemented. Since a solution typically spans multiple orgnisational entities within enterprise, the framework thus established, in a sense is valid for entire enterprise. So what value does an enterprise architect add, over and above this? An enterprise architect has to set up such a framework for entire enterprise (and not restricted to some entities within it). A solution architect has some freedom in setting a framework for his solution, based on overarching framework for enterprise. He can override enterprise wide framework, if his solution so demands, after following governance protocol. A solution architect can extend the framework and make it more granular. That is, enterprise wide framework will be more coarse grained, whereas solution level framework will be more fine grained. This solution level framework will have some reusable parts, which can be envisaged in any solution. Those should be moved to enterprise framework. Lifecycle changes happen in a solution level framework till the solution gets deployed and then the framework is frozen. Whereas an enterprise architect has to make sure his frameowrk is deployed rightly across various solutions and govern the changes or diversions from it. He also has to keep evolving organisation wide framework, all the time.
So from an Object Oriented viewpoint a Solution architect is a base class (appears counter-intuitive). An enterprise architect is a derived class. An instance of enterprise architect is also an instance of solution architect, but an instance of solution architect is not an instance of enterprise architect. Once a soluition architect develops the ability to genralize and abstract architecture concepts, he can progress to become an enterprise architect.