Development

#BigData is coming; what should SQL Server people do about it?

I’ve been presenting a lot on Big Data (specifically Hadoop) from the perspective of a SQL Server DBA, and I’ve made a couple of recent observations. I think most people are aware of the fact that data generation is growing at a staggering rate, with some estimates as high as 44 zettabytes by the year 2020; what I think is lacking in the SQL Server community is a rapid movement among database professionals to expand their skills to highly scalable Big Data platforms (like Hadoop) or streaming technologies. Don’t get me wrong; I think there’s people out there who have made the transition (like Michelle Ufford; SQLFool, now Hadoopsie), and are willing to share their knowledge, but by and large, I think most SQL Server professionals are accustomed to working with our precious relational system.

Why is that? I think it boils down to three reasons:

The SQL Server platform is a complex product, with ever increasing opportunities to learn something new. SQL 2016 is about to drop, and it’s a BIG release; I expect most SQL Server people to wrap themselves up in new features and learn something new soon. There’s always going to be a need for deep expertise, and as the product continues to mature and grow, it requires deeper knowledge.
Big Data tools are vast, untamed, and very organic. Those of us accustomed to the Microsoft development cycle are used to having a single official product drop every couple of years; Big Data tools (like Hadoop) are open-source, prone to various forks, and very rapidly developed. It’s like drinking from a firehose.
It’s not quite clear how it all fits together. We know that Microsoft has presented some interesting data technologies as of late, but it’s not quite clear how the pieces all work together; should SQL Server pros learn Azure, HDInsight, Hadoop? What’s this about U-SQL? StreamInsight, Spark, Cortana Analytics?

The first two reasons aren’t easily solved; they require a willingness to learn and a commitment to study (both of which are difficult resources to commit). The third issue, however, can be easily addressed by the following graphic.

This is Microsoft’s generic vision of a complete end-to-end analytics platform; for the data professional, it’s a roadmap of skills to learn. Note that relational engines (and their BI cousins) remain a part of the vision, but they’re only small pieces in an ever-increasing ecosystem of database tools.

So here’s the question for you; what should SQL Server people do about it? Do we continue to focus on a very specific tool set, or do we push ourselves (and each other) to learn more about the broader opportunities? Either choice is equally valid, but even if you choose to become an expert on a single platform in lieu of transitioning to something new, you should understand how other tools interact with the relational system.

What are you going to learn today?

2015-12-01 by Stuart Ainsworth Blogging is FUN! Hadoop Professional Development SQL SQLServerPedia Syndication 0

Reason 1234 for attending #SQLPass: The stretch

I’ve done a lousy job of encapsulating my thoughts about the Professional Association for SQL Server’s Summits for the last few years, but here’s a quick thought about one of the reasons I love this conference: the stretch.

What do I mean by stretch? It’s the exposure to new ideas, new concepts, things I may never use. It’s easy for technical people to get obsessed about our struggles of the day; we invest a lot of mental energy into figuring out problems that require immediate solutions, so we often pick educational sessions that fit into our current solution requirements (i.e. I’m having issues with ETL, so let me go pick up a few sessions on BIML). That’s satisfying, but it’s not a stretch.

The stretch is thinking about issues and problems which I don’t see ahead. It’s the creative detours, the opportunities to explore ideas that are just, well, fun to think about. There’s two benefits to this; first, by allowing the mind to wander, it actually gives me a chance to have an inspirational moment about my current issues (the “aha” moment). Second, by learning a little bit about something foreign to me, it gives me an advantage if the situation ever arises that I may need to know something about that topic (i.e. we don’t use Azure now, but we might in the future).

What’s your stretch at Summit? I’m going to squeeze in a class on R, and maybe some USQL.

2015-10-29 by Stuart Ainsworth Conferences PASS SQL SQLServerPedia Syndication 1

#SQLPass #Summit15 Gear: My KarmaGo

Just a quick post as I’m packing up for the Professional Association for SQL Server Summit 2015; this year, I’m carrying a mobile hotspot with me: my Karma Go. Just to state the obvious, yes, I am aware that the Washington State Conference Center has free wifi. I also know that wifi gets horribly overloaded in certain areas (like the keynote rooms) when thousands of device-carrying database people begin tweeting at once. I also know that most people have hotspots on their phone, but I don’t (corporate phone; unlimited data, no sharing).

