Great keynote at AWD Advance this morning by Captain Michael Abrashoff, author of It’s Our Ship, a book on leadership; I confess to tearing up a bit when he described how he supported and encouraged the young people who worked for him, and hope that I did a fraction as well when I ran a company.
Back to business, however, I’m in the technical session on AWD monitoring and business intelligence, following on from Kim Smyly’s introduction to the new monitoring yesterday, where Dirk Luttrell and Bob Kuesterteffan are giving us a peek under the covers for their new monitoring offering. They are implementing dimensional data modeling in their new offering – which, as I pointed out yesterday, is based on Oracle’s BI – in order to provide better business-based metrics and analytics. We got a brief tutorial on dimensional data models (star schemas in relational databases, or cubes in multidimensional databases), making me wish I was paying a bit more attention when my other half was talking about how he was implementing one of these in his data warehouse. In short, relational data models are organized around transactions, whereas dimensional data models are organized around business entities and information. Business entities are represented in fact tables, and dimensions are key to selecting, sorting, filtering and summarizing the data contained in fact tables.
The core AWD data is based on relational models, since it is a transactional system, but both the process and line-of-business data in AWD can be published to the dimensional (star) model for easier reporting and monitoring. If you’ve ever written a report or dashboard based directly on the process transactional data in a BPMS (which I have), you know that it’s not pretty: BI tools are optimized for dimensional data models, not relational transaction models. In the past AWD has allowed for reporting directly against relational models, but it was (is) not very flexible and could be prone to performance and scalability problems, requiring either extremely complex (and compute-intensive) queries, or denormalization and data duplication. Furthermore, it requires that report writers know and understand the underlying relational data model since they’re writing directly against that physical schema, which further locks in the core AWD product to that schema rather than being able to mask it behind a logical data schema.
In the new dimensional data model, they represent business entities directly: work items, queues, users and various other attributes of work including time dimensions. They also include a single line-of-business data dimension for all LOB fields (this seems like they are relational-izing their dimensional model, but I can understand the administrative and design complexity if they didn’t do it this way), so that fields such as account number can be used to cross-reference to other systems or for filtering, searching and sorting within the BI context.
They are creating the following fact tables:
- Assigned work fact, with dimensions regarding when and to whom a work item was assigned and unassigned, and the current state regarding assignment and work selection. This is used, for example, to report on assigned work by user.
- Completed work fact, which tracks work steps as they are completed, including duration, user experience level and other information about how the work was completed. This is used for reporting on work that was completed.
- Locked work fact, tracking items when they are locked by users: who, when and how. As with assigned work fact, this is used for reporting on work locked by a particular user.
- Login status fact, tracking when users log in and out, and whether they are currently logged in.
- Queue fact, tracking work as it moves from queue to queue, and the status that each work item is in.
- Suspended work fact, including when items are suspended and unsuspended, and who did it.
- Work fact, which including historical information on work but includes a “current” flag to filter for just work that is in flight.
[This is probably way more detail about their dimensional data than you’re interested in, but I blog because I have no memory, and this is my only record of what I see here. That’s right, it’s really all about me.]
Given that the same underlying relational model will still be there in AWD, customers can continue to use the existing AWD BI (which would hit against those tables), but I’m guessing that a lot are going to want to move over in order to take advantage of the ease of use, performance and scalability of the new BI environment. They’re also planning on some future features such as scheduled report delivery; I’m not sure which of the new and upcoming features are based purely on the underlying Oracle technology, and how much that they’re building themselves, but if they’re smart, they’ll leverage as much of the Oracle BI package as possible. They also need to figure out how to integrate/publish to enterprise data warehouses, and work up full replacement functionality for the current BI product so that it can be retired.