Having said this is largely about filling gaps in the IBM identity management portfolio, Encentuate does bring more than ESSO to the IBM table. The company has done a good job of integrating with a variety of strong authentication solutions and has a rather nifty ability to take physical access tokens (door swipes and so forth) so that they can be used as second authentication factors. Encentuate also has some neat audit and compliance capabilities which IBM will undoubtedly tie into the Tivoli Compliance Insight Manager (based on the acquisition of Consul in late 2006). In addition to the technology upside, Encentuate could also help IBM in the healthcare market, where smaller players such as Imprivata and Sentillion have done quite well: there's a good smattering of healthcare customers amongst Encentuate's 80.

Overall a smart acquisition by IBM. I am not so sure whether IBM's Tivoli Access Manager for Enterprise Single Sign-on customers will be quite so happy though. The company has committed to continued support but the next iteration of the product is going to shift from Passlogix to Encentuate. IBM will make it attractive for them to move but replacing identity and security solutions is, by definition, a risky business and I am sure they will have to carefully balance the risks of moving against those associated with sticking with a product which is not going to see further development.

Sxip was early to spot the potential opportunity in providing organisations with a simple, easy-to-deploy single sign-on (SSO) solution for software-as-a-service (SaaS). Sxip Access was its response to that opportunity, combining provisioning capabilities with some Sxip hosted services and an appliance. The company had also cultivated relationships with the likes of Salesforce.com and Google (for Google Apps).

The acquisition of Sxip Access is a smart move by Ping Identity. Although it can be used to provide SSO for SaaS, PingFederate (the company's flagship multi-protocol federated identity offering) lacks some of the rapid implementation and deployment capabilities of Sxip Access. Part of the SaaS proposition is that organisations can get up-to-speed much more rapidly. Authentication and authorisation shouldn't hold you back: something that Sxip Access should help to prevent. Back in September Ping began to actively target the SaaS opportunity, allowing providers to sell PingFederate-based SSO to their customers and share the revenue with Ping. Yesterdays announcement should accelerate this.

(As an aside, I do wonder whether we might see Ping's SignOn.com user-centric identity offering heading in the other direction, given that Sxip is now fairly-and-squarely focused there).

Ping and Sxip, whilst they are comparatively small, punch above their weight when it comes to identity mindshare. I wonder whether this announcement might shake the much larger incumbent identity management vendors, none of whom have really articulated a credible SaaS proposition, into action. It should. SaaS buying decisions often bypass the IT organisation and the business buyers aren't (and in fact shouldn't be) interested in identity management: they want access. If a Salesforce.com recommends that the customer just needs to get their IT department to deploy this box and hook it up to the existing identity management solution so be it. Job done. With SaaS increasing in popularity, particularly in the SME segment where they have struggled to gain a foothold, the incumbents need a strong proposition or lose out to the likes of Ping.

Credentica was founded by acknowledged security expert Stefan Brands, whose team has applied some very advanced cryptography techniques to allow users to authenticate to third parties directly without the involvement of identity providers, whilst preventing the disclosure of personally-identifiable information - in a way that allows accounts to be linked across service providers. It also provides resistance to phishing attacks. Credentica's own marketing literature highlights the synergies with CardSpace:

The SDK is ideally suited for creating the electronic equivalent of the cards in one’s wallet and for protecting identity-related information in frameworks such as SAML, Liberty ID-WSF, and Windows CardSpace.

This is a smart move by Microsoft. Not only does it bring some very innovative and well-respected technology (with endorsements from the likes of the Information and Privacy Commissioner of Ontario, Canada) which extends the capabilities of Microsoft's identity and security offerings; it also brings some heavyweight cryptography and privacy expertise and credibility from the Credentica team. The latter can, and undoubtedly will, be exploited by Microsoft in the short term: the former will take more time to realise with Microsoft stating that integrated offerings are more at least 12-18 months away.

Businesses and public sector organisations offering B2C/G2C services should be following Microsoft's integration strategy closely as privacy becomes a more significant concern (and thus differentiator).

"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."

I remembered a post of Steve Jones' I'd seen a couple of months back about development as a discipline for the masses - and also this one from Jeff Schneider about the value of SOA governance.

You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.

First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).

Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.

Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.