So why the Go? Besides the fact that I want to stay connected with more than just my phone, I also like the fact that it offers a reward for sharing. You see, Karma’s data plan consists of two parts:

Pay-as-you-go data. I filled up with a bunch of data (mostly to use when my home internet goes down), and I refill when I run out. No monthly subscription, so I’m not paying twice for unused Internet.
Sharing earns data. If a new user connects to my hotspot, they get 100MB of free data, and I get 100MB of data added to my account. Easy-peasy (my SSID is “Free Karma By @codegumbo”) .

Checking the coverage maps (Karma runs on Sprint LTE), it looks like I’ll have great coverage. Let’s see if I can stay connected through the keynote this year 🙂

2015-10-26 by Stuart Ainsworth Blogging is FUN! Conferences PASS Professional Development 2

Coding naked.

Me, circa 1992. This is not the most embarrassing picture of that time period.

Me, circa 1992. This is not the most embarrassing picture of me from that time period.

True story: when I was in college, I was the lead singer (if you can call it that) for a goth rock Christian rave band called Sandi’s Nightmare. I had zero musical talent, and relied solely on the strengths of my band-mate (Brad; you still rock); however, while my singing ability was dubious at best, I was pretty theatrical. We had a total of 3 awesome shows before we moved on to other things, but it was a lot of fun while it lasted. Our biggest hit was a cover of Lust Control’s Dancing Naked, a fantastic little number about David’s celebration of the ark returning; his passion and excitement overwhelmed his embarrassment.

I promise, I’m not making this stuff up; it was pretty edgy for the Bible belt of Northeast Louisiana in the early 90’s. I mean, I had an earring and everything. The point of this post (besides reveling in my musical abilities and tastes of 25 years ago) is that sometimes we just need to be naked.

Let me explain; I made choices that in hindsight are difficult to defend (like my haircut). However, there was a reason for the choice at the time, and even though it may not have been the greatest idea, I’ve learned something from every experience I had. While there are things that I would do differently if given the choice and knowledge I have today, I don’t regret many things. That’s what the metaphor of nakedness is all about; being open and honest about not only your successes, but your choices along the way. You can’t change the past, but you can learn from it.

Becoming a Naked Developer

I’ve spent most of my professional career as a SQL developer working for one company (13 years in November); I was the first developer hired by that company, and my job was to build an integration platform transforming syslog data into reports, all on a shoestring budget. I strung something together in a couple of weeks, and in the first month, I took a process that normally took two weeks to do by hand down to a day; my boss threatened to kiss me (I was flattered, but declined).

Was it pretty (the code, not the boss)? No. Was it successful? Yes.

Fast forward a couple of years to 2004: I’m a member of small team building a solution to analyze more data than I’ve ever seen in my life (terabytes of data from firewalls and Windows machines); we had to import and semantically normalize data in near-real-time. We built a solution using DTS, and then moved it to .NET and MSMQ.

Was it pretty? No. Was it successful? Yes. Part of that code is still being used today, and my company has thrived off of it. We were acquired by a larger company 8 years ago, and we’ve kept moving forward.

Every few years, we’d talk about doing a rewrite, and we’d bring in some outside expertise to evaluate what we’ve done and help us come up with a migration plan. Some consultant would come in, look at what we did, and shake their heads at us. Each time, we (the remaining original developers) would attend meeting after meeting as our code was dissected and judged; we sat naked (metaphorically) in front of a team of experts who told us everything that was wrong with the choices that we made. At the end of each visit, we’d regroup and complain about the agony of judgement. In all honesty, we would have done things differently, given our current experience (and modern technology). However, the simple truth is: we won the day. We continue to win the day.

During some of these initial code reviews, the consultants were jerks. They’d spend a lot of time bemoaning how horrid everything was; I’d be embarrassed and try to explain what I would have done differently if only I had the time. The consultants would eventually propose some complex solution that would cost hundreds of thousands of dollars to implement. Our company would consider the offer, stick it in a file somewhere, and we’d keep on keeping on. Clunky code that works is better than expensive code with the same outcome.

