While the trends already mentioned so far in this chapter are the most prominent ones that impact SharePoint, there are a few others that are well worth mentioning. The next few trends are often discussed with very different perspectives based on experience, and while there are no clear answers, there are certainly a few important points you can make to help reduce the uncertainty you might be facing.
A: One thing that SharePoint does a great job of is shining a light on all of the issues in your organization. While this can be considered a good thing, it can be very damaging if the organization isn't prepared to respond effectively.
A very common example of this is when an organization decides to index a file share and then finds a large number of documents that should be private or secured, but are actually not secured. SharePoint didn't change security, but it highlighted the existing security issue.
SharePoint permission sprawl (the uncoordinated and untrained application of permissions) is often one of the biggest challenges facing large implementations. While SharePoint security and permissions are robust and have most of the native capabilities organizations require, managing security and permissions over time (and across multiple sites or site collections) is extremely difficult with out of the box capabilities. This is also why there are product companies that specialize in providing additional security administration options for SharePoint.
It is critical for successful implementations to have clear permission guidance and to follow Microsoft recommended practices around fine-grained permissions (item-level permissions) as SharePoint performance and usability can be impacted by the permission sprawl.
For many organizations, SharePoint represents an opportunity for end users to manage their own permissions, but many organizations struggle with governing, training, and supporting this level of distributed permission management. When planning permissions, the organization should start with its existing active directory groups (when applicable) and focus on maintaining visibility and understanding for how content is being secured so that guidance, support, and policies can be updated accordingly.
Beyond just securing the information from an individual worker level you also have to keep in mind the importance of securing the entire environment. The positive thing here is that SharePoint is based on Windows server security as well as existing firewall security. So as long as you are diligent and maintain the security at both the external and internal server layers, often the providers themselves (such as Microsoft) will provide necessary patches, updates, and upgrades to ensure the environment remains secure.
Also, SharePoint has many security hardening measures that can be put into place from the farm and sever level, all the way down to the site collection level. Of course the more secure you make things, the harder it is to keep performance and user experience high. There is a saying that a system with no users/access is the most secure system, but that also means that the system isn't providing any benefit. So find the right balance based on your own business needs.
A: According to Gartner, by 2012 agile development methods will be utilized in 80 percent of all software development projects. The number of organizations adopting and leveraging agile software development to improve IT is continuing to grow. IT departments are finding that by introducing agile development methods, they are able to respond more rapidly and deliver more value to the business.
Agile software development is a software development methodology based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.
Agile development methods work extremely well with SharePoint solutions. Why? Put simply, because SharePoint is a large and complex platform. It requires careful learning and does not follow a simple pattern where one can know everything and account for everything in planned stages. Agile development focuses on building solutions where the requirements evolve and take shape over multiple iterations, making it a much more effective set of methodologies than ones that require significant or complete understanding at the outset of the development project.
Note
Even Microsoft Certified Master (MCM) and Microsoft Certified Architect (MCA), the highest level of certification possible with SharePoint, admit that no one person can know absolutely everything about SharePoint. In fact the MCM motto is "know what you know, know what you don't, and never confuse the two", which is very relevant for SharePoint work.
Another of the big issues is that SharePoint involves heavy user interaction. Often the challenges faced with SharePoint solutions and implementations are not technical challenges, but instead social or business challenges. This often results in expectation management and delivery problems, which are mitigated through the user or proof of concepts iteration, and earlier user involvement (all the things Agile development methodologies do well). In other words a more linear method will be less effective than one that is iterative.
The erratic line in the previous screenshot (from Jeff Conklin's outline of wicked problems http://cognexus.org/wpf/wickedproblems.pdf) outlines the cognitive activity of a designer when dealing with a design or planning problem. What it symbolizes is that the (solution) designer actually learns and improves his or her understanding, even when well into the implementation phase, if dealing with wicked problems. In SharePoint, many problems are actually wicked problems and follow this same pattern of opportunistic learning.
If you recognize that developing and delivering solutions with SharePoint effectively involves many rapid iterations, proof of concepts, and prototyping where you can get more user feedback, improve your understanding, and show more demonstrable value, then agile development methodologies align well with the less defined or structured SharePoint projects and solutions.
In fact for many of your clients SharePoint development is easier when building solutions using out of the box (OOTB) capabilities. This usage of OOTB capability leads to reduced testing, and more rapid development cycles as well as an increase in the volume of development projects. This increase then results in the organization looking at new ways to meet the increased demand and to effectively support the growing user expectations. While no single methodology alone is the answer, there is value in using agile methodologies with SharePoint.
A: "It depends" is always the correct answer to this question. The advantage of buying over building relates to scale of development and cost. It is mostly much more cost effective to buy, but it reduces the control you have on the application or solution.
With SharePoint's long upgrade path of over three years between versions, the build or buy is simplified as typically a product or application will deliver value for at least the lifecycle of the current version of the product within your enterprise.
There are over 4,000 SharePoint partners in the Microsoft ecosystem. Almost every one of those partners has solutions, tools, or products that help businesses get additional value out of their SharePoint investments.
So if you are considering building instead of buying, take two steps back and re-read that statement. It is rare for someone not to have experienced your challenge, and rare in the SharePoint marketplace for a solution not to be developed and available for purchase that has been vetted or implemented with multiple clients.
The trend in the marketplace is that far more people are buying instead of building with SharePoint 2010 over previous versions. With over 1000 SharePoint solutions and products in the marketplace and over 1000 in development, this shouldn't come as a surprise. That means that there are as many solutions, products, and add-ons in development right now as there have been built in the 10 plus years SharePoint has been in the marketplace.
Beyond the economic advantage of the tool costing less to buy than build for the organization as a whole, many organizations also prefer to have the software assurance and support agreements that come with such tools. Since SharePoint has an upgrade path, it is often useful to understand the company's approach for SharePoint upgrades for each product. Since most provide upgraded versions of their products for each SharePoint version, this can also save you the internal costs necessary with having to rebuild your own customizations before each upgrade.
While there is still a strong market for SharePoint tools that simplify administration, development, and training, there is also a quickly growing market of SharePoint applications. These SharePoint applications are different from the tools or heavier products, which focus on technical challenges and limitations; the applications often focus on end-user interaction and business challenges instead. These solutions are often built and sold by services firms or companies that aren't purely product companies. As a result it is important to carefully evaluate whether these are truly turnkey solutions, or whether they are services packaged to look like a turnkey solution.
A: While there is speculation around SharePoint marketplaces, there are a few reasons for why this growing interest may be taking place in the industry:
- SharePoint 2010 is a more developer-friendly platform and it is much easier for developers to get started than with previous versions due to increased documentation, market maturity, better certifications, simpler tools, and more training material.
- SharePoint 2010 standardized on a consistent delivery mechanism for almost all customizations.
- Code enhancements and sandbox management enable more business units or multi-tenant/shared hosting clients to use custom applications and solutions.
- The number of organizations now using SharePoint has grown drastically over the past few years. This makes it more attractive for businesses to develop and market solutions and applications.
- According to multiple surveys from Global 360 and AIIM, more and more businesses are beginning to use SharePoint for more than basic portal or intranet scenarios. This increasing maturity is creating a greater demand for specific vertical or horizontal business solutions.
In fact the SharePoint services industry is worth well over $6 billion. Does that sound intimidating? Microsoft stated that for every $1 of licensing sold it has led to between $6-9 of services. This makes sense when you consider that strategy, infrastructure, upgrades, migrations, integration, search, and development (such as branding) are all examples of services for which organizations often leverage external expertise.
For customers, this means that there are over 4,000 (registered) system integration partners who specialize in SharePoint around the world to choose from.
This is a good thing. It means that there are more competitive prices, more local partners you can connect with, and an abundance of solutions being built on SharePoint.
If you are having a business problem, it is almost certain that another business has had that same problem. With the size and breadth of the SharePoint partner ecosystem it is also almost certain that a partner has built, or helped build a SharePoint solution for that specific business problem. The more mature and frequent the business problem, the higher the probability that there is a structured and supported product built on SharePoint that solves it.
The downside to this is perhaps more important to highlight. It is a challenge navigating the world of SharePoint consultants and solutions. SharePoint's success has led to an abundance of partners rapidly developing SharePoint practices and many organizations being sold inexperienced or ineffective SharePoint services and solutions.
If you take this abundance of applications into account with the discussions around agile development and the growth of cloud technology, it begins to paint a very rapid, iterative, and business-focused picture of how IT must deliver technology solutions to the business. This change to how IT delivers may only be focused on communication and alignment initially, but over time will lead to behavioral changes, cost-allocation changes, and entirely new ways in which IT supports the business.