to homepage
 Weekly emails: how to advanced search
 Glossary lookup:


Loosely Coupled weblog

Wednesday, May 10, 2006

Why SOA Software bought Blue Titan

I happened to be visiting SOA Software in Los Angeles ten days ago. You can imagine my surprise when Blue Titan's Frank Martinez stepped out of the elevator to greet me on my arrival.

I was therefore able to get an early briefing on this week's acquisition announcement, while enjoying the panoramic 18th-floor view of the Pacific coastline that will greet Frank every time he makes the trip south to HQ from his base in Silicon Valley.

At first glance, this looks like an acquisition of a direct competitor — the first such by SOA Software, whose three previous acquisitions have been made to extend its technology and expertise. But in fact it turns out that the companies rarely came up against each other in sales calls. This makes the fit more complementary than it might seem. More importantly, it also provides an intriguing insight into the current state of the SOA market.

"The technologies while quite similar have a very different slant to them," SOA Software's VP of product marketing Ian Goldsmith told me as the three of us chatted.

"It's about governance and tolerance," he went on. "[SOA Software] instruments service consumers to implement downstream policy ... [Blue Titan] is a hell of a lot more about elasticity and quality of service."

This speaks to two distinct styles of SOA being implemented by enterprises today. On the one hand are very centrally controlled implementations, where the main concern is ensuring that services follow the rules that have been defined by a central IT architecture group. A good example of this type of implementation might be an organization that is using SOA to improve integration and reuse in order to consolidate and simplify its installed based of applications. The only way to achieve that objective is by defining a central set of rules and then enforcing them with strong governance.

At the other end of the scale, there are highly devolved implementations where the main concern is being able to tolerate a wide variety of service behaviors and policies. A typical implementation here would be in some kind of ecosystem in which autonomous participants choose their own service implementations and the owner of the SOA either has no power or can see no business case to enforce specific policies beyond common-sense security and boundary-setting. Exposing an API to customers is a good example of this type of implementation. The API provider isn't going to want to drive customers away by restricting the service implementations it will allow, and so has to be able to mediate anything from WS-* to REST and beyond, at various levels of service quality and sophistication.

This divergence may ring a bell with readers of my ZDNet blog, where I posted last week about SOA at rock bottom, and concluded that, "The missing link that connects SOA to Web 2.0 is a services mentality. SOA, SaaS and Web 2.0 are all services architectures; I see them all as part of the same continuum." The conversation I'd had with Ian and Frank was one of the strands that had led to that conclusion. SOA Software has acquired Blue Titan so that it can address the many fragments of that continuum, from highly controlled, governance-strong SOA-style architectures to highly devolved, governance-lite Web 2.0-style architectures. It's an astute move.

The other thing it does of course is to consolidate SOA Software's position as the leading pureplay SOA vendor, at the same time as narrowing the choice of acquisition targets available to others (such as BEA, Sonic, Mercury, Oracle, IBM, CA and HP) who might want to bolster their own SOA play. "We are clearly the best-positioned company in the SOA space to survive as an independent entity," Ian Goldsmith told me.

Certainly bringing Frank Martinez on board strengthens the company's visibility as a technology leader, as well as adding a much-needed Silicon Valley office. It will no longer be seen as so much of a dark horse. From Frank's point of view, the acquisition is probably the best available path that existed to avoid getting swallowed into a large corporation. Or as he put it: "We've built a phenomenal strategic footprint. Given the opportunity and ability to amplify what we've done, this is the perfect fit ... Our destiny is a hell of a lot more self-deterministic than we would have got alternatively."

posted by Phil Wainewright 10:51 PM (GMT) | comments | link

Wednesday, March 22, 2006

What will Spark ignite?

