This month I’ve attended SQL Saturday in Denver along with the Pre-Con event featuring Steve Jones and Kendra Little who discuss continuous integration and development. I’ve also attended the Teradata Universe conference in Denver, so it’s been a very busy month. Besides trying to catch up on email and work between sessions, I’ve been trying to summarize material into educational and actionable items for my customers.
I would like to share with you three sayings and some examples around them that I heard at these conferences. I think these phrases have a lot of insight to them and I hope you can take something productive away from this.
If it hurts, do it more often.
There are things that companies do that everyone dreads. And for some of those companies, that is deployments. Every time those companies perform a deployment, they break EVERYTHING.
Every deployment for those companies means over-time, firefighting, angry executives, angry customers, ramped up call centers, and all-around chaos leading up to and after deployment. In short, it HURTS. It doesn’t just hurt the business or your customers, but your employees are going to feel this pain. Most of us would like to work somewhere that doesn’t hurt. (Except maybe Cobol programmers.)
What if we could keep our customers, executives, and co-workers happy? Better yet, what if we could ADD value rather than stay afloat when we release? What if we can deliver things to the customer before they need them? What if we start pursuing new customers and meeting their needs before they realize they need something? We’re going to start capturing that market share relatively quickly if we are consistently meeting those goals.
Let’s look at clustering and administration as another example. It HURTS when I try to cluster servers and get things working properly at the network level. It hurts so much, that my article about my laboratory setup had to be delayed. (It was going to be today.) That’s ok! I can identify that I’m having troubles and there are gaps with my experience, knowledge, and process.
The more I practice, the more experience I gain and the more educated I become. As I fail, I identify where in my process I went wrong. I continue to refine indefinitely as improvement is a never-ending process. This is exactly like the other scenario with deployments.
Repetitive experience leads to automation which leads to failure and success which leads to refinement. Your failures and success are your experiences, this reinforces your knowledge while teaching you new things along the way. Eventually, you’ll have seen most of the problems and will have had a chance to fix them. What you haven’t seen, you will hopefully have learned about enough to avoid. Following best practices can help you circumvent the painfully learned lessons. The more you work at the problem, the easier the problem gets.
If it hurts, do it more often. Do it so often that it doesn’t hurt anymore and becomes boring.
What value does this deliver to the customer?
Sometimes it’s too easy to lose sight of the goal. Here are a few things we all may have done at one point or another:
- Seeing columns misnamed and re-name them.
- Re-format T-SQL in functions or source code with your new formatting tool.
- Translate our T-SQL scripts into SSIS packages.
Now, are those things not worth doing?
I’m not going to say yes or no to that question. I’m going to ask you another question instead. “What value does this give to your customer?”
There’s a possibility your columns are so confusing that no developer can continue to work on the product. There’s also a chance that things have become so discombobulated that finding things is nigh impossible. If the outcome of the project means you will consistently deliver better quality products more frequently to the customer because of the re-named columns, then yes! Absolutely you should do that!
What if there was another way that took less time or a different solution that adds value to the customer? What if we used views instead as an intermittent measure? What if we just used proper documentation tools and had a data governance board? If there were subject matter experts on hand to help us navigate the landscape, re-naming the columns doesn’t add as much value as some of the other ideas for the customer. And yet, the symptoms related to our problem would still be alleviated. Maybe we’d just rename them if we are visiting the section of the code again while working on a project.
What about the SSIS example? Will the performance gains of the SSIS packages change the delivery speed to the customer? Will we use enhanced logging or other capabilities that were not involved with the T-SQL scripts? Are there performance issues we are running into that are forcing us to make the switch or else we will cease delivery?
What value does doing X give the business? Are there alternatives to achieve this value? What are the pros and cons of doing this method and are there other methods that better align with the business for the short, intermediate, and long-term goals? Or better yet, what value does this deliver to the customer?
We should be thinking about where the business is headed and how to best align our tools and technology to enable the business. After all, that’s what IT is all about. Enabling the business to serve their customers.
Data is the new gold rush.
I think that phrase is complete rubbish. Data has always been the gold rush, past and present.
How did the gold rush start? I must admit, as soon as I typed this sentence, I realized I had forgotten how it started. A quick journey to Wikipedia reaffirmed my memory and suspicion, however.
The California Gold Rush (1848–1855) was a gold rush that began on January 24, 1848, when gold was found by James W. Marshall at Sutter’s Mill in Coloma, California.[1] The news of gold brought approximately 300,000 people to California from the rest of the United States and abroad.
shorturl.at/doO57
The gold rush began with data! Data (aka information, aka news) brought 300,000 people out to look for gold to become rich. The first people to get ahold of the news of gold were able to make the journey earlier to set up shop and begin operations first.
Data has always been valuable. Only recently in human history have we been able to compute information quickly and efficiently. We have become so great at it, we can begin driving entire businesses with data!
When the industry is referring to data as the gold rush, they really mean the rush is to achieve a mastery of the organization’s data maturity. Consistently executing and delivering on a solid data strategy with a framework in place will guide the organization to data nirvana. (I hear there is a soothing lake full of data that’s great for weekend fishing trips. Just don’t go too far East, you’ll hit the swamp.)
This means our quest for the holy data grail is no longer enveloped in just warehousing analytics and business intelligence. We still need those capabilities and they still deliver critical value. The winners of the data revolution will be those who excel in prescriptive analytics. Can you imagine how different history would have been if people could begin preparing for the next event before it even happened? What about those miners who went seeking gold? Can you imagine if they were able to predict where, when, and how to mine to best increase their profits?
Data is not the new gold rush, it was already the gold rush long before the concept of data existed. We are just now beginning to harness the capability of data and who knows what the future will decide for us. Well, besides Watson.