SharePoint 2013 major disruption in UI and UX

SharePoint 2013 Team Site in Office 365 is a major change in UI, making a more tablet friendly simply design

 One of the most striking things about SharePoint 2013 is simply how it look.  The new SharePoint is a radical brake from all earlier UIs.  SharePoint 2013 UI is more tablet friendly and simpler, with larger objects and less clutter.  SharePoint is also reducing the number of objects the confront the user.

SharePoint 2010 Team Site has most of the same features as the 2013 site, but is fully grounded in the PC world or mouse clicks.  Imagine trying to manage this thing with a finger.

I am finding SharePoint 2013 much easier to work with than SharePoint 2010, and a greater improvement over 2010 than 2010 was over 2007.

SharePoint 2007, while the UI changes between SharePoint 2007 and 2010 were in large part cosmetic, SharePoint 2013 is a real change in how people will be able to interact with SharePoint.

I think it would be a major mistake to think this is just a skin deep transformation, which it is easy to think.  Working with the new SharePoint 2013 you quickly see that it is mostly the same as 2010 under the hood.  But the new UI also comes with a new App model, new RESTful web services interface that returns JSON and ATOM, new JavaScript API model for cross domain communication.

Microsoft is embracing disruptive web technology from places like Google, Twitter, Facebook and the start-up culture of open interfaces.  Things are going to change a great deal, SharePoint silo nature may change for something more like Twitter.

A use case for SharePoint 2013 App Model

There probably is a heavy temptation for managed services providers who host large data centers that are sold as Clouds, to continue to develop Full Trust Web Parts even when going to SharePoint 2013.  Web Parts are what coders are used to, they may have a large library of existing Web Parts as WSP files that run in full trust.  This is possible, and it means working pretty much as you always did.

But if you are like most managed service providers I know you have some kind of internal structure between your infrastructure providers who build and maintain the farms and the application and solutions providers who face the customers and develop SharePoint from a raw out of the box in to something more specific and rich for their needs.

This DevOps work has been traditionally very difficult to manage in SharePoint.  When you would develop a solution to run in SharePoint 2010 you would hand it off to a deployment management team who would have to review the code for security risks, and impact on the servers. Since the code would run in the Farm it had an Enterprise level impact. This would involve extensive documentation and review, and complex levels of support for your solutions.  In the end you would probably be dependent on a different department of the company to deploy your work but still own the risks if they made a mistake.

By adopting a SharePoint 2013 App Model you can move away from this.  Two teams, even if they work in the same company can concentrate on what they are best at.  Infrastructure can concentrate on meeting SLAs, providing backup and DR and applying patches.  

Solution providers can create partial trust solution that use .NET SCOM or REST and JSON to create rich interfaces that are hosted in other domains, perhaps even other server farms with different domain controllers.  You now no longer have the tight link between the people installing SharePoint farm and the developers of solution, in fact you can separate your teams so that one applications team can create solutions, potentially in PHP or Ruby or anything really, that work off more than one SharePoint 2013 farm.

And if your clients decide to not renew the hosting contract with SharePoint to go with Office365 or another vendor, you don't necessarily lose your applications business.  You can still provide your application solutions simply by changing the RESTful web link.  You can de-risk big SharePoint deployments by breaking hosting from solutions, allowing your customer the option to keep one if they are unhappy with the other.  

So it makes solid business sense even for established big players to embrace JQuery and RESTful and build App that run in separate domains using OAuth and OData to communicate with SharePoint, creating UI in HTML 5 and CSS 3 because after all we all hated SharePoint OTB UI (admit it).

The potential is perhaps even greater for smaller firms.   Now a smaller firm with a team of talented web developers who know about JQuery, mobile, tablets, RESTful, OData and rapid design can muscle in on a space that previously only the provider could have.  And I speak from hard earned experience when I say that the big guys will be more than happy to have third party code isolated in its own IIS server rather than installed on perm SharePoint farm.  

It also my experience that the culture that makes a first rate development and business solutions firm (agility, innovation, creativity and social understanding) is often different than what makes a first rate hosting firm (stability, precision, technical expertise, compliance and control).  With the App Model the the create web designers don't make anything you host on the SharePoint Domains and the systems admins are not going to dictate solutions to the creatives.  You can have a more comfortable distance between application developers culture and hosting culture, and we all know sometimes IT people don't play nice together.

Really it is worth taking the time to really think through the changes to the ecosystem that Cloud hosting of SharePoint and App solutions will bring.  SharePoint has had a series of evolutionary changes since 2003 and its made some of us lazy (looks down in shame).  New SharePoint releases were a matter of learning a few new features and services.  But the App Model is a much more revolutionary change and it will change the business model.

Be ready or you will lose. 

JavaScripts and Cross Domain in SharePoint 2013

The most exciting new feature in SharePoint 2013 for an old web developer like me is the embracing of JavaScripting, JQuery and open standards.  Now more and more of what is done will be done in JavaScript, a language almost all developers know, and less in C#

