TOGAF vs ISO 42010 vs Разом

В чому незручність, коли використовують тільки одну методологію для опису архітектурних рівнів?

• TOGAF дає методологію (ADM-фази, артефакти, каталоги, матриці), але іноді в ньому бракує гнучкості у формальному представленні результатів.
• ISO/IEC/IEEE 42010 дає рамку опису архітектури: хто стейкхолдери, які їхні потреби (concerns), через які viewpoints ці потреби відображати, і у вигляді яких views це презентувати.
• Якщо користуватися лише TOGAF — є ризик, що опис буде “каталог + текст”, але не зовсім зрозумілий різним групам зацікавлених сторін.
• Якщо користуватися лише ISO 42010 — буде гарна структура “хто/що/для чого”, але без готових методичних кроків і артефактів (каталогів, матриць).

Комбінація TOGAF і ISO/IEC/IEEE 42010 методично сильніша, ніж використання кожного окремо: TOGAF забезпечує процес і набір артефактів, а ISO 42010 — формалізований спосіб представлення архітектури через стейкхолдерів, concerns і viewpoints. Разом вони дозволяють зробити опис не лише повним, а й зрозумілим для різних аудиторій.

Критерій	TOGAF	ISO/IEC/IEEE 42010	Разом (TOGAF + ISO 42010)
Призначення	Методологія розробки архітектури (ADM, фази, артефакти)	Рамка для опису архітектури (stakeholders, concerns, viewpoints, views)	Повний цикл: розробка + формалізований опис
Сильна сторона	Дає покроковий процес (ADM) і набір артефактів (каталоги, матриці)	Дає чітку структуру для комунікації з різними стейкхолдерами	Виходить і методика роботи, і методика подачі результатів
Слабка сторона	Може вийти занадто “всередину ІТ”, важко донести до нефахівців	Немає власної методики створення артефактів, лише правила їх опису	Компенсують слабкі сторони один одного
Фокус	Що і як робити (Data, Application, Technology, Business Architectures)	Як показати і пояснити (concerns, viewpoints, views)	І процес, і представлення зрозумілі й прозорі
Приклад результату	Каталоги даних, матриці застосунків, моделі потоків	Logical Data View, Security View, паспорти viewpoints	Каталоги + матриці (TOGAF), оформлені у views для різних стейкхолдерів (ISO 42010)

Таким чином, можна сказати так — разом вони дають повну картину:

• TOGAF = як і що робити (ADM, каталоги, матриці).
• ISO 42010 = як правильно це описати й донести (stakeholders, concerns, viewpoints, views).

Див. також:
⋄ Приклад опису архітектури системи згідно TOGAF → https://bga68comp.dreamwidth.org/787432.html

🪟 На стартову сторінку

ISO/IEC/IEEE 42010: Viewpoint & View

У ISO/IEC/IEEE 42010 (Systems and Software Engineering — Architecture Description) є два близькі, але різні поняття:

Viewpoint (точка зору)

• Визначення: це "шаблон" або правило, яке пояснює як і для кого треба створювати архітектурне подання.
  
• Він відповідає на питання: які інтереси стейкхолдера ми показуємо, яку інформацію включаємо, якими засобами (діаграми, таблиці, текст) описуємо.
  
• Простими словами: viewpoint — це інструкція або рецепт для створення подання.
  

View (подання)

• Визначення: це конкретний результат застосування viewpoint до вашої системи.
  
• Тобто це вже готова діаграма, таблиця чи текст, що показує систему під певним кутом зору.
  
• Простими словами: view — це фото системи, зроблене за тим рецептом.
  

Приклад

Уявімо, що будуємо архітектуру для хмарної платформи:

1. Stakeholder (зацікавлена сторона)
   
   • CIO (Chief Information Officer, директор з ІТ)
     
   • Його concern (потреба): чи масштабована система і як забезпечено інтеграцію між додатками?
     
2. Viewpoint (точка зору на інтеграцію додатків)
   
   • Назва: Application Communication Viewpoint
     
   • Призначення: показати, як взаємодіють модулі та сервіси
     
   • Мова: UML Component Diagram або ArchiMate Application Collaboration
     
   • Яку інформацію включати: сервіси, API, протоколи, залежності
     
3. View (конкретне подання)
   
   • Діаграма з Azure AD, веб-додатком на Ubuntu, RDS MySQL, інтеграцією з O365.
     
   • Тут видно, що користувачі логіняться через Entra ID, доступ йде через API-шлюз, БД інтегрується через ORM-шар.
     
   • Це вже готова картинка, яку CIO може подивитися.
     

🔹 Отже:

• Viewpoint = каже: "покажи архітектуру додатків через компоненти і протоколи"
  
• View = конкретна діаграма з вашим Entra ID, API Gateway і MySQL
  

🪟 На стартову сторінку

ORM

ORM (Object-Relational Mapping / Об’єктно-реляційне відображення) — це програмна технологія, яка дозволяє працювати з базою даних не напряму через SQL-запити, а через об’єкти мови програмування.

Простими словами:

• Без ORM: ви пишете SELECT * FROM users WHERE id=1;
  
• З ORM: ви пишете User.find(1) і отримуєте об’єкт User, з яким можна працювати у коді.
  

Де застосовується

• ORM є проміжним шаром (layer) між додатком і БД.
  
• Він транслює методи й властивості об’єктів у SQL-запити і назад.
  
• Це робить код простішим, зручнішим у підтримці та менш залежним від конкретної СУБД.
  

Приклади ORM

• Java: Hibernate, EclipseLink
  
• .NET: Entity Framework
  
• Python: SQLAlchemy, Django ORM
  
• Ruby: ActiveRecord
  
• PHP: Doctrine, Eloquent (Laravel)
  

🪟 На стартову сторінку