What are the most important challenges ahead for the MultiValue sector?

Users of MultiValue technology are extremely loyal but to maintain as well as expand MultiValue's footprint in the overall IT sector, the technology must be interoperable with other enterprise information technologies and take advantage of the opportunities presented by XML, Web services and .NET.   DBTA recently asked key MultiValue vendors to share their thoughts on the hurdles and the opportunities they foresee.

Robert Nagle, Vice President of Software Development, InterSystems

MultiValue applications have proven their worth in many industry sectors.  While the successful applications are unparalleled in their richness, today they face two major challenges. First, many of them are still struggling to develop rich Web-based user interfaces.  Users today are no longer willing to accept "green screen," "roll & scroll" interactions.  Furthermore, IT organizations are less and less willing to maintain thick client interfaces, with the support burden they require. To address this, application developers need to embrace component-based, web user interface development technologies.  These provide the necessary user interface richness without the maintenance burden of thick clients.  These aims are a key reason that organizations are embracing our Caché MultiValue-enabled database and application development technology.

The second and, in many ways, more pressing challenge is that enterprises want to harness these older applications within the context of enterprise wide processes. Single applications rarely meet the needs of the entire enterprise today.  Instead they need to be integrated within processes that follow the evolving requirements of the business.  Two architectural solutions are available.  The first is to expose key application behaviors as Web services.  To achieve this, the platforms on which the applications run must make it a simple task to generate these Web services, without the need to re-engineer the entire business logic or to rewrite the proven implementation. The platforms must also provide the requisite security capabilities and auditing to permit the newly minted web services to be deployed in a reliable and secure service oriented architecture. 

A second architectural choice is to make the existing business logic the heart of new composite applications.  Such a composite application will re-use existing application logic and integrate it (via business process modeling) with other legacy or new applications and services.  To accomplish this requires a platform capable of hosting MultiValue applications that also provides built in business process modeling, scalable messaging and a rich, extensible set of technology and application adapters. The InterSystems Ensemble rapid integration platform (which features the same Multivalue-enabled technology as Caché) addresses both types of architectural requirements and exemplifies the integration software developers are considering to enable leveraging MultiValue applications in new system initiatives.

There is no doubt that enterprises want to continue to harness the tuned, proven business logic preset in so many MultiValue applications.  The challenge faced by application developers is to keep that business logic relevant by embracing platforms that support the emerging architectural needs.

Mike Ruane, President and CEO, Revelation Software 

I’d have to say that the most important challenge for the MultiValue community is embracing both the past and the future. As MV developers, we’ve gained our success in our existing business-based applications. MV developers know their markets and market niches better than anyone else, which is why those MV-based solutions are still around. However, the computing world is evolving at speeds that astound even seasoned IT professionals. We’re progressing well past the character-based application, and even passing the Windows-based application.  With emerging technologies such as the Google suite of applications and mobile devices the size of a cell phone that have full QWERTY keyboards and Web browser capabilities, MV developers must be able to make their data and applications available and attractive on these new devices, while retaining control and ownership of their data.
 
Just as we all learned to program in BASIC because it was better for application development than Assembly language was, MV developers must learn that languages such as XML and AJAX are better choices for creating new Web- and mobile device-based applications.
 
As developers, most of us do not like change. We’re very familiar and comfortable with the skill sets we have. We know our BASIC programming language better than anyone else. Quite possibly, we’re happy in our rut. But just as BASIC-based application development eclipsed COBOL application development, so will browser-based applications pass BASIC-based applications. Technologies like XML and AJAX must be learned by the MV developer, or they will be left in the dust as well.
 
These languages are not as difficult to learn as some MV developers believe. XML is extremely similar to the idea of MultiValue development - MV calls it a dictionary, XML calls it a schema; MV calls them delimiters; XML calls them tags. AJAX is very similar to BASIC, except that it is case-sensitive, something that is a bane to nearly every MV developer I know, myself included.
 
One advantage that we have now that we didn’t years ago when learning BASIC and MV is the World Wide Web. Using Google or Ask or any of a number of other search engines, we can easily find tutorials, examples, and samples to hasten the learning process.  And it’s hard to resist the irony of using the web to learn how to create more Web-based applications, isn’t it?
 
MV developers and tool providers are smart: We see the writing on the whiteboard. By evaluating our markets, our competitors, and computing trends, we can figure out where we need to go next. The MV vendors are enhancing their tools to assist their developers. We at Revelation recently purchased a third-party Web-development tool and have modified it so that it will take our clients’ existing OpenInsight-based applications and port them to the Web with little or no code modification. These new Web-based applications are created using the existing OpenInsight toolset, so the developers MV experience and familiarity is retained while their abilities are increased tremendously. Other MV providers have done the same for their clients.
 
