Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

ArchiEssence -- наш гекзаметр для ArchiMate

Интересно смотреть не на определения элементов языка ArchiMate, а на разные примеры моделирования -- и пытаться из них понять, что подходит для этих элементов языка ArchiMate из определений других стандартов (например, Essence). И только потом смотреть на определения из самого ArchiMate.

Тут я не столько интересуюсь взаимным соответствием элементов разных языков (ArchiMate и Essence), сколько пытаюсь определить некоторые соглашения по моделированию, привнести какой-то стиль (назовём его эээ... SysMoLan версии 0.1 -- "чтобы приготовить рагу из зайца, нужно иметь хотя бы кошку").

Да, стиль -- ограничение свободы интерпретации ArchiMate). Понятно, что всегда есть возможность не следовать стилевым ограничениям и использовать "полный ArchiMate, как было задумано его авторами". Но наличие стиля обычно помогает, а не мешает. Белым стихом писать сложнее всего, но гениев мы больше знаем не по их белым стихам, а по каким-нибудь сонетам или гекзаметрам. Так и тут: белые архимейтовские стихи хороши, но мы тут прикинем наши гекзаметры и сонеты.

Всё ниженаписанное это только первые прикидки, чтобы запустить обсуждение.

1. Интерес

Driver (фактор влияния, русский перевод даю по варианту http://ailev.livejournal.com/988360.html) -- определяется в ArchiMate 2.0 (расширение целеполагания, http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html) как что-то, что создаёт, направляет и подпитывает изменения в организации. Examples of internal drivers (or “concerns”) are “Customer satisfaction”, “Compliance to legislation”, and “Profitability”. Drivers of change may also be external; e.g., economic changes or changing legislation. The name of a driver should preferably be a noun.

Как прямо указано в тексте стандарта, то "что-то, что создаёт, направляет и подпитывает изменения" внутри concerns, так договорились в ISO 42010 говорить об интересе (interest) стейкхолдеров. Конечно, concern -- это объект первого класса, а хоть и по ISO 42010. Типичные concerns для целевой системы -- это acceptability, accessibility, accountability, accuracy, adaptability, administration, affordability, agility, assurance, auditability, и так далее в алфавитном порядке: то, обеспечением чего озабочены (concern наиболее точно переводится как "озабоченность") самые разные стейкхолдеры. Если целевая система это организация (а в ArchiMate моделируются только организации), то сами concerns будут чуть другими, но тип элемента языка от этого не становится другим.

Внешние факторы влияния не слишком меняют дело: обычно находится какой-то стейкхолдер, озабоченный таким фактором, он стремится изменить организацию под действием этого внешнего фактора, движимый своим интересом.

Concerns важны тем, что они позволяют структурировать обсуждение: обсуждение идёт по одному интересу за раз (separation of concerns). Недаром concerns определяют viewpoints, которые определяют view.

В Essence concern (по предложению Rich Hilliard он проходит состояния Identified -- Specified -- Framed -- Managed -- Interrelated -- Addressed) может быть полноценной альфой. Ну, и Area of Concern в Essence, безусловно группирует описания, связанные с concerns (или целыми группами concerns) -- Customer, Solution, Endeavor.

Такие группы предопределённых concerns нередки, некоторые из них даже получают аббревиатуры (тот же Rich Hilliard приводит в пример CRAMPS -- Cost, Risk, Availability, Manageability, Performance, Scalability; PESTLE -- Political, Economic, Social, Technological, Legal, and Ecological и т.д..

Интересно, что и в Essence, и в Archimate views (area of concerns в Essence это, безусловно, views в ArchiMate) никак не привязаны к Concerns в самом языке. Но в ArchiMate хотя бы Driver есть, а в Essence и этого нет. В то же время Driver в ArchiMate никак не привязан к предопределённым Viewpoints, которые именованы по их concerns (и слово concerns приводится в их определении каждого из viewpoint: http://pubs.opengroup.org/architecture/archimate2-doc/chap08.html) -- например, Organization Viewpoint имеет стейкхолдеров enterprise, process and domain architects, managers, employees, shareholders и отвечает таким интересам, как identification of competencies, authority, and responsibilities.

2. Практика

Принцип (principle) определяется как нормативное свойство всех систем в данном контексте, или способ, которым эти системы реализуются. Принципы определяют желаемые свойства системы. Принцип определяет общее свойство, которое применимо к любой системе в определенном контексте и обосновывается какой-то целью.

Опять же, если внимательно присмотреться, то в качестве принципов описываются серебряные пули, в случае использования каковых надеются достичь цели. Это основные идеи (принципы), лежащие в основе практик, типа small batch size в практике Lean, или сразу Lean (как принцип, лежащий в основе всей практики). Best practice IMHO должно моделироваться через principle.

Да что там, само указание на "способ, которым системы реализуются" это прямое указание на практику: дисциплину + технологию, причём с акцентом на дисциплину: Similar to requirements, principles define intended properties of systems. However, in contrast to requirements, principles are broader in scope and more abstract than requirements. A principle defines a general property that applies to any system in a certain context. A requirement defines a property that applies to a specific system.

3. Обеспечение технологий

Тем самым, requirements в ArchiMate связаны с конкретными технологиями (по Essence -- рабочие продукты, в том числе инструменты), которые нужно использовать ("развернуть на местности") в поддержку принципа-дисциплины: A principle needs to be made specific for a given system by means of one or more requirements, in order to enforce that the system conforms to the principle.

Интересно, что requirements/технологии в ArchiMate чаще всего моделируют со словом provide -- обеспечить. Это неудивительно, ибо речь идёт о расширении целеполагания для архитектуры. Сами технологии описываются в основном языке ArchiMate, а "требование" тут -- "обеспечить описанное в основной архитектурной модели". In the end, a business goal must be realized by a plan or concrete change goal -- то есть цели и требования это "задачи" чего-то достичь, они SMART -- specific, measurable, attainable, relevant, time-based (хотя в ArchiMate вы вряд ли найдёте цели и требования/обеспечение технологий сформулированные как SMART, это всё-таки архитектурный язык).

Вообще цели и обеспечение технологий по формулировкам похожи на команды лидера: только одни указывают на целевые характеристики для интереса стейкхолдера (достичь роста прибыли на 30% за год), а другие на технологии/требования для этого ("создать службу спам-рассылки" с промежуточной целью "увеличить число клиентов", или уж сразу "создать отдел роста прибыли").

Понятно, что requirements в ArchiMate совсем не "требования"в традиционном смысле слова, равно как business function в ArchiMate совсем не "функциональное подразделение". Тем интересней разбираться с этими элементами языка через призму других стандартов, других онтологий менеджмента.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments