企业、系统和应用程序架构（最佳实践？）

发布于 2024-07-17 02:20:24 字数 884 浏览 4 评论 0原文

我目前的任务是为软件开发创建一个文档化的、一致的架构指南。我们有很多聪明的人在做正确的事情，但只是不一致和重复。

我们使用 Microsoft 的应用程序架构指南 2.0 作为起点。因此，提出一个应用程序架构是相当简单的（我不会说容易）。可能是因为我有几年的开发经验，所以我对这个领域有很好的理解，并且还有大量的示例和指导。

由于我们的组织有几个应用程序形成 1 个或多个系统，然后我们将其安装在“客户端”...我们认为创建系统架构和企业架构也是有意义的。这就是问题开始的地方。

那里没有一致的指导。如果您搜索“系统架构示例”，您得到的内容是如此不同，以至于我想知道是否有一种“标准”方法可以做到这一点。

从我对这一切的（有限 - 清晰）理解来看，系统架构是 1 个或多个应用程序架构的抽象，描述了它们如何协同工作以形成一个系统。此外，企业架构是一个进一步的抽象，显示您的系统如何适应组织企业以及它如何与业务流程、IT 策略交互以及它如何集成到企业中的其他系统中。

难道我的理解完全错误吗？
是否有任何标准（以及在哪里可以找到它们）？
是否应该有标准，或者“好的”系统架构只是任何格式的任何文档，对读者来说是清晰易懂且有用的？
经验丰富的建筑师会如何看待这种方法呢？

我不想简单地列出一组可能有用的 SOA 相关模式...我想让它更加关注我们所做的事情，即在面向服务的架构上构建财务解决方案。

更新：TOGAF(9) 怎么样。有没有人有这方面的经验，是否值得努力详细了解它。

原文

I am currently tasked with creating a documented, consistent Architecture guide for software development. We have a lot of smart people doing the right things, but just not consistently and repeatably.

We are using Microsoft’s Application Architecture Guide 2.0 as a starting point. Hence coming up with an Application Architecture is fairly (I won't say easy) straight forward. Possibly because I have a couple of years experience as a developer so I have a pretty good understanding of this realm and there are also loads of examples and guidance.

Since our organisation has a couple of applications that form 1 or more systems which we then install "at" clients... we thought it would make sense to create a System Architecture and an Enterprise Architecture as well. And this is where the problems start.

There is no consistent guidance out there. If you search for "System Architecture Examples", the stuff that you get back is so different that I am wondering if there is a "Standard" way to do this.

From my (Limited - clearly) understanding of it all, the System Architecture is an abstraction of 1 or more application architectures depicting how they work together to form a system. Furthermore, an Enterprise Architecture is a further abstraction showing how your system(s) fit into a organisations Enterprise and how it interacts with the Business processes, IT Strategy and how it Integrats into other systems in the enterprise.

Do I have it completely wrong?
Are there any standards out there (and where can I find them)?
Should there be standards, or would a "good" System Architecture simply be any document in any format which is clearly and easily understandable and useful to its readers?
What would the seasoned Architects think of that approach though?

I don't want to simply list a set of SOA related patterns that may be useful... I'd like to make it a little more focused to what we do, which is the build financial solutions on a Service Orientated Architecture.

Update: What about TOGAF(9). Does anyone have experience with it at all and is it worth the effort of trying to understand it in detail.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

三生路 2024-07-24 02:20:24

我几天前提交了这个问题，但是通过继续研究并阅读 littlegeek 的回复后，我想我已经发现了一份有趣的白皮书，我发现它内容丰富且有趣。

阅读：四大企业架构方法的比较
作者：Roger Sessions

片段...

-- - - - - - - - - - - 8< - - - - - - - - - - - -

许多企业架构方法在过去 20 年里来了又去。此时，也许该领域 90% 的人使用以下四种方法之一：

Zachman 企业架构框架 — 尽管自称为框架，但实际上更准确地定义为分类法
Open Group 架构框架 (TOGAF) — 尽管称为框架，实际上更准确地定义为一个过程
联邦企业架构 - 可以被视为已实现的企业架构或创建企业架构的规范性方法论
Gartner 方法论 - 可以最好地描述为企业架构实践

这个白色本文讨论了这四种企业架构方法。它是在一家虚构的公司面临一些非常非虚构的运营问题的背景下进行的。这些问题包括：

IT 系统变得极其复杂且维护成本越来越高。
IT 系统阻碍组织及时且经济高效地响应当前和未来市场状况的能力。
始终过时和/或完全错误的关键任务信息。
组织的业务和技术方面之间存在不信任的文化。

-- - - - - - - - - - - 8＜ - - - - - - - - - - - -

白皮书在几个方面帮助了我。

它给了我很好的介绍和架构（特别是企业架构）的历史，
它向我介绍了作者建议的 4 个领先的可用企业架构。
然后继续以逻辑和简单的方式将它们与我可以联系到的好例子进行比较。

我不能说我所有的问题都已得到解答，我现在已经准备好去死了:-)，但很多事情已经变得更加清晰，因此我认为其他人也可能会发现这很有用。

