Seen and Not Seen has an interesting post about “the tyranny of the average” in the design world.  A good read, worth the time.  If you are in a hurry, this graphic tells the gist of the story very clearly:

This has got me thinking about a lot of things we do in the data world, especially with respect to business intelligence.  One of the more useful buzzwords I have heard lately is “shadow systems“, describing the unofficial spreadsheets and databases that spring up within an organization to allow people to get things done (I have written a lot about them).

Too often, we  create or purchase data solutions that are designed to answer questions that the average user might have, as specified by the program sponsor, project manager, and developer.  The problem with this is that usually this user doesn’t exist at the time the design is finalized, is even less likely to exist when the project is completed, and is virtually guaranteed to be extinct within a year after rollout.

This means that designing for the average user delivers tools that aren’t useful to anyone.  Instead, we need to design data tools that are general enough to fit a large user base, and flexible enough to be updated to keep up with a changing business environment.  We don’t want to move at the speed of business at the time of design, we want to match the changing accelleration of the business over the life of the product.

Frank Dravis has a new post on metadata and its growing importance in the marketplace. Dravis wonders how metadata became a subject of interest for non-technical folk …

In years past, metadata was the domain of data architects. It helped them understand what data they had and how it related to the sources and operations from which it came and to which it went. At the first mention of metadata business users would roll their eyes and head for the conference room door. Surely metadata was the stuff of arcane IT discussions best had out of earshot of people driving and running the business.

Then metadata management progressed and someone had the silly idea of articulating the business value, the value to the business side of the house, for metadata. The value came from the resolution of an age old problem. A corporate manager is sitting in a conference room looking at their regular monthly sales report and it is different from what they expected based on anecdotal evidence from the field: the numbers are too low.

Personally, I think that this recent interest is driven by a few things:

1. Regulation and the threat of real penalties for inaccuracies in reporting. People got interested enough to protect their own hides.
2. The rise of ERP and BPM in the marketplace. If everything is in one place then metadata suddenly becomes a lot easier to manage.

Truthfully, I wonder how all of this is going to turn out. I know there are lots of people who want to sell metadata software, but in my experience it takes a lot of resource (time, effort, and expertise) to maintain a comprehensive metadata environment. The threat of jail time helps to keep people motivated enough to save their necks, but not enough to make something useful. Being locked into an ERP package can mean the same thing, only it is your data that is locked.

Share and earn some karma ...These icons link to social bookmarking sites where readers can share and discover new web pages.

• 
• 
• 
• 
• 
• 

Project X Discussions has an interesting article about project staffing and the bloat that often occurs with data related projects.

In a number of client environments I have often been amazed by the number of people that can be assigned to a project. Project Managers, Business Users, Business Analysts, Architects, Technical Analysts, Developers, Database Analysts, Database Administrators, Data Modelers, Subject Matter Experts, Testing specialists, Data Assurance people, Production and Operations People and of course a couple of people like me, the consultants.

While it is impossible for one person to do everything I often wonder how many people on such a project team could be removed from the project without impacting and perhaps improving the outcome.

They make some good points. In a structured environment it is very easy to get project bloat due to specialization and role playing. In my experience, a few smart, determined generalists deliver more than a pack of highly qualified specialists most of the time.

The Twist

The article then goes on:

One person I worked with recently proved that a single person acting alone can accomplish amazing things if they have access to all the right tools and know how to use them. In this scenario the end user need some reports - in excel format.

My friend, used UNIX scripts against flat files and SQL queries against the database to create a number of SAS data sets. He ran SAS functions against the data to aggregate it and exported it into Excel for the end user. It took him a couple of days.

It is easy to confuse project bloat with the need for high-quality business processes, and we have to be careful in this regards. I believe that this person was working with what I call “borrowed productivity”. He was able to deliver his part quickly, in large part by doing things that will make things more difficult (and expensive) in the future. He avoided all the processes that will save money over time with a quick fix immediately.

Where the organization will pay down the line will be:

1. Quality.
2. Sustainability.
3. Reusability.
4. Consistency.

My Experience

I once worked for a large (Fortune 500) company who had a division that did almost all of their reporting from Microsoft Access databases. They were able to crank out report after report and get them into excel format and delivered via email very quickly. At one point, this group was generating millions of emails

At the same time, there were a lot of things that didn’t work on this model:

• The reporting group was really never able to get their reports to match up internally, not to mention reports generated through the centralized data warehouse.
• When business processes or changed it was very difficult to find all the places where code needed to be updated.
• There were a huge number of reports that were very similar, with only slightly different parameters.
• When more reports were needed the only recourse was to hire more Analysts.
• The users soon grew tired of having a large number of excel spreadhseets in their Inbox each morning and stopped reading many reports

Eventually, this reporting system became unsustainable and the group went through several major crises and ended up being mostly disbanded. This was a huge waste of resources and a bitter loss of business expertise and technical talent. A lot of good people lost their jobs because of a bad system.

Conclusion
Small teams are good, very good. They are efficient and often much easier to run. Small thinking is bad, very bad. It often unintentionally deceptive and very expensive in the long run. There is no causation between big groups and small thinking or small groups and big thinking, but often there is a correlation.

Regardless of your environment, in developing your inormation architecture make sure that you understand that:

1. Data delivery has to be fast, at least as fast as the business that drives it.
2. Initial development is usually the smallest cost in the data lifecycle.

Normally, a discussion around this subject will neglect one side or the other, but this really is just a disservice to the efficiency of your organization.

Other Reading

Rick Sherman has discussed shadow systems , this is one of the few works I have seen that view the discussion holistically. I would highly recommend taking a look at his work.

The more important outcome of a decision, the more people will resist using evidence to make it.

– Michale Lovagalia, Chair of the Department of Sociology at the University of Iowa.

Youth cannot know how age thinks and feels. But old men are guilty if they forget what it was to be young.

– J.K. Rowling