Posts tagged "traits"

XOA Traits: Coarse-Grained Experience Components

The notion of fine-grained versus coarse-grained services is an oft-debated topic in SOA; if you take a look at this paper by IBM as an example, you’ll see how terse this discussion is, and how completely in absence of the end user of the software application it actually is. I’ll refrain from the debate.

XOA suggests that service granularity, and the services themselves, emerge from the needs of a presentation tier component, of an “experience”. Rather than hypothesize on the services we might want to expose in our banking systems for instance, we allow the user-experience of the application consuming the services to dictate the service, and the parameters/interface/signature of that service.

I recently presented on XOA to some of the innovation team at Credit Agricole, and they shared a great anecdote which I told them I’d use, and they allowed me to credit !

In the design of a service for transfering money between 2 accounts, the IT organization put a check in place in the service…if the account from which the transfer was being made didn’t have sufficient funds, the transfer did not take place. However, there was a very specific use-case from the broker team, where they needed to be able to transfer money from an account that was overdrawn … however, the use-case only revealed itself in the design of the end user-experience, and was never envisaged by the SOA architects. The consequence — no re-use, 2 services created, one of which is a more generic instance of the other, and now code to maintain in 2 places if business rules change. It’s a trivial but real example.

In an Experience Oriented Architecture, we would create a reusable component – in my world, this would be in Flex – that delivered the best imaginable experience for moving money from one account to another.

The component would encapsulate all the design findings from the user-experience team; it would provide visual affordance if the transfer was going to overdraw one particular account as a consequence, it would give meaningful feedback as to when the transfer might take place, or the duration of time for the transfer, it might also look at pending transfers in both accounts to inform that “though this won’t overdraw you right now, by the time the transfer takes place, this cheque will have cleared from this account and you will be overdrawn…do you want to instead transfer on this date, transfer less money, or also move money in from elsewhere to cover the cheque”.

In support of this enhanced, user-informed experience, is most likely some complex choreography of back-end services, most likely some horizontal integration of different back end systems (another trait of XOA I believe … for another day) and some implication to the SOA team on the services that need to be exposed in support of the user-experience the user deserves.

There will of course be complexity involved; the back end systems might include integration between different banking systems …. for a bank (such as Royal Bank of Scotland) that has 2 underlying banking systems as a consequence of a merger between 2 banks (RBS and Natwest), it might be the case that some accounts hold transactions in a CICS mainframe, some in an Oracle 8i system on the other side of the firewall, and the balance checking in both systems is different.

However, the contract with the application developer is “use this Flex MXML component, style and skin it according to the Flex programming model, and implicit in the reuse of this component, we will handle all of the underlying complexities of LiveCycle Data Services integration across CICS mainframes and Oracle 8i, and the nuances of balance transfer across the firewall, or within accounts”.

So XOA drives out coarse grained components (“An Account Transfer Component”), and these components handle the complexity of choreographing and orchestrating underlying services. And as a consequence, the decisions around which services are required, and the interfaces/signatures upon those services, is driven from user-needs, not from Business or IT.

Traits of an XOA (Experience Oriented Architecture)

As the phrase and philosophy of “Experience Oriented Architecture” (XOA) is capturing attention in the halls of San Jose at Adobe, particularly amongst our technical services organization and enterprise business unit, I find that I want to more concretely define what I mean when I think about XOA. It’s leading to a lot of interesting debate and dialogue that is promoting some of the SOA conversations of old, to XOA conversations of new…coarse grained versus fine grained, loosely coupled versus tightly coupled, etc. So let me share some of my own thoughts, on what traits define an architecture as “Experience Oriented”.

Let me start from my original premise – that of XOA as a way to address some common failures of SOA initiatives by taking a more user-centric approach to driving out services and architecture.

Addressing the SOA failure of reuse with XOA

So one of the cited failings of SOA initiatives is the disappointment in the ROI that was anticipated around re-use. SOA contends that by driving out a service tier, these services will be reused by developers across different projects. However, this is tightly coupled to another SOA challenge — too fine grained a service, and the reuse is wrapped up in a whole bunch of bespoke effort, too coarse grained a service and the reuse doesn’t happen because of the specificity of the service. The tension between fine and coarse-grained services is palpable.

So here’s the first traits I see for XOA:

  • Coarse Grained Experience Components
  • Implicit Choreography and Orchestration of Fine Grained Services in the SOA tier

I’ll take them up in another post; though I’d appreciate your thoughts and comments…