Relevant search results and links for car play mat…

Say you’re building chips for use in cell phones. The size of your direct market are companies that make these phones, you can count them on one hand. But your community is made of your employees, your customers’ employees, your suppliers, your outsourcing partners, your consultants, etc.

If you can make them more productive, get new products out faster, cut down development cycle, find cheaper sources, predict market trends, you’re ahead of the game.

The traditional approach to integration (EAI, portals, application servers) came out of client-server but ended up being the new mainframe. It takes too long to get anything done.

We need to bring back the PC running Lotus 1-2-3. That way users at the edge can self-help themselves to something better. Maybe you’re creating a mashup that only two people use, and it’s a horrible hack done in a day, but it could end up saving millions in sourcing materials at lower cost.

It’s the 80/20 rule, think Excel instead of nine fives. Sometimes you absolutely need all these features, cost aside. But most of the time, you want something lighter with less barriers to entry.

There’s clearly a place for provisioning and redundancy and end-to-end management. But there’s also a place for rapidly building new things. If you can rapidly build it, you can rapidly change it. And if you can rapidly change it, you can rapidly improve on it.

Sometimes you improve because something broke, most often because something better comes along. Instead of optimizing for “what if it breaks?” you’re optimizing for “what if I want to change it?”

It is. I just would like a catchier name for it…

Let’s say you need five nine uptime and have a five year roadmap for your application. Choosing replication assumes redundancy, and while you get redundancy with stock quotes and weather reports, you don’t get that with eBay listings or Amazon reviews. Those are single source. If they go out of business, change their API or simply decide to block you, your application goes down. You need some sort of agreement.

Let’s say you want a badge on your corporate Web site, and you found the right one. But it bothers you when it disappears because their ISP is down. Should you cache?

Now, what would happen if they decided to change their color scheme to flaming red and put ads for p*rn sites? You might want to get the data instead, store it locally, and then render it yourself.

Isn’t that service integration?

I agree with the analysis, and the term mashup might not be appropriate for what I am describing. Composite application might be better suited, even though it usually relates to something else. I need a term for production-ready mashups. Any idea?

But that’s exacly what makes them better, cheaper and faster. Most applications are just not that time critical, people are very adept at routing around failure, and things that are simple to build are also simple to fix.

So instead of dealing with plumbing, you just deal with end-user needs. And they keep the cost low, most of the good ones are weekend hacks.

Trying to fix mashups would end up breaking them.