April, 2006

Posts
  • Michaeljon Miller

    Sneaking past the corporate firewall - projecting business data

    • 0 Comments

    What would happen if a business, or even an individual application user, could project business data onto a secure workspace in the cloud? What scenarios would that enable and why would they be interesting?

     

    That's a topic that I've been spending a lot of time thinking about recently. In fact, it's very much the only thing I've been working on since I moved on from my last team. Let's look at one scenario that's simple to understand, has few moving parts, and doesn't require a ton of security. The CRM product supports several customer service scenarios, one of which is the problem database / knowledgebase. KB articles are interesting in a few ways because depending on the direction they "face" they support different roles. An inward facing KB article supports a call center world where the support representative relies on the KB contents to help solve problems. In this case the articles don't need to contain pretty formatting, they don't need to be "customer-ready", and they don't even need to be secure. The most important thing is that they're discoverable.

     

    Outward facing KB articles have a higher bar they must meet before becoming "public" as it were. [I'm going to leave the term "public" open to interpretation for a while because it really depends on the role of the consumer.] They must be correct, applicable to a given problem domain, discoverable, formatted reasonably, and "customer ready". That is, there may be internal information which shouldn't be presented for technical, legal, or other reasons.

     

    I won't go into the requirements for how to provide external access to this internal data. That's something that's described in the internet connector toolkit and license, and typically requires an IT support staff, a partner's time, and at least a quart of your own blood. I'm working on ways to reduce that cost to the business and make projecting this data as simple as hooking into the normal workflow.

     

    Let's see where this takes us...

  • Michaeljon Miller

    What's my new world made up of?

    • 2 Comments

    The MS-CRM world is made up of nearly one hundred entities. The original, v1 database design had one goal - to be readable by IT folks. There were several designs prior to the current version that were far more complex to read, but far more extensible in theory. We pulled the plug on the complex model during v1's first milestone and we threw away nearly all of the code that worked against that model. I have mixed feelings about that decision though. The model had the potential to be extremely flexible in terms of semantics. But, the implementation was lacking. Customizations required opening a UML model, tweaking it, and regenerating everything. That's never a good plan. What we ended up with - the metadata model - is a far better solution to the customization story. But, the underlying schema is a problem.

     

    If I were going to start over and create the CRM "schema" again, I'd take a completely different approach. Essentially I'd throw away the requirement that the database be readable by mere mortals (that's sarcasm by the way) and instead focus on four things:

     

    Principals

    Collaborations

    Exchanges

    Collateral

     

    That doesn't mean the database would only have 4 tables, but that's a close approximation to the number we'd need to describe quite a bit of the CRM world (it's my belief that we can describe even more worlds than CRM with the same model, but I don't want to talk about what I don't know… yet).

     

    If we had those four concepts along with their powertypes (concepts which describe concepts), we'd have eight "tables". Now, the most important thing in the data model is the relationships between the concepts. I'd argue that the most important thing about CRM, and other business applications, are the processes. We'll get to that later. If we took a very simple approach and created an M:M relationship between each of the concepts we'd end up with an additional six tables, for a grand total of fourteen. That's a far cry from the CRM database that ships today. We might take the extensibility one step further by creating powertypes for each of the M:M relationships which would increase the size of the model by six additional tables.

     

    On top of those fourteen tables we could create dozens of database views that merged powertypes and concepts to expose higher-level concepts that are more familiar to CRM users: customers, orders, support incidents, phone calls, KB articles.

     

    So, what are these four core concepts and how might they work? Principals capture the parties known to the world, the roles those parties play, and the relationships in which those roles are played. Collaborations are the long-running interactions between principals. Exchanges are the short-running interactions that move a collaboration through its states. Collateral is all the semi-static information that's used by parties during both short- and long-running interactions.

     

    Let's look at a few examples. A party is the most fundamental concept within the principals. It's a static item representing a person, company, or even a piece of software. When two parties connect they do so in various roles where the connection is a relationship. For example, we might have Contoso Ltd. and Jonny Jones as two parties. We can connect these parties in various ways that are interesting to each party. Jonny might be a customer of Contoso and an employee at the same time. Customer and employer (notice how roles are asymmetrical) are roles that the parties play with respect to each other.

     

    One example of a collaboration might be a support incident. In this case the long-running nature of the collaboration comes into play because there are typically many exchanges that occur to move the incident along. In this case the parties might email each other, fax documentation, or telephone each other. A support representative might involve an engineer or sales representative by creating additional collaborations or via simple exchanges.

     

    Solving the incident might require delivery of different information such as a knowledge base article or technical note. If the incident requires purchase of additional services (another collaboration) then sales literature or a contract template might required.

     

    So, these are the things in my new world. Watch this space for ways that these concepts pop up in software and services that we deliver.

Page 1 of 1 (2 items)