You Should Be Using Two-Factor Authentication. Everywhere.

We’re not very good with passwords, although we think we are. According to a recent study by security company CSID, 89% of us think we practice safe password routines. Unfortunately, 1 in 5 of us have had an online account compromised and yet only about half of us change our passwords more frequently than once per year. The best passwords typically utilize a combination of letters, numbers, and punctuation, and the longer they are the better (at least 8 characters). Only 6% of users have passwords that meet these criteria. Even worse, 60% of us reuse the same password for multiple sites. This is a recipe for disaster.

Here’s a quick scenario: Tommy has a forum account on a fan-made music site. The music forum that he visits regularly doesn’t maintain their security patches regularly, and a random hacker manages to hack into the site and steal his password. A simple web search reveals that Tommy works for Company X. Company X uses the Outlook web app, and wouldn’t you know it, Tommy uses the same password everywhere. Through a little trial and error, the hacker discovers that tommy@companyx.com is his work email, and boom, the hacker now has access to Tommy’s work email.

So what is two-factor authentication, and how does it solve this problem? Well, two-factor authentication (2FA) is a multi-stage method of verifying that you are who you say you are. Typically it’s a combination of something you know (a password), and something you have access to (a phone). Most commonly, the second factor of authentication will be a code that you will be sent through a text message or an automated phone call, and it’s only valid for a short period of time. This code will be entered on a secondary screen before you can have access to your account.

Unfortunately a lot of people don’t know what 2FA is – roughly 75% of people surveyed didn’t have a clue. It has also garnered a reputation for being a hassle, which is simply not the case. Most two-factor implementations will allow you to “register” a device as a “trusted device” for a period of time (typically ranging from a day to a month). I know what you’re probably thinking – what if I lose my phone? Then what? Well, the answer to that is “it depends.” Every two-factor implementation has different ways to handle account recovery in the event of a lost device, but this shouldn’t deter you from using 2FA – the benefits outweigh the risks by far.

So where are some common places you should start using two-factor authentication to protect your online accounts? Here’s a list:

  1. Google: Sends a 6 digit text message when you attempt to login from a new device. They also provide a Google Authenticator app for Android, iOS, and BlackBerry that can be used to obtain the second factor authentication codes.
  2. Apple: Sends you a 4-digit code via text message or Find My iPhone notifications when you attempt to log in from a new machine.
  3. Facebook: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  4. Twitter: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  5. PayPal: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  6. Microsoft Accounts: Sends you a 7-digit code via text message or email when you attempt to log in from a new machine.
  7. Yahoo! Mail: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  8. LinkedIn: Sends you a 6-digit code via text message when you attempt to log in from a new machine.
  9. WordPress: Utilizes the Google 2FA app.

For a more complete list of companies and products that support two-factor authentication, please review Evan Hahn’s list. Ask your local security or IT professional if your organization could benefit from using 2FA for email or work accounts. There are also ways to implement two-factor authentication into your own custom applications and web sites.

Passwords are becoming less secure all the time, and hackers are getting better at cracking them (check out the strength of your password). Enabling two-factor authentication provides an extra layer of security at a negligible cost. Protect your financial accounts, identity, and your career by using it wherever you can.

Why Gmail is Great – It’s Software Developed With the End-User in Mind

Technology in our daily lives is ever-expanding, so it should follow that software development companies are absolutely booming – in fact, MarketLine states that the global software market is expected to grow to a whopping $357 billion dollar industry by 2015, which is quite a boost from the $265 billion total from 2010. Companies already deep in this industry will certainly want an edge over their competition, and there’s no better way to gain the trust of their customers than building great software.

When you think examples of truly magnificent software, what springs to mind? For me, Gmail takes the cake – a simple yet intuitive piece of software that makes the mundane task of writing and organizing e-mail truly effortless. Every aspect of the software is designed to be as easy-to-use as possible, while providing the ability to use a wide array of features. Many times it’s difficult to strike a balance between simplistic design and power, but Gmail hits the nail on the head.

tabs

