Below is an diagram I have been using for a while in my presentations on software + services (more about s+s here); so due to popular demand 🙂 here is an explanation of it in my blog.
The image is meant to represent the new (or evolving) relationships among the different actors in a S+S world. Of course, reality is more complex and has more nuances, but hopefully it is a good approximation of what is going on.
On the right hand side, you see the S+S ISVs (previously known as SaaS ISVs, but now they have seen the light and have moved to an S+S model :). These ISVs are interested in building S+S solutions (such as this one), sometime to reach a wider market, for example the SMB space, sometime to revamp their product lines with product offering that better match their customers expectations.
These ISVs are increasingly collaborating with hosting companies, since part (if not all) of their solution is now a hosted service. This increased interest from ISVs is leading to an evolution of what hosters must offer to support the need of an S+S ISV. Co-location and dedicated servers are still the norm for now, but you must admit, it is a crude way of serving the ISVs need. An opportunity to offer a higher level platform, some call it a service delivery platform, as we described here and here is very real in many hosters mind. Leverage such platforms is even more real in ISVs mind. High touch managed services companies are also frequent but IMO a lot of what today falls into the "high touch" category could be architected out and automated, allowing even higher level of touch.
In addition to hosting services, there is an increased opportunity to offer “monetization services” such as a marketplace, a product catalogue, a reputation system, as well as more operational elements such as billing on behalf etc. In other words, the goal of the fictitious A Datum Marketplace in this diagram (and many real companies out there) is to connect software services supply with demand. Although today, many emerging software services marketplaces also provide the hosting of these services, it can (and should) be thought as a separate function. Fred has some related writings on this here and here.
Another interesting element in the S+S world is the emergence of “cloud infrastructure”, some call it platform as a service, I would rather call it infrastructure as a service but this will the object of a future post. Some of that cloud infrastructure is very "data center" oriented, as represented by the global foundation services image above. This is what people often refer to as "cloud computing"… very low level, usually commodity priced; it is becoming accepted that only a few players will be successful there. Massive economy of scale is the harsh law governing success in that part of the ecosystem and only a few have the aspiration and more importantly the financial capacity to achieve. There is also another set of "cloud infrastructure" which is a bit more "application level", pictured as building block services above, these services expose things like identity in the cloud, storage in the cloud, but also things like maps and alerts.
Finally, on the left hand side, there are 3 types of customers with quite different expectations: from individual consumers cherishing simplicity, not ready to pay anything for anything, happy about an advertisement model; to very large IT shops that have lots of legacy, regulatory compliance to worry about, often paranoid about their data, pressured by the competition to streamline all non core business, while augmenting agility and competitiveness. And of course the small and medium business market with little IT budget, wanting to tap into the benefit of large IT software 10 or 20 seats at a time.
The goal of architects in this world, is to understand how this interlinked system works or more accurately make it work. But making it work will depend on which actor you are in the system.
Typical concerns for ISVs are around solution architecture e.g. what are the tradeoffs in leveraging building block services, how do I design my solution to be hosting friendly, how do I design my solution to take advantage of multiple monetization schemes.
These concerns are very different from the hoster concerns; the hoster concerns are not only about the *-bilities (scalability, availability…), but also how to offer a service delivery plaform, how to architect the environment to transition from web site hosting to line of business application hosting, how to streamline operational processes to offer services to the long tail of service providers… dilemmas around buying servers vs. retailing "cloud computing" purchased wholesale… and of course the holy grail of hosting, maximize density.
The enterprises are often not interested in how to build or how to run, many are mostly interested in how to consume all this goodness available in the cloud. But consumption is not as simple as that, the concerns are around how to consume this goodness while keeping the high standards in terms of security, making sure that control of the most important data is kept, as well as compliance to Sarbanes Oxley, integrating cloud services with internal systems… A few of these concerns are explained here. And some enterprise are looking at bringing a lot of the cloud compute thinking in house i.e intranet-s+s.
Platform vendors will have to understand how to reach tremendous scale without blowing costs, abstract complex infrastructure into friendly programming models and of course fine tune what platform services are better offered as cloud services and which one are better offered as ‘on premise’ servers.
We have just scratched the surface here, but as one can easily see, with all "new worlds" come tremendous opportunities both in terms of slashing cost and in terms of top line revenue growth; these opportunities comes at a high price in terms of new scenarios to solve and new architectures to master. It looks like we (architects) have secure our jobs for another 10 years 🙂