HP acquires Trustgenix: no great surprise
HP today
announced the acquisition of Trustgenix Inc, continuing both its own recent acquisition spree (following those of
AppIQ,
Peregrine, and
RLX) and the consolidation in the identity management market (following Oracle's
recent acquisitions of OctetString and Thor Technologies).
This is hardly a shock. HP already OEM's Trustgenix' IdentityBridge, which it rebrands Select Federation, to provide federated identity management within HP's OpenView Identity Management Suite. And, whilst Trustgenix is certainly one of the leading specialist providers of federated identity management solutions, it seems unlikely given the land grab that is being made by the leading infrastructure and management vendors, that even a highly capable pure-play vendor could survive as an independent.
The press release left me with a couple of questions but we were sadly not privy to a briefing to ask any questions.
HP states
"Upon the closing of the acquisition, HP plans to integrate Trustgenix and its software solutions into the HP OpenView management software portfolio. The acquisition will allow HP to rapidly extend the federation capabilities of HP OpenView, enabling enterprise customers to help their business partners secure access to information residing on different systems." Now, as far as I can tell, IdentityBridge is already integrated into the HP software portfolio and offers federation capabilities, so I am at a loss to tell what additional value this will bring to customers. Rather, it seems to me that this is primarily a defensive move, to prevent someone else from snapping up Trustgenix - both Entrust and CA (through its acquisition of Netegrity) are also strategic partners. Which leads me to the second question: where does this leave those partnerhips?
One thing that this does bring to HP, which it chose not to mention in the press release, is the fact that TrustGenix has a specialised Carrier Edition of Identity Bridge which is targeted at wireless operators. This is obviously an important vertical market for HP with it's specialised telecoms software offerings, such as its
OpenCall and
Service Delivery Platform.
So, all in all, nothing terribly surprising and nothing, at least on my initial reading, that is going to have a significant impact on identity management market. HP does gain control of an important element of its identity management offerings and potentially bolsters its offerings in a key vertical market.
Just how flat is the world of IT, anyway?
Here at MWD Towers we get a daily newswire update in our inboxes, to ensure that we catch all the news from the major players in the IT industry.
On both Nov 21st and 22nd, as is about usual for an average day, we received notification of 14 news releases from the usual suspects.
On Nov 23rd - there were 2.
Today - 1.
This made me think two things:
1) "Wow - you can tell it's Thanksgiving week", shortly followed by
2) "Wow - you can tell just how much this industry is dominated by US companies."
Microsoft takes file formats to Ecma - but what about the ultimate beneficiaries?
Microsoft today announced, together with an assortment of other vendors and its own customers, the establishment of an
Ecma International technical committee to standardise the Microsoft Office Open XML Formats, which the company introduced as the
new default file formats for Office "12" in June this year. This is not the first time Microsoft has turned to the 44 year old, Swiss-based standards organisation. It was
5 years ago, together with HP and Intel, that the company co-sponsored the submission of its Common Language Infrastructure (CLI) and C# programming language to Ecma, which were ratified as standards ECMA-335 and ECMA-334 respectively within 18 months.
The company also announced significant changes to the licensing terms associated with file formats and a commitment, emulating that made by Sun in September around the
OASIS Open Document Format standard (described
here by the company's open source czar Simon Phipps), not to enforce relevant patents, which the company claims will remove the obstacles (nicely summarised
here by
David Berlind over at ZDNet) that prevent their implementation in open source software (including that licensed under the GPL).
In our discussions with Jean Paoli, Microsoft's
cup-winning XML architect who is credited as one of the driving forces behind his employers embrace of XML since joining the company in 1996, he was at pains to point out that these moves are a continuation of Microsoft's 7-year effort to promote interoperability and foster a broader development community around Office that's been going on since the (albeit limited) support of XML file properties in Office 2000 - and not a response to the much-discussed, politically-charged file format debate raging in Massachussetts (plaudits to David Berlind once again for some excellent reporting
here and
here). Jean claimed that the timing of the announcement is coincidental and a result of the need to wait for the file format to become sufficiently stable, heralded by the
first beta release of Office "12".
Frankly, I don't buy this. There is a long way to go before Office "12" is released and the file format could change as a result of beta testing. Microsoft could have announced its intention (and would have benefited from a PR perspective) to standardise the file format back in June - and anyway, stability of the file format has very little to do with the ability to make technology licensing changes.
There's little doubt in my mind that Microsoft is feeling the competitive heat from ODF (and the wrangling in Massachussetts has only served to raise the temperature gauge a few notches) and these announcements are an attempt to cool things down. So, how effective will they be?
By opening up its previously closely-guarded file formats, Microsoft had already been moving in the right direction to address concerns about vendor lock-in. However, opponents could justifiably claim that the company had not gone far enough, since future development of the file format remained a Redmond responsibility, giving Microsoft too much control and stifling innovation. With the Office XML formats now under the control of an Ecma committee, such criticisms seem more difficult to justify.
There are a couple of other noteworthy aspects to the Ecma standardisation effort. First, Ecma has an agreement with the International Standards Organisation (ISO) through which it is able to submit its specifications to ISO's Fast-Track process (both C# and the CLI became ISO standards within 18 months of becoming Ecma standards). Assuming Ecma takes the same path with the XML file format, it will become an official standard. ODF, whilst undoubtedly an open standard is, as David Berlind points out
'on it's (sic) way to being a de facto standard' since
'OASIS officially isn't a standards organization like the American National Standards Institute or the International Organization of Standardization (ISO) are'. Second, Microsoft will point out that is addressing the needs of the ultimate beneficiaries of standardisation through the participation of organisations such as Barclays Capital and the British Library in its submission to Ecma, and will contrast that with the makeup of the
OASIS Open Document Format technical committee, which (with the exception of 3 individual members) is populated exclusively by vendors, comprising members from Adobe, IBM, Intel (interestingly participating in both standardisation efforts), Novell and Sun Microsystems.
The changes to the licensing terms, coupled with patent amnesty, appear (
Disclaimer: I am neither a lawyer nor an expert in open source licensing) to address the concerns of the open source community. No doubt, this will be subject to much debate and scrutiny in the coming days and weeks.
By my reckoning, this announcement certainly furthers Microsoft's stated aims of promoting interoperability and fostering a third party development community around Office. At the same time, whether it's Microsoft's stated objective or not, it also serves to help level the playing field with ODF.
Ultimately though, it's important not to lose sight, amidst all the politicking and vendor positioning, of the reasons for this debate in the first place. Organisations, especially those in the public sector, need standards to faciliate interoperability and ensure that their employees, customers, partners and citizens, are able to access information now and in the future without being beholden to particular vendors and technologies. As long as there are competing standards, they are left in an invidious position. If they opt for ODF, will they have access to all of their legacy documents? If they opt for the Office Open XML Formats (or whatever ECMA-XXX standard it becomes), will there be alternative suppliers offering equivalent functionality or will they remain beholden to Microsoft?
This beggars the obvious question. If Microsoft, as it claims, has the interest of these organisations at heart, why not support ODF rather than promoting an alternative standard? Ray Ozzie is
reported as claiming this is down to resourcing issues, but the company has shown it can marshall its resources in response to customer requests. The recently announced
support for PDF is a case in point, with Senior VP Steven Sinofsky stating
'The Save As PDF technology represents a direct response to our customers, ... Requests for PDF functionality in Office represent the #2 request when customers interact with our worldwide support organization. Every month we receive over 120,000 queries worldwide for “PDF” through Microsoft Office Online.' Couldn't Microsoft do the same with ODF?
I doubt it - Microsoft would almost certainly point to concerns about backward compatibility, which is definitely a concern to customers. Claims about backward compatibility are more difficult to refute, without access to the closed formats. However if ODF-based solutions can demonstrate complete backward compatibility with Office formats then Microsoft won't have a case. So what then?
Well, there would be a follow-up argument about "loss of fidelity". Microsoft would claim that the ODF format is insufficient to support all of the functionality which Office provides. The ongoing
debate (thanks once again Mr Berlind) in Massachusets around access for the disabled highlights the complexity here. How much of the accessibility functionality is down to the file format versus the application? As David points out:
'If the lion's share of a document's accessibility to the disabled is largely independent of its file format, then many of Microsoft Office's accessibility features that are accessibile to documents stored in Microsoft's formats become would be accessible to documents stored in ODF. If this is the case, the dispute about ODF vs. the Office XML Reference Schema must yield the spotlight to bigger question of whether or not it's the state's decision to standardize on ODF that's allegedly intefering with document access for the disabled, or is it Microsoft's refusal to support ODF with its "accessibility tool" (Microsoft Office) that's getting in the way'So, where does that leave things. Microsoft, whether pushed to or not, has taken a further step in opening up its file formats and seemingly relinquished control of their ongoing development. At the same time, the company appears to have put the Office Open XML Formats on a level footing with ODF. But the situation for organisations needing to exploit files based on those formats is no clearer. We certainly haven't heard the last of this debate.
Business process confusion: once more unto the breech
I really like most of Ross Mayfield's stuff on
Many2Many. But in
The End of Process (as
here, which I
commented on previously) I think he's getting a bit carried away.
The piece actually replays many of the points that Ross made back in May, which I disagreed with then and still disagree with. The central argument in this piece seems to be that the processes that companies follow today often deliver poor results - and that if social software can live up to expectations, the role of process will change forever. For example:
Today, some staid corporations are abandoning process all together (I wish I could quote the source for this). Google is a more public example, albeit an exceptionally new large enterprise, where wikis and weblogs enable a culture of working openly in a flatter and decentralized organization.
Don't tell me that Google is abandoning accounting processes, corporate governance/regulatory compliance processes, HR processes, etc. Do you think that Google hires people based on what existing employees write in an open wiki? I very much doubt it. Ross is falling into the same trap as he did before - looking at the shadow that business processes cast onto today's structured IT systems, and focusing on that.
Ross, take those blinkers off! The universe of business processes is strange and wonderful: and social software is just as capable as providing structured support for some business processes, as transactional (eg ERP) software is capable of providing support for others. Some business processes are 80% or more about creativity - and others need to be 80% or more about repeatability. That's a fundamental fact.
This argument:
John Seely Brown and John Hagel point out that while 95% of IT investment goes to support business process (to drive down costs), most employee time isn't spent on process -- but exceptions to process.
Is fundamentally flawed. Just think - let's assume that the 95% of IT expenditure which is allegedly spent on automating processes, went away - that there was no process automation. What would happen then? Would people spend most of their time just managing exceptions, as they do now? Of course not - they would spend all their time doing tedious, repetitive work. The *reason* that people spend most of their time exception-handling, is that technology is automating most everything else. Ross is getting the causality the wrong way around here.
Also, Ross says:
Assume for a moment that the 25% of GDP that is search costs falls. Or the 50% of GDP that is transaction costs similarly declines. ... If a knowledge worker has relevant information at their finger tips, can form the right group to handle an exception, leverage the social context of information and contribute to memory as a natural by-product of getting work done -- what is the role of process?
Come on Ross - what do you think has driven transaction costs and search costs to decline? Process automation. Without automated processes fuelling the creation and maintenance of content and systems now exposed on the web, and without straight-through financial processing, where would we be?
Lastly:
My favorite Clay Shirky quote is "process is an embedded reaction to prior stupidity." That is, there was an exception to process and an expert designed a way for people to work together in one context that should fit all prior contexts. The problem is, the process becomes calcified and accepted as the rule. After all, it's a rule, and in corporations we follow them, even if it fails us or simply doesn't make sense. Because of constant change in our environment, processes are outdated the immediately after they are designed.
In the end, my belief is that Ross is right about the uselessness of some of our implementation and credo surrounding business process. But improving the situation is fundamentally a question of IT-business alignment, IT governance, and enlightened understanding of how the whole universe of business processes can be supported by different types of technology - it's not a question of
throwing out the baby with the bathwater.
EITM is to CA, what On Demand is to IBM
I’ll be publishing a fuller report on CA’s reinvigoration next week, but in the meantime I wanted to share this observation as I think it says a lot about what John Swainson is doing at CA, and in general, the value of a good idea.
The parallel between EITM and IBM’s "
On Demand" vision and strategy comes from the fact that CA’s EITM vision, like On Demand has been for IBM, is as much about rallying the troops internally around a core idea and driving synergies between different capabilities, as it is about telling a new story to customers and prospects. Having
reorganised CA to a business unit based structure that aligns product development to sales and marketing in CA’s strategic lines of business (enterprise & systems management, security management, storage management and business service optimisation) EITM is a way to now make sure that the whole CA proposition is greater than the sum of its parts.
The power of the "rally the company around something that customers can buy into, which will also help us to get things working better internally" idea, which has already brought IBM a heap of benefits, is just one reason why I think the majority of analysts and journalists are coming away from CA World with positive jottings in their notebooks.
Of course CA has "cried wolf" about product integration before (
here's a report of one example), and this time the scope of its ambition is an order of magnitude bigger - so now the focus has to be proof, proof, proof.
Why "users" is a dirty word
I want to ban the word "users" from our (that is, the IT industry's) vocabulary - in the same way that others want a
moratorium on the use of the word "consumer" in the context of ISP connectivity. In time, I'd like to see it disappear from the vocabularies of organisations' IT departments, too. Why? Well, it seems that a lot of people are spending a lot of time thinking and talking about "IT-business alignment" (we're among those who think the most about it, I would hope). But how many of us can be really serious about helping close the gap between business and IT, while we still deliver technology solutions to, and seek the "acceptance" of, "users"?
Let me take a step back.
The idea that language shapes behaviour is hardly new - just take a squint at "
linguistic determinism". It has long been argued that the language we use, shapes the thoughts that we tend to think (unsurprisingly, the same is also thought to be true of programming languages). I'm a firm believer in this idea - and in my book, that means that there are two big things that are wrong with (particularly casual or lazy) use of the word "users".
Firstly, referring to "users" reinforces the idea that a tool is created by IT, and then it is turned over to a group of individuals who use it. This reinforces the idea that the IT organisation is a provider of tools. If we're trying to align IT with the business, this is wrong. The IT organisation needs to be thought of as a service provider, working in collaboration with the business to maximise the utility and value of all the amazing technology and skill that exists.
Secondly, increasingly it's becoming apparent that the real value of IT within a business context has got very little to do with the specific relationships that individuals have with a particular piece of technology. Rather, the value comes from the way that technology can provide structured support for a business activity or process, in which individual businesspeople are actors playing roles. So focusing on individual "users" can make people miss the point.
On top of this, through interest in web services and SOA, increasingly the consumers of technology services aren't just individual people. Increasingly, software systems have to interact with other systems in order to support business processes - as well as interacting with businesspeople.
So: don't ask whether "the users" "accept" a system that's been delivered. Ask if the system delivers value to the business. And next time you hear someone (or hear yourself) saying "the users just don't understand
[insert your favourite IT project or issue here]" - replace "users" in your mind with "the business". Or even replace the word with "the entity that generates the revenue to pay my salary". And then think again.
Clarifying the ESB (NOT!)
I just came across the following article at
SearchWebServices which references a number of proponents of ESB (take a look
here for the other Neil's thoughts on that particular TLA du jour) and the JBI (
Java Business Integration) specification making, in my humble opinion, a number of dubious claims. For example, "We see JBI as the basic requirement for creating an ESB," and "When we first set out to create JBI over two years ago, we had a vision that one day JBI would help drive the shape of ESBs, much like the EJB spec drove the shape of application servers in the late '90s."
Now I could be wrong - and I am happy to be corrected - but it seems to me that JBI doesn't, contrary to the title of the article, help define an ESB and is certainly not the basic requirement for an ESB. Rather, combine a service bus with pluggable business integration components (based on standardised service provider interfaces) and don't you get a pluggable EAI solution - and a Java-only one to boot. But hold on ... isn't that where the likes of
Cape Clear,
PolarLake,
Sonic and others started in the heady days of web services euphoria: offering web services-based, lightweight EAI solutions.
This smacks of techno revisionism from the ESB crowd!
IT-business alignment, and the four levels of SOA capability
Having done quite a lot of research and analysis around how SOA can improve IT-business alignment if "done right", it's become apparent to me that organisations think and talk about the ability of SOA to improve IT-business alignment from four perspectives. The perspective they use, depends on the amount of time they’ve had to work with the concepts and the technologies involved. This appears to be true for both suppliers and users of IT!
The capabilities they refer to form a kind of “stepladder”, with each capability providing a foundation for the next.
(
By the way, I know that ZapThink also talks about four benefits in the context of SOA: reduce integration expense, increase asset reuse, increase business agility, reduce business risk – but I think these are different. ZapThink’s perspective is about what SOA can do: this thought is about how SOA can do it.)
The four capabilities are – from the “bottom up”:
Improved flexibility. This is one of the most-talked about potential capabilities of SOA, and it is the first one that most people consider. Flexibility of course concerns the ability of solutions to be altered in the face of changing business and technology requirements, and is boosted by the loosely-coupled nature of the services which are composed to meet solution requirements in a SOA environment.
Large-scale reuse. Along with flexibility, reuse is the other commonly talked-about SOA potential capability. With effective service-based solution design efforts in place, IT delivery organisations have the potential to build up libraries of business-meaningful functionality. These libraries will not be tied to particular usage scenarios, and (crucially, unlike earlier attempts at object-based reuse) are easily composable and re-composable to meet new business requirements; and can be hosted remotely or locally. With these libraries, organisations can reduce the investment required to address new business software requirements; make delivery of new solutions quicker and more reliable; and also improve the accuracy and speed with which solutions can be changed.
Improved comprehensibility. Successful SOA initiatives create groups of services which can be clearly linked to individual tasks within business processes, as well as lower-level technical services. In other words, strong service portfolios have many key elements which are easily comprehensible to business audiences (examples might include services which manage customer information, or which validate orders). Software comprehensibility is not often talked about as a benefit of SOA, but it has a massive impact on the ability of a SOA initiative to improve IT-business alignment. When software functionality is easily comprehensible, it is much easier to build a
common language between business and IT – which makes it easier to engage business stakeholders in real investment discussions and solution design work; and to show how particular “pieces” of software contribute to business activity
Improved value visibility. Beyond providing more comprehensible software solutions, successful SOA initiatives also have the potential to increase the visibility of IT’s value to the business. At the heart of this possibility is the fact that the idea of a “service” is both a business-meaningful unit of software design when a solution is being conceived and built; and a business-meaningful unit of reporting when a solution design is in production. With SOA, organisations have the ability to clearly relate the production of solutions in an IT environment, to the operation of solutions in a business environment. Together with the promise of comprehensibility, the visibility that an SOA initiative brings enables business stakeholders, administrators, designers and developers to share a common view of solutions
which makes sense to all of them. This has implications for improving the “business-alignment” of IT investment and IT service delivery, and for the co-operative management of change.
Moving from one step to the next requires a change in thinking as well as the utilisation of different technologies. As you move towards thinking about "value visibility", your thinking and approach to SOA has to change from one predominantly focused on software development concerns (which is where most people are today) to one focused on the entire delivery lifecycle.
If anyone’s got any comments or thoughts on this, I’d love to hear them – plaudits and brickbats are both welcome.
