Business Analyst as a Bridge Revisited

Periodically there is a discussion on a LinkedIn referencing the analogy of a Business Analyst to a bridge - usually a bridge between the business and IT.  A recent discussion suggested that the bridge has abutments and the business analyst is more like the abutments than the bridge itself. I typically point out, as I have in an earlier post that the bridge analogy is incorrect and that I feel as long as we see ourselves as bridges we will not fulfill our role as business analysts to the full extent we can.  The conversation went on and I suggested in a post that perhaps we might be considered 'hubs' rather than 'bridges' if we need an analogy responding to someone's suggestion of 'cog'. 
It took a while thinking about it, but then I realized what the real dangers are of the bridge metaphor are.  Here is my posting on the subject:

Going back in time I remember I when I was a programmer in the 60s we talked directly to the business people and sketched report formats, and drew up our own 5081 card layouts and even the scrolled conversation when we had terminals. Of course, IT was called Data Processing then and we were software engineers.

Then i was a programmer analyst because things got complicated and the few of us engineers who could put a meaningful sentence together and did not scare the business people were dispatched to talk with the stakeholders. But we still did all the interface design work and the business modeling and the like.  And then it was called MIS.

Time went on and I became a Systems Analyst which was cool.  Things got more complicated on both sides and the programmer analysts were morphing into more technical specialties like communications programming, network programming, database programming, etc. But I was still doing the same thing, although on a larger scale, evaluating business processes for conversion into 'systems'.  And it was now called IS. The "M" was dropped for a number of cynical reasons.

Then came the Business Analyst because systems analysis became too complicated and complex.  And so did business.  And the whole process of merging technology with business splintered. There were user interface designers and business process modelers and information architects and web design specialists and programmers became developers and testers became Quality Assurance and business analysts stepped into the middle.  And IS became IT.

Now here's the point:  we started off trying to merge business and technology, working together.  As things got complicated and complex, we added layers between and literally separated the two areas.  Now there is a movement (that has been going on for nearly 20 years) on many fronts to get back together again.  The concept of the bridge does nothing to merge business and technology. In fact, it makes it clear that there is only one connection between the two sides: the bridge, and emphasizes the separation of the two sides, else why would a bridge be needed?

Is there a better metaphor that would get all business analysts thinking in terms of closing the gap, rather than bridging the gap?  Is not one of the roles of the business analyst to blend technology into the business seamlessly so that using a computer based function is as natural as using paper and ink?

How about calling ourselves the 'glue of the organization' rather than the bridge?  Even the 'cog' or 'hub' analogies mentioned earlier imply that the components are separated by spokes, the only connection between the hub and component. I am not sure 'glue' is the right image because there are off-putting aspects of being considered 'glue' (stickiness, residue, hanging by a hard hat stuck to a girder, and so forth), but I am sure there is a better analogy or metaphor to depict our real role in the organization in terms of connecting business and technology.