Search results matching tags 'Opinion' and 'DBA'

Demo Mastery for the Technology Evangelist

KKline — Fri, 15 Feb 2013 17:02:00 GMT

In the same way that the finest presentations involve much more than the simple relaying of information, the finest software demos are much more than just presenting features.

REMEMBER: The goal of a demo is to INSPIRE the audience to use the software/technology, not to teach them every nuance of software/technology.

I've spent the last 10 years learning how to give good presentations and to give good software demonstrations. Here are several tips to take your software demonstration from informative to masterful:

1. Know your audience

Whenever you start a demo, make sure you have a good idea what the audience is interested in. That way you can focus the attention of the audience upon things that actively engage their imagination. You really, really want the audience to be thinking about how they're going to use the software that you are presenting. If it if you're not presenting on something that they're interested in, they'll mentally disengage. In some cases you'll even see them open their laptops and start to answer emails. That's the last thing in the world that you want to happen.

In many cases, I'll begin a presentation by asking my audience to tell me more about themselves. I want to know how much of their time is spent as a developer, as a DBA, as a designer. If nothing else, I can change the sort of examples that I use to be tailored specifically to the audience that are presenting to.

Truly bad software demos have problems. The code doesn't work. The beta software crashes. The screen shows the dreaded blue screen. But that's one thing. What you really want to avoid, is the truly mediocre software demo. The quickest path to a mediocre software demo is to simply show every feature and explain each in as much detail as you can. It's like those games that sit in our closet that no one likes to play. Most all of these games are ones in which one person takes a turn while everyone else waits. No one has any fun except for the three or four minutes in which it relates directly to them.

2. Start, but only start, with an agenda

It's always a good idea to inform your attendees of what you would like to present. What you present the agenda it's a great idea to confirm that this agenda is what the audience is looking for. Before I learned to do this on a regular basis, I found that my presentation might contain two or three lengthy sections of my software demo which were completely uninteresting to the audience. The customer is really numbed by this waste of time. It's far better to tell the audience what you are going to tell them.

Here's my routine when I start a demo. Confirm that your agenda is of interest to them and recheck the time constraints of the meeting. Then, get to what they are interested in. This flexibility also provides you the opportunity to inject other software demonstrations that are much more pertinent to your audience. Audiences love a presenter who can think on their feet and are flexible to the interests of the audience.

3. Skip the lengthy intro

This is a aspect of demonstrations and presentations that I struggle with. I worried a lot that I hadn't demonstrated enough credibility with my audience. And so for many years of my technology evangelism role, I spent a lot of time telling the audience about myself and about the company. What I found over time though, is that audiences actually give you an initial dose of credibility. It's up to you to maintain and even enhance that credibility through a strong demo and a good presentation. Better to have a very short introduction and get straight to the meat of the presentation.

Call out - Mouse Cursor Movement: It's especially important to remember in online demos that there is usually a great deal of latency between what you do on your screen and what your audience sees on their screen. So it's important to remember to MOVE YOUR MOUSE SLOWLY AND THOUGHTFULLY! I've sat in online webcasts, and even in in-person events, where the mouse literally disappeared on one section of the screen and reappeared elsewhere because the presenter was moving their mouse cursor here, there, and everywhere. If you want the audience to see what you're doing with the mouse cursor, keep it slow.

4. Show what is pertinent

One of the most important things a software evangelist can do is to show the most important and pertinent take away of their software. Let's you are trying to teach an audience about the extreme ROI (return on investment) of a particular kind of business intelligence strategy, it's crucial that you figure out in advance what are the key takeaways that you would like your audience to remember. Typically in audience will only remember two or three very salient points about your demo. If the BI presentation spends the first 30 minutes showing how to build a report but never once mentions ROI, what do you think the audience will remember? Once you know what is pertinent to your audience and what you want the key takeaway to be, you should focus the rest of your energies on building an airtight demo that supports those takeaways.

You will see the inverse of this many times in a mediocre or poor demo. At the end of the demo the audience will feel like they have sat through product training, rather than a call to action that inspires them to use the product. I've sat through demos in which the presenter carefully walk through several different menus, tabs, and wizards. And after 30 minutes of that, I now knew HOW to use the software, but I still didn't know WHY I would use the software.