Over time, I learned to live with the embarrassment (as you can tell from this post); I started listening to what the consultants would say and could quickly figure out which ones had good advice, and which ones were there to just be seagulls. People that focused on solving the immediate problems were much easier to talk to than the people who wanted to rip out everything and start over. Don’t get me wrong; sometimes you need to start over, but there is a cost associated with that decision. It’s usually much easier to start where you are, rather than trying to reinvent the wheel.

What’s my point?

First and foremost, don’t dwell on your past mistakes. If you can honestly say that you built something that worked within the constraints of the time period, no matter how clunky or silly it seems now, then it was the right decision. Working software works. Laugh at it, learn from it, and let it go; repair what you can, when you can, but keep moving forward.

Second, learn to code naked. Whatever it is that you’re trying to do at the moment, share it. Open yourself up to code review, to criticism; exposure brings experience. Granted, you’ll meet some seagulls along the way, but eventually, you’ll figure out who’s there to help you grow as a developer. Foster those relationships.

Third, encourage people to grow; recognize that the same grace you desire for your coding mistakes is applicable to others as well. Be kind, be gentle, but be honest; seek to understand why they made the design choices they did, and be sensitive to the fact that if it works, it works. Sometimes we get caught up on trying to figure out the right way to do something, and ultimately end up doing nothing because it’s too difficult to implement it according to the textbook.

Life is too short to not enjoy what you do; try to share that joy without embarrassment.

THIS is the most embarrassing picture of me from that time period. I thought being an actor was the best way to meet girls… Yes, those are tights I am wearing…

2015-10-08 by Stuart Ainsworth Code Good Habits Professional Development SQLServerPedia Syndication 3

Agile Perspectives: Fixed or Variable Length Iterations

Got into a deep discussion with a colleague tonight over different approaches to Agile development (yes, I’m a geek; why do you ask?). I’m a Fixed Length Iteration kind of guy, particularly since I’ve spent most of time on the Operational side of the house recently. He’s a Variable Length Iteration fan, and I thought the arguments on both sides of the fence were compelling enough that I wanted to blog about them.

Really, I’m doing this for my adoring fans.

Actually, I’m doing this because I feel guilty about not blogging, and thought this was at least SOMETHING to warrant paying for a domain year after year.

Anyway, here’s the breakdown of the two arguments; let me start by spelling out some common assumptions. I’m assuming that you’re reading this because you have some interest in development, and more specifically, some interest in agile development. If you have those interests, then I’m also assuming that you know what an iteration is. If not, the hyperlinks in the previous statements should help educate you and steer you clear away from this blog to more fascinating subjects.

The Argument for a Fixed Length Iteration

There’s a couple different versions of the Fixed Length Iteration, based on either a calendar (January, February, etc.) or a cycle (every four weeks); the goal is to commit to a ship date, and stick to it time after time. I’m more of a fan of a calendar-based Fixed Length Iteration; the actual length of the iteration varies (February is short), but development is consistently wrapping up every month, and every month code is being shipped out the door. My reasons for supporting this model are as follows:

People are cyclical creatures. We live from paycheck to paycheck; we hate Mondays and work for the weekend. Having a fixed length cycle (with some minor variation if you based that cycle on a calendar) helps in estimating and planning what gets done and when.
A fixed cycle forces developers to think in terms of components. If you’re expected to ship working code at the end of each month, you start writing code that is bite-size, so that you can leave out pieces that aren’t finished (rather than waiting until the whole thing is done). Bite-sized code is easier to test and deploy with reduced risk.
A fixed cycle means that it’s easy to change directions without stopping development efforts. Sometimes business priorities change; a fixed length cycle allows developers to continue moving forward until the end of the iteration and change gears there. The start of a new iteration is never far away, so most businesses can wait until the next month rather than waiting till an unknown end of a sprint.

The Argument for a Variable Length Iteration

