The Carrier IQ news story has illuminated an otherwise unknown privacy issue and the right of entities (corporations and governments) to “watch” our behavior while using their software and/or device. The wireless Internet has served to exacerbate the ease at which this information can be collected, centralized and used to benefit the entities collecting your information.

Software vendors place value on these usage statistics. The most common justification (for collecting the data) is to help the software company learn about usage patterns and user behavior. This agnostically (purportedly) aggregated research helps the service provider prioritize where they spend their future marketing and development resources.

The problem can be significantly magnified by cloud software implementations, especially cloud-based multi-tenant applications (such as Salesforce.com). But even smaller cloud implementations, like those based on Microsoft’s Azure or Amazon’s EC2 platforms, can monitor their customer’s usage statistics as they are tracked through the database and hardware systems shared by thousands of different companies with potentially millions of users.

Microsoft is usually very transparent about the process of collecting information. You may recall the way some of their applications prompt, asking if the software can monitor and report to Microsoft your usage behaviors. To my recollection I have never accepted these terms and always say no when asked.

Another example of transparency is Salesforce.com’s monthly usage analytics. Salesforce.com analytics are delivered to your firm's administrator on a monthly basis and help your firm understand the way you use their service.

At the end of the day you can augment your fiduciary responsibility by understanding the potential exposure of what may be considered "private behavior" to third parties. A good place to start is by asking your software vendor(s) the following questions:

Does your Software/Service monitor my usage in any way?

1. Is the information sent to or kept by the Software vendor?

    1.1.  Is your policy stated in the software Terms of Service?
    1.2.  Does your product explicitly require users to “opt in”?
    1.3.  Can it be disabled? How?

2.  Is the information stored locally in log files or logging applications?

    2.1.  Where is it stored and what accessibility does it have?
    2.2.  Can I delete the data? How?

3.What specifically do you monitor?

    3.1.  Do you validate our licensing over the Internet?

        3.1.1.  Just once or on an ongoing basis?

    3.2.  Do you implement Session Tracking and/or Login Attempts.

        3.2.1.  Success/Fail
        3.2.2.  Date
        3.2.3.  User
        3.2.4.  IP Address
        3.2.5.  License Key

    3.3.  Usage during session.

        3.3.1.  Do you have the ability to capture application data?
        3.3.2.  Do you monitor explicit usage of application functionality?

    3.4.  Do you have the capability to track usage patterns over a period of time?

        3.4.1.  How long is the information kept?
        3.4.2.  How is the information safeguarded?

4.  Is the information tied to our license as an entity in your data?

    4.1.  Can any metrics or data be tied to our vendor account in your system?

5.  Is my information combined with other information your company has collected (from other sources) such as court records and financial history?

6.  Can my information be sold to a third party? Is it?

7.  Is my information used in other departments or divisions of your company?

    7.1.  With whom is my information shared?

While much fanfare was exhibited over the announcement NOT to sunset Billing Matters, an uneasy silence surrounds the pending sunset of the World Edition of Time Matters. World Edition was released almost ten years ago and represented a major step for widely accepted practice management in the cloud (before cloud was cool). World Edition was years ahead of the competition and if allowed to evolve would be a dominate force in our industry.

Sadly, World Edition customers may be finding out the hard way that when they upgrade to Time Matters 11, they lose support for World Edition, which is no longer supported in Time Matters 11. I can only imagine the silence in the room.

Unfortunately, Lexis had little appetite or vision for continuing to develop the World Edition. Possibly related to the departure of the original architect, Frank Rivera, now CEO of LOGICBit Corp and chief architect of HoudiniESQ a major competitor in the new age of Practice Management. I would highly encourage firms looking to replace Time Matters and World Edition to take a close look at HoudiniESQ .

So, as the Time Matters World Edition is sunset I pay homage to the weekends, holidays and late nights I spent working on a dream and shared vision of what could have been. The good news is the consumer still has a choice and there are more alternatives than ever before.

In my previous article I introduced the HoudiniESQ (ESQ) default database (Derby) and a great database tool (dbVisualizer) for managing access to the database from outside of HoudiniESQ. We are now equipped to discover a few basic fundamentals of the ESQ database architecture.

The ESQ database design is truly “relational” and prevents data logic corruption commonly found in database designs that lack normalization. To illustrate this concept consider changing a Contact Name, the database does not need to go through the gyrations to update everywhere the name was used. The Contact is linked referentially and is not copied into the various records where the Contact was used, like in an Event.

ESQ’s consistent column naming makes it easy to identify relational links, dates and other commonly used data elements. For instance, the unique identifier in all ESQ tables will always be called GUID, an industry standard term for “globally unique identifier”. This GUID will be used in through the ESQ database schema to create relationships to other tables. In the naming conventions. For instance, every thing before the word GUID will be the name of the related table (that holds the related data). An example would be RECORD_TYPE_GUID is the GUID pointing to the RECORD_TYPE table in the ESQ schema. Let’s take a look at how this works with the Contact table.

GUID usage in the ESQ Contact Table:

    CONTACT.GUID, is the unique identifier for the underlying Contact record.
    CONTACT.RECORD_TYPE_GUID, is the identifier for the underlying Contact’s record Type.
    CONTACT.STAFF_GUID, is the identifier for the Contact record’s assigned Staff.
    CONTACT. CLASSIF_CODE_GUID, is the identifier for the Contact’s Classification.
    CONTACT.STATUS_CODE_GUID, is the identifier for the Contact’s current Status.

Let’s take a look at how we can use this in the real world. As you may know, ESQ takes full advantage of BIRT, an open source report writer similar to Crystal reports. BIRT is best in class and I highly recommend it in lieu of Microsoft SQL Reporting (I’ll tell you why in my next article).

The following select statement results in a user friendly Contact result set where the GUIDs have been replaced by a meaningful description (instead of a cryptic identifier).

SELECT t.name        AS type,
        s.staff_name AS staff,
        cc.name      AS class,
        sc.name      AS status,
        c.*
        FROM contact c
        LEFT OUTER JOIN record_type  t  on c.RECORD_TYPE_GUID = t.guid
        LEFT OUTER JOIN staff        s  on c.STAFF_GUID       = s.guid
        LEFT OUTER JOIN classif_code cc on c.CLASSIF_CODE_GUID= cc.guid
        LEFT OUTER JOIN status_code  sc on c.STATUS_CODE_GUID = sc.guid

Since BIRT has the ability to create something known as a Data Set, this query can be saved with a meaningful name and used for reporting purposes instead of directly using the Contact table.  It should be noted there is additional overhead caused by the JOINs so use joins judiciously, when you need the information provided by the descriptive elements in the related tables.