So, I repeat my initial statement: the most important challenge for the MultiValue community is embracing both the past and the future. As our customers’ and users’ expectations for their applications increase, we need to retain our control of our MV data while providing access and availability through the latest interfaces: the web and mobile devices.

Susie Siegesmund, Director, U2 Data Services, IBM Information Management

In order to retain and expand the use of MV applications, they need to communicate or interoperate with other applications both inside and outside of the enterprise. This requirement is at the heart of IBM’s On Demand strategy. An On Demand business is one whose business processes - integrated end-to-end across the company and with key partners, suppliers and customers - can respond with flexibility and speed to any customer demand, market opportunity or threat. IBM believes that the way to become an On Demand business is through the implementation of a services-oriented architecture (SOA). SOA is not a program or standard but an architectural framework that involves breaking down business applications into individual business functions and processes, called services, and then deploying and integrating these services independent of the applications and computing platforms on which they run. The vehicle for deployment is a common messaging bus. IBM calls this the Enterprise Service Bus. Of course what makes the services available to entities outside the enterprise is the Internet.

So the main challenge for the MV sector is to make sure we can be part of this vision. Because of the standards that have been used to support the SOA architecture, this means enabling XML, Java, and .NET access to and from the MV applications, in order to support Web services. The IBM U2 products have these technologies available today. We have extensive XML capabilities, UniObjects for JAVA and for .NET, and the IBM Data Servers ADO.NET Provider and Visual Studio Add-Ins (supporting UniVerse, UniData, Informix Dynamic Server and DB2) available today, and we will soon release a new product called IBM U2 MultiValue Add-ins for Visual Studio (or U2.NET for short). We also have a Web Services Developer that is a standard part of both UniVerse and UniData. This tool makes it very easy to build a Web service based on either a Basic subroutine or a LIST statement. Because XML looks a lot like an MV record, people who know XML should become much more comfortable using MV data servers. XML is definitely leveling the playing field, and making MV more mainstream.

Doug Leupen, President and Founder of Entrinsik

The most important challenges ahead for MultiValue Sector are:

Emerging technologies, trends, and tools that must be addressed by the multi-value community are:

At Entrinsik, we are constantly pushing our Informer Web-based Reporting software to incorporate the latest technology.  We believe its current technology basis is as aggressive as any tool in the industry as it delivers a web-based reporting solution.  It is easy-to-use yet powerful and intuitive to instantly access, analyze, and share up-to-the-second data for quick and efficient decision-making.

5-Mark Dobransky Managing Partner, Kore Technologies

The loyalty of MultiValue technology users is legendary bordering on religious, and rightly so. MultiValue systems are extremely fast, reliable, easy to maintain and adapt, and have a low overall cost of ownership. Furthermore, the environment is extremely effective for transactional data entry systems and operational reporting. 

The challenge has been and will continue to be interoperability with mainstream technologies (e.g., Microsoft .NET, Web services, and services-oriented architectures (SOA)) and the ability to leverage other technologies that are seen as commonplace by mainstream IT professionals, such as business intelligence (BI).   

Kore sees the use of BI as an increasing trend in the MultiValue market. Unfortunately, for BI the transactional strength and flexibility of MultiValue databases is also its weakness. We’ve noticed that the flexibility of the MultiValue data model and the way application designers have abused its flexibility makes use of standard data access methodologies like ODBC or Microsoft .NET complicated and problematic when extracting data.

The result has been that it is easy to get the data into the database, but it’s not so easy for casual users to access the data and it’s also difficult to get the data out in a manner or format expected by most professionals (e.g., interactive reports and graphs, dashboards, etc.).

The MultiValue engine is not well-suited to support the complicated queries through large datasets required for BI. Additionally, even if the MultiValue engine supported BI-type queries, most IT professionals would not dream of placing the heavy demands of BI on their transactional system. 

Kore believes the goal should be moving the data out of the MultiValue transactional system to a BI reporting platform, such as Microsoft SQL Server. This will enable the use of many commercial products available for creating reports or providing user queries. To address this industry requirement, Kore Technologies has developed its Kourier Integrator and SQL Accelerator products to address many of these data access challenges. This software is easy to install and implement and enables the deployment of a SQL Server data warehouse from one or more U2 databases, in order to support the BI goals of any company.

David McLean, President, DesignBais International

MultiValue indeed has a number of hurdles to negotiate to regain the level of market acceptance that it once enjoyed.

Emerging technologies and a market desire to implement those technologies represents a very large hurdle for the MultiValue application developer to scale.