I’m trying to give this perspective a fair shake, even though I don’t subscribe to it; in a variable length iteration model allows business and development to scope out work at the beginning of an iteration and estimate a ship date regardless of the cycle or the calendar; the goal is to allow code to mature and be more stable. My friend subscribes to this model because:

Variable length iterations resemble traditional projects. There’s a scope estimate, requirements gathering, and work estimates (and traditional slippage). Most agile purists immediately scream “WATERFALL”, and there’s some truth to that, but a variable length iteration is comfortable to business. It’s like Mr. Roger’s house shoes.
They lend themselves to continual shipment of code. If the iterations are variable, developers can focus on one task from start to end, and begin to operate on separate iterative cycles; if you have a development staff of 5, you could theoretically have up to 5 separate iterations going on at the same time; when a developer finishes, they ship their contribution without waiting on the sprint to end.
This fragmentation of the iteration allows for sudden, non-disruptive change. If there are multiple iterations occurring for each independent block of code, and business needs change for one line, then only that line has to shift gears. There’s no impetus to wait; you stop where you are on the one piece, and move on to the next piece.

Your Choice?

I’d love feedback on this; as I’ve stated from the outset, I’m a fixed length iteration guy. What did I miss? Are there other benefits to the Variable Length model that I’m missing?

2015-08-11 by Stuart Ainsworth Blogging is FUN! Development SQLServerPedia Syndication 5

Where does my index live? YouTube edition–#SQLServer

