架构框架：有意义还是荒谬？

本周早些时候，有人在LinkedIn上联系我，他在收听我参与的一期关于安全架构和云迁移的播客后，正考虑从安全工程师转向架构师角色，希望获得成功转型的建议。他特别想了解我对SABSA（Sherwood应用业务安全架构）等架构框架的看法。这次讨论促使我重新思考对架构的看法，以及过去关于框架的漫长争论。

应该说，我对架构框架怀着爱恨交加的感情。我热衷于有组织的批判性思维训练，因此框架的概念很吸引我。然而在实践中，它们往往会变成无意义的智力练习，就像神学家争论针尖上能站多少天使一样。根据我的经验，似乎没有人对架构框架真正满意，因为它们通常晦涩难懂且深陷复杂性泥潭。

从我工作过的组织来看，如果存在架构框架，通常都是TOGAF（开放组架构框架）的某种衍生版本。这并不意味着组织内部有人特意选择它作为最适合自身环境的方案，只是因为TOGAF存在时间足够长（始于1995年），已渗透到架构实践中并因此嵌入各类组织。

无论技术组织采用何种框架，我发现安全架构师要想有效协作，就需要与其他架构师使用的框架保持一致。这可能基于TOGAF，也可能是完全不同的方案。遵循他们的引领，你会更容易将安全融入实践。不过我从未见过哪个组织严格遵循TOGAF或其他框架，通常都是经过精简的实现，此时再叠加SABSA往往显得过于沉重和复杂。根据我的经验，我从未见过拥有成熟架构实践的大型组织使用像SABSA或TOGAF这样详细的框架。

但我承认自己没有接受过太多正式的架构培训。坦白说，我认识的专业架构师中也鲜有人接受过系统培训。也许这就是为什么存在许多糟糕架构师的原因，或者这反映了架构师的培养和训练方式——通常是非正式的。不过，我花了大量时间研究这类框架，以成为有深度的技术专家。我个人发现，当试图将架构讨论聚焦于通用分类法时，TOGAF框架和文档很有帮助。最重要的是，我信奉实用主义：与其他架构师在现有基础上协作，努力识别他们正在使用的共同框架，从而与同事成功合作。因为关键不在于使用最好的框架，而在于找到适合组织当前成熟度的可行方案。