?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

ArchiEssence -- наш гекзаметр для ArchiMate [30 Jun 2015|12:38am]
Интересно смотреть не на определения элементов языка 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 совсем не "функциональное подразделение". Тем интересней разбираться с этими элементами языка через призму других стандартов, других онтологий менеджмента.
7 comments|post comment

Учебная робототехника: готовим эникейщиков, или ДОСААФ-2015 [30 Jun 2015|12:57am]
Сегодняшние тренды в учебной робототехнике мне напоминают разворачивание массовой подготовки персонала для гарантийных мастерских мелкой бытовой техники (мастерами будут брать победителей соревнований по робототехнике, а остальных пропустят через фейс-контроль и поставят на приёмку-выдачу и разговоры с клиентами). Другое дело, что сам ремонт в таких мастерских всё меньше и меньше требует напряжения и умелости как рук, так и головы. И всё меньше и меньше требует ремонта. И всё меньше и меньше требует мастерских.

Заход был как с информатикой: "давайте готовить людей с алгоритмическим мышлением!", а на выходе даже эникейщиков не получалось. Учебная робототехника про "робототехническое мышление" (или хотя бы "инженерное мышление на примере инженерии робототехнических систем") даже не заикается, а аналога эникейщиков для робототехников пока нет.

Так что с постановкой задачи всё плохо, целеполаганием неясно, но маховик стремительно раскручивается: http://habrahabr.ru/company/balrobotov/blog/260855/. ДОСААФ-2015, не иначе.
16 comments|post comment

Трип нейронной сетки, управляемый из чата [30 Jun 2015|03:39pm]
Это нужно видеть: сны нейронной сетки (live video), при этом галлюцинации направляются из чата -- можно указать тему трипа, при этом разные темы плавно переходят одна в другую: http://www.twitch.tv/317070

Завораживающе.
3 comments|post comment

navigation
[ viewing | June 30th, 2015 ]
[ go | previous day|next day ]