Skip to content

Article: Code Access Security: When Role-based Security Isn’t Enough

Role-based security works pretty well in most situations but as Sharepoint developers learned long ago it doesn’t work for everything. Now that .NET supports Web parts, even more developers will find they need to get a basic understanding of Microsoft’s Code Access Security.

Ask any typical .NET developer about Code Access Security (CAS) and you’ve got the chance of hearing “Huh?” as the response. Most developers haven’t run into CAS at all—let alone in a way that would cause them to develop a deep understanding of it.

Ask your typical SharePoint developer about CAS and they’re likely to begin to shudder uncontrollably. Why is that? Well, SharePoint developers have been dealing with CAS since the day that SharePoint was released. Unlike ASP.NET, which makes the assumption of full trust—effectively neutralizing any impact that CAS will have on a standard .NET application—SharePoint starts with a minimal trust, which means most code will need to have a CAS policy applied to it in order to work.

http://www.devx.com/security/Article/31259/

Article: Microsoft Windows SharePoint Services or Microsoft Office SharePoint Portal Server?

Most organizations, when they initially start looking at SharePoint, are confused about what SharePoint is. They struggle to understand the features and what they need to solve their business problems. It doesn’t take long for the conversation to turn to a discussion of whether the organization needs to take on the additional cost of Microsoft Office SharePoint Portal Server (SPS), or whether the Windows SharePoint Services (WSS) already bundled with their operating system licenses is be sufficient. Most of the time, the decision isn’t very black and white. This article discusses the questions you should be asking before you make a decision.

http://mssharepoint.advisorguide.com/doc/17866 [Article removed]

Article: Use your star as a catalyst for productivity by amplifying the halo effect

To get the most out of your star developers and other team members, you’ll want to amplify the halo effect. In this document you’ll learn how to identify the halo effect, understand it’s potential, how to amplify its effect, and how to convert the halo effect into a permanent change even after the star developer has left.

Adding a star developer or architect—from here on we’ll just call them a “star”—to the team does more than improve your organization’s productivity by the amount that star can do. A halo effect often occurs where the existing developers on your team begin to improve their effectiveness too. This halo effect can be either amplified so that nearly every person on the team becomes better, or it can be isolated so that few, if any, people are affected by it.

To get the most out of your star developers and other team members, you’ll want to amplify the halo effect. In this document you’ll learn how to identify the halo effect, understand it’s potential, how to amplify its effect, and how to convert the halo effect into a permanent change even after the star developer has left.

Understanding the halo effect

A friend of mine and I were talking before her wedding which occurred a few years back. It was important to her that she be able to do ballroom dancing for her first dance with her new husband. She had been taking dance lessons and she related how when she danced with her instructor her dancing was much better than with her husband and she didn’t understand it. When she asked her instructor about it he told her that she was able to dance better because his leading was better. That with strong leadership she was able to follow clearly. Her future husband was a good, but not professional dancer, and so his leading wasn’t as strong or assured. Although their first dance turned out fine, she learned first hand about how a “star” can artificially increase the effectiveness of her dancing.

http://www.techrepublic.com/article/use-your-star-as-a-catalyst-for-productivity-by-amplifying-the-halo-effect/

Creating SharePoint Solutions Is About Designing for Happy Thoughts

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.

SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations

Book Review-SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations

Whenever a new SharePoint book comes out I’m very hopeful. There is so much to learn about SharePoint. Some of these things are strategic and cultural. Others are the inane details that allow you to make SharePoint do what you want it to do.
I quickly put this book into the details category with the highly specific and technical title. I was not surprised in this way. It drops down right into the details, right away. No stopping to smell roses, or fluffy introduction chapters – “just the facts, ma’am.”
Unfortunately, my read of the book led me to wonder whether it was providing extra value or not. Primarily, I was thinking about these free resources that have a similar level of coverage:

If you prefer a book that provides a lot of information in one place, rather than taking the time to gather it for free, this could be the right book for you.

This isn’t a book that I will generally recommend, but it does a reasonable job of covering the material, even if it does sometimes make leaps of understanding.

Article: A High Performance Model for State and Caching

Every Web application has to deal with session state in one way or another. Most default to the state management built into the environment of the language they’re using. It’s simple, quick, and in many cases effective.

The problem comes in when you’re trying to build a high volume site and the standard way of doing things just won’t cut it. Dumping everything into session state just doesn’t work; caching becomes a necessity. You’re forced to start bringing more things into memory per user—while simultaneously keeping your per-user memory utilization down. It is when caching is added to the performance mix that you begin to really see how your fundamental views of session state and caching need to shift.

In this article, I present a model for creating different pools of information tied to both, how the information is used and how expensive that information is to reproduce. I’ll detail a method for improving performance using careful management of state and cache.