One thing separating Gmail from the other e-mail services out there is their recent implementation of category tabs. I have to admit, when this feature was released, I wasn’t thrilled – my knee-jerk reaction was something along the lines of “Why complicate things by dividing my inbox? Why fix what’s not broken?” Oh, how young and foolish I was – this feature has quickly become one of my favorite aspects of Gmail, allowing me to quickly jump to different categories. Do I want to check out all of my social media updates? One click of the “Social” tab will do that! How about any promotional e-mails outlining that day’s sales? You guessed it, just hit the “Promotions” tab. Additionally, you don’t even have to specify which e-mail is sorted under which tab – Gmail does it automatically. Brilliant!

If you’ve ever mentioned attaching something in Gmail, and then completely forgot to attach it, you’re greeted with the following message:

attachfiles

This likely didn’t take much time to develop at all, yet has likely saved many people from looking foolish (first-hand experience here). While it isn’t likely to make or break which e-mail service you choose, these details really impresses you when you need them.

It’s this kind of usability that gives me confidence in Google’s software – I’d be more willing to try software that they develop, since I’m comfortable with the kind of work they do from prior experience. On the flip-side, had my Gmail experiences been full of frustration or lacked the features that I’ve come to expect, maybe I’d check out alternatives – in fact, it was my frustration with Yahoo!’s services that led me to leaving it behind in the first place. The bottom line – usability matters, and if you aren’t able to put out simple software with powerful features, your customers will find someone else who can.

Consistency is Key!

A successful software development project is one that maintains consistency.

Whenever I visit a site or application that lacks consistency, it makes me uncomfortable. If each page acts differently from the others, it can end up confusing the user and feeling and looking poorly developed and unprofessional. A good development coding standard can help ensure a high level of consistency throughout an application and, once in place, these standards need to be followed. In the end, a good developer needs to make sure his/her final output reflects the standards and is built in a consistent, user-friendly way.

Another reason to adhere to a consistent, standard approach when developing a new application? Without it, the ongoing maintenance of the application will become cumbersome. If five developers are all coding differently, in their own style, you’ll eventually end up with an application that won’t lend itself to easy maintenance and might not function properly in the long run.

Remember, software often ends up being maintained by people who weren’t involved in the initial development of it! If you’ve ever been responsible for the upkeep on an application that was built with little adherence to quality standards, you know—it’s no fun! If the cost to upgrade or improve an inconsistent application becomes too high, it could force the client in a different direction.

I remember supporting an old ASP 3.0 application that was generally using the same connection information in a standard configuration file but had a few forms using hard coded values for the connection information. I couldn’t understand why, all of the sudden, some of these were breaking when my database information changed. This should have been a quick change to the configuration file, but turned out to be a pain!

When building front-end user interfaces, make sure you’re putting on your “end user” hat before you start working. When building out forms, do so in a consistent manner. If you have grids with search results on a screen, make sure all those grids are reporting the same data, and the same options, in the same way. Make sure all dates are displayed in the same format. All numeric/monetary fields should display consistently. Buttons with the same underlying logic should have labels that are consistent so the user can understand, from screen to screen, that button does the same job or accomplishes the same function. Make sure your form controls are organized in a pleasant manner—one that’s easy on the eyes and that can be tabbed through quickly. If it’s a data entry screen that users will be spending hours on each day, make sure the controls are aligned and sized properly allowing users to keep their focus on one part of the screen and providing a better overall user experience.

Before you start developing, take a look around! Review some of the screens in the system—there should be a common theme to the user interface; follow the same approach. Take a look at messaging and make sure you’re reporting information to end users in the same way. It won’t take long to get familiar with the site and then, once you start building your new feature, you’ll have a good context as to what it should look like. When you’re done developing, the new feature should look like existing ones.

One last note when testing your development—people still use IE! Do some browser testing to make sure your site is looking good and functioning well in the major browsers. If you’re only developing and testing only in your personal favorite, you’re not doing a full test. Sometimes, there are specific client requirements for the system you’re working on, so be sure you know what they are before you start. Some internal applications are written strictly for IE. Are there mobile requirements for this application? If so, be sure you’re testing those as well.

In the end, making sure your software development is done in a consistent matter is better for everyone in the long run. It will ensure the end product looks and feels like a well thought-out, professional piece of work!

The Corporate Dashboard

In this post, I’d like to talk about the good fundamentals of dashboard design. There’s an important item that separate a bad dashboard from a great one. It’s called a “Key Performance Indicator” or KPI. When we discuss KPIs, we are usually talking about something like “Income forecast” or “Employee productivity rates.”

