Design and Develop Versatilities not Applications
If you have had the pleasure of working in the SharePoint Universe for a while, then hopefully you have had a chance to see lots and lots of examples of the incredible applications that end-users assemble in SharePoint all by themselves - without the help of developers or infrastructure or even business analysts. In my 5 years of Architecting and Developing SharePoint Portals and apps, I have had tours of some truly fantastic applications that individual business units - with enthusiastic business leadership - have assembled from SharePoint and Office System parts completely without the help of IT - and sometimes with the opposition of IT.
The first one that blew my mind was way back in 2004 at one of the major research hospitals in Boston where only a few weeks after I installed SPS03 for them - the nurse certification and training team had completely automated their business process within their SharePoint team site: class scheduling and calendaring, class syllabi, class sign-up, class workstation assignments, teacher registration, teacher bios, post class surveys, student grading and feedback, future class discussion lists, etc. etc. All completely created by the manager of this business unit and his team without any prior experience with SharePoint.
Since then I have been given tours of many many other fabulous - completely user assembled WSS/MOSS applications. Only last week I was shown around an Insurance Underwriting and Risk Assessment site that just rocked my world. The actuaries, engineers and underwriters had again completely automated their business process with lists and libraries and discussions of all kinds of oil drilling equipment, oil refineries, oil tankers, geographical variations, engineering experts by region, with ratings and location info, and analytical spread sheets tying all the data together. I can't go into any detail, but again the site was deep and rich and completely put together by the end-users - and it is in constant use for writing multi-million dollar insurance policies.
The fact is - end users know what they need, and with the right set of end-user tools that have the right set of capabilities - they can assemble, evolve and manage exactly the application that can keep their business riding the leading edge of the productivity curve. These kinds of applications blow the doors off of Agile or any other kind of "purpose built" development because they take developers and IT completely out of the presentation and productivity layers. No matter how fast or Agile a development effort is, it can never come close to keeping up with end-users directly satisfying their own needs through a Productivity Framework like SharePoint and the Office System.
So these fantastic and fabulously productive user assembled SharePoint applications - what should we call them? Well for starters, these are Composite Applications. And there are lots and lots of discussions out there in the software architecture world covering the great and wondrous future of Composite Applications. In the Microsoft/Office world the discussion revolves around Office Business Applications (OBAs) in which SharePoint plays a key part - but what I are talking about here is a specific species of Composite Application and/or OBA which I refer to as the End-User Composed Composite Application or EUCCA. And in my opinion, EUCCAs are the big time game changer!
OK, so we have all these highly productive EUCCAs being composed and evolved by business users on the SharePoint platform, so what's the beef?
The beef is that 96.4% (informal poll) of all applications developed to run in the context of SharePoint are not EUCCAs. They are Purpose Built applications that take advantage of lots and lots of parts of SharePoint: authentication, authorization, role based security, security trimmed navigation, search, etc. ; but they don't take advantage of the tremendous productivity potential of the End-User Compose-able application. They take a long time to deliver, and they can't be changed and adapted by the end users as the end-users requirements change.
And the reason that software architects and developers don't build more EUCCAs on SharePoint - in my opinion - is that we have the wrong mind set - the whole software development lifecycle has been drilled into us for years - we collect the business requirements, and then we design and develop a solution to deliver exactly those requirements. But the job of designing and building EUCCAs requires a significantly different mindset, because with a EUCCA you don't deliver a solution that exactly delivers on the requirements, instead you deliver these things - configurable parts and pieces - that the users can use to compose and evolve their own solution as their requirements shift and change.
The difference is like the difference between designing a train and designing a car. A train is totally controlled by the tracks. The users of a train are passive and the train's schedule with it's unchangeable set of stops dictate their possibilities. The course of the train does not change even if the plans of the individual user's change. This is a purpose built application.
The control of an automobile, on the other hand, is completely under the control of the end users themselves. They can go where they want when they want, they can loop back, they can change course mid-way. Their path evolves as their requirements change. In this way, building the presentation and productivity layers of a EUCCA requires a mindset like that of an automobile designer - it's all about handing the control of the Presentation and Productivity layers over to the end-users.
So what are these parts and pieces that end-users use when they are composing a solution? SharePoint has been called a "Capabilities Framework" - so are these things simply "Capabilities"? Yes, but you can deliver capabilities that aren't user compose-able. What we're talking about here are specifically user compose-able capabilities. Each one has it's own brake, accelerator, steering wheel and signals. Which brings me around to the title of this post. I am suggesting we adopt a noun form of the word Versatile - and we call these things Versatilities.
SharePoint Software Architects and developers need to focus on designing and developing Versatilities - small pieces of end-user configurable functionality that are versatile in exactly same way that the OOTB SharePoint functionality (lists, content types, views…) is versatile. We need to think totally in terms of extending the SharePoint Presentation and Productivity layers rather than simply building another Purpose Built application that sits on top of SharePoint.
Think "Versatilities". It will get you in the right mind set to build some fantastically productive EUCCAs!
An example to come.
