The gentleman in the photo below is my grandfather, Wes Fath. The picture was taken at the family grocery store, about 1959. Note the cash register: in those days, just about all transactions were in cash; in fact, the store was called “Fath’s Cash Market.” It’s an electro-mechanical model from NCR, and at the time, it was the latest technology. No one called them “point of sale terminals” in those days. They simply tracked the amount of each sale, so Wes could end each day knowing how much he should have in the cash drawer. Connectivity was limited to the 110 VAC outlet under the counter, and output was a paper tape. It didn’t accept credit cards, read bar codes and update stock records, or calculate how much change to provide; all of those capabilities came decades later. But Wes and every member of our family already knew how to make change, doing the arithmetic in our heads.
Fast forward to the 1990s. Personal computers, tied to relational databases on various types of mainframes and servers, the WIMP interface, the beginnings of a global network, and the growth of client-server ERP. Organizations selected software applications using a “best of breed” strategy, and developed custom software to share data between a system of record and the applications that needed the data in order to process their own transactions. Data warehouses were developed by forward-thinking organizations, so reports could merge information from multiple systems. The data was never current and frequently out of synch, but power users learned to compose elegant SQL statements in order to get exactly the view that they wanted.
Today, we see a growing “Internet of Things” producing data records, supplementing those captured by humans. Hundreds of software routines, distributed among dozens of devices scattered all over the world may participate in processing a single transaction. Object databases and search engines combine to provide access to unstructured data. APIs allow data formatted as XML to be shared and consumed without regard to how it is collected or stored. Software-as-a-service and other operating models make most of the processing and business rules opaque to the data consumer, but at least the results are based on real-time values. Mobile applications make the most of limited screen real estate, focusing on key data elements. The users have no idea where the information is coming from, but they can have whatever they ask for, even if they can’t spell all of the words correctly. No arithmetic and no SQL required.
Standardization, Minus the Structure
Nick Pisano recently posted an article describing a strategy for creating a standard repository for project management information. While I agree with his concept and most of his description, I think we now have the technical tools to do this in a much less structured fashion. I stress this aspect because the sticking point has always been getting everyone to embrace the same structure and schema used to describe project information. One size does not fit all, and few projects require the level of detail needed to manage the large budget programs that would benefit most from this sort of capability. I would argue that it is better to specify a set of APIs that can be used to request and receive information for display, as so many mobile apps do today. Allow the business rules and data model to remain opaque, so long as the content can be requested and interpreted in a meaningful manner.
To use my favorite example: Workday’s mobile application allows a manager to view an organizational chart, navigating up and down the hierarchy as needed. It doesn’t matter whether the organization comprises 400 employees or 400,000; it all just works. From the hierarchy, you can drill down to whatever data you have the rights to view, at the individual or supervisory organization level. Analytics present graphs depicting a variety of metrics and summaries. Your phone or iPad doesn’t care about the data, or how it’s stored. It just serves it up in a consumable fashion. And the punch line? The first version of this app was built by four recent college graduates, in a few months, just using the Workday APIs.
While I agree that we all need to agree on what the definition of “is” is, I think we have to embrace the current architectural state of affairs: distributed processing of distributed business rules against non-normalized data. We need to focus on insights we want to get from the data, rather than how it is collected or represented. The Big Data movement is using No-SQL databases to discover insights in mountains of records from disparate sources, which were not designed to relate to each other. I believe the project management community can realize a lot of benefits from a similar approach.
For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager