Home Search
Operating Environment and Architecture

Hi and welcome back to the CRM Products and Technology blog. This time I am going to focus on technology operating environment and architecture. Woah, big topics form a vast array of options.

 

As you all may or may not be aware, Consona has acquired three primary CRM companies (and other supportive technologies) culminating in five product lines.  We have the Consona Customer Management (CM) product line from the Onyx acquisition. Onyx or CM was designed to be a main repository, a customer master if you will, that houses all relevant customer information, be it front office or back office in nature, for front office operational usage.  This is generally divided into three main front office functions composed of information for the sales force, information for customer service or support, and information for marketing. Of course, many organizations don't fit directly into these molds (meaning that many departments actually cross over these poorly defined lines) but nonetheless, it fits the general classification of front office operations. It is also not just about the data; it's about the processes that need to occur when interacting with anyone outside of the organization. It is designed to truly be the system of record for those front office operations. This is mainly a Microsoft-based technology in which we are migrating from a COM+ infrastructure to a .NET infrastructure over time.

 

The second product line is called Consona Knowledge Management and it was acquired from KNOVA. This is a knowledge management application designed primarily for customer service and support organizations to populate and work with, or to spider and index external content, with an emphasis to publish this information to self-service for customers to consume. This is chiefly a Java-based application that actually runs on the Microsoft operating system, but regardless, is a Java based application in nature.

 

The third, fourth and fifth product lines were acquired through Consona’s SupportSoft acquisition. The third product line is called Live Assistance and is designed to facilitate communications through channels with customers and extends this core competency by including the capability to automatically diagnose technical issues on machines and automatically fix them as appropriate.  So, you might call it a multi-channel technology with automated diagnostic and repair technology. This is a technology that is Microsoft in nature and, given the current state of the market, works primarily against Microsoft O/S based machines. However, we do have desires and plans to move this beyond a Microsoft client stack to pick up other OSs like Mac and Linux.

 

The fourth product line is called Dynamic Agent and resides locally on a client machine to perform automated diagnostic and repair to those environments. It does actually quite a bit more than diagnostic and repair, it can detect and target an end user environment and push marketing information based on that computing environment. For example, if a PC is running low on RAM, we can profile and target those users running low on RAM and offer them an upgrade. Again, this is completely a Microsoft-based technology today and, like Live Assistance, we have plans and aspirations to extend this to other operating environments including different OSs and things like Mobile devices—at least on the client side.

 

Our fifth product line is Java-based and is designed to manage CPE devices, which which is completely unique to digital service providers like Comcast, O2 or BT. The idea here is that we can actually monitor the last half mile of client connectivity, maintain end point devices like DSL modems, update their firmware, and perform other diagnostic and repair information against the device.

 

So, as you can clearly see, we have about 1/2 Microsoft-based technology and 1/2 Java-based technology. Therefore, from a vendor prospective, what should we do?  Should we rewrite to one programming language and gain efficiencies, or should we just say forget it and keep them as they are upon acquisition with incremental improvements or should we take a fusion type approach to particle elements in the operating environment? I think the best way to serve our customers is to keep the software as it is and rewrite common parts of the application that can be shared across the product lines. In any conversion project, functionality is lost and often times not for customer gain, just for vendor gain. This why I don't like this approach. But rewriting certain components is a bit of a challenge. We are planning to consolidate on common elements of each technology, such as user administration, authentication and authorization, or business intelligence, so that those areas that matter to customers are actually common across all of our products. Therefore when a client of ours wishes to leverage multiple product lines, they can have the best of both worlds. First they get to retain all of the valuable technology that is developed to serve its purpose, but not worry about integrating or administrating complementary systems from the same vendor.

 

So why does this matter?  Traditionally for most organizations there was a holy war around Java vs. Microsoft technologies. And it mattered a bunch when organizations hired and maintained not only administrative but development personnel in order to maintain the software for their inter production use. However, now that we have customers migrating to the Consona Cloud, meaning that we take over the operations of their technology, they shouldn't care. They should care about things like common administration and business intelligence. Which is why as a vendor over time, we are inclined to provide an infrastructure that is not only the lowest cost possible, but also that provides the same level of software and service to our customers in the cloud.

 

I guess in retrospect, we had some apprehension offering a technology stack that is uncommon across our products. And now we don't. In essence, it's our problem to figure out how to service our software and applications as we offer our Software as a Service via the Cloud. Finally, the holy war is over and we can get back to what matters more—how well the software fits and how well it will help an organization meet or exceed their business expectations.