Продолжим публиковать серию статей, которые подготовил наш коллега, Александр Тетеркин, системный архитектор отела «Сервиса и Консалтинга», на тему работы в ArchiMate.

В прошлой статье мы обсуждали основные принципы и компетенции ArchiMate в разработке нового программного продукта.
Сегодня Александр расскажет, как построить «хорошую» архитектуру, как отобразить архитектурные концепции с помощью ArchiMate, рассмотрим классификацию требований по методу FURPS+ и прочие полезности.

Три принципа архитектуры Витрувия

В I в. до н. э., римский архитектор Марк Витрувий Поллион, написал свой знаменитый трактат об архитектуре: «Десять книг об архитектуре» (лат. De architectura libri decem).

Трактат является единственной сохранившейся античной работой об архитектуре и одной из первых на латыни.

  Мне в вышеозвученном трактате очень нравится триада Витрувия – три качества, которыми обязательно должна обладать архитектура:

• Firmitas (Прочность конструкции!)
• Utilitas (Польза!)
• Venustas (Красота!)

Изобразим их с помощью ArchiMate:

 
На изображении показано, как:
1.      системное соблюдение 3-х принципов (делать все надёжно, красиво, и чтобы это всё ещё и было полезно),
2.      позитивно повлияет (стрелочки с плюсом)
3.      на осуществление главного желания (драйвера или интереса) Витрувия: хорошей архитектуры.

Согласитесь, её можно применять при разработке, как программных, так и аппаратных решений? Но есть ли что-то не из античности? Давайте разбираться.

Хорошая архитектура

У многих слово «Архитектура» ассоциируется не только самим процессом планирования архитектуры и подготовки формального описания архитектуры (диаграмм, таблиц, документов и прочего), но и с воплощением в жизнь (зафиксированного в документации) замысла архитектора, т.е. с самой внедренной архитектурой. Говоря о хорошей архитектуре в этой статье, я хочу поговорить именно о последней ассоциации этого слова, о воплощении хорошей архитектуры, реализованной в виде внедренной информационной системы.
  
Для заказчика именно последнее определение архитектуры представляет наибольший интерес (value), только некоторым из заказчиков важны наши «картинки» и используемый нами процесс. Однако именно хороший процесс и хорошая документация могут гарантировать создание хорошей информационной системы.
Процесс создания архитектуры, процесс её описания и само внедрение создают цепочку ценностей, которые в результате формируют ту самую систему, к которой стремился Заказчик.

Для наглядности и вашего удобства, мысли эти я запишу в формате ArchiMate (язык моделирования ArchiMate 3.0.1):

 
Итак, что такое хорошая архитектура, понятно, но как её создать и реализовать?

Отображение архитектурных концепций с помощью ArchiMate

Итак, вам стало интересно… Спасибо!

Кто не очень знаком с нотацией языка моделирования ArchiMate, прошу посмотреть информацию за спойлером. Затем мы рассмотрим несколько принципов хорошей архитектуры.

---

  На примере картинки выше, я подробно расписал значение используемых элементов ArchiMate. На диаграмме приведены следующие объекты нотации ArchiMate 3.0.1:

1.      Облако смысла (meaning) – интерпретация смысла элемента архитектуры. Здесь я применяю его для объяснения смысла самого понятия Архитектуры. Более подробное объяснение содержится в самой спецификации ArchiMate 3.0.1 в разделе 6.4.1 «Meaning».



2.      Элемент Ценность (Value) (обозначается эллипсом или кружком фиолетового цвета) – представляет собой относительную ценность, полезность или важность основного элемента ArchiMate или результата. Внедренная архитектура полезна заинтересованным сторонам только тогда, когда она хотя бы частично удовлетворяет их требованиям. Более подробное объяснение содержится в разделе 6.4.2 «Value».



3.      Элемент Бизнес-процесс (обозначается параллелепипедом со скругленными углами с иконкой полой стрелки в верхнем правом углу) - описывает внутреннее поведение, выполняемое бизнес-ролью, производящей продукты и/или выполняющей услуги. В данном случае бизнес-роль – это архитектор, который создает описание архитектуры. Подробности в разделе 8.3.1 «Business Process».



