
Last month I argued that the Internet's ability to foster electronic commerce among millions of users will fundamentally change the nature of client/server applications. I also downplayed the much-ballyhooed benefits of Web browsers as thin clients by stating that, "I believe the real problems may be more systemic, but I'll return to that in a future editorial." The future is now, so I'll explain what I meant.
The key word here is "systemic." A system is a group of interrelated elements that make up a complex whole. A system's architecture arranges the elements so they enable the system to perform its functions. The finest components will be useless in a fundamentally flawed architecture, just as a "perfect" architecture hampered by poor quality components will not perform optimally.
Computer systems do not build themselves. (I believe software agents are evolving into increasingly proactive and self-adaptive programs, but that's another topic for a future editorial.) Because people build computer systems, the development process is no less important than the tools used to build systems. A defective or inadequate method will not result in high-quality components or a well-designed architecture.
A frequent justification for object-oriented programming techniques is the increased reuse of prebuilt classes. A good development methodology helps organizations reuse proven procedures while avoiding detrimental procedures. The point is to balance your focus on tools (what you use) and architectures (what you build) with a healthy concern for a good development process (how you build systems). Adopting Web browsers as the face of a new architecture will probably solve some application deployment issues, but it won't magically instill an effective development process.
So far, I have heard almost nothing about development methods suitable for developing Web applications. Just as methodologies that were originally developed for building host-based systems had to be adapted to client/server projects, I suspect similar renovations will occur over the next few years as development teams get past their first Web-based project. No matter what kind of system you build, if it is large and complex, you cannot shortchange your development process.
My April column, "One-Stop Shopping," included a survey asking your opinion about relying more on a single primary vendor. Unfortunately, I have only received 12 responses, so I cannot reliably draw any conclusions from such a small sample. However, the devoted dozen who took time to complete the survey deserve to have their responses tallied. In a few cases, the results were so extreme I feel compelled to report them.
Only one respondent now relies on a single vendor. Despite that, 10 agreed that an RDBMS server would be an essential offering. On the other hand, 10 respondents are happy buying a network operating system elsewhere. That's interesting when you consider that Windows NT is the nucleus of Microsoft's Back Office-based enterprise strategy. The two most popular factors used to choose a vendor are technical quality of products (the only unanimous 12 votes) and technical support quality and cost (11 votes). The latter tells me that implementing today's client/server products is still no piece of cake.
I had hoped to use surveys as one means by which to stay in touch with readers. Email is another (write to me at mfrank@mfi.com). I'd like to complement email with feedback from a core group of readers that I can talk to on a regular basis to critique the latest DBMS and discuss topics for future coverage. If you'd like to be part of an informal DBMS Reader Advisory Panel, call me at 770-977-4075. In exchange for your time during a brief phone call about once a month, you can help shape DBMS into a more valuable resource.
I am very happy to announce the promotion of two DBMS editors. After doing a terrific job as Associate Editor responsible for products coverage, Clara H. Parkes has been promoted to Features Editor. Clara's insights will grace this page next month as part of DBMS's special all-products issue, which she is coordinating. Betsy Slattery joined our staff in January as a copy editor and promptly demonstrated her talent and capacity for greater responsibility. Betsy has stepped up to Associate Editor and taken the helm of our products section. Clara and Betsy bring top-notch skills to very challenging roles, and I know they will continue to make DBMS an even better publication.