The biggest advantage may be consistency. Once everyone in the organization becomes familiar with the techniques and theories, finding the way around the software becomes easier. The data and the code is (usually) structured so that everything is in a predictable place.
Some people take it too far, however. Instead of just adopting the rules, they join a cult. They read the specs with such thoroughness that every decision must be made following the rules. Woe be it to thee who strays from the path.
But even if everyone buys into the cult of the framework and the office planning meetings are filled with happy rule followers, other problems can creep in. Sometimes teams reject perfectly good open-source code simply because it doesn’t align with their desired architectural framework. Sometimes they refuse to work with vendors who offer good options that, alas, wasn’t developed with the right philosophy.
Adhering to methodology above all
Frameworks can give structure, but they can also give cover for sloppy, lazy, or even malicious behavior. Sometimes teams can drag out decisions because they’re waiting on someone to fill out the right TOGAF form. There’s a fine line between supportive rules and stultifying red tape.
One guy I worked with loved the Agile methodology and he managed to twist it enough so his team was anything but agile. He knew all the meeting rituals and was great at filling his “sprint” with lots of story points for refactoring code that was written just last week. His team never seemed to be moving very fast at rebuilding the credit card checkout method that he was supposed to deliver, but if you look at the graph of Agile points earned each sprint, his team had the greatest velocity in the office.
We need some kind of method for organizing the development workflow. Programmers can argue for days about whether something is agile this or waterfall that. If the project is bigger than one person can handle on a weekend, well, there needs to be some kind of strategy.
The problems come when you begin to believe more in the methodology than what your eyes can see. When that happens, clever coders can game the system and earn big prizes even if their code doesn’t do much of anything.
Following (or ignoring) the trends
Developers love to latch on to the latest ideas and models for enterprise architecture. Sometimes they’re lucky and the new trend actually fits their needs. Their application is a good example of what drove the trendsetter to come up with the idea in the first place.
But that’s often only partially the case. Use cases may bear resemblance to the application that inspired the trend but only after a bit of hand waving. In the meantime, dev teams are stuck frantically trying to make their code fit the trend. Sometimes huge blocks of perfectly adequate code are tossed away, just because they were written toward some formerly trendy goal.
The problem is that completely ignoring trends can be just as deadly. Sure, your code has stayed true to some original vision using databases, formats, coding standards, and protocols that work just fine, thank you. But if the entire world has gone chasing some trend, then so have all the vendors, tool makers, and potential new hires, too. At some point, trends and fads can become standards and sometimes something even worse: legal compliance requirements.
Enterprise architects can’t win. If they follow the trends, they’re slaves to fads of the mob. But if they ignore them, they can get left behind. All they can do is cautiously try to do the right thing for the organization’s tech stack and the IT pros who must tend to it.
