OT: Mashups - you've got to be kidding!

[Bob Johnson]

I know this isn't .NET-specific (thus the "OT:" in the subject line) - but
it's relevant to what we do as modern distributed system developers:

So I'm hearing a lot of buzz about "mashups," "cloud based systems,"
"composite applications" etc...

From what I have read, these are apparently systems made up of many other
[perhaps smaller] systems. It's like the architects promoting these ideas
have taken component-oriented programming and cast the "components" as being
entire other systems. Now we're using entire applications as building blocks
for other entire applications.

The big benefit - as the promoters say - is that users - yes USERS of all
people - will be able to dynamically create entire new applications, or at
least dynamically add entirely new functionality to existing applications.
There is a long list of pitfalls and "gotchas" and ownership issues I could
add here, but I suspect most of you can easily see many on your own.

So, finally, my question:

Are any of you taking this mashup/cloud-based/composite application
architecture thing seriously?

It just seems *totally* out of touch with reality.

Please note: this isn't intended as any sort of rant, and I'm not any sort
of Luddite. I'm just wondering if I'm missing something, or if the king
really isn't wearing any clothes.

Thanks for your thoughtful insights.

 

[Oliver Sturm]

Hello Bob,

Are any of you taking this mashup/cloud-based/composite application
architecture thing seriously?

It seems to me that BizTalk, as an example, delivers a lot of what you
describe. And the whole idea of SOA is also not that far out... if I hook
up data from a Web Service into Excel, isn't that me (an end user)
creating a mashup from two separate systems to create a composite
application?


Oliver Sturm

 

[Bob Johnson]

Thanks for jumping in Oliver...
RE:
<< isn't that me (an end user) creating a mashup >>

Not as I understand mashup, "cloud-based" application, "composite"
application and the like.

What you've done by hooking into a Web service, or even hooking up a bunch
of services to an existing application, is you've *extended* the
application. You have not created [a whole new application built entirely
(or almost entirely) from other applications]. At least that's the grandiose
image of the mashup, cloud-based, architectures that I've been reading
about.

And working definition of "end user" I've seen from these architects is
business users (not programmers) doing all the work ("... you don't even
need a programmer to get involved... saving lots of money and time...
empowering the user community, and leading ultimately to world peace.").

BTW: the whole SOA thing is already an understood and successful
architectural model AFAIKT. No quibbling with that here.... nor with Web
services and extending apps across the Web.

-Bob

 

[Oliver Sturm]

Hello Bob,

Not as I understand mashup, "cloud-based" application, "composite"
application and the like.

I see what you're getting at. I'm not having such a hard time though (not
as hard as the one you're apparently having <g>) imagining that the same
basic approach can be carried further, allowing me to create a puzzle
consisting of application modules.

In the end it's not a technical issue, it's one of standardization. I can
create an architecture that would allow end users to create their own
applications. The problem is, there are only so many hours in my day and
so much domain specific knowledge in my head, so others would have to work
together with me to create a meaningful all-purpose platform.

The incentive to do something like this would be the idea of not having to
pay a developer, sooner or later. As long as the developer is still in the
picture, there's no reason to carry things just that far - we all know how
hard the last mile can be. And if the developer is not part of the final
target scenario, one has to wonder who will do the work to get there.

Is it technically possible? I believe it is. Does it make sense for a
particular purpose? I think it does, and I think it's being done - maybe
you didn't consider my previous examples to be relevant because they
lacked the final step of creating a stand-alone application, but I think
that's a minor point... given the .NET environment, I can easily have a
user select a few functional modules for his application and auto-generate
a new application from that definition. In addition to those I listed
previously, there are certainly lots of other examples around, whether
they result in compiled apps or not.

Finally, does it make sense to think of the whole future of software
development in this way? I don't think it does, it never does. IMO, the
landscape of software development and architecture has long been defined
by smaller and larger niches. No big or small hype has significantly
changed that in recent history.


Oliver Sturm

 

[Bob Johnson]

Hello Oliver,

Agreed on all points... especially:

< snip from Oliver's previous post >
In the end it's not a technical issue, it's one of standardization. I can
create an architecture that would allow end users to create their own
applications. The problem is, there are only so many hours in my day and
so much domain specific knowledge in my head, so others would have to work
together with me to create a meaningful all-purpose platform.
</ snip from Oliver's previous post >

What you're saying (and what I've been concluding) is that these "mashups"
et al are *really* just ginormous applications. Of course they are likely to
be distributed - and may have different development teams responsible for
major discreet functionalities. Making this all work in a way that can be
trusted by the business would be a a HUGE effort requiring a significant
amount of coordination, planning, TESTING, and agreement amongst the various
development factions. You know what that sounds like to me? A basic
run-of-the-mill distributed enterprise application development effort; oh,
but with the end result being that non technical business users can
point-n-click their way to an entirely new "application quilt" that
magically works and produces reliable and trustworthy data processing
capabilities. And, because this is a "truly unique" system, by definition,
it therefore has never been tested. Somehow the architects seem to think
that's unimportant (or magically taken care of by the unknown development
factions hiding somewhere in the cloud).

