我目前的任务是为软件开发创建一个文档化，一致的架构指南。我们有很多聪明的人做正确的事情，但不是一贯和可重复的。
我们使用Microsoft的Application Architecture Guide 2.0作为起点。因此，提出一个应用程序架构是公平的（我不会轻易说）直接。可能是因为我有几年作为开发人员的经验，所以我对这个领域有很好的理解，并且还有大量的例子和指导。
由于我们的组织有几个应用程序构成一个或多个系统，然后我们在“客户端”安装......我们认为创建系统架构和企业架构也是有意义的。这就是问题的起点。
那里没有一致的指导。如果你搜索“系统架构示例”，你得到的东西是如此不同，我想知道是否有“标准”的方法来做到这一点。
从我（有限 - 清楚）对它的理解，系统架构是一个或多个应用程序架构的抽象，描述它们如何协同工作以形成一个系统。此外，企业架构是一个进一步的抽象，展示了您的系统如何适应组织企业以及它如何与业务流程，IT战略以及它如何集成到企业中的其他系统中。
我不想简单地列出一组可能有用的SOA相关模式......我想让它更专注于我们的工作，这是面向服务的构建财务解决方案架构。
更新：TOGAF(9)怎么样？有没有人有这方面的经验，值得努力尝试详细了解它。
答案 0 :(得分：20)
我几天前提交了这个问题，但是通过继续研究和阅读littlegeek的回复后，我想我发现了一篇有趣的白皮书，我发现这些白皮书内容非常丰富且有趣。
阅读：A Comparison of the Top Four Enterprise-Architecture Methodologies 作者：Roger Sessions
一个片段......
- - - - - - - - - - - 8＆lt; - - - - - - - - - - - -
在过去的20年中，许多企业架构方法已经出现过。此时，可能有90％的人使用这四种方法中的一种：
本白皮书讨论了这四种企业架构方法。它是在一家面临一些非虚构的运营问题的虚构公司的背景下这样做的。这些问题包括：
- - - - - - - - - - - 8＆lt; - - - - - - - - - - - -
白皮书在几个方面帮助了我。
我不能说我的所有问题都得到了回答，我现在已经准备好死了:-)，但是很多事情已经变得更加清晰，因此我认为那里的其他人也可能觉得这很有用。
我仍然会重视您对此主题的任何其他意见，建议和问题。
答案 1 :(得分：1)
你似乎对形势和对建筑领域的理解有了很好的把握。
“系统”Architecure稍微难以定义 - 可能是寻找“解决方案”或“IT”，但听起来您正在寻找您的软件架构如何与物理服务器世界相关，并且有点网络投入
“我们有很多聪明的人在做正确的事情，但却不能始终如一地重复。”
然后，作为TOGAF 8认证自己， - 我会说TOGAF为定义架构的不同方面带来了一种“方法论”，并将各种专业技术团队聚集在一起并将其牢固地固定在业务目标上。 TOGAF还有助于理解架构治理的必要性，并将变革的理念（从所有部分的技术，数据，系统，软件和业务）牢牢地带入流程。
所有帮助都会收集有关Archtecture工作的信息，并为开发和EA提供一致的方法。
它还可以帮助客户了解您正在做什么以及如何呈现TOAGF作为展示它如何组合在一起的方法。
PS - 我只说TOGAF是有用的，因为TOAGF会为你解决这个问题。
还有其他建筑师的框架。
答案 2 :(得分：0)
我没有关于EA的实践经验，但我实际上已经参与其中。在前四种EA方法中，我遇到了前三种方法。我只是不知道Gartner，可能是因为它的文件不可用。恕我直言，当我们谈论EA时，我们实际上是在谈论将业务与技术结合起来。因此，所有EA方法都必须面向业务。如果没有，那根本就不是EA。
我认为TOGAF非常有用且易于理解。是的，这是一个将当前基线架构发展为目标架构的过程。架构原则是EA开发的高级指导。 TOGAF的核心组件是业务架构，信息架构和技术架构。每个人都可以拥有自己的架构模式。 NIH已经使用FEAF实施了EA。这是实施EA的一个很好的例子。我认为这与TOGAF方法非常相似，至少从可交付成果的角度来看。
答案 3 :(得分：0)
到目前为止，为EA创建建模框架的唯一明智尝试是Archimate：https://en.wikipedia.org/wiki/ArchiMate
ArchiMate是The Open Group的技术标准，它基于IEEE 1471标准的概念。
此外，请参见以下有关EA工件及其之间可追溯性的链接：