Blogs

It seems that just about everyone is using SharePoint in one way or another these days, ranging from collaboration and sharing of documents within a team site to comprehensive document management and workflow systems involving rules-driven form processing that spans organizational boundaries. SharePoint is popular for corporate intranets, as well as for its publishing features for an organization’s public-facing web site. Simply put, SharePoint is many things to many people. Below is a recent post by my colleague Jonathan Matcho, Director of SharePoint Solutions at Sitrof Technologies.

---

At Sitrof, we are in the business of building custom document management and workflow solutions closely integrated with our customers’ business needs. At times, we are presented with requirements to build a “ground-up” software solution to provide functions X, Y and Z. In addition to commonly expected features (security, logging, version control, information and metadata management, document storage, workflow and so on), a customer’s unique business rules and processing must be implemented.

The initial reaction (and often the assumption by our customers) is that we must design and build a database-centric solution paired with web pages and system control components to realize the solution.

While building these software solutions, we came to realize that the time required to build and manage the framework-level software approached that required for the customer’s business-specific requirements. Though building this “plumbing” was fun and exciting for the development team, it became obvious that we were not moving business features of the solution forward as fast as we wanted to. We began to search for a way to better apply our development efforts to the customer’s needs.

We decided to explore the use of SharePoint as an application platform. This was a major shift, as it effectively made the reusable designs and software components we had spent so much time building, obsolete. Naturally, this decision was met with some resistance as it represented a fair amount of risk.

Taking a close look at the SharePoint technology platform one finds an architecture designed for extensibility and customization. The SharePoint platform itself is well documented and supported by the industry, and has a wide array of services available for custom development.

Reading from the bottom of this diagram up, we can see that SharePoint is actually a .NET web application leveraging .NET services running on a plain-old Windows server – curiously similar in design to our in-house framework!

Microsoft packages SharePoint as follows:

• SharePoint Foundation 2010 – the “free” version containing core SharePoint services that can be used to build many solutions
• SharePoint 2010 Standard Edition – adds additional capabilities and services, most notably search and enterprise content management capabilities
• SharePoint 2010 Enterprise Edition – adds premium capabilities (forms, business intelligence features) and additional document rendering options

As can be seen from the collection of components within the SharePoint Foundation layer, a robust set of application services are available. In hindsight, we recognized that by building and maintaining an in-house framework we were effectively competing with Microsoft in this area – a fruitless endeavor.

Microsoft has designed SharePoint to support large volumes of users, documents and page views. The SharePoint topology itself is scalable, allowing additional web servers to be added to the farm with ease, and individual services to be partitioned to separate application servers to support performance and availability – architecture which is available out-of-the-box.

The Results

Moving beyond architectural diagrams and pro vs. con discussions, we took the leap and began building.  Of course, there was an initial learning curve required to be effective with new technology (even adding a new team member would require the same in any project), but a major benefit of SharePoint is that there’s a planet full of SharePoint developers, books, blogs, videos, etc., that can be leveraged. We were able to grow our staff by adding SharePoint developers that essentially knew a good portion of our design and framework – the architectural plumbing.

We were also able to leverage “out-of-the-box” services where we would have otherwise needed to build our own, or extend a prior software component to support new technical requirements. Services within the SharePoint Foundation are well thought-out and documented, and fully integrate with our existing tools and affinity with the Microsoft .NET technology stack.

A side effect with our SharePoint-based approach is that we found certain features became available for inclusion in the solution that were either not thought of during the requirements phase, or were regarded as too complex to build. In actuality, some features became “freebies” – the customer was given the option to include a new feature or not. Implementing these options was often no more difficult as turning on a switch to enable a fairly significant capability (for example, document versioning).

Conclusion

Ultimately, we were able to deliver a solution that looked, smelled and talked like a ground-up custom software solution custom-fit to the business requirements. We could argue that the solution took less time to develop; however, our philosophy is that good software is not just a matter of the time it takes to write code, but how many iterations the team has to work through. By using SharePoint as an application foundation, we feel our software is much more robust with higher quality than would otherwise be available within the same timeframe.

While SharePoint may not be appropriate for all technology solutions, it is a viable option as a front-end information management platform for the vast majority of corporate business software solution needs.