New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Sadek Drobi on Jul 20, 2008
What is the optimal business model for today's web? Opinions diverge in a series of articles around this issue. Some weeks ago, Stan Schroeder's argued that adding extra features to an application is rather a risk than an opportunity. Offering every possible tool for a specific need has been a key to success, but it becomes less true in a fluid, ever-changing environment offered by the Internet "where everything shrinks and expands and overlaps all the time". It is indeed a rather shaky ground to build something complex especially if it then needs to adapt to the change:
Sure, if the conditions around you don't change much, you can satisfy the needs of a certain group very well [...]
Once upon a time, if you wanted to create a successful application, one of the keys to success was to 'offer a lot of features your competitors don't have. Adobe's Photoshop is one such application. If you need to edit some photos, it's the best, period, because it has every tool you could possibly need.
But this is the disconnected world we're talking about. On the web, things change. It's not only important what you can do; you also want to be able to do it from wherever you want; you want to plug in into other services, you want to work together with other people
What users want today are "simple, widgety applications that cater to a specific service". Schroeder believes, however, that rather than creating a lot of specific small applications it would be preferable "to build a very simple service that caters to a very basic need, and slap an API on top":
I think [a] better [approach] is to find the lowest common denominator, an underlying basic need that connects all these various niches, cater to that, open it up and let mashups do the rest. This way, people can choose exactly which features they want to use, and your application becomes a fluid, modular service that can be as simple or as complex as the use wants it to be.
According to Schroeder, such services would "unlock the web" and as long as the need they cater for is shared by a significant number of people "it will be impossible to compete against them."
Fred Wilson applies this reasoning to the groups market. He builds his reflection on Charlie O'Donnel's post about groups but slightly disagrees with his conclusions. O'Donnel believes that there will never be "One Ring to Rule Them All" in web services for groups because "every group is different, so the idea of one particular group software solving everyone's problem is never going to work". However, he highlights three properties that, in his opinion, are needed by every group:
- A customizable site to call their own, even if it just has information as to what the group does and how to sign up
- A way to communicate internally, via a one-way or two-way listserv, depending on the group
- A way to do RSVPs for events
This is what leads Fred Wilson to suggest that this can be considered Schroeder's lowest common denominator applied to groups. While he somehow agrees with O'Donnel, asserting that "building yet another groups service is not the answer", he suggest, nevertheless, that building the killer API offering the tree mentioned services and allowing everyone building on top of that could be an interesting business model for groups market.
Considering insights provided by different authors, Bob Warfield suggests a more careful approach to the 'less is more' paradigm that, in his opinion, doesn't often win.
We need to be really careful not to mistake the apparent simplicity of less for real simplicity that can lead to a paradigm shift.
[...]
One of my favorite UI design quotes is Alan Kay's, "Simple things should be simple and hard things should be possible.'"[...] Being the first on the block to raise the level of what is simple to do in your software is a tremendous advantage. It means you can deliver more to people who can only deal with less.
Warfield believes that this is precisely what matter in Web 2.0 context. Social networks, blogs, groups are "successive iterations on how an individual or a group can have a web site that is tailored for what they want to get out of it very very simply". Their success, according to him, is related to their ability to "make various previously difficult things simple, and in some cases, [...] hard things possible". He, therefore, suggests that this is the key for a successful business model for today's web. This requires a rigorous approach to the user interface design that should allow keeping "the simple at the forefront and to avoid confusing with the hard while still retaining the ability to do the hard" so that "it looks so simple until you're done doing what used to be hard and suddenly realize you're now ahead."
Hence, the authors seem to share the conviction that simplicity is the key in today's web. Yet, simplicity can be understood in many different ways. Which of them, in your opinion, responds most to users' needs and should be the foundation for new business models attempting to win the web market?
Nothing beats the simple aspect of business. Regardless if this is done online or not, business in the most basic manner that a person can think of is the best way to get it through.
Perhaps one thing that runs in people’s mind is that being sophisticated is to impress. It does not always follow. Remember that the key point in doing business is making it easily understandable. This is something that most aspirants have forgotten. While technology offers a lot of innovations to be able to impress people, unless they understand the gist of what you are getting at, it will all be futile.
It never hurts to impress people with what you know. Just don’t overdo it. Stick to the basics so that they can understand you and in the end you may find it the optimal solution to doing business on the web.
Much of the above is a discussion of the technical construction of a business. Where's the consideration of how one charges for these services?
Subscriptions? Hourly rate? Per API call? Something else?
Ditto what Dan said - the term "Business Model" usually describes how a business makes a profit. An article relating web architecture concerns with how real businesses currently make (or plan to make) a profit from their web applications would very interesting IMHO.
I agree that Revenue sharing and margins and Value chain structure are two very important components of a business model. However, there are four other key components where this post fits in. www.quickmba.com/entre/business-model
Anyway, I'll try to hunt for these two other aspects for a following post maybe :)
Thanks for your comment.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
4 comments
Watch Thread Reply