Additional Integrational Hybridization

For some unaccountable reason, my semi-coherent bluster a couple of weeks ago wandered across the topic of integration when discussing Windows Azure hybrid applications. Since then, I’ve been delving deeper into the whole area of hybrid application challenges as we fine-tune our thoughts on the third of our series of guides about designing and developing applications for Windows Azure. And it seems that we in the IT developer community are dragging our heels when it comes to inventing exciting new words.

Yes, there are lots of new words entering the world’s languages all the time, but in recent years these seem to be coming from the general public. Words such as “Graycation” (going on holiday with your grandparents), “Spinnish” (the language used by politicians and spin-doctors), and “Blamestorming” (having a meeting to decide whose fault it was) are useful, but reveal the shortcomings of the great unwashed who can only manage to munge two common words together.

Not so long ago it was the IT community that was in charge of creating exciting new words (“munge” as used in the previous paragraph is a classic). And we surely hold the trophy for turning abbreviations and acronyms into words – think “RAM”, “GUI”, “AMOLED”, and “PCMCIA” (OK, so some aren’t pronounceable even if they do sound like a Village People song). In fact, the Enterprise Library team here at p&p excelled recently with “WASABi”. Supposedly it stands for Windows Azure Scaling Application Block integration, though why they want to associate it with rather pungent green stuff I’m not sure.

But where there must be real opportunity for exciting and useful new words is when describing concepts in software architecture. And “integration” (as in WASABi) is a perfect example. Last week’s vague meanderings into Enterprise Application Integration (EAI) revealed that – as far as hybrid Azure applications are concerned – it’s not really integration that’s the core challenge, it’s the opposite. Rather than trying to figure out how to get disparate applications and components to work together, it’s more about trying to get cohesive applications and components that already work together to still do so when there’s a big lump of Internet in the middle.

Hybrid application challenges are primarily concerned with making communication, service access, and business logic work across the new boundary you introduce when you evolve an existing on-premises application so that some parts run in the cloud, or when you design a new application with some parts in the cloud and other parts on-premises or hosted by external partners. You aren’t integrating the bits, you’re separating them. But “separation” doesn’t seem to hit the spot.

I wondered about “intragation” or even “extragation”, but the alternative prefix on these doesn’t work because “integrate” comes from the Latin word “integratus” meaning to renew or restore. Neither does it seem reasonable to use the real antonym “disintegrate” (unless, of course, your code blew up when you ran it). So, after much head-scratching, I’ve decided to propose an exciting new word as an addition to our IT glossary of terms:

hybrigation (noun) [hi-bree-gay-shun] Making all the parts of a hybrid application work together across the on-premises, cloud, and partner domain boundaries.

Though they probably won’t allow me to use it in our new guide…

Comments (0)

Skip to main content