SharePoint Explained Using Salem™

You might plausibly expect this to be an easy question to answer but in fact it is one of the hardest questions to resolve in the last twelve years of business technology development. Perhaps almost as hard as defining the term 'cloud'! During the Microsoft SharePoint™ Conference keynote in October 2009 in Las Vegas, Steve Ballmer, CEO of Microsoft Corporation endeavoured to answer this tricky question and you can watch his worthy attempt here:




Interestingly this was Steve’s first SharePoint keynote. Now what Steve rightly stresses is that SharePoint™ is unique and this is extremely important for being able to describe what it might actually be. It comes as no surprise that almost everyone has tried to describe SharePoint by its technical attributes, components and features which is exactly why for as long as one can remember, Microsoft has described SharePoint via the famous segmented ‘pie’ which groups together categories of features. Various graphically-enterprising Microsoft Partners over the years have endeavoured to re-create the ‘pie’ to try and make it easier to understand by business audiences, but the real issue is that this problem exists exactly because SharePoint is being described by its technological features.

It is worth noting that further problems ensue when one tries to describe SharePoint by comparing it with other ‘competitive’ products in the market. The issue is that there is currently no truly ‘like-for-like’ comparison out there, and consequently comparing apples with pears becomes a futile task. For example why compare SharePoint Online or Office 365 with Google cloud offerings?

The comparison only really becomes valid when SharePoint is removed from Office 365 and the comparison with Google made again – then there is a closer feature set to compare – apples with apples if you like. Similarly how can one truly describe SharePoint by comparisons with Oracle Beehive or IBM Lotus Notes. They simply do not square up.

With the incorporation of Yammer™ into the Microsoft stack, confusion reigns supreme. Should a client define its strategy by choosing the social features of Yammer or the social features of SharePoint 2013 or seek to identify its plan via the integration roadmap of features into Office 365? What happened to business defining business requirements and then requesting a blend of technologies to facilitate?

Okay so back to describing SharePoint (or for that matter Yammer) for what it is, without comparative equal and required to be explained in isolation. Take a different view for one second. Let’s not describe SharePoint through its technological features at all, but instead through its business potential. The Salem (Sequenced & Logical Enterprise Methodology) Process business framework for SharePoint describes it as a sequential and logical group of modular, inter-related business services that describe any organisational ambitions with information, publication and collaboration. Image therefore that a business modular framework is used to describe SharePoint without ever referring to its technical capabilities and feature sets – what would be the benefits?

* Business understanding and interpretation of value
* Strategy beyond an ever changing technical feature set
* Strategy translates to a blend of both cloud and on-premise services
* Business program rather than IT project approach
* Business sponsorship that drives business adoption
* Sell Office 365 benefits through SharePoint business services

It was Mark Zuckerberg who noted that every new enterprise platform appears to be defined almost solely by its latest technical feature set and SharePoint is certainly no exception. In the 2007 release of MOSS much was made of new features such as blogs and presence via OCS integration. By 2010 it was the ribbon and easier user interface changes as well as FAST search. By 2013 it was unified search and community sites as well as social features. The SharePoint Business Strategist understands these features and comprehends the value they may bring, but only within the context of a wider business framework. In technological terms, SharePoint is increasingly an eclectic kit-bag of publication and collaborative tools, services and features that can be used somewhat like a Lego set to build technology solutions driven by business need.

Receiving SharePoint for the uninitiated is rather like being given a toolkit as a gift. The first question would be: what do I do with this? Build something is the answer. Build what? Whatever you want or need to build. I’m not sure what I want, is there a blueprint or plan? No. Can we build what someone else has built? Sure. Can you help us build something the same as someone else has? Sure yes. How much will it cost? It depends what you want, we will need to discover what your specific needs are. Yes but how much will it cost as a ball-park figure? It depends on what you want. I want what everyone else has! Ah but everyone else is different so we cannot tell you how much it will cost and how long it will take until we have defined your exact requirements. And so it continues… In other words, the SharePoint toolkit is powerful but without a logical, progressive business plan, blueprint or roadmap alongside SharePoint is extremely difficult for a business audience to imagine in terms of a future, valuable whole.

