基于我的研究,这里有一些架构审查清单,我发现这样做的问题更公正一点,并提供了一些背景什么是架构审查。(这里似乎有点困惑。)

每一个潜在的候选人都包括许多不同的类别。根据业务需要,这些类别的总体重要性会有所不同。嗯,没关系。在审查和排除检查表时,问另一个问题的成本要比完全漏掉一个问题或一个类别的成本低得多,因为它看起来不太重要,不足以包括在最初的检查表中。

• “ Software architecture review guidelines “亚历山大·诺瓦克
• “ Review Checklist for Architectural Design Document[s] “作者:Tom Verhoeff
• “ Checklist: Architecture and Design Review “来自Microsoft模式与实践开发中心
• “ Conceptual Architecture Checklist “作者:Craig Borysowich
• “ App Arch Guide 2.0 Knowledge Base: Checklist - Architecture and Design “作者:J.D.Meier、Alex Homer等。(通过彼得·斯图尔的链接找到)
• “ TOGAF Architecture Compliance Review Checklists “来自开放组
• “ Architecture Review Process “Ricky Ho

虽然我没有读过,但似乎还有一篇关于这个主题的白皮书。它试图用大约11页的篇幅来回答这个问题。

• Architecture reviews: practice and experience Maranzano、Rozsypal等人

另外,一位同事推荐了斯普林格的一套书,尽管我自己没有检查过:

• The Enterprise Engineering Series 来自Springer

还有一些需要考虑的问题:

• 是否确定了所有利益相关者?(示例:客户、最终用户、业务分析师、用户界面设计师、开发人员、测试人员、维护人员)体系结构是否经过利益相关者的验证?
• 体系结构如何解决安全问题?
• 是否规定了可用性和可靠性要求?体系结构如何解决这些问题?(示例:平均故障间隔时间、平均修复时间。)
• 如何处理灾难恢复?

两本好的书可以提供更多的想法:

• Software Systems Architecture 作者:Nick Rozanski和E_3 in Woods
• Software Architecture in Practice 作者:Len Bass、Paul Clements和Rick Kazman

你打算怎么测试它

它是否使用可靠的原则?

架构是否符合技术供应商的指导和路线图?

你想从你选择的平台得到支持,而不是与之抗争。

例如,对于以Microsoft为中心的解决方案,这意味着记录您的选择与 Microsoft Architecture guidance .

有没有一个人能用足够的时间来负责建筑 (1)拟建建筑的技术知识; (2)管理事物的经验; (3)站在公司的立场,使其决定不会被一个不知情的管理者推翻。

因为(2)和(3)并不真正依赖于架构,我会找到那个人,问他想做什么。

现在假设你是那个人(从你的问题上来说这并不明显——这只适用于你认为你会在一段时间内仍然是这件事的首席架构师的情况),我会考虑 advice of Joel On Software blog 写一份设计说明书,包括计划,目标,客户,解释设计选择,一切。这应该能使视野开阔。

后世思想

我试着想一想,在编写了规范之后,您可能会问自己哪些确切的问题,比如“是否易于更新项目”、“是否允许最终目标的灵活性”、“是否会使支持变得容易”、“是否存在安全问题”等,但是,尽管有必要问这样的问题,我只是不想。看不出它们可以用于任何“评估”,因为除了过滤掉明显的错误之外,我认为没有任何 具体的 这个问题对“评估体系结构”有很大帮助。也许你的问题会从重新措辞中受益?