Rather than write a Q&A on the subject I am tempted to just ask “why?” and leave it at that.
Mercury says the $105m deal is “to Capitalize on High-Growth SOA Market”.
That’s a good answer for shareholders perhaps, but what about customers and prospects? Which constiuencies are going to be targeted – architects, QA, operations?
It is one thing to buy into a growth story in a well understood market that you already play effectively in (CA’s just announced Wily bid is a good example).
But Mercury here is moving into a new, as yet poorly defined space in this case: Service Oriented Architecture. The acquisition is definitely not business as usual. So what is going on?
Over time we can expect to see increasing convergence between business service and IT service management. Thus, for example, the just announced IBM Registry and Repository will be integrated and merged with the Tivoli Relationship Registry (both will use some of the same underlying technologies). IBM therefore recently acquired Collation as a service discovery mechanism.
While SOA will lead to a future where we won’t know necessarily where the underlying services constituting a business service will run, in order for SOA to be effectively manageable you are going to want to be able to map infrastructure to services to ensure performance across them. I mentioned IBM efforts in this regard above. Microsoft has its own end to end story in the shape of dynamic systems initiative (DSI) and associated manifest.
But this view of the world remains fairly developer focused: the notion of building new services according to a model, build, test, deploy lifecycle. Which is where Mercury’s latest acquisition comes in. Mercury owns QA, it has some traction with operations. It needs more play in the architect space.
Systinet’s view of the world is aggressively UDDI-centred, which will potentially attract architects with XML Web Service mania, that have swallowed the WS-I hype whole, but may not mesh so well with the far broader view of what constitutes a service, and how that service should be managed, that we see in systems and operations management departments.
That is the question Mercury wants to be able to answer most effectively.
Recent Systinet announcements around Blizzard indicate that the firm beginning to widen its view, but as comments on monkchips clearly demonstrate, Systinet’s position has been UDDI-way or the highway. After all, why give customers what they want when you can pitch what suits you best?
Mercury is evidently determined to go head to head with IBM in the service management space. Again, BMC will be watching with interest. BMC should probably put in a call sooner rather than later to Infravio to suggest joint go-to-markets.
Systinet had reseller relationships with BEA and Oracle and a partnership with IBM. Its likely the BEA and Oracle relationships will be sustained through the acquisition but the IBM relationship is likely pretty broken now.
For BEA however the news is not ideal. SOA governance is too important an area to rely on a small player….
So who are some other players in this space?
service management
- BMC
- Microsoft
- Amberpoint
- Compuware
- Segue Software
middleware and SOA
- Infravio
- SOA Software
- Microsoft
- Sun
My final question: What does Mercury Do?
The answer from my colleague Stephen O’Grady – “testing”… that is perhaps Mercury’s problem in a nutshell. It needs a new narrative.
Mercury is making an extremely bold move here. So bold my first reaction was “really?”.
But its going to have to be a masterpiece of execution. And no more Nasdaq delistings.
disclaimer:
—————————————————–
IBM, BMC are clients
CA, Mercury, Oracle are not.
Miko Matsumura says:
January 9, 2006 at 11:21 pm
Infravio are extremely pleased by this event! We compete against Systinet for customers and am happy to see them taken out by Mercury.
Great stuff! Infravio will see much more revenue, partnership and other opportunity in 2006 as a result…
Miko
Anonymous says:
January 10, 2006 at 1:13 am
Based on Mercury’s history of execution after previous acquisitions (especially Kintana, which was part of their big push into IT Governance), a “masterpiece of execution” is not what I would bet on here.
Anonymous says:
January 10, 2006 at 5:48 pm
Accurate observation on UDDI shortcomings. Service metadata management goes far beyond what UDDI offers. Effective runtime access of services requires the service registry to be optimal and UDDI falls short here, again.
james governor says:
January 11, 2006 at 10:19 am
Three excellent comments, two of them anonymous (shame!)
The Kintana point is a good one. Certainly Mercury’s acquisition fueled recent growth seems a little haphazard.
I have been a long time friendly critic of UDDI. its not that it doesn’t have a role to play, but that its only one, optional, element of a SOA approach