The most important part of the KPI acronym is the “K” for “Key.” Key means it’s supposed to be important but all too often, I’ll hear:

“I want a dashboard with 50+ KPIs that can quickly show me the health of my company at a glance.”

Remember, the “K” stands for “Key.” Do you really need more than 50 indicators to “quickly” show the health of your company or department? Are there really 50 plus things that are “key” to your review? Can you even review 50 of anything “at a glance?” Really?

As an example, let’s take a look at a “Dashboard” with only a few KPIs versus one with lots of KPIs and see which is better suited to give us an “at a glance” view of the status of our company:

While each of these dashboards shows information that’s likely very important to the user and the health of the system, there’s an obvious difference in the amount of information being displayed and each is intended for a different kind of user.

The first is clearly a dashboard from a plane, specifically a B-58, and it has a ton of indicators and gauges. This type of dashboard can certainly be overwhelming to someone who’s not a pilot and hasn’t undertaken the significant training needed for its effective use. Now, this doesn’t mean there are too many KPIs on the dashboard, it just means that the process that the user is attempting to navigate is very complex and requires a high level of expertise. It would not be expected that someone viewing the dashboard would be able to tell the status of the plane in “at a glance.” If you really dug into it, there are probably only a few “Key” indicators on the board and lots of additional indicators that will help the pilot track specific information, look for particular problems, or do their job in emergency situations.

The second dashboard is from a BMW M series. It has two large dials for the Speedometer and the Tachometer and a few indicator lights for important factors like “Door Open” or “Check Engine.” This type of dashboard requires a much lower level of training to understand and interpret and only offers KPIs that tell the user how the car is performing in its primary objective–moving–and if there are any significant problems like a lack of gas or increased oil temperature. And it’s pretty important to realize that your car door is open when you’re driving along at 60 miles per hour! There are hundreds of other metrics that could be useful to different users (i.e. the car technician or the racing enthusiast) but they’re not “Key” performance indicators needed to simply drive the car and they can be retrieved in other ways.

Now, both of these dashboards accomplish their goal of providing all of the information that the user needs at their fingertips. But as I’m sure you could guess, the B-58 dashboard costs a lot more, because it’s more complicated in its design, its build, and its output.

If you’re considering building a dashboard, you must start by defining who your audience will be and what information they’ll need “at their fingertips” to be successful. Most dashboards only need a few metrics/gauges; the bulk of the effort should be spent on important things like that “Oil Temp” light. Define the rules to indicate that there are problems and then allow the dashboard to work for you. 

In an effort to collect some input from the readers, please comment below if your company has a dashboard. How many KPIs do you think are enough?

Self-Help and What It Means to the Future of Customer Service

Self-help–it’s the sort of thing that everyone wants to be able to do in order to be the most efficient they can be without having to bug someone else or take more time out of their already busy day to track down assistance.  Self-help is becoming the norm in everyday customer service, across many different technology platforms.  But, the question that has yet to be answered is, will the general public accept the self help model of service?  The answer is, if implemented correctly, yes, because it will increase productivity and make customers feel empowered–able to assist themselves without having to ask anyone else for guidance and without having to wait around for answers or instructions.

I can’t tell you how many times I have heard people complain about having to speak to a Help Desk representative because they often sound like they’re just reading from a script, giving no real advice and providing no real insight. Experiences like these offer very little to instill confidence in a customer about the level of service they’re receive.  By giving customers the option of self-help, we’re putting them in the driver’s seat. They can resolve issues for themselves and feel the pride that’s inherent in fixing something on their own.

Support professionals need to be creative in identifying and creating opportunities for customers to embrace the self-help style of customer service, though, in order to encourage the mainstream adoption of the model. Successful self-help relies on detailed and well-informed knowledge base articles, how-to videos, and tutorials. Compiling lists of frequently asked questions is a great place to start–

If we approach development projects with consideration for where we can build self-help options into the software we’re building, we can make it easier for our customers to use and experience the benefits of our solutions. Finding opportunities to place a link or a button that provides immediate access to knowledge base articles that offer step-by-step procedures on how to fix issues are a great example: tutorials and how-to videos make it much easier for users to “see” the application in use, instead of having to read through steps which might be confusing to some. Identifying ways to incorporate both options, like the use of new “multiscreen” software built into many new Samsung phones and tablets, is fantastic because it gives the user the ability to view the help documentation while walking through the necessary steps in the app at the same time.