Microsoft Office embraces the concept of Apps

 

The concept of the app, a small piece of special purpose code sold or distributed on the web, is catching on to Microsoft.  The greatest thing about the new app model for Office and SharePoint 2013 is not only is it built on web standards like HTML 5, CSS and JavaScript, but it is sold and distributed in a business model people will easily understand: the app store.

 

You can buy an app on an app store, or have one developed to special task either inserted directly in to the tools you use like Excel or on SharePoint.

 

I personally am looking at Excel apps, as I think for Big Data this is going to be a killer app.

Apps model for Office and SharePoint 2013

Things are changing in the App world for SharePoint, Microsoft is doing what it does best, copying what other people have already made. And Office and SharePoint are embracing the App model based on open web standards.

Office 365 makes the iPad a work tool

 

We all know that iPads and Android tables are great.  But we also almost all have felt that these new tools sadly are not so useful at work.  I have found that Office 365 actually can bridge the gap, allowing me to use my iPads as a tool to create documents, wikis, lists and links in my iPad.

 

I am currently working with SharePoint in Office 365.  Though full use of Office 365 on iPad is not possible.  Office 365 needs Napa which does not run on any of the browsers, and you can't open Office documents.  But, if you configure you SharePoint site to open documents in browsers an Office 365 site will let you suddenly turn an iPad in to a enterprise productivity tool with all of major Office features.

Agile failed for Universal Credit, and perhaps is not right for government (opinion)

Computer Weekly asks why agile development failed for Universal Credit and gives a fairly powerful answer.

Its a shame that the article is so long, because the summing up points are not that complex and ones that people in IT and Government should be able to see.

Agile is a method that came out of academic, R&D and some corporate IT.  At the core of Agile is out modern age's embracing of uncertainty and change.  In an Agile project you might decide to build A for $20,000 but end up getting B.  In the past this was called mission creep, but as time evolves we are more and more likely to see it as a good thing, as Agile.

I think the first thing I learned in software as a business is that one person's bug is another persons feature.  Much of what we do in software is setting up value systems and criteria by which we are going to judge software.

Another thing I learned the hard way is that these criteria need to be appropriate for the group which is going to use the IT.

Its seems obvious that the new government that came to power in 2010 in the UK wanted to, as so many new governments do, adopt some new cost saving concepts from the business sector.  For IT the buzz for some time has been Agile as a way to save money and speed up development time.

Agile is hard to precisely define but overall its a reaction against classic Waterfall, where a set of requirements create a design lead to a build, go through testing and go live.  This fix cost, fixed outcome model has been standard for a long time and has become hated by just about everyone in IT and business.

As cheaper computers and then virtual machines came along the sector embraced more agility.  The core idea was that rather than Waterfalls fixed concept of fixed features, fixed time frames and fixed cost you could do a better job allowing one to vary.  So if you have fixed casts you can decide to get a fixed set of features but allow the project time frames to change, or you can fix time frames but review features over time.

It seemed like just a confession of reality, Waterfall projects are infamous for over running in either time or cost, or not delivering everything promised.

The problem for DWP, and any big government agency is that the role of government is not agility.  I would go beyond most critics in saying government does not get Agile,  and I would say that the role of government means they should not get Agile.

We live in a Capitalist society of constant change, our culture is reworking itself at amazing speed and with this constant innovation culture we have created great wealth but also great risks.  The financial collapse of 2008 can probably be viewed as an inability of Capitalism to self regulate the risks innovation in Financial institutions created.

So the role of government is precisely to not innovate.  Government is the gate keeper, society needs a stable fixed point in a sea of innovation.  Its the very fact that Government culture is so static, so unwilling to change and so political that gives it so essential value to the larger society.  We live in a world of innovation to the point of self destruction, and when we create chaos we need the rigid institutions of government to maintain stability.

So the deal is this, private sector can provide innovative experience and cost saving to government and it should, but IT service providers need to acknowledge what government is, and politicians in opposition hoping to take power have to understand that radical reforms in the way government work have a almost 100% failure rate.

The more we embrace change the more we need to count on institutions of stability.  Its the very rigid culture of government that makes it valuable to our chaotic economic system.

DocAve for AvePoint is a simpler alternative to RBS

One of the limitations of OTB SharePoint, including 2013, is that everything is stored in SQL Server.  When you are dealing with large files or lots of files this can become expensive to the point of unsupportable.  For example SharePoint won't support files over 2 GB, and yet in our world of audio, photo and video media a 2 GB presentation is not unheard of.

People are often just keeping their really big files like movies, podcasts and computer designs outside of SharePoint.  But DocAve File Share Navigator from AvePoint promises to allow you to expose your file shares in side of SharePoint. This is not only a cheap and dirty alternative to simple RBS requirements, but it can mean that if you have lots of large files you can still have SharePoint as your team and project portal.

Kung Fu Migration to Windows Azure SQL Database

Video above of Scott Klien presentation that I will be seeing in London this evening.