McObject's New Business Looks Anything But Embedded
A Q&A with Steve Graves, President and CEO
The term “database” has long been associated with enterprise scale database management solutions from companies such as Oracle, IBM, Microsoft, and others. These database management solutions provide enterprise access to a shared collection of related information to meet the needs of the organization.
McObject is a company formed to serve embedded systems developers. Its eXtremeDB was premised on the idea that embedded software is managing larger volumes of complex data, and applications need an off-the-shelf database management system (DBMS) designed with embedded-friendly characteristics like small footprint, real-time performance and support for real-time operating systems (RTOSs).
But some of McObject’s new business looks anything but embedded, with the company announcing its role in new financial trading systems, social networking Web sites and software-as-a-service (SaaS) applications.
VDC recently had a chance to talk to McObject CEO Steve Graves and ask whether this growth represents a change of direction for the company. Before co-founding McObject in 2001, Steve served as president of several companies providing database software and services to both the embedded and non-embedded markets.
VDC: Has the recession affected McObject’s business opportunities in the embedded technology sector? Has this been a driver in seeking new market opportunities elsewhere?
You are correct that McObject was founded purely with embedded systems in mind and that our involvement in what we term the “real-time enterprise” market came later. But, our presence in non-embedded software pre-dates the current recession. As far back as 2005, companies developing financial trading systems were evaluating, and eventually licensed, our eXtremeDB database.
The truth is, we didn’t target that market. They found us because they are driven by high performance and we are the fastest in-memory database. Reliability is another key requirement for enterprise applications such as financial. eXtremeDB was “born” with a streamlined design (in software, less complexity means more stability) and with a unique type-safe API that minimizes the potential for bugs. You’ll land on McObject’s Web site pretty quickly if you search for ”type safe database API”, and it turned out that embedded developers weren’t the only ones looking.
Enterprise applications like financial, social networks and analytics present a great opportunity. But that doesn’t mean we’re focusing less on embedded systems or forgotten that the majority of our income is derived there. eXtremeDB still has a very modest footprint, and we still pay attention to small details that are important in embedded systems.
As for the recession and its effects, the great thing about embedded systems is that it consists of many sub-markets with different exposures to the economy: industrial control, medical devices, network/telecom, military/aerospace, and consumer electronics. That diversity gives us some insulation. So, while we didn’t grow as fast as we’d have liked in the last 18 months, we have grown. Within embedded, military and aerospace has been particularly strong.
VDC: Is this move into the “real-time enterprise” achieved simply by communicating your existing product’s value to the new market? Or has it also required a new direction in product development, with new features and capabilities required in eXtremeDB?
Once we started seeing opportunities, we began to add features/capabilities to meet some of that market’s needs. An important milestone was our release in 2006 of a 64-bit edition that we call eXtremeDB-64. 64-bit technology increases the amount of memory a system can address from a few gigabytes into the Terabyte-plus range. For a database system that delivers breakthrough speed via in-memory storage, this is a powerful capability.
More recently, we added an optional multi-version concurrency control (MVCC) transaction manager that accelerates multi-process database applications running on multi-core CPUs. Also new is a Java native interface (JNI), to define and call eXtremeDB databases from within Java applications. Both have applicability in embedded systems as well as real-time enterprise software.
VDC: Was the decision to add a SQL interface to eXtremeDB driven by your targeting the real-time enterprise market?
That is a logical assumption. SQL is by far the standard language for corporate enterprise databases.
But surprisingly, we added SQL in response to demands in the embedded market. As it turns out, SQL is so well-known that some developers – even embedded developers – equate “database” with “SQL”. In fact, many databases offer a native API, in addition to or instead of SQL. In McObject’s case, this native API is navigational: interface functions embedded in application code work on the database one record at a time usually by searching an index for records that meet some search criteria, then looping, with application logic determining when the iteration through the index has traversed beyond the result set of interest. SQL is more “English-like” in its commands and syntax, but like anything in programming that provides a higher level of abstraction, it comes at a cost in performance and determinism. Our native API is fast and predictable, and its type-safety is very attractive for safety-critical embedded applications that need to build in fault tolerance at the programmatic level.
We often find that while SQL support is important for getting in some companies’ doors, the developers are thrilled to learn about eXtremeDB’s native API and add it to their toolset. This is true of enterprise as well as embedded systems customers, though the bias toward SQL is certainly more prevalent in the enterprise. It is also the case that, performance notwithstanding, SQL can relatively succinctly (relative to a navigational API) express a complex query (e.g. joining several tables, calculating aggregates and sorting a result set on columns of more than one table) that would be comparatively laborious to code with any database vendor’s navigational API. Similarly, an SQL ‘update’ or ‘delete’ statement can as easily operate on 1000 rows as on one single row. So (again, performance notwithstanding), SQL can have a place in embedded systems.
VDC: Do embedded systems and real-time enterprise software present separate, unrelated opportunities? Or has your activity there grown out of some convergence of the two markets?
For the most part, real-time enterprise and embedded opportunities come to us separately – one does not drive the other.
However, on the horizon we do see some convergence. Microsoft’s Windows Embedded group and others are doing interesting work in interactive “smart” in-store signage; one could easily see embedded software on the device (sign) level integrating with enterprise systems for inventory, pricing, etc. In addition, there is already a need for embedded systems data in some instances to be aggregated within a data store that can be accessed by enterprise systems such as analytics applications. To this end, we will introduce a new eXtremeDB feature that builds on the database’s existing transaction logging capabilities and allows transaction data to be “skimmed” selectively and relayed to an enterprise DBMS.
VDC: Is an embedded database management system unique in its ability to gain traction in both markets? Or is the real-time enterprise an opportunity that other embedded software companies should be looking at?
When you consider the key requirements for an application category like securities trading – including speed, predictable response time, and fault-tolerance – the requirements seem very similar to those of many embedded systems. My expertise is in database systems and I won’t pretend to have expertise about the barriers and/or opportunities for other types of product in the real-time enterprise. I will say that part of the challenge lies in getting your company and product known within enterprise development groups that are used to working with a specific set of vendors. Part of the barrier is cultural. If you call on Wall Street accounts, dust off your suit.