Где-то я слышал, что в психотерапии существует следующая методика работы с пациентом – пациенту предлагают сесть и написать в свободной, «потоковой» форме все что накипело, волнует, будоражит сознание и, отражаясь на подсознании, не дает спать по ночам. Применительно к этому есть хорошее, нежно ласкающее слух слово – фрирайтинг.
Итак, почему я решил это написать – когда сталкиваешься с полным пренебрежением к проектированию ПО как таковому, пренебрежением к качеству и соблюдению хоть какой-нибудь методологии разработки, всегда удивляешься. Когда сталкиваешься с этим раз за разом, об этом уже хочется написать.
Первое о чем думаешь – может инженерия уже мертва и миром правит маркетинг — не важно как написано, спроектировано, спроектировано ли вообще, главное продать, всучить, впарить? А инженерия как таковая, отошла на второй план, и настоящие «креативщики» – это эти прыткие молодые люди, менеджеры по продажам, пронырливые и настойчивые как таксы, достающие барсука из норы? Это мысль сама по себе дикая крамола, но она приходит в голову раз за разом, когда наблюдаешь происходящее.
Бизнес инженерия. Прорыв в мозгах. Типы результатов. #AlexToday 263
Теперь подробно о том, что собственно происходит. Происходит то, что инженерная деятельность оказалась служанкой бизнеса. Что самое парадоксальное даже в тех случаях, когда основной продаваемый продукт/сервис компании является программным продуктом. Бизнес диктует свои правила, бизнес ограничивает, подгоняет, бизнес благосклонно относится к тем людям из технической «обоймы», которые готовы действовать ради него в ущерб качеству и дизайну. В этом случае менеджмент напоминает недалекого человека, который сидит на суку и потихоньку этот сук подпиливает, толи из-за недостатка знаний, толи сегодня прибыль, а завтра хоть трава не расти.
Впрочем, «особенности национального менеджемента» — это тема для отдельного, большого и довольно грустного разговора…
Бизнес вообще напоминает прожорливое чудовище, которое к тому же имеет свойство поедать и самого себя.
Замечательное понятие – технический долг, всем знакомо, все читали, кое-кто даже реально представляет себе что это. Но число реальных проектов, которые ведутся с учетом этого понятия на мой субъективный взгляд, пренебрежимо мало.
Причина проста – технический долг очень не нравится бизнесу, он его ненавидит, ненавидит даже разговоры о нем.
Бизнес полюбил скрам – но очень странной любовью. Скрам в большинстве случаев это просто превосходная соковыжималка. Кто в роли фруктов и овощей? Конечно разработчики. Более того, скрам используется в качестве своеобразного «фигового листочка», прикрывающего несостоятельный подход к множеству технических вопросов.
Из скрама берется все, касающееся части «навесим побольше функционала и сделаем это побыстрее». Я имею ввиду прежде всего порции новых фич, реализация которых вешается на каждый новый спринт. Но все практики, касающиеся качества кода и продукта в целом, достижения и поддержания устойчивого к изменениям, легко тестируемого и сопровождаемого дизайна – в большинстве случаев просто отбрасываются.
Инженер: плюсы, минусы, зарплата
Тут надо оговориться – я не хочу обобщать всех и все, я говорю про тенденции, которые объективно существуют на сегодняшний день.
Далее – QA. Понятия обеспечение качества и контроль качества для огромного количества проектов является чем-то далеким и загадочным, как туманность андромеды. И это напрямую вытекает из неполноценного использования скрам-практик. Если continuous testing не реализован на проекте именно как один из процессов жизненного цикла ПО – даже если есть люди, которые в ручном режиме пытаются «нащелкать» баги в UI, такое тестирование иначе чем профанацией назвать нельзя. Результат – баги, выпорхнувшие в релиз из-за такого отношения к QA, наносят такой репутационный и финансовый ущерб компании, по сравнению с которыми затраты на постановку реально эффективного процесса работы с качеством продукта покажутся мизерными.
Но опять-таки – кто занимается этими метриками, этими подсчетами, этими соотношениями затраченных ресурсов…
Документирование бизнес тоже не любит, затрачиваемые ресурсы серьезны, эффект неочевидный, да и вообще тут тоже можно прикрыться скрамом: «у нас скрам, тесная коммуникация к группе, нам это не нужно».
Это при том, что проект досконально знают в лучшем случае 2-3 человека из группы, остальные знают его в общих чертах и/или фрагментарно, как следствие если эти, обладающие «тайным» знанием люди выходят из игры, то проще переписать все заново, что повлечет затраты, несопоставимые с затратами на документирование. Плюс к этому – возможность анализа системы на предмет рефакторинга кода или более серьезного реинжиниринга. Плюс к этому – к примеру, вход нового человека в проект. Насколько быстрее оно произойдет, насколько быстрее человек станет эффективным, если с самого начала начнет работать с задокументированной системой.
И хорошо еще, если на проекте присутствует code review, адекватно реализованная модульная архитектура на базе SOLID принципов, нормальная нотация для структурирования, форматирования, именования переменных разных уровней, классов, методов – это в значительной степени может компенсировать отсутствие документации, но думаю описанная выше идеальная ситуация – скорее исключение из правил…
Как лечить все эти негативные тенденции в индустрии разработки ПО?
Как мне видится, главная таблетка тут – образование.
Чем быстрее многоуважаемое академическое сообщество дозреет до осознания программной инженерии как самодостаточной инженерной дисциплины, а не вечной «падчерицы» у «мачехи»-математики, тем быстрее будут скорректированы учебные программы, надеюсь, больше людей будут приходить из реальной разработки в качестве преподавателей в ВУЗы.
Самое главное, что должно давать профильное образование в области разработки ПО — это объемное виденье процесса разработки, если люди имеют такое виденье, они с вероятностью близкой к единице смогут правильно расставить акценты и максимально гармонизировать требования бизнеса со своей деятельностью.
- проектирование по
- качество по
Источник: habr.com
Виды дисциплин инженерии предприятий
Есть множество дисциплин, предметом которых является инженерия организаций/предприятий/бизнесов:
· Инженерия организации (organizational engineering) – академическая (научная) дисциплина, определяющая организационную структуру предприятия. Основа – способ распределении полномочий между членами команды. Основная затрагиваемая ипостась – «команда».
· Инженерия предпринятия (enterprise engineering) – дополняется технологической инфраструктурой, включая IT-инфраструктуру. Затрагивает ипостаси: «команды», «технологии», «работы».
· Инженерия бизнеса (business engineering) – дополняет предыдущие дисциплины стратегированием по выходу на рынки (предпринимательской деятельностью). Дополнительная ипостась – «возможности».
Системная инженерия в этом ряду замысливает целевую систему, проектирует ее, изготавливает, испытывает, эксплуатирует и выводит из эксплуатации. При этом затрагиваются ипостаси «определение системы» и «воплощение системы».
Для того, чтобы заниматься целевой системой, необходимо замыслить, спроектировать, изготовить и т.д. предпринятие, как обеспечивающую систему: команду, технологии и выполняемые ими работы.
Основной предмет курса: инженерия предпринятия. Трактуется как поддисциплина системной инженерии, в которой к рассмотрению организации добавляется рассмотрение технологической инфраструктуры, включая IT-инфраструктуру.
Термин «предпринятие» позволяет включить в себя:
· Предприятия – юридические лица, включая холдинги и филиалы.
· Оргструктуры меньшего размера, включая подразделения предприятий, рабочие группы, проектные команды.
· Структуры большего размера, в частности, несколько предприятий, сотрудничающих между собой в рамках большого проекта.
Тем самым, инженерия предпринятия понимается как расширение инженерии предприятия.
Следует отличать предпринятия и сообщества. Предпринятие предполагает определенную цель и кооперацию деятельности сотрудников по созданию целевых систем. Сообщества создаются для обмена знаниями, выработки общих принципов и знакомства людей друг с другом, не предполагая создания целевых систем.
Еще одно отличие предпринятия от сообщества – организованность входящих в него людей. Это, в свою очередь, позволяет давать друг другу поручения по использованию команды и технологий. Это можно считать следствием основного отличия – того, что предпринятие имеет какую-то цель.
Сущности предпринятия
Предпринятие представляет собой систему, которая выполняет функцию, задаваемую собственниками. Собственники являются стейкхолдерами. Они могут одновременно быть как собственниками, так и членами команды и даже клиентами.
Цели предпринятия делятся на два вида:
· Общие (goals), которые никогда не будут достигнуты (деньги для акционеров в возможно большем количестве).
· Конкретные (targets) – достижимые сейчас. В частности, выполнение работ, необходимых для реализации инженерного проекта.
· Миссия предпринятия формулируется в терминах его целевой деятельности. а не прибыльности. Инженерия предпринятия получает миссию в качестве входных данных.
Цель инженерии предпринятия – получение самого быстрого во всех смыслах предпринятия (быстрее выпускающее целевую систему, быстрее осваивающее технологии, выполняющее проекты и т.п.).
Цели должны соответствовать подходу SMART, т.е., цели должны быть:
· S – specific, significant, stretching – конкретная, значительная.
· M – measurable, meaningful, motivational – измеримая, значимая, мотивирующая.
· A – attainable, agreed upon, achievable, acceptable, action-oriented – достижимая, согласованная, ориентированная на конкретные действия.
· R – realistic, relevant, reasonable, rewarding, results-oriented – реалистичная, уместная, полезная и ориентированная на конкретные результаты.
· T – time-based, timely, tangible, trackable – на определенный период, своевременная, отслеживаемая.
Корпоративное управление – это практика признания ценностей и целей хозяев предпринятия, учет ограничений со стороны других стейкхолдеров, выбор текущих целей, выработка стратегии и тактики их достижения в изменяющихся внешних условиях (в том числе бизнес-планирование и составление программ развития — но таким образом, чтобы обеспечить подотчётность и подконтрольность предпринятия его хозяевам).
Одним из основных частей ипостаси «возможности» является практика стратегирования. Основной признак стратегии – это не «чем бы заняться», а нахождение занятия, при котором отказываешься от многих других занятий.
Стратегирование – это предпринимательская деятельность, умение «предвидеть будущее». Стратегирование (выбор того, чем заняться) по мере принятия различных решений (реализации стратегии) плавно перетекает в маркетинг (привлечение внешних стейкхолдеров-покупателей) и продажи (заключение конкретных сделок).
Инженерия предпринятия не занимается предпринимательством, стратегированием, маркетингом, продажами, но тесно связана с ними. Инженерия предпринятия создаёт ту часть предпринятия (организационную структуру и технологию, т.е. организационные звенья, инструменты, способы выполнения и координации работ, рабочие продкуты), которая занимается стратегированием/маркетингом/продажами – и обеспечивает неразрывную связь этой части предпринятия с инженерной частью.
Инженерия предпринятия подобна системной инженерии, где в качестве целевой системы выступает само предпринятие. Основные отличия:
· Вместо инженерии требований говорят о стратегировании и/или целеполагании.
· Системную архитектуру называют архитектурой предприятия.
· Вместо проверок и приемок говорят об измерениях.
· Задачи операционного управления рассматривают более с менеджерской, нежели с инженерной точек зрения.
· Классические представления системной инженерии усложнены за счет того, что человеческие особенности заведомо сложнее любых технических систем.
Общим является то, что полноценное выполнение предпринятием своих функций требует тщательного проектирования и воплощения его инженером.
Управление технологиями 0 это замена практик: осознание и вывод из использования старых практик и освоение новых практик.
Есть отличия между развитием и совершенствованием предпринятия:
· Развитие – это смена технологии, совершенствование – сохранение технологии.
· Развитие – это управление технологиями, совершенствование – отлаживание технологии, ее «настройка», операционное управление.
· Развитие – продвижение в новые ситуации, совершенствование – занятие обороны в знакомой ситуации и продвижение за счет этого.
Управление технологиями страшно, ибо прекращает совершенствование, показывает бесперспективность совершенствования в применяющихся практиках.
Совершенствование комфортно и ведет к успеху, если рыночная ситуация не меняется. Если жизненные ситуации меняются, то совершенствование смертельно.
У предприятия различают производственные (целевые) проекты и проекты развития.
· Производственные – это проекты по оказанию услуг клиентам, проектированию, конструированию и изготовлению целевых для клиентов систем.
· Целевой системой проекта развития является технология производственного проекта (в части разворачивания новых инструментов и рабочих продуктов) и команда производственного проекта (в части образования членов команды новым дисциплинам и обучения их работе с инструментами и рабочими продуктами).
Закон Конвея утверждает, что «структуры определения целевой системы (продукта, изделия, сложного инженерного объекта, сервиса и т.д.) будут копировать будут копировать структуры коммуникации создающего его предпринятия.
Перефразируя: два модуля не смогут провзаимодействовать, если не смогут провзаимодействовать их создатели, поэтому для заработавшей системы структура конечных модулей будет отражать структуру коммуникации разработчиков.
Таким образом, структура целевой и обеспечивающей системы оказываются связанными. Плохо, если разбиение системы на модули игнорирует коммуникационную и организационную структуру разработчиков этих модулей.
Следствие Брукса: поскольку первые приходящие в голову архитектуры обычно плохи, то разбиение системы на модули неизбежно будет меняться по ходу проекта. Организация должна быть гибкой в плане изменения архитектуры.
Все наработки системного подхода вполне применимы к инженерии предпринятия:
· Предпринятия материальны (предпринятие есть люди, здания, сооружения, оборудование и другие ресурсы, среди людей есть договоренности по полномочиям в использовании этих ресурсов).
· Предпринятия состоят из структурных иерархий компонент, модулей, размещений.
· Предпринятие имеет жизненный цикл.
Нельзя недооценивать совершенствование. Предпринятие должно находиться в цикле непрерывного совершенствования.
Цикл непрерывных улучшений предпринятия представлен на рисунке 1.7.1.
1.7.1 Цикл непрерывных улучшений
Еще один известный цикл совершенствования – цикл Шухарта-Деминга (цикл PDCA). Он изображен на рисунке 1.7.2.
1.7.2 Цикл Шухарта-Деминга
Архитектура предпринятия
Условно любое предпринятие можно вообразить выполняющим инженерные проекты. При этом все инженерные деятельности можно переформулировать как «сервисы». Пример: благотворительный фонд – сервис для благотворителей. Получатели благ – бенефициары, но не клиенты.
Как любая система, предпринятие имеет определение и воплощение. Речь идет об ипостасях организационного и технологического решения предпринятия: распределение ответственностей и полномочий между людьми и подразделениями, а также – какие практики (технологии) поставлены на предпринятии.
Объекты определения предпринятия:
· Стратегии, описания целеполагания, бизнес-архитеуткры (аналог «требований»).
· Архитектуры предпринятия (основные организационные и логистические решения).
· Неархитектурные организационные и логистические (операционные) решения.
Есть две полярных точки зрения на определение предпринятия:
· Бесполезно выражать его в рабочих продуктах, ибо оно никогда не будет совпадать с реальностью.
· Мы ничего не сможем изменить в предпринятии, пока хоть как-то не определим его.
Определить/описать предпринятие – описать его в терминах объектов воплощения:
· Деятельность (компоненты: услуги, сервисы, функции, роли, полномочия).
· Подразделения (модули: сотрудники, здания, оборудования, материалы).
· Размещение (географическое нахождение ресурсов): распределение ресурсов по зданиям, странам, рынкам и т.п.
· Другие аспекты, интересные разным стейкхолдерам.
Виды практик описания деятельности:
· Технологии (дисциплины, рабочие продукты, инструменты).
· Работы (логистика: отслеживание выполнения работ ограниченными ресурсами предпринятия – процессные и проектные описания).
· Команда (упор на организацию тез, кто выполняет работы).
Организация – группа людей, зданий, материалов, в которой оговорены полномочия людей по распоряжению ресурсами, включая возможность поручать друг другу выполнение работ. Сущность организации – коммуникация в части координации выполнения работ.
Архитектура предприятия ничем особенным не отличается от архитектуры любой другой системы. Только компоненты, модули, размещения выглядят другим образом, плюс – принципиальные схемы выглядят по-другому. По сути, именно доля архитектуры предприятий были изобретены организационные диаграммы. Архитектурное описание предприятия состоит из ряда диаграмм, необходимых для того, чтобы понять устройство организации и поменять его в будущем.
Большинство архитектурных диаграмм изображают процессы, процедуры, практики, проекты, функции, структуры подчиненности и т.д.
Матрица Захмана
Важным методом (а вероятно и основным) проектирования архитектуры предприятия является матрица Захмана, изображенная на рисунке 1.7.3.
1.7.3 Матрица Захмана
Строки матрицы – ипостаси предприятия с точки зрения разных стейкхолдеров. Столбцы – различные элементы жизненного цикла каждой ипостаси. В клетки матрицы вносятся описания и диаграммы архитектуры элемента (их может быть несколько). Допускается вносить в клетки идентификаторы создаваемых документов.
Бизнес-архитектура
В архитектуре предприятия отдельно определяют, как предприятие будет получать возможности – бизнес-архитектуру. В бизнес-архитектуре особо выделяют сети пользы и бизнес-модели.
Сети пользы позволяют обсудить, как добавляется польза от выстраивания каких-то цепочек обменов. На основе восьми разных способов описания цепочек «добавления пользы» создан стандарт OMG VDML (value delivery modeling language). Альтернативный язык описания бизнес-архитектуры – OMG BMM (business motivation model).
Бизнес-модель – ответ на вопрос, «как заработать деньги на предмете деятельности». Есть много способов описания бизнес-модели (от текстовых описаний до моделирования в VDML), Сейчас одним из популярных является описание при помощи «порождения бюизнес-модели»: бизнес-модель описывается через ключевые деятельности, ключевых партнеров, ключевые ресурсы, структуру затрат, отношения с клиентами, сегментирование клиентов, предложение пользы, каналы продаж, источники доходов). Для удобства все это изображается на диаграмме-«холсте».
Следует помнить, что бизнес-архитектура является частью предпринимаетльского, а не инженерного взгляда. Архитектурой предприятия чаще занимаются не стратеги, а выходцы из айтишников, включая «бизнес-аналитиков», а бизнес-архитектура – часть менеджерской/стратегической деятельности.
Органиграмма предприятия
Органиграмма (организационная диаграмма) – структура подразделений, декомпозиция предприятия, его модульная структура. Подразделение в органиграмме представлено либо своим названием, либо своим руководителем.
Пример органиграммы предприятия приведен на рисунке 1.7.4.
1.7.4 Пример структуры организации
На диаграмме приведен пример организации, целью которой является разработка приложений – путеводителей для туристов. В нем выделены подразделения, занимающиеся разработкой программного обеспечения и контента для путеводителей, а также – коммерческий отдел (маркетинг и продажи) и дирекция, обеспечивающая деятельность организации. Управленческие решения по организации принимаются советом директоров, состоящим из генерального директора и руководителей подразделений верхнего уровня.
Источник: megalektsii.ru
Инженерия предприятия
Дисциплины, предметом которых является инженерия систем-организаций/предприятий/бизнесов:
- Organizational engineering — академическая (научная) дисциплина, в которой речь идёт главным образом о “человеческой” (организационной) части предприятия — организации. Этот предмет организации очень грубо можно свести к способу распределения полномочий в альфе “команда”: как команда делит между собой работы и координирует выполнение этих работ.
- Enterprise engineering — практическая инженерная дисциплина, трактуется как поддисциплина системной инженерии. Всё организационное дополняется в ней вниманием к технологической инфраструктуре, включая IT-инфраструктуру — предмет тут альфы команды, технологии, работы.
- Business engineering — более широкий термин, в него включается также и стратегирование по выходу на какие-то рынки, т.е. предпринимательская деятельность: для бизнеса характерно внимание не только к организации и технологиям работы, но и альфе возможностей, которые приносят стейкхолдеры.
Системная инженерия в этом ряду дисциплин занимается своим делом: альфами определения и воплощения системы — замысливает целевую систему, проектирует её, изготавливает, испытывает, эксплуатирует и выводит из эксплуатации (хотя и необязательно все это происходит в рамках одного предприятия).
Самая приоритетная цель самой инженерии предприятия: получить быстрое во всех смыслах слова предприятие — быстро выпускающее целевую систему, быстро перестраивающееся и осваивающее новые технологии, быстро выполняющее проекты. В конечном итоге в конкуренции побеждает обычно самый быстрый, поэтому цель повышения скорости работы явно выделяется изо всех других целей. Если вы не знаете, делать ли вам дешевле, лучше или быстрее — делайте быстрее, это в долгосрочном плане самая выигрышная стратегия (на сэкономленное время вы успеете сделать другие проекты, причём и лучше, и дешевле).
Инженерия предприятия создаёт ту часть предприятия (организационную структуру и технологию, т.е. организационные звенья, инструменты, способы выполнения и координации работ, рабочие продкуты), которая занимается стратегированием/маркетингом/продажами — и обеспечивает неразрывную связь этой части предприятия с инженерной частью.
Миссия предприятия формулируется в терминах его целевой деятельности, а не прибыльности. Инженерия предприятия получает миссию предприятия как входную для своей работы (это user needs, желания собственников).
Инженерия предприятия подобна системной инженерии, но с оговорками:
- вместо инженерии требований по отношению к предприятию говорят чаще о стратегировании/целеполагании (как и в случае инженерии требований, работа с user needs тесно связана с работой над требованиями — в данном случае определением функций предприятия как “чёрного ящика”, с выходом на функциональную декомпозицию), системную архитектуру называют архитектурой предприятия,
- по факту не говорят о проверках и приёмках, но занимаются измерениями (measurements — выставляют KPIs/Key Performance Indicators и проверяют их выполнение),
- задачи операционного управления (operation management — максимизации прохода работ через систему-предприятие), лидерства (leadership) и управления организационными изменениями (change management) системы систем предприятия рассматривают совместно больше с менеджерской (т.е. учитывая человеческий и социальный аспекты предприятия), нежели инженерной (предприятие-машина) точки зрения.
- классические представления системной инженерии не слишком применимы к предприятию: в силу самопринадлежности каждого человека, как основной организационной единицы, речь всегда идёт о системо-системной инженерии. Это означает, что можно сколь угодно тщательно определять предприятие, но вот воплощение предприятия может проходить с огромным трудом.
Практики инженерии предприятия
- Корпоративное управление
- Стратегирование
Виды описания предприятия
- Описание работ — process-based (activity-based), Управление процессами,OMG BPMN
- Описание технологии — product-based (практики, кейсы), CMMN
- Описание команды — communications-based (полномочия и поручения), DEMO
- Описание архитектуры предприятия (см. Архитектурные подходы)
Развитие и совершенствование предприятия
Бизнес-архитектура
В архитектуре предприятия выделяют определение того, как предприятие будет получать возможности. Бизнес-архитектура может быть частью общей архитектуры предприятия, либо отдельно от любых других определений предприятия. В бизнес-архитектуре особо выделяются описание сети пользы и бизнес-модели.
Сети пользы (value networks) позволяют обсудить то, как добавляется польза от выстраивания каких-то цепочек обменов (value chain, value-added).
Для описания цепочек “добавления пользы” используют
- стандарт OMG VDML (Value Delivery Modeling Language).
- язык описания бизнес-архитектуры это OMG BMM (business motivation model).
Бизнес-модель отвечает на вопрос “как вы зарабатываете деньги на том, что делаете”.
Органиграмма
Органиграмма (organizational chart) — структура подразделений, декомпозиция предприятия, модульная его структура. Любую функцию предприятия должен кто-то поддержать: компоненты должны быть реализованы какими-то модулями. Как и любая архитектура, архитектура предприятия считается созданной только тогда, когда вместе удалось совместить логическую архитектуру (требуемые деятельности — поведения, функции, процессы, практики, коммуникации) и физическую структуру, включающую обычно определение полномочий по распоряжению её физическими ресурсами.
Неархитектурные описания предприятия
Неархитектурные описания предприятия можно обнаружить в крупном предприятии по-разному описанными минимум четырежды в самых разных подразделениях:
- в архитектуре предприятия, чтобы понимать, какие информационные системы её поддерживают, при этом архитектура предприятия часто будет разбита на два отдельно моделируемых куска:
- «бизнес-процессы» и регламенты работы будут отмоделированы в «службе обеспечения качества» — ибо есть стойкое поверье, что описание процесса помогает именно качеству выполнения работ, и будет использован “Процессный подход” (т.е. описана последовательность действий).
- архитектура информационных систем и аппаратного комплекса будут отмоделированы в «IT-службе» как IT-архитектура (а иногда и этот кусок бьют на отдельно архитектуру программного обеспечения и архитектуру компьютерного и связного оборудования).
Информация и данные в предприятии
Информация и данные, которая используется во множестве проектов/предприятий называется:
- знаниями (если акцент делается на кортекс и том, что «внутри головы», а также обсуждения потребностей в этом знании. О формате представления умолчим, ибо употребляющие слово «знания» избегают разговора про форматы и формализмы).
- нормативно-справочной информацией (если акцент делается на эксплицитно представленном знании в любой их форме — неструктурированной/полнотекстовой, равно как структурированной в виде объектных, реляционных, графовых баз данных, файлов данных компьютерного моделирования и т.д.).
- справочными данными (если акцент делается на структурированной части НСИ, представленной единообразно, а рассмотрение не столько содержательное-инженерное, сколько менеджерское-логистическое — то есть “хранение и доставка данных по назначению”, абстрагированное от смысла данных).
- мастер-данными (если акцент делается на справочных данных, подвластных единому центру администрирования — обычно в рамках одного предприятия- юрлица).
Виды работ над информацией:
- инженерная/информационная работа (преобразование в соответствии с технологией получения целевой системы)
- операционная работа («управление» в его учётном/конфигурационном и логистическом/маршрутизационном смысле, акцент на формирование данных в отвязке от их содержания, их учёт и их передачу между местами содержательной обработки).
Ссылки
- гильдия бизнес-архитекторов (главный продукт — Business Architecture Body of Knowledge, BIZBOK™ 3.0) — новое объединение, организации всего пара лет, они делают акцент на то, что это «знание архитекторов от сохи».
- ассоциация бизнес-архитекторов (главный продукт — сертификация бизнес-архитекторов), это смычка университетов и консалтеров.
- SIG в OMG (стандарт VDML — это как раз их рук дело, презентации).
- дискуссионная группа в LinkedIn.
- разные вебсайты типа http://www.bainstitute.org/ (утверждают, что там комьюнити более 40тыс. членов, родственные сайты BPMinstitute.org и SOAinstitute.org).
- школы типа Chicago School of Business Architecture.
См. также
Источник: sewiki.ru