RIA + SOA = XOA (Experience Oriented Architecture)

| 7 Comments

Abdul Qabiz left a comment in one of my previous posts about using RIA to create a widget/component platform where we essentially enable "user-generated applications" as well as "user-generated content".  This is an extreme of an architectural philosophy within the enterprise that I've been calling "Experience Oriented Architecture", and Abdul's comment prompted me to complete this blog-entry that I'd started penning some time ago.

Almost a year ago, I had the pleasure of speaking at the Bulter Group's Analyst Briefing on Service Oriented Architecture.  Amongst enterprise vendors like Sun, Hewlett Packard, CapeClear, the one question I kept getting asked on our stand in the exhibition hall was, "...what are Adobe doing at an SOA event ? "   The surprise stems from the expectation that SOA is a technology-led initiative - however what I presented was how Adobe has the SOA technology in LiveCycle ES, but blends that with a heritage of understanding design, and the importance of design-thinking in creating creative and innovative products and services.

Experience Oriented Architecture

The talk I gave was called "Experience Oriented Architectures", and in the talk I aimed to address some of the reasons why multi-million dollar investments by organisations in service oriented architecture have failed to realise the anticipated returns.  My thesis; that when any IT initiative is technology driven rather than user-driven, chance of failure is dramatically multiplied.  A solution I proposed, was to start thinking about "Experience Oriented Architectures" as a means of putting the consumers of services front-and-center of an SOA initiative, rather than the services themselves. Or to paraphrase Alan Cooper, to free the asylum from the grip of the inmates.

I picked 3 drivers for an SOA initiative that are most cited as not delivering the anticipated ROI (Return on Investment):

  • Re-use (by creating a well-exposed service-tier, one hopes that services will be re-used more readily)
  • Business Agility (with a well-exposed suite of services, one hopes that others will be able to more rapidly deliver new products to market)
  • Alignment of Business and IT functions (with the service-tier arguably the exposition of the underlying IT infrastructure to support business needs, it could be argued that an SOA initiative brings these groups to the same table, and offers the opportunity for an alignment that otherwise can fail to occur)

I thought a quote from Annrai O'Toole, the CEO of ClearCape, that appeared in the March 2007 edition of Information Age was apt here, "...unless you really understand what services you are going to create and why, there is no point in doing SOA.  You must have a revolutionary approach."

A Revolutionary Approach - forget technology, what does the user need ?

I believe that a revolutionary approach is to recognise that focussing on a bottom-up technology driven approach to deciding what services an SOA platform should deliver, then putting in place all manner of incentive and governance to align business and IT and to drive service reuse and greater business agility is an upside-down-approach.  Instead, we can turn this problem (and solve it) on it's head by thinking of driving out services from the experiences that the consumer, citizen, customer, call-center operative, manufacturer, or whomever the user is, expects from their transaction.  I find this such an obviousism - that services are in service of the end user, and not vice versa.

Though we can be fascinated with identifying technology patterns, design patterns and architecture patterns, we are remiss not to recognise that there are patterns of engagement, patterns of behavior, user-experience patterns that once identified, self-identify not only the services that we may wish to consume consistently across our organisations, but the granularity of those services (another SOA challenge that much debate can circle around) and most importantly the manner through which these services should be consumed.

When we have user-experience patterns and fragments in an organisation, we create applications for which discoverability in one area of an application leads to expectations and easier understanding ("less cognitive dissonance") of other interactions in similar applications.  When we create reusable components that match service interactions - form guides, bank account statement displays, auction results, worklists, etc - we have RIA experiences sitting upon SOA services, that are in service of creating an architecture of "experience fragments" that can be easily reused by application developers.  Achieve reuse of the user-experience, and not only do we create more consistent experiences for end-users, not only do we accelerate the development of user-experiences within an organisation, but implicitly we achieve the re-use of services, the agility in being able to rapidly create new solutions upon those services, and we align business and IT not through governance, but through the shared responsibility of being in service of the end user.

