Requirements and Versatilities
Reusable components. A lot of work and effort and thought has been put into reusable components...
OK, so let's talk about a specific type of reusable components... let's talk furniture design and Versatilities.
There is a certain Scandinavian furniture company, not sure if I am allowed to say their name, but they are incredibly successful at selling really nice, practical, well designed inexpensive stuff.. But their designs are significantly different from traditional furniture designs because their business model requires them to meet some very stringent non-functional requirements.
First off, a piece of their furniture has to fit in a box that weighs as little as possible, and be transportable home by the customer themselves. So Movability is a huge non-functional requirement. Second their designs have to be easily assembled with only simple graphic instructions, and a few included tools. So Assemblability is another very important non-functional requirement. Third, their designs are designed to look and work great together across completely different types of furniture and housewares and accoutrements. All of their stuff has to be nicely composable into different attractive interior designs and styles. So Composability is also a hugely important non-functional requirement.
- Movability
- Assemblability
- Composability
These are the uber-requirements. These are requirements that have to be satisfied no matter what the end user's requirements. If what the end user's want can't be designed to be Movable, Assemblable, and Composable - forget it. This company isn't going to deliver it. The end user (customer) will have to go elsewhere.
SharePoint Versatilities are versatile components that have these same three non-functional uber-requirements: Movability, Assemblability, and Composability. Therefore you have to design from the get-go for Movability, Assemblability and Composability - otherwise you're not designing Versatilities.
OK, so you have a bunch of business users, and they want an application that does x, y and z. So what are you going to do? If you design them an application that does x, y and z, and exactly x, y and z, then you have a purpose built application. If you get the requirements for a reclining chair, and you then build a one-off reclining chair right in their own living room, as one solid monolithic reclining chair - then what you have is perhaps a great reclining chair, but it only works now, for that particular user with their current decor. If they want to "recompose" their living room into a different design, then they'll have to bring the furniture craftsmen back in and rebuild. Sound familiar?
If you want Versatility - if you want applications that the end user's can move around, assemble and reassemble, and compose and recompose, then you have to take their requirements, and do a whole different level of analysis on them. You have to look beyond the x, y and z, and treat x, y and z as a sub-set of a larger set of possibilities - and you have to explore how Versatilities can be designed to deliver that mix. In other words, like our Scandinavian design heros, you have to be really smart about the design.
So now let's say you've been super smart - and you've come up with a slick set of Versatilities that can do x, y and z and so much more - well now you have a more difficult problem. Now you have to convince your stakeholders that your set of Versatilities is a superior solution to their x, y and z requirements. SharePoint users in general have totally realized the value of Versatilities. They love lists and columns and views and content types and web parts, and everyday they realize tremendous value out of moving them around, reassembling and recomposing them into new solutions. But first off, most SharePoint users didn't arrive at their SharePoint site with a clear set of requirements. They arrived at their SharePoint site thinking - here's a whole set of tools, what can I do with them? And second off, what if your stakeholders aren't SharePoint users at all? Quite often you're dealing with CXOs that only have a vague conceptual understanding of what is going on in SharePoint - and they're used to the waterfall lifecycle - they expect you to gather requirements, and then deliver an application that exactly satisfies those requirements.
How do you convince your fickle and persnickity bunch of stakeholders that they should care about Movability and Assemblability and Composability - how do you convince them that their interests are best served by your set of brilliant Versatilities?
Convincing stakeholders to care about non-functional requirements is always hard. You have to plan, you have to prepare, you have to lay the ground, you have to do great drawings and presentations, you have to work at hitting the right notes from the very first conversation. You have to get them to understand that Versatilities will give them the agility and speed to continuously execute on their business objectives.
But you can't sugar coat the downside because it will bite you back. Applications composed using a set of Versatilities always require a little more work on the end-user's part - they require more clicks than a purpose built application. Just like the Scandinavian furniture, they have to be assembled, and they come with directions that the end-user's have to follow... So yes, their users will have to do more work and learn a few things, but in return they will be able to compose the application in their own SharePoint site in a matter of hours - and then be able to change it themselves whenever it requires changing.
Of course you have to show examples. Most stakeholders don't know what they want until they see it. So show them as many similar end user composed SharePoint applications as you can - and if you have a running version, show the stakeholders how the end user's themselves can change and evolve the application as their business changes and evolves - without the need to call in the developers for another 6 months of rebuilding in order to add an account code, or to deliver the same application to a new office in Timbuktu.
I'll walk through some real examples next time...
