Blogs

RedMonk

Skip to content

Front Ends & Portal Plasticity: glue to putty, SAP to Adobe

Rather than writing a once and future post I wanted to jot some thoughts down about legacy portals and what to do with them. Portal reskinning is a growing business – both Deloitte and Accenture, for example, have built practices dedicated to using Adobe technology to make existing enterprise applications and their portal front ends less painful for users.

That’s right- less painful for users. Products like IBM WebSphere Portal and SAP Netweaver Portal were supposed to bring much improved user interaction models to enterprise IT, but unfortunately traditional systems-focused IT departments, rather than user interaction specialists and their web brethren, did the work. People like Josh Porter generally weren’t invited to the party. Portals were built to support IT systems and data, rather than users. Portals were part of what Adobe calls a system-centric view of the world. Portals had glue, if not concrete poured all over them.

What kicked off this line of thought? The Adobe 09 analyst conference in San Jose. At the time I said:

Who would have thought Adobe’s big enterprise play would be portal replacement? #adobe09

That’s right. Adobe technology used -notably Flash Builder – to front end traditional portals, without trying to compete with portal functionality such as SSO.

The canonical example of a systems-centric view of the world is SAP, and its customer base. Everything is about data and process, not user experience. Its no surprise that SAP portals are hardly renowned for being user friendly. That is not to say they aren’t valuable, they just aren’t very flexible. So it is time to rethink SAP Portal is a management interface rather than a user interface?

Just Add Ajax

Major portal vendors such as IBM and SAP have now implemented AJAX in their portal suites, offering whizzy eye candy transitions, and enhanced performance, reducing screen refreshes across for example text search using frameworks such as DOJO. This is all to the good, and certainly dramatically improve the portal user experience, but the goodness of AJAX should not be confused with the goodness of Web 2.0 more broadly.

Web 2.0 is more about information than presentation, and the social aspects of information sharing at that – and that’s where plasticity is required. The other issue about reskinning for better interaction is.. who actually does the work. For obvious reasons services vendors are pitching the idea most strongly. Meanwhile it is lines of business, not IT, that are most keen on moving to a user, rather than systems, focus and are driving budget accordingly. Of course reskinning and rethinking user experience is a great services opportunity, which explains why firms like Deloitte are interested, but also may explain some user recalcitrance. “Spend money on software we already bought? Why do that?” The answer of course is business value.

What Kevin said

I recently met with Kevin Cochrane, chief marketing officer at Day Software [client]. I thought he described the evolution of content management and user interaction I am describing really well. So let me quote him at length.

“The trend that happened between convergence of portal and content management needs to continue. In the early days of web everything was hand-rolled. Along came Interwoven etc but the presentation layer was build your own, and so more complex. There were also simple use cases- but because the CM vendors were stabilizing their back ends, they couldn’t invest in the front end. Then you saw the development of an independent portal market – plumtree etc. You also saw application server maturation and consolidation, with the likes of Silverstream going away.

The fixation then was on a portal deployment model. But that took away the design aspect of a lot of web sites. Notably “tailorability”. It was partly a reaction – personalised design was just too expensive. Now we’re seeing the pendulum swing the other way. We have these web 2.0 apps, with javascript we can add all kinds of flexibility.

Pendulum swung that way. So now – people are saying I want a portal framework that I can have easy lightweight customisations”.

Word.

Victims of Systems-based computing

One way to think about first generation portals is as management interfaces rather than user interfaces. SAP Portal is a management interface, offering access control, single sign on and so on. But its not something you’d necessarily expose to end users.

Deloitte’s play was particularly impressive. The slideware may not have been as slick as Accenture’s – but Jaco Von Eeden, the guy that runs the practice, was outstanding. Here are a couple of quotes from his presentation:

“Virtually every ERP deal we see we ask where can we use Adobe. We have a reasonable revenue flow and fantastic pipeline.”

Accenture and Deliotte were pretty well aligned in terms of overall message though. Accenture’s ERP practice representative Joel Osman, said what we’re seeing is a second wave of rich internet apps. For more on this see this presentation. You can also check out this case study from IDC about Accenture’s work improving Well Fargo’s apps.

But the real killed quote came when Osman said:

“We’re at the back end. victims of systems-based computing”

Ouch.

But where does user interaction end and process begin? Very good question, it turns out.

Process Flexibility: The Southwark experience

Lets take a look at Southwark Council in the UK, which signed up Vangent to build its one touch citizen services apps and call center. Adrian Blair ran the project, and he has form in using Adobe to improve public services. What does he say?

