应对不确定性的企业架构：需要考虑3个因素
我们经常听到这样的话，例如， “变化是一种常态 ”或者 正如Steve Case所说“快速变化和完全颠覆创造了巨大的机会 ”。尽管我们知道这是真的，但许多从业者似乎还是按照一套固定的时间点要求来设计和开发业务应用和系统。
软件开发引出了对业务应用持续再开发的需要，以应对新的机会。然而，持续集成/持续交付（CI/CD）的一个隐藏的副作用是，开发人员有可能产生糟糕的解决方案，通过不断地修复方案，来获得最佳实践。但是，敏捷软件开发团队通常使用的方法并不是唯一可用的方法。架构师可以而且应该更好地解决我们如何为变化而设计的问题。
在刚刚过去的“The Open Group企业架构从业者峰会”上，我们主导了一个“关于运用架构思维应对不确定性”的研讨会。会议中探讨了，为不确定性做准备，首先要重新思考开发代码和制作数据库的典型做法。技术并不总是唯一需要解决的问题。通过思考来解决，或者就架构师的情况而言，通过架构思维来解决，以鼓励架构师重新思考创建业务应用的规律。
不要害怕打破常规：
我们强烈建议架构师不要屈服于采用那些不能长期为IT从业者和组织服务的“最佳实践”。许多最佳实践只是名义上的“最佳实践”。
我们相信，架构师已经具备了帮助组织解决这一挑战所需的资质和能力，而架构思维正是展示其能力和对组织贡献价值的一种方式。然而，架构师们也需要确保他们不会因为过于倚重现有的一些应对机制而约束自己，包括：
• 设定一个硬性的范围边界
• 将范围覆盖率降到最低
• 将解决方案的构成部分简化为基本的通用结构
• 缩短规划的时间跨度
• 对内容进行删减，以便进行简单的比对
当然，上述这些非常有效的应对机制，可以帮助我们作为架构师有效地考虑和制定解决方案。但这里要指出的是，这些措施也是自定的，如果我们通过 "肌肉记忆 "采用它们而不认真考虑其后果，就会限制我们的工作方式和成果。
关于不确定性的三个想法要牢记于心：
你必须睁大眼睛才能看清楚。这里有几个关键点，帮助架构师进行改变：
1不确定性不是主要的关注点或兴趣点：架构师可以通过在组织内解除不必要的限制，引领批判性思维的发展，来证明他们的能力。
2不确定性是复杂的：IT从业者总是喜欢被需求驱动来工作。用确定的东西来工作是比较容易的。讨论企业中某人明年变化的需求可能是抽象的和令人生畏的。这项活动甚至可能显得毫无结果。但是，如果变化是不可避免的，我们必须开始为变化提供空间并开始使用适应性技术。
3当你学会如何应对不确定性时，你将永远领先一步：以随机的方式思考组织是最容易的，就好像它是大型的方程式中的另一个数字，而不是一个可预测的事件序列。
例如，你最喜欢的软件项目、解决方案或应用程序，可能已不再是1.0版本。这意味着每一个业务应用都已经被修订。修订不应该意味着代码的改变。一个新的版本或点式发布是代码改变的结果。其他技术可以用来减少编码修订的数量。思考解决不确定性的问题，开始在前期就引入一些技术。
重新评估你是如何应对不确定性的：
我们希望能够帮助你重新思考如何应对不确定性，并通过确保你的修订没有超出有用性来进行自我评价。
本文作者：Neal Fishman, Paul Homan
原文来源：redhat.com
注：所表达的观点仅代表作者个人，不代表The Open Group的观点或意见。