Create Platforms not Application + User Generated Content --> User Generated Applications

In the consumer marketplace, we're already seeing where organisations create platforms, expose widgets/applications upon these platforms, and create an "architecture of participation" whereby end-users can create "mashup" applications that sit upon the platform. Think of what Salesforce.com are doing with TheForce.com toolkit for Adobe AIR and Flex. Think of Intuit's cloud-computing platform that is based on Flex and QuickBase. Think about eBay's Flex SDK for creating applications that sit upon the eBay platform.

I think these are all tremendous examples of where creating a platform, but then creating the user-experience around which an architecture of participation upon that platform can emerge, is a powerful enterprise architecture trend.

Rich Internet Applications (RIA) combined with Service Oriented Architecture (SOA) = Experience Oriented Architecture (XOA).

What are your thoughts ?

Is this a pattern that describes the kind of architectures that you are creating in your organisation ?  Are you seeing this trend in consumer-facing applications only, or are you seeing these trends of building experience-oriented platforms and reusing UI plus services in your enterprise organisation as well ?  Are you perhaps working for a company creating a business model upon someone else's platform ?  Is there an opportunity for you to monetise the creation of UI services upon someone else's platform - is this an opportunity for innovation where you can commoditise someone else's platform by providing value added services upon their platform (that perhaps you can interchange easily with the services of another platform) ? Or do you think that you're more likely to embrace a platform if instead of having to invest your induction in learning the service API calls, there was instead a lower barrier to entry by reusing user-experience components that are built upon those underlying services ?

As always, I'd appreciate your comments and thoughts.

7 Comments

Hi Steven,

As you know an experience oriented architecture is exactly what we've created here at Arum.

OSGi is a SOA platform and seems to be more suitable to a loosely coupled model than J2EE and of course Flex is a fantastic UI technology to work with, so we are taking the best of both and have come up with with Solstice.
http://www.arum.co.uk/solstice.php

We should see how well it pans out over with our product based on the Solstice platform in the next month or two. The only downer on it is that LCDS doesn't fit in well with OSGi. I have had to butcher BlazeDS a little bit more than I would have liked just to get remoting working and since our roadmap is to take J2EE out of the picture completely I don't see us being able to integrate LCDS for use with Solstice based applications. This is a shame as there's some really cool stuff in LCDS which could save developers using Solstice (or simply OSGi) a lot of time. If only LCDS were deployable as OSGi bundles... ;)

While I think about it, your post reminds of an article that I read last year called "Life Above the Service Tier", which discusses SOFEAs (service oriented front end architectures). You can read more here:
http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html

Cheers,
Chris

Hi Steven,

“My thesis; that when any IT initiative is technology driven rather than user-driven, chance of failure is dramatically multiplied.”

It is a proven fact that too many technology projects fail because they are technology driven. However, now RIA is turning from novelty into commodity we see technology projects fail for a new reason. Here’s my thesis. When any IT initiative is user-driven rather than business-driven, chance of failure is high too. What I mean is, we currently see a rapidly growing number of RIAs delivering great user-experiences. This does not mean however they are therefore meaningful and add substantial value to the business. If today, Adobe decides the standard company car will be an Aston Marton DB9, they create a wonderful experience for their employees, that may not be that relevant in the end. User experience is one element of an effective business solution, but I don’t think it is the holy grail, or primary driver for architecting innovative, meaningful business solutions.

I always adhere to the following consulting approach in my own practice: business drives design, and technology serves design. Therefore, I would prefer Business Oriented Architectures instead of Experience Oriented Architectures. Architectures based on core business objectives, effective strategies, smart business processes and architectures that can handle a range of future business scenarios and new business models.

Best,

Vinny

