Strategy(ies)

Some cool things to try:1) Ask employees for initiatives that have worked, that have not worked, what they've tried that they think will work well across the organization. That way, management would get ideas people have tried in their own units that have worked well and that should probably be evangelized across the organization.

2) Prototyping and front-end development responsibilities should be kept in the high cost center arenas. Integration with the back-end should be done in the high cost center. [See my previous posts for this subject beaten to death].

3) There seems to be a running theme in many of these applications we create at the investment bank. Take someone's spreadsheet and turn it into an application. Front-office users are adept at Excel apparently. Here's the progression:

1. They create the spreadsheet, start really using it, and get dependent on it.
   
2. They start mailing the spreadsheets all around.
   
3. They wind up with multiple copies all over the place and they get out of sync.
4. Then they ask IT for help...
   
5. IT comes to the rescue with a solution with 3 tiers and 6-12 months development time.

We should start looking at other solutions. If we keep following this procedure, IT is reduced to not adding any real value; we're placed in the position of playing constant catch-up. And IT is not really innovating or doing anything kewl.

Instead why don't we:
1) Train business users to use IT more wisely. There are a myriad of technologies out there. When I stop by a business user's desk, the same things strike me each time: how few applications they have installed on their box and how non-facile they are at using applications. As part of their on-boarding, they should be indoctrinated into the tech tools that are available to them; for instance, an introduction to using Sharepoint technologies; If they use an online-spreadsheet in the first place, IT might never have to build them an application at all. And even if they needed something extraordinary, we could build them a Sharepoint component to help them, for example vs. building them a whole new app. Hell, even use something like Google docs!

2) IT should get away from the mindset of creating applications from scratch. In this world of plug-n-play, we should be leveraging other solutions. That means hiring people who like to play with new technologies, with vendor products, experiment, attach the output of one product as the input to another product and integrate them, etc. We should be coding only when we HAVE to. Even the idea of taking code from one application and using it in another is often far-fetched. In reality, ripping this stuff out and using it elsewhere doesn't work so well in practice. And you usually need the guy who developed it in the first place to stick around. If he's not, good luck!

Get IT to play with experimental technologies and to prototype with them [I'm thinking of using frameworks to prototype quickly: Rails, django, adobe flex, etc].

A BA should be a RAD developer. Not!

Ok, so I started hacking up some HTML using our corporate branding standards and the free snippets we have. While it was cool and easy for me to just drag a snippet into Dreamweaver and have it appear on the page without any work, there's a lot of customization involved to get it to look exactly the way I want. I just don't know enough HTML to start playing with divs, tables, spans, colwidths, etc. and putting various elements exactly where I need them, nor do I have the inclination. We really do need a full-time expert on this kind of job! It was a good exercise for me to try in any case. I now am familiar with the space, know what kind of expertise is required, how to set up other people to do the same thing, and I know enough to make a case for bringing this kind of expertise into our firm.

My philosophy is: talk is cheap; only by doing do you really know [and what I mean by know is knowing by your gut]. You just gotta experiment and try different things and see what works.

Can't commoditize the "experience"

Here's something that I find interesting.

We've long ago commoditized many kinds of products. Services have been the next to go. We have BPOs happening in India, outsourcing of all kinds to many different types of firms all over the world. Some of it is good, some bad, but they're getting better. The next step up from services some say is the experience. Starbucks may not have been the ones to pioneer this, but they certainly have made it a household word. Starbucks just doesn't give you coffee (a product), or give you mere service; they've transcended into the world of experience.

So what's the point I'm making? Well, if services are becoming commoditized (and many of us are busy still making sure that goes OK), then experiences, which is next down the list, still need to remain close to the customer. We can't outsource the experience. I don't even know what that means or what it would look like! So applying this to software, we have U/X engineers: U/X = User Experience Engineers. Since the GUI is what the user sees as the entire application (users are blissfully unaware of all the middle tier and back-end stuff), we need to ensure their experience with the software is a positive one, not a traumatic one. We also need to show them that we are responsive to their needs. Thus the user experience is something we dare not commoditize and ship overseas. We need to keep this one close to our chests.

A BA should be a RAD developer. Maybe Not!

So I've had some more thoughts along these lines.

After delving into the world of Dreamweaver and XHTML, CSS & Javascript [we'll see about AJAX], and talking to a real good front-end developer and senior BA, I've come to realize that my assertion about BAs becoming RAD developers is probably far-fetched. I was eager to learn it and with a bit of training and getting up to speed, I could probably create some workable pages (which I'm in the process of doing).

But I saw after my interactions with these guys that the front-end development I was thinking about is probably going to require someone devoted entirely to that task: a full-time HTML or ASP.Net front-end developer. There are just too many details that would need attending to. This is really a developer task. While I might be able to deliver workable pages (something perhaps good enough to show my users) they probably would be hacked and not very tightly coded; definitely not worthy of production. And I personally wouldn't want to go that route. My interests aren't in developing HTML pages.

So my thoughts have changed. I would say that having a BA along with a front-end developer at the high-cost centers (read: NY, London, anywhere that's close to the user) should be the new paradigm. The front-end IS the application from the user's point of view. If we get that right, everything else follows. But we need to get that right. We need customer involvement in getting there.

So if a BA and a front-end person meet with customers or users and are able to rapidly turn around the requirements into a working, clickable prototype, GREAT! You could have them iterate as much as they need to get it right. And then the front-end developer could deliver working XHTML code to the back-end developers. You can also start utilizing the front-end developer on other projects if the back-end people take a bit longer to deliver their pieces (or maybe not, depending on the methodology you're using: waterfall vs. XP for e.g.).

The main point here is that having a front-end developer to carry out RAD very close to the customer is the item that will start to foster good relationships between IT and business. The business will see that IT is more responsive because IT is able to come back in a few days with improvements in the interface that were requested. BAs will have more definitive answers and be more confident about what they're asking developers to do. And the RAD developer can deliver production-ready front-end code that back-end developers normally want nothing to do with. This is a win-win situation!

In our particular environment, we have branding guidelines we need to adhere to. The branding department has provided us with a framework of html and css (both with and without Javascript) as well as various code snippets. The front-end developer doesn't need to start up from scratch on each project. This makes high-fidelity prototyping or RAD more within reach than ever before.