Microsoft's Michael Platt on Monday presented a model of the emerging Web 2.0 architecture at the Mix 06 show in Las Vegas. So at least the weekend's deliberations at Spark (which had been Michael's project) had some result. As soon as I have a link for the deck, I'll post it here [Update: Loosely Coupled now has a copy]. Will that be it, or will anything else come of Spark?

On the plus side, I think Spark surfaced some very useful ideas, and validated many others. Perhaps it is the validation, rather than what it created, that is the most valuable result. There are an enormous number of ideas floating around about the meaning of Web 2.0 and how it relates to SOA, SaaS and other trends. By getting a couple of dozen of us together, it was possible to filter out the ones that mattered.

I jotted down my own impressions of the key points that went into Michael's model as we discussed it on Sunday afternoon. For me, these are the essential ideas that have been validated over the weekend:

  • The user is the core, the foundation — but not the center. Saying that the user is the most important component is not the same as saying that everything revolves around the user. Thinking of this architecture as having a focal point inevitably leads you to misunderstand it. It is more akin to an eternal circle — an endless loop — in which providers interact with consumers who in turn become providers. Every endpoint is also a starting point.
  • There are many gradients — of trust/control, standardization, monetization, rate of change, core/edge. Enterprise architectures tend to stand at the controlled, well-defined ends of these gradients. Web 2.0 in its present-day form stands at the opposite ends, which means that it often seems chaotic and fuzzy. But the gradients form a continuum, and some of the chaotic/fuzzy stuff has a valuable role to play in the enterprise, while Web 2.0 could do with a bit more definition and order. No one yet knows, by the way, what are the optimum points on each of these gradients. We include them because it is important to recognize them, but we have not begun to calibrate them.
  • Content and context is the lifeblood of the architecture — what brings it to life. Therefore the architecture has an obligation to provide a framework for relationships and to manage information flows. That is partly a technical requirement, providing mechanisms for messaging, quality of service, versioning, identity, security and so on. At a higher level, it must also provide participants with structures for community and discovery.

On the negative side, there were some things we didn't get to. I didn't hear anyone mention network effects, for example, which in retrospect seems a most bizarre omission. Mediation was mentioned but didn't really get taken up. It's implicit in the architecture but we didn't explore it in the depth it deserves. Another gap was a lack of participants with expertise in on-demand applications and SaaS — no one from or Rearden Commerce or StrikeIron, any of whom might have brought a very different perspective to some of the discussions. At one point late on Sunday I found myself obliged to point out the significance of code customization versus declarative configuration in multi-tenant architecture, which shows how little we got under the skin of the on-demand SaaS model.

But Spark seems to have stimulated thought for the participants, several of whom have already posted some illuminating insights, including Dion Hinchcliffe, Richard Veryard, Dave Linthicum (who also recorded a podcast with some of the participants, including yours truly) and Jeff Schneider, whose diagram of The Web 3.0 Maturity Model deserves special study.

In conclusion, Spark began to dig into topics that will need to be explored further before they yield up all their secrets. Maybe Microsoft will find it worthwhile to repeat the event in six months or a year's time. In the meantime, mark it down as a useful starting point. Thanks to Michael along with his colleagues Norman Guadagno and John deVadoss for making it happen.

posted by Phil Wainewright 9:06 AM (GMT) | comments | link

Sunday, March 19, 2006

Spark and restart

I'm at Las Vegas with Microsoft discussing the future of architecture. Actually, not with Microsoft so much as a group of architects and analysts with a lot of collective expertise and practical knowledge about services architectures and Web 2.0 (software-as-a-service was also on the list of converging forces we're supposed to be discussing, but there are no hardcore practitioners of that here apart from Dave Linthicum, CEO of Bridgewerx.

It's been a couple of months since I posted to Loosely Coupled, precisely because I wanted to think about the impact of these three forces (SOA, Web 2.0 and on-demand) on how Loosely Coupled evolves. So it's appropriate to restart blogging at Spark, even if I haven't quite finished the work on the backend that I've been doing to streamline the way the site operates. So please excuse us if the news on the site remains a little out-of-date until I get back home from this trip.

What of Spark? We had a day's discussion yesterday to tease out the key drivers changing architecture and will aim to tie it all together today. Yesterday's session ended with a huge collection of ideas pinned up on a set of boards at the front of the room, but I thought this flipchart summary encapsulated everything that mattered:

  • Facilitation of user as center of universe — and as part of community
  • Balance of control:
    • $
    • technology
  • Change
  • Connectedness

I was especially glad that we got $ in there, which is one of my special bugbears. Kudos to Anne Thomas Manes among others for pushing on it.

I jotted down some other areas that seemed to have become important pools of interest during the discussion:

  • control/accountability

  • sharing/interop

  • speed/scale

  • facilitating user-centric innovation/Web as context

    generation Internet/social use of computing

And we must also not forget that this is all made possible by the existence of what you might call firehose connectivity — the unprecedented capability we now have to connect and to publish/consume (the flipside of which is the volume of hype that we have to filter out before we arrive at a real understanding of what's going on).

Spark continues today and I'll publish more later.

posted by Phil Wainewright 5:04 PM (GMT) | comments | link

Friday, January 20, 2006

Why Progress bought Actional

It looks like the market underrated Actional. Its technology is "vastly superior" to that of competitors, Progress Software's CTO Gordon Van Huizen told me yesterday in the wake of the company's latest SOA-related acquisition (although probably not its last, of which more later). But he conceded that Actional had not been winning the battle for visibility, so it was not getting on customers' shopping lists as often as it should have done.

Since customer traction is what counts when valuing companies these days, it follows that Progress has probably picked up Actional cheaply at $32 million in cash and stock. Actional will become part of the vendor's Sonic Software subsidiary, whose ESB product line has attracted lots of customers in the SOA marketplace, many of whom may have only just started to realize they need a management capability. "Over the last six months, organizations have become a lot more savvy about what they're trying to achieve with SOA," Van Huizen told me — one factor in a "rapid uptick" he claimed Actional had seen in its sales success in recent months.

Of course, it's hardly a surprise that Van Huizen would want to talk up Actional's merits. But on the technology, he was able to quote detailed test results that showed Actional's message interceptor does its work in as little as 25 to 50 microseconds, compared to milliseconds of latency with competitor products. In fact, he revealed that it had been quite an education comparing the various vendors' offerings when Sonic set out to make its choice: "I was astounded in the difference in implementations in what seemed to be similar products from a handful of vendors," he said. "In terms of robustness of the architecture, the depth of infrastructure in the Actional stuff is vastly superior."

The Actional product will now benefit from Sonic's worldwide sales organisation and market presence, so if the technology really is as good as Van Huizen says it is, Progress will quickly reap a return on its investment. That's more than you can say of Actional's backers, who over the years have plowed at least $78 million into the company (searchWebServices reports an even higher figure of $85 million). The latest figures I have are as quoted in Loosely Coupled's SOA Management Report 2005: $50 million of funding in Actional before it merged with Westbridge, itself funded to the tune of $15.1 million, and then a further $12.9 million on merger in October 2004. Whatever the final tally comes to, $32 million must be disappointing as an exit sum, although at somewhere in the region of 40 cents on the dollar (assuming all investors are treated equally) it's better than nothing. With any luck, there's also some upside on the Progress stock included in the deal, as the company seems to be gearing up for a new spurt of growth with all its recent acquisitions (it bought legacy-to-SOA specialist NEON Systems last month and event stream processing specialist Apama in April, two product sets that are enhanced by bringing Actional on board).

By the way, as long ago as February 2004, I made this prediction: "I wouldn't be surprised to see ESB specialist Sonic Software acquiring some web services management technology". And as I pointed out back then, it's inaccurate and sloppy for analysts to glibly classify all this acquisition activity as "consolidation." What we're seeing is more a case of vendors buying their way into an expanding market they're eager to exploit — or filling out gaps in their current offerings — rather than existing vendors in a slowing market having to merge because there isn't enough business to go round.

Although positioned as an ESB vendor, I've been arguing for quite a while now that Sonic offers more of a complete SOA infrastructure than just an ESB stack. That's even more the case now with the Actional acquisition, but if Sonic really wants to cover all of the ground then it has to do something now to plug its SOA governance gap. When I put this to Van Huizen, he agreed with me, pausing only to rephrase it as a need for "a metamodel and a repository that can be used across development and runtime environments. That's an area we are hugely interested in further development." Although he went on to say that it's not something Sonic is yet seeing customers asking for in any volume, it's an area the company is investing in, and he agreed that Sonic would be making a move in this area before long. "What we've done is acquire the other pillars. SOA governance is the last one to drop in."

posted by Phil Wainewright 10:22 PM (GMT) | comments | link

Wednesday, January 18, 2006

What should an SOA repository look like?

It's becoming clear that a repository is an essential component in a successful SOA. What's less clear is what a successful SOA repository actually looks like. Is it just an expanded registry, or something else? I've been asking SOA vendors for their views over the past couple of months. The range of replies I've had is illuminating.

Early adopters more or less stumbled upon the need for a repository, without at first realizing just how crucial it was going to be. Recognition of the role of the repository went through three phases:

  1. Denial. Originally, it was thought that a registry, based on the UDDI standard, would be sufficient: Services would just use the registry to seek out matching resources at runtime and consume them automagically. But this early vision failed to take into account issues like contracts, shared meaning, reputation and trust.

  2. Awareness. As enterprises began to build SOAs that linked services from different domains, it became obvious there was a need for some kind of system of record that developers could consult at design time. This would have to provide more information than a barebones UDDI registry was equipped for, and indeed taking into account the need to include documentation and other supporting material, it became evident that the directory-like registry model didn't go far enough. There needed to be some kind of document store with its own defined processes, in other words, a repository.

  3. Acceptance. The more one started to think about what one could do with a repository, the more obvious it became how necessary it was to have one. Not just at design time, but also through deployment, runtime, and on to change time — those moments when a live service needs to adjust to changing circumstances.

The extent to which the debate has moved on through this process was summed up for me when Cape Clear's CEO Annrai O'Toole posed me this question when we met in London in late November: "How should a repository work? Like a database, or like a wiki?"

What's happened is that we've moved from a starting point when it was assumed that all the negotiation would be done by machines, application-to-aplication, to arrive at the conclusion that in fact it's going to have to be done by people, working in collaboration. Instead of looking like a soulless library or asset register, the repository suddenly takes on more of the aspect of a coffee shop, filled with back-and-forth conversation — replete with social context, to use today's lingo.

So began my mission to find out what other SOA specialists thought the repository should be like. I realized that Bill Portelli, CEO of CollabNet, which quite a few large-scale SOA adopters are using to manage development, had already put it succinctly in an earlier conversation: "SOA is really a community development problem." I'd also talked with Flashline's CEO Charles Stack about the company's launch of an SOA governance platform (I'll finally get around to posting that interview in the next few days, now that I've got onto this topic). He summed up the repository's role with the image of a "parts catalog." But it was evident that Flashline's SOA parts catalog takes a very Internet-savvy approach: "We’ve designed our application as a central point from which to popularize reuse," he told me. It lets developers see which assets get used the most, who are the most prolific consumers, and which are the most popular services.

When SOA testing tools vendor Mindreef launched its SOA collaboration platform, Coral, last month, it seemed to me to be positioning the repository as a kind of virtual demo room, where would-be consumers can put services through their paces and check out whether they'll meet requirements. Company president and CTO Frank Grossman pointed out that the context in which the information is presented is more important than where it is actually stored: "Coral is more a tool to front-ennd the registry and repository — the various components might be held in various places."

Early this month, I put the question to Thomas Erickson, Systinet's CEO, in the midst of finding out about his company's acquisition by Mercury. "A little bit like Google or Amazon," he told me, but with the caveat that customers should have the flexibility to choose what works best for them: "Give people basic capabilities they can extend and let them decide how they can extend their specific model." A couple of days later, Frank Martinez, Blue Titan's CEO, called in during a visit to the UK. He said simply, "It should be just like using a browser."

Then yesterday, I saw Marc Benioff demonstrate's AppExchange platform (link to video) and all those ideas suddenly snapped into place. Of course, AppExchange is a showcase for on-demand applications, so it's not exactly the same thing, and it targets end users rather than professional developers or business analysts. But its primary aim is to maximize reuse, and to that end it incorporates RSS feeds that update users on changes to applications or new additions to categories, it presents popularity metrics, it allows users to post reviews and comments, and of course it's searchable in a variety of ways. AppExchange is an excellent example of what an SOA repository should look like.

posted by Phil Wainewright 10:32 AM (GMT) | comments | link

Tuesday, January 10, 2006

Why Mercury bought Systinet

SOA is hot, governance is hot. When Mercury asked customers what their priorities were for SOA, "The first thing they were asking about was governance," Mercury's SVP strategy, Zohar Gilad, told me yesterday. It was unexpected, but on consideration it makes sense, he added: "Customers need to chaos-proof their SOA implementations."

Why was Mercury asking about SOA? "We believe that SOA is the next big shift in IT," said Gilad. "It's definitely becoming the next big shift in IT."

So buying Systinet was obvious, really. Perhaps more intriguing than the question I've led with (and which I'll return to in a moment) is the corollary: Why did Systinet sell to Mercury? Readers of October's Loosely Coupled monthly digest on change management may recall we reported a hint from a BEA executive that the vendor might cement its OEM relationship with Systinet by acquiring the company. Systinet also has an OEM relationship with Oracle, and — as the de facto leader of the SOA governance market — it partners with just about everybody else of any substance in the SOA landscape. So it has probably seen a good number of offers, and yet preferred to stay independent. What was different about Mercury?

The official answer, of course, is that a merger with any one platform vendor might have poisoned those other alliances. "We were a Switzerland of sorts in the way we worked in the SOA ecosystem and we believe it's important to continue that," Systinet's CEO Tom Erickson told me yesterday. "Mercury has a tradition of working with many vendors, including BEA, Oracle and SAP."

It's no use me probing because I wouldn't get any other answer than that, but I can speculate. The first thing that leaps out is the price. According to Loosely Coupled's SOA Management Report 2005, Systinet raised a total of $27.4 million in venture finance, and there's been no word of any further rounds since — the company seems to have had solid enough revenues to fund recent growth organically. So the sale price of $105 million in cash is a very tidy return on that investment, and one that further cements founder Roman Stanek's reputation as a very dependable and insightful tech entrepreneur. One factor that may have contributed to getting such a good price is Mercury's recent NASDAQ delisting for missing filing deadlines — Mercury needed to have some good news to tell.

The timing worked well for Systinet, too. There have been suggestions that the company — even though its dominance of the SOA registry space meant it was well-placed to be a big player in governance — was slightly wrong-footed by the speed at which governance emerged as such a major concern for SOA customers. This was especially evident last July, as I argued at the time, when it announced "Blizzard", a product that wouldn't be ready until the end of the year (and which hasn't yet appeared). Certainly it no longer has the governance field to itself, as I'll discuss shortly. It may have sold at its peak.

