Robert Bogue
April 13, 2006
No Comments
Note: This was a full length article I wrote on speculation for a publisher who decided it wandered too much for them. I’d really appreciate your feedback on whether you thought it was valuable or not. Comments on the blog are disabled but you can email me your thoughts. thanks — rlb
Playing the role of devil’s advocate is fun. You get to punch holes in even the most detailed and elaborate plans. You can ask fun questions like, “What happens if both your primary and secondary power sources fail?” Most developers and architects who have much experience are adept at playing the devil’s advocate role. It’s one that others have played in the past for us, and occasionally “Murphy” has intervened and demonstrated a few worst-case scenarios.
However, all of this planning for the worst possible case has a cost and, in many ways, a non-trivial cost. Instead of viewing what we can do and how things can solve problems, we get wrapped up in how someone might work around the system, create a problem, or get things out of whack. We begin to plan for the exception rather than planning for the rule.
SharePoint solutions inherently don’t do well with the point of view that everyone is going to try to break the system down, or make changes they aren’t supposed to make. SharePoint just doesn’t work well when you assume that the users are generally bad people. SharePoint is, instead, focused on enabling people to get things done and trusting that the people that you have given permission to will be responsible adults.
You need to understand the difference in mindset that facilitates successful, and inexpensive, SharePoint implementations as it compares to the way that most IT organizations are familiar with doing business. In this article we’ll break apart the problem for you and show you the attitude to take for success, and why to take it.
Traditional Software Development
When developing software for computers, we as an industry started with accounting packages and enterprise systems that were used to manage money and coordinate large groups of people. Computers were expensive, so they could be used only for those tasks which were considered mission critical. Because of the types of systems that were being built, we needed checks and balances, authorizations, and controls for who could do what and when. When you’re working with the ability to cut checks for millions of dollars, for instance, it’s a good idea to make sure someone’s authorized to cut that check.
The Internet and the rise of hackers (or crackers, if you prefer) has shed new light on the idea that you must be able to secure systems from the masses, even the masses that include your customers. The need for security on nearly all levels has become, unfortunately, a way of life. We have to accept that we must protect ourselves from the world at large.
The same way you might lock your doors in a bad or unfamiliar neighborhood to discourage a car jacking, in software development you make sure that all of your proverbial doors are locked, the ‘Ts’ are crossed, and the ‘Is’ are dotted. You certainly don’t want to have someone breaking into your system or accidentally doing something that they’re not supposed to do.
Traditional software development is focused on managing risk, even small risks. Interfaces, even hidden ones, that might allow an individual to bypass some security or some business process are locked down so that no one can use them inappropriately. This happens whether the interface is critical to the system or not. Even if the interface simply logs a note to the account, it must be locked down, audited, and security tested.
Author’s Note: This is not an attempt to say that traditional development is wrong, invalid, or bad. It’s simply a statement of observation. When I do security application reviews, these are the things that I look for because that’s what the organization (and in some cases the government) wants to see.
SharePoint Development
In stark contrast to the kinds of financial-impact systems that started software development, and the hoards of “bad” people on the Internet, SharePoint is most frequently used by a group of people who know and trust one another. They are people who, even if they don’t work for the same team, often work for the same organization. More frequently than not, the people using SharePoint exist within the sphere of “a neck to choke,” if they won’t play by the rules. Even if you can’t physically reach out and touch every person using the system, you generally know someone who can. You have some level of community responsibility with the people using the system.
There’s a higher degree of integrity offered by the closeness of the folks using a SharePoint solution and a greater degree of community responsibility. SharePoint systems aren’t elaborate machines where each person doesn’t see the effects of his work. Instead, each member sees his part in the solution. In some cases, he feels a responsibility to help be part of the solution, and not a part of the problem.
There is very little need for the controls, locks, and gates on which traditional development focuses. Sure, we all would like the ability to refine how the system works to enforce business rules; however, when developing for a small group, and especially a team, these controls are nice to have, rather than necessities.
Planning the Happy Path
Planning for the happy path is simple; however, it’s so simple that most IT professionals block it out of our minds. When spreadsheets came out on the market, they were rapidly adopted as a way for users to convert the data they had into the information they needed. Lotus 1-2-3 introduced a powerful macro language. Microsoft Excel extended this model (as Microsoft often does) and enhanced it into a true programming language. Even today many organizations rely in part on Excel to close the accounting records of their businesses. (We hope that the Sarbanes-Oxley Act is reducing this practice; however, by observation it is still all too popular.)
Microsoft Access spread like wildfire in the early 1990s. Users were suddenly able to take data sets too large to process in Excel and create decent looking reports, simple data entry screens, and – in general – simple solutions. Many organizations are still recovering from their addiction to Microsoft Access as well. They struggle with systems written by engineers who’ve long since moved on. They’re not sure precisely how the database works but they do know that it does work.
Evaluating Excel and Access, one can quickly surmise that neither tool is perfect. Certainly I wouldn’t be using words like “addiction” with a product without flaws. Excel’s lack of formal structure is a double-edged sword. The flexibility of the tool for solving a wide range of problems in turn increases the likelihood of a user mistake in data entry or an error in a formula. Excel lacks a good data entry interface, and has until recently been limited in the amount of data that it can manage.
Access has its own set of challenges. It has a tendency toward data corruption with large numbers of users. Performance can be slow, particularly across a WAN. The file-based mechanism of accessing the database means that some of these problems cannot be directly resolved. Most databases are developed by business users with a problem. Their organization’s IT department is overwhelmed, underfunded, and hard to reach out to. As a result, users have developed innumerable databases for their own use, for their department’s use, and in some cases for their enterprise’s use.
So why, if these applications have glaring problems, do they gain the kind of user acceptance that makes them so popular? The answer is that they can be made to solve a need. Excel is not perfect; the tool can be broken. It doesn’t have neat and clean data entry forms, and validating input is beyond most users. However, it allows quick and easy creation of solutions.
Herein lies the fundamental truth of SharePoint’s power. SharePoint may not do everything you want exactly the way that you want. However, with a little bit of manual work, some ingenuity, and a little bit of give, SharePoint can create very workable solutions to complex problems.
So, you can’t have item-level security. The solution is to create a library for each access level of permission needed by individual groups of people for different types of documents. No one would say the approach is perfect, but it’s an approach that works.
This is the happy path. No one will ever get into an item and change a field that he’s not supposed to. You’re not worried about someone taking his task and marking it closed unless the project manager has approved it. No, or little, consideration is given to the idea that someone on the team would change something they shouldn’t.
Of course, people do change things they shouldn’t, and there are problems occasionally with data being wrong; however, the number of times that people accidentally or purposefully change data that they shouldn’t is so small that building a complete system with all of the controls, locks, and gates just isn’t justified.
The happy path is that: a happy path. It’s characterized by focusing on what you can get done. Potential problems are acknowledged, but their importance is minimized when compared against the benefits SharePoint can bring.
Falling Off the Happy Path
The ideal of everyone playing nicely is certainly the goal, but what about the situations when you can’t do that? What about when you must have field-level validation, which SharePoint doesn’t natively support? What if you have to secure individual data to prevent users from accessing things that they shouldn’t? The answer, however flippant it may sound, is, “Deal with what you must, mitigate what you can.”
In other words, if you absolutely have to do it, plan on finding a solution – one that will likely be an order of magnitude more expensive to create than doing it the “happy path” way. However, before you give up and hand over your checkbook, evaluate the real risk that you’re taking by not creating the kinds of restrictions that you’re considering.
Many times the requirement to provide field-level validation or secure individual documents can be either mitigated or addressed via an alternate structuring of the problem.
Let’s explore this idea of field-level validation. Say that the purpose is to restrict the assigned-to field to yourself or one of your direct reports. In other words, you should be limited to accepting tasks for yourself and those for whom you directly control the work. This makes sense, and could easily be written into a procedure manual. The probability that a user or manager would assign a task to someone outside of his group, even without the procedure, would be low – why would they do something like that? The impact of the problem is likewise low; someone else will need to address the item or it can be set it to unassigned again. All in all, it’s probably not that important of an item – certainly not one to put on the must-have list of enhancements for SharePoint.
Why shouldn’t it be on the must-have list? There is simply no way, short of creating your own database with its own web parts, its own administration, its own integration to Excel, and its own alerting system, to effectively trap every case where someone might try to input or update a record in a SharePoint list and force it through your validation. You can, as I describe in the article
Master Advanced List Editing in SharePoint, change the user interface of the list edit page to perform the additional validation that you require; however, you cannot intercept the Excel datasheet view, so users can still enter data directly, bypassing your enhancements to the user interface. The net result is that adding these kinds of enhancements to a SharePoint site is substantially more expensive than just creating procedures to support the somewhat open way that SharePoint approaches the problem.
One of the observations that is often made by clients who’ve deployed SharePoint is that the easy is very easy and the hard is very hard. There is little in between these two extremes.
Conclusion
Performing a cost-benefit evaluation on every feature that you want to implement may be impractical. However, being able to identify those features which may cost substantially more to implement than a nearly as good solution is important to maximizing your return on your SharePoint implementation – or any implementation, for that matter. Consider the impact of embedding the business rule into your process rather than in the solution.
