Common Courtesy in the Digital Age

As we continue the path of being social in digital terms via the different social media networks, we are forgetting how to be social in real life. I'm not just talking about being socially awkward, I'm also including in that our mannerisms, morale behavior, public display of affection, the exaggerated use of words, fear, etc. Above all, we're losing our notion of being polite, courteous and cordial.

Allow me to touch on these a little further:

Different Project Documents

I have found that often there is a lot of confusion around the different artifacts –the different documents– that might be needed for a project, or in a particular software or technology-driven shop. Much of the confusion is in the naming convention of these documents (docs), and in the fine line delineation between them all.

Different Documents
So, I have decided to put all I have learned, coupled with a few plagiarized searches, into this one post –A repository describing the most common documents involved in a typical Software Development Life Cycle (SDLC).

But before I jump right into it all, I ask that you share with us all your feedback ... feedback on the post itself and on any other artifacts that might require clarification.

Technical Requirements Doc. (TRD) –It includes the layout of the systems, firewalls, performance, SLA’s, and general & specific details of the technical implementation process (this includes the environments, along with sessions, load-balancing, data mappings, etc.).

A different document, but is a sub-set of the TRD, is the Entity Relationship Diagram (ERD). This should include the [logical] data model (LDM), which’s different* from the ERD but quite similar.

Data Dictionary –Tables, columns, data types and descriptions.

* A logical model is slightly more abstract than a physical model. A physical model represents exactly what is implemented in a database ... table and column names are as they exist in the schema, you define indexes, specify column datatypes and sizes, contraints, tablespaces, partitions and all the other requirements to actually define the database. A logical model shows entities, attributes, keys and relationships. Names are usually more free-form and descriptive. Often, "conceptual models" sometimes get confused with "Logical Models".

A conceptual model might have a fact table with the dimension tables but without any column names. Some of the dimensions might later be split into 2 or combined. It's almost a graphic presentation of the BUS Architecture.

The logical model might have the column names in lay terms - "Group Identifier" instead of group_id. There may not be difference between a view and a table.

And the Physical Model is what the database physically looks like.

To many, there is no logical dimensional model. Conceptual and logical models are normalized data structures used to define data dependencies. Unfortunately, there is no consensus on what goes into a conceptual model other than it is less than the logical data model.

In layman’s terms …
A Conceptual Model is what you do on a scrap piece of paper.
A Logical Model is what you do in Excel.
And the Physical Model is what you get when you use Visio to reverse engineer the database.
Actually, a variation on the conceptual model comes in handy when setting up the reporting tools.

Business Requirements Document (BRD) –This is your project scope. It’s the reason behind the madness. Why the project is needed, and how the vision of the project is supposed to come into manifestation. This also includes the commitment to the delivery of the project. The BRD can be an extension of the SOW. The BRD should include the process required/needed, which represents the project along with any process-flow and logical diagrams. Functionality is not part of the BRD. The BRD acts a summary of the detail that would ultimately make it into other documents, like the Functional Specs. Document (FSD).

Functional Specifications Document (FSD) –This document includes logic and details to implement the business vision, process and overall project in technical terms. The FSD includes object definitions, and may include procedure definitions as well. The FSD includes use cases, which later make it into Quality Assurance’s (QA’s) Test Plans. The FSD is divided or represented into different functional areas that relates to the different working parts that make up the overall project. Examples includes, data feeds, reports, campaigns, business intelligence deliverables, etc. These areas are represented in the BRD at a high-level and include the functionality aspect here. As such, and in most cases, some of these are divided into their own respective documents; which are still a sub-set of the FSD.

  Campaign Requirements Document (CRD) –This could address the overall architecture, process, inputs/outputs and overall handoffs of a campaign, as well as a listing of each campaign expected. The result should be a document, which houses all the campaigns agreed upon as part of this project’s scope & deliverables. Upon completion, this document is handed over to Production Support.

  Business Intelligence Requirements Document (BIRD) –This document, on its own, should provide enough specificity with respect to the kinds of business intelligence applications that are needed; including the different kinds of applications, from basic reporting and OLAP to sophisticated analytics. In general, this document guides development of the business intelligence databases and applications that deliver the BI, or to guide the business process changes that deliver the bang for the buck to the business.

Warning: I'm about to digress for a little bit ...

The BIRD is more than the following traditional statements:
  • “…produce enhanced organizational capabilities to manage data and information as organizational assets.”
  • “…provide a single version of the truth.”
  • “…enable consistent and reliable access to accurate corporate-wide data.”
  • “…provide more sophisticated reporting and analysis, faster turnaround, improved accessibility and enhanced quality.”
  • “…a single touch point where detailed financial transaction information can be filtered on user-entered selection criteria, viewed online, downloaded in standard file formats and used to generate real time reports.”
And it’s also more than the traditional BI Functional Specifications:
  • The system shall provide the ability to drill down, drill across, and slice-and-dice.
  • The system shall provide the ability to specify organizational hierarchies and display performance scorecards for each organizational unit.
  • The system shall enable role-based access to information.
  • The system shall provide capabilities to route alerts to business users according to user-defined parameters.
  • The system shall enable integration of data from multiple disparate sources.
And most of all, it’s more than the traditional Give Us Everything We Might Need and We’ll Figure Out What to Do with It.

While such data element listings can be helpful, and while we need to understand what business information is needed as a core expression of BI business requirements, the listing alone says nothing about how the information will be used or how it might need to be integrated with information about products, manufacturing locations, store locations, organizational units and other organizational information. Further, BI capabilities built on top of large stores of unintegrated subject data elements run the risk of spawning inconsistent business intelligence depending on how development teams and/or power users choose to integrate data for their specific purposes. In other words, simple data element listings don’t provide enough specificity to guide development of the BI databases and applications that deliver business intelligence or to guide the business process changes that deliver the bang for the buck to the business.