MultiValue development organisations are forced to expand and embrace the seemingly exponential growth of emerging technologies. Does the average MultiValue software house have the resources to evaluate and adopt these new technologies? Personally, I think not. Sure, there are some that possess the resources required and thrive, but from my experience, this is not the norm.

The average MultiValue developer builds great commercial-grade applications. They understand how to make MultiValue work for business more than they understand the underlying technology.

MultiValue developers are usually very efficient and can turn around projects in extremely short intervals. This is great for the customer, great for the software house. Small teams of MultiValue developers can produce extremely functional and complete applications that customers embrace and are not keen to part with. Ironically, this efficiency seems to lend itself to smaller margins and diminished profitability.

These small, extremely efficient teams of MultiValue developers become increasingly inefficient as they attempt to navigate and negotiate the terrain of these new technologies. More importantly, the organisation behind these developers, are not adequately funded to resource a move to these new technologies.

Regardless of the technology chosen, it ideally should allow the average MultiValue developer to be as efficient as they have been historically. If not, the risk of failure is substantial.

When you prototype using the new technology, prototype the most complex part of your application. This will provide a much better understanding of the capabilities of the technology and also a better idea of how-much and how-long.

It is also important to consider that a commercial-grade application needs to be vanilla. Sure the application can have chocolate sauce as a splash screen or a dashboard, but ideally, the components aimed at end-users should be vanilla. So make sure that the technology that you adopt can serve you a great vanilla. This will help you to quickly deliver a consistent and complete product to market.

Your application must have a modern interface. It must negotiate and interact with other applications and application services. That is a given. Most importantly, you must employ technologies that will allow you to deliver your application to your market while it is still relevant. You should also plan to have some resources left over to allocate to marketing your application.

Marketing in my opinion is the greatest challenge that faces MultiValue. It is a hurdle that I am unsure that we as a collective will conquer. As the cost of hardware reduced significantly in the '90s, so did the profitability of a number of MultiValue vendors. As the profitability dropped, so did the marketing activities. A large number of very good salespeople and marketers left the MultiValue marketplace never to return. This left the developers charged with tasks of marketing and sales.

Oddly, the database vendors seemed intent on cannibalistic marketing practices that only served to diminish our market and make our competitors stronger. MultiValue application vendors even stopped reporting success stories because of fears that a MultiValue competitor would whisk away a client.

There is currently no vehicle for the promotion of MultiValue that is cost -efficient and effective. Our forums have become IQ battle grounds as opposed to a space to foster and nurture new ideas and collective action.

The MultiValue community must dedicate more resources to marketing as a community. If you have done something great, tell everybody in the community about it. Get back on the forums with positive news and stop the rot that has set in. Make these spaces count. If you make a sale, tell everybody about it. When those from the outside look into the fishbowl that is MultiValue, we want to make sure that what they see is a functional and cohesive unit. One day soon we may want to sell them an application.

With the advent of the ASP, the underlying technology tends to play second fiddle to the strengths of the application offering, as it should. Our customers correctly assume that the underlying technology is sound. This is proving to be very lucrative for those MultiValue application vendors that have applications ready to exploit the phenomena.

I have seen many MultiValue applications over the last few years, from many countries, in many languages, developed by many individuals with varying skill sets. What I can say with some hope is that most of these applications are not only the best MultiValue applications that I have ever seen, but they are also the best commercial-grade applications that I have ever seen.

So when you decide not to attend a MultiValue conference, participate in a local user group or forum, it may be you that are creating the greatest challenge for the future of MultiValue.

Bob Markowitz, Sales Executive, jBASE International

jBASE VARs and end-users with business-critical applications are the core of our user base. From jBASE’s point of view, our challenge is to keep providing the tools and features which allow those valuable applications to grow and evolve along with the most current technology of the day.

The ability to efficiently handle data interchange between jBASE and other databases and architectures is fundamental.  When we look at the jBASE database itself we have for many years supported direct integration with C, .NET and Java, and in jBASE Release 4.1 we have support for XML  -  all of this makes it easier for jBASE to integrate with the mainstream.
 
Developers continue to require both Java and .NET development tools, with .NET being the more popular within our customer base.  We are extremely well placed with our jRCS product that delivers Java, .NET and C++ development environments.  This truly versatile product adds value to jBASE and delivers exactly what developers require for Microsoft, Java and even Delphi -based applications. 
 
In addition, we have a partnership with BlueFinity International to provide our users with their market-leading mv.NET product.  Using open system tools such as BlueFinity’s Reporting Services Data Connector to Microsoft’s SQL Reporting Services allows MultiValue users to demonstrate they are just as open as any other database.  Reliance upon open system tools as opposed to proprietary MultiValue products is an important trend in the MultiValue community. 

