一、捷径难寻
企业级建设是一个美好却艰难的愿景。了解领域驱动设计（DDD）的朋友可能知道，DDD 对企业级建设并不乐观，它认为企业级的实现只能一个领域一个领域地尝试和融合，自底向上生长，而非自顶向下规划。
在金融领域，业务五花八门，看似都在同一领域，实则“各不相干”。比如传统存贷款、票据业务、现金管理、交易银行、托管、养老金业务以及新兴的资管、理财等，它们之间差别很大。客户和账务可以说是企业级的部分，但其他部分就像 DDD 主张的那样，得逐个领域建设。
所以，企业级建设的难度与所在行业特点直接相关，没有通用的业务模型可套用。银行不能照搬阿里的业务架构，阿里也不能套用银行的架构。甚至同一行业内，不同企业的内部特点也决定了企业级建设路径和结果的不同。这是企业级的第一大难题，没有捷径可走，别人的经验只能借鉴，自己的路还得自己摸索。不过，有做过企业级实现的科技公司或开发团队带路，会有很大帮助。
二、文化难建
企业级在很多时候不只是技术问题，这让技术人员很为难。比如综合积分的案例，就需要多方协调。在传统企业中，建立企业级就像一场“内战”，要重新界定部门边界和协同关系。
建企业级真有那么可怕吗？要么是之前各部门分工合理（基本不可能），要么是没解决真正问题却一团和气地结束了（很有可能）。如果下定决心做企业级，传统企业要改造的东西太多了。引入新方法、新思维带来的冲击需要大量时间消化，这是一个大转身。在此过程中，业务和文化的调整都很重要，尤其是企业文化。现代管理学之父彼得·德鲁克说过：“文化能将战略当午餐吃掉。”可见企业文化调整之难。
三、预期难控
人们常说“期望越高，失望越大”。企业级建设耗费大量人力物力，各方往往寄予厚望，把蓝图描绘得过于美好，期望多年夙愿能“毕其功于一役”。但建设周期长、过程曲折以及不断对现实妥协，会让理想大打折扣，项目进度也可能一拖再拖，结果不如当初设想的美好。
有些问题不是企业级才能解决，有些成果也不一定归功于企业级，成本和收益还难以直接计算。就像从单体应用到 SOA、微服务的演变，灵活性提升的同时通信和维护变复杂了，企业级效果可能要慢慢显现。这会让人对企业级产生怀疑。所以要管理好企业预期，别给企业级项目戴太多不该戴的“高帽”，而应重视企业文化建设和整体转型。
转型就是转变行为习惯，观察企业各级领导和员工的行为习惯是否改变，就能判断转型项目是否成功。如果行为符合预期，即使系统目标未完全实现，也只是需要更多时间而已。
四、权责难定
在组织中，事情要做好，做事的人就得权责匹配。企业级转型期间，临时性项目组织架构可拥有较大权力保证项目落地。但转型结束进入常态开发后，架构如何定位呢？
若权力太小，不足以维护企业级，企业级可能会“名存实亡”；若权力过大，又会变成新的部门化组织，阻碍架构创新。对于传统大型企业来说，“官本位”思想严重，这个问题很常见。企业级建设要让企业正视技术定位，思考数字化转型后的管理结构，技术到底是工具、主业，还是脑或手？对架构师的合理定位也是企业的大考验。
传统企业通常把架构师当技术专家，缺少“架构师”岗位和有意识的培养，导致项目实践经验难以转化为方法论层级的知识。好的架构师能帮助企业实现合理规划，是数字化转型的关键力量。阿里智能云事业群总裁张建锋也说过，大部分企业缺少非常好的业务架构，而业务架构只能自己培养。
五、长志难立
企业级的长期坚持很难。就像减肥，很多人花钱花时间减肥，但真正坚持到底不反弹的很少。企业也一样，水会流向阻力最小的地方，企业级的放弃可能是缓慢的无序，由一个个需求的偏离堆积而来。
企业级维护难度高，很难与个体、局部利益明确结合，很多时候靠员工自觉。这又涉及到战略和文化问题，也就是如何打造“伟大的企业”。
企业级建设的这些难处，让大型传统企业的企业级建设与互联网科技公司有很大不同。对于后者，更多是技术规划和技术栈建设问题；对于前者，非技术因素与技术因素同等重要。
参考：《企业级业务架构设计方法论与实践》 付晓岩著
