In the first article in this series, I’ve introduced skybow and our mission. In the second and third article, I was writing about data modelling and processing, UI and reporting. In this article, I will focus on the technology underneath.
1 – What is skybow?
2 – skybow solution accelerators: data modeling and processing
3 – skybow solution accelerators: UI and reporting
4 – skybow solution accelerators: what is under the hood?
5 – skybow: the next generation of products, and my role in it
How is it done
I already hear the question: OK, this is all cool, but how can we actually use it? There is something called skybow solution studio. For us, a solution is that “leave request” scenario. Solution Studio is a web application, running in browser, triggered from the site actions menu. There you create the data models (“Case files”), define values, calculations and aggregations on fields, create actions, build expressions and define user interface. Best of all, you never leave SharePoint.
As I mentioned, all the customizations are stored in the appropriate schema.xml files, nothing leaves SharePoint, so even if you uninstall skybow solution accelerators, you never loose any of your data. This XML-based approach gives us opportunity to record all customizations in “changesets”, so you can always revert a complete changeset or even pick and revert single changes from the change sets. This also removes the need for a classical deployment – all we do is transferring XML files, either through skybow solution studio UI, or through PowerShell scripts. If a requirement for request for leave is changed on some way, you just need to change an expression in skybow solution studio on the developer machine, and to bring it to customer’s environment, instead retracting and redeploying solution (what is always connected with night or weekend work hours, and expected downtimes).
It is possible to export and import all the customizations to the XML files. On that way, those customizations can be transported through development-test-staging-production environments. If someone prefers including skybow customization in automated release management, that is also possible to achieve – all customizations can be exported and imported through PowerShell scripts.
I hope you got the idea until now. If you think of that „leave request“ scenario, with two-step management approval, a decent UI and a management reporting, then we are talking about 3-4 event receivers, one or possibly two timer jobs, few complex web parts to get a decent user interface, and a lot of custom development to cope with management reporting. We speak of 2-3 man/weeks for a skilled developer, plus the whole testing/deployment cycle. With skybow solution accelerators, we are speaking about hours. Event Handlers, Timer Jobs and UI are already there, they just need to be put to work together inside that solution.
And this is the major benefit of skybow solution accelerators: development, deployment and change response times are decreased by 85% percent in most of the cases. If you think on the ALM cycle, those are the areas where benefits are largest and costs saving are enormous. Some savings can be made also during the architecture phase (you don’t have to plan every single event handler and timer job), and operations phase (there is much less things to maintain), but major savings are in the three before mentioned disciplines.