The Uphill Battle for Architecture
There have been a long list of challenges (some would say fights) as IT and Enterprise Architecture have improved and become accepted in businesses of all sizes. I want to talk about one that is self inflicted: our lack of professionalism.
I have directly witnessed the training required by a student of various professions, from attorney to nurse or building architect. And one thing that these training programs have in common: students wanting to learn and practice this profession MUST adopt a standardized “language”.
It’s not difficult to recognize a standardized language. In the law, the concept of a “tort” is standardized. In medicine, there is one word for the “femur”. We don’t say “leg bone” to refer to this particular body part.
Similarly, in building architecture, there are types of drawings that are included in a package of blueprints, and their stakeholders are well understood.
IT and Enterprise Architecture have worked to create some of the standard terms and methods. But we have not standardized the right things, and we have not taught our stakeholders what our standards actually are.
As a result, I may describe an architecture, but if no one can read, understand, and build the architecture as I’ve described it, then the result will not look ANYTHING similar to my description.
This happened to a wonderful client I had a few years ago. They wanted to modernize their systems and retire an old mainframe package (yes, people are still running COBOL on mainframes). We worked to create an excellent services-based cloud native architecture and to find a software package that could fulfill their needs.
On three different occasions, I worked with this client. The first was before the selection of a software package, the second was after a package was selected but before much of the integration software was written, and the third time was as the final deliveries were made. Each time, I updated the diagrams to reflect the intent, the possible, and the reality.
The biggest challenge I faced was not the challenge explaining the architecture to my stakeholder. It was in describing in real terms the architecture to my development team in India. The developers had no idea how to read the models or what they meant.
And the product managers couldn’t understand that there was a knowledge and skills gap, so they viewed my presentation of the architecture as “sufficient, now go build”.
The result was a working system but not a modern one. The developers did not “future proof” the installed system with services. All integrations where point-to-point and leveraging limited mechanisms for integration. Honestly, I was embarrassed.
But rather than curse the darkness, I think it’s time to light some candles. We have spent a decade teaching the architects to use common terms (they still do not). But now it’s time to teach the ENGINEERS how to read and use architectural models.
We have to get on the same page as architects before we can expect the engineers and developers and infrastructure implementors to trust us.