4.      Элемент Представление (representation) (обозначается в виде оборванного документа) – представляет собой воспринимаемую форму информации, содержащейся в бизнес-объекте (Бизнес-объект представляет собой любую концепцию из сферы бизнеса: счёт, заявка, претензия и т.п.). Это может быть сообщение, документ, изображение или группа подобных носителей. У нас в данном примере – это совокупность всех описаний архитектуры. Кстати, один бизнес-объект может иметь несколько представлений. Подробности в разделе 8.4.3 «Representation».



5.      Элемент Продукт (изображается в виде светло-желтого прямоугольника со значком папки в левом верхнем углу) – представляет собой единый набор Сервисов (услуг) и/или других Бизнес-объектов и/или Представлений (см. выше), которые сопровождаются Контрактом (соглашением) и предлагаются внешним или внутренним Клиентам как единое целое. Важным вкладом Системной инженерии является представление деятельности поставщиков решений в виде процесса создания полноценного продукта (со своим жизненным циклом), а не просто в виде выполнения законченных проектов (по принципу «сделал и забыл»). Подробности см. в разделе 8.5.1 «Product».



6.      Элемент связи ассоциация (отображается в виде простой линии связи без стрелок и каких-либо других обозначений) – моделирует связь между элементами без какой-либо специализации (простая ассоциация) или в случае, если в стандарте ArchiMate не находится подходящего элемента связи. На примере выше используется для обозначения связи: между разными элементами Облако смысла (простая соединительная линия), между элементами Облако смысла и Ценность, между элементами Соединение и другими элементами, между Описанием архитектуры и Внедренной архитектурой. Подробности в разделе 5.4.2 «Association notation».

 
7.      Элемент связи Соединение (отображается в виде небольшого черного кружка) – используется для соединения элементов связи (связей) одного типа. Подробности в разделе 5.4.3 «Junction» .



8.      Элемент связи Влияние (отображается в виде обычной стрелки с пунктиром иногда со значками «+» или «-») – используется для обозначения влияния одного элемента нотации на другой (например, на элемент внедрения или на мотивационный элемент). У нас создание хорошей архитектуры положительно влияет на ценность системы для заказчика (знак «+»). Подробности в разделе 5.2.3 «Influence Relationship» .



9.      Элемент связи Доступ (Access) (отображается в виде линии, состоящей из точек; могут применяться простые стрелки для отображения направления воздействия) – моделирует способность элементов поведения и активных структурных элементов получать и передавать информацию или воздействовать на пассивные структурные элементы. В нашем примере, в процессе разработки архитектуры создается (т.е. записывается → Access) документация Описание архитектуры, а затем используется (снова Access, но стрелка в другом направлении) при создании готового продукта, при Внедрении Архитектуры. Подробности см. в разделе 5.2.2 «Access Relationship» .

---

Язык моделирования ArchiMate настолько понятен, что даже отдельных объяснений не требуется. Но иногда нам важно знать что собеседник подразумевает под тем или иным словом (понятием).

На картинке я показал из каких составляющих состоит Архитектура, что именно важно заказчику в первую очередь. Далее давайте рассмотрим чуть подробнее, что нужно сделать чтобы достичь желаемого результата.

Классификация требований заинтересованных лиц по методу FURPS+

Несколько базовых определений:

• Участвующие стороны (Stakeholders) - лица, наделенные ролью в системе или имеющие к ней непосредственный интерес. Заинтересованы в результате (Outcome).
• Функциональные требования описывают что система (или её часть) должна делать.
• Нефункциональные требования описывают, какими дополнительными полезными качествами должна обладать система (или её часть).

Чтобы создаваемая или существующая система была полезна ключевым заинтересованным сторонам мы должны гарантировать выполнение их требований. Но часто, при проектировании, важные требования упускаются из виду, в следствие этого Важно пользоваться единой системой классификации требований! Это один из принципов, который можно добавить в «копилку» (репозиторий) архитектора.

