您正在尝试混合Solution Architecture
和Enterprise Architecture
,这可能就是它看起来令人困惑的原因。
正如您正确指出的那样,TOGAF 是关于企业架构的 - 宏观的东西。另一方面,关于具体应用程序的信息更多是解决方案架构问题。当然,有人可能会争辩说,您可以根据需要尽可能详细地描述企业架构,但这不是重点。
不过,回答您的原始问题:您拥有的应用程序信息(架构描述、组件描述、功能描述)似乎应该存储Architecture Repository
为Solution Building Blocks
. 我建议在 和 期间将它们作为和Baseline Application Architecture
描述Baseline Technology Architecture
的一部分来解决。Phase C
Phase D
再说一次,你应该首先仔细考虑你是否真的需要这么高的细节水平。
PS如果你提供更多关于你想要达到的目标的背景,我可能会给你更具体的建议
2018 年 11 月 11 日更新
我在哪里可以放置公司结构、人员、团队等公司信息?
这取决于。公司结构应Baseline/Target Business Architecture
作为Organization structure
模型的一部分存储。这是来自 TOGAF 的定义:
“组织结构:记录组织结构,确定业务地点并将其与组织单位相关联。”
它也是输入之一 - Organizational Model for Enterprise Architecture
(参见第 IV 部分,TOGAF 规范的 36.2.16)。
我在哪里可以放置公司提供的产品和服务等业务信息,如何计算定价?对企业来说,“X 事物”是什么意思?
它也是 的一部分Business Architecture
,这是 TOGAF 规范的完整列表:
- 组织结构 - 识别业务地点并将其与组织单位相关联
- 业务目标和目的 - 为企业和每个组织单位
- 业务功能 - 一个详细的递归步骤,涉及将主要功能区域连续分解为子功能
- 业务服务——企业和每个企业单位向其客户提供的服务,包括内部和外部
- 业务流程,包括措施和可交付成果
- 业务角色,包括技能要求的开发和修改
- 业务数据模型
- 组织与职能的相关性——以矩阵报告的形式将业务职能与组织单位联系起来
我应该把正在进行的评估放在哪里?一旦投入生产,我应该把它放在哪里?
TOGAF 中有一个标准模式:
- 评估当前情况并将其写成
Baseline Architecture
- 创建一个愿景并将其写下来
Target Architecture
- 努力工作并随时
Target Architecure
更新Baseline Architecture
因此,最后,您的基线应该等于目标,现在它是您下一个 ADM 周期的新基线。
我应该把通用术语表放在哪里?
它通常在为您的企业定制 TOGAF 期间尽快完成 - Preliminary Phase
ADM 周期(参见第 IV 部分,TOGAF 规范的 36.2.21)。
我应该把开发指南放在哪里?比如环境列表、IP、交付工作流程、jira 工作流程等?
开发指南、jira 工作流程和其他项目管理内容通常不是 TOGAF 直接关注的问题。一定要知道,企业架构师甚至可能会就这件事进行咨询。就项目管理而言,只有一件事会浮现在脑海中——路线图,它们几乎在所有阶段都被记录下来并根据需要进行更新。
环境、IP 和其他基础设施信息通常在 期间处理Phase D
,主要作为技术架构模型和规范的一部分。
我应该将服务 API 定义放在哪里?
同样,您应该仔细考虑是否需要这种详细程度,但在Phase C (Applications Architecture)
. 其中一个步骤是定义模型(TOGAF 建议在您的行业中找到参考),其中可能包括 API 定义。就企业而言,解决更抽象的问题通常就足够了Applications Interoperability
。
非常重要的一点:TOGAF 只是一个框架,您可以根据自己认为适合当前企业的方式对其进行定制,只是不要忘记记录它。您还应该记住,它不仅是一组工具,而且是一组期望、术语表和指南,因此新架构师不需要在他工作的每个新企业中从头开始学习所有内容。一如既往 - 你必须找到一个适当的平衡点。