6 deadly sins of enterprise architecture

Keeping the enterprise running has never been an easy task. The rise of software tools have made many parts of the workflow faster, smoother, and more consistent for everyone but those who have to keep the software running. It’s like the old line about a duck gliding along a pond: Everything above the water looks placid, while below the water line the feet frantically paddle.

To the casual end-user, manager, or C-suite exec, an enterprise architect’s job is magical. The endless chores of synchronization, organization, and stabilization all handled by computers so humans can do what they do best. But all the web portals, collaboration stacks, and repository omnitools hide the endless challenges of keeping everything straight. For all its advances, enterprise architecture remains a new world filled with tasks and responsibilities no one has completely figured out.

Enterprise architects are still learning, experimenting, and then learning more about what they should do and — more importantly — what they can’t do. Along the way many mistakes have been made and are likely to be made again and again as we search for the best way to keep the software stacks running and the working life of everyone throughout the organization as simple as possible. Some of this is due to the highly technical and complex nature of the job. But some of it is because of the following sins we enterprise architects keep committing.

Storing too much (or too little) data

Software developers are pack rats. If they can, they’ll cache everything, log every event and store backup copies of the enterprise’s endlessly evolving state. But all those gigabytes and petabytes add up. Even at the lowest costs of cold storage offered by some of the cloud vendors, the little charges can be significant when the data is big.

To make matters worse, finding the right bits gets harder as the data lakes get filled to the brim. Like that warehouse at the end of Raiders of the Lost Ark, technically all the information is there, but can you ever find it?

The problem is that keeping too little information comes with its own failure modes and pain points. Some companies have tried setting data retention policies to destroy everything as soon as regulations allow. But then the enterprise muddles along with a kind of amnesia as every answer to every question seems to be, “We don’t have that file.” No one knows anything.

Finding the right balance may be impossible. All we can do is try to find a good data storage architecture that files away the right information in an easily accessible structure so that it doesn’t seem like everyone is just fumbling around in the dark spending most of their time looking for a light switch.

Relying too much on one platform (or embracing too many)

The simplest way to build out enterprise software is to leverage the power of various tools, portals, and platforms constructed by outsiders. Often 90%+ of the work can be done by signing a purchase order and writing a bit of glue code.

But trusting the key parts of an enterprise to an outside company has plenty of risks. Maybe some private equity firm buys the outside firm, fires all the good workers, and then jacks up the price knowing you can’t escape. Suddenly instantiating all your eggs in one platform starts to fail badly. No one remembers the simplicity and consistency that came from a single interface from a single platform.

Spreading out and embracing multiple platforms, though, can be just as painful. The sales team may promise that the tools are designed to interoperate and speak industry standard protocols, but that gets you only halfway there. Each may store the data in an SQL database, but some use MySQL, others use PostgreSQL and others use Oracle.

There’s no simple answer. Too many platforms creates a Tower of Babel. Too few brings the risk of vendor lock-in and all the pain of opening that email with the renewal contract. And we haven’t even spoken about the cost of bringing all development in house.

Outsourcing too much (or too little) to the cloud

The cloud has made life much easier for enterprise architects. If someone needs a machine of a certain size, well, it can be available in minutes. No need to fill out purchase orders. No need to find rack space. No need to do anything but give the cloud company your credit card number.

The upsides of having any machine available in minutes or even seconds are obvious. The biggest downside is the price. Cloud computing is often dramatically more expensive than doing the work in-house. Many CFOs dread opening up the cloud bills each month because they’re often larger than anyone expected.

But doing the work yourself means managing — and paying for — a staff, a data center, and more. The list of headaches and regulations can be long and the joy that comes from a smaller budget can be fleeting.

Some enterprise architects can win big with the cloud. If your demand spikes for a small amount of time each week, month, or year, spinning up the servers needed to handle the load for just a few minutes or hours can be dramatically cheaper than doing anything in-house. Everyone else is left wondering whether they’ve invested too much or too little in the cloud.

Embracing (or ignoring) the cult of framework

Now the complexity of today’s enterprise stacks, some smart architects have created frameworks to help organize them. The Open Group Architecture Format (TOGAF), for instance, is a strategic framework for building practically everything an enterprise would need. It offers a number of guidelines and best practices including an architecture development method (ADM) and an architecture compliance framework (ACF), among other acronyms. Others approaches, such as the Zachman Framework or the Federal Enterprise Architecture Framework (FEAF), bring their own versions of rules and regulations for building out a stack.

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.