In the worst cases, showing everything that your software can do may leave the audience feeling that it is too complex, too detailed, or too overwhelming for them to use effectively. Remember that a software demo is not design to train the audience. A software demo is designed to inspire the audience to use your products.

5. Don't get sidelined

We usually get sidelined in our demos by two things: questions from the audience and "technical difficulties" a.k.a. bugs.

Questions from the Audience

It's usually a good sign if your demo is provoking questions from the audience. However, you don't want to demo to turn into free consultation to solve one person's problem. Nor do you want to turn into fact-finding for one very narrow set of interests or to become the arbiter of some sort of political dispute between factions in the audience.

When taking questions, remember to repeat the question to the audience. This ensures that you fully understood the question, that the questioner asked for what they meant, and that if there is any recording going on the question will be picked up by the recording system.

But my typical rule of thumb is to only spend a couple minutes on a single question and questioner. Once a single questioner goes beyond a couple minutes, you can usually tell if you're heading for the sidelines. It's at that point that I asked the questioner if we can take the question off-line and come back to it afterwards so that everyone else can benefit from the time that we have set aside right now.

Technical Difficulties

Another form of sidelining are bugs in the software and outright crashes of your demo environment. Many times this simply can't be avoided. This is especially true if you are demoing a beta version of the software. But there are couple important things to remember if you are sidelined by a bug or crash.

First, mention if you're using a beta and that it might not be fully stable. Also, be sure to mention that the software WAS stable when you prepared the demo. Second, test your demo after conducting a full reboot of your demo environment. I've seen many demos crash because the presenter made other changes in the environment but only tested for the software demonstration itself. Third, Don't draw attention to bugs that you encounter during the demo, especially if they're just cosmetic. It's important not to do things like slap your four head and exclaim "what the hell is that?" If it's a bigger bug that hampers or interferes with functionality, you might state that it's normal functionality is… XYZ. Finally, if you experience a major bug or crash, immediately disconnect the projector or the desktop sharing application. There's nothing worse than seeing a presenter struggle with the bug in front of the entire audience.

6. Hit the jackpot

All good jokes have a punchline. All good action movies have a climax. All good newspaper stories have a headline. Your demo needs to have a jackpot, where the audience can clearly and immediately see how your software pays off.

Let's say you're doing a demo of the new columnstore features in SQL Server 2012. You could spend a lot of time showing the conceptual underpinnings of a columnstore index. You could show the state was to create columnstore indexes, to modify them, to drop them. You could admonish the audience and ways to build read-write systems so that they can easily get data into and out of columnstore indexes.

But what's the real payoff of a columnstore index? It is incredible fast for a particular kind of scenario on SQL Server. So in this example, your jackpot is to show how difficult that scenario is under normal circumstances and then immediately show how easy and fast it is with the columnstore index. Bingo! Your audience is hooked. They immediately see why they want this. There inspired to start using it. Now, they want to figure out how to use it and want to know when and under what conditions they should use.

Are you an SC, technology evangelist, or technology presenter? What are your tips for a better demo?

-Kevin

-Follow me on Twitter

PASS Summit 2012, Day 1

KKline — Thu, 08 Nov 2012 15:18:00 GMT

One of the most positive experiences I can have, as a former leader of the PASS organization, is when I see a neophyte become a passionate support and champion for the community. On my first day in Seattle, before the event had even begun, I was stopped several by people who'd attended their first PASS Summit last year. But this year, they were excited to tell me that they'd started user groups in their own community, spoken for the first time at a PASS event, or even helped launch a SQL Saturday event.

Wow! To go from a complete newcomer in the PASS community to an active and engaged community chapter is a major achievement!

Many years ago, the founding board of directors wrestled with the major issues of how to attract new members at the same time while lacking major funds to create services and offerings attractive to SQL Server professions. Compared to other major professional IT associations, we simply lacked the money to do the cool things that we saw happening elsewhere.

But one of the things that we settled on is that, while we didn't have the money to put on a big dazzle-dazzle conference or to publish hard-bound conference proceedings, we could simple be a more giving, supportive community. Being more friendly, more encouraging, more supportive. Those were things that we could excel at which would cost us nothing.

