At a Salesforce.com dinner held here in New York this evening, we had a chance to compare notes on the characteristics of the new media vs. the old. Specifically, the values of old line “straight” journalism vs. the more informal tell-it-like-is blogging metaphor that increasingly is becoming the way many of us communicate and receive news. Of course, blogging is about more than just news, it’s a highly participatory, immediate, interactive medium that when done properly, stimulates conversations across an extended community. And through provision of links, it makes communication far more transparent, in that you provide readers the option of going straight to the source.
But we’re wondering whether it’s possible to have too much transparency. In particular, we’ve come across a service called FEEDJIT that provides what we’d characterize as a Twitter in reverse. That is, while Twitter tells you what your source is up to, this one points the mirror back at you, the reader. When you click onto a blog site that uses FEEDJIT, it will show you, not what the blogger is up to, but geographically where the readers are coming from. And since it lists readers in chronological order (latest readers first), you’ll see your location staring at you, at the top of the list.
While there’s no identity information disclosed, the effect was still a bit chilling. It’s as if you’re entering a library and a guard at the door announces the name of your street as you walk in. In an online world where helpful navigational aids like cookies can be transformed into inadvertent spyware, somehow the idea of seeing your locale announced when you log onto a website to us seems like an invasion of privacy. In other words, a case of Web 2.0 transparency taken a bit too far.
Does that bother you?
There’s kind of a love/hate relationship between SOA and mashups. While the primary benefit of SOA is better enterprise agility, for many organizations, the reason to do SOA is a more flexible, standards-driven form of EAI. The recent WOA vs. SOA backlash has been driven by perceptions that SOA, in the form of web services, is too complex, and with the bewildering array of WS-standards, too confusing. In some eyes, the emergence of mashups has been perceived as a PDQ alternative to SOA because, heck, you can lay chunks of web objects atop each other without having to do all that architecture “stuff.”
But as we and others have noted over the past year, adults are attempting to occupy the vacuum of control that Ajax-style mashups have created. The approach is not a black and white SOA vs. mashups choice for enterprise integration, but rather, use of mashups for the last mile of integration that may, in many cases, utilize data services, feeds, or other sources that more often than not are exposed as Web or RESTful Services.
Lorraine Lawson provided her own mashup of recent developments in the enterprise mashup marketplace, citing recent developments pointing to emergence of enterprise mashups, not simply as a discipline or design pattern, but as a more formalized market. Lawson pointed to a Forrester Research study estimating a $700 million market within 5 years. The challenge of course is defining it, so she referred to comprehensive analysis by Dion Hinchecliffe from last month’s Web 2.0 Expo, along with recent articles from JackBe’s John Crupi and Chris Warner citing the need for, in effect, an enterprise sandbox approach to mashups. That is, business users can play freely with assets that are vetted and/or created by IT. In fact, JackBe’s approach isn’t all that unique; for instance, Serena’s Business Mashups operate on similar principles.
We were especially impressed with Hinchcliffe’s diagram, which provided one of the first and easiest-to-understand mappings of how this market is shaping up. Specifically, he divides the terrain into data, code, and visual mashups – providing a good way for understanding how different vendors are approaching mashups. We believe that this represents stage 2 of 3 – the first was emergence of primitive Ajax tooling, the second is more formal delineations that in many ways reflect existing silos within enterprise software architecture. That is, you have database tools, coding tools (also known as IDEs), and then you have your web design.
Ultimately, in stage 3, these approaches themselves will mash up as simply multiple technology-driven paths to the same summit. As long as IT vets it, you shouldn’t need different tooling to combine a structured data service with an unstructured content feed, a piece of business logic, and some rich expressive user interface design artifacts. Consequently, the technology-based silos illustrated by Hinchecliffe are an interim phase in an evolution that will ultimately see the mashup market simply shake out into two über categories: unsupervised, consumer-oriented mashups, and the more formalized enterprise mashups.
Not everything always goes by design, as SAP is learning firsthand with BusinessByDesign (BBD), its for-now temporarily stalled foray into the SaaS market. The ideas behind BBD, of a repository, SOA-based framework offered the promise, not only of buzzword-compliance, but potential breakthroughs in the kind of lightweight, flexible, agile app environment for SMBs that of course is missing in SAP’s traditional ERP offerings.
Although their frequently over-the-top marketing often makes it difficult to discern grains of truth, Salesforce.com’s “No Software” campaign is more than bluster; it indicates that Software-as-a-Service is plain different from the software business in numerous ways, encompassing revenue model (subscription rather than perpetual license + maintenance); deployment (once); pace of change (quicker, because when you free clients of upgrade hassles, they expect faster responsiveness that will be seamless); and architecture (multi-tenancy model).
This morning, Phil Wainewright, who recently spent spent several frustrating days at Sapphire Berlin, provided an excellent roundup of his observations and those of several Enterprise Irregulars who, on why BBD for SAP has so far not proceeded as originally designed.
As we mentioned a couple weeks back, we didn’t think that Microsoft’s walking away from its original Yahoo offer was absolutely final.
We expected that if Yahoo’s proposed ad syndication offer with Google hits an antitrust wall, that Microsoft would be back. Microsoft has just issued a statement saying exactly that, and although it might not derail a Yahoo-Google ad deal in the short run, it is actively declaring that it will be next in line should the anti-trust folks shoot things down.
And of course, in the past couple weeks, activist investor Carl Icahn has jumped into the game at Yahoo. You might recall that he recently bought a chunk of BEA, which eventually succumbed to Oracle after playing similarly hard-to-get.
Here’s an excerpt from Microsoft’s statement:
“Microsoft is considering and has raised with Yahoo! an alternative that would involve a transaction with Yahoo! but not an acquisition of all of Yahoo! Microsoft is not proposing to make a new bid to acquire all of Yahoo! at this time, but reserves the right to reconsider that alternative depending on future developments and discussions that may take place…”
It’s going to be a while before the fat lady sings.
In the wake of Microsoft’s failed Yahoo bid, we recently sat in on a BriefingsDirect podcast to give our prognostication on the future beyond keywords. Will software vendors find an alternative to subscription sales with ads, or is the future more driven, not by advertising as we know it, but product placement in the context of an activity, such as gaming, or a process, such as bookkeeping? As for Microsoft, what’s its next act after Yahoo? Could Facebook provide the opening, not necessarily through ad placement, but as a way to infuse social computing into enterprise collaboration?
Convened by ZDNet blogger & analyst Dana Gardner, we joined fellow independent analysts Joe McKendrick and Phil Wainewright in the roundtable; to hear the podcast or read excerpts, click here.
Just mention the word “governance,” and most people will equate it with auditors or attorneys who scold on all the wrong things you’re doing, or that a gap in the access control system could put your CEO in jail. No wonder governance is such a hard sell, and why Forrester Research analyst Mike Gilpin and Software AG chief marketing officer Ivo Totev concurred that when it comes to SOA governance, maybe we need another name.
Nonetheless, on a beautiful day in May, roughly 150 customers and prospects showed up for a SOA governance summit presented by Software AG at a hotel in the heart of Times Square. Maybe the turnout wasn’t so surprising given the locale. With the financial sector having seen Enron and corporate options scandals, not to mention the subprime meltdown, if there was ever a sector that begs governance, this one’s the baby.
It was also a pretty sophisticated audience when it came to SOA background; virtually everybody in the room had already gotten their feet wet with SOA projects, and roughly 60% were already involved in some form of SOA governance effort. We had the chance to moderate a panel with Gilpin, Software AG’s Miko Matsumura and Jim Bole, plus HCL Technologies consultant (and pragmatist) Rama Kanneganti, most of whom had spoke earlier in the morning.
Gilpin and Kanneganti gave the audience healthy doses of realism.
Gilpin maintained that, at least for larger enterprises, the deeper they get into SOA, the more likely they’ll wind up with four, five, or more enterprise service busses. In other words, don’t fool yourself with the myth that you’ll have a single monolithic grand unification architecture, despite the best efforts of your enterprise architects. Just as most organizations never succeeded with the galactic enterprise data warehouse or that top-down enterprise data model, life in a modern post M&A world is just too complex and heterogeneous. He noted that no vendors have yet picked up the mantle on how to integrate all those integration stacks, but in the next year or two you’ll start seeing commercial product rolling out. Nonetheless, he conceded that selling an integration stack of integration stacks may not be the easiest pitch that you’ve ever made to a CFO. For starters, if you end up using the same rationale that was purposed towards justifying those initial SOA investments (e.g., more reuse, agility, better IT/business alignment), the response is likely to be jaded. Gilpin’s dose of reality was not without its ironies: as you implement SOA to unify your app and data silos, you could wind up with creating yet another über silo.
When it was Kanneganti’s turn, his talk was a welcome departure from the usual SOA-and-see-the-light presentations in its acknowledgment that in the trenches, SOA may seem so abstract that it may difficult at first to gain support through acclimation. He presented several lessons, such as:
1. “Dumbing down the technology” by eliminating the aura of mystery and the abstractness of service abstraction. Take advantage of social computing tools to tell stakeholders what’s really happening on the project and what it means (a challenge because architecture is not as easy to explain as, say, implementing a functional module of a business application), develop common plumbing services to get some quick wins (things like error handlers seemed a bit low level to us, and he later admitted to us that, no, those are not the first services you should develop, but they’re useful when you want to scale out the project) and then show how an approach that stays close to the basics can result in predictable production of services.
2. To reduce risk, organize something like an informal Center of Excellence, but pitch it more as “a center of getting things done” that contends with issues such as ownership of data or processes.
3. When it comes to the usual role of EAs, which is to promote better, consistent architecture, use a carrot rather than stick approach.
In between, Miko (we’re violating our usual editorial convention of last names because, well, his first name is so heavily branded) provided a talk that was, literally, a stretch. Relating some metaphors of evolution (reptilian functions are still present in human brainstems, and we’re genetically 95% equivalent to chimpanzees), he explained how SOA projects must navigate entrenched tribal turf rivalries, such as when services transition from design (software development) to run time (operations). And from that, he launched into a discussion of his latest initiative, looking at the synergies of service provisioning and virtualization – which we feel is the tip of the iceberg of a larger issue. Namely, how can you manage compliance with service level agreements or contracts as part of run time governance without some logical ties with IT operations and IT service management/ITIL worlds. It’s an area for which vendors on both sides of the aisle – the Software AGs, the HPs, and the IBMs, have yet to provide adequate answers. But, bringing the point back home, it’s a question of dealing with potentially warring tribes, as a debate rekindled by Todd Biske on the future of ESBs brought out a few weeks back.
As if we can’t get rid of this tribal mania yet, well, maybe they’re not a tribe, but a group of (choose one) soothsayers, high priests, or medicine men within the tribe. We’re talking about EAs here. When we posed the question of what SOA governance is, the panel concurred that it is a combination of people and processes, with technology as tool to apply the processes that people (in or out of their tribes have worked out). Bole volunteered that business processes might be a better way to sell SOA, and ultimately, SOA governance to the enterprise. We pressed again, asking, at the end of the day, who’s accountable for SOA governance? One of the answers was, maybe, yet maybe, SOA governance could make EAs relevant, finally.
Only leaked yesterday, this morning HP confirmed it would acquire EDS for north of $12 billion. The obvious driver, as colleague Dana Gardner noted, is that with the IBM and its global services colossus and the growth of outsourced, cloud, or on demand computing, that enterprise customers were going to demand a viable alternative – an Avis to IBM’s Hertz so to speak.
Of course the deal brings back memories of when Mark Hurd’s predecessor left off, which was the attempted purchase of PwC consulting for $18 billion back in 2000. Barely a couple years later, IBM swooped up PwC up for roughly a fifth of the cost. Besides the ridiculous price tag (these were pre-inflated dollars) was the question of culture clash. HP’s techie culture seemed a poor fit for PwC’s suit-and-tie atmosphere; as we maintained, IBM and PwC were a much better fit.
And while $12 billion still sounds like a lot of money, that’s probably about half of what HP would have paid back in 2000 with pre-deflated dollars.
But what a difference a few years and a more-focused senior management team make. Not only has Hurd rationalized the Compaq acquisition, but for the first time his team actually cultivated HP Software as more than an oxymoron, and has bulked it up with some shrewd acquisitions. Admittedly, success at HP Software doesn’t automatically portend similar results with EDS, which has been through the acquisition game before. More importantly, comparing Hurd to Fiorina, he exercises the far more hands-on management style that will be necessary to pulling such a transformative deal off.
Among the challenges are reorienting EDS away from IBM to promote HP infrastructure. Given that EDS is stronger in infrastructure outsourcing rather than mainstream systems integration, that might be a smoother shift, but it will require an internal migration of expertise. EDS is already part way down the transformation road, having been slimmed down by CEO Ronald Rittenmeyer (he stays on as business unit head), and before that, Michael Jordon (no, not the Air Jordans guy).
Significantly, HP will preserve EDS’s identity and autonomy, handing over some of Ann Livermore’s services operations. With more engaged management, HP stands a better chance this time of making such an acquisition work.
SOA Software, a company that makes secrecy a virtue, has surfaced just long enough to tell us that they’ve finally plugged a gap in their SOA offerings. The privately held firm, which until now has concentrated on run time SOA management and integration, is acquiring LogicLibrary, which has the upstream SOA repository component.
SOA Software has historically competed with AmberPoint, which has concentrated on SOA management, otherwise known as run-time governance. By contrast, SOA Software has also focused on run-time integration, offering products providing service gateways for B2B transactions, mainframe CICS transactions, along with its existing service mediation and routing (SOA Software isn’t so buzzword-crazy as to call their mediation offering an ESB).
But as customers get past piloting their SOA environments, they need to adopt more of a lifecycle approach to managing the service, from concept to run time, and whatever you do at the end of a service’s live. More importantly, they also want to leverage reuse, which without a place to manage the service lifecycle (and track what kind of service it is), is practically impossible. For SOA customers, adding that level of lifecycle governance required them to go best of breed.
That’s where LogicLibrary comes in. With IBM, Software AG, Tibco, and Oracle/BEA promoting end-to-end approaches (with HP nudging in), the question with SOA Software was when they would finally add the missing link.
Significantly, LogicLibrary’s lineage is more akin to Flashline, later acquired by BEA, as opposed to something like WebSphere Registry/Repository. Specifically, LogicLibrary began life as a component, rather than specifically an SOA repository. As such it emphasized links with source code management systems (SCM), with APIs to all the major names: Rational ClearCase; Serena PVCS and Dimensions; Microsoft Visual SourceSafe and Team Foundation Server; and open source offerings like CVS and Subversion.
Consequently, LogicLibary brings an SDLC (Software Development Lifecycle) focus to the SOA lifecycle, providing the ability to establish dependencies for components that are exposed as services back to the assets released by software development organizations. That’s counter to the louder noises or recent that SOA should be business process-, rather than software artifact-driven. That is, your services should be driven by the business stakeholder’s view of what services should be offered, as opposed to the software developer’s integration focus based on lower-level perceptions of what software components or artifacts should be exposed. Call it the BPM or top-down, vs the Component-Based Development, or bottom-up view.
We doubt that SOA Software wants to get in the middle of that shouting match, but they will get dragged in.
What’s more interesting is that SOA Software and LogicLibrary have rarely crossed paths in the field. It sounds like both started to work on a partnership, with one thing leading to another., The upside is lots of cross-selling opportunities, the challenge is educating each other’s customer base that they are missing something essential.
While our overriding impression was that the Rich Internet Application was the predominant theme of this year’s JavaOne, we did stumble across one potentially interesting server development. Caucho, a 10-year old firm that we’ve never heard of, has recently reached a major milestone in its 3-year effort porting PHP over to Java. That is, it’s taken the underlying constructs of PHP, which are written in C and C++, and reimplemented them in Java. The result is kind of you-can-have-it-both-ways deployment platform for PHP.
The result is Resin, an open source appserver that lets you write your web app in PHP, but run it on a server that takes advantages of most (not all) of the Java EE services of brand name appserver platforms. In other words, you get the reliability, load balancing, and other bulletproofing features of Java EE, but you don’t have to write Java. It’s drawn several major PHP sites, which the company cannot disclose, but does brag how Japan’s largest online gaming portal migrated from Tomcat to Resin.
Caucho doesn’t claim to have the job finished; in fact, given the impedance mismatches between PHP and Java, it never will be a 100% artifact-for-artifact translation. For starters, there’s the immaturity and rough edges of PHP, which still isn’t fully documented and has its share of bugs. But the company has attained compatibility with PHP 6 and now supports some of its most popular apps like the Drupal social networking-oriented content management system, WordPress blogging platform, and MediaWiki engine that powers Wikipedia.
We never heard about Caucho before, but given PHP’s popularity and the current tooling vacuum surrounding it, we couldn’t ignore these obscure folks. PHP and other dynamic scripting languages like Perl, Python, and Ruby have emerged as responses to Java’s complexity. In essence, Caucho Resin is yet one of a number of responses (like “rebel” frameworks such as Spring or Hibernate) to the complexity of Java EE – and the idea of writing PHP appservers seems to be catching. Reportedly, IBM is also pursuing the idea.
Watch this space.
JavaOne provides a good barometer of the current fads hitting IT. Three years ago, Java discovered open source; two years ago, it was Ajax; while last year was a non-event. But this year, the rich client’s back, baby.
In fact, this being our tenth JavaOne (which we covered remotely this year – too much darn travel), the spotlight on the client was déjà vu all over again. Covering our first JavaOne back in 1998, most of the booth traffic was around demos showing Java applets adding animation to word, numbers, and pictures on the browser. Ironically, we could have cared less about the animated browsers; instead what piqued our attention was this startup company called WebLogic, which made a bet on Enterprise Java Beans (EJBs) before the standard was approved. More importantly, their message was, forget the animations, the true value of Java was back on the server.
You know the rest of the story. Java’s early stab at rich client fell prey to bandwidth hurdles (those were the days of dial-up) and the nagging issue of browser compatibility. The Flash runtime stole eventually the thunder, literally.
But we digress.
This year’s appearance by Neil Young set the tone: it’s all about really rich multimedia, the type of stuff where Plain Old Ajax (POA?) runs out of gas. Yes, Sun made some announcements about its open source Glassfish appserver (a new telco edition was coming out), but this year’s big announcement was the roadmap for JavaFX, the rich Java client framework that Sun first announced last year.
Thanks to Neil Young, JavaOne made the news, but the news was hardly about Java. The headlines read, Neil Young is beginning release of his entire music and video archives on Blu-Ray, making it the first serious music collection to hit the new high-def DVD format. But it was funny seeing pictures showing Sun CEO Jonathan Schwartz barely squeezed into the frame as a rock fan. The Java connection? Java lets you have a real interactive experience with Blu-Ray, rather than the rudimentary front, back, right, left navigation you get with run of the mill DVDs.
Back to JavaFX, it’s Sun’s all-Java answer to Adobe Flex/AIR and Microsoft Silverlight. To recap, JavaFX is a programming framework for accessing the rich media capabilities that to some extent were already part of the Java SE desktop spec, plus new ones such as the streaming audio and video codecs from On2 that Sun just announced it was licensing. And with the whole deal is yet another new scripting language, JavaFX Script, which would make all the rich media capabilities of Java accessible to web designers. Just like Microsoft Silverlight, and its associated scripting languages, this is yet another play for the Adobe Dreamweaver crowd.
During the keynote, Sun splashed demos showing screen renderings of the kinds of spinning, 3D spheres that for us rekindled memories of demos of the first multimedia PCs of the early 90s, and the finite element model renderings of CADCAM systems using souped-up graphics cards a few years before that. Some demos never change. We also saw a demo of Java applets (remember them?) being dragged and dropped off the browser to the desktop, where you could persist them as a regular local app –- which in its own weird way could be construed as Sun buying into Microsoft’s Software + Services vision blending the cloud with local client.
Ever since Sun hatched JavaFX a year ago, we wondered about why the world needed yet another multi-platform rich client framework, as Adobe would have proven a convenient multi-platform partner. But that was based on the dated perception of Sun viewing Microsoft as its primary rival. In fact, it’s much more nuanced picture, given (1) Sun’s and Microsoft’s interoperability détente; (2) the increasingly intense rivalry between NetBeans and Eclipse for Java development platforms; and (3) competition for the hearts and minds of Rich Internet Application (RIA) developers and designers, where for now it’s advantage Adobe.
And that’s where you get into a battle of lies, damn lies, and statistics. Sun and Adobe are battling over whose runtime is more ubiquitous in the connected world. Adobe claims that the Flash Player reaches over 98% of Internet-enabled desktops in “mature” economies (the number drops to 97% when rest of world is factored in), compared to 84% for Java. Sun counters that the JVM is on 90.7% of all Internet-connected desktops, plus virtually all smart phones produced within the last three years. Well not quite. The iPhone is expressly omits Java support, and of course, there are Windows Smart Phones. Adobe has Flash Lite for mobile devices, but it hasn’t published studies showing killer penetration.
Nonetheless, when you parse the numbers and statements, it’s clear that Sun views Adobe as it main rival for the Rich Internet client. JavaFX is Sun’s stake in the ground for its argument that the Java Runtime Environment (JRE) is the place to do your multimedia, rather than the Flash plug-in. And that’s why Sun is trying to reopen the barn door, even after some of the horses have galloped out.
« Previous entries Next Page » Next Page »