I was recently contacted by Webucator, an online training services provider, and asked if they could turn a recent post of mine (#SQLServer – Where does my index live?) into a video. They are promoting their SQL Server classes by doing a free series called SQL Server Solutions from the Web using (with permission) different blog posts from around the web. Wish I’d thought of this sooner; enjoy!

2014-12-09 by Stuart Ainsworth SQL SQLServerPedia Syndication 0

#SQLPASS – Fluffy Bunnies

File:Fluffy white bunny rabbit.jpg I didn’t really have a good name for this post, so I thought I’d just try to pick something as non-offensive as possible. Everybody likes bunnies, right? Anyway, the last series of posts that I’ve made regarding the Professional Association for SQL Server has raised a number of questions that I thought I’d strive to answer; since I’m still mulling over my next post, I figured this was as good a time as any.

What’s your motivation in writing this series?

Believe it or not, I’m trying to help. For several years, it seems like there’s been one controversy after the other within the Professional Association of SQL Server, and those controversies dissipate and re-emerge. My goal is to document what I perceive to be the root causes for some of these issues so that we can work toward a solution.

Why are you bashing PASS?

I’m trying very hard to NOT “bash” the Professional Association for SQL Server; I’ve been a member for several years now, and I’ve seen controversies get personal. I really don’t feel like I’m doing that; I still believe that the Board of Directors are a great bunch of people that are making decisions based on their circumstance at the time. I’m trying to wrap a schema around those circumstances, so I can understand those decisions.

I’m trying to articulate my own perspective on what I think is wrong, so that I can be better prepared to have an honest discussion about those perceptions. Relationships aren’t about ignoring issues; the first step in addressing an issue is to identify the issue.

You mentioned “transparency” as an issue with the BoD before; what do you mean by that?

That’s more complicated to answer than I thought it would be. At first, I thought it was more information; as an active community member, I felt like I needed to be more involved in the decision-making process. However, I can’t really name a specific reform that I would make for the BoD to be more transparent. I don’t want to read meeting minutes, and most of the form letter emails I get from the Association go straight to the trash; I’m too busy for them to be transparent.

On further consideration, what I’ve been calling transparency is more about leadership and up-front communication than it is about revealing information. As an example, I help run one of the largest SQL Server chapters in the world; if I had realized that the Professional Association for SQL Server was planning a major re-branding exercise, I feel like I could have contributed some “notes from the field” on what that would mean, and how to best prepare our membership for it. Instead of appearing defensive about a controversy, the Board would appear to be very proactive.

It’s that feeling of being left out of the conversation that bothers me, I think. I realize that there’s some details that can’t be shared, but I feel like the onus is on the BoD to find better ways to communicate with members (and to me, chapters are an underused resources). The information flow is very unidirectional; Summit keynotes and email blasts are not an effective way to discuss an issue. Maybe those conversations are happening with other people, but if so, few people have stepped forward discussing them.

It’s also an issue of taking action when an issue is raised; for example, the recent passwordsecurity controversy was documented by Brent Ozar. He states that he and several other security-oriented members had several private conversation with board members, and yet no comprehensive action was taken until it became a public issue. The perception is that the only way to get the BoD to act is to publically shame them. That’s not healthy in the long run.

What’s your vision for the Association?

That’s the subject of my next post, so I’m going to hold off on that one. I do think that the unidirectional flow of communication is not just an issue with the organization, but that it’s a tone set by our relationship with Microsoft. As I pointed out in my last post, if the Association knew more about the needs and desires of the membership, that knowledge becomes a very valuable resource. Instead of being a fan club for a product, we could become strong partners in the development of features for that product.

How do you feel about the name change?

Frankly, I feel a little sad about the change in direction, but I understand it. I predict that SQL Server as on premise-platform is going to become a niche product, regardless of the number of installations. It just makes sense for Microsoft to broaden their data platform offerings. I do think that we (the Association) need to do a better job of preparing membership for this new frontier, and it’s going to take efforts to transform administration skills into analytic skills. Without providing that guidance, it seems like we’re abandoning the people who helped build this organization.

Where is this series headed? What’s the final destination?

To be honest, I don’t know. When I first started writing these posts, I was sure that I could describe exactly what was wrong, and suggest a few fixes. The more I write, the easier it is to articulate my observations; I’m surprised to find that my observations are not what I thought they would be. Thanks for joining me for the ride; hopefully, it leads to some interesting conversations at Summit.

2014-10-23 by Stuart Ainsworth Blogging is FUN! PASS SQL Server SQLServerPedia Syndication 8

#SQLPASS–Data Professionals?

So, in my last post, I described the financial pressures of community building; two companies benefit from building a community organization. I’ve tried to stay away from assumptions, but I am assuming that their influence must factor into the Board of Directors’ decision making process (Microsoft has a seat on the board; C&C is dependent on the decisions that the BoD makes). The metrics that matter most to Microsoft are the breadth of people interested in their product line, not the depth of knowledge attained by those people.

Influence isn’t a bad thing per se, but in my mind, it does explain why good people continue to make bad decisions, regardless of who gets elected to the board. What do I mean by a bad decision? In general, the Professional Association for SQL Server BoD remains a non-committal and opaque organization. Board members have personally promised me that “they would look into something”, and yet the follow-thru never materialized; the opacity of the decision making process is documented by other other bloggers in posts like the following:

http://www.sqlservercentral.com/blogs/steve_jones/2010/06/30/pass_2C00_-don_1920_t-waste-my-time/

https://ozar.me/2014/09/bigger-passvotes-problem-password-shared/

http://sqlblog.com/blogs/andy_leonard/archive/2014/06/27/pass-and-summit-2014-session-selections.aspx

SIDEBAR: I will say that the Board continues to work on the transparency problem; Jen Stirrup and Tom LaRock have both stepped forward to explain decisions made. However, such explanations are usually given after a controversy has occurred.

For a specific example, I want to focus on the branding decision (the decision to remove SQL Server from marketing material for the Professional Association of SQL Server and to be know simply as PASS); the decision to move the organization away from its lingua franca of SQL Server to a new common language of “all things (Microsoft) data” is not in and of itself a bad thing. Recent marketing trends from Microsoft indicate that the traditional role of the DBA is continuing to evolve; as individuals, we need to evolve as well.

However, as database professionals (or data professionals), we should be inclined to make decisions based on data. As Jen Stirrup herself says:

I think it’s important to have a data-based, fact based look at the business analytics sphere generally. What does the industry say about where the industry is going? What does the data say? We can then look at how PASS fits in with this direction.

Jen’s post goes on to state some great statistics about the nature of the industry as a whole, but then uses some less concrete measures (growth of the BA/BI Virtual Chapters) to identify support within the organization. I generally agree with her conclusions, but I’m concerned about several unanswered questions, most of them stemming from two numbers:

Association marketing materials claim we have reached over 100,000 professionals, and
11,305 members were eligible to vote (a poor measure of involvement, but does indicate recent interaction).

I look at those two numbers and wonder why that gap is there; just for simplicity’s sake, let’s say that 90% of “members” have not updated their profile. Why? What could the Association have done to reach those members? Who are those members? What are their interests? What’s a better metric for gauging active membership?

Of course, once I start asking questions, I begin to ask more questions: How many members don’t fit into Microsoft’s vision of cloud-based computing? How many members use multiple technologies from the Microsoft data analysis stack? What skills should they be taught? What skills do they have? What features do they want? The short answer: we don’t know.

As far as I know, there has been no large scale data collection effort by the Board of Directors to help guide their decisions; in the absence of data, good managers make a decision based on experience, but then strive to collect data to help with future decisions. Continuing to rely on experience and marketing materials without investing in understanding member concern, desires, and input is simply put, a bad decision.

Shifting an organization that shared a common love for a particular technology to an organization that is more generally interested in data is a huge undertaking; overlooking the role that the community should have in determining the path of that transition is an oversight. I don’t think the Professional Association for SQL Server is going to revert back to a technology-specific focus; that would be inconsistent with the changing nature of our profession. However, the Board needs to continue to understand who the membership is, and how the organization can help a huge number of SQL Server professionals transition to “data professionals”. Building a bigger umbrella may help the organization grow; investing in existing community members will help the organization succeed.

2014-10-21 by Stuart Ainsworth Blogging is FUN! PASS SQLServerPedia Syndication The Social Web 7

#SQLPASS–Who’s Making It Rain?

As promised in my previous post (#SQLPASS–Good people, bad behavior…), I’d like to start diving in to some of the controversies that have cropped up in the last year and critically analyze what I consider to be “bad decisions”. This first one is complex, so let me try to sum up the players involved first (with yet another post to follow about the actual decision). Please note that I am NOT a fan of conspiracy theories (no evil masterminds plotting to rule SQL Server community), so I’m trying to avoid inferring too much about motive, and instead focusing on observable events.

A lot of the hubbub over the last couple of weeks about the Professional Association for SQL Server wasn’t just about the election or the password controversy, but about the decision to become simply PASS in all marketing materials (gonna need a new hashtag for twitter). So much controversy, in fact, that Tom LaRock, current Board President, wrote an excellent blog post about building a bigger umbrella for Mike. I applaud Tom for doing this; it’s a vision, and that’s a great thing to have. However, I wanted to take this metaphor, and turn it on its side; if we need umbrellas, then who’s making it rain? Let’s take a look at the pieces of the puzzle.

Community as Commodity

To figure out the rainmakers, we need to define what the value of the Professional Association for SQL Server is. If you’re reading this post, I bet you can look in a mirror and figure it out. It’s you. Your passion, your excitement, your interest in connecting and learning about SQL Server is the commodity provided by the organization. We (the community) have reached a certain maturity in our growth as a commodity; we recruit new members through our enthusiasm, and we contribute a lot of free material to the knowledge base for SQL Server. At this point, it’s far easier to grow our ranks than it would be to start over.

However, the question I would ask is: what do YOU get out of membership? For most of us, it’s low-to-no cost training (most of which is provided by other community members). The association provides a conduit to connect us. The value to you increases when you grow. Exposure to new ideas, new topics, a deeper understanding of the technology you use; all of these are fuel for growth. In short, as individuals, community members profit most from DEPTH of knowledge.

The more active you are in the community, the more likely you’ll be able to forage out valuable insight; how many of you are active in the Professional Association of SQL Server? According to this tweet from the official twitter account, 11,305 people have active profiles with the organization. While that’s not a great metric for monitoring knowledge seekers, it does provide some baseline of measure for people who care enough to change their profiles when prompted.

Microsoft Needs A New Storm

The Professional Association for SQL Server was founded to build a community of database professionals with an interest in learning more about Microsoft SQL Server; the founding members of the organization were Microsoft and Computer Associates, who obviously saw the commodity in building a community of people excited about SQL Server. The more knowledge about SQL Server in the wild, the more likely that software licenses and training will increase. Giving away training and knowledge for a lost cost yields great dividends in the end.

This is not a bad thing at all; it’s exciting to have a vendor that gives away free stuff like training. However, it appears that Microsoft is making a slight shift away from a focus on SQL Server. What makes me think this?

It’s getting cloudy (boy, I could stretch this rain metaphor): software as a service (including SQL as a service) is a lot more profitable in the long run than software licensing. By focusing more on cloud services (Azure), Microsoft is positioning itself as a low-to-no administration provider.
Electricity (Power BIQuery): Microsoft is focusing pretty heavily on the presentation layer of traditional business intelligence, and touting how simple it is to access and analyze data from anywhere in Excel “databases”. Who needs SQL Server when your data is drag-and-drop?
The rebranding of SQL Server Parallel Data Warehouse: Data warehouse sounds like a database; Analytics Platform System sounds sexier, implying that your data structures are irrelevant. Focus on what you want to do, not how to do it.

The challenge that Microsoft faces is that is has access to a commodity of SQL Server enthusiasts who don’t exactly fit the model of software-as-a-service; those of us that are comfortable with SQL Server on premise haven’t exactly made the leap to the cloud. Also, many DBA’s dabble in Excel; they’re not Analytics practitioners. In short, Microsoft has Joe DBA, but is looking for Mike Rosoft (see what I did there?), the Business Analyst. Mike uses Microsoft tools to do things with data, not necessarily databases. The problem? Mike doesn’t have a home. In order to maximize profits, Microsoft needs to invest in the growth of a larger and more diverse commodity. In short, Microsoft wants a BROADER audience, but they want them to be excited and passionate about their technology.

Rain Dancing With C&C

The Professional Association for SQL Server has been managed by Christianson & Company since 2007. While the Professional Association for SQL Server Board of Directors is made up of community volunteers, C&C is a growing corporation with the traditional goal of any good for-profit company: to make money. How does C&C make money? They grow and sell a commodity. If the Professional Association for SQL Server grows as an organization, C&C’s management of a larger commodity increases in value. As far as I can tell, the Professional Association for SQL Server is C&C’s only client that is managed in this way.

The community gets free/low-cost training; C&C helps manage that training while diverting the cost to other players (i.e., Microsoft and other sponsors). If Microsoft is looking for a broader commodity, C&C will be most successful if they can serve that BROADER audience. The Professional Association for SQL Server’s website claims to serve a membership of 100,000+; that number includes every email address that has ever been used to register for any form of training from the association, including SQLSaturday’s, 24HOP, and Summit. Bigger numbers means increased value when trying to build a bigger umbrella.

Yet, this 100,000+ membership is rarely reflected in anything other than marketing material. Only 11,305 of them are eligible to vote; less (1,570) actually voted in the last election. 5,000 members are estimated to attend Summit 2014. Perhaps the biggest measure of activity is the number of attendees at SQLSaturdays (18,362). Any way you slice it, it seems to me that the number of people that are actively seeking DEEPER interactions are far fewer than the BROAD spectrum presented as members. Furthermore, it would seem that reaching more than 100,000 members is challenging; if only 11,000 members are active in the community, and they’re the ones recruiting new members, how do you keep growing? You reach out to a different audience.

Summary

I feel like it’s important to understand the commercial aspect of community building. In short:

Microsoft needs to reach a broader audience by shifting focus from databases to simply data;
Christianson & Company will be able to grow as a company if they can help the Professional Association for SQL Server grow as a commodity;
The community has reached critical mass; it’s far easier to add to our community than it would be to build a new one.
The association has reached several members of the community (100,000+); far fewer of them are active (11,305).

Where am I going with this? That’s coming up in my next post. While I don’t deny the altruism in the decision by the Board of Directors to reach out to a broader audience, I also think we (the commodity) should understand the financial benefits of building a bigger umbrella.

2014-10-20 by Stuart Ainsworth Blogging is FUN! PASS SQLServerPedia Syndication 12