Integrating the unintegrated

Dear Bob …

We are an organization constructed out of recent acquisitions — more than a half dozen large modules maintained by geographically and organizationally dispersed teams. The product manager’s official goal is application performance.

We don’t have an integration strategy. While I goal is to “have the best products and dominate the market,” top management oversimplifies the problems, middle management strikes defensive postures, and the troops on the ground mix confused inertia with deep anxiety.

Any thoughts on what we should to to improve the situation?

– Dis-integrating

Dear Dis …

I’m going to limit my answer to what I think the organization should do (the usual disclaimers apply). How you persuade the organization to go about doing it is, of course, more complicated in that it requires a lot of persuading, mostly in areas where you have little authority.

If you trace everything back, I think the key is the need for and absence of architecture management. The good news is that this missing piece will impair overall application performance along with the other problems it’s likely to cause – especially, an incoherent product line and excessive cost and time for creating new releases.

So what I’d recommend is establishing a product architecture group, responsible for managing the convergence and integration of the various acquired pieces according to a target architectural plan.

Rather than creating this group from scratch and putting it in charge (which would create major organizational angst among the existing constitutencies, probably making the whole thing impossible) I’d suggest federating the function. Establish an “architectural council” with each product group contributing a member. The chair should be someone independent of the politics; the tough part is that the chair needs to be both a good engineer and a strong facilitator and leader.

This group has authority over:

* Product module boundaries (so different groups don’t create overlapping functionality).

* The target data architecture, standards, and naming conventions.

* Application interface architecture and syntax.

* Regression and integration testing.

One other bit: Team dynamics. The product architecture group needs enough face-to-face time together to work through issues, turn itself into a team, and establish an architecture management process so it doesn’t address every issue through nothing more than knowledge and ingenuity. Making this work will be difficult enough. It will be impossible if the group’s members see themselves solely as representatives of their home constituencies. They need to build trust and good team dynamics so when they go back to their “home” teams they can attest to the validity of the plan.

– Bob

——–