Skip to main content

2. ЩО ТАКЕ АРХІТЕКТУРА?

Переклад​

2.1 Опис​

2.1.1 Стандарт ISO/IEC/IEEE 42010 визначає архітектуру як:

«Фундаментальні концепції або властивості системи в її середовищі, втілені в її елементах, взаємозв’язках між ними, а також у принципах її проєктування та еволюції».

2.1.2 У контексті NAF система — це будь-що, що може розглядатися із застосуванням системного підходу, зокрема:

  • продукт,
  • послуга,
  • інформаційна система,
  • система систем, або
  • підприємство.

2.1.3 Водночас опис архітектури може розпочинатися ще до будь-якої ідентифікації систем. Це має місце у випадках, коли опис починається з суто операційного опису або з набору операційних спроможностей, що пояснюють, чого потребує користувач.

2.2 Навіщо розробляти архітектури?​

2.2.1 Архітектури розробляються з багатьох причин, і їх розроблення може розглядатися як процес і як дисципліна. Архітектури сприяють розробленню систем, які забезпечують реалізацію рішень, здатних задовольнити потреби організації для досягнення її місії.

2.2.2 Прикладами причин, з яких архітектура є необхідною, є:

  • планування переходу спроможності протягом усього її життєвого циклу;
  • досягнення більшої гнучкості, адаптивності та спроможності до економічно ефективних закупівель і побудови багатонаціональних систем для підтримки операцій;
  • розуміння та зниження ризиків;
  • краща адаптація до змін у бізнес-середовищі, галузевих тенденцій і регуляторного середовища;
  • узгодження бізнесу та технологій щодо єдиного набору пріоритетів;
  • планування та управління інвестиціями і контроль витрат на бізнес;
  • покращення комунікації в межах технічних доменів і між спільнотами за інтересами (Communities of Interest, CoI).

Примітки перекладача​

Примітки до 2.1.1​

Наведене визначення з ISO/IEC/IEEE 42010 описує архітектуру не як схему чи документ, а як сутнісну характеристику системи. Тобто потрібно розуміти архітектуру не як схему чи документація, а як цілісне уявлення про сутність системи в її середовищі, яке проявляється через її елементи, зв’язки між ними та принципи створення і розвитку. Вона визначає не лише як система виглядає зараз, а й як вона може змінюватися, залишаючись собою.

Розберемо елементи визначення:

  1. Фундаментальні концепти або властивості системи (The fundamental concepts or properties of a system) — це те, без чого система не є самою собою. Зазвичай це визначається через визначення призначення системи, перелік ключових функцій та можливості системи, визначення правил та обмежень.

  2. Розгляд у середовищі (of a system in its environment) - система розглядається у своєму середовищі а не ізольовано. Архітектура враховує правове, соціальне, культурне, організаційне та технологічне середовище. Архітектура визначається взаємодією з іншими організаціями, людьми та системами. Середовище та використання є важливими складовими частинами контексту використання.

  3. Втілена в елементах (embodied in its elements) — архітектура не абстрактна ідея, вона проявляється через складові частини системи. Елементи можуть бути: організаційні (інституції, ролі), функціональні (процеси, повноваження), технічні (системи, платформи), нормативні (правила, норми). Не варто вважти архітектуру як перелік елементів, правильно казати що ми бачимо архітектуру у її проявленні через елементи.

  4. Зв’язки між елементами (relationships) - зв’язки є не менш важливими, ніж самі елементи. Вони визначають відносини між елементами та середовищем - хто з ким і як взаємодіє, визначаються різні типи відносин (ієрархія, мережа, залежності, модифікації). Завдяки зв’язкам ми можемо визначати потоки інформації, ресурсів, рішень, відповідальності.

  5. Принципи (and in the principles of its design and evolution) - архітектура включає принципи проєктування (як система створюється) та принципи еволюції (як вона змінюється з часом). Ці принципи визначають що архітектура не є статичною, задає рамку допустимих змін та визначає, як система може розвиватися, не втрачаючи цілісності.

Примітки до 2.1.3​

Пункт 2.1.3 містить:

Водночас опис архітектури може розпочинатися ще до будь-якої ідентифікації систем. Це має місце у випадках, коли опис починається з суто операційного опису або з набору операційних спроможностей, що пояснюють, чого потребує користувач''.

Архітектура не обов’язково починається з опису конкретної системи (її компонентів, меж, інтерфейсів тощо). Архітектурний аналіз може стартувати з опису того, що потрібно робити, а не того, що вже існує - тобто з етапу бізнес аналізу

Замість питання

«Яка у нас система?»

проводиться аналіз різних аспектів:

  • виклики
  • умови середовища,
  • зацікавлені сторони
  • сценарії використання,
  • відносини та взаємодія акторів,
  • пріоритети, стратегії,
  • обмеження та очікувані результати.

На цьому етапі системи як об’єкта ще немає - є виключно елементи бізнес аналізу. У військовому, державному та міжвідомчому контексті ішення не можна “прив’язувати” одразу до конкретних систем. Це дозволяє: відокремити потреби користувача від реалізації, провести якісно та повно бізнес аналіз, застосувати вищі рівні менеджменту (мислити на рівні візії, місії, стратегії, операцій і спроможностей).

Визначення спроможностей (capabilities)​

Спроможність — це:

  • що потрібно вміти робити,
  • з яким рівнем ефективності,
  • у яких умовах,
  • незалежно від того, якими саме засобами.

Наприклад:

  • “здатність швидко реагувати на інциденти”,
  • “здатність обмінюватися даними між відомствами”,
  • “здатність забезпечувати безперервність управління”.

Оригінальний текст​

2 WHAT IS ARCHITECTURE?

2.1 Description

2.1.1 ISO/IEC/IEEE 42010 describes architecture as:

“The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”.

2.1.2 In the case of the NAF, a system is anything that can be considered with a systemic approach, such as a:

  • product,
  • service,
  • information system,
  • system of systems, or
  • enterprise.

2.1.3 However, a description of architecture can be started before any identification of systems. This is the case when the description starts with a pure operational description or a set of operational capabilities explaining what the user needs.

2.2 Why Develop Architectures?

2.2.1 Architectures are developed for many purposes and their development can be described as both a process and a discipline. Architectures aid the development of systems that deliver solutions that can meet an organization’s needs in order to achieve its mission.

2.2.2 Examples of why architecture is required include:

  • planning the transition of capability throughout its lifecycle,
  • achieving greater flexibility, adaptability and capacity for cost effective acquisitions and building Multi-national systems for supporting operations,
  • understanding and mitigating risks,
  • better adaption to changes in the business landscape, industry trends and regulatory environment,
  • aligning business and technology to the same set of priorities,
  • planning, and managing, investment and controlling expenditure to business, and
  • improving communication within technical domains and between Communities of Interest (CoI).