对于临时的最终用户、经理或高级管理人员来说，企业架构师的工作是神奇的。无休止的同步、组织和稳定的琐事都由计算机处理，这样人类就可以做他们最擅长的事情，但所有的门户网站、协作堆栈和存储库万能工具都隐藏着保持一切顺畅的无尽挑战。尽管企业架构取得了进步，但它仍然是一个充满任务和责任的新世界，没有人完全弄清楚。
企业架构师仍然在学习、试验，然后更多地了解他们应该做什么，更重要的是，他们不能做什么。在这个过程中，我们已经犯了许多错误，而且很可能会一次又一次地犯错误，因为我们正在寻找最好的方法来保持软件堆栈的运行和整个企业中每个人的工作生活尽可能简单。这在一定程度上是由于这项工作的高度技术性和复杂性，我们的企业架构师经常犯下以下错误。
存储的数据太多(或太少)
软件开发人员是成群结队的人。如果可以，他们将缓存所有内容，记录每个事件，并存储企业不断发展的状态的备份副本。所有这些GB和PB加在一起，即使一些云供应商提供的冷存储成本最低，但当数据量很大时，收取的费用可能会很高。
更糟糕的是，随着数据湖被填满，找到合适的比特变得更加困难。就像《夺宝奇兵》结尾的那个仓库一样，严格来说，所有的信息都在那里，但你能找到吗?
问题是，保留太少的信息会带来自己的失败模式和痛点。一些公司试图设定数据保留政策，在法规允许的情况下尽快销毁一切。但随后，这家企业就带着一种健忘症糊涂了，因为每个问题的每一个答案似乎都是，“我们没有那个文件。”没有人知道任何事情。
找到合适的平衡可能是不可能的。我们所能做的就是努力找到一个好的数据存储体系结构，将正确的信息保存在一个易于访问的结构中，这样就不会让人觉得每个人都只是在黑暗中摸索，花了大部分时间寻找电灯开关。
过于依赖一个平台(或包含太多平台)
构建企业软件的最简单方法是利用外部人员构建的各种工具、门户和平台的力量。通常，90%以上的工作可以通过签署采购订单和编写一点胶水代码来完成。
但将企业的关键部分委托给外部公司存在大量风险。也许一些私募股权公司收购了外部公司，解雇了所有优秀的员工，然后在知道你无法逃脱的情况下抬高了价格。突然，在一个平台上实例化您的所有鸡蛋开始严重失败。没有人记得来自单一平台的单一界面所带来的简单性和一致性。
然而，扩展和拥抱多个平台可能同样令人痛苦。销售团队可能会承诺，这些工具是为互操作和使用行业标准协议而设计的，但这只让您实现了一半。每个数据库都可以将数据存储在SQL数据库中，但有些使用MySQL，有些使用PostgreSQL，有些使用Oracle。
没有简单的答案。太多的平台造成了不兼容。太少会带来供应商锁定的风险，以及使用续订合同打开电子邮件的所有痛苦。我们甚至还没有谈到把所有开发项目都放在家里的成本。
将太多(或太少)外包给云
云让企业架构师的生活变得容易得多。如果有人需要一台特定大小的机器，那么，几分钟内就可以买到。不需要填写采购订单。无需寻找机架空间。不需要做任何事情，只需要给云公司你的信用卡号码。
任何机器在几分钟甚至几秒钟内就可以使用的好处是显而易见的。最大的不利因素是价格。云计算通常比内部工作的成本高得多。许多首席财务官害怕每月打开云计算账单，因为它们往往比任何人预期的都要大。
但自己做这项工作意味着管理员工、数据中心等。令人头疼的问题和法规清单可能很长，而来自较小预算的喜悦可能会转瞬即逝。
一些企业架构师可以通过云大获成功。如果您的需求在每周、每月或每年的一小段时间内激增，启动处理负载所需的服务器几分钟或几个小时可能比在内部执行任何操作都要便宜得多。其他所有人都在想，他们在云计算上的投资是太多还是太少。
依赖(或忽视)框架
由于当今企业堆栈的复杂性，一些聪明的架构师已经创建了框架来帮助组织它们。例如，开放式组体系结构格式(TOGAF)是一个战略框架，用于构建企业所需的几乎所有内容。它提供了许多指南和最佳实践，包括体系结构开发方法(ADM)和体系结构遵从性框架(ACF)，以及其他缩略语。其他方法，如Zachman框架或联邦企业体系结构框架(FEAF)，提供了它们自己版本的规则和法规来构建堆栈。
最大的优势可能是一致性。一旦企业中的每个人都熟悉了技术和理论，找到软件的方法就变得更容易了。数据和代码(通常)都是结构化的，因此一切都在可预测的位置。
然而，有些人做得太过分了。他们固守规则，而不是仅仅采用规则。他们如此彻底地阅读规格，以至于每一项决定都必须遵循规则。
但是，即使每个人都相信这个框架，办公室规划会议上充斥着快乐的遵守规则的人，其他问题也可能悄悄出现。有时，团队拒绝完全好的开源代码，仅仅是因为它与他们想要的架构框架不一致。
坚持方法论至上
框架可以提供结构，但也可以为草率、懒惰甚至恶意的行为提供掩护。有时，团队可能会拖延决策，因为他们正在等待某人填写正确的TOGAF表格。支持性规则和陈腐的繁文缛节之间只有一线之隔。
与我共事的一个人喜欢敏捷方法论，他扭曲了它，所以他的团队一点也不敏捷。他知道所有的会议例行公事，并擅长用上周刚刚编写的重构代码的许多故事点来填充他的“冲刺”。他的团队似乎从来没有在重建他应该提供的信用卡结账方法方面进展得很快，但如果你看看每一次冲刺获得的敏捷点数图，他的团队在办公室里的速度是最快的。
我们需要某种方法来组织开发工作流。程序员可能会争论几天，争论这件事是敏捷的，还是那件事是敏捷的。如果项目的规模超过了一个人周末的处理能力，那么，就需要有某种策略。
当你开始更多地相信方法论而不是你的眼睛所能看到的东西时，问题就来了。当这种情况发生时，聪明的程序员可以玩弄系统并赚取大奖，即使他们的代码没有什么作用。
追随(或忽视)潮流
开发人员喜欢抓住企业架构的最新想法和模型。有时他们很幸运，而新趋势实际上满足了他们的需求。他们的应用是一个很好的例子，说明了是什么驱使引领潮流的人首先提出了这个想法。
但这往往只是部分情况。用例可能与激发这一趋势的应用程序相似，但只是在稍微挥手之后。与此同时，开发团队陷入了疯狂的困境，试图让他们的代码适应趋势。有时，完全合适的大块代码会被丢弃，只是因为它们是为了某个以前流行的目标而编写的。
问题是，完全忽视趋势也可能是致命的。当然，您的代码使用了运行良好的数据库、格式、编码标准和协议，保持了一些原始的愿景，谢谢。但如果说整个世界都在追逐某种趋势，那么所有的供应商、工具制造商和潜在的新员工也都是如此。在某种程度上，潮流和时尚可能会成为标准，有时甚至会变得更糟：合法的合规要求。
企业架构师如果追随潮流，他们就是狂热的奴隶，但如果他们忽视了这些，他们可能会被甩在后面。他们所能做的就是谨慎地尝试为企业的技术堆栈和必须管理它的IT专业人员做正确的事情。
