Canadian IT Architecture Blog

The SharePoint 2010 Platform

Many of my customers refer to SharePoint as their “business operating system”. This ideal is re-enforced by the platform enhancements in SharePoint 2010. There is a business opportunity to leverage SharePoint 2010 as a development platform. A recently published David Chappell article, The SharePoint 2010 Developer Platform: An Introduction for ASP.NET Solution Architects does a nice job of highlighting the new features that application development teams need to consider when thinking about such a platform. There is also a discussion on his blog.

However, this has the potential to create another set of challenges!

I have mentioned previously that I get this question a lot. I always respond the same way: there is no whitepaper to download because well, it isn’t really a science (it’s an art!). Well, thanks to Mr. Chappell I can now point people to a good primer on the subject, but as Architects we need to examine a few other areas to round out our technical knowledge.

Many technology decisions are linked (avoid breaking them)

Sections of his paper are dedicated to discussing the traditional layers of design and their application against the SharePoint platform. So many options! The advantages to an application framework are obvious but so are the caution signs. For example, using SharePoint Lists as the data source in your application begets the content repository database and associated API set. This had tradeoffs when it comes to reporting (think cross-table relational join) that you may be faced with later as your application expands.

Leveraging a tool like InfoPath can be a fast-to-market approach and solve very tough problems in a short amount of time. But again, this scenario leads you towards InfoPath services, web service data retrieval, SharePoint Workflows and document libraries for submission and event handling.

We like to group ‘areas’ of functionality and make technical decisions about the appropriateness of the solution in each (independent) case. For application architects, you may want to consider the cascade effect of each decision when applying that philosophy against the SharePoint platform.

Business Analysis & Architectural View Point

The article recommends styles of applications that are appropriate for SharePoint, and those that are not. It suggests you target applications with collaboration characteristics, look like a portal or other LOB ‘snack data’, web-part centric or bite sized pieces of information that have horizontal appeal, applications that leverage any of the SharePoint features instead of building them, and corporate websites.

On the do not try list, he mentions high (transactional) list volumes, data / processing intensive applications and scenarios that involve integration as their core reason for being.

I would add that an important examination would be the type of request being made: is it a box or a line? I have talked about capability modeling before, but also true in integration, are we dealing with the concept of movement, transfer and collaboration or the actual process, workflow and human interaction therein? Many times, this can provide very unique insight: Would you build an accounts payable (box) solution in SharePoint or leverage it to perform secure dissemination, lookup and reporting of receivables (line).

Internal Demands

While David’s article does a great job focusing on the technology, it is equally important to focus on the internal equation you live and breathe every day. Developers have an existing skill set, you’ve made an investment where you need to realize a return, or you have outsourced a portion of your IT operations. These are all important factors and play into the ‘art’ I mentioned previously.

I find that a questioning framework works well – it doesn’t imply an answer but instead suggests topics for exploration. Continue to refine and discuss the answers as you move along the spectrum of choice:

• What type of timeline are you on? Can you leverage “out of the box” components at 80-90% fit?
• Who is building the application? Are you retaining these skills in house? Are you contracting them? How will you find the skill set later to manage and maintain?
• Is there an intermediate step that can be achieve? I often see applications go from Excel/Access to full blown Enterprise SQL/.NET custom applications. Perhaps we can leverage components inside a platform like SharePoint to provide a logical stepping stone.
• Is the request the result of a lack of authority? Governance structures are wonderful things until they start to inappropriately restrict self-service. Leverage the permissions model where appropriate, govern and manage policy and give the users the ability to satisfy their own demand. What is the correct mix of systematic vs. opportunistic development?

How are you addressing this challenge in your organization?

I’d love to hear about your insights into this complex topic!

Craig Gibson, Architect Advisor, Microsoft Canada