James Governor's Monkchips

Case Study: T-Mobile and Adobe Flex, Extending SAP with Agile methods

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

At Adobe MAX the most interesting session I attended was a presentation by T-Mobile. The wireless provider is using Adobe technology to extend SAP and rapidly bring new applications to users, without any Big Middleware SOA blather. The development team might as well have walked around with Neon Tangerine Flake “We Get It” signs above their heads (well this was Las Vegas, after all). It was, as I say, good stuff.

The application in question is an employee-facing application, used for scheduling staff training sessions, including ongoing mail reminders and automated customised PDF documents for participants. It accesses SAP back end systems with a rich user interface. If you want to download the application it is open source and available on Flexcoders.

The application uses:

  • ActionScript (Adobe’s implementation of the ECMAscript standard, used throughout its tools)
  • Adobe Captivate (for online help, showing not telling, using screencasts)
  • Adobe Coldfusion (needs no introduction. T-Mobile was able to reuse existing code components)
  • Adobe Flex 1.5 (Son of Coldfusion, Flex is Adobe’s XML and data handling runtime and toolset). 
  • LDAP for SMTP services…
  • Microsoft ActiveDirectory (for authentication)
  • Microsoft SQLServer (a T-Mobile mandated platform)
  • MXML
  • SAP HR module

From an enterprise perspective Flex is Adob’s new route in. Quoting from development team lead Andrew Spencer:

“I can do Flash stuff but I cant see myself creating an application in Flash. I dig Flex though- I can get down with Flex”.

Flash is a design tool while Flex is very much about application development. Flex Data Services allows the user to pull down data relatively easily from back end systems into data grids which can then be accessed by forms-based applications. Why Flex? The answer became clear when an audience member asked about gathering requirements for the application, and suddenly we were in agile heaven.

“Requirements? You mean the analyst? Oh no I just worked it out. We just went ahead and built the application. I was a little worried it looked too much like a web app at first. Anyway – we make each component as reusable as possible. For example, the project tracking system. You can just grab a component and snap it in. if you think it could be a custom Flex component then turn it into one.”

Ah yes- the smell of agile. What about supporting user populations without a big staff once the apps are built? 

“Every app must be as easy to use as possible. You don’t want end users calling the helpdesk. So put contextual help in the application.”

T-Mobile did so using Adobe Captivate as a screen casting app for help (hey, it sure beats a paper clip…) Another attendee asked about scalability issues, given the team just built the app and rolled it out, without a lot of upfront performance modeling/capacity planning. 

“We didn’t run into any issues. Its an intranet app; the total initial user pool is 4,000 users, but concurrent- the number is very small. There are some large lists, they were managed [by Flex].

How often do you hear a developer say…

“I wish we had done more testing, and established a complete procedure list… “?

More often with agilists, that’s for sure. Agile development teams do a lot of unit testing, notably. Small pieces, loosely joined.

Talking of agile – one approach to easier code maintainability is lessconfig – the less needless customization in an application the easier is is to maintain. With that in mind, some of Andrew’s decisions about the UI for are salutary here, getting to the heart of the “forget flashy, make it work” theme. One of the thing that struck me about the scheduling app when I saw it was it was literally out of the box Chrome. No changes.

“You could skin it, but it was good out of the box… which means easier maintenance.”

That’s lessconfig…

Richness has a role though, when it enables more effective collaboration. T-Mobile is considering making the scheduling app richer – by using the Flex Media Services APIs to allow screen sharing between different users.

I thought Andrew got agile, but then his boss, Thelbert “Mack” McNeely, stepped up and it became clear this was a culture of agility rather than an isolated developer. 

“I have a small high impact team. The VP puts requirements down and says i need this on this date, you need to do it.”

You can’t have agile without trust and accountability.

What can we learn from T-Mobile? A couple of things.

1. Agile delivers real business value, and its a cultural as much as technical phenomenon.

2. Start small, and keep the componentry isolated.

3. The more upfront function testing for the components the better.

2. You don’t need SAP NetWeaver to usefully extend your SAP business applications. This is both good and bad for SAP. I know someone at SAP that lives this tension every day, and is going to love this case study. I must apologise to both Andrew and Craig Cmehil for not getting this online earlier. So much for agile… Craig let me know and I will pass on Andrew’s deets. This is a great example for you guys. I would certainly recommend that you ask Andrew to present at SAP TechEd or other events. 

And finally a question for Andrew- what do you think of Adobe’s Apollo strategy?

 

disclaimers: Adobe is currently not a subscription client, neither is SAP. Contrary to the claims of some people that should know better, we do write plenty about firms that aren’t clients. You can’t track the grassroots and practitioners otherwise.  

Technorati Tags:  –  –  

5 comments

  1. James,
    Cool bananas. Any chance of a screencam or a couple of screen prints?

    Actually come to think of it I’d like to see a youtube type arrangement for demos. Imagine being able to go and see demos of all the products and developments you were interested in.

    Thomas

  2. James –
    I think things like this are only good for SAP and here’s why. SAP sucks at UI, they always have and they probably always will; the shift you are starting to see is that SAP has finally decided as a corporation that they can’t compete in the UI space, specifically on the web. From a business perspective they need to be focusing on the stability and diversity of their business applications, namely what they are best at. My CIO has said it a million times before, he can’t remember the last time someone said one of our R/3 systems was down. However, I can never remember him saying that people truly enjoy using them :-). SAP needs to allow customers to create new paths to their own data — you are starting to see this with the widget and scripting communities. Personally, though I am not sure the SAP customer base is ready to make these type of decisions for themselves. Customers have always bought a total solution from SAP, from database to UI so, it is interesting to see companies that are unafraid of those choices. As for the agile stuff, I am stewing on a new blog, I’ll be sure to trackback here.

    -d

  3. It seems that James finally got around to blogging about something he saw. He talked a bit about it during one of the RedMonk Radio episodes but did not even scrat …

  4. James,
    saw this from the Analyst days…

    Among them was Dan McWeeney, business-process analyst at Colgate-Palmolive, which runs about 95% of its business on SAP. McWeeney says his team has built a proof-of-concept application using the Ruby on Rails open-source development language. “Pretty much every open source language can consume SOA easily,” he said. McWeeney said the application for human-resources management was easy to develop and plug into the back-end SAP system, with little knowledge requirements of SAP.

    http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?articleId=196601726

Leave a Reply to James Cancel reply

Your email address will not be published. Required fields are marked *