Business stakeholders have a requirement to describe SharePoint to their own internal audiences and this is frequently where initial problems occur. They call in a Partner to demonstrate the value of SharePoint in an hour. What is all too often described is a technical demonstration of a team site, or a workflow, or a form, or version control etc. SharePoint is being described both by some isolated features, and in isolation of a fuller business context. This issue regarding describing SharePoint is often anticipated by Partner Sales Managers prior to a client presentation by requesting some specific problems the business may be prioritizing and basing a pitch and demonstration regarding how SharePoint can solve these specific problems.

Therefore SharePoint, as an enterprise platform, is all too often described in these situations primarily as a project-specific technological solution. What happens when that problem is solved – where does the client go then, what does the business do next, what else can they build? And so we come back to the same dialogue as before. What other problems do you have? What other priorities can we assist you with? How much budget do you have? It is because of this scenario, played out hundreds of thousands of times globally that a number of things have occurred that have assisted in defining SharePoint in a specific way.

The first is the flexibility of solution design and delivery. This has led to SharePoint rather frequently being described as a ‘development platform’. ‘Tell us what you want and we will build it’. Ah, says the client, but we don’t know what we want. ‘It’s okay’ says the platform developer, SharePoint can be used to develop and provide you with anything and everything you want. Within a short space of time of the introduction of SharePoint solutions are being built without any form of business plan.

Another way of defining SharePoint has been through the project-centric approach of IT divisions as the primary purchasers of SharePoint. The software has become available as part of an Enterprise Agreement or other licensing service, been adopted by the IT department as it is software that has been bought, paid for and is otherwise sitting going to waste. IT uses it to create a demo, proof of concept or test platform for a business issue that lacks budget, that quickly moves from demo to business critical solution, often unwittingly and often in an unplanned or unintended way. Too late, SharePoint is therefore described in such circumstances as a project-centric solution platform driven and justified through organic growth. This description has in fact occurred because SharePoint was not understood as anything more, has no business roadmap or progressive blueprint and was not budgeted for as anything more than available software that could be deployed to provide rapid, disconnected solutions.

For many, SharePoint will be understood and described as software for building intranets. This description is frequent because of SharePoint’s presentation of services through a web browser and through its excellent ability for custom and fairly easily-provided custom user interface design. Similarly this has occurred due to ageing incumbent technologies such as HTML intranets that have long since been abandoned by the business or have fallen into disuse or decay for a wide variety of reasons and which can be migrated to SharePoint as a starting point. Indeed migrations from legacy systems which have run their course is often the basis for a business understanding of what SharePoint is. SharePoint can all too often be described as the ‘replacement’ for something else. You can spot evidence of this for yourself through the (often unnecessary) branding of things. For example, an intranet is called CorpWeb and the contents have been moved to SharePoint so now SharePoint is described to business audiences as CorpWeb 2. What happens when a different service is introduced onto the SharePoint platform? Does the business user describe SharePoint by multiple brand names or are they simply confused? Perhaps if a business user states that they have placed something on SharePoint that we are getting closer to being able to describe SharePoint as a business-ubiquitous set of eclectic services.

For many, SharePoint is understood and described as a document management system. We would need to break down the last decade or more to see what this is the case in some many instances but in part it was because the earlier free versions such as WSS and later SharePoint Foundation offered document management through team sites at no cost, fairly easily deployed and once again adopted by business users through various types of organic growth. Let’s take the issue of the cloud and Office 365. Is Office 365 SharePoint? No it is a collection of services including Lync and Exchange, Office and SharePoint (depending on the chosen licensing plan). Would we choose to describe SharePoint as Office 365? Perhaps not! Is Office 365 described by SharePoint? Generally no: So irrespective of cloud hosted services, SharePoint whether online or on-premise still needs a rational business-orientation description of what it is. If SharePoint should not be defined by its technological feature-set composition then what is SharePoint? On the one hand we may argue that it is whatever we want it to be, that is the raw beauty and power of such a flexible and richly extensive technology platform. However choice costs money and we currently live in a global economy where choice, though desirable is seen as increasingly expensive, if not out of reach.

 The ‘app’ approach to commoditized technology is prime evidence to business seeking quick solutions that meet 80% rather than 100% of needs and that speed of access is more valuable than being truly fit for purpose. Let’s try to clear our minds and think of SharePoint not as one or more as its technical features past or present. In fact, let us not describe SharePoint through technology at all. Instead let us think of all the common things that organisations are trying to achieve, all the common things that businesses want to do with their information and all the common ways in which information is produced, stored and typically shared.

Let’s embrace how human beings work, what they like to do and what they avoid. Let’s remove technology words and replace them with business language. Let’s then take all these things and place them into a blueprint that has a logic and a sequence but which can be adapted to almost any eventuality. Is this possible – can SharePoint really be described this way? The answer is yes it can and not only that it is extremely sensible to do so. If you are to be successful in describing SharePoint then you must engage the minds of your audience and provide empathy and you can achieve that through common perceptions and understanding. You must describe SharePoint using business terms and business services and your description must show not only a flexible blueprint but also a roadmap. In doing so, the features and technical services of SharePoint will naturally slot into place.

Think of SharePoint as a comprehensible, modular set of business services that are themselves composed of business sub services. Think of these business services has having a logical sequence of release, of having a relationship with each other that determines the most effective business adoption sequence. Think of SharePoint as a set of business services that encapsulate anything the business may be aiming to achieve and which can adapt to cope with new and future business challenges. Place all these business services within a framework which visually describes the entire business enterprise within minutes. Use such a business framework to provide a cohesive vision of the entire business enterprise to the extent that other technologies are aligned with SharePoint in context so that SharePoint, as the business framework, provides both a business and an IT roadmap. Does this mean that SharePoint, through its definition as the enterprise business framework sits at the centre of the business vision? The answer has to be ‘yes’.

Applied to Office 365 in future SharePoint Online as a progressive enterprise business framework will be critical in defining cloud strategy, rather than simply via Exchange and Lync as things have stood to date, just as the same framework is critical to onsite strategy. Those who wish to rally against describing SharePoint from a business context may simply be those who are working in a haphazard, unplanned way for a wide variety of reasons, or are fearful that they do not have the business backing and budget to progress successfully but hope to gain it through stealth.

Alternatively it may simply be a question of strategic training and learning, which is one of the purposes of the WASBS. You may have encountered those who are vehement that unstructured or organic growth are the best mechanisms for business adoption or that business frameworks are too ‘inflexible’. If so, consider for yourself why some make these cases and whether in fact there is something else really underpinning this viewpoint. It is true that most have not yet been trained in a SharePoint business framework but in most cases it is a complete revelation when the business framework approach is described fully.

So is SharePoint best described as an ECM and EDRMS platform with social and community and search functionality or is it better to describe SharePoint as a progressive business program of inter-related and inter-linked business services (and composite business sub services) which may be sequenced to fit specific organizational priorities and yet ultimately achieve the same enterprise goals as a different organisation following the same blueprint that has been sequenced for them? The role of the formally-trained SharePoint Business Strategist is to describe and sequence the business blueprint and roadmap for SharePoint for any organisation by using a framework, methodology approach. In turn this will describe what SharePoint really is, through its business value and its progressive logic.

The primary reason the business strategist role is able to achieve this task whether it be cloud or in-premise is because part of the strategist training is to understand why this approach is achievable, how it is achieved and what are the outcomes and next steps that naturally follow. As we saw at the beginning with Steve’s keynote in 2009, SharePoint is difficult to describe through technology features alone and anyone who has really tried will accept this as fact. SharePoint can be many things to many people but it is certainly not all things to all people. Its diversity can also be its undoing at times and all too often its description through technical features leaves many business audiences cold and many others detached or dis-engaged. Yet business needs often remain the same decade after decade. Consider for yourself the entire concept of describing SharePoint or comparative and companion platforms not as technology at all but instead as a structured business framework with Salem™ and you will be far better placed to succeed in describing what SharePoint is to anyone you encounter along the way.