Finally, there's the question of the deal itself. Being all-cash, there's no incentive (apart from any earnout conditions that may have been negotiated to keep management in place for a year or two) for key figures to remain at Mercury once the deal is done. Gilad assured me that Mercury will keep Systinet's Prague R&D base in operation, and the business will operate as a wholly-owned subsidiary of the parent. But I still wonder whether Roman Stanek and other key personnel will be there in a year or so's time. Perhaps Roman's already planning some other venture. Who knows?

The final factor, I guess, is whether Systinet's people believe they've found a "good home" in Mercury. I suspect they probably have. Certainly Systinet seems to fit well with Mercury's mission statement of being the primary supplier of "Business Technology Optimization" (BTO) software, despite Mercury's irritating boasts of being the leader in BTO (having invented the category, it would be a calamity to be anything but the leader). The adoption of BTO extended Mercury's reach out of its roots in software testing into application management and IT governance. Registry, Gilad's words, is "a fundamental tool. This is a system of record that is foundational." It completes a four-stage lifecycle picture of registry - validation - monitoring - feedback.

I also pressed Gilad on whether Mercury might have another acquisition in the pipeline to bolster its SOA management capabilities, although this is another question I knew I wouldn't get an answer to. My speculation is that Mercury is considering it, and is not the only vendor in the software testing and application management space that's doing so.

I mentioned Systinet has a few more rivals than it appeared to in the first half of last year, when I compared it with Infravio and could only name a couple other minor players. But the advent of governance has changed the emphasis from registry technology to repository expertise, and that has brought in a number of new players from arenas such as asset management and even software testing. Most notable among them are WebLayers, LogicLibrary, Flashline and Mindreef. I spoke to the latter two companies late last year and have yet to write up their stories, both of which are very interesting. Now that it's become very topical I'll be doing that next week as part of a series of postings exploring the inter-related topics of SOA governance, registry, repository and lifecycle management.

posted by Phil Wainewright 1:10 PM (GMT) | comments | link

Assembling on-demand services to automate business, commerce, and the sharing of knowledge

read an RSS feed from this weblog



latest stories RSS source

Headline news RSS source


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.