Two important building blocks in creating a digital platform
Why putting users in control is at the heart of Skylark CMS
Recently, I wrote on these pages about ways of responding to a digital media market that is constantly going through change. That a shifting market poses a challenge in re-architecting an existing platform, as well as building an entirely new platform.
In discussions I had at the NAB Show not long after that post, there was a theme related to this that kept coming up and which I’ve recently been thinking about in relation to Skylark — and that is control. There are two parts to this that stand out for me: cost and technical supervision.
Cost: knowing what to expect
At Ostmodern, we have worked with a large range of clients for more than a decade. Each has been consistently driven by the need to achieve predictable costs.
In the fragmented digital ecosystem that exists today, running multiple platforms can lead to increased expenditure and accumulate risks over the lifetime of every piece of software. These greater risks and expenditure are what everyone wants to avoid.
In developing Skylark, we recognised that a core product principle had to be to respond to the demand for controlled and predictable costs. Among our objectives for Skylark has been to conceive a repeatable model with well-defined financial implications for deployment and configuration.
This model would actively avoid creating hidden costs. We would continually monitor and measure our success with this objective.
We’ve achieved this in part through being honest about what our own costs are. In Skylark, we built a product business while running a professional services company — all without taking any outside investment.
This has meant we already have a considerable understanding of many of the concerns and motivations our clients have, as well as the financial challenges they face.
Also, it has placed us in a position where we can make the case for, and justify, costs. We can critically assess ourselves to know when these arguments do not stack up. Any instance where a client could incur a cost we need to be able to say confidently that there isn’t another option or better way — that a capital investment is needed for what they want to achieve.
Regardless of any of this we’ve had to be confident that the productised approach we’ve developed is a genuine value-add, and that the client cannot find another way to compete with it over the long term.
Through this process, we’ve also recognised risks in the sales process, including common areas of debate on cost, and minimised these by investing in it ourselves. Not only does this avoid distractions in a new relationship, but it leads to a client getting better value, and feeling it soften their bottom line.
All of this has been essential to building relationships with our clients that are founded on trust. We’ve earned that trust by being honest about where we can — and can’t — predict costs.
Technical supervision: understanding your product
The most frustrating part of being a software developer can be not having control of the product you are responsible for delivering. Just as we are concerned with how a product owner perceives the impact of a CMS on their product, we also empathise with CTOs who want authority over their systems.
Being able to control and delve through systems that you have invested in shouldn’t be too much to ask for. We’re aware that developers often crave a balance between the visionary and the routine when it comes to tasks so it’s important to account for both.
With this in mind, we built a highly extensible object-based system whose features eclipse those available in most bespoke systems.
We carry with us enough proof of this accomplishment, making the most out of the same fundamental framework through being able to enable complex sports and media products that have unconventional — and so require bespoke — data structures, and content which changes depending on the location or region.
The API we built was a consequence of this reasoning. It has been developed to allow services to be integrated with Skylark, using its fully-documented API to achieve what the developer wants, at their own predictable cost. Developers are given the power to redefine what Skylark is ‘for’ through the breadth of possibilities our API creates.
Our read/write API is often commended precisely because it gives companies the control and supervision they need, while allowing them to take full advantage of the extensive power of Skylark and its broad range of capabilities.
There is a common myth that every development team just wants some software they can control and ‘hack’ to their heart’s content. Anyone who has managed developers will know that often developers and similar disciplines work well with clearly defined constraints where they can see the endgame of their work.
Freedom to innovate
We built a system that respected this need to have some structure and some predictability from the software which developers use, whilst allowing them to dream up wildly unique services to plug into it, with little restriction.
Skylark was born out of trying to meet the needs of our own teams. They wanted a tool that would allow them to flex their own product design and development muscles, without feeling restricted by the tools provided to them.
We are excited at having created a platform that delivers flexibility together with the means for companies and developers to control their costs, and their software.
Thank you for reading!
If you like this article, give us 50 claps. If you really like it, let us know why. Leave us a comment with any question or opinion you might have on the subject.
You can reach us on Twitter @Ostmodern to continue this and other discussions.
Follow our publication for more stories on tech, design, video and other interesting topics.
