May 1, 2012

Thinking about market segments

It is a reasonable (over)simplification to say that my business boils down to:

One complication that commonly creeps in is that different groups of users have different buying practices and technology needs. Usually, I nod to that point in passing, perhaps by listing different application areas for a company or product. But now let’s address it head on. Whether or not you care about the particulars, I hope the sheer length of this post reminds you that there are many different market segments out there.

Last June I wrote:

In almost any IT decision, there are a number of environmental constraints that need to be acknowledged. Organizations may have standard vendors, favored vendors, or simply vendors who give them particularly deep discounts. Legacy systems are in place, application and system alike, and may or may not be open to replacement. Enterprises may have on-premise or off-premise preferences; SaaS (Software as a Service) vendors probably have multitenancy concerns. Your organization can determine which aspects of your system you’d ideally like to see be tightly integrated with each other, and which you’d prefer to keep only loosely coupled. You may have biases for or against open-source software. You may be pro- or anti-appliance. Some applications have a substantial need for elastic scaling. And some kinds of issues cut across multiple areas, such as budget, timeframe, security, or trained personnel.

I’d further say that it matters whether the buyer:

Now let’s map those considerations (and others) to some specific market segments.

I could keep going for quite a while — but for now I won’t. Vertical markets I’m thus omitting include but are not limited to:

Finally, for yet another omission — in my original outline I contemplated distinguishing among various geographical areas, with my first-pass segmentation being:


9 Responses to “Thinking about market segments”

  1. Mark T on May 1st, 2012 9:19 am

    Great post! I feel marketers and product designers greatly underestimate this diversity…

  2. Robert Hodges on May 1st, 2012 1:19 pm

    I’m curious how you concluded that humongous consumer internet companies do not like relational designs. The folks I have met from such companies seem to have fairly catholic tastes in data management and tend to use whatever works for the problem at hand. Facebook, for example, is one of the anchor users of MySQL and drives much of the innovation in that community. Google and Yahoo also have enormous installations of MySQL. All of these companies also make heavy investments in non-relational solutions such as HBase, BigTable, and PNUTS.

  3. Curt Monash on May 1st, 2012 6:59 pm

    Well, look at what Facebook does with MySQL. Nontransparently-sharded MySQL is not a very relational design in my book.

    Facebook did invent Hive, but if they really cared about relational stuff they’d use something with better SQL performance than Hive.

  4. Robert Hodges on May 2nd, 2012 2:08 am

    I guess we would need to let Facebook folks comment. One of them did so at least informally when Domas Mituzas strongly refuted Mike Stonebraker’s criticism of Facebook’s MySQL application design. ( Experienced practitioners in the MySQL community consider the Facebook implementation a model for how to scale SQL databases effectively.

  5. Curt Monash on May 2nd, 2012 6:49 am

    Exactly my point, Robert. Mike Stonebraker criticized the Facebook guys for not engaging in traditional relational modeling or schema design. They don’t dispute the characterization, but strongly dispute that they’re doing anything wrong.

  6. Robert Hodges on May 2nd, 2012 10:25 am

    My read at least from the Derrick Harris article was that Stonebraker was attacking the overhead of implementing on MySQL, not Facebook’s relational modeling approach per se. That’s the HStore/End of an Architectural Era argument. It’s interesting, but as no implementation based on HStore concepts has 800m users it seems we should not be overly hasty to accept that criticism. At that scale it’s unlikely you can do “traditional” anything.

  7. Curt Monash on May 2nd, 2012 4:34 pm


    Oh yeah. I think you’re right about the Stonebraker critique.

    Even so, if you don’t do joins, you’re not using RDBMS in a traditional way. So I continue to be baffled as to why you’d raise Facebook as a supposed relational traditionalist.

  8. Robert Hodges on May 2nd, 2012 6:23 pm

    I unfortunately can’t comment further on the Facebook architecture for a variety of reasons. In general, however, sharding does not preclude joins. It just restricts their scope, for example within a set of users belonging to a particular service. In that sense you are right that the system is not fully relational, at least at the level of the DBMS. However, in large systems, you cannot join with everything anyway and still scale linearly. At some point you have to break things into pieces to ensure performance and availability.

    There was a nice article by Pat Helland a few years back called “Life beyond Distributed Transactions: an Apostate’s Opinion” that laid out the issue of scopes very neatly for infinitely scalable systems. Within such scopes nothing precludes use of the full panoply of relational techniques.

  9. barfo rama on May 2nd, 2012 6:57 pm

    This is an excellent set of categorizations. I’ve noted that some small organizations can get way out of whack when they fall for an inappropriate dogma. For example, the $20M business that hires 12 programmers to spend a couple of years writing a whoop-de-do custom postgres system, then throw it all out when someone shows them some vanilla OTS that does the same thing, plus it’s been battle tested. 20 years ago it might have made sense (with the tech of the time) because the OTS didn’t exist.

    I could rant on about traditional enterprises and SAAS, talk about lack of relational design ability, sheesh. I blame it all on MS Excel, confabulating presentation and data layers.

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.