В далеком 1992 году Роберт Грэди, работавший тогда в Hewlett-Packard, применяя системный подход, изобрел метод классификации архитектурных требований, гарантирующий, что ценные требования заинтересованных сторон, не будут упущены из виду. Аббревиатура FURPS расшифровывается так:
  
1.      Functionality (Функциональность)
2.      Usability (Удобство использования)
3.      Reliability (Надежность)
4.      Performance (Производительность)
5.      Supportability (Удобство поддержки)

Позднее метод был доработан и к стандартным пяти добавились дополнительные типы:

1.      Design requirements (Требования в Разработке)
2.      Implementation requirements (Требования к Внедрению)
3.      Interface requirements (Требования к интерфейсам)
4.      Physical requirements (Физические требования)

Далее я приведу список категорий FURPS+ наглядно, в формате ArchiMate. На картинке появились новые типы элементов (попробуйте найти из значение самостоятельно). Эти элементы показывают нам, что:

1.      Основной мотив (драйвер) «заинтересованной стороны» «Заказчик» – это «Развитие бизнеса».
2.      «Развитие бизнеса» помимо прочего включает в себя желание видеть «Эффективные ИТ-системы, приносящие желаемый результат».
3.      На что «Влияет» наличие «Хорошей архитектуры».
4.      Архитектура, в свою очередь, «реализуется» через выполнение всех «Требований».
5.      Требования состоят из «FURPS+», которые включают в себя первичные требования «FURPS».

Краткую справку по значению новых «стрелок» (связей) можно посмотреть здесь: Раздел 5.5 «Summary of Relationships».

Рассмотрим значения этих требований более подробно:

Функциональные требования (F – Functional)

Функциональные (F – Functional) требования обычно относятся к основным функциям системы. Например, для складского приложения могут быть требования, относящиеся к обработке заказов (например, «функция просмотра списка заказов») или управлению запасами (например, «добавление товаров на склад»).
Однако функциональные требования не всегда привязаны к конкретной области. Например, поддержка приложением русского языка является дополнительным функциональным требованием, которое помогает осуществить основное требование (например, обработку заказов).

На картинке ниже изображены основные и дополнительные функциональные требования в виде диаграммы ArchiMate 3.0.1:

Требования к удобству использования, надежности, производительности и поддержке (URPS)

Оставшиеся в аббревиатуре FURPS+ буквы U, R, P, S описывают нефункциональные требования, которые, в основном, являются архитектурно значимыми (любое требование, сопряженное с высоким риском, высоким приоритетом или низкой стабильностью может считаться архитектурно значимым):

1.      U – Usability (Удобство использования) – связано с такими характеристиками, как эстетика и согласованность в пользовательском интерфейсе.
2.      R – Reliability (Надежность) – связана с такими характеристиками, как доступность (отношение нормальной работы системы ко всему времени), точность расчетов системы и способность системы восстанавливаться после сбоя.
3.      P – Performance (Производительность) – зависит от таких характеристик, как пропускная способность, время отклика, время восстановления, время запуска и время выключения.
4.      S – Supportability (Удобство поддержки) связана с такими характеристиками, как тестируемость, адаптивность, ремонтопригодность, совместимость, конфигурируемость, устанавливаемость, масштабируемость и локализуемость.

Требования к проектированию, к внедрению, к интерфейсам и физические требования (+)

Знак «+» в аббревиатуре FURPS+ используется для определения дополнительных категорий, которые обычно представляют собой ограничения:

1.      A design requirement (Проектное требование, часто называемое Проектное ограничение) – указывает или ограничивает выбор средств и методов при проектирования системы.
Например, если вы указываете, что необходима реляционная база данных, это проектное ограничение.
2.      An implementation requirement (Требование к внедрению) – определяет или ограничивает разработку, или построение системы. Примеры могут включать обязательные стандарты, языки разработки и ограничения по ресурсам.
3.      An interface requirement (Требование к интерфейсам) – определяет внешний элемент, с которым должна взаимодействовать система, или ограничения на форматы или другие факторы, используемые в рамках такого взаимодействия.
4.      A physical requirement (Физическое требование) – определяет физическое ограничение, наложенное на аппаратное обеспечение или инфраструктуру, используемые для размещения системы — например, форма, размер или вес.

Другие методы

Есть и другие методы классификации требований. Например, см. раздел 2.3 “Requirements Classification Schema” в BABoK (Business Analysis Body of Knowledge) международного института бизнес анализа (International Institute of Business Analysis) – Обратите внимание, требуется регистрация!

Но основная мысль такая – у вас может быть своя система классификации требований, но в любом случае это должна быть система, тогда будет гарантия того, что вы учли все основные (нужные нам) требования.

Оценка осуществимости по методу TELOS

С требованиями мы разобрались. Но что делать, если требования запредельные, технологии или бюджеты не позволяют осуществить задуманное? Вроде мы всё учли, но вдруг что-то забыли? Опять мы возвращаемся к необходимости наличия некоторой системы оценки (системного или архитектурного подхода, или мышления). Вот и новый принцип сформировался: Важно пользоваться единой системой оценки осуществимости проектов!

У вас может быть и своя методика оценки, но, если её пока нет, вашему вниманию предлагается посмотреть на методику TELOS, которой многие годы пользуются архитекторы и менеджеры проектов. Методика, позволяет оценить осуществимость концепции до того, как вы под всем подписались.

Telos (греческ. τλλος) переводится как “предназначение”, “конец” или “цель”; и относится к философской концепции предназначения. Это достаточно популярное слово, но мы поговорим именно о концепции, используемой в сфере управления проектами (Project Management).

Итак, TELOS (в сфере управления проектами) – это аббревиатура, используемая для обозначения пяти основных областей осуществимости (они и определяют, стоит ли запускать проект или нет):

1.      T – Technical (Техническая осуществимость) – Возможен ли проект с технической точки зрения?
2.      E – Economic (Экономическая осуществимость) – Можем ли мы позволить себе проект? Увеличит ли это нашу прибыль?
3.      L – Legal (Юридическая осуществимость) – Является ли такая деятельность законной?
4.      O – Operational (Операционная осуществимость) - Сможет ли текущая операционная деятельность поддержать связанные с проектом изменения?
5.      S – Scheduling (Плановая осуществимость) – Возможно ли выполнить проект вовремя?

Используя язык моделирования ArchiMate, для каждой области можно сформулировать ряд вопросов (оценок) для проверки осуществимости проектов.

Основная мысль такая: у вас может быть своя система оценки осуществимости, но в любом случае это должна быть система – тогда будет гарантия исполнения проектов.

Что дальше

Мы рассмотрели несколько принципов хорошей архитектуры. Но одно лишь должно быть неизменным – Важно использовать системный подход в любой сложной деятельности! Т.е. необходимо создавать систему и фиксировать в стандартах, чтобы однажды созданное вами, могло быть полезно коллегам и друзьям.

Как видно, ArchiMate можно успешно применять для понимания и обозначения смыслов понятий; для визуализации и запоминания различных концепций, связанных с архитектурой (предприятия, системы, инфраструктуры). В следующей статье я расскажу, как можно применять ArchiMate при описании архитектуры в облачных средах.

Источники

1.      Десять книг об архитектуре
2.      Standard: ArchiMate 3.0.1
3.      Wikipedia: «Functional requirement»
4.      Wikipedia: «Non-functional requirement»
5.      Wikipedia: «FURPS»
6.      IBM Developer article: «Capturing Architectural Requirements»
7.      Wikipedia: «Types of Requirements»
8.      Standard: «BABoK – Business Analysis Body of Knowledge»
9.      Wikipedia: «Feasibility study common factors»
10.    Article «Using TELOS For Validation & Feasibility Checking»

 Познакомиться подробнее с проектами отдела Сервиса и Консалтинга ГК ХОСТ можно по ссылке.