I think your comments about XOA are completely correct -- there has not been enough attention given to the user experience of SOA. I think Adobe Flex is an excellent platform for handling the user experience and that is why we built FlowUI, a mashup development framework for Flex targeted at enterprise applications. Unlike Cairngorm and other frameworks, FlowUI is a high-level framework that tries to speed up this process by providing resources and a structure designed for enterprise development. We've built our own software on top of the framework and think it might be useful to other developers, vendors, and businesses so we've released it under the Mozilla Public License. If you're interested you can check it out at: http://www.flowui.org.

Chris -- thanks for your comments. When you say that you are "exactly doing an Experience Oriented Architecture", I'd be careful not to attach buzzwords..are you enaging user-experience professionals, are you participating in UX initiatives like task-analysis, user-analysis, interviews, personas and ecosystems, and are you using these user-experience learnings to inform the design of user-experiences, and those user-experiences to inform the services that your business tier / SOA should expose ? That's my thesis....not that just having a rich front end upon an SOA is necessary in itself for having an "experience oriented architecture".

However, I do think if you have reusable components delivered upon a service platform, you do have the opportunity to get more reuse out of underlying services...but you've still taken a bottom-up technology-guess at "are they the right services, and are they at the appropriate level of granularity".

Re: Blaze DS ... I'm a little worried that you feel Blaze DS (or LiveCycle Data Services ?) isn't meeting your needs and you're having to hack at it....I'd like to understand your problems in a little more detail (and comments probably isn't the best forum). I would be surprised if you can't achieve what you need.

Vinny -- a blast from the Flex 1.0 past! Good to hear from you, I trust you are well ? So I'll do a separate post to one of your points; I absolutely agree that business context and business needs are an essential factor in deciding what a solution should be. My discussion of XOA presumes the solution is known, and we're now driving out the service architecture for that solution.

A diagram I can't post to the comments here, is the Adobe Consulting believe that it's not unless you perfectly balance business needs, user needs, and technology capabilities do you even begin to capture requirements and create user-experience design for the "right thing". The business as a proxy for the customer is a bad-smell, "You don't need to speak to our customers, we know what our customers need" is typically a sign of feature-itis, and of embarking upon a solution that might align with corporate objectives, but not match a user's perspective, tasks, aspirations or goals. But equally, and to quote Henry Ford, "if I'd asked my users what they wanted, they'd all have said they wanted a faster horse". So though it's critical that design is informed by user understanding, we must balance the tension between what the user needs and what the business needs. And the final tension in the mix is also what technology can support. Where we blend our insights in these 3 areas - what we've learned about the business needs, the user-needs and the capabilities of our technology amongst the constraints of a customer's technology landscape, we have a cauldron for innovation to happen. But all of this is about answering the question, 'what is the solution or solution that we should be building'.

Only once we have answered that question do I believe XOA is a discipline that's relevant to driving our service architecture; structure features and requirements in terms of what the user needs to accomplish, implement the user-experiences that can most effectively fulfil those tasks, goals and aspirations, and create a service archtiecture that is in service of the experience, not slave to it.

I suspect we are in violent agreement.

"I suspect we are in violent agreement"

Yes we are. We even use the same Henry Ford quote :-)

At the moment there is so much blogging, writing and talking about User Experience, which I like from a personal viewpoint, but from a professional viewpoint I think it is a bit overhyped and out of balance with the other elements that contribute to an effective business solution.

Having a strategy consulting background I would love to see Adobe Consulting employees blog a bit more about what's in their business toolkit and how they use it in their projects. That's what I miss in the current discussions

Hi Steve
Was reading your great post about cairngorm and it said for more info check your book 'developinp rich clients with macromedia flex'.
I have the book and the website stated: www.iterationtwo.com/flexbook/index.html

does not work! Where can I get the code and help to follow along with the book?
Thanks Tee

Leave a comment

About this Entry

This page contains a single entry by Steven Webster published on June 3, 2008 12:15 PM.

User Experience Disruption: Car/Auto Insurance (Part 1 of 3) was the previous entry in this blog.

User Experience Disruption: Car/Auto Insurance (Part 2 of 3) is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.