Thursday, September 19, 2024

Identity Federation: The Backbone of On Demand

When we understand that the key principle of On Demand is ‘straight through processing’, where business processes can execute in their entirety across multiple systems in multiple companies instanteously, in ‘real-time’, we can clearly see that the keystone to On Demand is Identity Federation. It provides the platform to achieve this through engendering a singular semantic architecture that can be used to consistently describe and therefore integrate workflow.

On Demand is as it says: Give me what I want when I want it. For example, if I am watching On Demand TV and my customised advert offers me a test drive of the new Ford, then I just want to press a button here on my remote control to book it. I don’t want to phone a call centre, and I definitely don’t want to fill in a form specifying my personal details. I want it On Demand.

Eliminating repetition of common information and services is the mantra of On Demand, because it tackles the core enemy of fluidity: Complexity.

Have you noticed how any time we want improved operations, we add more systems and processes. More technology, more money, more EAI. In other words, when seeking greater simplicity we actually increase complexity, which goes a long way to explaining why so many large IT projects fail to deliver their stated objectives and go way over budget. There is simply too much to manage to make it effective in the fast changing real world. Therefore a whole new way of thinking about IT strategy is required, a completely different approach to how we go about buying, implementing and integrating enabling applications and infrastructure.

This new way is On Demand, and its backbone is Identity Federation.

With straight through processing of workflow across an entire ecosystem of business partners being the goal, the role of EAI (Enterprise Application Integration) is obvious: These systems must all ‘speak’ to one another to communicate the information required to fulfil the business process. Whenever there is an ‘air gap’ between two required systems, then the process must drop out of real-time and be manually marched around the office and re-typed into new systems to continue the sequence. The Real-Time Enterprise grinds to a halt and goes back to being the Slow-Time Enterprise. “I’m sorry sir, I can’t see any information about the status of your order on our system yet” becomes the phrase you must train your customer service staff to use frequently. That and “oh sorry, the system seems to be running slow today”, but that’s another story (which will be covered).

So with all the huge budgets spent on EAI how come we don’t have all of our applications happily communicating with one another? Why is systems integration a continually failing practice?

It is mainly due to the continual acquisition of new applications to enable new workflow, and the use of ‘point to point’ integration methods. This refers to the fact that Siebel is integrated directly with SAP, with the e-business web site, the back-office and the HR system. SAP is then also directly integrated with the e-business site, the … and so on. Each system speaks directly to another. Each connection requires its own development and maintenance, and thus managing interfaces becomes another dimension expanding the complexity of managing all the business systems in a coherent manner.

But yet, when we abstract ourselves from the spaghetti, what do we see? Well, the absolutely critical point is one of semantics. The core problem is that SAP uses a different data format to identify and store information about [The Customer], than that used by the Siebel system and that used by the e-business site. Each is using its own formats, methods and technologies to represent this entity, so when communicating information about [The Customer] between systems translation is required so that mutual understanding is possible. It is this translation process that causes us so much heartache.

Therefore to tackle complexity we need simplicity, and what could be simpler than: Well, why not just have everyone use one single format for [The Customer]?

If we all maintain the information in our own systems according to a singular, universal method, then we never need to create another direct point-to-point connection with another system again. Any application that connects to this information bus via the agreed, shared standards can then be communicated with by any other system on the same network. No more EAI, every again.

This concept is achieved via Identity Federation, the framework for multiple different networks uniting around the practice of maintaining a consistent version of shared information. An Identity Federation is a collective group of entities (technology, people and companies) who agree (form a union/federation) to formulate a single semantic representation of a shared service. Identity is the keystone service, because without it nothing else can happen. You can’t use anything if you don’t know who or where it is on the network, so network identity is naturally the building block from which all other processes and composite applications will be built.

How is this relevant to On Demand?

Consider the On Demand TV advert example:

The consumer, presented with the customised advert (derived from his federated identity profile) is offered the booking of a test drive simply by pressing the red button on his remote control.

