Страница:
www.geao.org Всемирной организации корпоративной архитектуры» (GEAO – Global Enterprise Architecture Organization): «Архитектура предприятия описывает те способы, с помощью которых общее видение деятельности организации отражено в структуре и динамике предприятия. На различных уровнях абстракции она дает единый набор моделей, принципов, руководств и политик, которые используются для создания, развития и обеспечения соответствия систем в масштабе и контексте деятельности всего предприятия в целом».
На практике архитектура предприятия принимает форму достаточно обширного набора моделей, которые описывают структуру и функции организации. Важной областью использования этих моделей являются систематизация процесса планирования организационных и технологических изменений и обеспечение лучших условий для процесса принятия решений.
Отдельные модели архитектуры предприятия логически организованы так, чтобы в совокупности обеспечивать все более возрастающий уровень детализации информации об организации – ее целях и задачах, реализуемых корпоративных программах и организационной структуре, системах и данных, используемых технологиях и всех остальных представляющих интерес областях.
Концепция позиционирования архитектуры предприятия с различных ракурсов (предметных областей) и уровней абстракции позволяет бизнесу четко видеть влияние предлагаемых изменений на различных уровнях (управленческом, исполнительном и т. д.) и различных компонентах (технологических, информационных, организационных и т. д.).
Такая ситуация заставляет по-другому оценивать роли и место моделирования бизнес-процессов в деятельности организации в целом и развития ИТ в частности. В первую очередь следует отметить, что целевой задачей моделирования становится не описание отдельных бизнес-процессов под разрозненные задачи, а построение бизнес-архитектуры, являющейся составной компонентой архитектуры организации.
Данная компонента призвана не только представлять в систематизированном виде бизнес-цели и бизнес-функции организации, но и обеспечить взаимоувязку организационных и технологических ресурсов в единые процессы, обеспечивающие получение целевых результатов. По этой причине моделирование бизнес-процессов можно рассматривать в широком и узком смыслах. А именно с точки зрения отражения логики действий по получению целевого результата («узкое понимание») и с точки зрения некоторого интеграционного решения, определяющего взаимосвязь и взаимодействие организационных, технологических, информационных и других ресурсов в рамках осуществления целевой деятельности организации.
Учитывая данные обстоятельства, описание архитектуры бизнес-процессов охватывает не только компоненты, необходимые для отображения бизнес-логики, но и компоненты «окружения», с которыми обеспечивается взаимодействие в рамках процесса получения целевых результатов деятельности организации.
Как указано в работе [4], «задача разработки бизнес-архитектуры состоит в моделировании «картины в целом» и последующем углублении в тщательно отобранные ключевые процессы и информационные потоки, в том числе с использованием таких инструментов, как декомпозиция функций/процессов, анализ бизнес-событий, модели местоположений и модели интеграции».
В рамках бизнес-процессов описание компонент окружения осуществляется ровно на таком уровне детализации, который позволяет обеспечить:
а) оценку влияния компонента на процесс;
б) взаимосвязь с другими компонентами и интеграцию в целевой бизнес-процесс.
Детализация же имеющих самостоятельное значение компонент «окружения» бизнес-процессов происходит в рамках соответствующих элементов архитектуры предприятия.
Таким образом, бизнес-архитектура предприятия обеспечивает лучшее понимание всей модели предприятия, поскольку именно она несет значительную часть нагрузки по отражению связи между различными моделями (или артефактами), описывающими различные предметные области архитектуры предприятия.
Можно согласиться с выводами авторов [4], что отсутствие понимания и взаимосвязей между различными артефактами архитектуры и неспособность явного описания таких взаимосвязей в рамках бизнес-архитектуры являются одной из основных причин неудач проектов разработки архитектуры предприятия в целом или практического использования результатов подобных работ.
Контекст и основные элементы бизнес-архитектуры
Существует достаточный разброс мнений в понимании и определении бизнес-архитектуры и бизнес-модели. Одна из трактовок предусматривает определение бизнес-архитектуры как области, которая определяется высшими руководителями, отвечающими за основные функции (бизнес) организации [10]. Такая трактовка, как правило, включает в себя утверждения по поводу миссии и целей организации, критические факторы успеха, бизнес-стратегии, описания функций, а также структуры и процессы, необходимые для реализации функций.
Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры ИТ-приложений, которые обеспечивают автоматизированную поддержку этих процессов. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer Арр [11]: «Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты и где начинаются технологии».
Состав и содержание компонент, входящих в модель бизнес-архитектуры, должны определять возможность ответов на вопросы: что, как, где, кто, когда. В рамках типовых методологий моделирования осуществляется следующее «распределение» между элементами бизнес-архитектуры и задаваемыми вопросами:
♦ используемые данные (что?);
♦ процессы и функции (как?);
♦ места выполнения этих процессов (где?);
♦ организации, персоналии-участники, системы (кто?);
♦ управляющие события (когда?);
♦ цели и ограничения, определяющие работу системы (зачем?).
В рамках модели бизнес-архитектуры выделяются следующие основные компоненты:
1) бизнес-процессы / цели и стратегия построения бизнеса;
2) организационная компонента / организационное окружение;
3) информация / информационное окружение;
4) приложения / обеспечивающее окружение.
В данном случае авторы не претендуют на полноту и «стандартизацию» предлагаемого варианта описания бизнес-архитектуры. Более важным является отображение «интеграционных» аспектов.
Проблемы и подходы, связанные с проектированием «окружения» бизнес-процессов, отображены в главе 3 книги.
Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик, что, в свою очередь, является основой для построения архитектуры приложений, которые обеспечивают эти процессы.
Можно привести следующие определения по целевым постановкам задач для бизнес-архитектуры: «Если архитектура ИТ-предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно так же бизнес-архитектура описывает, как элементы бизнеса соединены вместе» [12].
Бизнес-архитектура включает в себя, как правило, следующие аспекты:
♦ бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации;
♦ архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т. п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры, например объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т. д. Эта часть является как бы «точкой соприкосновения» между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений;
♦ показатели результативности. Этот аспект состоит в определении ключевых показателей результативности (КПР) работы организации, их текущих и желаемых уровней. Модель КПР используется как средство мониторинга исполнения бизнес-процессов. Для определения показателей результативности работы организации применяются различные методики, например широкую популярность завоевала методика Роберта Каплана и Дейвида Нортона «Balanced Score Card (BSC)». BSC представляет собой систему, основанную на причинно-следственных связях между стратегическими целями, отражающими их параметрами и факторами получения планируемых результатов. Она рассматривает четыре проекции: финансовую, взаимоотношения с потребителями, операционной эффективности и человеческого потенциала организации, цели и задачи которых взаимосвязаны и отражены финансовыми и нефинансовыми показателями.
Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры ИТ-приложений, которые обеспечивают автоматизированную поддержку этих процессов. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer Арр [11]: «Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты и где начинаются технологии».
Состав и содержание компонент, входящих в модель бизнес-архитектуры, должны определять возможность ответов на вопросы: что, как, где, кто, когда. В рамках типовых методологий моделирования осуществляется следующее «распределение» между элементами бизнес-архитектуры и задаваемыми вопросами:
♦ используемые данные (что?);
♦ процессы и функции (как?);
♦ места выполнения этих процессов (где?);
♦ организации, персоналии-участники, системы (кто?);
♦ управляющие события (когда?);
♦ цели и ограничения, определяющие работу системы (зачем?).
В рамках модели бизнес-архитектуры выделяются следующие основные компоненты:
1) бизнес-процессы / цели и стратегия построения бизнеса;
2) организационная компонента / организационное окружение;
3) информация / информационное окружение;
4) приложения / обеспечивающее окружение.
В данном случае авторы не претендуют на полноту и «стандартизацию» предлагаемого варианта описания бизнес-архитектуры. Более важным является отображение «интеграционных» аспектов.
Проблемы и подходы, связанные с проектированием «окружения» бизнес-процессов, отображены в главе 3 книги.
Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик, что, в свою очередь, является основой для построения архитектуры приложений, которые обеспечивают эти процессы.
Можно привести следующие определения по целевым постановкам задач для бизнес-архитектуры: «Если архитектура ИТ-предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно так же бизнес-архитектура описывает, как элементы бизнеса соединены вместе» [12].
Бизнес-архитектура включает в себя, как правило, следующие аспекты:
♦ бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации;
♦ архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т. п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры, например объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т. д. Эта часть является как бы «точкой соприкосновения» между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений;
♦ показатели результативности. Этот аспект состоит в определении ключевых показателей результативности (КПР) работы организации, их текущих и желаемых уровней. Модель КПР используется как средство мониторинга исполнения бизнес-процессов. Для определения показателей результативности работы организации применяются различные методики, например широкую популярность завоевала методика Роберта Каплана и Дейвида Нортона «Balanced Score Card (BSC)». BSC представляет собой систему, основанную на причинно-следственных связях между стратегическими целями, отражающими их параметрами и факторами получения планируемых результатов. Она рассматривает четыре проекции: финансовую, взаимоотношения с потребителями, операционной эффективности и человеческого потенциала организации, цели и задачи которых взаимосвязаны и отражены финансовыми и нефинансовыми показателями.
Структура организационной компоненты
Организационная компонента в модели бизнес-архитектуры отвечает на вопрос «кто за что отвечает» в бизнес-процессах. Распределение ответственности за результаты бизнес-процессов определяется в виде задания ролей, определяющих те или иные полномочия, «инкапсулирования» данных ролей в конкретные бизнес-процессы и закрепления ролей между конкретными персоналиями. Соответственно, организационная компонента должна поддерживать описание существующей в организации организационно-штатной структуры, а также отражать закрепленное в должностных инструкциях распределение функциональных обязанностей участников бизнес-процессов.
Целью разработки модели организационной компоненты является обеспечение возможности получения качественных и количественных оценок эффективности использования кадровых ресурсов в реализации бизнес-процессов и как следствие поиск вариантов оптимизации организационной структуры предприятия.
Целью разработки модели организационной компоненты является обеспечение возможности получения качественных и количественных оценок эффективности использования кадровых ресурсов в реализации бизнес-процессов и как следствие поиск вариантов оптимизации организационной структуры предприятия.
Структура информационной компоненты
В рамках модели бизнес-архитектуры содержание и детальность отображения информационной компоненты определяются степенью ее влияния на поддержку бизнеса. Информационная компонента должна быть «коррелирующим» отражением бизнес-архитектуры.
Если бизнес-архитектура в целом отвечает на вопрос: «С учетом нашего общего видения, целей и стратегий, кто и что будет делать?» – информационная компонента должна отвечать на вопрос: «Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?».
Соответственно, в рамках модели бизнес-архитектуры информационная компонента включает в себя все те информационные объекты (потоки, документы, данные), которые непосредственно связаны с бизнес-событиями. Реализуемые описательные модели информационной компоненты являются более абстрактными, чем в случае решения проектных задач по разработке приложений. В первую очередь эти модели используют язык бизнеса и обеспечивают контекст, который требуется для моделирования данных.
Целью разработки моделей информации и моделей данных является создание графических представлений потребностей организации и отдельных бизнес-процессов в информации. Это становится основой для реорганизации бизнес-процессов и конструирования новых прикладных систем, описания взаимодействий и информационного обмена, который происходит между организацией и клиентами, партнерами.
Информационная компонента представляется в таком виде, чтобы была обеспечена возможность рассмотрения моделей информации на различных уровнях абстракции, исходя из потребностей бизнес-процессов (в первую очередь потребностей ролевых участников).
Если бизнес-архитектура в целом отвечает на вопрос: «С учетом нашего общего видения, целей и стратегий, кто и что будет делать?» – информационная компонента должна отвечать на вопрос: «Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?».
Соответственно, в рамках модели бизнес-архитектуры информационная компонента включает в себя все те информационные объекты (потоки, документы, данные), которые непосредственно связаны с бизнес-событиями. Реализуемые описательные модели информационной компоненты являются более абстрактными, чем в случае решения проектных задач по разработке приложений. В первую очередь эти модели используют язык бизнеса и обеспечивают контекст, который требуется для моделирования данных.
Целью разработки моделей информации и моделей данных является создание графических представлений потребностей организации и отдельных бизнес-процессов в информации. Это становится основой для реорганизации бизнес-процессов и конструирования новых прикладных систем, описания взаимодействий и информационного обмена, который происходит между организацией и клиентами, партнерами.
Информационная компонента представляется в таком виде, чтобы была обеспечена возможность рассмотрения моделей информации на различных уровнях абстракции, исходя из потребностей бизнес-процессов (в первую очередь потребностей ролевых участников).
Организация компоненты «Приложения»
По аналогии с информационной компонентой компонента «Приложения» ориентирована на отображение того, какие прикладные системы нужны предприятию для выполнения бизнес-процессов. Также можно перефразировать вопросы в отношении связи прикладных систем и бизнес-процессов: «С учетом нашего общего видения, целей и стратегий, кто и что будет делать?» – компонента приложений должна отвечать на вопрос: «Для эффективного выполнения процессов необходимо использование следующего перечня информационных систем».
Детальность описания прикладных систем должна обеспечиваться на уровне, достаточном для понимания состава автоматизируемых функций, хранимых (обрабатываемых) операционных данных (документов), что в конечном итоге дает объективное представление об уровне ее значимости для организации в целом.
Описание компоненты «Приложения» должно быть не только достаточным для понимания, в какой части бизнес-процессов обеспечивается поддержка, но и с точки зрения оценки затрат и выгод по использованию систем.
Детальность описания прикладных систем должна обеспечиваться на уровне, достаточном для понимания состава автоматизируемых функций, хранимых (обрабатываемых) операционных данных (документов), что в конечном итоге дает объективное представление об уровне ее значимости для организации в целом.
Описание компоненты «Приложения» должно быть не только достаточным для понимания, в какой части бизнес-процессов обеспечивается поддержка, но и с точки зрения оценки затрат и выгод по использованию систем.
Базовые принципы, методы и определения моделирования бизнес-процессов
Одной из составных (зачастую «невидимых» для пользователей) частей модели бизнес-архитектуры является используемая методологическая база. Зачастую данная составляющая оказывается интересной только для разработчиков. Вместе с тем знание базовых принципов и определений, касающихся вопросов моделирования, имеет важное значение для заказчиков и пользователей системы «модель бизнес-архитектуры». Это знание определяет общее представление о возможностях и ограничениях системы, позволяет не только выступать в пассивной роли пользователей, но и формулировать постановки задач по дальнейшему развитию системы.
Крайне сложно ожидать объективной оценки и полноты использования возможностей модели бизнес-архитектуры от пользователей, не имеющих хотя бы общих представлений о системном анализе, процессном подходе, базовых принципах моделирования и т. д. По этой причине авторы посчитали важным дать общее представление о предметной области – моделировании бизнес-процессов.
Крайне сложно ожидать объективной оценки и полноты использования возможностей модели бизнес-архитектуры от пользователей, не имеющих хотя бы общих представлений о системном анализе, процессном подходе, базовых принципах моделирования и т. д. По этой причине авторы посчитали важным дать общее представление о предметной области – моделировании бизнес-процессов.
Определение моделирования
Объектом моделирования может выступать любая сущность, описанные в книге подходы универсальны и могут быть применимы как к архитектуре корпоративной информационной системы или компании в целом, так и при проектировании отдельных информационных систем.
Определение по ISO-15704 Моделирование – абстрактное представление реальности в какой-либо форме (например, в математической, физической, символической, графической или дескриптивной), предназначенное для представления определенных аспектов этой реальности и позволяющее отвечать на рассматриваемые вопросы.
Определение по ISO-15704 Моделирование – абстрактное представление реальности в какой-либо форме (например, в математической, физической, символической, графической или дескриптивной), предназначенное для представления определенных аспектов этой реальности и позволяющее отвечать на рассматриваемые вопросы.
Типология моделей
В общем, модели можно классифицировать по различным критериям, например:
♦ формальные (использующие общепринятые правила, нотации и средства) и неформальные;
♦ количественные – позволяющие производить численные оценки и проверки, и качественные – предназначенные для понимания поведения и структуры системы;
♦ описательные – предназначенные только для восприятия человеком, или исполняемые – позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходном объекте.
Примерами качественных и описательных моделей являются:
♦ текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;
♦ визуальные модели, представляемые в виде диаграмм с определенной нотацией. Вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы.
Примерами количественных моделей могут служить: математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа «что – если». В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными.
Динамические исполняемые модели строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модели последнего типа относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией. Хотя разработка такой модели и проведение исследований требуют определенных затрат времени и ресурсов, во многих случаях применение подобных моделей оказывается экономически обоснованным, а в отдельных областях, связанных с военными, космическими, ядерными и другими подобными объектами, – единственно возможным.
♦ формальные (использующие общепринятые правила, нотации и средства) и неформальные;
♦ количественные – позволяющие производить численные оценки и проверки, и качественные – предназначенные для понимания поведения и структуры системы;
♦ описательные – предназначенные только для восприятия человеком, или исполняемые – позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходном объекте.
Примерами качественных и описательных моделей являются:
♦ текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;
♦ визуальные модели, представляемые в виде диаграмм с определенной нотацией. Вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы.
Примерами количественных моделей могут служить: математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа «что – если». В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными.
Динамические исполняемые модели строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модели последнего типа относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией. Хотя разработка такой модели и проведение исследований требуют определенных затрат времени и ресурсов, во многих случаях применение подобных моделей оказывается экономически обоснованным, а в отдельных областях, связанных с военными, космическими, ядерными и другими подобными объектами, – единственно возможным.
Общие принципы моделирования
Перед тем как дать описание основных используемых на сегодняшний день методов моделирования, укажем общие принципы и особенности, которые должны быть учтены при построении модели.
1. Принцип осуществимости. Создаваемая модель прежде всего должна обеспечивать достижение поставленных целей. Таким образом, прежде чем приступить к сбору информации об объекте, нужно четко определить границы области моделирования, цели и количественные показатели их достижения; «моделирование ради моделирования» обычно создает негативное отношение к проекту в компании, снижает лояльность руководства.
2. Принцип информационной достаточности. При полном отсутствии информации об исследуемом объекте построение его модели невозможно. При наличии полной информации моделирование не имеет смысла. Существует некий критический уровень априорных сведений об объекте, при достижении которого имеет смысл переходить от этапа сбора информации к этапу собственно построения модели.
В данном случае закладываются условия для выполнения такого значимого требования, как адекватность модели, а именно достижение разумного баланса между детальностью и потребительскими качествами модели.
3. Принцип множественности модели. Создаваемая модель должна отражать те свойства реального объекта, которые влияют на выбранные показатели эффективности. При использовании любой конкретной модели познаются только некоторые области действительности. Для более полного исследования реального объекта необходим ряд моделей, позволяющих с разных сторон и с разной детализацией отражать рассматриваемый процесс.
4. Принцип агрегирования. В большинстве случаев сложную систему можно представить в виде совокупности агрегатов (подсистем), для адекватного описания которых оказываются пригодными некоторые стандартные схемы. Имея хорошо структурированные, относительно независимые блоки нижнего уровня, появляется возможность довольно гибко перестраивать модель в зависимости от меняющихся по ходу проекта требований, предлагать на выбор лицу, принимающему решение, различные варианты построения модели, лишь перегруппируя подсистемы и изменяя взаимосвязи между ними.
5. Принцип отделения. Исследуемая область, как правило, имеет в своем составе несколько изолированных компонент, внутренняя структура которых достаточно прозрачна или не представляет непосредственного интереса для целей проекта, в таком случае ее место в модели занимает условный пустой блок, для которого определяются только значимые входные и выходные информационные потоки.
Этот прием используется при определении границ области моделирования и при расстановке приоритетов внутри нее, он позволяет сократить объем и продолжительность моделирования, однако может негативно сказаться на адекватности модели.
1. Принцип осуществимости. Создаваемая модель прежде всего должна обеспечивать достижение поставленных целей. Таким образом, прежде чем приступить к сбору информации об объекте, нужно четко определить границы области моделирования, цели и количественные показатели их достижения; «моделирование ради моделирования» обычно создает негативное отношение к проекту в компании, снижает лояльность руководства.
2. Принцип информационной достаточности. При полном отсутствии информации об исследуемом объекте построение его модели невозможно. При наличии полной информации моделирование не имеет смысла. Существует некий критический уровень априорных сведений об объекте, при достижении которого имеет смысл переходить от этапа сбора информации к этапу собственно построения модели.
В данном случае закладываются условия для выполнения такого значимого требования, как адекватность модели, а именно достижение разумного баланса между детальностью и потребительскими качествами модели.
3. Принцип множественности модели. Создаваемая модель должна отражать те свойства реального объекта, которые влияют на выбранные показатели эффективности. При использовании любой конкретной модели познаются только некоторые области действительности. Для более полного исследования реального объекта необходим ряд моделей, позволяющих с разных сторон и с разной детализацией отражать рассматриваемый процесс.
4. Принцип агрегирования. В большинстве случаев сложную систему можно представить в виде совокупности агрегатов (подсистем), для адекватного описания которых оказываются пригодными некоторые стандартные схемы. Имея хорошо структурированные, относительно независимые блоки нижнего уровня, появляется возможность довольно гибко перестраивать модель в зависимости от меняющихся по ходу проекта требований, предлагать на выбор лицу, принимающему решение, различные варианты построения модели, лишь перегруппируя подсистемы и изменяя взаимосвязи между ними.
5. Принцип отделения. Исследуемая область, как правило, имеет в своем составе несколько изолированных компонент, внутренняя структура которых достаточно прозрачна или не представляет непосредственного интереса для целей проекта, в таком случае ее место в модели занимает условный пустой блок, для которого определяются только значимые входные и выходные информационные потоки.
Этот прием используется при определении границ области моделирования и при расстановке приоритетов внутри нее, он позволяет сократить объем и продолжительность моделирования, однако может негативно сказаться на адекватности модели.
Базовые определения по архитектуре
В качестве общих элементов определений, связанных с архитектурой, можно использовать следующий перечень [7]:
♦ архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т. д.);
♦ архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;
♦ уровень детализации архитектуры выбирается таким, что «опускается» вся информация о компонентах, которая не имеет значения вне вопросов взаимодействия с остальными компонентами архитектуры;
♦ поведение компонент является частью архитектуры настолько, насколько это важно с точки зрения взаимодействия с другими компонентами;
♦ каждая система имеет архитектуру, даже система, которая состоит из одной компоненты;
♦ архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;
♦ определения архитектуры не содержат описания самих компонент.
Приведенные в вышеуказанном источнике примеры общих принципов, связанных с архитектурой в целом, также могут быть взяты за основу при осуществлении проектирования и использовании модели бизнес-архитектуры:
♦ все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом;
♦ архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т. д.);
♦ архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;
♦ уровень детализации архитектуры выбирается таким, что «опускается» вся информация о компонентах, которая не имеет значения вне вопросов взаимодействия с остальными компонентами архитектуры;
♦ поведение компонент является частью архитектуры настолько, насколько это важно с точки зрения взаимодействия с другими компонентами;
♦ каждая система имеет архитектуру, даже система, которая состоит из одной компоненты;
♦ архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;
♦ определения архитектуры не содержат описания самих компонент.
Приведенные в вышеуказанном источнике примеры общих принципов, связанных с архитектурой в целом, также могут быть взяты за основу при осуществлении проектирования и использовании модели бизнес-архитектуры:
♦ все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом;