Here's a really neat presentation from Mike Kuniavsky on how with 486 level computing power becoming dirt cheap, we will see more and more computing and networking functionality embedded in physical objects.
The metaphor of the 'enchanted object' brings to light what Mike sees as the most appropriate targets for this treatment. I love this term and think its far more appropriate and evocative than the term 'augmented objects'.
Highly recommended.
http://www.orangecone.com/tm_etech_magic_0.3.pdf
Tuesday, April 3, 2007
Thursday, March 15, 2007
The Downside of SaaS
Software as a Service is a high profile new way to consume IT.
Consuming software as a utility just as you consume electricity or water is very appealing. The analogy suggests continuous availability and ease of consumption on demand.
The utility analogy also betrays one of the most key limitations to Software as a Service. Electricity supply suffers from blackouts. Water supply suffers from pipe failure. In both cases, you have little control of when and how your service will be resumed.
Software as a Service can also suffer from outages. When it happens you have no alternative but to wait.
On the other hand, economies of scale suggest that Software as a Service vendors can build a more resilient data center and software offering than most individual companies could afford.
What's more important to you?
A high likelihood of stability, or a high level of control?
Prompted by this article about a Salesforce.com outage in their system for partners: http://www.aspnews.com/news/weekly/article.php/3665531
Consuming software as a utility just as you consume electricity or water is very appealing. The analogy suggests continuous availability and ease of consumption on demand.
The utility analogy also betrays one of the most key limitations to Software as a Service. Electricity supply suffers from blackouts. Water supply suffers from pipe failure. In both cases, you have little control of when and how your service will be resumed.
Software as a Service can also suffer from outages. When it happens you have no alternative but to wait.
On the other hand, economies of scale suggest that Software as a Service vendors can build a more resilient data center and software offering than most individual companies could afford.
What's more important to you?
A high likelihood of stability, or a high level of control?
Prompted by this article about a Salesforce.com outage in their system for partners: http://www.aspnews.com/news/weekly/article.php/3665531
Wednesday, March 14, 2007
Friday, February 16, 2007
The future of mash ups - the web as database
Yahoo Pipes is getting a fair bit of interest at the moment as a way graphical way to link up and work with web content and feeds. In a sense it could represent democratization of the mashup phenomenon, from type A programmers to all the rest of us.
I liked this take on it, http://www.readwriteweb.com/archives/yahoo_pipes_web_database.php comparing the emergence of yahoo pipes with the emergence of PC based relational databases. There's also a heck of a lot of other commentary out there and it'll be interesting to see how much it takes off.
I liked this take on it, http://www.readwriteweb.com/archives/yahoo_pipes_web_database.php comparing the emergence of yahoo pipes with the emergence of PC based relational databases. There's also a heck of a lot of other commentary out there and it'll be interesting to see how much it takes off.
Tuesday, February 6, 2007
Wikis wikis wikis
I've just come across an experiment by penguinbooks to write a novel with contributions from anyone who visits at amillionpenguins.com. (From this article.)
A wiki is a web site where any visitor can view and edit any page, can create pages, and can roll back changes from other users. This approach has had a surprisingly amount of success over the last few years. Probably the most celebrated wiki is wikipedia (wikipedia.org).
It will be interesting to see if the million penguin wiki succeeds at all. While the high level structure of a novel as a whole is well understood, I'd expect a lot of difficulty converging on a common thread for the story. Particularly when the level of antagonistic contributors is likely to be high.
My first Citrix wiki was for brainstorming on a high-tech business proposal with a senior cross-functional team. While there was a good amount of interest, it was surprisingly difficult to get complete engagement.
Why? Well not everyone fully understood what a wiki was (this was a few years ago). There was also a surprising amount of Resistance to using a mark up language and to changing other peoples text. Mostly though, I made the mistake of expecting that the technology would drive an emerging structure. (The romantic notion of 'wiki nature').
Wikis rely upon having a well understood overall structure, so the wikipedia encyclopedia approach works well as everyone has a good idea of what an encyclopedia should look like (stand-alone articles with cross references).
From a business perspective, the wiki is an important tool for content management and collaboration. However, the technology is not magic and should be treated as a tool. Here's my short list of minimum requirements for success:
A wiki is a web site where any visitor can view and edit any page, can create pages, and can roll back changes from other users. This approach has had a surprisingly amount of success over the last few years. Probably the most celebrated wiki is wikipedia (wikipedia.org).
It will be interesting to see if the million penguin wiki succeeds at all. While the high level structure of a novel as a whole is well understood, I'd expect a lot of difficulty converging on a common thread for the story. Particularly when the level of antagonistic contributors is likely to be high.
My first Citrix wiki was for brainstorming on a high-tech business proposal with a senior cross-functional team. While there was a good amount of interest, it was surprisingly difficult to get complete engagement.
Why? Well not everyone fully understood what a wiki was (this was a few years ago). There was also a surprising amount of Resistance to using a mark up language and to changing other peoples text. Mostly though, I made the mistake of expecting that the technology would drive an emerging structure. (The romantic notion of 'wiki nature').
Wikis rely upon having a well understood overall structure, so the wikipedia encyclopedia approach works well as everyone has a good idea of what an encyclopedia should look like (stand-alone articles with cross references).
From a business perspective, the wiki is an important tool for content management and collaboration. However, the technology is not magic and should be treated as a tool. Here's my short list of minimum requirements for success:
- Tied to a corporate or business unit goal
- A commonly agreed structure
- A commonly agreed purpose
- Ownership by one or more team members
- Well constrained topic
Monday, February 5, 2007
Soft bodied robots
Here's a great multi-disciplinary approach to robotics.
Most of today's robots are built from an assembly of stiff materials in contrast to most living systems that leverage primarily soft, elastic materials in combination with stiff materials such as bone. This article talks about a Tufts University initiative that starts with building robots that from materials that mimic biological material. It's a really interesting first step toward their ultimate goal "...to develop systems and devices -- soft-bodied robots-- based on biological materials and on the adaptive mechanisms found in living cells, tissues and whole organisms".
http://www.sciencedaily.com/releases/2007/01/070128105355.htm
Subscribe to:
Posts (Atom)