Pressing the button then initiates a workflow sequence where the end-result is the CRM system of the local car dealer being populated with the contact details of the consumer so they can call him the following day. All this happens in real time through a series of Web service calls across all the networks involved: The Digital TV provider, Ford and their e-marketing systems and the CRM system of the local dealer. Yes this could be achieved by traditional EAI, connecting all of them directly to one another, but this is usually prohibitively expensive and complex when factoring in the numerous small organisations such as the car dealers who likely use low cost applications.

In contrast, a federated identity approach achieves a liberating ‘develop once, use many’ platform. Each system, once connected to the identity network becomes aware of information changes and reflects them in their own applications, allowing the definition of business processes that span across this meta-level without worrying about the underlying components. In this case, the request [Book Me a Test Drive] is a concept agreed and understood by all the systems so the actions can be taken by all involved to achieve this objective, On Demand. Obviously everyone has to know who ‘Me’ is.

This is known as a ‘loosely coupled’ architecture, where applications can be written to address global variables such as [The Customer], without directly addressing the databases and systems that enable the actual physical data. This way application code that describes workflow can remain the same while underlying infrastructure is changed and upgraded. This virtualisation and indirect addressing is the formula that unlocks the mechanisms of the ‘agile business’, as it allows change to be a constant factor, not a variable one. Furthermore, it offers the opportunity to present considerably more friendly application development tools that work only at this higher, abstracted level, allowing non-technical staff to also become part of the development process. Some code changes are only needed at the business logic level (e.g. where a response to the TV advert should be routed) so they don’t need highly paid developers to implement them, instead they can be put into effect immediately by those managers responsible for the process. Indeed, the Agile Business is fully enabled when front-line business personnel are equipped with these sorts of tools, as change is implemented where and when it is needed. On Demand.

Exciting new ‘one-click’ ordering methods like the above example are but one of the many business benefits that federated identity strategies can enable.

The simplest way to describe the enormous potential is to highlight the fact that despite there being umpteen different applications and data formats all describing [The Customer] there is only ever one customer!

Because no alternative has ever been presented, every single business repeats the same expensive, fundamental CRM process: Capturing, storing and using customer data. We are forever presented with forms that ask us for our name, address, company and so on, simply so that it can be stored into yet another marketing database. But there is only one ME! I only have one postal address, one set of personal preferences and one set of data that powers my life, so why do I have to keep creating copies of this information? Why can’t each company simply request access to one instance of this data?

As well as creating the expensive EAI problems outlined in this article, it also forces companies to spend massive amounts of money on activities such as ‘data cleaning’, ensuring that my information on their systems is up to date so they can communicate with me when required. In contrast, if they instead became part of an Identity Federation where my data is shared in a consistent manner, then if it is changed anywhere in the network, it is changed everywhere in the network. This is a huge win/win for customer and business alike, because immediately a whole different world for CRM strategy is created:

– When you move house, change your postal address just once. Just once!

– Every company that needs this information will have this updated automatically reflected in their systems. No more data cleaning for them, ever again. No more direct mail to “gone aways”.

– I have one set of contacts: Whether I change them on my mobile phone or in my PC Outlook, these changes are reflected everywhere. I could lose my mobile phone down the toilet, and simply plug a new one into the network and have it automatically re-create all my contact data on the phone.

Yes, On Demand is the most important business concept you’ll be presented with to consider for your organisation, because it’s simple: Give customers what they want, when they want it, in the form that they want. It’s what ‘pure supply’ should aspire to, dynamically meeting exactly the market demand that is expressed, no more, no less.

Identity Federation is the backbone to this because it dissolves expensive complexity that holds back fluid processes, and it centres enabling information architecture around the single most important person: The customer.

Neil McEvoy is CEO of the Genesis forum (http://www.webservices-strategy.com), an
industry initiative of Service Oriented Architecture vendors describing the
business benefits of their technologies. He is the Chief Architect of the On
Demand framework, the platform for autonomic business models that match demand
and supply perfectly. Neil provides unique consultancy solutions to enterprise
end-users and vendor suppliers customised to deliver ROI within the On Demand
market. He can be reached at http://www.ondemand-strategy.com

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles