In this post, John Underwood shares his experiences so far with pushing beyond initial perceptions about SharePoint. John is a new Technical Evangelist for ThreeWill. He will be presenting a webinar in September covering the important topic of SharePoint Product Development.
Many of us are familiar with the picture above or similar pictures that play tricks with our mind. We stare intently and see one thing, only to have another thing emerge upon further review. Studies show that the effect is even stronger when we are preconditioned to believe we are going to see a certain picture. In the book The 7 Habits of Highly Effective People a similar picture is used to illustrate how strongly our preconceived notions can influence what we see. Two groups of people are shown the same picture. One group has been told they will see a picture of a young woman; the other has been told they’ll see a picture of an elderly woman.
When the picture is finally shown to each group they easily identify the young or old woman based on what they’ve been told to expect. Each group is convinced that they are right and have trouble seeing the other group’s perspective. Only when the two groups begin to communicate and review the picture together can they see each other’s view.
I have experienced a similar effect recently in my professional life. For years I’ve used SharePoint as a way to manage the content for the programming courses that I’ve written. I’ve used it to create document libraries for slide decks and student manuals. I’ve used lists to track questions asked by students. I’ve setup team sites to share information with students that have attended my classes. I’ve written surveys to track customer satisfaction. I feel as though I’ve employed SharePoint enough in my daily work to have a pretty good grasp of what it is and what it does. And yet, in the last 3 weeks I’ve been confronted with the notion that, perhaps, SharePoint is something more than what I perceived it to be.
In early August I started a new job at ThreeWill as a Technical Evangelist. This new job will entail presenting SharePoint to everyone from executives to end users to developers. I was informed in my very first week that a big part of that message will be “SharePoint 2010 as a Product Platform.” Clearly I knew that it was possible to customize SharePoint through application pages, Web Parts, and custom workflows. I knew that we could use these tools to tweak SharePoint and make it behave in a way that more closely fits the way a certain team or department does business. But the notion that it could be used as a foundation for building entire applications – even applications that ISV’s would sell as a shrink-wrapped product – is something that I had never considered.
ISV’s or corporate developers may choose to engage SharePoint in the following ways:
- Connect: building software that will connect SharePoint with other applications. As an example, enabling SharePoint search results to include data from a company’s existing database applications.
- Extend: creating Web Parts, Workflows, and employing other out-of-the-box SharePoint components to create a highly-customized application for meeting a business need.
- Build-on: SharePoint becomes a library of functionality that can be consumed from a custom Windows, ASP .NET, or Silverlight application. Each of these applications uses the Client Object Model library to call into SharePoint and consume its functionality.
As a developer I think about the features of SharePoint and how they map to applications that I’ve written in my career. I can remember building an application that had to capture and track medical images. There was a significant amount of effort exerted in building a subsystem to manage and track the image files. Today a SharePoint document library can readily provide that functionality with little or no programming required. Likewise, I’ve worked on an application that implemented a massive custom workflow engine. 75% or more of that application could have easily been constructed using SharePoint workflows. As a developer I found it intellectually stimulating to work on these complicated subsystems; but the reality for most companies is that it’s more profitable for their developers to write business logic than it is to write complicated, plumbing-oriented code.
Some have used the phrase “Business Operating System” (video on Steve Ballmer’s take on the subject at the SharePoint 2010 Conference) to describe the set of features presented to developers by SharePoint. It is a vast set of capabilities to allow developers to quickly build sophisticated applications while at the same time permitting a support model that will fit nicely with the IT infrastructure of a company that has already adopted SharePoint for more “traditional” purposes. For ISV’s and corporate developers that choose to use SharePoint as a foundation, they will also find that it opens up new opportunities inside companies that have already invested in SharePoint and are eager to maximize the return on that investment.
So when it comes to something as simple as a picture – or as complicated as a software development platform – don’t be afraid to step outside of preconceived notions and look at something in a new way.
Are you interested in learning more? Attend a webinar led by John on September 24th.
No related posts.












