Of strategy, tools, and trade-offs

I'm going to take some time over the remainder of this year to talk about different solutions for data replication.  It's a complicated discussion, and I'll be limiting the scope to only cover solutions that are write-order consistent (sorry rsync fans).


While collecting my thoughts, though, I thought it made sense to talk a little philosophy.


First, I want to touch on strategy.  A few years ago I was called into a brainstorming meeting with a customer to discuss their IT strategy and make suggestions.  It was a very brief meeting, as their strategy was "We use vendor X."  Confused, I tried to clarify what, exactly, that meant.  "You mean you use them to fulfill a piece of your strategy?" I asked.  "No,  whatever X tells us to do, we do."  Six months later, X was bought by Y, and not too many years later Y was bought by Z.  The customer, meanwhile, was left high and dry.


Strategy does not equal products.  Strategy does not equal vendors.  A strategy is a plan.  A plan identifies direction not details.  Customers (should) have a strategy.  Vendors (should) have a strategy.  Sometimes the two align and there can be a mutually beneficial relationship.  If a customer cedes control of their strategy to a vendor, though, then they are basically saying that IT does not matter to their business.  While that may be the case it should be considered and made as a conscious decision.


Second, it's important to realize for all the passion around specific products and approaches they are ultimately tools.  Products are neither good nor bad - they are either fit for a purpose or unfit.  Just because it's made by a specific vendor doesn't make it bad, especially in the acquisition-crazy world we're living in.  Just because it's not the approach you're used to doesn't make it bad, either.  The real question is does it do the job I need done, at a reasonable cost (both hard and soft dollars) without forcing me to fundamentally alter the way I do business today.


And that ties into the third point, trade-offs.  There is no one perfect solution for every problem - and thank God because that would be a boring world.  Sometimes you're willing to trade an hour's worth of data loss in the event of a disaster for the (substantial) cost savings.  Sometimes you're willing to single-path development hosts.  The key is to understand what trade-offs are available, and again make a conscious decision about what is right for your environment.


With that as the groundwork, I'll continue next week with the common approaches to data replication.

Of strategy, tools, and trade-offs