Luke Bucklin, President, Sierra Bravo

I think we can all agree that technology is, and has been, growing exponentially. Since computing power (and utilization) will grow more in 2008 than it did in 2007 we can expect to see "old" systems get older a whole lot faster over time. If you think your legacy system is having a hard time keeping up with today's technology, your tolerance for this situation may be shrinking exponentially as well. It's not to say that MultiValue systems are old by nature, but without continuous upgrades and enhancements, any computer system becomes old. Just as there are old MultiValue systems in the field today, there are old Windows and Oracle systems out there, too. 

For many businesses today, technology is the key to continued growth and success. MultiValue-powered businesses that have their eye on the future are expanding the features of their existing systems. This trend increases the gap between how well the existing system meets the needs of the business and how well new (replacement) systems meet the same needs. Every time the MultiValue system is stretched, it becomes harder to replace.
Accelerating change is an epidemic for computing systems, but it hits the MultiValue sector hard because the DBMS manufacturers have not embraced new technologies in a consistent way. This has left the MultiValue professionals on their own, and in a constant state of uncertainty regarding "best practices" for ongoing modernization.

Modernizing MultiValue systems is a great way to maintain the investment without sacrificing features. Best practices for modernization should not be dictated by MultiValue professionals, they should be gathered from the larger community of software integrators. Services-oriented architecture (SOA) has been widely accepted as a solid method for integrating data and processes between disparate systems. Conversely, investments in green-screen-to-GUI tools can be short-sighted. Due to the exponential growth of technology, modernizing your system to a 2007 look-and-feel is going to be more of a short-term-fix than a long-term strategy. Future-proof your systems with SOA.

Shrinking Talent Pool and Decelerated Innovation: The roster of capable MultiValue professionals is not growing, and I believe a large number of today's professionals are in their last 10 to 15 years as active members of their profession. The talent pool is shrinking and with accelerated growth in technology, this math works against the MultiValue sector. Another factor to consider is that programmers approach their jobs differently depending on where they are on their career paths. A typical young programmer wants to learn everything and experiment with new technology. Conversely, a programmer that's retiring in five years is more likely to be complacent with the status quo. If today's MultiValue talent pool is (on average) less eager to approach problems with new technology, we're likely to see less innovation and fewer surprises. I fear that this makes MultiValue users more likely to hear, "No, you can't do that with this system" from the professionals that serve them.

The MultiValue community needs to get serious about providing training programs that can bring people up to speed in the database and programming environment. Additionally, the community could benefit from an online community where MultiValue users could connect with programmers and consultants to get their needs met. MultiValue users should consider investing in documentation of their systems if they have been growing organically over time. In my experience, very few MultiValue systems have current documentation on the database, programs and processes.

Underestimated Capabilities and the Lure of Shiny Objects: Those of us that have been in the MultiValue community for a while have heard countless stories of failed conversions away from MultiValue. Certainly, MultiValue professionals may feel a hint of pride when sharing these stories, but we should learn from them as well. MultiValue systems are often underestimated in their sophistication and complexity. A new shiny system that has a feature that the existing system lacks can often be inaccurately perceived as "everything I have and more." The dangerous assumption that a new modern system is a superset of the legacy system's capabilities can often be found at the root of failed conversions. Remember, the younger programming crowd is full of enthusiasm, passion and confidence. This is the same crowd that is behind the shiny objects that attract the attention of legacy systems users - and they can be very quick to make this assumption as well.

When evaluating a new replacement system, don't forget to bring up the fact that typing “dot slash dollar-sign” in the "Part #" field in the order-entry screen produces a 12-month rolling average sales price normalized for units of measure. Don’t expect others to automatically know about all the features hidden away in your application software.

Start by making a list of the features in your system that you like (or need). This is an easy and crucial exercise that will help you avoid post-conversion surprises that result from your assumptions

David Cooper, Lead Developer, BlueFinity International

The MultiValue environment has some tremendous strengths.  The key challenge that we face is to make sure that these strengths are not strangled by the inability to integrate in with emerging technologies - the key technology from BlueFinity’s perspective being .NET.  Without wanting to seem like a peddler of Microsoft sound-bytes, I think (within our sphere of operations) there are two critical initiatives coming out from Redmond:  LINQ and Silverlight.  LINQ will change the way in which we (as developers) view and interact with data repositories; Silverlight will (if its promise comes to fruition) provide Web application developers with a fundamentally different way of creating solutions - one which will improve developer productivity by orders of magnitude.  Here at BlueFinity, we are working at a feverish pace to ensure that we can provide our customers with tools that not only provide integration with these key technologies but tools which actively promote and leverage the unique strengths of the MultiValue model.