Бизнес-архитектура: моделирование полезности (value) и справляемости с (capabilities)
Бизнес-архитектура (business architecture) это совсем не то же самое, что "просто часть архитектуры предприятия" (enterprise architecture) с тамошней "архитектурой деятельности" (как правильно было бы переводить в большинстве околоайтишных случаев слово business, в буквальном его переводе "бизнес" явно имеющее предпринимательский смысл). Я бы честно переводил по-разному "архитектуру деятельности" в разных околоайтишных подходах типа Архимейт и "родную" business architecture с её лозунгом "начинайте с бизнес-модели". Традиционная (не-айтишная) бизнес-архитектура -- это "про всё важное" (помним про определение архитектуры!) для бизнеса, т.е.:
-- предпринимательскую стратегию
-- формулирование/документирование этой стратегии
-- переход к выполнению сформулированной стратегии.
Бизнес-архитектура является традиционной вотчиной экспертов из McKinsey & Co, Bain & Co, Booz & Co, BCG, Palladium и прочих всеми ругаемых "консультантов не по делу". Именно это преподаётся в разных университетах в курсах MBA. Ключевые слова тут -- "кому это нужно" (полезность, value), "справляемся ли мы с" (capability, над переводом думать и думать), "мы банда" (сообщество, кластер, фирма, рабочая группа) и т.д.. Обратите внимание, как этот "предпринимательский" разговор (начинающийся с вопроса о том, кому всё это нужно и зачем мы всё это делаем) отличается от "работ/процессов", "акторов", "функций" и прочего привычного менеджерского и инженерного разговора, очень важного для организации эффективного производства (которое крайне важно, когда вы уже знаете, что производить, и вам нужно сделать подешевле и побыстрее). Кроме "побыстрее" и "подешевле", или даже "чтобы результат был качественный" (инженерный взгляд на вещи), бизнесменам нужно ответить на вопрос "зачем это вообще делать" (не технологическая причинно-следственная цепочка, а ценностная -- нужно ли кому-нибудь затеваемая деятельность).
На сегодня есть:
-- гильдия бизнес-архитекторов -- http://www.businessarchitectureguild.org/ (главный продукт -- Business Architecture Body of Knowledge, BIZBOK™, к концу года выйдет уже версия 3.0). Это новое объединение, организации всего пара лет, они делают акцент на то, что это "знание архитекторов от сохи".
-- ассоциация бизнес-архитекторов -- http://www.businessarchitectsassociation.org/ (главный продукт -- сертификация бизнес-архитекторов), это смычка университетов и консалтеров. Обратим внимание, что гильдия бизнес-архитекторов придерживается других взглядов на предмет, чем ассоциация (отчетливо это проявляется в репликах William Ulrich треда http://www.linkedin.com/groups/When-Stars-Align-Business-Architecture-4379346.S.130420677).
-- SIG в OMG -- http://bawg.omg.org/ (стандарт VDML -- это как раз их рук дело, презентации http://bawg.omg.org/12-06-01.pdf, текст последней версии -- http://neffics.eu/wp-content/uploads/2012/06/12-05-02.pdf).
-- дискуссионная группа в LinkedIn -- http://www.linkedin.com/groups/Business-Architecture-Perspectives-Transforming-Business-4379346
-- разные вебсайты типа http://www.bainstitute.org/ (утверждают, что там комьюнити более 40тыс. членов, родственные сайты BPMinstitute.org и SOAinstitute.org -- ну, вы поняли).
-- школы типа http://paularthurbodine.com/the-chicago-school-of-business-architecture/
-- и много чего другого, ссылки наверху даже не надводная часть айсберга, это махонький кусочек.
Архитектура предприятия (включая тамошнюю архитектуру деятельности) -- это то, чем сегодня занимаются не столько стратеги, сколько выходцы из айтишников, включая "бизнес-аналитиков" (которые опять же, про "деятельность" как тип для повторяющихся в чём-то дел, но не про "бизнес" в предпринимательском смысле этого слова), тоже вырастающих из программистов. Это часть enterprise engineering, которая в свою очередь часть systems engineering в части систем предприятий. Распознать, с какой именно архитектурной школой мы имеем дело легко: айтишники мыслят прежде всего "процессно" (в крайнем случае -- сервисно), что позволяет относительно легко объяснять, как используется софт. Даже "антипроцессники" с трудом понимают, о чем вообще эти "бизнес"-архитекторы говорят (см., например, недоумения Max Pucher по поводу VDML -- http://www.linkedin.com/groups/VDML-ACM-DCM-2452802.S.88269024, он видит в capabilities и value chains главным образом motivation model, а затем быстро переходит к GRL-для-предприятий, собственно как и реализовано в "стратегии-для-айтишников" OMG BMM). Обратный ход от "стратегов" к айтишникам тоже делается -- вот, например, попытка: http://www.valuenetworksandcollaboration.com/advanced/processworkflowvna.html (опять же, обратите внимание упор на intangibles -- это явно не artifact-based!).
Айтишные процессы нацелены в общем случае на "как сделать" и "кому отдать", а вот бизнес-потоки (business streams) -- как угодить клиенту, это про "клиент-ориентированность" и документирование "трассирования к нуждам клиента". Ну ладно, "стейкхолдер-ориентированность" (ибо акционер ведь тоже клиент, хотя и другого рода).
В "большой системной инженерии" (читай: военной системной инженерии) этот тренд на "бизнес-архитектуру" проявляется в резком сдвиге от обсуждения системы-как-сервисной к обсуждению всяческих capabilities в systems of systems engineering. Никакого "бизнеса" у военных, но вот самый верхний "стратегический" уровень заказа работ системным инженерам (acquisition) -- это заказ capabilities, а не systems или services. Заказывается поддержка возможности что-то делать, а не системы или сервисы этих систем. Это тот же тренд, что и в организациях, от которых требуют "конкурентоспособности", а не "поддержки сервиса по выигрышу конкуренции".
ArchiMate 2.0 (http://pubs.opengroup.org/architecture/archimate2-doc/) является неплохой попыткой гармонизации мира "бизнесОв" и "операционистов-процессников", но и там айтишники с их "сквозными процессами" на диаграммах являются главными, а все эти value и "стратегические" дополнения версии 2.0 только аннотируют основное процессное блюдо, а не являются полноценными главными объектами для архитектурной работы. То же можно сказать про все остальные enterprise architecture frameworks: их делали айтишники, менеджерам с ними плохо, они не про "бизнес", а больше про "операции".
Так что стоит задача в части архитектуры предприятия гармонизировать не просто несколько стандартов, а несколько совершенно разных групп описаний (viewpoints), адресующих совершенно разные интересы абсолютно разных заинтересованных сторон:
-- бизнес-стратегов (VDML, гармонизирующий сам по себе довольно много, а также всяческие canvas типа http://businessmodelgeneration.com/)
-- управленцев-операционщиков (BMM, ArchiMate 2.0 и т.д.. CMMN, Essence/SPEM 2.0 и BPMN 2.0 наряду со SBVR попадают сюда же). Все эти case management, critical chain -- отсюда. Организационный аспект (кто что кому может поручить, кто чем распоряжается -- DEMO) это тоже главным образом сюда, это "коммуникативная парадигма" процессов, хотя у Koskela на этот счёт это "инженерный" аспект дела (пункт 2.1. в http://ailev.livejournal.com/603806.html -- кто что кому обещает определяется содержанием работы прежде всего).
-- содержательных людей (инженеров), которых прежде всего интересуют стандарты описания продукции и управления конфигурацией, а также выбор адекватной для объектов работы технологии. Удивительно, но про "артефакты" aka "объекты работы" (work products) в стратегических или операционных стандартах практически ничего сказать нельзя, ибо детализация объектов работ в тех описаниях не предусмотрена. Тут интересны новинки типа языков описания variability, а также тренда использования онтологий (типа ISO 15926 и ISO 15629) как средств отражения разнообразия. Действительно, видов объектов в разы и разы больше, чем задействующих их видов процессов, и само это разнообразие тут является проблемой. Ну, и инженеров волнуют неожиданные (ибо природа упруго сопротивляется) изменения, отсюда issue tracking и adaptive case management в связи с управлением конфигурацией.
Нужно чётко понимать, что эти взгляды на деятельность какого-то предпринятия (ценностный, потоковый и технологический) абсолютно разные, но это не отменяет задачу создать компактный язык (мета-модель, онтологию), позволяющий отражать договорки бизнесменов (кому выгодно и кто заплатит), менеджеров (как делать эффективно и кто будет делать) и инженеров (как и из чего получить годный результат). Я не первый раз об этом пишу (вот, например, в 2008г. я писал про "коскеловщину", ср. с пунктом 2 в http://ailev.livejournal.com/603806.html -- ведь ровно то же самое, хотя чуток другими словами. Собственно, это очередной пост в рамках сказанного в том давнем посте "А теперь нужно самому крепко подумать, и выдать обобщающий для всего этого месива фреймворк". Это, конечно, предмет проекта ПраксОС, praxos).
А есть ещё взгляд айтишников, которым этот компактный язык нужно поддержать в своих информационных системах, и им нужен какой-то формализм для этого языка, ибо компьютеры пока художественные образы типа "работа слаженной команды" и "визионерство наших руководителей" не поддерживают.
Созданием такого языка и занимаемся, прикидки (на русском и английском) будут чуть попозже.
-- предпринимательскую стратегию
-- формулирование/документирование этой стратегии
-- переход к выполнению сформулированной стратегии.
Бизнес-архитектура является традиционной вотчиной экспертов из McKinsey & Co, Bain & Co, Booz & Co, BCG, Palladium и прочих всеми ругаемых "консультантов не по делу". Именно это преподаётся в разных университетах в курсах MBA. Ключевые слова тут -- "кому это нужно" (полезность, value), "справляемся ли мы с" (capability, над переводом думать и думать), "мы банда" (сообщество, кластер, фирма, рабочая группа) и т.д.. Обратите внимание, как этот "предпринимательский" разговор (начинающийся с вопроса о том, кому всё это нужно и зачем мы всё это делаем) отличается от "работ/процессов", "акторов", "функций" и прочего привычного менеджерского и инженерного разговора, очень важного для организации эффективного производства (которое крайне важно, когда вы уже знаете, что производить, и вам нужно сделать подешевле и побыстрее). Кроме "побыстрее" и "подешевле", или даже "чтобы результат был качественный" (инженерный взгляд на вещи), бизнесменам нужно ответить на вопрос "зачем это вообще делать" (не технологическая причинно-следственная цепочка, а ценностная -- нужно ли кому-нибудь затеваемая деятельность).
На сегодня есть:
-- гильдия бизнес-архитекторов -- http://www.businessarchitectureguild.org/ (главный продукт -- Business Architecture Body of Knowledge, BIZBOK™, к концу года выйдет уже версия 3.0). Это новое объединение, организации всего пара лет, они делают акцент на то, что это "знание архитекторов от сохи".
-- ассоциация бизнес-архитекторов -- http://www.businessarchitectsassociation.org/ (главный продукт -- сертификация бизнес-архитекторов), это смычка университетов и консалтеров. Обратим внимание, что гильдия бизнес-архитекторов придерживается других взглядов на предмет, чем ассоциация (отчетливо это проявляется в репликах William Ulrich треда http://www.linkedin.com/groups/When-Stars-Align-Business-Architecture-4379346.S.130420677).
-- SIG в OMG -- http://bawg.omg.org/ (стандарт VDML -- это как раз их рук дело, презентации http://bawg.omg.org/12-06-01.pdf, текст последней версии -- http://neffics.eu/wp-content/uploads/2012/06/12-05-02.pdf).
-- дискуссионная группа в LinkedIn -- http://www.linkedin.com/groups/Business-Architecture-Perspectives-Transforming-Business-4379346
-- разные вебсайты типа http://www.bainstitute.org/ (утверждают, что там комьюнити более 40тыс. членов, родственные сайты BPMinstitute.org и SOAinstitute.org -- ну, вы поняли).
-- школы типа http://paularthurbodine.com/the-chicago-school-of-business-architecture/
-- и много чего другого, ссылки наверху даже не надводная часть айсберга, это махонький кусочек.
Архитектура предприятия (включая тамошнюю архитектуру деятельности) -- это то, чем сегодня занимаются не столько стратеги, сколько выходцы из айтишников, включая "бизнес-аналитиков" (которые опять же, про "деятельность" как тип для повторяющихся в чём-то дел, но не про "бизнес" в предпринимательском смысле этого слова), тоже вырастающих из программистов. Это часть enterprise engineering, которая в свою очередь часть systems engineering в части систем предприятий. Распознать, с какой именно архитектурной школой мы имеем дело легко: айтишники мыслят прежде всего "процессно" (в крайнем случае -- сервисно), что позволяет относительно легко объяснять, как используется софт. Даже "антипроцессники" с трудом понимают, о чем вообще эти "бизнес"-архитекторы говорят (см., например, недоумения Max Pucher по поводу VDML -- http://www.linkedin.com/groups/VDML-ACM-DCM-2452802.S.88269024, он видит в capabilities и value chains главным образом motivation model, а затем быстро переходит к GRL-для-предприятий, собственно как и реализовано в "стратегии-для-айтишников" OMG BMM). Обратный ход от "стратегов" к айтишникам тоже делается -- вот, например, попытка: http://www.valuenetworksandcollaboration.com/advanced/processworkflowvna.html (опять же, обратите внимание упор на intangibles -- это явно не artifact-based!).
Айтишные процессы нацелены в общем случае на "как сделать" и "кому отдать", а вот бизнес-потоки (business streams) -- как угодить клиенту, это про "клиент-ориентированность" и документирование "трассирования к нуждам клиента". Ну ладно, "стейкхолдер-ориентированность" (ибо акционер ведь тоже клиент, хотя и другого рода).
В "большой системной инженерии" (читай: военной системной инженерии) этот тренд на "бизнес-архитектуру" проявляется в резком сдвиге от обсуждения системы-как-сервисной к обсуждению всяческих capabilities в systems of systems engineering. Никакого "бизнеса" у военных, но вот самый верхний "стратегический" уровень заказа работ системным инженерам (acquisition) -- это заказ capabilities, а не systems или services. Заказывается поддержка возможности что-то делать, а не системы или сервисы этих систем. Это тот же тренд, что и в организациях, от которых требуют "конкурентоспособности", а не "поддержки сервиса по выигрышу конкуренции".
ArchiMate 2.0 (http://pubs.opengroup.org/architecture/archimate2-doc/) является неплохой попыткой гармонизации мира "бизнесОв" и "операционистов-процессников", но и там айтишники с их "сквозными процессами" на диаграммах являются главными, а все эти value и "стратегические" дополнения версии 2.0 только аннотируют основное процессное блюдо, а не являются полноценными главными объектами для архитектурной работы. То же можно сказать про все остальные enterprise architecture frameworks: их делали айтишники, менеджерам с ними плохо, они не про "бизнес", а больше про "операции".
Так что стоит задача в части архитектуры предприятия гармонизировать не просто несколько стандартов, а несколько совершенно разных групп описаний (viewpoints), адресующих совершенно разные интересы абсолютно разных заинтересованных сторон:
-- бизнес-стратегов (VDML, гармонизирующий сам по себе довольно много, а также всяческие canvas типа http://businessmodelgeneration.com/)
-- управленцев-операционщиков (BMM, ArchiMate 2.0 и т.д.. CMMN, Essence/SPEM 2.0 и BPMN 2.0 наряду со SBVR попадают сюда же). Все эти case management, critical chain -- отсюда. Организационный аспект (кто что кому может поручить, кто чем распоряжается -- DEMO) это тоже главным образом сюда, это "коммуникативная парадигма" процессов, хотя у Koskela на этот счёт это "инженерный" аспект дела (пункт 2.1. в http://ailev.livejournal.com/603806.html -- кто что кому обещает определяется содержанием работы прежде всего).
-- содержательных людей (инженеров), которых прежде всего интересуют стандарты описания продукции и управления конфигурацией, а также выбор адекватной для объектов работы технологии. Удивительно, но про "артефакты" aka "объекты работы" (work products) в стратегических или операционных стандартах практически ничего сказать нельзя, ибо детализация объектов работ в тех описаниях не предусмотрена. Тут интересны новинки типа языков описания variability, а также тренда использования онтологий (типа ISO 15926 и ISO 15629) как средств отражения разнообразия. Действительно, видов объектов в разы и разы больше, чем задействующих их видов процессов, и само это разнообразие тут является проблемой. Ну, и инженеров волнуют неожиданные (ибо природа упруго сопротивляется) изменения, отсюда issue tracking и adaptive case management в связи с управлением конфигурацией.
Нужно чётко понимать, что эти взгляды на деятельность какого-то предпринятия (ценностный, потоковый и технологический) абсолютно разные, но это не отменяет задачу создать компактный язык (мета-модель, онтологию), позволяющий отражать договорки бизнесменов (кому выгодно и кто заплатит), менеджеров (как делать эффективно и кто будет делать) и инженеров (как и из чего получить годный результат). Я не первый раз об этом пишу (вот, например, в 2008г. я писал про "коскеловщину", ср. с пунктом 2 в http://ailev.livejournal.com/603806.html -- ведь ровно то же самое, хотя чуток другими словами. Собственно, это очередной пост в рамках сказанного в том давнем посте "А теперь нужно самому крепко подумать, и выдать обобщающий для всего этого месива фреймворк". Это, конечно, предмет проекта ПраксОС, praxos).
А есть ещё взгляд айтишников, которым этот компактный язык нужно поддержать в своих информационных системах, и им нужен какой-то формализм для этого языка, ибо компьютеры пока художественные образы типа "работа слаженной команды" и "визионерство наших руководителей" не поддерживают.
Созданием такого языка и занимаемся, прикидки (на русском и английском) будут чуть попозже.