HP is attempting to go that bit further by more tightly integrating the registry/respository capabilities it acquired with Systinet to the policy-based management and monitoring capabilities of its SOA Manager product. Whilst HP also brings other valuable functionality to fill out the SOA pyramid, including business process monitoring (HP Process Insight), security and identity management (HP Select Access) and synthetic transaction monitoring and reporting (HP Business Availability Center) it does not - and nor would it claim to - have everything.

Enter the Governance Interoperability Framework (GIF) it inherited from Systinet. The GIF is designed to facilitate information exchange with the Systinet Registry and Repository allowing third parties to integrate relevant technologies, such as policy enforcement and service orchestration, with the SOA lifecycle management capabilities. As well as announcing 10 new GIF partners, HP is also publishing the GIF specifications.

Integration is not totally reliant on GIF though. Systinet's registry is also embedded in the SOA infrastructure offerings from the likes of BEA, Oracle and TIBCO, which makes HP an obvious potential source of broader SOA lifecycle management functionality for their customers. The company is not such an obvious choice for customers of IBM and Software AG who are building out their own capabilities.

SOA platforms do not begin and end with BEA, IBM, Oracle, Software AG and TIBCO though. There are other choices: Microsoft, Progress, Red Hat and SAP etc. Not forgetting of course that organisations will be acquiring service oriented solutions as part of business applications. What's the story there? There are two. The first is GIF. The second is the HP SOA Registry Foundation that also formed part of yesterday's announcement and which the company describes as

a new software product expressly designed for independent software vendors. HP SOA Registry Foundation is a powerful, standards-based way to publish, categorize and discover SOA services and artifacts. This new product can be easily embedded with packaged applications and distributed solutions.

In other words, it's an OEM-specific version of the registry designed to allow HP to replicate the BEA, Oracle and TIBCO agreements.

Coupled with the HP's services capabilities, these announcements should mean that HP is able to exploit its systems management heritage and installed base to position itself as a credible SOA lifecycle management provider to organisations moving beyond project-level SOA initiatives - and to the software vendors that are helping them on that journey.

In order to test the old adage that a picture speaks 1,000 words, I'm not going to write a whole lot to explain what the diagram is showing: if it's a good diagram then you should be able to work that out pretty quickly. Of course, if I get an avalanche of comments asking for an explanation then (1) of course, I'll post one; and (2) it's not as cute a diagram as I thought it was!

First it's another of what is still a comparatively rare breed of "real-world" adoptions of CardSpace (Otto in Germany, which I commented on back in September, being another).

Second it sees Experian exploiting the wealth of information it has gathered about individuals, together with its relationships with commerce service providers due to its position as the largest credit checking agency in the UK (it claims to process over 70% of all UK credit applications), to position itself as an identity provider.

