Обсуждение

Не слишком ли для чипизированного голема (в Вашем описании "Уровень программ") так уж и понимать: "что означают данные в реальном мире: ведь опасно к килограммам прибавлять километры".

По уровню программ есть замечание. Там есть и обещания, и поручения, и единство килограммов и километров. Например. Есть такая хрень, как финансовый мониторинг. Если организация совершила сделку на 600 000 руб и более, то она обязана срочно настучать на себя в "уполномоченный орган". Не банк, не налоговая, а ты сам должен поставить специальный софт, с ключами и АЦП, и отчитываться. А если не уследишь, то банк и налоговая все равно стукнут и тебя крепко возьмут за жопу. Уследить бывает сложно, организация большая, людей много, дела вертятся, а все сделки пропускать через специального человека (или отдел) - это трата времени, да и люди порой ошибаются. Поэтому, специальный софт следит за суммами и в случае чего бъет тревогу - шлет емейлы и СМС-ки всем причастным. При желании, можно и отчеты в "уполномоченные органы" автоматом отсылать, но это не так просто, там тоже кушать хотят и всю родню кормить, поэтому всю автоматику рубят на корню. Это на тему обещаний и поручений. Еще пример, попроще. Допустим, банальная торговля. Клиент сделал заказ товара с доставкой, фирма выставила счет, клиент его оплатил. Дальше бухгалтер принимает из банка выписку, где указан платеж клиента. И по идее, сразу же нужно товар отгрузить и доставить. То есть, бухгалтер должна позвонить менеджеру и сообщить о поступлении оплаты. Менеджер созванивается с клиентом, что оплата получена, мы готовы ваш заказ доставить. Потом выписывает и заверяет в бухгалтерии накладные, готовит маршрутный лист, вызывает курьера и передает ему товар и документы на товар и на маршрут. Это еще относительно простая схема, бывает и посложнее. Если это будет делаться людьми, то весь процесс может длиться от нескольких минут до нескольких недель - бухгалтерия может тупо не сообщить менеджеру об оплате, а тот не почешется, пока у клиента не лопнет терпение и он сам не позвонит. К счастью, весь этот процесс хорошо автоматизируется, вплоть до нулевого участия человека (!). Когда через онлайн-магазин заказывается какой-нибудь софт или фильм, то вся торговля автоматом проходит. Только при курьерской доставке пока что люди участвуют, но и это вопрос ближайшего будущего. Получается, что нематериальный софт оказывает вполне материальные услуги, через поручения людям. Что касается килограммов и километров - это всего лишь характеристики. В ювелирке учет ведется одновременно в штуках и граммах. В нефтянке в литрах, кубометрах и тоннах. В телекоме минуты и мегабайты. В галантерее есть размеры, сорта, цвета, и еще куча всяких характеристик. И везде есть учет в валюте - рубли, евры, доллары, гривны, итд. Любой продавец вам запросто к штукам прибавит граммы, переведет в рубли и умножит на километры.

Кстати, а "уровень людей", "уровень программ" и "уровень оборудования" это, случаем, не "business layer", "application layer", "technology layer" соответственно? А "объекты работ" случаем не делятся на активные и пассивные?

Уровни -- такие. А вот активные -- это выполнители работ, а объекты работ -- пассивные.

Это прямая отсылка к прикладности программ с одной стороны (программист, когда пишет код, он знает что у него за данные -- и кодирует именно это знание), и использованию (часто неосознанному) семантических технологий с другой стороны (когда программа может сама разобраться хотя бы с переводом единиц измерения, согласовать временные интервалы и т.д.). Хорошая программа работает не просто с данными, но и предусматривает работу с метаданными. А плохая программа -- это уже не программа, а часть тупого компьютерного оборудования, гонялка байтов (которые уже непонятно что означают в реальном мире, ибо на уровне оборудования это никого не волнует). В принципе, это отсылка к O-предприятию, I-предприятию и D-предприятию из DEMO. Авторы Архимейта, кстати, хорошо знакомы с DEMO.

Вот вы и путаете выполнителей-людей и выполнителей-программ, работы людей и работы программ, умения людей и умения программ. Не расстраивайтесь, все программисты это путают. Я очень надеюсь, что новый "народный" язык описания эту путаницу уменьшит -- когда начнёте диаграммы делать в русифицированном Archi, то ошибок будет меньше.

А город можно признать организацией, так же как предприятие? Можно город описать на этом языке?

Тогда либо перевод неправильный, либо вы пытаетесь что-то свое придумать на базе архимейта. Business layer - это деловой уровень, это то, как работает предприятие с клиентами/партнерами и с точки зрения клиентов/партнеров, в общих чертах. Там нет имен, но есть должности. Я вам приводил пример с торговлей - это как раз бизнес-процессы. А товар, клиент, счет, договор - это бизнес-объекты. Товар - это пассивный объект (сам нихрена не делает), клиент - активный. Есть еще "поведение" или "действие" - нематериальный процесс, например, процесс заключения договора или процесс оплаты. Application layer - прикладной уровень, или как предприятие реализует свою бизнес-модель. Тут уже фигурируют имена людей и организаций, компьютерные программы и конкретные объекты (документы с датой, номером, автором; товары со своими свойствами, итд..). Technology layer - технический уровень, это уже подробности реализации прикладного уровня. Файлы, записи БД, соединения, поля в бланках, технологические процессы, итд.. Вот с этим и работаем, все это есть в архимейте. Я вам, если хотите, ссылки дам и на описание архимейта 2.0, и на TOGAF, и на википедию, и на ГОСТ. Потому что я это не выдумал, а прочитал. И еще потому что я работал над автоматизацией десятков предприятий, и все это видел изнутри.

Нет.

И я все эти тексты читал (неужели вы думаете, что я не знаю о существовании TOGAF и не читал свеженьких версий? Я и другие архитектурные фреймворки читал, в количестве), и тоже работал с автоматизацией десятков предприятий и понасмотрелся всякого (у меня рабочий стаж в этой области с 1980). И прямо сейчас я наблюдаю за попытками использования Архимейта сразу у нескольких предприятий (причем, не только в России), и вожу почти каждый день пальчиком по свеженьким диаграммкам, подготовленным как айтишниками, так и не-айтишниками. Так что я для Архимейта не только спецификацию читал. Но я уже много лет не столько консультант по IT, сколько консультант по стратегии, и поэтому довольно много принимал участие в оргпроектах крупных компаний, в которых дело до автоматизции даже не доходило. А архитектура деятельности была нужда для самых разных других целей, для чего и делалась. Кстати, Захман в своей третьей версии фреймворка убрал вообще слово "данные", намеренно. Сказал, что на это слово прибегает слишком много айтишников, и полностью искажают смысл того, что он делает в плане архитектуры предприятия. Вот и я поступаю по его примеру. У Архимейта есть некоторые тонкости в применении, отличающие Архимейт от других стандартов (почему этот стандарт и становится популярен). Вы иногда пишете об этих тонкостях правильно, а иногда неправильно -- хотя по мере изучения материала уже много получше (подождем еще пару дней, так и вообще хорошо будет. Вот этот коммент вы уже почти правильно написали). Люди в Архимейте -- это не только должности, но и целые их группы (подразделения). Я про уровень людей еще не писал подробно. А что вы простой мой язык на свой птичий перетолковываете -- это нормально. Вы же айтишник, вот и перетолковываете. Мне же нужно подчеркнуть вполне определенные акценты, именно акценты Архимейта. Кстати, можете поглядеть на мой предыдущий перевод -- он мне как раз и не нравится, что малопонятен простым людям (последний кусочек в http://ailev.livejournal.com/978200.html -- и там в пункте 6 много-много ссылочек на прошлые тексты). Так что это я переделкой уже сделанного занимаюсь, второй версией. Вот вы берите Archi, и сделайте свой Russian language package. И вашим переводом с радостью будут пользоваться толпы айтишников. А моим переводом будут пользоваться архитекторы предприятий.

Город - не знаю, а мэрию - можно. =)

Мэрию, - говорите. Значит ли это, что описать можно нечто функционирующее тем или иным образом? Хорошо, сменим масштаб: а отдельно взятый интеллектуальный дом/здание/квартиру, - описать можно в нем? Только не представляйте дом натурально, как стены, потлок и прочее. Представьте его, как некую функционирующую организованность. Тогда можно описать? Почему я спрашиваю именно про "интеллектуальный дом", раскрывать или не надо?

Можно описать гостиницу, общежитие, товарищество жильцов. А просто дом (даже интеллектуальный) - не знаю. Разве что на техническом уровне..

Смотрю ссылку http://ailev.livejournal.com/956829.html В целом хорошо, за счет дословного перевода. Режет глаз, но хотя бы понятно, что имелось в виду. Из принципиальных неточностей: Бизнес-процесс это вполне сформировавшийся термин. http://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81 Зачем из него неопределенный "процесс" или "операцию" делать? Application component - это "прикладной компонент", "приложение-компонент". Но никак не "компонент приложения". Разница как между "частным домом" и "частью дома". Data object - это скорее порция данных, чем просто данные. Self-contained piece of information with a clear meaning to the business, not just to the application level. Документ, визитка, карточка товара. Вот есть же готовое определение, почему вы его не используете? Application service - прикладной сервис. Это не только обработка данных, а вообще любой общедоступный функционал, реализуемый прикладными программами. Бухучет, расчет зарплаты, прием заказов.

