Data Analysis
May 31 2011
Data, Information, Knowledge and Wisdom
In my reading I recently came across the concept of the Data, Information, Knowledge, Wisdom (DIKW) hierarchy. While it is perhaps loosely defined, I see the concept as a helpful way to illustrate the progression from raw data to actionable information (requiring wisdom to handle it correctly). There are valid criticisms of this model, but it does reflect the goal of collecting and managing data - turning it into something that allows business users to make wise decisions.
So how do we get our business customers from data (which is available in quantities so big they are difficult to grasp) to knowledge and wisdom? Let's consider the illustration of buying a house.
Feb 02 2011
Leveraging SharePoint 2007 for Program Management
Recently, CapTech was asked to support the program management office (PMO) for a leading mortgage sourcing and servicing provider. The client was embarking on a multi-year (and $MM) program and needed a qualified group of resources to manage and track the overall program delivery. Our initial responsibilities were to determine the PMO guidelines and, specifically, which tool would offer a collaborative platform between our team and the major stakeholders, such as the project managers (PMs).
Our team ultimately settled on SharePoint 2007 for a number of reasons. Known mostly as a document management platform, this tool can be leveraged to document information through its variety of features such as lists and team sites.
Jan 27 2011
Cost of Convenience
A colleague introduced the term “convenience view” to me and that term resonated with me ever since. A convenience view is one of those database objects intended to make life easier for people to access data without actually understanding the nuances and relationships of those data. Convenience views frequently join multiple tables together so data users will not need to code or optimize those joins. Convenience views may also include business logic which transforms data so end users will not need to code or argue those transformations. The concept seems noble enough. Who opposes simple data access, optimized joins and centralized business rules? Just like that store that sells everything right off the interstate, convenience comes at a cost.
One obvious cost is all of those optimized joins. Sure each individual join may be optimized, but the database engine has to collectively consider all available join options before an execution