I agree that a balance needs to be struck with SaaS solutions - they do not require the app lifecycle overhead of traditional solutions. I think the answer is to identify the aspects of the lifecycle where the overhead is less and adapt. You do not need big upfront designs generally with SaaS when you can configure and demo in the time it would take to produce all that, then retrospectively document what is built. The platforms are more stable, consisting of more abstracted and stable building blocks so less testing effort needed etc. I could go on and on but I feel the solution is to identify these areas and adapt. I think the CloudSpokes idea is novel, but largely impractical.
Basically the article says it. For a self contained, well specified task then CloudSpokes is fine. But usually components have inter-dependencies, not all of which are obvious before you start building, so lack of communication may provide issues. And if the requirement changes then it would be difficult to renegotiate with the person who has picked up the 'well defined task', they are surely only liable to produce what is documents. This concept is much like 'Mechanical Turk' that Amazon provide - a task is put out there to the market and anyone can pick it up. If you look at the kind of tasks there, then we could probably make a judgment about the kind of tasks would appear in the context of CloudSpokes albeit they will be in a technology context. So just picking 2 examples from Mechanical Turk:
-Write 100 line description of Bingo
or
-In this task, we'll give you an object name, like "Palm Tree" or "Banana". We want you to put a box around the objects.
Self contained, certainly. Limited use, certainly. I think CloudSpokes will be similar, but I am all for new approaches.
http://cloudsovercricklewood.blogspot.com/
The further that SaaS vendors penetrate into the higher echelons of enterprise computing, the more they’re accused, like the pigs running the show at the end of George Orwell’s Animal Farm, of becoming just like the establishment vendors they claim so much to despise. Complex implementation projects, multi-year contracts with payment upfront, deal sizes that run to six- or seven-figure sums, alliances with the established global SIs, and account management teams recruited from the ranks of old-guard vendors such as Oracle, IBM and HP. Meet the new boss, same as the old boss.
It all starts to look as though SaaS isn’t the disruptive force its proponents claim it is. Perhaps the established conventional software vendors are right after all when they say that the only reason SaaS seems better, faster, cheaper is because it lacks the sophistication to satisfy top-class enterprise needs. If it ever evolves sufficiently to match those needs, the end result will look no different from the incumbents, they argue.
The counterpoint is to observe that, if you take a disruptive innovation and smother it in products and practices better suited to its establishment rivals, then it’s bound to get bogged down. What is the point of inventing a completely new approach to application development and deployment, only to saddle it with outdated implementation practices, brittle integration technologies and bureaucratic lifecycle management? SaaS vendors should be more wary. All the energy and potential of SaaS is getting squeezed out and drained away by the old deployment and management models. To reverse the familiar phrase, if you wear the pig’s lipstick, don’t be surprised if you end up looking like a pig.
In the past decade, SaaS has evolved enormously in terms of the application platforms themselves, but progress has barely started when it comes to applying cloud models to the implementation and lifecycle management processes. If cloud services are going to avoid the fate I’ve outlined above, then there needs to be a disruptive change in those areas, just as much as in the platforms themselves. This revolution won’t be complete until the current business models of the global SIs — Accenture, Deloitte, IBM and the others — are as comprehensively undermined as those of the software vendors they’ve traditionally worked with.
Last week saw the launch of an initiative that perhaps models the shape of this impending disruptive change. Cloud integrator Appirio [disclosure: a recent client] announced CloudSpokes, which aims to bring a crowdsourced, community approach to enterprise cloud development tasks. The idea is very similar to what 99Designs does for web design projects: organizations post specifications for tasks they want done and a price they’re willing to pay, and any community member is free to do the work in the hope of being selected as the contest winner and walking off with the money.
The idea is to prime the pump for this loosely coupled model of cloud development as a counterbalance to the current dominance of traditional, high-overhead methodologies espoused by the global SIs. To that end, Appirio is committing an initial $1 million-worth of contest tasks to start building community momentum. It’s also a necessary investment to fine-tune the model until it works, as Appirio’s co-founder and CMO Narinder Singh explained to me last week:
“We have to create liquidity in the market. We’re teaching our people how to break down problems into components. We need to understand as an organization how to use this resource.”
Software development is not like web design, with clear-cut, established demarcations between different types of task. To have any success with CloudSpokes, and forge a truly loosely coupled development cloud, people are going to have to learn how to break down their projects into discrete tasks that the community will be able to make sense of. That may be a big ask.
“As companies build on the cloud in the right way, this process should become natural,” said Dave Messinger, chief architect and evangelist for CloudSpokes at Appirio, who previously architected TopCoder, a similar community that targets traditional development platforms. He explained that the best type of task to submit to CloudSpokes would be, “Things that you can specify well. You know what the inputs and the output are but you don’t know the algorithms, the best way to code it. A well scoped, well defined piece of work like that works really well.”
There are so many reasons why I want this to work: to speed the progress of cloud applications; to share best practice and high-quality output; to help strong, instinctive cloud developers win visibility and better leverage for their talents; to give the bloated, inefficient global SIs their comeuppance.
“With CloudSpokes as a community,” Narinder told me, “the idea [is] creating a marketplace and showing the contrast with what you can achieve with the cloud. We’ll benefit because other people won’t be as willing to cannibilize their traditional business as we are.”
Celebrating the match of cloud meet crowd in a blog post, he added:
“CloudSpokes will create transparency for the market around cloud platforms and cloud development. Market pricing and past results will show what it really costs to do something in the cloud, by platform, type of problem, sophistication and more.”
This all sounds really good, but like Dennis Howlett, who is just as intrigued, I have to wonder whether it will work. Ever since the dawn of computing, there’s always been this nagging itch to scratch, this feeling that most of the code a developer is building for any given project has already been built somewhere else, if only it could be reused. This sense of waste has inspired successive advances: indirection, subroutines, object orientation, separation of concerns, request brokers, service oriented architecture, virtualization, platform-as-a-service. It’s impossible to resist the allure of every new idea that promises a way of sourcing the best possible code without having to reinvent the wheel every flipping time.
Could CloudSpokes, or something like it, win widespread acclaim as the next solution to this age-old problem? I’d like to think so, I really would.