“We use SAP CRM. When citizens call, you have to create a ticket etc, as per the system, but that’s not what the process is [italics mine], for example there is a car blocking my way.

SAP Portal is used for application access. for its exchange infrastructure and business warehouse and so on, but Adobe is our choice for user workflows. We have a user-driven desktop built in flex, which is user centric rather than system centric.”

The problem keeps rearing its head… what is the difference between a user interaction and a business process? How do we define where systems focus ends?

Ray Wang wrote an interesting post the other day which comes at a related problem from a slightly different angle – Why Every Social CRM Initiative Needs An MDM Backbone.

In order to cut through the high noise to signal ratio, organizations must determine how best to manage the complexity and scale of data being generated

Master Data Management is very much part of the Systems first view of the world, and as such is an extremely valuable concept. Corporations thrive on the idea of a single view of the truth, which is the MDM space. In the social context you want to know exactly who a person is – entity resolution. But we’re talking about user interactions right?

With other users, or with data, or with both?

Wikis as Plastic Front Ends

Like Adobe Flex Builder and Flash, Javascript can offer a surprising amount of user interaction function, and folks like John Lister aka Jayfresh can build it. But wait that guy is a web designer, isn’t he? Stat!

Read my lips-no Java skills required. At the risk of pimping a client, Mindtouch is all about this model. It has plenty of customer examples using the Mindtouch wiki as the pane of glass for Javascript-based integration, offering flexible data and user interaction services.

What Say You

AS I said at the top of the page, this post is more a placeholder than a finished article. The industry doesn’t have an agreed language for the new interaction focus (“RIA” just doesn’t cut it). Suffice to say this will be a research focus over the next couple of months.

picture credit jurvetson

clients: Adobe, Day Software, IBM, Mindtouch, SAP

“the trend that happened between convergence of portal and content management needs to continue” – early days of web. Interwoven etc- the presentation layer was build your own, more complex. But there were also simple use cases- because the CM vendors were stablising their back ends, they couldn’t invest in the front end. Then you saw the development of an independent portal market – plumtree etc. Also saw app server maturation – silverstream going away etc

New growth portals. The fixation was on a portal deployment model. But that took away the design aspect of a lot of web sites. Tailorability. It was partly a reaction – personalised design was too expensive. Now we’re seeing the pendulum swing the other way. We have these web 2.0 apps, with javascript we can add all kinds of flexibility.

Pendulum swung that way. So now – people are saying I want a portal framework that I can have easy lightweight customisations. JSR 168 – that’s where our new version plays.

Categories: Uncategorized.

Comment Feed

