Experian partners with Microsoft to develop an identity selector proof of concept
Perhaps it's because we're in the run up to the holiday season or because
the press release came from the UK that accounts for the lack of commentary on the announcement that Experian has developed a CardSpace proof of concept with Microsoft. This is notable for a couple of reasons.
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 ... consumersRather, 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.
Labels: Bandit, CardSpace, Experian, identity, Microsoft
Pure-play partnerships: helping light the way to BPM + SOA?
Enterprise Service Bus (ESB) players often talk about their ability to support
BPEL, and this is often mistaken for
BPM support. But BPEL is a misleading beast (as I've blogged about
previously). It's not a bad technology for helping IT folks with declarative specification of service-to-service integration processing, but it's not the same as BPM. This is often overlooked, and is where a good deal of the
confusion surrounding BPM stems from.
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.]
Labels: Appian, BPEL, BPM, Cape Clear, ESB, Lombardi, sonic
Please don't hire a VP of SOA
This might sound like an odd title for a post, but I was prompted by this
ZapThink ZapFlash, via the ever-watchful
Todd Biske.
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.
Really? I haven't seen that. If some organisations (maybe US based ones?) are doing this, I hope they're more focused on business transformation than on IT implementation - and that SOA isn't in their job title.
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.
Although it's slightly off the topic of this post, I wonder how many people fitting this description are out there? If SOA success relies on you hiring someone with all these capabilities, then I think we're going to see a hell of a lot of failures. This is where I get seriously worried though:
This position reports directly to the CIO with dotted line responsibility to the COO, and will be responsible for a seven-figure annual budget... job responsibilities include:- Provide executive-level management leadership to all architecture efforts across the enterprise. The directors of Business Architecture, Enterprise Architecture, Technical Architecture, Data Architecture, and Network Architecture will all be your direct reports.
- Drive all Business Process Management (BPM) initiatives enterprisewide. Coordinate with process specialists across all lines of business, and drive architectural approaches to business process.
Ummmm... so this role reports to the CIO, but drives all BPM efforts across the company? Even though the note says
"even though the VP of SOA reports to the CIO, the role is primarily a business role" this is pure fantasy. Unless you're in a small-to-medium business it's just not practical to make this happen.
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.
Labels: BPM, SOA, toddbiske