In a nutshell Experian plans to issue individuals with a 'Experian Card' information card. When the individual visits a CardSpace-enabled site, they will be able to present the 'Experian Card' when challenged to provide credentials and other identity-related data. CardSpace (and presumably non-Microsoft identity selector alternatives, such as the Bandit Project's DigitalMe) would then send a request to Experian to validate the identity and return a signed token to be used by the site to determine whether the individual is who they claim to be.

Having a proof-of-concept is one thing but Experian is in a similar position to the first person to invest in a fax machine. They need others to participate if the technology isn't to languish as just an interesting experiment. Experian, because it is already trusted by service providers, is well positioned to get the identity selector ball rolling and according to the press release is

already in discussion with a number of organisations

and

will be in a position to demonstrate it to organisations, with the ultimate intention of launching an Identity Management Service in the near future.

That's only half the story though. The customers of those service providers also need to come on board. Whilst the wallet metaphor of CardSpace is intuitive, we have all grown too accustomed to the username/password/PIN/mother's maiden name ... approach to authentication and I am not convinced by Experian's claims that

there will be enormous demand for such a service from ... consumers

Rather, I think Experian is going to have to encourage service providers to actively promote the identity selector approach, not least because individuals (unless they are using Windows Vista) are going to have to install CardSpace or a non-Microsoft alternative.

I definitely don't want to pour cold water on the announcement. It's encouraging to see the adoption of "user-centric" (a term that I think is going to bandied about less in 2008) alternatives to traditional authentication mechanisms, given the enhanced usability and security, and I hope we do see a launch with a healthy group of service providers in the near future. Definitely something to watch.

The gap between BPM and BPEL is one perspective from which Cape Clear's recent tie-up with Appian - and Sonic's earlier tie-up with Lombardi - are newsworthy.

BPM initiatives need to be supported by technology that can flexibly integrate existing application, system and information assets into executing process instances. BPM pure-plays like Appian and Lombardi are both frequently tested against larger platform vendors (think IBM, BEA, TIBCO, Software AG, Oracle, etc) and, when standing alone, their integration stories are less comprehensive than those of the big boys.

Conversely, many SOA initiatives are pursued in the context of business process integration and improvement initiatives, and ESB specialists like Sonic and Cape Clear are frequently tested against the larger platform vendors, which on paper can offer more sophisticated support for runtime management of business processes. They certainly have more engineering and marketing resources.

So figuring out that partnerships between BPM specialists and ESB specialists are sensible is hardly rocket science. There are plenty of organisations out there which (for whatever reason) don't want to spend too much money with the big platform vendors, preferring instead to work with specialist suppliers.

What's more intriguing to me is how the separation of technologies forced by these partnerships can actually encourage good practice in "BPM + SOA".

It's often the case, where BPM and SOA tools are presented as part of broad tool suites, that separating business-focused process models from more technical models and service integration models is not encouraged in any meaningful way. Unless you work hard to keep these different models separate, over time artifacts which by rights should remain separate end up bleeding across models and it becomes harder and harder for different teams and stakeholders to remain actively involved in the programme, using tools and models that make sense to them.

By separating business-focused BPM modelling tooling from BPEL tooling and ESB configuration tooling, but still making it easy to link and reference where necessary between models and tools, these partnerships may well help to enforce good practice. It'll be really interesting to see how these partnerships develop, and whether the participants can make 1+1 = 2 (or more). If they can, then I agree with Sandy: these partnerships have the potential to create market-leading positions.

[Another interesting angle, IMHO, to the Appian-Cape Clear tie-up that's not really been picked up is that both companies are active in the area of SaaS. Cape Clear is doing quite a lot of work enabling integration of SaaS and on-premise capabilities for customers; Appian has a SaaS implementation of its technology called Appian Anywhere.]

The ZapThink note starts off talking about the challenges in SOA adoption that come from organisational issues - specifically, challenges that arise from situations where tactical decisions continue to trump strategic decisions. All these are good points well made (FWIW, when trying to educate people about the importance of enterprise architecture, governance, BPM and SOA, we talk about the strategic importance of global vs local business optimisations).

However the note all goes wrong when it goes on to say:

Among the various approaches organizations take to overcome such obstacles, one technique is increasing dramatically in popularity: bringing on board a new executive responsible for the enterprise's SOA initiatives.

The note then goes on to suggest some ideal characteristics for such an executive:

The ideal candidate will first and foremost be a business process guru who also has broad experience in IT. Must have a background in architecture and ten-plus years in increasingly senior management roles. Must be able to communicate to both business and technical audiences. The successful candidate will be part team builder, part evangelist, and part bean counter.

Think of a concrete example of a process transformation - something related to CRM. There's a wealth of salutory tales out there about the folly of driving CRM initiatives (which are process improvement/transformation initiatives) from within IT: CRM initiatives need to be owned and driven by the business. Extrapolating out to process improvement/transformation more broadly, even if transformation of some process areas isn't in the same league as that involved in CRM (and you'd have to argue hard to convince me of that) then I'd still argue that business leaders have to share ownership of process improvement and transformation initiatives. Real BPM cannot be driven by someone reporting to your average CIO - not even by a $200k-a-year uber-architect-cum-process-guru who's equally happy wearing patent leather shoes or pizza-stained trainers.

Of course there is a need to bring people together to push through significant IT and business transformations, such as those required to make the most of the promise of SOA and BPM initiatives. I would wholeheartedly back ZapThink and others in that. But in the real world - particularly in large organisations - people who drive these change programs aren't able to directly push everything, as ZapThink seems to be advocating: they have to be influencers and coordinators first and foremost. Think of an enterprise architect you know. If they're successful, chances are one of their key skills is in how they influence others' behaviour and get different stakeholders working together.

Even if you believe that one role can drive all this - especially from within the IT organisation - then your VP of SOA will be a transitory role. If your SOA initiative succeeds in its mission, then SOA becomes part of the furniture, and when that happens, roles like this one melt into the responsibilities of other, "business-as-usual" roles. If your SOA initiative doesn't succeed, then SOA is seen as yet another over-hyped industry silver bullet - and your $200k-plus hire is now seen as an expensive mistake.

One of the challenges in the growing market for Business Process Management (BPM) technology is the fact that there are many different technology providers bringing tools to the market, and each has its own technology background and heritage customer set with its own expectations. In truth, there isn't "one BPM".

What makes things particularly challenging is that it's very difficult to find a vendor that can truly support a rich range of different types of processes from the perspective of modelling, analysis and optimisation; while at the same time supporting complicated integration requirements. The task is particularly difficult if you're looking for an elegant technology solution with no duplication (some vendors can point to good coverage of all the main functional requirements today, but they can only do this by bundling overlapping and poorly-integrated products and technologies together).

It's a bit of a simplification, but broadly speaking, vendors fall into a "business process specialist" camp, where sophisticated modelling, monitoring and optimisation tools are provided; or a "process integration" specialist camp, where the main centre of gravity is being able to orchestrate services and applications in relatively sophisticated ways. The smaller, specialist vendors (such as Lombardi, Pegasystems, Singularity, Appian) fall into the former camp; the larger, generalist vendors (such as IBM, Software AG, TIBCO, Oracle) fall into the latter camp. Interestingly, BEA (and also TIBCO) actually span the camps as they've both bought pure-plays as well as having integration-centric backgrounds.

Next spring we'll be launching a major research programme looking at the discipline of BPM and the technology you need to support it - but until then the most pithy advice I think that can be given to an organisation looking to purchase BPM technology is:

Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the work - is it business people, IT people or both?

Unfortunately, getting to the bottom of things is not as simple as saying "I need a human-centric BPMS" or "I need an integration-centric BPMS".

But let's take a deeper look. Quite aside from the role that one of these beasts plays (something I'll attack in a future post), what does a best practice CoE look like?

From what I've seen out there in real-world implementations of SOA and BPM initiatives, I suspect that the best results come from having a good mix of responsibilities / personalities in the group. Something like an even distribution across this matrix of perspectives:

Although it's tempting to staff a CoE with good dependable technical people that you understand, you need a good mix of business-focused types and technology-focused types, because those business-focused types will help keep expectations practical, and help keep business people from outside the CoE engaged and willing to help. And it's vital to get a good mix of practical and visionary focus, because rolling out new concepts and approaches to delivering IT capabilities requires both "selling" and getting things done.

That's my view. What do you think?

do 'managers' belong on the list of knowledge workers whose jobs are being transformed by information technology?

His question is prompted by a number of interesting examples of the use of IT in areas such as "fluid" building fabrication, sculpture, BMW car design and poker playing. He then goes on to describe, based on the experience of his course teaching, that most general managers do not believe that IT can help them in their roles as leaders, change agents and value generators because:

until fairly recently the profession of general management was actually not one of the ones deeply affected by technology. Prior to the mid 1990s the footprint of most corporate IT -- the sphere of direct influence for a piece of technology -- was the single function or task. This made for a happy marriage between technology and knowledge workers like engineers, scientists, and analysts because these workers stayed within a single function. But general managers, by definition, do not. They're responsible for orchestrating the work of multiple groups. So from their perspective, IT was actually delegable and low level.

This chimes well with some of the points we raise in our March 2005 BPM report (which will be updated next month). In it we highlight that much of IT discussion of business process is actually about the shadow that IT automation casts on real business processes. The real world of business processes is much more complicated than would appear to be case based on what IT can support. There are business processes which serve to differentiate the business and there are those that are a cost of doing business. There are business processes which support day-to-day operational activities (or single functions or tasks as Andrew refers to them); there are those that support management of those operational activities; and ultimately there are those that govern strategy.

IT has historically played a prominent role in support the non-differentiating, operational processes. That role is significantly diminished when it comes to differentiating, management and strategy processes because they are more ad-hoc and collaborative and nature and depend on harnessing and exploiting a wide variety of applications and structured and unstructured information assets.

Andrew believes that the emergence of ERP and the Internet has enabled a new class of business process automation which operates at the level of the organisation and so are more suited to management processes. He also believes that "Enterprise 2.0" technologies (which Angela discusses in the broader context of enterprise collaboration in her recent report), by virtue of their emergent characteristics, promise to do the same and concludes that he is:

comfortable adding 'general managers' to the list of knowledge workers who have very powerful digital tools at their disposal, and who need to learn how to use them well. Does this also seem right to you?

His historical analysis of business process automation certainly seems right to us and we believe that a range of new IT capabilities have the potential to shift IT's supporting role in the direction of differentiating management and strategy processes. However, it's not just about managers learning how to use them well. As we highlight in our BPM and collaboration reports (and more broadly in our analysis of IT-business alignment), these management competencies must also address a broad range of organisational, cultural and governance challenges if these innovations are to fully realise that potential.

As with many things identity management, it's primarily driven by compliance, with a small helping of increased operational efficiency and cost reduction. As well as promising to streamline the provisioning and de-provisioning of entitlements, roles can help organisations to define, enforce and demonstrate those entitlements to address regulatory compliance demands.
The realisation of that potential, however, has proved elusive. Organisations have struggled to identify (!) the roles that they need, and inconsistent management approaches have often resulted in an explosion of roles to the point where there are as many roles as users. The likes of Bridgestream, Eurekify and Vaau, whose offerings provide role discovery, analysis, allocation and provisioning, emerged specifically to address these challenges, creating the identity management sub-market of ERM along the way.

With compliance top-of-mind for many of their customers and prospects, the major identity management suite vendors who were unable to respond as rapidly as the nimble ERM start-ups quickly established partnerships and, in some cases, moved beyond the press release to actually provide pre-built integration. Sun, for example, provides bi-directional data integration with Vaau (which should help to speed up the integration process). With two of the leading ERM players now with competitors, this leaves the likes of CA and IBM in an interesting position. Their partnership teams no doubt have their eyes (and potentially their wallets) pointing in the direction of Israel, where Eurekify is based.

Some of you may wonder why I didn't include Novell in this list. Had I been writing this post straight after the Sun announcement it would have been. But not long after the announcement I came across this post from an identity management group blog at Novell, which discusses how the company has been building its own role management capabilities, focused on role provisioning, exploiting its directory heritage (discussed in more detail in our assessment here) and partnership with Eurekify for role discovery and analysis. The post's author claims no knowledge of acquisition talks. Then lo and behold, and far be it from me to suggest that Sun's announcement had anything to do with the timing, the next day Novell announced its new Roles Based Provisioning Module.

Of course, a Eurekify acquisition by Novell could still be on the cards, despite the blogger's ignorance of any such discussions, but it seems to me based on Novell's stated strategy that the Israeli company is more likely to end up in the arms of CA or IBM.

The implications for customers are varied. Bridgestream and Vaau customers, who have plumped for a vendor other than Oracle or Sun, should be a little nervous and seeking concrete assurances regarding ongoing support. Customers of the likes of CA, IBM and Novell who are considering ERM will have to think very carefully before plumping for Bridgestream or Vaau for similar reasons.

that it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.

This acquisition has been long-discussed so I can't say I find the news particularly surprising, particularly with Carl Icahn recently upping his stake in the company. I think this just makes it more likely that Oracle's proposal will be accepted.

This is primarily as a market share grab by Oracle. It does plug some gaps in the portfolio - particularly around business process management (based on BEA's Fuego acquisition), where Oracle only has basic BPEL web services orchestration; adds some telecoms vertical market capabilities to complement Oracle's vertical market push and the virtualisation work that BEA has done with the WebLogic Virtual Server Edition. Also, there's the opportunity for Oracle to tap into the healthy Tuxedo base. With a significant chunk of Oracle's profitability coming from maintenance, the revenue from BEA's customer base will suit its business far better than it did BEA which was suffering with its inability to grow license revenues.

This is yet another example of the bigger specialist players getting squeezed out by the industry goliaths - IBM, Microsoft, Oracle, SAP - and the open source, smaller best-of-breed players. SAP's recent acquisition of Business Objects is another example (although that did plug a few more gaps). It leaves some of the other bigger specialist players - TIBCO, SoftwareAG (and to a lesser extent Progress and Red Hat) in an interesting position. On the one hand they will be more attractive, particularly for SOA and BPM, to customers looking for an application-independent infrastructure offering. On the other, though, taking market share for those customers from BEA is one thing: taking it from Oracle quite another. Ultimately, IBM is the big beneficiary in this regard.

In summary, then, I see: the acquisition going ahead; BEA's customers looking worried as they see themselves with an application-dependent infrastructure stack; IBM looking happy at the prospect of providing those customers with an application-independent alternative; the likes of TIBCO and Software AG pondering their options; and SAP and Microsoft carrying on in there own sweet way.

popularity is entirely on the provider side. There are no consumers of note.

and that CardSpace:

appears to live in its own little world, supported only by Microsoft products

I think this is to be expected given that we are still in the early stages of both.

Where I find myself disagreeing with Ben, however, is with his conclusion about CardSpace:

So why does this make Cardspace like Passport? Well, the fear with Passport was that Microsoft would control all your identity. The end result was that Microsoft was the only serious consumer of Passport. When Cardspace is deployed such that all providers and consumers of identity are really the same entity, then all its alleged privacy advantages evaporate. As I have pointed out many times before, when consumers and providers collude, nothing is secret in Cardspace (and all other standard signature-based schemes). So, there?s no practical difference between Cardspace and Passport right now.

Ben's right about the implications for privacy when the those consuming identity information collude with those providing it but that's not an issue peculiar to CardSpace.

Even Microsoft would (and indeed does) agree that Passport was a failure due to the company's control of identity data, I think Ben doesn't tell the whole story. It wasn't just down to control of an individual's identity data. It was also due to the fact that Passport and Hailstorm were designed from the outset to wrest control of identity data from Microsoft's business partners and customers. The same can not be said of CardSpace and that's why I believe there is a difference between CardSpace and Passport. There are already examples, Otto in Germany springs to mind, of organisations other than Microsoft using CardSpace and, as I said, it's still early days.