Is it just me, or is this just nuts?

What the authors of these "cloud-based" systems consistently put in their
articles is a laundry list of disclaimers - stating more or less "we have a
long ways to go before this can be realized and here's what has to happen in
order for us to get there from here" -----> and then they go on to describe
what it takes to develop a single large application... including a standard
database schema or rules for translating amongst data stores for achieving
common or interchangeable attributes, blah blah blah.

So, it appears to me that at the end of the day, they really haven't
introduced anything *new* - they've just come up with a new vocabulary to
describe stuff we already know.

Again, please {anyone}correct me if I'm missing anything that would point
out how "mashups", "cloud-based" et al are really different than just
big-*ss distributed enterprise applications.

-Bob

 

[darrel]

Are any of you taking this mashup/cloud-based/composite application

architecture thing seriously?

It just seems *totally* out of touch with reality.

What is 'reality'?

-Darrel

 

[darrel]

Again, please {anyone}correct me if I'm missing anything that would point

out how "mashups", "cloud-based" et al are really different than just
big-*ss distributed enterprise applications.

The 'web 2.0 mashup' buzzword typically just appears to be a web site
grabbing data from multiple sites via an open API and then
re-rendering/colating/calculating said data in a new way on their site.

Examples are sites that utilize Flickr and Googlemaps and Yahoo Pipes and
the like.

-Darrel

 

[Bob Johnson]

RE:
<< What is 'reality'? >>

Oh, let's not go there!

Now, seriously (i.e., back to "reality"), can you provide me with the tech
support number for the cloud? I'm developing a cloud-based system and I
pointed-n-clicked-n-everything and it just doesn't work. Can you please give
me the tech support number for the, um, cloud-base thingie?

Thanks.

 

[Bob Johnson]

RE:
<< Examples are sites that utilize Flickr and Googlemaps and Yahoo Pipes and
the like>>

Thanks Darrel, that's helpful feedback. I'll look more closely at those and
what makes them "go" to see what I can learn.

-Bob

 

[Oliver Sturm]

Hello Bob,

... it therefore has never been tested. Somehow the architects seem to
think that's unimportant
Is it just me, or is this just nuts?

I guess the assumption is that the whole will be as good as the sum of its
parts, which may of course have been tested on their own, or in certain
combinations.

Again, please {anyone}correct me if I'm missing anything that would point
out how "mashups", "cloud-based" et al are really different than just
big-*ss distributed enterprise applications.

I can see at least two ideas why such ideas are put forward:

* Repositioning an idea. "Distributed Enterprise Applications" describes not just an architecture - somehow we all make certain assumptions about that although the term doesn't really convey much -, but also the Enterprise, large corporate market as the target. These architectures are not, by nature, evil, so why not try to interest other people in them by calling them something that doesn't inspire the same known feelings.