As developers and support representatives, we need to keep in mind that, the more we can successfully integrate self-help features into the software we build, the more value we’ll provide to the customers using our solutions and the easier it will be for our customers to stay on task without getting waylaid or frustrated. In a society where time is money and instant gratification is expected, this value can’t be overlooked.

Supporting New Software? No Problem.

One of the first stages of the software development life cycle is the roll-out of brand new software and with it comes that awkward honeymoon phase – it’s anyone’s guess as to what problems might arise during the first few weeks of use. With this comes a sense of uncertainty, but it doesn’t have to be all that scary! Since I’ve started working at Algonquin Studios, I’ve seen many old and grizzled systems scrapped in favor of bright and shiny new ones and I’ve learned a lot about piecing together a support process for when you aren’t totally familiar with the new software. Here are a few important things to keep in mind when venturing into uncharted territory:

There will be bugs. Probably more of them than you expected.

Even if you have the most fantastic software developers imaginable (like we do here at Algonquin), there are going to be unforeseen issues that pop up, so expect a sizable workload increase in the first couple months after releasing a brand new system. This leads to my next point…

Stay organized and consistent with bug tracking.

With an increase in bug reporting, it’s vital that the support team is clearly documenting all bugs reported and all team members tasked speaking with end users are kept up-to date on issues as they develop. Being diligent about your tracking will ensure that when it comes time to fixing those nasty bugs, everyone has as smooth a ride as possible.

Make sure you manage customer expectations.

As with all customer support issues, it’s important to manage expectations about bug fixes and requests for new features (Hey, I actually wrote a whole post about that here!). If there’s an issue or request that a user is anxious about seeing to resolution, let them know that you’ll be documenting the issue to be reviewed, but make no promise of when it will be completed. Not everything can be fixed or added at the same time and it’s best not to give false expectations.

Create and update a Knowledge Base from the get-go.

If you’re not keeping an updated Knowledge Base for your support team, you need to start… And you need to start yesterday. A centralized location for in-house use is crucial to being able to provide consistent answers on issues as they arise. Are you receiving the same questions on how to do a specific task in your software? Create a step-by-step “how-to” that you can send to customers quickly and easily, saving everyone a whole lot of time and confusion.

Have a simple way to escalate issues on a regular basis.

Whether it’s a weekly meeting or a regularly-sent report, there needs to be a way to let upper-level management know what’s going on. It’s ultimately not up to the front-line team to decide what gets fixed and when, but it is their responsibility to make sure the higher-ups are able to hear about the most dire issues. If there’s no process in place to communicate this, make sure you create one so the development life cycle can progress naturally.

Remember, as bleak as handling support may seem at the launch of new software, it will always get easier as time goes on. Implementing a brand new system is a learning process for both end users and support teams, so treat it as such! Look at it as an opportunity to grow your own skills and knowledge and reassure everyone involved that the process will all be worth it in the end. Every company will handle the launch of new software differently; what are some examples of procedures that your team utilizes when implementing a new system? Leave a comment and let us know!

Problems Don’t Float

Software developers have access to helpful debugging tools that let us step through the logic of our code and discover lines of code that might be misbehaving or causing problems. If our code is generating an error, the debugger will tell us which line of code is at fault. If we know our data, we know what results to expect and we can work through the code to diagnose problems if we don’t get the expected results.

Diagnosing problems during software development is relatively easy. The real challenge comes when your software is in operation and the end user has an issue–users report the effects of a problem and we, as developers, have to diagnose the root of the problem from the user’s description.

In the health care industry, they often remind doctors to cure the disease, not the symptoms. The same should apply to software developers; it’s very easy to get mislead by symptoms. My favorite “explanation” from an end user is “It worked before and now it’s not working.” This vague statement always sends developers down a path of investigating what changed between when the software worked and when it didn’t. Often, this investigation turns out to be a waste of time.

Let me give you some real life examples of being led down the wrong path thanks to the wrong focus:

My friend, a staff engineer for Delphi, had to diagnose a problem with overheating vehicles. The company’s customer service staff analyzed all the issues reported and came to the conclusion that most of the cars reporting the overheating problem were yellow in color. The engineering department was misled down the path of studying whether paint color had an effect on the temperature of a vehicle’s engine. Later, they discovered that the overheating was caused when the vehicle’s engines idled for too many hours during the day. Many of the cars that reported the problem were cabs in New York City. Since most of the cabs spend a fair amount of time idling while waiting for passengers and most NYC cabs are yellow, the customer service team’s analysis of the situation was accurate (many cars with overheating issues were the same color) but it didn’t get to the root of the problem (idling time).

I once wrote an application for processing reversal of payment transactions. After the application was in use for a while I received complaints that it didn’t work when processing reversals that resulted from bounced checks. I knew I’d tested for this scenario, so I was upset to learn that something was going wrong in its “real life” use. I found out later that a new staff member had been assigned to process the bounced check reversals. This new employee wasn’t properly trained and was mistakenly entering check numbers in the account number column, and vice versa. The problem wasn’t with bounced checks; it was user error. But I wasted a lot of time researching the bounced check stuff before we discovered the real issue.

This leads me to a line one of my Operational Analysis professors used to use: “Problems don’t float, only their effects come to the surface.” Don’t get misled by how a problem is described to you, instead do your own investigation; build your own understanding. Don’t just skim the surface; you have to dive deep if you want to find the root cause of a problem.

Here are few basic steps I’ve always found helpful when diving deep:

1. Collect examples of where the application malfunctioned and make sure you don’t limit the examples based on how the problem was defined to you. Do some analysis of your own to see which data sets produced the wrong results.

2. Compare the data to the source document to eliminate any data entry issues. Don’t assume anything. I remember one application where data fields were mislabeled during a configuration step, causing the wrong data to appear in the wrong columns.

3. Make sure that business requirements haven’t changed. Try not to offend the user reporting the problem, but make sure the output they expected matches the business requirements you followed to build the application. I remember an instance where a payroll auditor held back hundreds of paychecks, declaring that salary calculations were wrong. Many hours were wasted verifying the software used to process the calculations, only to discover that the payroll auditor hadn’t been informed that pay raises had gone into effect.

4. Work through the application using the data from the examples you collected. Make sure each step of the way that the output matches the business requirements. Again don’t assume anything, work through each and every step. Not only will this help you diagnose the problem reported, you might discover some other malfunction that was overlooked during development time.

And finally, remember that once you do uncover the root of the problem, you congratulate the end user for discovering that special “hidden feature” in your application!

Maintain Your Software Like It’s Your Home

Are you interested in software that runs on a magic PC somewhere in “the cloud,” never has to be bothered with, and always works smoothly? Sure you are, but if you think such a thing sounds too good to be true, you’re right. Keeping an application performing well throughout its life is much like maintaining your own house–it’s necessary and valuable.

In an previous post, I discussed the Software Life Cycle and made some basic comparisons between the preparation needed to build a house and the preparation needed to build software. The parallels don’t end there; a lot of similarities can also be seen in the maintenance of, and care for, both a house and a software system. Unfortunately, once your new home or application is built, you don’t get a free pass to kick back with your feet up and a nice cold beverage in hand. Using the house/software comparison, below I’ve listed a few areas where maintenance is important in both places:

Regular care

Lawnmower

  • Regular care at your house will include mowing the lawn, raking the leaves, staining the deck, painting the fence, landscaping, etc. All those things we love to keep busy with! We do them for a reason–to keep our homes looking nice and increase it’s value.
  • Likewise, you should regularly be evaluating how to maintain an aesthetically pleasing and user-friendly experience to keep engagement with your software at its peak. In most cases losing engagement will mean losing value in some way. “Regular maintenance” here can mean generating fresh content regularly, updating the layout of your site, adding accessibility features, or implementing new software standards, where appropriate, to keep your application looking and feeling new.

Upgrades

Roofer

  • Eventually, and hopefully not before you’re good and ready, your house is going to need a new roof, a refinished driveway, an updated heating/air conditioning system, etc. These are bigger projects and occur less frequently than the weekly, monthly, or yearly tasks mentioned above but these can easily be considered even more important to the general upkeep and maintained value of your home.
  • Your software should be getting upgrades too, as regularly as possible. Regular maintenance times for things like hardware upgrades, software patching, and security updates are a must. Beyond that, you should consider moving your software to the latest versions of code frameworks and database management tools. Staying on old versions of these things, much like failing to replace an old roof, increases susceptibility to leaks. And the longer you wait, the more likely your path to upgrading will be even more painful, more stressful, and more costly.