In those days, I have to admit, it wasn't really a difficult calling to be the 'more' friendly professional association. With board members like Kurt Windisch, Joe Webb, Stefanie Higgins, and Wayne Snyder, being friendly came naturally. As new board members, like Rushabh Mehta and Bill Graziano and Tom Larock and Andy Warren, joined the leadership the idea of openness and friendliness became an institution ideal.

By 2006, the concept of 'sqlfamily' wasn't simply something we aspired to, it was an integral part of our culture. I can recall plenty of decisions being settled with the question of "Does this decision make our community more inclusive or not?" If it didn't, then we didn't do it. At other times, in the face of conflict, we asked ourselves "What's the high road? What's the right thing to do?" Our intent wasn't to do what was most advantageous, the most expedient, or the least costly, especially if we had to compromise on our ethics. Do what's right. Do what is helpful to our people. And then don't look back.

That certainly doesn't mean that we made all of the right decisions or that there weren't any situations where we wouldn't do it differently if we could do it again. But it did ensure that, when we made a mistake, we didn't have too many regrets.

So here we are in 2012. How has that early initial decision to focus on building a community of care panned out? The association now has 126,000 members, with more than 300 chapters around the world, and more than 60 yearly SQL Saturday events per year. The annual Summit is more than 300% bigger than our first event, with about 100 more sessions over the course of three days.

And, in my opinion more importantly, I'm being stopped on the street by people to tell me how excited they are to have started a new user group, spoken at an event, or attended a conference. It's in these moments that all of those hard years of work on the PASS board are crystallized as a valuable and worthwhile. Those decisions are still paying dividends today. The spirit of SQLfamily is stronger than ever!

Enjoy!

-Kev

P.S. I'll be speaking on Thursday and Friday at the event. Come see me!

Timewarp: What Is a Relational Database?

KKline — Wed, 05 Sep 2012 19:23:00 GMT

Relational?!? Move On, Geezer!

Maybe you're thinking that relational databases management systems (RDBMSs), like Microsoft SQL Server and Oracle, are going the way of punched cards and rotary phones. After all, there's been a lot of hype these days in the IT media about the rise of so-called NoSQL (Not Only SQL) databases. Many new and upcoming CS and MIS graduates who like working with data might think that relational databases are, at best, soon-to-be legacy systems and, at worst, are a career dead-end.

Wrong!!!

It's true that all the cool-cat computing services (Amazon, Facebook, Google, Pinterest, etc) are indeed making heavy use of NoSQL technology. They're also making heavy use of traditional RDBMS'es too. In fact, some of the world's biggest users of SQL databases are hand-in-hand the biggest users of NoSQL databases. The reason for that is that both types of data platforms are exceeding good at specific types of data storage and data processing. They also have their own unique weaknesses too. Meaning, each platform has a sweet spot and a weak spot, and that none are a 100% panacea for all imaginable data processing scenarios. Take a look at this article by my friend and former colleague, Guy Harrison - 10 Things You Should Know About NoSQL Databases, for a good discussion on the pros and cons of NoSQL in comparison to SQL data platforms.

Timewarp! Let's Take a Look Back at Why Relational Databases Were Needed.

These days, relational database management systems (RDBMSs) like Microsoft SQL Server and Oracle are the primary engines of information systems everywhere, particularly for enterprise computing systems and web applications. Though RDBMSs are now common enough to trip over, it wasn’t always that way. Not too long ago, you would probably trip over hierarchical database systems, or network database systems, or flat-file systems (heck, that still happens in many government IT shops who still use COBOL). A quick-and-dirty definition for a relation database might be: a system whose users view data as a collection of tables related to each other through common data values.

Perhaps you are interested in more than a quick-and-dirty definition for the term relational database? Here goes. The whole basis for the relational model follows this train of thought: data is stored in tables, which are composed of rows and columns. Tables of independent data can be linked, or related, to one another if they each have columns of data that represent the same data value, called keys. This concept is so common as to seem trivial; however, it was not so long ago that achieving and programming a system capable of sustaining the relational model was considered a longshot with limited usefulness.

