OO Part 1: Irony

I am writing a post about OO and data, collecting thoughts from recent development experience that have after the latest Microsoft CTP of LINQ.

But before addressing OO/data, I realized I may need to mount a mini-defense of OOAD to set the stage. In particular, I find it ironic that, on the one hand, at the implementation level OO tools, languages, and pattens have become de facto standards (whether .net or Ruby or Java, whether Visual Studio with its built in CASE facilities or Eclipse with its first-order refactoring and semantic search); yet true OO analysis and design (at the human domain level, not the system or design-pattern level) seems to be out of favor. It appears that OOAD practice is still seen as being tied to heavyweight long-running processes (not agile enough).

With respect to the timeline and heaviness of the process (usually measured by the proportion of activities which are bound to non-code deliverables or resource intensive checkpoints such as meetings or workshops), OOAD can be heavy or light. The heavy examples are famous, the light ones less so because there is less to be famous ...

But the power of the OOAD process to solve hard development problems in vertical domains remains remarkable. Let's make this concrete. Some time ago, eTag (the predecessor company to Skip) was prototyping a new form of automated airline checkin. We worked with one of the major carriers in the US. In the beginning, important stakeholders at the airline were convinced that the sort of automation we proposed was an impossible, intractable problem because of the enormous sophistication of their check-in system and related workflow activities (e.g. seat changes, upgrade request processing.) Without being inside the airline and working our way through everyone else's systems there, it would never work, they felt.

Our assertion was that it is possible to execute checkin scenarios, upgrades, loyalty program operations, rebooking, etc. in an airline agnostic manner using only actions (like "change") , objects (like "seat"), and events ("your account is charged when you make some flight changes") that the customer is already familiar with. Or in other words, we asserted that neither the customer nor the front end of the system needs to understand the airline's peculiar internal rules and representations regarding seats. No knowledge of mainframe record layouts, fare codes, or business rules is necessary to fully define these activities.

It is possible to address scenarios such as these using various "more agile" techniques... but the actual clear, articulated OO analysis deliverables were a sine qua non to establish that our approach did work. A partial implementation, code iteration, or a process that meant our team could move like ninjas was meaningless. We needed to show conclusively that the approach could solve the entire problem before we could overcome the objections and meet the risk profile necessary to move forward.

And the full analysis (large in scope but only weeks in duration) allowed us to execute not only the front and middle tier parts, but also the proprietary legacy integration for everything in a matter of a few months. Because we had already validated the shape and behavior of every domain object in the system, even an extremely complex custom integration to ancient, undocumented, and proprietary mainframe components was reduced to "mere implementation detail."