Additions

Blueprint

  • You want to move your laundry room from your first floor into the basement and then remove a wall to expand your dining room? Great…Maybe. Any good contractor will tell you how these changes will affect your house (what if that dining room wall is a load-bearing wall?) and that you’ll need to take these changes into consideration when you think about continued upkeep for your home.
  • Most of your software will have additions after your initial launch, too. This isn’t a bad thing…Much like the laundry room situation above, you won’t always think of everything in your first go-round. How new additions will fit and interact with the rest of your software, and how to most effectively make these additions, should be an important part of maintaining your software. You’ll want to analyze whether new features will cause other parts of your system to have issues, much like how removing a wall from a house may affect its structural integrity. Once your software is live, always consider how system processes interact and what adding a new feature will mean for the people already productively using the software.

Clutter

Clutter

  • When you use your basement as a one big storage closet, continuously piling things down there without a periodic clean out, it leads to a huge mess. What happens when you have an emergency and a plumber or HVAC expert needs to get down there and fix something?
  • Even if you haven’t thought about it yet, at some point you’re going to have to clean up your software the same way you would your basement. Today, it’s a brand new system using bleeding-edge technology and state-of-the-art hardware. But as your amazing software ages, all of the data you’re compiling is going to, eventually, become difficult for the system to manage. Do you really need to hang on to a record set of 10,000 emails logged from 1995 anymore? Probably not… So maybe it’s time to archive anything that’s clutter, helping your application breath a little easier. This clean up will help troubleshooting and day-to-day activities go more smoothly, too.

I could keep making house/software upkeep comparisons all day but I think my point has been made: we frequently overlook the maintenance portion of software development but, much like ignoring home maintenance, it’s a bad idea. Take this to heart; regularly scheduled maintenance is incredibly valuable in keeping your software functioning at its best and understanding why and how you need to care for your software will make dealing with it easier in the long run.

K.I.S.S.

Nope, I’m not talking about extravagant costumes, black and white face paint, and fire breathing.

I’m here to discuss the old adage “Keep it simple, stupid” and how it applies to software development.

As a Project Manager, I spend a lot of time meeting with clients to review requirements for their software and work with them to turn those requirements into a full system. As I work with my clients to navigate the treacherous waters of system design, we inevitably end up with a “feature” that we all agree is on the borderline of “Necessary” and “Nice to have.” This is especially hard to determine in a business system that users will be working with every day.

This is when things get interesting! Let’s take a look at what questions to ask yourself:

Why do you want this feature?

You can tell a lot about how important this feature really is by the initial reaction of a client when you ask this question. If it takes a few minutes of fumbling to eek out a satisfactory answer, you can most likely scrap the feature.

Is it worth it?

To answer this one, we’ll ask a few follow up questions, too:

  • How often will this feature be used?
  • Is there a manual workaround that can be used instead of this feature?
  • Who will use this feature (and how many of these users are there)?
  • How much work will be created for a user is this feature is left off?

Now do a little quick math and, magically, we can determine if it’s financially worth adding this feature. Here is an example:

Add this monthly report that aggregates data for X, Y and Z. 
  • Feature will be used monthly
  • User can perform this process manually
  • 1 administrative user will use the report
  • If this feature isn’t implemented, the administrative user will need to run 3 reports and aggregate the data themselves. This process will take approx. 20 minutes.

Answer: If building the report adds 8 hours to the system build, it will pay for itself in 2 years.

Does this feature add complexity to other areas of the system?

I’ll let you in on a little secret, the answer to this question is always YES.

No mater how much you want this fancy new feature, it will make your system more complex. We often try to convince ourselves that a feature is so simple that it won’t add complexity, but there are a couple of points that always hold true:

  • This feature will need to be tested after every update.
  • The users of this feature will need training.
  • This feature will need to be documented in the help system (and maintained).
  • This feature will need to be discussed when future changes to the system are designed/implemented.

So, let’s return to our seemingly simple example report and apply these issues to the “complexity” question:

  • Will this report need to be tested? Yes
  • Will the users need training? Yes
  • Will we need to add help documentation? Yes
  • Will this report need to be updated if we make changes to report X, Y or Z? Yes

There’s no doubt about it–every time you want to add a feature, you’re choosing to make the system more complex.

Before you commit to a feature, ask yourself if it’s a system requirement and make sure you really understand, and accept, the increase in time, complexity, and cost that including the feature will entail. If the answer is “yes,” then let’s build it. But if there’s any doubt, remember, it’s never a bad idea to K.I.S.S.

Microsoft SQL Server 2012 – AlwaysOn

Microsoft SQL Server 2012 – Always On

As technology advances, so does the need (and want) for instantaneous information. The goal is always “How can we get information as quickly as possible?” The same is the standard for disaster recovery. How quickly can we recover in the event of failure? The answer in many cases is seconds. One of the newest options for High Availability is Microsoft SQL Server’s AlwaysOn technology. The name is self-explanatory–AlwaysOn is designed to have data and information always available, even in the event of disaster. Disaster Recovery time is minimized with SQL’s AlwaysOn ability to sync multiple databases across multiple database servers.

I had the recent experience of using SQL’s AlwaysOn technology to set up a redundant application environment. The purpose of this blog post is to summarize my experience with the technology. By no means is this a start-to-finish coverage of the technology.

Overall, the perception of AlwaysOn amongst users has been very positive (simply Google “SQL Always On” and you’ll see other posts stating its benefits). I, too, was impressed with its simple setup and configuration and how well it handles failover scenarios (verified during our pre-launch testing). With all technology, there were some downsides, but I felt that the positives of AlwaysOn far out-weigh its drawbacks.

Availability Groups

  • Replication in AlwaysOn is no longer thought of as individual databases to individual servers. Complex systems can be replicated as a group, not as individual databases, minimizing setup and configuration time for replication. The one downside is that the replicas are limited to four sets, so one group can only be replicated to 4 different locations.
  • Synchronous and Asynchronous Setup
    • Synchronous Replication – Transactions are not completed until committed to all databases in the Synchronous Availability Group
      • The first thought I had when hearing this process was that it may be performance impacting since SQL will need to commit the transaction to multiple databases on multiple servers.
      • We tested this process to ensure synchronous replication to multiple databases would not cause performances degradation.
      • We used SQL’s query performance statistics to ensure that the performance of data read/writes were as efficient with the new environment as they were in the old environment.
      • As a side note, there were other factors that affected query performance times (for the better – new environment, new OS), so our test wasn’t a true comparison of SQL performance with and without AlwaysOn replication. For the purpose of our test, we needed to ensure that the AlwaysOn replication was not a detriment to application performance.
    • Asynchronous – Transactions are queued and committed to this Availability Group at a later time. Transaction completion is not dependent on committing to this database group. This is similar to Database Log Shipping in older versions of SQL Server.
      • In previous versions of SQL Server, Log Shipping would require the database to be inaccessible during restoration of the transaction logs. With AlwaysOn, the database is always online and accessible.
      • This allowed us to use the Asynchronous process for other purposes, in this case Read-Only reporting. We took long-running reporting queries and calculations and removed that processing need from the transactional database and server altogether, providing an indirect performance benefit from AlwaysOn.

Automatic Synching

  • One of the most frustrating aspects of SQL Log Shipping is when the process gets out of sync and the transactions are not being properly applied to the replicated database. This would generally result in manually copying and restoring a database to the replication server and restarting the transfer process
  • This headache is alleviated with the Asynchronous Replication of AlwaysOn. AlwaysOn polices itself for the data replication, automatically re-synching the database if a network connectivity loss or other event disrupts the replication process

Licensing

  • Unfortunately, AlwaysOn is only available with the Enterprise Edition of the SQL 2012 License, so you’ll need justification to spend the extra money for the Enterprise license. This may not be the best DR solution for smaller applications.
  • However, licensing is setup to use Active vs. Passive server. This means that you don’t need an additional license for your replication servers if it is only being used in a failover scenario, which allows you to limit the number of licenses you will need.

Again, this was just an overview of my experience with Microsoft SQL Server’s Always On functionality. In the event that you are in the process of setting up a new environment using Microsoft SQL Server, I highly suggest considering AlwaysOn to handle the High Availability/Disaster Recovery requirements. See Microsoft’s overview of AlwaysOn here: http://msdn.microsoft.com/en-us/library/ff877884.aspx