我仍然非常重视您对这个主题的任何其他评论、建议和问题。

I submitted the question a couple of days ago, but by continued research and after reading littlegeek's reponse, I think I have found an interesting white paper that I found very informative and interesting.

Read: A Comparison of the Top Four Enterprise-Architecture Methodologies
By: Roger Sessions

a snippet...

-- - - - - - - - - - - 8< - - - - - - - - - - - -

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
The Gartner Methodology—Can be best described as an enterprise architectural practice

This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:

IT systems that have become unmanageably complex and increasingly costly to maintain.
IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.
Mission-critical information that is consistently out-of-date and/or just plain wrong.
A culture of distrust between the business and technology sides of the organization.

-- - - - - - - - - - - 8< - - - - - - - - - - - -

The White Paper helped me in several ways.

It gave me a good introduction and history of Architecture (Enterprise Architecture specifically)
It introduced me to what the author suggest is the 4 leading Enterprise Architectures available.
And then continues to compare them in a logical and simple manner with good examples that I could relate to.

I cannot say that all my questions have been answered and I am now ready to die :-), but much has become clearer and thus I thought that someone else out there may also find this useful.

I would still value any additional comments, suggestions and questions you may have on this subject.

回复收藏 0 原文

甜心小果奶 2024-07-24 02:20:24

您似乎对形势有很好的把握，对建筑领域也有很好的理解。

“系统”架构有点难定义 - 可能是寻找“解决方案”或“IT”，但这听起来像是你在寻找你的软件架构如何与物理服务器世界相关，其中加入了一些网络

“我们有很多聪明的人在做正确的事情，但只是不一致和可重复。”

然后，我自己获得了 TOGAF 8 认证，我想说 TOGAF 为定义架构的不同方面带来了一种“方法论”的感觉，以及一种将各种专业技术团队聚集在一起并将其牢固地固定在业务目标上的方法。 TOGAF 还有助于理解架构治理的需求，并将变革的理念（从技术、数据、系统、软件和业务的所有部分）坚定地引入流程中。

架构

开发方法
技术参考模型
标准信息库
企业连续体

都有助于收集有关架构工作的信息并提供一致的开发和 EA 方法。

它还可以帮助客户了解您在做什么以及如何展示 TOAGF 作为展示其如何组合在一起的方法。

PS - 我只是声明 TOGAF 有用，我引用的内容是 TOAGF 会为您解决这个问题。

还有其他建筑师框架。

回复收藏 0 原文

绝不放开 2024-07-24 02:20:24

我没有 EA 的实际操作经验，但我实际上很喜欢它。在前 4 种 EA 方法中，我遇到过前三种。我只是不知道 Gartner 的那个，可能是因为没有它的文档。恕我直言，当我们谈论 EA 时，我们实际上是在谈论业务与技术的结合。因此所有的 EA 方法都必须以业务为导向。如果不是的话，那它根本就不是EA。

我认为 TOGAF 非常有用且易于理解。是的，这是一个将当前基线架构演变成目标架构的过程。架构原则充当 EA 开发的高级指导。 TOGAF的核心组成部分是业务架构、信息架构和技术架构。他们每个人都可以有自己的架构模式。 NIH 已通过 FEAF 实施了 EA。这是实施 EA 的一个很好的例子。我认为它与 TOGAF 方法非常相似，至少从可交付成果的角度来看是这样。

回复收藏 0 原文