Tuesday, April 17, 2012

Software Platforms: where code meets politics


Sharing and re-using software within a company is a noble and rational goal, but I've seen it lead to some very ignoble and irrational behaviour.

What I now understand is that aligning products and projects around shared software has far reaching implications: it leads directly into organizational design, personal motivations and politics.

Those API's you designed now also serve as organization interfaces between the application and platform team. Poorly designed API's will have the teams bickering; application design choices will be limited by directives about re-use; in the worst case the motivation to produce a finely pointed solution may fizzle out, replaced by hacking around with the wrong tool for the job.

It doesn't help that re-use seems so obvious - heck even a CFO can almost understand it! Think of our platform as LEGO the bean counters are told with a helpful picture of a simple brick.

Oh yeah, re-use is that easy? Here try re-using this LEGO piece to build a house:

The worst Lego piece ever made?

Frankly, the simplicity of the re-use idea is one of its downfalls - a case of an over-simplistic metaphor taking the place of critical thinking. Typically a cute name is devised for the shared software platform - see my list in the appendix below - which allows executives to sound like they know what they want even if they couldn't even begin to describe what it is. So a project may be forced to use a platform that doesn't meets its needs because of a corporate directive.

I could go on. I will go on. Here are some other problems I've encountered with shared platforms:
  • They stifle innovation, or they're perceived to which amounts to much the same thing. Most innovators will want to work rapidly outside the platform rather than deal with its constraints: do you really want to slow down work on a prototype in order to make it platform-compliant?
  • Platforms are a lightning rod for politics. In my experience there is always a battle between platform centrists and application separatists that becomes a power struggle, sapping energy and diverting attention from what really matters: the utility of the solution.
  • They become legacy, instantly. Since new products will begin outside the platform, the platform itself becomes the embodiment of legacy.
  • They force compromises in order to come up with shared services. Not bad in itself, but user interfaces come out badly from these sorts of compromise.
  • They're costly. Developing features in line with the constraints of a platform is often more expensive that just doing them. However this should of course be balanced by features that the platform brings to each product for free.
Clearly these software platforms are a terrible idea, right?

Well no actually: sharing and re-using software within a company is a noble and rational goal. It's just bloody hard to do right. I've wrestled with this problem for years in a few companies and while I haven't cracked the problem - and it's a slightly different problem every time - there are some lessons I've learned.

So if you do find yourself in the desperately unlucky position of leading the development of a software platform, consider the following:
  1. Have a plan from the outset for innovation and prototypes. Sponsor new initiatives - don't try to kill them because they don't fit with today's platform.
  2. Set up the platform development to iterate quickly so that you can respond to the needs of projects. Agile methods with short iterations is the only way to go.
  3. Nothing is more important than the design of API's and getting the right balance between simplicity and power.  There's a world of knowledge out there about how to do this so go and do some research. Be ready to make mistakes and start over. 
  4. Support all products equally.  Be ready to leave some products outside the platform if including them would cause too much disruption to the architecture.
  5. It's impossible to create a good platform by carving it out of an existing product - a platform has to be designed for that purpose then honed with application experience
  6. Keep the platform as small as possible - don't get it involved in every piece of product development. I like the principle of subsidiarity which basically means only centralize when a goal is better achieved that way - otherwise let the projects do what they need to do.   (Subsidiarity is supposed to be a feature of the EU but often isn't  - that's a future topic for the BigLooLaa I think.)
  7. Be aware of the political power struggles and see them for what they are. The platform will need Architects and Technical Leaders who are good listeners and consensus builders who can defuse the politics. People who combine these skills with technical nous are rare so treasure them.
  8. Above all, the platform should be a distilled version of the best of your products. The greatest attribute of your products is usability or scalability perhaps? Well that's what your platform should do best. Often platforms take on a direction that is different from that of the products and a platform like that can never succeed.
  9. Be humble, ready to learn and willing to change your software.



Appendix: Cute Names, Big Challenges

ART - Adaptive Runtime Technology
The core platform for all the integration products at IONA technologies, the name is a marketing way of saying  "plug-ins dynamically loaded at run-time" but it gave us a pretty vocabulary for project names: Matisse, Warhol etc. We had lots of heated debated between our teams in Boston and Dublin, sometimes resolved by a shared interest in Guinness.

Oh, that reminds me:
  • Develop shared interests amongst users of the platform, especially those interests that lend themselves to a pub setting
JaNetOR - Java Network Oadapter Replacement
CORBA based O/R technology in Ericsson for a line of network management products. Functionally perfect but Java circa 1998 was a terrible choice for performance critical software. See suggestion #8 above.

STRIVESynthetic Tactical Real-time Interactive Virtual Environment
CAE's software platform for all of the simulated systems and environments in aircraft simulators.  From a developer's perspective STRIVE does the job; for a system integrator, a critical role when building a simulator, it badly lacks tools. Missing key requirement lie that is typical for a platform that was originally designed with one product  in mind and then adapted to others

iTopia - No idea. Perhaps this is where Steve Jobs is, now that he's iDead? (Sorry!)
This is the software platform I work with today. Since I apply everything I've learned, its development is totally smooth and uncontroversial. Cough.

No comments:

Post a Comment