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\u2019s 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.\n\nTo the casual end-user, manager, or C-suite exec, an enterprise architect\u2019s 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.\n\nEnterprise architects are still learning, experimenting, and then learning more about what they should do and \u2014 more importantly \u2014 what they can\u2019t 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.\n\nStoring too much (or too little) data\n\nSoftware developers are pack rats. If they can, they\u2019ll cache everything, log every event and store backup copies of the enterprise\u2019s 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.\n\nTo 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?\n\nThe 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, \u201cWe don\u2019t have that file.\u201d No one knows anything.\n\nFinding 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\u2019t seem like everyone is just fumbling around in the dark spending most of their time looking for a light switch.\n\nRelying too much on one platform (or embracing too many)\n\nThe 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.\n\nBut 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\u2019t 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.\n\nSpreading 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.\n\nThere\u2019s 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\u2019t even spoken about the cost of bringing all development in house.\n\nOutsourcing too much (or too little) to the cloud\n\nThe 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.\n\nThe 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\u2019re often larger than anyone expected.\n\nBut doing the work yourself means managing \u2014 and paying for \u2014 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.\n\nSome 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\u2019ve invested too much or too little in the cloud.\n\nEmbracing (or ignoring) the cult of framework\n\nNow the complexity of today\u2019s 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.\n\nThe 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.\n\nSome 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.\n\nBut 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\u2019t align with their desired architectural framework. Sometimes they refuse to work with vendors who offer good options that, alas, wasn\u2019t developed with the right philosophy.\n\nAdhering to methodology above all\n\nFrameworks can give structure, but they can also give cover for sloppy, lazy, or even malicious behavior. Sometimes teams can drag out decisions because they\u2019re waiting on someone to fill out the right TOGAF form. There\u2019s a fine line between supportive rules and stultifying red tape.\n\nOne 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 \u201csprint\u201d 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.\n\nWe 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.\n\nThe 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\u2019t do much of anything.\n\nFollowing (or ignoring) the trends\n\nDevelopers love to latch on to the latest ideas and models for enterprise architecture. Sometimes they\u2019re 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.\n\nBut that\u2019s 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.\n\nThe 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.\n\nEnterprise architects can\u2019t win. If they follow the trends, they\u2019re 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\u2019s tech stack and the IT pros who must tend to it.