42 Responses

  1. Front Ends & Portal Plasticity: glue to putty, SAP to Adobe http://tinyurl.com/nkq7ey – See also my post | http://bit.ly/ONPx2
    This comment was originally posted on Twitter

  2. Great thoughts by @monkchips on enterprise application UI http://bit.ly/1Av31D
    This comment was originally posted on Twitter

  3. Nice post by James regarding the evolution of portal technology in the enterprise http://bit.ly/YOGIu
    This comment was originally posted on Twitter

  4. Front Ends & Portal Plasticity: glue to putty, SAP to Adobe http://ff.im/-7HamW
    This comment was originally posted on Twitter

  5. @monkchips suggests that UX (using me as an e.g. :) is generally not “invited to the party” in enterprise IT http://bit.ly/3W4fHy
    This comment was originally posted on Twitter

  6. And there I was thinking John Lister just drew cartoons.

  7. Moving from web design to SAP – from a focus on building great user interfaces to being forced to deal with SAP’s lack thereof – was one of my most difficult career moves ever. So when I started working with Adobe’s solutions in the SAP world some years ago, I dreamt of a combination of Adobe’s more user oriented and SAP’s (or any other) system-centric view.

    2009 has been the year where I finally saw the industry move in this direction too. User interfaces and user interaction are important again. SAP itself is playing an important role here by focusing on their user interface technology the last years, but also by Adobe for relentlessly evangelizing the Flash platform.

    I have had more questions about how Flash can be used in an enterprise setting this year alone than in the previous three years together. The word about Adobe/Flash seems to finally have reached the IT departments, not only as Adobe forms, but now also as a tool for building better user interfaces. (even though I am still asked questions where the words Flex and output management are used in the same sentence). The amount of projects and companies working in this field is steadily growing every year, so it must be a growing market. Unfortunately much of the development is still happening behind closed doors so it is difficult to share any actual numbers.

    As I see it RIAs/Flash/Rich Portals (we definitely need to agree on a language soon) won’t replace the existing portals or user interfaces, but rather be a supplement to what is already installed. The portals or SAP GUIs won’t disappear, instead there will be a bigger need to differentiate which user interface fits which end users. Letting the end user, rather than the system, being the main focus.

    This is still early days and the discussion over the next months should be interesting.

    Anne K PetterøeSeptember 6, 2009 @ 12:17 amReply
  8. James,
    Thoughtful stuff. You and I have discussed this many times over the last few years.

    I sense that most of the problems/challenges with enterprise UI are not just a tool challenge. It is a design thinking problem. Until design thinking permeates enterprise application development, UI will be a sore point.

    The UX innovation that you mention above is goodness, it is concerning though, that instead of deploying “standard” software user organization end up building their own. The short term costs of this are significant, the longer term maintenance even more so.

    I worry that rolling in legions of consultants to “build” UIs it creates higher cost of ownership and a long term dependency problem. Who will support these “uis” when they don’t behave perfectly? Who will write the documentation?

    Users deserve usable applications. Applications Vendors should deliver them, or at the very least, offer clear, consistent guidelines on options, technologies and techniques.

    Thomas

  9. @Thomas:
    The “UI in the enterprise discussion” is definitely one of the most interesting discussions I know, getting all excited again!
    While we still have a long way to go, I see that focus on design is getting more and more important, also from the buyer’s side. My company has been forced to focus on making SAP easy, also in terms of UI, to be able to keep up with the competition in the SME market.

    At SAP’s Sapphire this year I talked to several big corporations, which all had started developing new UIs which worked like glue (filling the gaps) between SAP backend and portals. I didn’t get the impression that they were worried about these applications not being standard or asking questions about who would support them. The impression was rather that they had all accepted the fact that this is what the enterprise UI world will look like in the years to come.
    (Ie. the vendors supporting the technologies, but not development itself.)

    • great great comments Thomas and Anne Katherine. thanks!

      Thomas- supporting the new architectures will indeed be a challenge-one reason its helpful SAP has “anointed” Adobe in the UI role, although customers still face a number of options – when they are talking to SAP. Organisations will indeed need a design culture to get the most out of internal apps -almost certainly the biggest challenge of all: culture, services, education – all the stuff companies just love in invest in ;-)

      AK – your experience talking to the big shops makes it clear customers have realised UX must be addressed, even if it does increase support requirements.

      James GovernorSeptember 7, 2009 @ 9:58 amReply
  10. “It is a design thinking problem” @vendorprisey very rightly points out on @monkchips post on state of Enterprise UIs http://bit.ly/YOGIu
    This comment was originally posted on Twitter

  11. One major roadblock in my opinion in a lot of these adoption scenario’s around RIA in the Enterprise is simply a lack of consolidation of available components, tools and knowledge.

    Apple does a good job here with the AppStore and Developer Center, MSFT does a good job with MSDN however Adobe is kind of all over the place. They’ve the AIR Marketplace but still they are all over the place when it comes to tracking down or reusing components.

    Right now I’m hunting (the past 36 hours) for a decent example or existing component for working with Flex and databases and I’ve found tons of great stuff but not what I specifically need – chances are it does not exist but an “Flex based Component” store would be an excellent move for Adobe – especially considering SAP now launched Flash Islands these components are becoming invaluable in my world.

  12. Over the last years I’ve seen a few UI modernisation projects (not in the SAP field though). One of the bottleneck in such projects was often the performance. Because the legacy app was not designed for the frequent request from AJAX apps, or because the software stack added for the new application layer was in order of magnitudes bigger than the legacy ones.
    If that performance aspect is taken in consideration early enough, there is a chance for a success.

  13. Doh! Now I remember (as he finds 2 pages of notes on his desk) this Friday’s show is around this topic http://bit.ly/EqX1q
    This comment was originally posted on Twitter

  14. Great post by @monkchips on portals: user vs system centric; data backbone; wikis; beyond RIAs. http://bit.ly/sTtca
    This comment was originally posted on Twitter

  15. Interesting post by James Governor about (the lack of) Portal Design and Adobe’s Portal Play: http://bit.ly/sTtca
    This comment was originally posted on Twitter

  16. Note, I’m not speaking for my employee here, nor do I mention SAP here :)

    @Stephane, I agree that real and perceived performance are key factors here. The issue is that Enterprise Web services are often not very well tailored for building high performance (Flex-)UIs on top of them. One would need a communication protocol that supports client side caching, pagination and is flexible enough to support sending only the data necessary. Wouldn’t RESTful API’s fit here? This is not only a problem for Flex, but for example a GWT based application would need a similar protocol.
    BTW, I’m sad I missed you, when you were in WDF meeting Anne. Would have been an interesting discussion, I guess :)

    Someone mentioned Flashislands. Also they have their uses, they also have the limitation that they require a server roundtrip as soon as you want to communicate with the rest of the page.

  17. how things are implemented is key.
    SAP’s portal for community is an interesting example. the firm does tend to pour concrete on things like Jive, Confluence, and so on… so you end up running older, less slick versions of things
    This comment was originally posted on Rags to Riches

  18. That’s true.
    I was trying to highlight why in general enterprise software has bad user experience .. I think its because of the missing design thinkers … interaction design is usually not part of the process of building enterprise applications .. and unless that changes I think we will continue in this state we’re in.
    This comment was originally posted on Rags to Riches

  19. I have met couple of experienced Usability experts or Interaction Designers or User experience or other things they choose to name the profession of delivering usable and rich interfaces. A lot of them end up creating a UX assuming the technology to be used is going to be HTML or even worse no assumptions at all.
    I think many of the Interaction designers do not understand what is possible with RIA technologies.
    Even if there are Interaction designers as part of a team , if they have less willingness to explore what is possible , enterprise UI will remain boring.
    This comment was originally posted on Rags to Riches

  20. Fantastic blog post regarding legacy portals #gov2au http://twurl.nl/dilizt
    This comment was originally posted on Twitter

  21. Many companies like Adobe seem to be releasing new versions just to generate sales based on the fact that it is their latest release. I strongly prefer their older versions than their newer, more difficult to use UI nightmares.
    This comment was originally posted on Rags to Riches

  22. in my experience this problem tends to stem from the general principle that for businesses ‘more is more’ and for end users ‘less is more’. Businesses see value in huge requirement lists being met and masses of functionality being provided (in many cases, functionality that is way beyond the needs of the organisation that has acquired it). All of this excess functionality places a huge toll on the user experience for the people who have to use the software day to day.

    A user experience practitioner should be able to help the organisation to identify what is the required functionality and the best way for that functionality to be presented in the UI so as to optimise the experience for the end user. However, in many cases, this would require a radically new way of thinking about what value means in these kinds of business transactions.

    Sadly, in too many cases, the people who could potentially help make these good decision are either not at the table at all (as you suggested James) or are at the table but so far away from the management that all they can do if fiddle with the UI here and there.

    Ajax, Javascript, Flash – they’re all great tools, but only if well applied, and they’ll never solve the problem of feature bloated and overly complex interaction pathways.

    What is really needed is a UX person sufficiently aware of the end user behaviour and sufficiently influential within the business to be able to take a chainsaw to feature bloat and to insist on being able to create interactions that are just as much as they need to be and nothing more.

    Then we can take a look at the RIA side of things and use them as they *should* be used, which are *enhancements* to the overall user experience.

  23. Mrinal, I have to completely agree that it is lack of an influential design or UX voice within the organisation that is strikes me as the reason that in many cases the UX is getting worse and worse, not better – even though we’re now trying to paint rich interfaces over the top.
    The problem, I think, is fundamental – for a business doing a deal on a piece of software, more is more. The more the software can do, the more valuable it is perceived as being.
    UX people would see things very differently – it is probably simplistic to say that less is more, but they are much more interested in just having the right things, and no more. All that extra functionality takes a huge toll on the User Experience.
    Until it’s actually seen as valuable to strip the excess away and to streamline the UI so that it actually better supports the key tasks that end users want to perform, then the addition of rich interfaces will be little more than lipstick on a pig, at best.
    But it’s requires business to actually really be interested in making sure that their employees, the end users, are using software that makes them as efficient, as productive as they can be, rather than just ticking a major deliverable off the list (CRM portal, done.)
    In my experience, despite much willingness to pay lipservice at the outset of the project, those organisations are few and far between.
    This comment was originally posted on Rags to Riches

  24. “the problem is that for businesses ‘more is more’ and for end users ‘less is more’” http://bit.ly/3W4fHy @leisa law of excess functionality
    This comment was originally posted on Twitter

  25. #asymmetricdemand RT @monkchips the problem is that for businesses ‘more is more’ and for end users ‘less is more’ http://bit.ly/3W4fHy
    This comment was originally posted on Twitter

  26. Leisa,
    Thanks for sharing you thoughts … you’re absolutely right, its really hard for most business decision makers to perceive the value in stripping features off their product … the reality though is that many a time features exist only to compensate for the ineptness of some other feature in the system.
    I think (hope) that the way around this is that businesses will start to understand tangible value in UX (already happening?) and that will hopefully create these influential UX voices and give them a proper place they deserve in application development work flows.
    Mrinal
    This comment was originally posted on Rags to Riches

  27. You say
    “Its not about rounded corners or gradients or “flashy” animations ”
    I fully agree. The flashy stuff comes on top. IMHO often a good interaction design and good *performance* is all users need.
    Is GMail, or even google.com “flashy”? not really, but I suppose google has done some interaction design and performance is usually just very good.
    The problem is that building a new high performance UI on some existing application can be very difficult or maybe even impossible.
    For example if the original UI was build on a server side rendering technology, it might be very hard to build a new UI that is based on a client side rendering technology such as Flex.
    This comment was originally posted on Rags to Riches

  28. That is a very good point Markus,
    Moving from server side controlled rendering to a thicker client approach can be pretty challenging implementation wise.
    Although, the focus on UX is independent of that technology choice, there are many examples of great experiences built with older UI technologies and at the same time many horrible experience built using newer so call RIA technologies.
    I think, its more related to how teams that produce software think … and weather on not there is a driving force in the team that consistently directs the team to good UX choices. Ideally this person should have an authoritative role in the process .. because at times he/she will point you to seemingly disruptive directions .. but that’s what’s needed.
    Mrinal
    This comment was originally posted on Rags to Riches

  29. Good article. Most of the enterprise application user experience is terrible. UX voices are unheard and users suffer. (for us it is peoplesoft instead of SAP).
    This comment was originally posted on Rags to Riches

  30. I’m glad to see this discussion re-showing up. Every once in a while, the UI topic comes back onto the table, as it is a constant issue to deal with, especially in the world of business applications.

    I have written a piece about this just a few days ago on SCN, just about why Business Apps needed RIA.

    I am currently working on a project where the UI is a main focus, built entirely in Flex. From this point, we had to re-think the way of building a UI. It had to be done by a design thinker who spends time with key users, collecting data about how the screens should be designed, what were their usual requirements down to the personalization features.

    I see the main problem with the introduction of portals within the Enterprise world, is that the portal was seen as the UI instead of a tool to deliver an UI. Just as quoted, it was used mainly for technical purposes and the user-centric aspect was completely forgotten in the transition.

    The tooling has matured and is able to deliver industrialized, easily maintenable UIs, that will provide an enhanced interactive experience to the users, with a double centricity:

    – User-centric from the usability perspective (screen design)
    – Process-centric from the logic perspective (screen flow)

    Thorough the building process, designers and developers should keep in mind the whole picture rather than just the component focus, constantly matching the global design with the collected data from the users and process owners. This becomes even more true when it comes to the integration with the back-end systems.

  31. It is about the users not the developers or solution providers http://bit.ly/NBans
    This comment was originally posted on Twitter



Some HTML is OK

or, reply to this post via trackback.

Continuing the Discussion

  1. [...] from:  Front Ends & Portal Plasticity: glue to putty, SAP to Adobe 04 Sep 09 | [...]

  2. [...] James Governor’s Monkchips » Front Ends & Portal Plasticity: glue to putty, SAP to Adobe [...]

  3. [...] James Governor’s Monkchips » Front Ends & Portal Plasticity: glue to putty, SAP to Adobe (tags: Monkchips enterprise) [...]

  4. [...] Governor of RedMonk yesterday kicked off an interesting discussion about the state of Enterprise User Interfaces, more specifically Enterprise Portals and points out … “… That’s right- less [...]

  5. [...] Front Ends & Portal Plasticity: glue to putty, SAP to Adobe [...]

  6. [...] summarized the problem with the technology and, therefore, the word “portal”: That’s right- less painful for users. Products like IBM WebSphere Portal and SAP Netweaver [...]

  7. [...] bought up recently when he contended that “the best UI is no UI”. Vinnie was riffing on a post by James Governor who was discussing the major portal re-skinning projects taken on by some of the [...]

  8. [...] Front Ends & Portal Plasticity: glue to putty, SAP to Adobe [...]