* Keeping technical innovations in the picture. The world moves on. We have communication standards today that are more interoperable than they've been for a long time. The software development and runtime environments allow for things that were previously possible only in theory. Give something a new name and bring across the fact that there's something new about it. At least make people take another look.

Is that useless? I don't think so... as is often the case, it would be
nice if somebody took the time to give a great explanation when a new idea
(or something that's supposed to look like one) is put forward. But then,
maybe someone did - I didn't really look while this discussion went on.
Things are being reinvented for various reasons all the time, and you
don't create a hype by making it all too clear that the hype subject has
been there before...


Oliver Sturm

 

[Oliver Sturm]

Hello darrel,

The 'web 2.0 mashup' buzzword typically just appears to be a web site
grabbing data from multiple sites via an open API and then
re-rendering/colating/calculating said data in a new way on their site.

Examples are sites that utilize Flickr and Googlemaps and Yahoo Pipes and
the like.

I was on a totally different track on this topic, but of course you're
right - I've heard the words in this context, too.


Oliver Sturm

 

[Bob Johnson]

Thanks for the dialog Oliver.

RE:
<< Repositioning an idea>>

Yes! I get it: It's just like my Doritos: according to the packaging they
now have "more nacho cheese flavor" than ever before. LOL! My favorite
peanut butter was recently relabeled as having "more peanut taste" (no
kidding!). So I guess I could jump on this bandwagon and, at my next client
meeting, I'll start talking about my "cloud-based" system (and be thinking
"plain old OLTP RDBMS").

Now I can finally start using clouds instead of rectangles in my Visio
diagrams. This is going to be fun.

-Bob

 

[Kevin Spencer]

I do believe you're missing at least one point, Bob. Oliver stated that

"The incentive to do something like this would be the idea of not having to
pay a developer, sooner or later. As long as the developer is still in the
picture, there's no reason to carry things just that far - we all know how
hard the last mile can be. And if the developer is not part of the final
target scenario, one has to wonder who will do the work to get there."

I don't see this as the primary purpose of such an application. The primary
purpose for such an application is to provide a service that enables
end-users to perform tasks using automation, which is the same primary
purpose of all software. And, as with all software, the development of such
technology does not have the impact of putting developers out of work; in
fact, the application itself must be maintained, supported, and extended by
developers. As long as software exists, developers will be developing it.
The fact that an end-user can perform tasks that previously required a
developer to accomplish is nothing new either. As the technology evolves,
this happens all the time. The end result is that developers are called upon
to perform more complex tasks than end-users, those tasks which are "higher
up the food chain" of technology.

I really don't see this as anything new, in terms of what it accomplishes,
except for the specific ability that it provides. Otherwise, it is like any
other product of the evolution of software.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

I had the same problem once. Fixed it using the same solution.

 

[Bob Johnson]

Hi Keven,

I always appreciate your prespective.

RE:
<< I don't see this [<FromOliver> The incentive to do something like this
would be the idea of not having to > pay a developer, sooner or later
</FromOliver>] as the primary purpose of such an application. The primary
purpose for such an application is to provide a service that enables
end-users to perform tasks using automation, which is the same primary
purpose of all software>>

It could easily be both, IMHO.
In fact, I have built a small but successful and growing business around an
ASP.NET-based application that enables my customers to maintain their own
Web sites. My thought, prior to building the thing, was that I could provide
the (1) convenience of do-it-yourself maintenance to the customer + (2) NOT
pay Web developers to do all the maintenance - thereby lowering my costs
significantly.

Being that I have actually pulled this off with some success, I can tell you
firsthand that business users don't want to do their own Web site
maintenance and certainly don't want to create it - REGARDLESS of how easy
and "intuitive" the tools are. One of the big benefits of this whole mashup
cloud-based et al architectural push we're seeing is that "users can create
their own unique applictions (mashups and whatnot)." Based on my little
corner of the world (my Web business plus 14 years of independent consulting
for government and big business), I can tell you that business people simply
don't want to engage in the creative process, maintain their own systems, or
have much to do with IT beyond using it. They're much more interested in
being a business person and doing the doing of their business. Why would
they want to create their own "application quilt"? They are very clearly
interested in having something fall into their laps - even if they have to
pay for it - that they can learn and use and run with immediately. What is
of most value to them, IMO, is that it "just works" and helps them to do
their jobs better faster, etc. They really could care less (at best) or even
overtly avoid (most common) taking on anything that resembles them creating
or maintaining the software, itself. So, at the end of the day, these
"mashup" promoters appear to be very much disconnected from much of the
business user community by claiming that end-user-created apps are desired
by the business user community at large.

-Bob

 

[Kevin Spencer]

Hi Bob,

I see your point regarding business customers. However, I see this as a step
along the evolutionary path of software. The problem today is that software
is not intelligent enough to be convenient to businesses. It will probably
be a long time before it is. But it seems to move in that direction
constantly, and I can imagine a point where such a thing will be widely
embraced.

--

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

I had the same problem once. Fixed it using the same solution.

Hi Keven,

I always appreciate your prespective.

RE:
<< I don't see this [<FromOliver> The incentive to do something like this
would be the idea of not having to > pay a developer, sooner or later
</FromOliver>] as the primary purpose of such an application. The primary
purpose for such an application is to provide a service that enables
end-users to perform tasks using automation, which is the same primary
purpose of all software>>

It could easily be both, IMHO.
In fact, I have built a small but successful and growing business around
an ASP.NET-based application that enables my customers to maintain their
own Web sites. My thought, prior to building the thing, was that I could
provide the (1) convenience of do-it-yourself maintenance to the customer
+ (2) NOT pay Web developers to do all the maintenance - thereby lowering
my costs significantly.

Being that I have actually pulled this off with some success, I can tell
you firsthand that business users don't want to do their own Web site
maintenance and certainly don't want to create it - REGARDLESS of how easy
and "intuitive" the tools are. One of the big benefits of this whole
mashup cloud-based et al architectural push we're seeing is that "users
can create their own unique applictions (mashups and whatnot)." Based on
my little corner of the world (my Web business plus 14 years of
independent consulting for government and big business), I can tell you
that business people simply don't want to engage in the creative process,
maintain their own systems, or have much to do with IT beyond using it.
They're much more interested in being a business person and doing the
doing of their business. Why would they want to create their own
"application quilt"? They are very clearly interested in having something
fall into their laps - even if they have to pay for it - that they can
learn and use and run with immediately. What is of most value to them,
IMO, is that it "just works" and helps them to do their jobs better
faster, etc. They really could care less (at best) or even overtly avoid
(most common) taking on anything that resembles them creating or
maintaining the software, itself. So, at the end of the day, these
"mashup" promoters appear to be very much disconnected from much of the
business user community by claiming that end-user-created apps are desired
by the business user community at large.

-Bob

 

[intrader]

I know this isn't .NET-specific (thus the "OT:" in the subject line) - but
it's relevant to what we do as modern distributed system developers:

So I'm hearing a lot of buzz about "mashups," "cloud based systems,"
"composite applications" etc...

From what I have read, these are apparently systems made up of many other
[perhaps smaller] systems. It's like the architects promoting these ideas
have taken component-oriented programming and cast the "components" as being
entire other systems. Now we're using entire applications as building blocks
for other entire applications.

The big benefit - as the promoters say - is that users - yes USERS of all
people - will be able to dynamically create entire new applications, or at
least dynamically add entirely new functionality to existing applications.
There is a long list of pitfalls and "gotchas" and ownership issues I could
add here, but I suspect most of you can easily see many on your own.

So, finally, my question:

Are any of you taking this mashup/cloud-based/composite application
architecture thing seriously?

It just seems *totally* out of touch with reality.

Please note: this isn't intended as any sort of rant, and I'm not any sort
of Luddite. I'm just wondering if I'm missing something, or if the king
really isn't wearing any clothes.

Thanks for your thoughtful insights.

Have you looked at QEDWiki or at Yahoo Pipes? Both are mashup
composition IDEs, one a little higher in the food chain than the other.