Finding your way to your own frontend...

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 scratch the service leaving me sitting ask "What the..." but finally he blogged it and will hopefully be sending over the "deets" from Andrew soon.

James saw a presentation from T-Mobile and how they developed (rather quickly) an app using Adobe Flex. Now I like Flex (I too can get down with Flex) and I'm hoping to add a "Flex" forum to SDN here in the near future (any Adobe guys want to help moderate?) and since I've been pushing the use of Scripting Languages his post is right up my alley in fact in more ways than one.

I'm not going to comment on SAP's UI strategy, Filip did that and Thomas just reminded everyone of that and raised a few more comments, nor will I comment on what Dan said about SAP's UI, not that I don't have an opinion it's just...

I really don't care what anyone's UI strategy is.

Give me a service, API or an RFC connection to their system and I will work the rest out myself. It's a given though that Corporate Identity in the enterprise world is a must and by that it usually refers for the most part to the text sizes, colors and fonts - in my experience not many companies lock down the individual components or layouts beyond the simple page layout.



How much time does a developer really need to spend working on a layout? Start your app development environment slap some components, connect to your services, do some logic and you are done -- OK I do have to agree with a comment from Den,

But to be perfectly blunt - if the UI sucks then is the user as effective as they might be? Of course thing need to get done, but it sure as heck helps if the user is getting some pleasure out of it instead of having to fight it.

However if you spend all your time building that "look and feel" into your app you'll never get it perfectly right and end up delaying your launch, if done correctly then someone else could spend time on the "look and feel" or better yet simply "apply" the proper "look and feel". Which is one reason I think SAP "does get it" not only do they give you a way of expanding their own software but they give you the platform and the means to do it as well. Some people will of course bring up the fact that SAP has too many ways of doing the same thing, for example SAP has two ways of working with ABAP in a web environment one (a favorite of mine) is BSP and the other is ABAP Web Dynpro. I did a video interview with the creators of BSP who also happen to be some of the brains behind ABAP Web Dynpro, you should really watch that and see the official stance on the use of the two languages. Does this mean that SAP made a mistake or can't decide on which way to work with? Not at all, so what does all this mean then? What is the core message being sent out...

• The backend must be stable, SAP has one of the most stable I've ever worked with
  
• The frontend is nice to have but not required
  
• Services, if you can't connect to it via SOA, RFC, API or whatever way matches your fancy is it worth it? I think the fact that SAP has devoted so many resources and time to building or services out (have you seen how many are available out of the box) says a lot.
  

With that in mind SAP has created one of the most flexible platforms to work with and to work on with little in terms of constraints. You don't have to be an ABAP guru anymore to work with SAP (knowing one does help though, and Rich is one of the best) you also don't have to know Java or ABAP to even get started, you simply have to have a working understanding of building an app and how the processes behind it all work. Case in point, Amsterdam, October of this year we had the SAP TechEd event. At this event were two individuals who had zero experience with SAP technologies, however within a few days of the event starting one of them had taken up the gauntlet thrown down by a SDN community member and started building a Ruby on Rails application connecting to a SAP backend system. We saw similar development taking place at the Las Vegas TechEd a month earlier.

Now back to James' post about Adobe Flex - "agile" is putting it lightly. He mentions , "You don't need SAP NetWeaver to usefully extend your SAP business applications." which is true if you look at SAP NetWeaver as the application server and not the entire platform. It's one of the coolest things about SAP and the NetWeaver platform, I can connect to it using Flex, PHP, Perl, Python, Ruby, Ruby on Rails, JavaScript (oh yes!), .NET, Java - I can spit out applications using any of those as well as using SAP's own BSP, Web Dynpro (Java or ABAP), Visual Composer, BPEL (that's new isn't it), ahh the list goes on and on. So have I ranted enough that everyone is now lost or do you start to see the pattern emerging? SAP isn't building a system that is locked down and closed and you can only use their tools to expand it - T-Mobile has shown that with this awesome demo, or from Matt or Ryan with their demos made during the week of TechEd with no prior SAP experience.

The Widget's starting to pop up all over SDN is another point, SAP has the platform and services and they give you the ability to use your own tool set to continue to expand and work - no need to stop what you are doing to get retrained you can just keep working. So that's the one extreme the other is the fact that SAP also does the hard stuff for you, they give tools like Visual Composer and Java and ABAP Web Dynpro so you can build the apps without having to worry about the layout, they do it for you if you want it - if not you have all the other options to work with.

Agile, flexibility, expandability, scalability these are terms you can't help but use when you begin working with the SAP NetWeaver platform it's all there it's like the Baskin & Robbins of the development world - just pick your flavor!



Technorati tags:

sdn blogger