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
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
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.