Архимейт по-русски 1.1 -- бета готова
Сегодня я закончил новый перевод Archi 3.2.1, обозвал его версией 1.1 (версия 1.0 была выпущена три года назад -- http://ailev.livejournal.com/988360.html).
По сути, это третья редакция перевода:
-- первая была формальная, и все стандартнаци были очень довольны. Уже в первой редакции я максимально согласовал с уже имеющейся терминологией переводов ISO 42010 (Архимейт на нём базируется). Эта редакция так и осталась внутренней, плагина к Archi я для неё не публиковал.
-- после тестирования на клиентах я решил резко сбить пафос и убрать по возможности канцелярит-стандартит. Основной аргумент был: деньги за реализацию архитектуры платят те люди, которые айтишных стандартов не читали, но они должны хотя бы что-то понимать из ведущихся разговоров, хотя бы полпроцента. В этом виде и вышла версия 1.0 плагина к Archi (глоссарий -- http://ailev.livejournal.com/956829.html, дополнения второй версии -- http://ailev.livejournal.com/978200.html).
-- третья версия 1.1 выйдет сейчас, и я продолжил там гнуть ту же линию снижения пафоса и укорочения говорения. Профессионального сленга стало больше, на лёгкие проблемы я сознательно махнул рукой (ибо решение этих проблем, которое я пытался реализовать в версии 1.0 было хуже, чем сами проблемы), плюс учтён опыт прошедших трёх лет -- и несколько источников ошибок я постарался исправить на уровне выбора слов.
Вот главные изменения:
1. Я перестал добавлять ко всем словам название уровня. Не "объект деятельности", и даже не "оргобъект", а просто "объект". Не "процесс деятельности", и даже не "оргпроцесс", а просто "процесс". Хотя там, где одинаковые слова для похожих элементов разных уровней, я уровень оставил -- оргсервис, программный сервис и сервис "железа".
2. Уровень Business-"люди" стал "деятельностью" (не будем беречь этого слова, потратим его свободно. Busniness -- это "дело", "деятельность"). Но в некоторых местах я вместо длинного "деятельность" даю короткую приставку "орг" -- тот же оргсервис. И всё-таки я не стал называть уровень "организационным". Три уровня деятельность-"софт"-"железо" звучат для меня более понятно, нежели организация-"софт"-"железо", ибо про деятельность того же софта я сказать не могу, а вот про организацию софта -- запросто. Но оргсервис я не перепутаю с программным сервисом, поэтому не просто "сервис", и не длинно "сервис деятельности людей" (по мотивам прошлой версии перевода), а "оргсервис", ибо короче и понятней.
3. Уровень оборудования стал уровнем "железа". А заодно Node-оборудование стало "железом" (если говорить о единице оборудования -- будет единица "железа"). "Железо" пишем в кавычках. Я с клиентами в "реальном секторе" неоднократно натыкался на то, что они подолгу не понимали, о каком я говорю оборудовании -- о том, которое в их информационных системах, или в котором их информационные системы! А уточнять каждый раз, что "айтишное оборудование" -- это длиннее и не менее сленгово, чем просто "железо".
Так что было Infrastructure usage-"использование оборудования", стало "использование "железа"", Infrastructure function стал функционалом "железа", а не оборудования, а Infrastructure interface стал интерфейсом "железа".
4. Уровень программ стал уровнем "софта". А Application Component-"программная компонента" стала "программой". Описание программы (инкапсуляция, интерфейсы, реализация файлом и т.д.) чётко указывает на то, что речь идёт именно о программном модуле. Компонента там по смыслу -- "программный функционал", на выполнение которого назначается модуль. Так что слово "компонента" просто опущено.
Ну, и Application Behaviour -- работ "софта" (а не работа программ), Application Cooperation -- взаимодействие "софта", Application Structure -- структура "софта". Там, где говорится о множестве программ, где используется собирательное понятие, там "софт".
Но не "софтовый" сервис, а "программный сервис", не "софтинка", а "программа", не функционал "софтинки", а "программный функционал" -- где имеется ввиду не весь "софт" предприятия, а одна или программа или небольшая группа программ.
5. Крутейшее изменение, которое касается и ISO 42010. View (помним, что в стандарте veiw группирует входящие в него модели) переобозван из группы описаний просто описанием. Да, там нюансы. Так, архитектурное описание (description) само состоит из разных тематических групп описаний, а элементарными описаниями являются "модели" (models). По мне сегодняшнему, так это очередная попытка навести разнотиповую иерархию там, где просто специализация типа. Ведь определение системы противопоставляется описанию системы (description -- все view вместе), которое делится на тематические описания типа архитектурного -- и уже это вполне себе view. А затем view делятся на маленькие подвьюшки -- модели. А в Archi description называется Total veiw, низовых моделек нет вовсе. И слово "модель" там занято, по смыслу это как раз definition (видеть модель можно, только вынеся на какую-то диаграмму-описание или в специальном окошке диаграммы дерева-модели -- и как называется это окошко? Правильно, тоже view).
Итог: группа описаний стала просто описанием. Есть определение, а есть описание. То, что в Archi view-окошко программы и ArchiMate view обозначаются одним словом -- это ничего, это нормально. Так что там иногда путается в переводе "закрыть окошко" и "закрыть описание".
Ах, насколько же стало проще и понятней!
Viewpoint я так и оставил "методом описания" (а не "практика описания") -- подразумевается, что в метод описания входят самые разные практики, необходимые для описания (не только метамодель, но и указания по стилю -- "соглашение о моделировании", типовые паттерны и т.д.).
6. Actor-люди стали "ответственными" -- это прямой реверанс в сторону DEMO (у них там те же Actors: те, кто имеют право что-то попросить или выполнить. Это и есть суть организации: разделение полномочий и ответственности). Тут тонкость: в организации есть обычно не два (как в Архимейте), а целых три объекта:
-- должности, подразделения -- вся органиграмма (ответственности)
-- роли по отношению к деятельности (они связаны с практиками: в ArchiMate одна практика -- одна роль)
-- люди (или их группы), занимающие должности и выполняющие в этих должностях (профессиональные, по отношению к деятельности) роли.
Архимейт явно проговаривает, что никаких конкретных исполнителей ролей в нём не предусмотрено, Actors главным образом используется для выражения органиграммы. А "ответственный" обычно ещё и несколько ролей играет, ибо назначен явно не на одну практику. И вот поэтому переводим "ответственный" (главный инженер, департамент закупок и т.д.), а не просто "исполнитель".
7. Product (который я в прошлый раз честно оставил "продуктом") надёжно всех сбивает с толку -- это "банковский продукт", "страховой продукт", но в реальном секторе каждый раз удивляются, почему Арчи не позволяет поступать с ним как с продуктом, как будто он какие-то работы (activity), а не продукт! Да, ArchiMate определяет product именно как service+contract! Вот он и ведёт себя как оргсервис при моделировании! Так что я назвал его хитро: оргсервис-продукт, чтобы прямо из названия следовала аналогия с "банковским продуктом".
Парное к нему соглашение об уровне сервиса (contract) я так и назвал полностью, чтобы дополнительно прояснить эту засаду с оргсервис-продуктом как сервисом -- "соглашение об уровне сервиса". Архимейт 2.1 тут странен: в тексте подробно говорится, что чаще всего тут SLA, а иногда другие типы контрактов. А элемент назвали контрактом. Я перевёл по наиболее частому случаю, строго по стандарту! И приписал в подсказке, что могут быть и другие виды контрактов.
8. Stakeholders стали из заинтересованных сторон просто "стейкхолдерами". Язык развивается, и это нужно учитывать. Слово компьютер постепенно заменило слово ЭВМ, и тут ровно такой же случай.
9. Requirements по более тщательному рассмотрению стало не требованиями (ещё можно говорить про требования к "софту" или "железу", но про деятельность редко говорят в терминах требований), а... контрольной точкой. Это удивило и меня самого.
Идея, что это "задачи" из "целей и задач" -- тоже не проходит. Слово "задача" в части противопоставления целей и задач каждый трактует, как хочет -- каждый ведь много раз участвовал в пустопорожних спорах по формулированию "целей и задач" в каком-то важном документе и попытках определить, чем же отличаются цели от задач (о, я знаю уже много "самых верных пониманий" -- в каждом коллективе они складываются свои).
Почему "контрольная точка"? В контрольной точке же явно оттенок команд-глаголов из "управления кейсами", а не декларативная чисто инженерная запись о "требуемом свойстве"!
Ну, Goal (а requirement это по сути декомпозиция Goal) там тоже SMART-цель с ярко выраженным глаголом-командой. "Увеличить продажи на 20% к 3 января" -- цели все такие. И requierment, из них следующие тоже все имеют этот оттенок требуемого действия, а не требуемого пассивного свойства. Это требование действия, требование изменения. И даже стандарт говорит, что для достижения целей нужен план, и именно для этого служат requirement (но тут же стандарт сбивается, и продолжает говорить про "свойства системы").
После внимательного рассмотрения примеров (и особо замечания Gerben Wierda, что всякие контроли моделировать нужно requirements -- то, что требования контролируются, было и так понятно, но он уточнил, что сам контроль моделируется элементом requirement!), а также принимая во внимание тренды в части кейсов (контрольная точка становится элементом контроля, соединяющим требования и выполнение работы -- поскольку требования выполняются сейчас асинхронно, то в каждой контрольной точке указывается условие её достижения, фрагмент требований). То есть контрольная точка -- это тот самый синтез элемента плана и требуемых свойств, о которых говорит данный пункт стандарта.
Я писал в http://ailev.livejournal.com/1202776.html -- "Планируются события как чеклисты (к продуктам) и контрольные точки (состояния продуктов в проектах)". Вот события предприятия ("архитектуры") в ArchiMate планируются через Event, а события развития ("с архитектурой") планируются через удовлетворение requirement, контрольные точки. Так что эта логика case management попадает теперь и в дополнение целеполагания.
10. Presentation из "представления" стало "рабочим продуктом" -- объект в ArchiMate это "информация", альфа. Так что информация никак не представлена. Но она может быть представлена в данных и затем артефактом (но это уже чисто айтишные заморочки -- невидимые в деятельности), а в деятельности альфа представляется рабочими продуктами (одним или несколькими). Формулировки и объяснения стандартов ArchiMate и Essence тут весьма близки. Так что я просто учёл тут результаты наших работ с Essence.
11. Driver стал из "фактора влияния" интересом (concern). В ArchiMate, впрочем, об этом прямо говорится -- и про связь со стейкхолдером, чей этот интерес. Миром движут интересы, всё правильно. Замечание, что может быть и просто "какой-то внешний фактор" игнорируем: это означает, что интерес к фактору есть, и по норме дальше мы просто должны понимать, чей этот интерес. Но можем, конечно, не указывать, чей интерес какое-нибудь "падение рынка", язык вполне допускает тут расслабиться. Но я бы не рекомендовал расслабляться, и подумать, кого это может из стейкхолдеров волновать. Так что тут я просто чуть-чуть подправил перевод в сторону чуть более строгого системного подхода.
12. Gap стал "различием" (из "расхождения"). To be и as is не "расходятся", а "различаются".
13. Deliverable из "комплектующего" (что более пристало инженерным, а не орг-работам) стал "результатом пакета работ", практически по тексту стандарта.
14. В большинстве случаев в интерфейсе я начал писать не "ошибка при открытии файла", а "ошибка открытия файла" -- и по этому же шаблону все остальные подобные выражения. Тут, конечно, можно открывать холивар, но это явно не самый большой грех этого перевода. Хочется, хочется быть поближе к народу!
Технически сейчас ситуация такая:
-- переведено уже всё (пользовательский интерфейс+подсказки), кроме хелпа. Хелп я переводить не буду.
-- есть техническая проблема: время от времени вдруг вместо перевода показываются английские слова (иногда это при перезапуске Archi исчезает, иногда остаётся). Эту проблему буду решать в ближайшие дни -- я думаю, что-то там не то с версиями Eclipse, я сделал запрос автору Archi (ну, или придётся тут поискать какого-то местного знатока локализации в Eclipse). В принципе, основное там уже всё по-русски, и все эти вкрапления английского не слишком мешают. Тем не менее, публиковать версию пока рано. UPDATE: всё уже исправлено.
-- готов отдать language bundle для Archi 3.2.1 на бета-тестирование прямо сейчас -- под обязательство потыкать и прислать мне какие-то замечания в ближайшую пару дней. Для этого напишите мне на ailev@asmp.msk.su
По сути, это третья редакция перевода:
-- первая была формальная, и все стандартнаци были очень довольны. Уже в первой редакции я максимально согласовал с уже имеющейся терминологией переводов ISO 42010 (Архимейт на нём базируется). Эта редакция так и осталась внутренней, плагина к Archi я для неё не публиковал.
-- после тестирования на клиентах я решил резко сбить пафос и убрать по возможности канцелярит-стандартит. Основной аргумент был: деньги за реализацию архитектуры платят те люди, которые айтишных стандартов не читали, но они должны хотя бы что-то понимать из ведущихся разговоров, хотя бы полпроцента. В этом виде и вышла версия 1.0 плагина к Archi (глоссарий -- http://ailev.livejournal.com/956829.html, дополнения второй версии -- http://ailev.livejournal.com/978200.html).
-- третья версия 1.1 выйдет сейчас, и я продолжил там гнуть ту же линию снижения пафоса и укорочения говорения. Профессионального сленга стало больше, на лёгкие проблемы я сознательно махнул рукой (ибо решение этих проблем, которое я пытался реализовать в версии 1.0 было хуже, чем сами проблемы), плюс учтён опыт прошедших трёх лет -- и несколько источников ошибок я постарался исправить на уровне выбора слов.
Вот главные изменения:
1. Я перестал добавлять ко всем словам название уровня. Не "объект деятельности", и даже не "оргобъект", а просто "объект". Не "процесс деятельности", и даже не "оргпроцесс", а просто "процесс". Хотя там, где одинаковые слова для похожих элементов разных уровней, я уровень оставил -- оргсервис, программный сервис и сервис "железа".
2. Уровень Business-"люди" стал "деятельностью" (не будем беречь этого слова, потратим его свободно. Busniness -- это "дело", "деятельность"). Но в некоторых местах я вместо длинного "деятельность" даю короткую приставку "орг" -- тот же оргсервис. И всё-таки я не стал называть уровень "организационным". Три уровня деятельность-"софт"-"железо" звучат для меня более понятно, нежели организация-"софт"-"железо", ибо про деятельность того же софта я сказать не могу, а вот про организацию софта -- запросто. Но оргсервис я не перепутаю с программным сервисом, поэтому не просто "сервис", и не длинно "сервис деятельности людей" (по мотивам прошлой версии перевода), а "оргсервис", ибо короче и понятней.
3. Уровень оборудования стал уровнем "железа". А заодно Node-оборудование стало "железом" (если говорить о единице оборудования -- будет единица "железа"). "Железо" пишем в кавычках. Я с клиентами в "реальном секторе" неоднократно натыкался на то, что они подолгу не понимали, о каком я говорю оборудовании -- о том, которое в их информационных системах, или в котором их информационные системы! А уточнять каждый раз, что "айтишное оборудование" -- это длиннее и не менее сленгово, чем просто "железо".
Так что было Infrastructure usage-"использование оборудования", стало "использование "железа"", Infrastructure function стал функционалом "железа", а не оборудования, а Infrastructure interface стал интерфейсом "железа".
4. Уровень программ стал уровнем "софта". А Application Component-"программная компонента" стала "программой". Описание программы (инкапсуляция, интерфейсы, реализация файлом и т.д.) чётко указывает на то, что речь идёт именно о программном модуле. Компонента там по смыслу -- "программный функционал", на выполнение которого назначается модуль. Так что слово "компонента" просто опущено.
Ну, и Application Behaviour -- работ "софта" (а не работа программ), Application Cooperation -- взаимодействие "софта", Application Structure -- структура "софта". Там, где говорится о множестве программ, где используется собирательное понятие, там "софт".
Но не "софтовый" сервис, а "программный сервис", не "софтинка", а "программа", не функционал "софтинки", а "программный функционал" -- где имеется ввиду не весь "софт" предприятия, а одна или программа или небольшая группа программ.
5. Крутейшее изменение, которое касается и ISO 42010. View (помним, что в стандарте veiw группирует входящие в него модели) переобозван из группы описаний просто описанием. Да, там нюансы. Так, архитектурное описание (description) само состоит из разных тематических групп описаний, а элементарными описаниями являются "модели" (models). По мне сегодняшнему, так это очередная попытка навести разнотиповую иерархию там, где просто специализация типа. Ведь определение системы противопоставляется описанию системы (description -- все view вместе), которое делится на тематические описания типа архитектурного -- и уже это вполне себе view. А затем view делятся на маленькие подвьюшки -- модели. А в Archi description называется Total veiw, низовых моделек нет вовсе. И слово "модель" там занято, по смыслу это как раз definition (видеть модель можно, только вынеся на какую-то диаграмму-описание или в специальном окошке диаграммы дерева-модели -- и как называется это окошко? Правильно, тоже view).
Итог: группа описаний стала просто описанием. Есть определение, а есть описание. То, что в Archi view-окошко программы и ArchiMate view обозначаются одним словом -- это ничего, это нормально. Так что там иногда путается в переводе "закрыть окошко" и "закрыть описание".
Ах, насколько же стало проще и понятней!
Viewpoint я так и оставил "методом описания" (а не "практика описания") -- подразумевается, что в метод описания входят самые разные практики, необходимые для описания (не только метамодель, но и указания по стилю -- "соглашение о моделировании", типовые паттерны и т.д.).
6. Actor-люди стали "ответственными" -- это прямой реверанс в сторону DEMO (у них там те же Actors: те, кто имеют право что-то попросить или выполнить. Это и есть суть организации: разделение полномочий и ответственности). Тут тонкость: в организации есть обычно не два (как в Архимейте), а целых три объекта:
-- должности, подразделения -- вся органиграмма (ответственности)
-- роли по отношению к деятельности (они связаны с практиками: в ArchiMate одна практика -- одна роль)
-- люди (или их группы), занимающие должности и выполняющие в этих должностях (профессиональные, по отношению к деятельности) роли.
Архимейт явно проговаривает, что никаких конкретных исполнителей ролей в нём не предусмотрено, Actors главным образом используется для выражения органиграммы. А "ответственный" обычно ещё и несколько ролей играет, ибо назначен явно не на одну практику. И вот поэтому переводим "ответственный" (главный инженер, департамент закупок и т.д.), а не просто "исполнитель".
7. Product (который я в прошлый раз честно оставил "продуктом") надёжно всех сбивает с толку -- это "банковский продукт", "страховой продукт", но в реальном секторе каждый раз удивляются, почему Арчи не позволяет поступать с ним как с продуктом, как будто он какие-то работы (activity), а не продукт! Да, ArchiMate определяет product именно как service+contract! Вот он и ведёт себя как оргсервис при моделировании! Так что я назвал его хитро: оргсервис-продукт, чтобы прямо из названия следовала аналогия с "банковским продуктом".
Парное к нему соглашение об уровне сервиса (contract) я так и назвал полностью, чтобы дополнительно прояснить эту засаду с оргсервис-продуктом как сервисом -- "соглашение об уровне сервиса". Архимейт 2.1 тут странен: в тексте подробно говорится, что чаще всего тут SLA, а иногда другие типы контрактов. А элемент назвали контрактом. Я перевёл по наиболее частому случаю, строго по стандарту! И приписал в подсказке, что могут быть и другие виды контрактов.
8. Stakeholders стали из заинтересованных сторон просто "стейкхолдерами". Язык развивается, и это нужно учитывать. Слово компьютер постепенно заменило слово ЭВМ, и тут ровно такой же случай.
9. Requirements по более тщательному рассмотрению стало не требованиями (ещё можно говорить про требования к "софту" или "железу", но про деятельность редко говорят в терминах требований), а... контрольной точкой. Это удивило и меня самого.
Идея, что это "задачи" из "целей и задач" -- тоже не проходит. Слово "задача" в части противопоставления целей и задач каждый трактует, как хочет -- каждый ведь много раз участвовал в пустопорожних спорах по формулированию "целей и задач" в каком-то важном документе и попытках определить, чем же отличаются цели от задач (о, я знаю уже много "самых верных пониманий" -- в каждом коллективе они складываются свои).
Почему "контрольная точка"? В контрольной точке же явно оттенок команд-глаголов из "управления кейсами", а не декларативная чисто инженерная запись о "требуемом свойстве"!
Ну, Goal (а requirement это по сути декомпозиция Goal) там тоже SMART-цель с ярко выраженным глаголом-командой. "Увеличить продажи на 20% к 3 января" -- цели все такие. И requierment, из них следующие тоже все имеют этот оттенок требуемого действия, а не требуемого пассивного свойства. Это требование действия, требование изменения. И даже стандарт говорит, что для достижения целей нужен план, и именно для этого служат requirement (но тут же стандарт сбивается, и продолжает говорить про "свойства системы").
После внимательного рассмотрения примеров (и особо замечания Gerben Wierda, что всякие контроли моделировать нужно requirements -- то, что требования контролируются, было и так понятно, но он уточнил, что сам контроль моделируется элементом requirement!), а также принимая во внимание тренды в части кейсов (контрольная точка становится элементом контроля, соединяющим требования и выполнение работы -- поскольку требования выполняются сейчас асинхронно, то в каждой контрольной точке указывается условие её достижения, фрагмент требований). То есть контрольная точка -- это тот самый синтез элемента плана и требуемых свойств, о которых говорит данный пункт стандарта.
Я писал в http://ailev.livejournal.com/1202776.html -- "Планируются события как чеклисты (к продуктам) и контрольные точки (состояния продуктов в проектах)". Вот события предприятия ("архитектуры") в ArchiMate планируются через Event, а события развития ("с архитектурой") планируются через удовлетворение requirement, контрольные точки. Так что эта логика case management попадает теперь и в дополнение целеполагания.
10. Presentation из "представления" стало "рабочим продуктом" -- объект в ArchiMate это "информация", альфа. Так что информация никак не представлена. Но она может быть представлена в данных и затем артефактом (но это уже чисто айтишные заморочки -- невидимые в деятельности), а в деятельности альфа представляется рабочими продуктами (одним или несколькими). Формулировки и объяснения стандартов ArchiMate и Essence тут весьма близки. Так что я просто учёл тут результаты наших работ с Essence.
11. Driver стал из "фактора влияния" интересом (concern). В ArchiMate, впрочем, об этом прямо говорится -- и про связь со стейкхолдером, чей этот интерес. Миром движут интересы, всё правильно. Замечание, что может быть и просто "какой-то внешний фактор" игнорируем: это означает, что интерес к фактору есть, и по норме дальше мы просто должны понимать, чей этот интерес. Но можем, конечно, не указывать, чей интерес какое-нибудь "падение рынка", язык вполне допускает тут расслабиться. Но я бы не рекомендовал расслабляться, и подумать, кого это может из стейкхолдеров волновать. Так что тут я просто чуть-чуть подправил перевод в сторону чуть более строгого системного подхода.
12. Gap стал "различием" (из "расхождения"). To be и as is не "расходятся", а "различаются".
13. Deliverable из "комплектующего" (что более пристало инженерным, а не орг-работам) стал "результатом пакета работ", практически по тексту стандарта.
14. В большинстве случаев в интерфейсе я начал писать не "ошибка при открытии файла", а "ошибка открытия файла" -- и по этому же шаблону все остальные подобные выражения. Тут, конечно, можно открывать холивар, но это явно не самый большой грех этого перевода. Хочется, хочется быть поближе к народу!
Технически сейчас ситуация такая:
-- переведено уже всё (пользовательский интерфейс+подсказки), кроме хелпа. Хелп я переводить не буду.
-- есть техническая проблема: время от времени вдруг вместо перевода показываются английские слова (иногда это при перезапуске Archi исчезает, иногда остаётся). Эту проблему буду решать в ближайшие дни -- я думаю, что-то там не то с версиями Eclipse, я сделал запрос автору Archi (ну, или придётся тут поискать какого-то местного знатока локализации в Eclipse). В принципе, основное там уже всё по-русски, и все эти вкрапления английского не слишком мешают. Тем не менее, публиковать версию пока рано. UPDATE: всё уже исправлено.
-- готов отдать language bundle для Archi 3.2.1 на бета-тестирование прямо сейчас -- под обязательство потыкать и прислать мне какие-то замечания в ближайшую пару дней. Для этого напишите мне на ailev@asmp.msk.su