Lessons Nobody Wants To Learn: Enterprise Upgrade Path

Quite often, I hear this argument that is supposed to be very convincing: "But our enterprise has millions of dollars invested in infrastructure X, it is our duty to protect it".

Give me a break.

Let me give you an example: In 1997, I've invested $2000 into a highly modern computer. It had the brand new Pentium MMX 233MHz CPU, whopping 32MB RAM, and incredibly large 2GB hard drive. It even had the SoundBlaster. Forget the fact that 12 years and countless generations of computers passed by since, I still must protect my investment and support and nurture the obsolete monstrosity with less computing power than a phone in my pocket?

What part of the message you still don't understand?

Enterprise: Missing The Big Picture

Google is a glutton for punishment:

• When will Books allow collapsing labels, just like GMail did?
• When will Latitude merge back contacts that are already merged in Contacts, and why did they split them to begin with?
• When will Books allow merging authors and titles, just like GMail merges contacts?
• When will they allow labeling places in Maps?
• When will they allow labeling events in Calendar?
• When will they allow labeling products and vendors in Froogle?
• When will they allow labeling search results in Search?
  
• Just as Contacts grew out of GMail and Voice, will Labels grow out of GMail, Contacts and Books?
• When will they remember the lessons of Smalltalk and allow meta-operations? For example, why can't I label labels?
• When will Reader comments have the same level of markup as Blogger?
• Speaking of which, when will Blogger comments have the same level of markup as Blogger blog entries?
• When will YouTube allow promotion and elimination of search results just as Search does today?
  

Is your enterprise better, by the way?

One difference between enterprises

• Smart enterprises: spend efforts on creating automated tools supporting the process, so the human factor is alleviated, and the process is enforced.
• Stupid enterprises: spend efforts on creating documentation on what processes to follow, so the human factor is confused the hell out of, and more effort is needed to create documentation to explain what the original documentation had in mind, ad nauseum.

Android G1: RIM should be afraid. Very afraid.

Here's what is going to happen pretty soon, in no particular order, with different probability of materialization:

• Software development houses are going to realize that Android offers them equal, if not more powerful platform than BlackBerry OS;
  
• They are going to realize that social networking and application interoperability (a.k.a. Web 2.0) is making their life much easier, and development overhead smaller, and time to market shorter;
• For a short while, corporations will bitch and moan about absence of Microsoft Exchange and Lotus Notes support on Android;
• Software development houses are going to realize that whoever comes up with Microsoft Exchange and/or Lotus Notes support on Android is going to hit the jackpot;
• Hence, the Big Race will start (I believe it has already started), and Microsoft Exchange and Lotus Notes support will inevitably come to Android, and very soon;
• This will eliminate the competitive advantage that BlackBerry is still enjoying;
• RIM is going to realize that Android in general, and G1 in particular, is the BlackBerry killer;
  
