Database Reference
In-Depth Information
Build Solutions, Not Infrastructure
With apologies to true ethnographers everywhere, my observations of the natural
world of the wild software developer have uncovered an amazing finding: Software
developers usually hope to build cool software and don't want to spend as much
time installing hard drives or operating systems or worrying about that malfunction-
ing power supply in the server rack. Affordable technology for infrastructure as a
service (inevitably named using every available spin on the concept of “clouds”) has
enabled developers to worry less about hardware and instead focus on building Web-
based applications on platforms that can scale to a large number of users on demand.
As soon as your business requirements involve purchasing, installing, and adminis-
tering physical hardware, I would recommend using this as a sign that you have hit a
roadblock. Whatever business or project you are working on, my guess is that if you
are interested in solving data challenges, your core competency is not necessarily in
building hardware. There are a growing number of companies that specialize in pro-
viding infrastructure as a service—some by providing fully featured virtual servers run
on hardware managed in huge data centers and accessed over the Internet.
Despite new paradigms in the industry of infrastructure as a service, the mainframe
business, such as that embodied by IBM, is still alive and well. Some companies pro-
vide sales or leases of in-house equipment and provide both administration via the
Internet and physical maintenance when necessary.
This is not to say that there are no caveats to using cloud-based services. Just like
everything featured in this topic, there are trade-offs to building on virtualized infra-
structure, as well as critical privacy and compliance implications for users. However,
it's becoming clear that buying and building applications hosted “in the cloud” should
be considered the rule, not the exception.
Focus on Unlocking Value from Your Data
When working with developers implementing a massive-scale data solution, I have
noticed a common mistake: The solution architects will start with the technology first,
then work their way backwards to the problem they are trying to solve. There is noth-
ing wrong with exploring various types of technology, but in terms of making invest-
ments in a particular strategy, always keep in mind the business question that your data
solution is meant to answer.
This compulsion to focus on technology first is the driving motivation for people to
completely disregard RDBMSs because of NoSQL database hype or to start worrying
about collecting massive amounts of data even though the answer to a question can be
found by statistical analysis of 10,000 data points.
Time and time again, I've observed that the key to unlocking value from data is to
clearly articulate the business questions that you are trying to answer. Sometimes, the
answer to a perplexing data question can be found with a sample of a small amount
of data, using common desktop business productivity tools. Other times, the problem
 
Search WWH ::




Custom Search