| 前页 | 后页 |
好架构的特点
当关于“架构”上下文在 21 世纪的企业系统时间中的实际含义仍然存在激烈而持久的争论时，很难定义好的架构的特征是什么。 2000多年前，罗马建筑师维特鲁威在他的论文De Architectura 》中定义了良好架构的三个特征。有趣的是，它是古代描述架构的唯一幸存文本。这些原则是：
- 耐用性 ( Firmatis ) – 它应该坚固耐用并保持良好状态
- 实用程序 ( Utilitas ) – 它应该对使用它的人有用且函数良好
- 美丽 ( Venustatis ) – 它应该让人们高兴并振奋精神
良好架构的品质
为了有效，架构必须具有许多品质或特征。 Enterprise Architect提供了一套广泛的特征和工具来帮助建筑师制作高质量的架构。此表包含一些最重要的品质，并描述了如何使用Enterprise Architect来确保这些品质内置于工具中创建和维护的架构中。
质量 |
描述 |
也见 |
|---|---|---|
|
强大的 |
架构应该是强大的，并且不容易受到业务、信息、应用程序和技术系统的微小变化的影响。 Enterprise Architect可以帮助确保架构之间的良好集成，并提供许多工具，例如关系矩阵可追溯性插入相关元素特征等可用于此目的 |
|
|
可行的 |
无法实施的架构将意味着无法实现企业的目标和目标。最好尽快确定这些要求，以免让申请架构工作的一方失望。 Enterprise Architect可以通过允许架构师、设计师和开发人员讨论架构并使用讨论和审阅窗口确定其可行性并将企业架构映射到能力或解决方案架构来提供帮助。 |
|
|
实用 |
架构必须具有实用性，进而在实施时会产生实际结果。优雅但不能为利益相关者或征用它们的各方提供可证明和可衡量的价值的架构最终不会成功。 Enterprise Architect的工具允许架构被不同的利益相关者可视化和理解，允许在架构过程的早期发现实用程序的任何问题。 |
关系矩阵 |
|
耐用的 |
架构是描述目标状态的活实体，一旦实施，将成为新的基线状态。随着时间的推移，架构应该被证明是持久的，并且能够适应架构生命周期中可能发生的业务和技术环境的变化。这意味着他们必须——尽可能地——抢占未来的条件和环境。 |
|
|
灵活的 |
架构必须是灵活的，能够适应不断变化的条件，并且还为了解其学科知识的实施团队提供足够的指导，以便就技术问题和机会做出重要且必要的决策。创建过多细节的架构将通常会导致脆弱且不灵活的设计和实施，从而导致系统无法适应不断变化的环境和环境。 Enterprise Architect有一个广泛的特征，可以帮助更改元素、功能范围和基线图的变化，允许用户案例需求特征的可视化和优先级。 |
|
|
可验证 |
应该可以验证架构将按设计运行，并且不会因架构及其影响的企业部分而产生副作用。对此的最终测试是它是否能够实现愿景声明中承诺的商业价值。 Enterprise Architect可用于对定义的措施进行模型，以业务目标（以及目标）是否已实现。 |
|
|
优雅的 |
架构必须函数形式和功能，是衡量架构优雅的好方法。一个设计良好的架构往往是优雅的，并且具有简单的形式，这对于那些花时间研究它的人来说是显而易见的。 Enterprise Architect具有广泛的特征，允许将架构的优雅可视化，包括创建专业发布物的能力，这些发布物可以使用一系列内置或用户定义的模板从工具中自动生成。 |
|
|
可追溯 |
架构是在特定细节级别上对企业的描述，它不是孤立存在的，而是通常与业务驱动程序和目标以及相同级别或更高或更低级别的其他架构以及实施计划和项目相关。 Enterprise Architect允许向任何方向跟踪元素，并提供许多有用的工具来可视化跟踪，包括关系矩阵、可追溯性窗口和图表。插入相关元素功能可用于自动构建跟踪图，几乎神奇地创建了富有表现力且从未见过的存储库视图。 |