{"id":62,"date":"2006-03-24T18:06:23","date_gmt":"2006-03-25T01:06:23","guid":{"rendered":"http:\/\/www.redmonk.com\/cote\/wp\/?p=62"},"modified":"2006-03-24T18:06:23","modified_gmt":"2006-03-25T01:06:23","slug":"bea-analyst-summit-2006-mashups-composite-apps-consumer-tech-and-stopping-brutus","status":"publish","type":"post","link":"https:\/\/redmonk.com\/cote\/2006\/03\/24\/bea-analyst-summit-2006-mashups-composite-apps-consumer-tech-and-stopping-brutus\/","title":{"rendered":"BEA Analyst Summit 2006: Mashups, Composite Apps, Consumer Tech, and Stopping Brutus"},"content":{"rendered":"<p>\n<a href=\"http:\/\/www.flickr.com\/photos\/cote\/117396308\/\"><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/static.flickr.com\/40\/117396308_695ef696bf_m.jpg\" width=\"240\" height=\"180\" alt=\"Liquid! BEA badge\" \/><\/a><\/p>\n<p>As <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/ibm_open_source.html\">seems to be the trend<\/a> with me going to analyst conferences, I wrastle for some time with many drafts and snarky write-ups about my thoughts. In the end, taking a wider, industry view, as reflected by the company at hand, wins out. As I try to tell people, my prime interest is in seeing the industry thrive and evolve, not torn apart by the likes of me, customers, and, <a href=\"http:\/\/www.amazon.com\/gp\/product\/1590591046\/\">more often<\/a>, itself.<\/p>\n<p>So, here&#8217;s some &#8220;summary,&#8221; <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/bea_analyst_sum_2.html#comments\">as promised to make up for all that damn note-posting<\/a>.<\/p>\n<p>(The funny thing is, I was originally just going to post on how GMail should list links to all the emails you&#8217;ve sent\/recieved from someone when you&#8217;re replying to that person. The use case being so that you could remember who the person was if you didn&#8217;t immediately know. Yeah, sorry&#8230;too much navel gazing there.)<\/p>\n<h2>Composite Applications Meet Mashups<\/h2>\n<p>One of the big concepts at the BEA Analyst Summit was composite apps. SOA&#8217;s can help enable composite apps, so you can imagine BEA, the self-proclaimed Masters of SOA, are all over composite apps. Which is <i>not<\/i> to say that you couldn&#8217;t have them without SOA&#8217;s, just that the two are a natural fit. The <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/bea_analyst_sum_5.html\">Pratt &amp; Whitney customer story was a great tale of composite apps and SOA&#8217;s at work<\/a>.<\/p>\n<h2>On the Glass with JavaScript Includes<\/h2>\n<p>A phrase you hear a lot is &#8220;on the glass&#8221; or &#8220;screen&#8221; integration. Indeed, that&#8217;s the most successful approach in web-land: JavaScript includes rule the school when it comes to quick and easy composite apps. As I suggested to several people, if you&#8217;re doing any sort of content\/portlet platform, you should really, <i>really<\/i> use <a href=\"http:\/\/www.phpied.com\/javascript-include\/\">JavaScript includes<\/a> as one of your interfaces. SOAP interfaces are par for course; REST interfaces, now I&#8217;m listening ; JavaScript Includes, jack-pot!<\/p>\n<p>They&#8217;re wildly successful on the web for pulling (<a href=\"http:\/\/www.flickr.com\/badge_new.gne\">flickr<\/a>, technorati, <a href=\"http:\/\/del.icio.us\/help\/javascript\">del.icio.us<\/a>, Google Text Ads etc., etc.) and pushing (every single hosted website log tool, including <a href=\"http:\/\/www.google.com\/analytics\/\">Google Analytics<\/a> and the much better <a href=\"http:\/\/www.statcounter.com\/\">StatCounter<\/a>) data between websites and services. JavaScript includes are pure on the glass composite applications at their best: they&#8217;re easy to use and cheap to develop. They call it The Sweet Spot: Kids like it because it taste good, moms like it because it&#8217;s healthy.<\/p>\n<p>Dude, and don&#8217;t even get me started on <a href=\"http:\/\/en.wikipedia.org\/wiki\/Bookmarklet\">bookmarklets<\/a>. That&#8217;s some consumer tech ripe for the enterprise picking. Those little bookmarks are so damn useful. Look no further <a href=\"http:\/\/weblog.infoworld.com\/udell\/gems\/libraryLookup1.html\">than our man Udell for proof positive<\/a>.<\/p>\n<h2>Consumer Tech Driving Enterprise Tech<\/h2>\n<p>It&#8217;s worth pointing out, as several BEA folks did when I told them I liked Web 2.0 ideas and technologies, that &#8220;composite app&#8221; is just a fancier term for &#8220;mashup.&#8221; For reasons of &#8220;coolness&#8221; &#8212; <a href=\"http:\/\/www.msnbc.msn.com\/id\/11569228\/site\/newsweek\/\">apparently, you have to be under 35 to know the term<\/a> &#8212; &#8220;mashup&#8221; has received bigger flurry of &#8220;yuh!&#8221; than &#8220;composite application&#8221; did.<\/p>\n<p>Which of course, begs the question: how can we get the enterprise software vendors of the world to use cooler words like &#8220;mashup&#8221; instead of &#8220;composite application&#8221;? Would it work? The over 35 crowd (hopefully it&#8217;s obvious that I&#8217;m poking fun at <a>that claim<\/a> instead of those over 35) might think it&#8217;s a toy; <a href=\"http:\/\/www.theregister.co.uk\/2001\/04\/20\/ibm_caught_tagging_san_fran\/\">The Kids might think it&#8217;s false <\/a>. Or, the mind shift required to make the name change possible might just result in better software.<\/p>\n<p>More importantly, it highlights the a major trend in innovation that&#8217;s worth pointing out, obvious as it may be to some: consumer technology is driving (or should be!) much of enterprise technology. Business needs drove technology much more in the past. But now that there&#8217;s actually <a href=\"http:\/\/today.reuters.com\/investing\/financeArticle.aspx?type=hotStocksNews&#038;storyID=2006-03-24T214910Z_01_N24263210_RTRUKOC_0_US-FINANCIAL-GOOGLE-INDEX.xml\">quite a lot of money in consumer software<\/a>, there&#8217;s quite a lot of innovation in it. I&#8217;m not the first to point this out by far. On the other hand, enterprise software vendors don&#8217;t seem to be benefiting from that trend as much as they could.<\/p>\n<h2>REST and SOAP<\/h2>\n<p>Another trend, of course, is REST vs. SOAP. Sure, consumer sites like eBay, Amazon, and flickr are REST heavy, but what about in the enterprise? It seems <a href=\"http:\/\/www-03.ibm.com\/developerworks\/blogs\/page\/woolf?entry=which_is_most_common_soap\">not so much<\/a>&#8230;though it&#8217;s tough to say. The interlacing of SOAP and SOA makes me worry that SOA&#8217;s slogan will simply become &#8220;SOA: it&#8217;s like CORBA&#8230;except this time it&#8217;ll work!&#8221;<\/p>\n<p>Point being, I&#8217;m not too thrilled about the long term viability of an SOA approach based on SOAP. SOAP is complex, and that complexity causes costs. That creates a whole market that&#8217;s geared towards making the SOAP based SOA easier to use.<\/p>\n<h2>A Love Complex<\/h2>\n<p>As a vendor, you <i>love<\/i> that: enterprise vendors help their customers solve problems by writing better software than the customers could themselves. Writing the best software possible is BEA&#8217;s model, and they&#8217;re very proud of it. As <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/bea_analyst_sum_2.html\">they said<\/a>, &#8220;the reality is that we&#8217;re providing these features that our competitors can&#8217;t provide.&#8221; Quality software aside, the love of complexity is really just short term though because&#8230;<\/p>\n<p>As a customer, you hate complexity. In the world of requirements, protocols, and everything in-between, complexity is a cash-burner. When it comes to web services, the further away you get from a URL that anyone could type in a browser, the more complexity you have. Complexity is why you spend so much on IT. That&#8217;s why I&#8217;m such a broken record when it comes to <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/notes_on_enterp.html\">Agile software development<\/a> and <a href=\"http:\/\/www.amazon.com\/gp\/product\/0884271781\/\">lean tuning<\/a>: they&#8217;re complexity killers.<\/p>\n<h2>If the Software Won&#8217;t <a href=\"http:\/\/www.jwz.org\/doc\/groupware.html\">Get You Laid<\/a>, At Least it Should Be Fun<\/h2>\n<p>Not to mention the fact that REST is so much more fun than SOAP. Even XML-RPC is more fun to use than SOAP. As <a href=\"http:\/\/www.tuaw.com\/2006\/03\/24\/the-history-of-microsoft\/\">crazy as the idea has been put in the past<\/a>, developers ultimately play a huge part in the success of a technology. Just think of the cycle:<\/p>\n<ol>\n<li>You, an enterprise software vendor, sells a big middleware stack to some wing-tips.<\/li>\n<li>The wing-tips tell the developers: <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/02\/the_exciting_wo.html\">here is your middleware<\/a>. Now let&#8217;s implement that system!<\/li>\n<li>The developers dislike the middleware.<\/li>\n<\/ol>\n<p>Now, you, the enterprise software vendor, are at the mercy of the developers. The developers are the ones who&#8217;re going to make your software look good&#8230;or really bad. If the developers are late delivering, you can fully expect them to start saying, &#8220;that damn middleware takes too long to work with. It&#8217;s too complex.&#8221;<\/p>\n<p>They could be right. They could be wrong. It doesn&#8217;t matter: in the scenario you&#8217;re middleware looks bad to most people. And if they actually paid for the middleware instead of got it for free, so much the worse.<\/p>\n<p>More than likely, this same trend will start happening with <a href=\"http:\/\/www.redmonk.com\/sogrady\/archives\/001419.html\">dynamic languages<\/a>. &#8220;I could have delivered on time, but this Java takes so long. I whipped up something in Rails last night though&#8230;&#8221;<\/p>\n<p>Both of those instances are nefarious uses of one of the better, but little used, Agile tools &#8220;failing in order to learn how to succeed.&#8221; If you&#8217;re a vendor, that&#8217;s a terrible tool to be at the wrong end of.<\/p>\n<h2><a href=\"http:\/\/www.presentationhelper.co.uk\/friends-romans-countrymen.htm\">&#8220;But Brutus says he was ambitious&#8221;<\/a><\/h2>\n<p>As one of my architect buddies put it today:<\/p>\n<blockquote><p>\nA great opening quote for your upcoming book on enterprise software: &#8220;In the late 90s, enterprise software was alive and well until it was slowly beaten to death by enterprise software companies.&#8221;\n<\/p><\/blockquote>\n<p>While there is no upcoming book, he&#8217;s right on. Obviously, I&#8217;m not here to kill enterprise software, or run around saying it&#8217;s dead. Hardly. On the other hand, I sure would like to see enterprise software, stop harming itself with complexity.<\/p>\n<p>I am that weird type who likes it, and the even weirder type who likes systems management. It is my sickness.<\/p>\n<h2>BEA<\/h2>\n<p>From the content I got at the BEA summit, I can&#8217;t really make the call as to whether BEA&#8217;s offerings are too complex. Things don&#8217;t really get that low-level at such events: though, it is fun to see the spark in tech-people&#8217;s eyes when you open the door for them to talk about tech stuff instead of feature tick-lists, workflow management, and reports, all of which tends to dominate the Q&amp;A&#8217;s.<\/p>\n<p>From what I did hear &#8212; the goals, ostensible purposes, and lengthy on- and off-line conversations &#8212; BEA is taking a smart approach to things. Let&#8217;s just hope they don&#8217;t end up in WS-Hell and the mind-set that takes you down that path. Even Superman and Navy Seals might find that one a hard extraction.<\/p>\n<p><a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/bea_analyst_sum_9.html\">BEA&#8217;s Holland, Graffiti, and Runner projects<\/a> where the most encouraging things I heard about along the lines of running towards simplicity. I&#8217;m hoping to hear, see, and talk a lot more about them in the future. Those project have the potential to un-burn <a href=\"http:\/\/scottmark.blogspot.com\/2005\/12\/portal-oriented-architectures-poa.html\">those who got burned by portals<\/a>.<\/p>\n<h2>It&#8217;s Possible<\/h2>\n<p>BMC doesn&#8217;t make a big, <a href=\"http:\/\/www.google.com\/search?q=%22BMC+Performance+Manager%22+tags\">or any<\/a>, stink about it (I and others often wonder why), but thanks to some internal marketing and the enthusiasm of the people who picked up the charge, while I was there we managed to get tags into an enterprise software system, even a search box. Which is a <a href=\"http:\/\/www.langmaker.com\/db\/eng_ginormous.htm\">ginormous<\/a> sentence to say: I&#8217;m a huge believer and have practiced getting Web 2.0 technologies into enterprise software. It&#8217;s strange going, but possible.<\/p>\n<p>(I could write even more about search being the ultimate feature. But I&#8217;ll save that for another time, it&#8217;s not even my idea, I just borrowed it from <a href=\"http:\/\/speakercity.blogspot.com\/2005\/06\/do-users-know-what-they-want.html\">someone else<\/a>.)<\/p>\n<h2>&#8220;Mashup&#8221; is shorter than &#8220;Composite Application&#8221;<\/h2>\n<p>Yes, which has always been the point, hasn&#8217;t it? <a href=\"http:\/\/lesscode.org\/\">Less is more<\/a>. When you&#8217;re making a &#8220;composite application,&#8221; why not just drop in a JavaScript include instead of configuring and wiring up a portlet to an SOA&#8217;ed WS? Do you really need <a href=\"http:\/\/www.redmonk.com\/sogrady\/archives\/001379.html\">a &#8220;suite&#8221; of applications to type a memo<\/a>? When you&#8217;re creating an SOA, why not just write up a <a href=\"http:\/\/del.icio.us\/help\/api\/\">3-5 page POX API<\/a>, and that&#8217;s it? Do you win much from adding those 80-200 other pages and XSDs? You can no doubt, dear readers, figure out my answers to those questions.<\/p>\n<p>Of course, <a href=\"http:\/\/www.redmonk.com\/cote\/archives\/2006\/03\/bea_analyst_sum_1.html\">even <i>that<\/i> creates a problem ripe for vendors<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>As seems to be the trend with me going to analyst conferences, I wrastle for some time with many drafts and snarky write-ups about my thoughts. In the end, taking a wider, industry view, as reflected by the company at hand, wins out. As I try to tell people, my prime interest is in seeing [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,7,9,11,12,13,23,31,33,34],"tags":[],"class_list":["post-62","post","type-post","status-publish","format-standard","hentry","category-agile","category-collaborative","category-companies","category-conferences","category-enterprise-software","category-ideas","category-programming","category-rss","category-social-software","category-systems-management"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/posts\/62","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/comments?post=62"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/posts\/62\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/media?parent=62"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/categories?post=62"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/tags?post=62"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}