3 Ways Enterprise Architects Can Bridge the Socio-Technical Gap
09 August 2023
Request your demo of the Sigrid® | Software Assurance Platform:
17 February 2020
2 min read
Reading the usual stories on technology, one can’t help but think there’s continual progress. Things are always improving, every new release is better, every new piece of technology is better than the one before. This way, we’re constantly getting better and life is improving almost on a daily basis. But is this always the case?
In aerospace, you may be familiar with the “Concorde moment,” the moment where technology suddenly took a step back. I never had the pleasure of flying on the Concorde; the only time I ever saw it was as a tourist in New York, where it proudly stands on the Intrepid aircraft carrier, a testimony of past technology. The Concorde made it possible to cross the Atlantic in three hours, making a business trip to New York for a day quite feasible (though a tad expensive). Then, due to cost reasons as well as a very unfortunate disaster, the Concorde stopped and we all had to fly below Mach 1 again.
It’s typically seen as a one-off, but there are more examples. The introduction of the iPhone definitely made a lot of things better and faster. But now almost 13 years later, the typing on a smartphone is still indescribably worse than on a Blackberry. I, and many others, could type blindly on a Blackberry. The lack of true tactile feedback makes typing blindly more difficult (not impossible, but certainly more difficult). Of course, there are ways to get close to it, but typing definitely got worse. Other things improved enormously, but not in typing.
I recall a particular situation many years ago, when I was involved in a different company where we had to re-architect our system. We knew this re-architecture effort would bring enormous advantages and scalability opportunities, so it was a must-do. On the other hand, we lost an important capability. In the old architecture, changing the data model could be done instantaneously, which was a great advantage while implementing and demoing to prospects. But in the new architecture, data model changes had to be propagated to the database, which would cost at least five minutes. Definitely acceptable, but certainly a step back. We discussed it at length, and feared tremendous pushback, but in the end, it turned out all the advantages far outweighed this clear disadvantage. But the initial focus on the disadvantage, our Concorde moment perhaps, almost made us think differently.
These Concorde moments happen often, and we need to be explicit about them. I would advise making your Concorde moments explicit to your users and clients and explain why they happen. Don’t just bury your steps backward under a stream of nice new features. And maybe more importantly, don’t be afraid to make the change. Sometimes, the Concorde moment is really necessary to take the next step forward.
As the French say, Reculer pour mieux sauter (take a step back to jump farther). Not sure where the step forward in the actual Concorde moment is hiding, to be honest.
We'll keep you posted on the latest news, events, and publications.