Chris Gerrard

2014 - Tableau Practice Manager for Claraview, Teradata's consulting organization

It looks like Tableau is finally catching on with corporate America. We're focusing on helping organizations with their business data analysis needs and efforts.

2010 - 2014

BI consulting with a variety of clients, concentrating on bringing the opportunities Tableau provides to bear, improving the velocity and quality of business data analysis by adopting and adapting the principles of agility and, as much as possible, patterns to the practice of analyzing business data, and helping others become adept at doing so.

2010 - Managing Consultant in IBM's Business Analytics and Optimization practice in Global Business Services.

2009 - 2010

Have done a lot of work with Tableau, from Tableau Software, in Enterprise BI projects. I've found that Tableau is a supremely good tool for closing the gap between data and analysis, frequently to near-zero. There are implications arising from this across the full spectrum of BI, e.g.

at the business-information-consumer surface the ability to sit down with a business person and intimately connect to their data invariably results in insights into the data. These insights are superficially about the data relationships; more subtly and deeply, the business stakeholders can begin to believe that obtaining insights into their data is possible, and beyond that, should be the norm.
in the Enterprise BI project process stream, every process can be accelerated and quality-enhanced from the continuous analysis of the process-relevant data relevant
the initial analytics developed in intimate collaboration with the business stakeholders become the gold standard for everything else that happens; recreating these analytics in whatever the Enterprise BI technology is becomes the primary driving principle of the whole Enterprise BI endeavor.

2008 - Global Solutions Architect for one of the larger IT consulting companies. I've spent the past few years deeply immersed in Business Intelligence, is a sense returning to my original professional experience in everything to do with helping real people gain real insights into the information captured in their data.

One of the things I'm currently engaged with is: Is there a 'proper' approach to modeling real-world things in business intelligence systems? There are two opposing forces in my current situation. On the one hand, our end users want us to model the real-world surveys they're analyzing, even though it makes some analytical operations much more difficult, and is inflexible in incorporating changes to the surveys themselves. On the other hand is the 'elegant' approach of modeling the surveys with a level of abstraction that can perform all of their current analytics, albeit differently, is flexible in the face of change, and makes some analytics much, much easier and more straightforward.

Previously: Obtained my MBA from The University of MD Smith School Of Business, May, 2007.

Spent a good bit of time working for the Washington D.C. city government. Very interesting.

Worked in Columbia, MD at a very interesting place replacing their Perl customer-facing apps with Java/J2EE, where the challenge is to be aware of and take advantage of all the good stuff in the world of software development.

Worked for a software development company in Malvern, PA. 2001-2002. Very interesting, and ultimately futile. One of the things I knew, but learned concretely, was that a servlet that spanned 12 pages when printed out is a *bad idea*.

I have a deep interest in almost everything having to do with helping people augment their intellectual abilities with computing machinery, including:

Analytic Information Design
Agile Business Intelligence
Intimate Analytics
Human Cognition
Data Visualization
Programming Languages
Patterns
Development Processes
Organizational Issues
and so on and so forth and such like, including:Application Conceptual/Architecture Patterns

Is there anyone else out there who wonders about the "nature" of the software we build? What does this mean? It seems clear that there is a conceptual collision between the types of software implicit in the Object Oriented world, where the application is composed of collaborative communities of objects, and the "business" world, where the "applications" are considered as veneers to (relational) databases, and the thinner the better.

I'm trying to come up with some descriptions of these concepts that make sense. Here's a stab at it...

The OO application type is something like ApplicationAsCollaboratingObjects. Then there is the ApplicationAsDbVeneer.

Extreme Programming

My first exposure to highly productive development environments was in the mid-80s using a first-generation 4GL (yup.) to create high-value information systems. I'm attracted to XP's characteristics that represent the same types of experiences.

Software Patterns

In early '97 as I was learning Java. The OO principles I'd earlier learned were brought to life in an approachable language. Good stuff.

At the moment I'm pondering the issues involved in trying to help my company learn how to develop complex software, and if there is a body of work or information, or other people engaged in similar pursuits.

On of my real wonderings is what are the linkages between the various forces that exist in an organization that can guide the selection of development processes. It seems to me at this point that organizations can be - roughly - be categorized according to their 'maturity', and that lighter weight development processes are more suitable for those more mature, while heavier weight processes provide more organized guidance for less mature organizations.

Here's a rough stab at those characteristics that seem to matter:

Technical Proficiency - programming
Technology Proficiency - technology of the product
Social Proficiency - human communication
Project Type
Organizational Structure

* hmmm, I've stalled...

These thoughts aren't well formed; I'd appreciate any suggestions, directions, or pointers to areas where similar issues are discussed.

Other than that, I'm trying to come up with a cogent description of myself. It's difficult. ---

I've been thinking quite a lot lately about the "nature" of Web-type applications, particularly those on J2EE. Most of the common, or popular, information represents these applications as publishing mechanisms for the contents of databases. Relational databases at that. The implicit assumption is that the data the applications render is not the same as the "state" of the application. In this conception the application is itself a thing separate and apart from the information of interest to the user of the application.

This has troubled me for quite some time, although I've not been able to form a good firm idea of the disquiet, but keep trying.

There's nothing wrong with applications such as these. What I find objectionable is that in the J2EE space pretty much <b>all<b> applications are framed to be of this type. This is clearly a grossly limiting perspective that doesn't admit the potential for other more effective types of applications.

I'll try to explain with an example. In my last project the basic idea for the new product we were building is that an entity - organization, person, etc. - is involved in numerous relationships of various types with multiple other entities. This may be pictured as an arbitrary graph with the entities as nodes and the edges as relationships. To clarify, any given pair of entities may be connected with multiple relationships; whether these are combined into on aggregate relationship or not never was really well defined.

The application was intended to have these features:

It had to be web based
The entities must not be fixed, are to be custom modeled to suit the client
The relationships are to modeled similarly to the entities
Mechanisms for communicating information across the "relationship network; e.g. if a "news item" about one of the entities becomes known to the tat entity the news should be communicated to the entity's relationship partners interested in news of that "type"
A mechanism for traversing the network via the relationships between entities
A mechanism querying the entity population for entities matching specified criteria.

In the end, the application is at once an application generator and the final execution engine for the generated applications.

My very strong feeling is that this situation calls for what I think of as a "classic" OO solution: conceive of the modeling application as a set of objects that provide the means to model the specific relationship network; provide the means to generate classes representing the specific entities and relationships in the network; provide the mechanisms for interacting with the relationship network itself.

Now comes the fun part - determining what the form of the running relationship network application should be. I think of there being two basic types: one is the aformentioned "standard" J2EE application where all the entities and all the relationships are kept in the database and only surfaced up through the application in response to queries; the other is more like the classic OO (and I'm thinking of the Storage Depot example in the Fusion method) model where the network is itself a community of entity objects and relationship objects referencing one another as appropriate. My classic model feels better. Why? That's what I'm trying to figure out.

Perhaps because the representation of a complex graph of "things" fits the OO paradigm, whereas rendering complex graphs in a relational database feels unnatural. The structure of the OO network "is" the structure of the business relationship network whereas the relational db form required decomposing the structure into tables and reconstructing the structure from the tables in response to every request.
Perhaps because I can see clearly in my minds eye the communicative behaviour of the network objects rendered as messages passing between objects; contrasted to the awkwardness of implementing behaviour in or on top of a relational database.

---

CategoryHomePage