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

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: Adobe – Coldfusion – Flex – SAP – T-Mobile – agile – lessconfig – MAX – ActiveDirectory – LDAP – HR – MXML – ActionScript –  Captivate