Columns
Componentware turns the corner
Can components carry forward the torch of object technology? That question is central to recent research by London-based Ovum Ltd. ADT Editor Mike Bucken talked over lunch with the very knowledgeable Neil Ward-Dutton, Ovum senior consultant, not long after Ward-Dutton had completed the report entitled Componetware: Building it, buying it, selling it.
Q. Objects have been discussed for years. Now the word is components. How are components better than objects?
A. The great advance in component technology is that it enables people to achieve many of the benefits of object technology, but it does not dictate or delay any particular type of development approach. I'm sure you're aware of the history of object technology and how it came to be. The interesting thing was that component technology and object technology originally had the same foundation. A guy called David Parnas, in 1972, came up with the idea to build around a principle called data hiding -- to basically design software in such a way as to create a set of modules. [He was] essentially saying 'work out what it is, then work out what kind of things you want to do with it, and then encapsulate that data with a set of functions that operate on the data.' You'll find that if you do this, the software is a lot easier to customize and more easily readable by people who haven't seen the software before. It tends to reflect the real world more. This is pretty much where object and component technology diverge.
When people started implementing the principles of object technology in programming languages, they started coming up with all kinds of extra stuff that you might want to do to make it easier to write more sophisticated software. They came out with things like polymorphism and inheritance. The problem was that using these OO program languages meant you could get the benefits of object technology -- that is more modular software -- but the problem was that you had to learn one of these OO languages, which have never been particularly easy to learn.
Component technology is just the packaging technology that was originally proposed by David Parnas. It's a way of packaging units or modules of software that makes them such that they could form some particular kind of plug standard. So, it's easy to take a module written by Person A and give it to Person B and they could just use it, much like you would assemble a hi-fi system out of components. The packaging technology is not predicated on any particular development approach. What that means is that you can get the benefits of object technology without having to learn a nasty object-oriented programming language. That is the chief benefit of component technology. You get the gain of OO without the pain.
What are the elements that are carrying components forward today?
There are a number of things. The first thing is that we have a market where there are competing standards. For a while, there was a component-plug standard available, what we call a component architecture, and that was COM from Microsoft. And a small market grew up out of GUI-type client-side components -- things like calendars and on-screen widgets. Now we have more than one standard, so we actually have competition in the market.
And the other thing is that now there is a killer app and that is the bridging of Web and legacy. We think the big market development in component-based software is going to be server-based software that links the sort of embryonic corporate Web presence to the vast islands of mainframe functionality that run the core business process of any large organization. Component technology is reaching a critical mass at the same time people are encountering this problem. All of the mainframe and infrastructure vendors we have spoken to are positioning themselves to take advantage of this clear opportunity, which is bridging.
Won't the battle between COM, Corba and JavaBeans hurt it?
No, I think it's very beneficial. The research that we just concluded points to it in immediate terms being completely irrelevant. What's going to happen is that software vendors are going to basically position themselves to lock you at higher levels of the component architecture, whether that's COM or Corba or JavaBeans.
What's interesting is that the vendors are trumpeting the openness of their platforms [and] architectures, and saying they are architecture-neutral. They are, in fact, locking-in at a higher level. It's the platform or application server that will lock you in. We don't believe that the battle between the different standards is harming the competitive market. We actually think it's a beneficial thing -- there is a lot of leap-frogging going on, which is advancing the technology. This has to be to the benefit of end users.
Do you suggest one over the other?
No, we believe the decision people have to make is partnering with an infrastructure provider -- that is someone who can provide the services that you require to run your server-based component systems, which are going to help you integrate back-end systems into the Web. Vendors like IBM, Oracle, Microsoft, Sybase, Inprise. The only vendor who is taking a stand is, of course, Microsoft, because Microsoft is going to support COM. If your planning on working only with NT, I would suggest Microsoft anyway. And despite the fact that [Microsoft says that] COM is going to be delivered everywhere, it is only the plug starter that is going to be delivered everywhere. Microsoft's plan is to put COM everywhere to enable them to persuade people to migrate systems from other operating systems onto NT. I think the strategic position is going to be choosing a provider. It doesn't have anything to do with component architecture; so, no, we don't make a stand on one over the other.
There are different kinds of architectures for different people, which is as you would suspect, I suppose. Looking at IBM, Oracle, Microsoft and Sybase, there are two distinct kinds of architecture approaches taken. Microsoft and Sybase have taken the approach where the difference revolves around how the vendors treat the database, which is interesting. Both Microsoft and Sybase seem to be taking the approach, if you look at the architectures they offer, that the database is something over there. It's a back-room technology that you can use to get data in and out.
IBM and Oracle actually take an alternative approach where they view the database as providing just another service to the architecture. So, just as you have a security service, an authorization service and directory services, you also have a persistence service and a transaction service. In IBM's case, those are basically provided by technology that was taken from the DB2 Universal database. In Oracle's case, they used the services provided by the DB kernel itself and its architecture. There are two fundamentally different philosophies there. I happen to think from a technical perspective that the IBM/Oracle point of view is more robust from a long-term approach, but it's going to appeal to a different type of person.
What we're predicting in our research is that the first wave of component adoption is going to fall into the hands of Microsoft and Sybase, despite the fact that we believe the products are technically inferior. This is because both of those vendors are positioning their architectures as a way of taking the stuff you already developed using their development tools, and taking it forward to the Web, to a three-tier, thin-client architecture. We believe there is a very low resistance path for people to take existing stuff built using Visual Basic for example, or PowerBuilder, and use the particular products that make up the architecture. We believe those will actually enjoy quite significant growth in the short term. But we believe the later phase is where people will actually look at building component systems from the ground up. We think that the more middleware-centric approach, rather than the tools-centric approach, will make those architectures more appealing to that kind of person. We think that a person who has an immediate problem today and is interested in the short-term solution will end up buying Sybase, Microsoft products. We believe people taking the long-term, more strategic architectural view will be best served using Oracle, IBM products.
How long do you think it will be before the long-term stuff takes over?
Post-2000. There is a real impact on the application development market by the year 2000 problem, and we see many end-user organizations imposing moratoria on application development. What we're predicting, in fact, is that component technology is going to appear in two waves. The first wave will be driven by this need to bridge legacy and Web. And it's going to involve the main customization and integration of existing back-end systems, and linking those systems to fit client presentation systems. We think the second wave will appear post-2000, and it's going to be rearchitecting existing stuff from the ground up and building new systems. But we do think most of that will happen post-2000.
What makes components OK for companies to embrace today, rather than in all of the years they were talking about it?
Good question. To be honest with you, at the moment, it's still driven mainly by the vendors. We see that the real reason people are going to pursue it now, rather than years ago, is because products exist today that can help you do it and do it straightforwardly. In the past, you could have built everything in component-like fashion, but it would be a lot of work just to get moving. There's a lot of infrastructure you'd have to build yourself from the ground up. This is provided by mainstream software suppliers. We're getting to the point where small to medium ISVs, for example, can take advantage of this technology. Big infrastructure providers like Microsoft, IBM and Oracle are forging strategic partnerships with whole oceans of partner ISVs to get them building component systems. It's built up a critical mass.
Do you think Inprise has a shot here?
Technologically speaking, yes. Inprise's big challenge is convincing the world it's a different company. Changing your name is rarely enough. Its heritage is as a tools company. It's bought a couple of middleware companies. It now has to galvanize everything from its sales force to its embryonic consulting organization to its marketing department. It's a whole different ballgame. It's a whole new sell. It's a whole new marketing pitch. It's a whole new consulting and support if you're a truly strategic piece of software to someone. If they buy it, it's something they are going to want to change relatively rarely, more than every six months, which is what tool vendors are getting into. It's going to undergo a big transformation.
Does componentware do what a lot of these vendors say it can do? What about re-use?
I think it depends on who you are. We've studied this area and we believe component technology is actually going to lessen the reuse occurring in end-user organizations. The reason is because it's easier to integrate existing systems and also, by implication, make packaged off-the-shelf software easy to customize.
Almost every packaged application vendor we spoke to is adopting component technology to lever component interfaces to their products. This means that in the next couple of years, software will be a lot more customizable. The difficulty of customization was the main reason why people historically did not buy software, but chose to build it themselves. What we're going to see is that componentware will actually shift balance and make it much more appealing to end-user I/S organizations to buy software because they will get flexibility. They won't have to trade-off flexibility against risk.
We believe I/S end-user organizations are going to buy rather than build. What that means is that they will build less software; and if they build less, they will have less to reuse. We think the people who do stand a chance to reuse software, on the other hand, are service providers like Andersen, EDS and IBM Global Services - those are the people who are going to be building software for end-user I/S organizations who don't want to go to a packaged supplier. Anyone who doesn't want to go to SAP, for example, can go to Andersen or EDS and get a spoke system that is built using frameworks that the service providers have built themselves. And we're seeing those service providers already reporting high levels of reuse because what we're doing essentially is building the same systems again and again for different customers. That's where reuse is going to happen, and we don't believe it's going to happen for most I/S organizations.
How widespread do you think the use of components is in I/S today?
In fact, I think it is probably quite widespread, but I don't think people really believe they have it or understand that they have it. Most I/S organizations run Microsoft Office and maintain that, and Microsoft Office is a set of components. I think the problem they have at the moment is that Microsoft has built office components largely for its own purposes, not for the purposes of people wanting to customize and integrate components with other pieces of software. We do see other stuff from competing vendors coming out which look more promising, specifically there's a product from Lotus -- E-Suite Developer Pack -- that is specifically aimed at people who are building off-the-shelf.
How about companies that are building components to sell?
I think the market for that is limited. The reason is if we drill down into the scenario where a CIO or I/S project manager has a business requirement that needs fulfilling with a piece of software, they're going to have three options.
That's going to a package vendor like Baan and saying 'OK, we'll buy what will very soon be a package set of components.' They can then get the software, install it and integrate it with other pieces of software. That's fine. It's definitely going to be what everyone wants. Some people won't want to enter into a relationship with SAP or Baan, preferring to have a bit more control. They still have two options.
The second option is going to a services provider like IBM or Andersen. I pick those as examples because those two both have frameworks they have spent years building. What that means is you get something that someone else is responsible for if it breaks, and is tried and tested and still relatively low risk.
The third option is something that's been talked about a lot, which is for an I/S organization to go directly to a number of vendors and say I'll buy a component off you, and I'll buy a component off you, and I'll buy a component off you, and I'll take them all and assemble them. Essentially, I'm going to an open market for components -- I'm getting components that I know will fit together. And I'm going to assemble them into a solution that has the same functionality as SAP or something. We think this is very unlikely to succeed.
There are a number of reasons this [is unlikely to succeed], not the least that if I'm an end user at an I/S organization, and I go to multiple suppliers and ask them to deliver me a component, how can I be sure that in three years' time all of those component suppliers will still be there? The very attraction of the open market in the first place is that a guy in a garage can compete against SAP. The problem is SAP will be here in five years, and the guy in the garage probably won't. What happens if something goes wrong? There's quite a big gap in terms of what would be delivered by those niche component suppliers and what the I/S organization needs, which is a single point of contact and a trusted point of contact for an application. Don't forget the mainstream is the only set of technology that is interested in a solution not a technology.
We see that the third option will actually be driven by the service provider, the Andersen or the IBM Global Services, who will in turn subcontract specific parts implementation to niche suppliers. While we do think that there is space in the software market for niche suppliers, we don't think there's going to be a free market where components suppliers can just advertise their stuff, make millions and then retire to Malibu.