Will the “real” SharePoint Architect please stand up!
As we've all come under tight times these days, it seems that the working environment around SharePoint is changing dramatically. As the usage of the product has grown, so has the cottage industry around it.
While it is true that as a Microsoft Product based on .NET thus uses the common tool set for developers, SharePoint is a much larger animal than it seems. As a very mature set of tools, SharePoint has the power to transform an organization – or kill it.
As SharePoint usage has expanded, so have the types of people around to support it – Architects, Business Analysts, Administrators, Developers and Designers. While the ‘name’ of these roles may sound familiar in terms of .NET, they are quite different in SharePoint. Each of the roles in a SharePoint environment has a direct contribution to the overall success or failure.
In general, any “web based product” regardless of .NET, Java, etc. is something that most organizations can get a handle on. After all, it is usually to solve a specific need or set of needs for internal use, a client, etc. SharePoint on the other hand is many things already built. Content management, group collaboration, document control and communications are all different aspects. Getting your arms around the whole thing – and know how to implement it across the organization – is quite a challenge.
Knowing how SharePoint is used
The use of SharePoint is probably the biggest hurdle for most organizations. Hearing the accolades of what SharePoint can do, companies often implement it and then try to figure out what to do with it. In most cases, the initial attempt either stalls or completely fails.
The reason(s) for this are pretty typical:
• The business does not know how to implement
• Decisions are made without proper knowledge
• IT bottlenecks the usage or takes total control
• End users and content producers are not trained
• The long term purpose is not planned out
• There is no established governance controlling the use
Guidance (and lack thereof)
Many firms will seek outside resources to help them with SharePoint. In some cases, Microsoft Partners or consulting companies and in others, piecemeal teams organized ad hoc. This is where most companies make the biggest mistake. Many a “contractor” (not a true consultant) and many companies will tell you they have ‘extensive architecture’ experience and able to help the organization to implement it.
Unfortunately, the vast majority of them are overstating their expertise - it is not that they are really “lying”, but close.
One of the issues is SharePoint itself - provided in three flavors, Foundation, Server and Enterprise Server, it can be confusing when someone says “they know SharePoint”. Unless working at a high level with the product in every aspect (from content management to document management to integration with external systems), it is very unlikely that the “Architect” knows the whole story. Many a company will say they have a “SharePoint Practice” but have implemented it only a few times in small shops.
Likely the biggest problem is that many (both individuals and companies) think that simply ‘time’ working with SharePoint qualifies them as ’Architect(s)’. They've implemented a farm or two or worked with a single Farm for a few years and feel like they are the ‘go to person’. However, that’s the extent of their knowledge. In addition, many “architects” – including those in consulting firms, will say “I know SharePoint, but I don’t do development”; unfortunately an admission to their lack of understanding of the product. You can’t say you can design a car without having driven one.
Finding a True Architect
For SharePoint, the areas of knowledge for architecture are wide spread:
• Business Acumen – Must be able to understand YOUR business, be it manufacturing or telecommunications. This means a general idea of the goals of the organization, including an understanding of capital, overhead and ROI.
• Governance – Knowing the best way SharePoint can be leveraged within your organization requires extensive understanding of governance – the how, what and why of the use.
• Risks and Impact – Clear understanding of the impact SharePoint will make to individuals and job roles along with knowing the associated risks are the keys to implementation.
• Practical Knowledge – Understanding of the way in which SharePoint will affect the organization in terms of daily business operations around business continuity planning and disaster recovery.
On the technical side, a wide range of skills are also needed:
• SharePoint Administration – Ability to setup, configure and tune a SharePoint implementation based on the intended use.
• Windows Infrastructure – Ability to design and build the necessary infrastructure (OS/Servers) to support the intended use.
• SQL Server – Ability to plan and size the infrastructure to match the need and growth of the storage needs.
• Visual Studio – Ability to design and develop solutions as well as guide others in learning how to leverage SharePoint as a platform
And there’s always training – an architect should be able to provide training skills and knowledge transfer at all levels – from the CIO to communications to HR to developers to users.
Make the Right Choice
It is true that SharePoint can truly transform a company – from communications to applications development and unless you intend to be a SharePoint consulting company, don’t do it alone! You need guidance – but you need to be SURE you are getting the expertise from the right source(s).
A ‘true architect’ should be able to assist you in the entire process from analysis through deployment. Once turned on, the architecture designed and knowledge transfer should be enough to enable the organization to manage and maintain it going forward.
Start by asking questions - regardless of an individual or a consulting firm, you need to ask questions to determine whether they can really provide you the services you need:
1) How many implementations (end to end) have they done? In your industry? In others?
2) Can they handle the entire process from analysis to deployment or just a part?
3) Do they tout that they've “built sites” (a red flag!) and emphasize out of the box features as expertise?
4) Do they push for a large engagement with a project manager, developers, etc.?
5) Is development the first thing they talk about or do they explain how to leverage SharePoint for what it does first?
6) Do they have the business understanding to know what your organization needs? Can they relate to the types of constraints on budget and time?
7) Can they provide knowledge transfer for the entire organization or are the offering just to ‘turn it on’?
8) Do they provide direct knowledge on business continuity planning in the event SharePoint is disabled or completely unavailable?
9) Do they know the differences between SharePoint Foundation, Server and Enterprise?
10) Can they explain the SharePoint Installation Wizard and when NOT to use it?
Understanding the above will help you to make the best decision – you don’t want to become another learning exercise for the inexperienced. Don’t be afraid to ask for an example deployment; if they really know SharePoint, deployment of a small farm as a test should be no issue (for the record, such a test would take no more than 8 hours).
Overall, if a consultant or company makes you comfortable with the overall expertise required and can provide you with demonstrated knowledge, go with it. If they do not have unified approach or cannot demonstrate they know HOW to use it, pick someone else!
Of course, SICG has all the skills you need – we've done more end to end implementations globally than anyone! Not finding the right folks? Get in touch! firstname.lastname@example.org