企业架构

最近，我在亚马逊上收到了一些关于P of EAA的负面评价，因为书中没有关于企业架构的内容。当然，这有充分的理由——这本书是关于企业应用程序架构的，即如何设计企业应用程序。企业架构是一个不同的主题，即如何将企业中的多个应用程序组织成一个连贯的整体。

事实证明，我对企业架构持相当悲观的看法。这种悲观情绪源于企业架构倡议的常见生命周期。通常，它们以辉煌和关注的姿态开始，因为 IT 部门启动了一项重大举措，将带来协同效应、重用以及打破应用程序孤岛（以及其他合适的类比）带来的所有其他好处。两年或三年后，并没有做太多的事情，企业架构团队的电话也打不通了。再过一两年，这项举措悄然消亡，但很快又会启动另一项举措，繁荣与萧条的循环再次开始。

那么，为什么这种循环会如此规律地发生呢？我认为，参与这些举措的大多数人都会说，它们失败的主要原因是政治——但他们经常忽略的是，这些政治力量是不可避免的。要在这些事情上取得成功，首先要认识到这些政治力量的强大。

中央架构团队的问题在于，它们受 IT 管理驱动，但它们要组织的应用程序却受业务需求驱动。如果一个应用程序团队被告知要完成一项对他们的应用程序没有直接益处的工作，但可以使其更容易融入架构，那么他们自然会不愿意这样做。此外，他们还有王牌——业务赞助商。如果业务赞助商被告知应用程序将延迟四个月才能符合企业架构计划，那么当他们说“不”（即“我们以后会处理它”）时，他们就会有动力支持应用程序团队。由于应用程序直接与提供业务价值相关，而中央架构团队则没有，因此应用程序团队获胜。这些胜利导致企业架构举措失败。

为了避免这种情况，企业架构举措必须认识到并服从政治现实。

• 了解任何企业架构举措的业务价值。
• 确保任何工作都得到业务价值的短期增量收益的支持。
• 将应用程序的成本降到最低

一个好的思考方式是，这些举措应该更多地关注如何制定应用程序的总体计划，而更多地关注如何提出在任何情况下集成应用程序的技术。（毕竟，应用程序边界主要是社会建构，它们不太可能符合任何人的未来计划。）这种集成架构应该对应用程序团队的影响最小，这样团队就可以根据业务价值的合理性提供少量功能。我认为，你还需要关注那些最大程度地减少应用程序之间耦合的方法，即使这些方法不如更紧密耦合的方法高效。

这些原因往往让我倾向于采用消息传递方法进行集成。虽然它有其缺陷，但它可以以对现有应用程序的影响最小化的方式应用。

顺便说一句，企业应用程序架构可以对企业集成产生重大影响。那些分层良好的应用程序，特别是那些具有良好表现层域分离的应用程序，更容易拼接在一起，因为你可以更容易地通过服务公开应用程序的功能。这不会给应用程序带来成本，因为良好的分层使应用程序更容易维护。然而，很少有应用程序开发人员了解如何进行表现层域分离。集成团队可以做的最好的事情之一就是支持教育和培训，帮助他们做到这一点（如果他们像Architectus Oryzus 而不是 Architectus Reloadus那样行事，这种方法将得到最好的支持）。因此，从某种意义上说，我的书与企业架构有很大关系。