Relational data theory was first proposed by E.F. Codd in his 1970 paper to the ACM entitled “A Relational Model of Data for Large Shared Data Banks”. Soon after, Codd clarified his position in the 1974 paper to the Texas Conference on Computing Systems entitled “The Relational Approach to Data Base Management: An Overview”. It was in this paper that Codd proposed the now legendary 12 Principles of Relational Databases.

If a vendor’s database product didn’t meet Codd’s 12 item litmus tests, then it was not a member of the club. Note that the rules do not apply to applications development. Instead, these rules determine whether the database engine itself can be considered truly “relational”. These rules were constructed to support a data model that would ensure the ACID properties of transactions and also eliminate a variety of data manipulation anomalies that frequently occurred on non-relation database platforms (and still do occur on non-relational database platforms). (As an aside, the transactional paradigm was conceived by my hero, Gray, Jim in 1981 while at Tandem Computer and presented in the paper "The Transaction Concept: Virtues and Limitations").

Codd’s 12 Rules for a Truly Relational Database System

Are you curious about Codd’s 12 Principles of Relational Databases? Don’t be ashamed that you don’t know them by heart; few technology professionals do, and no one on the marketing staff of technology companies do. However, the few folks who do know these principles by heart treat them like religious doctrine, and would likely be mortified by their “lightweight” treatment here. Nevertheless, I'll give them to you in my own paraphrasing:

Information is represented logically in tables.
Data must be logically accessible by table, primary key, and column.
Null values must be uniformly treated as “missing information” not as empty strings, blanks, or zeros.
Metadata (data about the database) must be stored in the database just as regular data is.
A single language must be able to define data, views, integrity constraints, authorization, transactions, and data manipulation.
Views must show the updates of their base tables and vice versa.
A single operation must be able to retrieve, insert, update, or delete data.
Batch and end-user operations are logically separate from physical storage and access methods.
Batch and end-user operations can change the database schema without having to recreate it or applications built upon it.
Integrity constraints must be available and stored in the metadata, not in an application program.
The data manipulation language of the relational system should not care where or how the physical data is distributed and should not require alteration if the physical data is centralized or distributed.
Any row-processing done in the system must obey the same integrity rules and constraints that set-processing operations do.

If you know much about SQL, then you probably recognize immediately that SQL ended up fulfilling rules #5, #7, #11 and possibly more. Others of the rule are manifest in the system tables of a relational database, such as DMVs in Microsoft SQL Server and V$ and X$ views in Oracle.

Relational Rises

There is some debate about why relational database systems won out over hierarchical and network database systems back in the late 1980's and early 1990's, but a couple of reasons seem self-evident. First, the high-level language interface (SQL) is much simpler to learn and more intuitive than that mishmash of languages supporting non-relational databases. (In fact, the lack of something like SQL is a hindrance to adoption of many NoSQL database platforms). Second, relational databases provide efficient and intuitive data structures that easily accommodate ad-hoc queries and reporting. People just intuitively understand the value of storing data in tables. From phone books to hotel registries, relational databases (of the paper sort) are second nature to most people. Third, relational databases provide powerful integrity controls such as check constraints and referential integrity - thus providing higher quality data. And high quality data is near and dear to the heart of CFOs around the world.

In fact, the strength that relational databases demonstrate with data quality, consistency, and durability are the same reasons that they'll be with us - quite possibly - forever. So were NoSQL databases excel at storing data that is moderately important and requires eventual consistency, SQL database excel at storing data that is of paramount importance and requires immediate consistency. As long as we're exchanging money, there's a need for relational database technology and ACID transactions.

And, just my opinion here, but database administration is currently, and will continue for decades to be, an excellent career choice. Why? First, although databases are widespread, good databases are not. So there's always need for those who can tune, troubleshoot, and optimize what is currently in the marketplace. Second, just because database are widespread doesn't mean that they're everywhere they need to be. Some estimates gauge that only half of the enterprises that need SQL databases actually use SQL databases. Imagine if only half of the citizenry wore shoes, and of the half that wore shoes, only half of them wore both shoes and consistently tied them. It'd be a good time to be a maker of loafers! Well, that's where we're at today with relational databases.

So what do you think? Am I off the mark on the longevity of relational database? Do you think the sun has set on them? Will they be smashed, degraded, and humiliated by NoSQL database platforms? Or will they stand shoulder-to-shoulder with a variety of data platforms in the years to come?