Now that Microsoft is preaching components as the development model for the next decade, that model could finally become a reality. However, this technology on its own won't create a sure success: without some corporate planning, insights and examples, component-oriented development will become even more unmanageable than client/server ever was.
This is not to say component development is necessarily bad - it's great! Building your application from a series of compatible modules is the right way to develop software. This fundamental approach is core to the new model that Microsoft is outlining for its developers at its annual TechEd conference in New Orleans. It is also core to the company's updated tool strategy, as well as to the development of Office and Windows.
A recent convert
Of course, Microsoft is only a recent convert. IBM has been proclaiming the value of components both in approach and in its San Francisco frameworks. Big Blue's transaction server and message queue architectures are its core to this promising approach, and components are the very premise that Sun leveraged the entire Java craze on. Additionally, other Unix vendors have seen the virtue of components for years.
Yet, one has to ask - if component and object development are so fantastic, why haven't they caught on? In theory, IBM and Sun should have blasted Microsoft's Windows monolith apart with their component architectures. Yet today, we see Java continuing to promise this capability and Unix vendors claiming that their time will come, even though we have seen several Object Management Group-like collaborations form and dissolve in recent memory, not to mention the initial attempts by Borland to deliver object tools.
There is a definite paradox. Components can offer capability to build applications, yet, when unbridled, this capability can become its own worst enemy. So while many companies continue to chase the holy grail of reusable components, few developers are trained (or given incentives) to develop these building blocks.
Microsoft's presence in this category can change all that. It has continued to prove it can produce complete and powerful development tools. It also has a rich collection platform for components buried on corporate desktops - the Office and Windows environments. It is laying out its natural progression from Visual Basic and SQL Server applications into multitier Microsoft Transaction Server, Remote Data Services, and COM-oriented environments. With the promises of Office 9 and NT 5, this platform will only grow in its capabilities.
But even Microsoft might falter. Handing over a component-oriented development environment to unprepared developers is like handing 17- year-old drivers the keys to a Ferrari. While novices may have fun at first, they'll probably crash quickly.
This is where corporate IT parents need to step in to offer some discipline. Corporations must play an early role to avoid the mistakes seen with client/server development. They should create corporate architectural committees and lay out component guidelines before starting development. This beats the traditional approach of putting a committee together after mega-bytes of incompatible code have been deployed.
Down the road
These committees should dev-elop the reuse road map - when the company should develop a reusable component, when it should invest that extra 10 to 20 per cent necessary to expand a component into a reusable one, and how to leverage a corporate repository to catalogue the existing components.
They should also determine when to add ones developed outside the organisation.
Of course, this committee should leverage all efforts from vendors to set their standards. Microsoft and others will enhance their tools to serve this budding approach.
Does your company have internal application development committees? Are corporations disciplined to create centralised architecture committees? E-mail me comments.