http://www.developer.com/tech/article.php/3593386

Article: Generate development documentation with the inclusion by reference method

Whether your software development process is the antique waterfall method or something more razzle-dazzle like the latest agile methodology, you have got to be creating some minimal levels of artifacts like documentation. That is, of course, excepting those who continue to use no methodology, or the methodology of “code and fix.” While much attention has been paid to the excessive weight of artifacts, including documentation, in recent years, little has been done to talk about strategies which still meet the need for a common understanding of the software, while at the same time minimize the effort required to create and maintain documentation.

One technique which deserves some attention is the idea of including documentation by reference. In other words, refer folks to a more comprehensive source for the detailed information while maintaining a reasonable summary in the document itself.

http://www.techrepublic.com/article/generate-development-documentation-with-the-inclusion-by-reference-method/

Article: How SharePoint and SOA Fit Together

What do you get when you take SharePoint, a wildly popular product, and Service Oriented Architecture (SOA), a widely misunderstood but sought after technique for improving the agility of an IT department, and put them into a single article? Hopefully you get a popular article where people poke their heads in to learn if this is another combination like peanut butter and chocolate, or if it’s more akin to spinach and strawberries.

Services Oriented Architecture is a perspective on how to build systems that emphasize reusability, loose coupling, and standards-based approaches. SharePoint is a specific portal technology that is focused on getting information into the hands of the users who need it as quickly and as simply as possible.

In this article, we’ll explore how SOA and SharePoint work together to help organizations that are struggling with minimizing costs and maximizing benefits

http://www.intranetjournal.com/articles/200603/ij_03_16_06a.html

The Psychology of Computer Programming

Book Review-The Psychology of Computer Programming

One of the more interesting questions that I get is how to get an organization to adopt agile methods. Sometimes folks frame it in terms of a problem: “I’m trying to get my organization to buy off on agile development, but they’re not convinced.” I believe that the book The Psychology of Computer Programming can really help with making agile development more powerful. Let me explain.
One of the things that I’ve noticed with most of the agile books, articles, postings, and so on, is that they describe WHAT to do and HOW to do it. However, they are noticeably missing the WHY it works. They’ll argue that WHY to do it is that you experience more productivity, efficiency, quality, etc.; however, they rarely attempt to explain WHY those benefits occur.
So how can a book that was written 25 years ago explain how agile works? The answer is simple. Agile works because it capitalizes on the psychology of programming – even if it only capitalizes on it by accident. Penicillin was created by accident, remember. Some of the core reasons why agile practices work are explored with experiments in The Psychology of Computer Programming.
By now you should be asking, “Okay, so how could I use it to help me sell agile to my organization?” The answer has to do with some of the antiquated material in the book and the way that they may seem nostalgic to the managers who are leading the technology department.
The book was originally published in 1971, so its references are, to say the least, a bit dated. The language examples are FORTRAN and PL/1. The most prevalent system mentioned is OS/360. There are references to punched cards and computer rooms. Terminals are just beginning to gain favor. However, despite the quite noticeable and sometimes distracting antiquated references, the core messages about how programmers (developers) work with one another and with the computer are still clear.
Frankly, the references to older systems make the book more credible than the respected agile books of today. Senior technical managers often will remember these systems with a sense of loss that they can no longer develop code. (Everyone’s inner geek suffers when it’s not allowed to grow.) Because of this connection, the more formalized study methods and the slightly academic feel of the writing makes it a book that is believable to anyone who grew up through the technical ranks.
So how do you use this? First, read a copy of The Psychology of Computer Programming, plowing through some of the parts where it seems like there may be little to offer in terms of today’s agile methods. Highlight the sentences and paragraphs that align to today’s agile practices. Then hand it over to the manager who’s not convinced that agile is the way to go and ask him to read it.
You know that they aren’t likely to read it, but they may flip through and notice your highlighting. You’ve got them hooked. If they read around the highlighted passages they’ll find that comfortable nostalgia and, hopefully, settle into trusting the book.
From there, it’s just a matter of hinting that you should try some of the ideas outlined in the book – that just happen to align with one of the agile methods you’re looking at starting.
I have no idea whether the founders of the agile methods that folks are reading today read The Psychology of Computer Programming, but whether they did or not, there are certainly some interesting correlations.

Article: Squeeze more out of the construction phase of application development

The world of software development is changing. Software development tools and frameworks are promising to improve speed of development. New agile development techniques are changing how we approach the development process. Whether your organization has adopted new tools, new methodologies, or is just looking at what’s going on in the market, you’ve got to account for the compression of the construction phase of the software development process.

http://www.techrepublic.com/article/squeeze-more-out-of-the-construction-phase-of-application-development/6049011/

Recent Posts

Public Speaking