Вы пытаетесь смешать Solution Architecture и Enterprise Architecture, поэтому, вероятно, это выглядит странно.
TOGAF - это корпоративная архитектура, как вы правильно отметили, - это большая картина. Информация о конкретном приложении, с другой стороны, является скорее проблемой архитектуры решения. Конечно, можно утверждать, что вы можете описать архитектуру предприятия настолько подробно, насколько вам нужно, но это не главное.
Тем не менее, отвечая на ваш первоначальный вопрос: похоже, что информация о приложении (описание архитектуры, описание компонентов, функциональное описание) у вас должна храниться в Architecture Repository как Solution Building Blocks. Я бы порекомендовал обратиться к ним как к части Baseline Application Architecture и Baseline Technology Architecture описания, во время Phase C и Phase D.
Опять же, вы должны сначала тщательно обдумать, действительно ли вам нужен уровень детализации такого высокого уровня.
P.S. если вы предоставите немного больше информации о том, чего вы хотите достичь, я, вероятно, смогу дать вам более конкретный совет
Обновление 11/11 / 2018
Где можно разместить информацию о компании, такую как структура компании, люди, команды и т. Д.?
Это зависит. Структура компании должна храниться в Baseline/Target Business Architecture как часть модели Organization structure. Вот определение от TOGAF:
«Организационная структура: документирование организационной структуры, определение местоположения предприятия и привязка их к организационным подразделениям.»
Это также один из входов - Organizational Model for Enterprise Architecture (см. Часть IV, 36.2.16 спецификации TOGAF).
Где можно разместить деловую информацию, такую как продукты и услуги, предлагаемые компанией, как рассчитывается цена? что значит «вещь Х» для бизнеса?
Это также часть Business Architecture, вот полный список из спецификации TOGAF:
- Организационная структура - определение местоположения предприятия и привязка его к организационным подразделениям
- Бизнес-цели и задачи - для предприятия и каждой организационной единицы
- Бизнес-функции - подробный рекурсивный шаг, включающий последовательную декомпозицию основных функциональных областей на подфункции
- Бизнес-услуги - услуги, которые предприятие и каждое подразделение предприятия предоставляют своим клиентам, как внутри, так и снаружи
- Бизнес-процессы, включая меры и результаты
- Бизнес-роли, включая разработку и изменение требований к навыкам
- Модель бизнес-данных
- Соотношение организации и функций - связать бизнес-функции с организационными единицами в форме матричного отчета
Где я должен поставить текущие оценки? и куда мне положить, как только он будет запущен в производство?
В TOGAF есть стандартный шаблон:
- Оцените текущую ситуацию и запишите ее как
Baseline Architecture
- Создайте видение и запишите его как
Target Architecture
- Работайте в направлении
Target Architecure и обновляйте Baseline Architecture по мере продвижения
Итак, в итоге ваш базовый уровень должен стать равным целевому, и теперь это ваш новый базовый уровень для следующего цикла ADM.
Где мне поставить общий глоссарий терминов?
Обычно это делается как можно скорее при адаптации TOGAF к вашему предприятию - Preliminary Phase цикла ADM (см. Часть IV, 36.2.21 спецификации TOGAF).
Куда мне направлять руководства по разработке? например, список сред, IP-адреса, рабочий процесс доставки, рабочий процесс Jira и т. д.?
Руководства по разработке, рабочий процесс jira и другие элементы управления проектами, как правило, не являются прямой проблемой TOGAF. Об этом следует обязательно знать, корпоративный архитектор может даже проконсультироваться по этому вопросу. С точки зрения управления проектами приходит на ум только одна вещь - дорожные карты, они записываются и обновляются по мере необходимости практически на всех этапах.
Среды, IP-адреса и другая информация об инфраструктуре обычно обрабатываются в течение Phase D, главным образом, как часть моделей и спецификаций архитектуры технологий.
Где я должен разместить определения API сервиса?
Опять же, вы должны тщательно продумать, нужен ли вам этот уровень детализации, но, кажется, уместно обратиться к нему в Phase C (Applications Architecture). Одним из шагов является определение модели (TOGAF рекомендует найти ссылку в вашей отрасли), которая может включать определения API. Обычно достаточно обратиться к более абстрактному Applications Interoperability с точки зрения предприятия.
Очень важный момент: TOGAF - это просто фреймворк, вы можете адаптировать его так, как считаете нужным для вашего текущего предприятия, просто не забудьте документировать его. Вы также должны помнить, что это не просто набор инструментов, но также набор ожиданий, глоссарий терминов и рекомендаций, поэтому новому архитектору не нужно будет изучать все с нуля на каждом новом предприятии, на котором он работает. Как всегда, вы должны найти правильную точку баланса.