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?

Technical architects - what are they?

I'm often asked to explain what a 'software architect' or 'technical architect' does. Is this just a title for highly-tenured engineers? A vanity title? A distinct role?

I believe software/systems architecture is a distinct role, and an important one, especially in the context of software that requires a more complex stack than simply PHP or RoR or (put your favorite tech here) backed up by a database:

1. Architects have to be comfortable working with higher-level abstractions - thinking in terms of separation and packaging of concerns, integration/intermediation and other patterns, problem and solution spaces before they zero in on specific point solutions.
    
2. Architects, compared with similar level engineers, have to trade some of the depth for breadth. This does not mean being superficial or glossing over important technical details. It means having enough depth - understanding the salient aspects but of more domains. A seasoned engineer is expected to have a more detailed knowledge, but of fewer domains.
    
3. Architects have to be comfortable with weaker ownership ties to many code artifacts - they may own an interface definition, but not its implementation, for example. Since most of us come to architecture after being seasoned developers, it's not always an easy transition.

Not every organization has the title 'architect', but most of those of sufficient scale do have people who play that role.