So a few people recommended I post my slides or content from my
European SharePoint Conference session. I cover a list of
considerations that makes a good reference for people undertaking
the design of custom applications on SharePoint.

Usually in projects you would have people responsible for the
design of the infrastructure and then a development team would dig
into the technical design of the SharePoint application. They will
try to answer how different components will be used to satisfy the
requirements. Solution Architects explore various options for
meeting each requirement and all these options and choices
intertwine into a proposed design, maybe a model or a proof of
concept, and hopefully a document. Projects that miss this
communication are either chaotic, or extremely agile.

When doing architecture there is usually more than one possible
way to achieve the same thing – the “right” one will depend on the
situation and each of the things I’m pointing out here could be
equally right or wrong. This is especially true for SharePoint.
That is why “awareness” and the knowledge of SharePoint are one of
the key requirements for an architect to be any good.

This list is not the ultimate list – it is just my summary of
what always lands on my table. It is also not the base for a
definitive Technical Design document (it’s a start!). Some items
below didn’t get mentioned in my talk as time was limiting what I
could include.

Front-end Planning
Page Model – How you plan to store you (ASPX) pages
•Application Pages (_layouts)
•ASPX files served from a Document Library
•ASPX files in folders
•Publishing Infrastructure – page layouts
•Consider Web Part Pages vs. Wiki Pages

Form Strategy – Consider how you will capture data and
what controls/interfaces you will use
•Understand how SharePoint forms work and consider using
SharePoint’s API’s
•SharePoint InputControls are great but may be difficult to use
and may have limitations
•Consider exchanging data between forms. Plan Session and
ViewState requirements
•SharePoint Scenario Framework
•Consider validation requirements and the UX on the
validaiton
•Also consider Silverlight and InfoPath forms as alternatives for
capturing data

Client-Side Scripting – plan out any requirements for
client-side JavaScript
•If using validation, plan out your client-side scripting
and the use of any frameworks
•Will you use the Dialog Framework or any other popup/dialog
framework/toolkit?
•Consider the use of jQuery, Modernizr, Knockout

Page Components – define what controls, web parts or other
components you will use to create the actual interfaces
•Web Parts vs. User Controls
•SharePoint Rendering Templates and the Form UI
(_controltemplates)
•Consider the styling/branding of your custom interfaces – you
don’t want your developers to be designers (unless they really
are)
•Iframe – various solutions use Iframes to display external
content or components hosted elsewhere (plan out
authentication)
•Consume HTML asynchronously – I have seen solutions that grab
HTML from an ASHX or other services
•InfoPath – always think about the User Experience when you deal
with InfoPath
Resource Files – evaluate how you will use resource files and what
components will require localisation
•Code-behind resource files
•ASPX resource files (14Resources, AppGlobalResources)
•Feature Resources
•Localised Web Templates

Back-end Planning
SharePoint Data Model – define the storage of data
Consider:

•How are you going to store data?
•How will it scale?
•How are you going to access it? (SP OM, External Data (BCS), Web
Service calls)
•How are you going to “replicate” it? (backup, archive, move/copy,
log)
•How are you going to store applicaiton settings (SP list, P&P
Settings)
Visual Studio Solution Structure – How will you structure code and
artefacts
•Number of WSPs/Number of Features
•Separation of code
•Separation of SharePoint items
•Namespaces and naming conventions
•Source Control strategy

Design Patterns/Anti-Patterns – make your code
maintainable and nice if it makes sense to do so
•SharePoint Service Locator (P&P)
•Façade/Adapter
•Consider/plan your data access layer

Security Model – don’t think about it in production
AuthN:

•Kerberos/NTLM (consider the requirement for Kerberos)
•Claims (consider the effort to pull it off and any
side-effects)
•Plan the use of service accounts and access for/to external
systems
AuthZ:

•Use SP groups or AD groups?
•Nested groups
•Do you really need item-level security?

Exception Handling and Logging – define how to
display/capture errors and how you log them
•Consider how you will display errors to the user (don’t
do lblMessage.Text = ex.ToString(); )
•Define what needs to be logged and how
•SharePoint Logger (P&P) gives you a good API for Diagnostic
categories and areas
Deployment

Other Knobs and Dials – there are many other things that
affect deployment
•WSP lifecycle
•Feature activation
•Activate on Default
•Deployment configuration
•WSP additional DLL’s
•Force on Activate
•Safe Controls
•Web.config modifications
•Web Part deployment
•List re-creation
•Feature Upgrade

Site Templates – reusable functionality that admins or end
users could provision
•Site Definitions
•Web Templates
Continuous Integration and Testing
•Plan and define the CI/Build process
•Always consider how you will upgrade the solution
•Define the unit testing and mocking requirements (Pex &
Moles, TypeMock)
•Funcitonal UI Testing (Selenium, Coded UI, Telerik Test
Suite)
•Always sync with the test team and what they do/how they will
test your solution

To close off the talk I finished off with a few tips:

> Build applications in such a way that makes you feel proud
of what you have built. Doctors feel good when they help people,
architects feel good when their creation is built, lawyers are
happy when they get paid – there is no reason why SharePoint
developers and architects shouldn’t feel good about what they do if
they do it well.

>Motivate your team to do good work – As an architect you are
most likely a role model. Do your best to motivate your team
members to be champions and get good stuff out there. Reward them
for good efforts.

> Change your job if your boss/architect/team leader/project
manager is pressuring you to do crap work with no process around
it, no scope, no clarity, no design, etc. Your SharePoint career is
way to short for you to be doing crap work in crap teams. Only you
could make that change.

>Apply development practices and architecture to SharePoint
solutions – many say that there is no real development in
SharePoint. It’s true that there is a lot of “other stuff” in
SharePoint projects, but for the development part – make it
count.

Here is my slide deck
SharePoint Solution Architecture – Radi Atanassov

During my talk I showed bits of a solution I use to POC various
SharePoint components. I use it to explain and demonstrate things
to students, forums and colleagues. I call it Community.SharePoint
and as soon as it has a few other key components I will post it on
CodePlex.

Here is the version I used at the European SharePoint
Conference:
Community.SharePoint-EUSPC

Hope this helps someone!