computers should be less friendly

After reading a lot about Rails and it’s former inclusion (thanks to Tom and Ryan) of a bunch of REST functionality into the next release and a blog by Dr. Nic about his Magic Models project I’ve decided to embark on a new project.

Simply put I want Dr. Nic’s magic models for ABAP. The basic idea behind the project is that RoR developers should be able to easily consume ABAP objects. Current solutions only create the ability to call RFCs, which if you are not an ABAP person are totally procedural elements so, this removes any of the beauty of OOP from systems you can build that interact with ABAP. With this project I hope to put it back. In the end what you should be able to do on the RoR side is create a config file to point to your SAP instance and then make calls like this:

@abapObject = Zcl_foobar.new

@abapObject.callMethod( with, some, params )

Where Zcl_foobar is the name of class that resides only on the ABAP system. What this will allow a RoR developer to do is simply and quickly access classes from ABAP without having to have an ABAP person wrap every method call in a function module. In the background Ruby is using the const_missing method to generate a generic class for Zcl_foobar. When a method is called the call is converted into a specially formatted REST call to an ICF Node ( basically a servlet ) on the ABAP side and ABAP responds to the message with another XML document that the newly generated class understand and unpacks into more Ruby data objects.

For now I am only building a “connector” to the Ruby programming language but, there is nothing to prevent the addition of other scripting languages from using this method and the base ICF node to accomplish similar feats. Over the next month or two I will be focusing almost all my time in taking this from it’s current stage, simply a proof of concept to a fully working system.

If your IT department is even the smallest bit like mine it may seem that is almost totally impossible to create a place where you can safely try out new technology. In my IT shop though we have carved out a small niche where we have a hand full of folks with a small percentage of their time to really seek out impossible problems and help solve them. At first this seemed like an impossible sell to senior management, however using the following logic we were able to get the time we needed to see if some of any new technology could help our business.

1. Agile Development
• Im totally guessing here, but in most IT shops I assume you probably use some locally bastardized version of the Waterfall method. In our R&D team we use an over simplified version of Scrum, the idea is to remove all the unnecessary artifacts from the process and “Shutup and make it work,” to use one of our teams mantras. The basic idea is get testable code in another team’s hands as frequently as possible; this could mean every night or every week.
• The reason this is number one is that it will allow you ( and/or your team ) to prove value instantly. People go nuts when you deliver the 1st version of working code before other teams have even decided who writes the spec
• Using this type of process automatically distinguishes you from your colleagues, it allows you to move fluidly with the ever changing IT landscape, it is a huge win over your normal process and a big key to my team’s success
2. Flatten your Team
• This may seem like a no brainer but odds are there are lots of people between you and your user community. To be successful at delivering code as fast as you will need to justify your spent time you must be as close as possible to your user base. This means you can’t have a rigid structure the person who knows the most about the area needs to make the decisions. Suck up your pride and let them run the show.
3. Get smart people
• I have a really hard time phrasing this statement but, suffice to say, you have to get the cream of your organization. If you want someone to go decide if Ruby on Rails is a good idea you better trust that person’s ability to learn and their ability to judge technologies. In the end it’s better to have fewer people then an army of people you have to micro-manage.
4. Research is failure
• This is one of the hardest concepts for an IT shop to grasp — they mostly deal with uptime and throughput but when experimenting with new ways of doing things you have to be able to deal with a certain amount of risk and this finally brings me to the reason for this blog, a recent post ( really go read it ) by Carmine Coyote at Slow Leadership, really a great job about the fear that makes these teams fail. Which brings me to my last point
  
5. Fear Nothing
• You can’t be a “disruptive innovator” ( thanks Shai ) without risking something every once in awhile
• Make your management understand that fear is costing them $
• “Thrill your users” ( thanks again Shai ) any fears your management has will go away

Good luck, if IT in the US is to stay we must stop being a commodity and start delivering really measurable value to our businesses again. The simplest way to do this in the enterprise space is to simply make those ugly back end systems usable.

btw — this blog was written somewhere south of Greenland at about 33k feet. On board internet is great.

For some reason Feedblendr has stopped picking up my new posts. Not really sure what the deal is, if you look at the raw RSS feed you will see that all the post are there but as soon as I set up a blend of it, the newer posts don’t show up. Check this rss or atom, they only pick up my 1st post from a few days ago, any ideas?

Update 11/7/2006 1:33 pm: Beau the person who maintains www.feedblendr.com updated his blog saying they are really having problems. So if you use feedblendr sit tight as it appears he’s fixing it.

Update 11/7/2006 9:41 pm:  Looks Beau fixed it, and we are back in business.  Thanks a lot to Beau for running feedblendr and for responding to mails.  If you use feedblendr you should think about donating to the cause.