If you’re a SharePoint Architect, there are a number of areas you want to focus on in your career. Personally, I decided long ago that implementation, structure, automation of the business process in SharePoint is my focus. To do that, I combine my technical knowledge of SharePoint with the project planning, business and planning skills that I’ve gathered through over 20 years of Systems Analysis and Design.

SharePoint is a collaborative technology. But, after all, it’s simply a system, a software product. That system is subject to the exact same laws in terms of management as any other. Therefore, in terms of deploying it the processes and procedures followed will be exactly the same as any other system in that the planning, implementing, deploying and supporting processes will be ‘standard’.

This system needs to be fully understood by the relevant Solutions Architect, and as you will have guessed, for SharePoint this is a SharePoint Architect. This person understands the nature of the beast (deeply) and that also includes the format and application of any connected technologies to this system. And, that person would know how to implement features of the product using not just technical knowledge, but traditional Systems Analysis skills.

What?

You can’t be serious Geoff – The SharePoint Architect is a System Analyst?

Well, let’s look at the key tasks of a Systems Analyst and see how this ties in with the tasks of a SharePoint Architect:

1. Detailing and Understanding Current Business Processes
2. Defining Requirement Specifications to match with defined User Requirements
3. Designing, Planning and Producing a System Specification, including rules for management
4. Creating the Solution – Yes – the Systems Analyst could be a Programmer too (in some circumstances)!
5. Implementing the Solution, working the lifecycle (3, 4 and 5 again and again)

So, we could assume that:

1. A Programmer is not a Planner
2. An Architect combines Support, Configuration, sometimes Planning, even Developing
3. But, an Architect is not necessarily always the planner

So, let’s go to the Planning….

Let’s say that you have been appointed ‘SharePoint Dude’, and are about to embark on installation of SharePoint to an organisation. The organisation will definitely adopt SharePoint. That organisation wants to go down the route of applying a ‘trial’ platform which is intended to eventually migrate into a full platform.

Here are the very basic things you would need to do. So, making this look scary (but pretty real), lets say that you are the only person going set to do this (meaning, that you would be the planner, supporter, programmer – hey I’ve seen this happen!):

1. Gather requirements from the users e.g. site premise, structure, information analysis, data content typing, organisational structure, stakeholder management
2. Design the Solution e.g. Wireframes, Taxonomy, Metadata, Content Formatting, Capacity, Logical and Physical
3. Define the Implementation Process e.g. Procedures, Guidelines for use, Governance, Testing, Verification, Validation, Customisation
4. Design Support; SLAs, Backup and Restore, Disaster Recovery and Business Continuity, Staffing, Training
5. Installation, Configuration of SharePoint
6. Testing, Verification and Validation
7. Educate, Train and Educate the users

Hey that looks suspiciously like the Systems Analyst work?

So, as you can see doing this as one person is no mean feat – and if this is not communicated to the business from the outset there would be serious issues concerning the planning and implementation because no one would know the risks involved. Even if the SharePoint Architect is also the Planner that person would need to be able to prioritise all the tasks because the Architects hat will be changed very often! This means frequent confirmations with the business stakeholders again.

Additionally there is a split between what is perceived as technical (server and software configuration) and business driven (user requirements) needs. Whilst it may be prudent for the SharePoint Architect to gather, design, document and implement these some would argue that not only is it very time consuming and difficult to plan, but it means all eggs in one basket and again, without this being communicated back to the business there will be serious problems ahead…

See where I’m going with this?

The bottom line is that the SharePoint Architect is not the planner in a large installation project or a project where there is a requirement to gather lots of information. However, for a small pilot install where the risks are low it could be perceived that the SharePoint Architect is also a planner, though the definition of medium would have to be stressed to the business. And, in my view, there is no such thing as a SharePoint Architect in a small office / company installation …

Bold statements, Yes?

But, I think its key to understand that a SharePoint installation will go out of control without someone to drive the targets and meet time objectives. That’s where the planner / project manager steps in – and guess what – they would know SharePoint.

So, in summary. Organisations new to SharePoint who need to improve collaboration, information management and online web based communication need to ensure that a SharePoint Architect is provisioned to make it happen. The SharePoint Architects’ task is to ensure that the platform is resilient, performs, meets user requirements, is future proof. The Planner is there to ensure that its implementation takes place on time and in most cases to budget. Hence, ensuring there is control and standard systems analysis will ensure that SharePoint is not perceived as a silver bullet but as a tool that enables the client to be more data productive..