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.
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.)
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.”
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.