Вы думаете, я не знаю, что "бизнес-процесс" это уже вполне сформировавшийся термин?! Но я регулярно работаю с организациями, в которых к слову "бизнес" относятся отрицательно. Слово "процесс" (как развёртка во времени) тут существенно, а вот слово business лучше передавать как "деятельность". Деятельностный процесс, другими словами. Насчет "прикладного компонента" я тут полностью согласен. Но речь идет о софте, и поэтому в новом переводе это будет программная компонента. Ибо слово "прикладной" -- это слово для большинства не-айтишников ни про что. А вот слово "программа" ассоциируется с софтом. Я бы вообще "софтовая компонента" написал, но это уж совсем сленг. Ну, и вместо "программы" гостовское "программное средство" я тоже не хочу писать. Мне нужно общение айтишников и не-айтишников, как главный критерий, а соответствующий стандартам канцелярит этому явно не споспешествует. Я долго думал, вводить ли квалификатор объект/порция/набор или любой другой того же типа для данных. Пришел к решению, что не вводить: структура (выделение объектов) и так очевидна. Подробности и точность терминологии появятся при моделировании данных (если интересно, мы как раз специализируемся на моделировании сложных структур данных -- даже методики разрабатываем, см. русский и английский варианты тут: http://techinvestlab.ru/ISO15926). Архимейт же моделирование данных по факту не поддерживает (что я считаю его недостатком). Конечно, application service -- это программный сервис (ну, или сервис программ). Особо отмечу, что "неприкладные программы" (системный софт) я бы вообще лишал статуса "программ", а считал бы его частью оборудования (типа микропрограмм, или firmware -- ОС ведь это такая "прошивка" к оборудованию). Мне еще предстоит помучаться с переводом для системного софта, всё-таки нехорошо системные программы "прошивками" называть, хотя по сути это и верно.

Насколько мне известно, от слова "бизнес" корежит только потомственных бюджетников. Но это их проблемы, ибо "business" - это "дело", от слова "делать". Не обязательно опускаться до глупостей, чтобы угодить глупцам. Используйте простые слова, но не искажайте смысл. "Прикладная программа" это понятно и спецам (прикладная), и не-спецам (программа). То же самое касается "данных" и "сервиса".

Странно, почему это вводит в незнание. Может загвоздка в вашем представлении дома? Давайте его зададим. Анатолий говорит, что язык описывает три уровня работы. Назовем работу, - исполнением функций. Получаем три уровня функционирования: на уровне функций, исполняемых человеком (жителем дома), далее исполняемых программами (установленных в доме), далее на уровне оборудования дома (с программируемыми чипами). Какие функции выполняет житель дома? Их же можно задать и потом описать, так же? Чем человек-житель отличается от человека-работника мэрии? Ничем. Функции другие выполняет, ну, и что. На предприятии человек-работник тоже не такие выполняет. Но это же не помеха для языка. Какие функции выполняет охранная программа для дома, тоже можно описать. Или какие фукции выполняет программа системы отопления и вентиляции, тоже известно. Ну, а какие функции выполняют (работы) наборы оборудования дома, разве не известны? И их можно описать в этом языке. И сервисы каждого уровня можно описать. Так в чем же выражается это ваше "- не знаю"?

Давайте не будем тут про то, кого корёжит от слова "бизнес"? Меня больше корёжит, когда никакого бизнеса нет, а слово есть. Это и к Думе относится, которая "не место для дискуссий", и вообще к жизни. Так что пусть будут "процессы", а вот про "бизнес" будем говорить там, где есть предпринимательство. В речи у двухсловных сочетаний одно слово исчезает. У "прикладной программы" исчезает слово "прикладная". Я просто делаю это исчезновение сразу. И тогда "прикладной сервис" уже не перепутаешь с сервисом деятельности -- если говорить "сервис программ" и "сервис людей". Слова "данные" и "сервис", конечно, останутся. Еще раз: вы точно не моя целевая аудитория. Вам-то Архимейт по-русски не нужен, вы сами и по-английски отлично справитесь. Ну, или сделаете себе перевод, какой хотите.

Деловой уровень - это не уровень человека. Это уровень предприятия, это то, как предприятие взаимодействует с внешним миром, что оно дает и что получает. У дома этого уровня нет, все, что дом делает, дает или получает, находится на уровень ниже. Может, что-то можно натянуть на глобус этого уровня, но я этого не знаю. На прикладном уровне - двери, квартиры, лифты, лестницы, мусоропровод, уборщица, сторож, итд.. То, с чем непосредственно взаимодействуют жильцы и гости, а также сами жильцы и гости. И это с большой натяжкой, поскольку прикладной уровень - это реализация делового уровня, а у дома его нет. На техническом уровне - все остальные подробности. Отопление, вентиляция, канализация, сигнализация, и прочее электричество.

Хорошо, но тогда уж "процессы деятельности", а не просто "процессы". Вы уж извините, но я не вижу смысла упрощать до потери смысла. Это же не азбука для детского сада, а профессиональный инструмент. Кстати, даже в детской азбуке строго следуют терминологии, а пояснения дают простым языком, с наглядными примерами. Вы делаете "архимейт для чайников", но при этом опускаете его до уровня чайников. Делайте лучше "архимейт с пояснениями для чайников".