Instead, the BIRD should be Business-Driven BI Requirements

A. Establishes a clear linkage between business strategies, the core business processes via which the strategies are executed, and BI-driven business improvement opportunities, which is the basis for a BI business case that is compelling to the business stakeholders;
B. Identifies and clearly describes what business information, analytical tools and techniques, and decision support is required by the business to realize BI-driven improvement opportunities to management processes, customer processes and/or operational processes;
C. Provides the essential input to the process of defining specific BI projects and prioritizing those projects based on key criteria such as business impact and time-to-market;
D. Provides the means of aligning business intelligence, business process improvement and balanced scorecard initiatives;
E. Drives key data architecture decisions;
F. Provides the basis for end-to-end traceability between BI requirements approved by business users and the delivered data stores and BI applications; and
G. Provides a key baseline against which the performance of the BI initiative can be measured.

Data File Layout (DFL) –Description of data fields. Note how this works in tandem with the ERD, data model and data mappings; which are typically part of the TRD, or a sub-set of that.

Digital Catalogs - TheFind, Amazon's WindowShop and Google's Catalog

The Wall Street Journal reported that in 2010, there were more than 20 billion catalogs mailed in the U.S. alone. That averages out to approximately 200 catalogs annually per household. People generally love flipping through these catalogs, but until today, consumers seeking a way to virtually browse their favorite catalogs were forced to download countless applications from individual retailers. Enter digital catalogs. Generally speaking, these digital catalogs are either individual (and independent) apps available for mobile platforms (specifically tablets), or they are web-based applications available directly on the browser a domain click away.

Back in 2002, Google launched a Catalog Search. It was later shut down in April, 2009. The short-lived product allowed users to browse popular mail-order catalogs, and search across those catalogs for specific products.

TheFind Catalogue
Since then, other players have come into the picture and have created an updated but similar product, which predominantly (and naturally) focuses on the tablets. Among such new comers is TheFind Catalogue. The app, available for both iPads and Android tablets, allows users to browse specific catalogs and search across all available inventory for particular products. It also allows users to customize a “my catalogue” area as well as save any single item or store catalog to the personal dashboard.

Amazon WindowShop

In a similar browse/search manner, Amazon's WindowShop also offers a rivaling experience. WindowShop, however, has a smaller selection of products from branded retailers. Both, and others discussed in this article, are taking advantage of the magazine-like format of tablets, are reaching to partner with retailers to save on printing costs (and offer dynamic content), and be green while doing it. On TheFind site, I found this: "5.6 million tons of catalogs and other direct mail advertisements end up in U.S. landfills annually. We are doing our bit to help reduce the number of unwanted catalog subscriptions, and save natural resources."

Google Catalogs
This year Google [re-]launched its digital catalog-shopping offering Google Catalogs. Besides browsing, and like other digital catalog offers mentioned in this article, users can search for a particular item across multiple catalogs, zoom in on individual items, but can also watch the occasional video, save items to a “favorites” file among other things one would expect from a digitized catalog. Other features include the ability to find and check inventory at nearby stores and a collage function that allows for shoppers to create a collage of favorite products that can be shared with fellow shoppers within the app. The app makers say that Google+ integration is coming soon.

Clearly, there is (and will be) emphasis on partnerships --especially with merchants. Google Catalogs currently has 50 partners and over 100 catalogs. Google envisions users kicking back on the couch with the app. “I hope that users can use this as a relaxing shopping experience,” said Abigail Holtz, business product manager for Google Catalogs. Further, a recent Forrester study found that shopping has become a killer app for the tablet platform. In a survey of online shoppers and vendors conducted less a year after the launch of the Apple’s iPad, tablet users were already driving anywhere from 21% to 50% of the mobile traffic on retailer sites.

All that said, late last year Google launched, and later launched its app; which so far I can only find for the iPad. The surprising part is that I have not seen a link between Boutiques and Catalogs, despite their similarities. Granted, I see the former more akin to Net-A-Porter, which seems to cater to a niche market. Still, they all seem to be dabbling with the Digital Catalog space. Building on that, call me crazy but I think that Google's Product Search, which I still call Froogle (yes, you can reach Google Product Search using that), can also be bundled up with Catalogs. Visiting today, it's no surprise that I saw Google Offers, and Catalogs, both as clear call-outs on the front page. Google Offers, which I know little about, seems to be a contender for Groupon.

Another company that has made its debut earlier this year in the Digital Catalogs space is called Padopolis, which launched the app Catalog Spree back in April this year; but its CEO said that early on retailers weren’t sure what to make of tablets: “When we started to approach vendors in July and August of last year, people thought that the tablet was going to be a fad,” said Joaquin Ruiz, CEO of Padopolis.

One might argue that Flipdoo fits into this categroy. I, on the other hand, view them more of a platform And they seem to emphasize Flash by Adobe as their backbone. Of course, to a retailer/merchant, they may not care as long as the result is the same; where I might be more picky taking into consideration accessibility, scalability and search-engine friendliness.

I suspect that the number of players in the Digital Catalog space will continue. It will be interesting to find out who makes it and who doesn't, what the differentiating features are, etc. I would like to see a matrix of their offerings; but even more interested in why merchants/vendors/partners select one over the other (regardless of features/offerings). If you or someone you know uses any Digital Catalog offering, please let us know in the comments. I'm sure there are others out there, or perhaps you have an opinion or two on some of the ones mentioned. Chime in and be heard.