• RIM may do the right thing and drop BlackBerry OS altogether, with just legacy support (unlikely, that's too much of loss of face) or
  
• RIM may do the right thing and release a BlackBerry device with Android instead of or along with BlackBerry OS, gradually fading BlackBerry OS into oblivion;
  
• Presence of Android on BlackBerry hardware is going to save their butt, and allow them to save billions of dollars on not having to develop something the rest of the world is already eager to do for them. Just let them.

So here's what I would do:

• If I was responsible for mobile application development for consumer sector: drop BlackBerry development, change iPhone/Android resource allocation as 20/80 - iPhone is just one iPhone, Android is a platform, a cheaper platform, with more phones to come and vastly wider distribution;
  
• If I was responsible for mobile application development for corporate sector: forget that Android is not currently on the approved list. This will change very fast. Change the BlackBerry/Android resource allocation to at least 50/50, and keep watching the market. Oh, and look very deeply into not reinventing the wheel, for application interoperability will be the key for Android applications, and there'll be lots of reusable code to reuse;
  
• If I was responsible for infrastructure development: location based services are somewhat overdue, make sure they're not forgotten - and start planning ahead already;
• If I was responsible for buying a phone for myself: I'd buy G1, in fact, I just did;
• If I was responsible for corporate procurement plan: I'd eliminate all sorts of long term contracts with RIM and kept talking to Google about how they can make my life easier.

Now the prediction's been made, let's sit and wait and see what happens. I don't think holding one's breath for extended periods of time is necessary - BoA's mobile banking application has already been available on day one, Visa has declared their intent to do the same, there's some action as far as Microsoft Exchange support is concerned, Motorola is working on something. Let's see how much time it takes for others to realize that either they have to jump on the bandwagon, or be left in the dust.

Update: Told ya: CompanionLink Releases Outlook Syncing App For Android. Less than a month. May not be perfect, but certainly proves the point. Now let's see how long does it take for Lotus Notes sync app to arrive.

Lessons Nobody Wants To Learn: Enterprise Integration

It was a long time ago. I was young. It was my first job.

The job was to write a cross-compiler between two CAD systems.

On the receiving side, there was a minicomputer (a Soviet PDP-11 knockoff) running P-CAD.

On the sending side, there was a PC running some sort of a CAD supplied by, I believe, Sigmex - at least this is my recollection almost exactly 20 years later.

There was an interesting caveat to it.

You see, P-CAD is a PCB design tool.

And the Sigmex application complex was intended to create mechanical designs.

You can only imagine what sort of bribes and kickbacks could introduce a mechanical CAD system, woefully inadequate for designing PCBs, into an environment used exclusively for PCB design. I'm not even talking about the fact that there was plotting equipment designed to work with different paper size - about 2/3 of very expensive paper was being wasted into offcuts.

But I digress...

This is how ONE test run looked like:

1. Run the prototype, convert Sigmex output file into P-CAD input file;
2. Log off 6 (six) people working on P-CAD mini, busy as hell, trying to meet the production deadline;
3. Shut down the mini;
4. Take out the plotter adapter card;
5. Install the RS-232 interface card, connect the PC and the mini;
6. Boot up the mini;
7. Transfer the file from PC to mini;
8. Perform the test run on the file;
9. Withstand the scornful looks of the whole department which just lost about ten man-hours, as the following steps are conducted;
10. Shut down the mini;
11. Take out the RS-232 interface card;
12. Plug in the plotter adapter card;
13. Boot up the mini.

As you can imagine, it wasn't often that test runs were performed...

Long story short - painful attempts to produce the cross-compiler lingered for almost three years, with very little visible results. Eventually, I got sick of the task and needed to bury this dead horse once and for all.

This is what's been done:

The amount of work necessary to complete the task was doubled by adding another component to the list of deliverables. The component was a complete P-CAD file viewer.

It took less than a month to write it from scratch. Hundreds, if not thousands, of existing P-CAD files from the actual production environment were used to verify the correctness of the parser/visualizer implementation.

After this was done, the results of the dreaded cross-compiler were fed into the viewer. Since the purpose of the viewer was primarily to verify the input data, diagnostics were much, much better than "Error 0x2312980", and all the errors in the files produced were immediately obvious.

Turned out that the files were actually almost fine, with a few off-by-one and signed/unsigned conversion problems. It took a few more days to iron out those wrinkles.

The day was saved.

So, what it took to bring the project that was hopelessly beyond the budget and delivery date back in shape was a conscious decision to double the perceived amount of work to be done. Whereas it looks bizarre on the surface, it is actually not surprising.

The lessons that I learned back then were:

• You better have your APIs set in stone, thoroughly documented, with change control available, transparent and strictly followed;
• You must have a playground available for both your inputs and your outputs;
• If your input or output integration partner doesn't provide you with a playground, it is in your best interest to build one;
• Building an integration playground does NOT extend the project time and budget, on the contrary, it allows you to bring a runaway project back under control;
• If you are an API provider, it makes perfect sense for you to take responsibility for creating a sandbox of your own application, at your own expense. Complete with documentation, tutorials and help desk, of course. All this expense will pay for itself with the first API consumer, which will not bleed you with endless Q&A sessions;
• Massive amounts of test data help a lot when testing applications with either extensive protocols, and/or vague or incomplete or unknown requirement sets ("We don't know how to put this into words, but we'll know it when we see it").

It was many years later when I first saw the signs of enterprises having learned these lessons. Notable notions:

• PayPal Sandbox
• Google Checkout Sandbox
• Amazon Flexible Payment Service Sandbox is one of many sandboxes offered by Amazon Web Services
• Android Emulator is one of many examples of device emulators offered without charge by hardware and runtime manufacturers
  

But this is just about all.

Wikipedia Sandbox article was created on July 22 2006, when PayPal sandbox existed for a long time already, and Google Checkout sandbox was rolled out a month before. Two years later, it is still pretty sketchy.

The need to dedicate serious attention to sandboxes hasn't reached the attention of corporations yet.

It is counter-intuitive to invest additional resources into something you are not judged by completion of, therefore, sandboxes are not usually included into project plans.

Or, there is a reliance on "tried and true" methods of integration testing, consuming countless man-hours, extremely inconvenient and time and resource consuming because of a necessity of coordinating large numbers of people, departments and organizations, and extremely fragile due to the integration partner system downtime.

Or, simply lack of awareness.

There'll be some changes made.