By: Dr.Thomas J Mowbray Chairman, iCMG

About 75 percent of the IT profession works in service and support roles, including IT outsourcing. If you're reading this article, chances are more than likely, you are part of the IT services sector too. I believe that the kind of work that you are doing today is going to change in the near future. Either that or a lot of work will go elsewhere. Maybe your job too.

What's known about IT services is that it's locked into a certain phase of the technology cycle. If you're working on the newer technologies, services content is very high (i.e. the early adopters phase). Profitability can be high. As the technology matures, services content decreases (i.e. the early mainstream phase). Eventually most services content is engineered away, into shrinkwrap products (i.e the late mainstream phase). Long after technologies reach their heyday, service content increases again, because the original manufacturers no longer provide support (i.e. the laggards phase).

The Y2K challenge has created a last gasp to keep old systems alive. Unfortunately, many IT services companies are stuck in the laggards phase, working with the oldest technologies, e.g. COBOL, assembler, dumb terminals and so forth. Y2K is keeping the laggard services market alive, at least temporarily.

Most experts have been claiming that the IT market will change dramatically after Y2K. Obviously, after year 2000, all the Y2K upgrade work will vanish. After the Y2K transition, I believe that many of the old COBOL and other laggard systems will be scrapped. Goodbye dumb terminals and assembler programming!!!

Also it is widely believed that much or new system development is being held back until after Y2K. In fact, it's an official government policy (for US Federal Systems) that no new systems development funds can be spent until after Y2K problems have been completely resolved. The post Y2K market shift will create many new-start projects in newer technologies, e.g. components. And IT services for laggard technologies will be greatly reduced. If your job is heavily dependent on laggard technologies you had better plan for this transition. This is your Y2K+1 crisis in IT services. And it will be significant.

Why objects and components? Every new system development project that we've encountered is headed for the object-oriented mainstream. Companies take a long agonizing look at commercial IT and see that everything currently seems to be based upon objects, e.g. C++, Java, CORBA, etc.. It's all about objects. At least at first inspection.

But components are a superset of objects. To do components you use OO languages and tools in smart ways. Components are a more sophisticated way of thinking about and working with objects. The straightforward "transition to object-orientation" (OO) has largely been discredited by software experts. Unfortunately, that's what many companies appear to be doing. Look at the latest software books, nobody is preaching pure OO anymore. The object paradigm has been around for more than 20 years and it's shortcomings are very well known. We know where the OO pitfalls and antipatterns are. We wrote the book. And we're not the only ones who are enlightened about OO.

There's been an intellectual revolution in software against pure OO, and today's educated approach to software is Component Based Development (CBD). In fact, in software conferences since 1996, it's been widely acknowledged that OO-ness is not equivalent to good-ness. And the whole field of design patterns (as well as a new found interest in software architecture) are reactions to the fundamental weaknesses of OO. And that's why patterns and software architecture play a large role in components too. To circumvent the well-known problems of OO, you have to think in terms of components. Whereas objects are units of instantiation (too small for plug and playreuse), components are your units of software deployment - ideally suited for reuse. From the beginning it's been said that OO is not worthwhile without reuse. In many ways, OO failed to deliver it's promises. Widespread reuse, in corporate development, never happened.

And we believe that reuse will never happen, for corporate development. But fortunately, real-world reuse does happen, quite frequently. We just call it by a different name: "software products." Software products comprise reused software, redeployed across dozens or thousands of customers. But what is a software product? All software is automation of business processes in one form or another. In this case, a software product includes the automation of IT services. The lucrative kind of IT services that occur in the early adopters phase. It's all about IT services, in one form or another: products are a converted form of services, coded in software.

In any case, a funny thing happened on the way to components. Corporate development was nearly 100 percent in-house when OO started, and now it's down around 45 percent in-house programming. The other 55 percent is now going to outside IT services, e.g. consulting and outsourcing. In other words, the business has come towards what you probably do, IT services. And it's increasing in your direction, year by year. In fact, Computer world (13-Oct-1999 issue) states that the US economy could easily grow IT services by another $105.5 billion if we could find a way to perform the IT services that need doing.

We consider the transition to software components to be an imperative. For survival. Because we foresee some massive changes in the industry. Companies that are comfortably dependent upon work with laggard technologies are overdue for a shakeout. Y2K work that is keeping legacy systems operational is going away. And with the disappearing Y2K market, so are many laggard technology systems, gone forever, with new technology systems business coming on strongly in Y2K, Y2K+1 and beyond.

To be successful and Y2K+ you can't be satisfied with old-fashioned dumb OO. It's just not good enough, unless you're willing to repeat the 80 percent plus of unsuccessful projects with plain OO and previous software technologies. OO is a done deal, it's here in today's software market. It's what's sold and supported by software vendors. Instead of dumb OO, what's needed is smart OO, that's what components represent. That's what you and your company should learn now. And what you will be doing in this market. Assuming you survive the Y2K+1 crisis in IT services.