Monday, June 25, 2012

Organizational map-reduce & the role of technical architects

What if you have a huge code base and a large organization with its multiple subdivisions responsible for owning/maintaining various parts of it?

Typically, any significant, core-affecting product development requires involvement of many of these sub-units. How does the organization manage such involvement?

The bad way: Meetings are set up, inviting everyone remotely related to the new thing so they can supply estimates for 'impact' to their domains. The most knowledgeable, and thus busy, invitees decide this is a waste of time and don't show up. Those who do show up throw some estimates into the ring just in case. Each participant may have their own idea/interpretation of what the target solution is.

The good way: The product owners work with their technical architects from the start, and by the time the grand map-reduce is required, it can be done in a context of a reasonable technical solution, which can be vetted by and singed up to by all the key affected parties.

Which would you choose?