1.1-3

120
-1- Архитектурный подход к развитию предприятий и их информационных систем Часть 1 разделы 1 - 3 Зиндер Евгений Захарович, президент Фонда ФОСТАС, директор АБ «Группа 24» Фонд ФОСТАС «Фонд поддержки системного проектирования, стандартизации и управления проектами» www.fostas.ru, [email protected] +7(495) 601-2049 2012 г. АИБС

Transcript of 1.1-3

Page 1: 1.1-3

-1-

Архитектурный подход к развитию предприятий и их информационных

систем

Часть 1 разделы 1 - 3

Зиндер Евгений Захарович, президент Фонда ФОСТАС, директор АБ «Группа 24»

Фонд ФОСТАС «Фонд поддержки системного проектирования, стандартизации и управления проектами» www.fostas.ru, [email protected] +7(495) 601-2049

2012 г. – АИБС

Page 2: 1.1-3

-2-

Сначала рисуется «общая картина» - задается архитектоника

Как правильно развивать ИТ на предприятиях?

Как правильно развивать само предприятие?!

.

Как правильно

рисовать филина?

.

Page 3: 1.1-3

-3-

Последние исследования:

На основании исследований 2005-2011 г.г. показано (Forrester research, Gartner и др.), что

- ИТ на предприятиях продолжают создаваться, но степень их соответствия реальным потребностям растет очень медленно

- ИТ-менеджеры и специалисты признают, что нужны существенно большие усилия с их стороны для погружения в проблемы бизнеса (основной деятельности) предприятия

- служащая обеспечению такого соответствия дисциплина «Enterprise Architecture» в 80% случаев или более применяется неверно, с недостаточным включением людей бизнеса в АП и недостаточным включением ИТ-людей в бизнес

Page 4: 1.1-3

-4-

В то же время показано, что АП стала активно применяться уже и для развития всего предприятия на уровне и силами общего руководства (вплоть до Совета Директоров).

В этих условиях происходит дальнейшее развитие методов АП и практики их применения.

Page 5: 1.1-3

-5-

СодержаниеЧасть 1. Основы архитектурного подхода и

архитектуры предприятия

Введение1. Что такое «предприятие» и его архитектура (АП)2. Что такое «Схема Дж. Захмана» с точки зрения

дисциплины АП3. Как применять Схему Захмана4. Метод планирования АП С. Спивака (EAP)5. Управление изменениями (Change management) как

вид деятельности, реализующий изменения архитектуры предприятия.

6. Другие варианты. 3-я версия схемы Захмана - онтология.

Конкурс архитектурных мастерскихЗаключение Части 1. ===============================

Page 6: 1.1-3

-6-

Часть 2. Изменения в применении АП и стандарты формирования АП

7. Изменения в применении АП. От обследования предприятия к построению стратегии предприятия на основе модели эффективности

8. Метамодель и модели эффективности / результативности в составе трансформирующейся архитектуры предприятия

Модель результативности - практическая работа.

9. Оценка изменений в применении АП после 2000 года и в 2005 – 2009 годах.

10. Систематизация и стандартизация концептуальных идей АП

11. Основные положения ГОСТ Р ИСО 15704 и GERAM

==========================

Page 7: 1.1-3

-7-

Часть 3. Современные принципы и задачи АП.

12. Современные принципы и задачи АП. АП – инструмент Совета директоров, а затем - CIO13. «3D-предприятие» и «nD-предприятие» как развитие подхода Захмана, «Архитектура как вектор»14. Обобщенные схемы АП для очень больших систем (для «Электронных правительств» и многоотраслевых холдингов). 15. Комплексный архитектурный процесс. 16. TOGAF v. 8.1 и v.9. Другие возможные референсные модели17. Особенности применения архитектурного процесса. Практические рекомендации для предприятия. Сервисно-ориентированные предприятие и архитектуры (SOE и SOA). Облачные вычисления.Заключение. Достижения и перспективы применения и развития АП как профессиональной дисциплиныЗачет

Page 8: 1.1-3

-8-

ВведениеЧто, когда, зачем, кто, как, где, … ?

• Что такое «Архитектура Предприятия», Что в нее входит

• Когда появились базовые достижения АП (и под давлением каких факторов)

• Зачем ей занимаются (в ИТ, в бизнес-менеджменте)

• Кто ее придумал, Кто ей занимается• Как приступать к работе с АП, Как строить

целевую АП• Где сильнее развивается методика АП

Page 9: 1.1-3

-9-

Введение. Необходимость комплексного подхода в применении к сложным системам

1960-е: человеко-машинная система. (Вклад в «общее дело» разработок сложных военных систем)

Состоит из людей и машин, взаимодействующих друг с другом и с внешней средой (и с информацией !!),

имеет цели и поведение, (всегда ли «…организованная для определенной цели…» - это так определенно и постоянно ?!)

может их менять,• изменяя при этом внешнюю среду, • другие системы и/или • саму себя, (когда в результате возникает другая система ?!)обладает социальным устройством своей внутренней среды,может иметь весьма приблизительную границу между внутренней и

внешней средой,

Выделено много типов предприятий, один из них – ИС, понимаемая в то время как, например, АТС.

Очевиден действительно комплексный подход к объекту, что очень много дало для появления и дальнейшего развития АП.

Все же это – еще не в полной мере предприятие, как будет видно из дальнейшего.

Page 10: 1.1-3

-10-

ВОПРОСЫ:Что известно

про «архитектуру предприятия»?

Что известно про стандартISO 15704?

Page 11: 1.1-3

-11-

Приметные области ландшафта

• Дж. Захман “Enterprise Architecture Framework” (… 1987 – 1992/3 – 2001 – 2004 – 2011 – …)

• С. Спивак “Enterprise Architecture Planning” (1992/3)

• GERAM, «3D-Предприятие», ISO 15704 (1997 – 1999 – 2000 – 2010 – 2011 – …)

• FEAF, FEA, архитектурные схемы и архитектуры ведомств и регионов (1999 – 2001 – …)

• TOGAF v.8 (2004) TOGAF v.9 (2009)

• Мультимодельные системы поддержки архитектурного моделирования (CaseWise, ARIS Toolset, … 1990s – 2010…)

• SOE и SOA (… 2000 – 2010 …)

• Расширение практики применения АП на стратегическое планирование бизнеса и стратегическое планирование ИТ, лучше согласованное с потребностями бизнеса (2005 – 2011 – …)

• Cloud computing и техническая архитектура инфраструктуры …

• Направления дальнейшего развития (например, расширение дисциплины Enterprise Architecture до бизнес-дисциплины – Open Group)

Page 12: 1.1-3

-12-

Содержание 1-й частиЧасть 1. Основы архитектурного подхода и архитектуры предприятияВведение1. Что такое «предприятие» и его архитектура (АП)• 1.1 Что такое предприятие? 1.2 Что такое система? 1.3 Что такое архитектура

предприятия? • 1.4 Основные «теоретические» подходы и «практические» дисциплины, интегрируемые в

АП • 1.5 Цели первой части этого курса2. Что такое «Схема Дж. Захмана» с точки зрения дисциплины АП• 2.1 Почему Схема Захмана появилась именно в 1987-1992 годах- работы IBM (Дьюи Уокер, Джеймс Мартин, BSP, …)• 2.2 Что такое Схема Захмана в 92 году 2.3 Принципы и правила Схемы Захмана 1992

года3. Как применять Схему Захмана• 3.1 Наследование идеи трансформации предприятия 3.2 Начальный сценарий Захмана • 3.3 Согласование архитектурных слоев 3.4 Последующие методы и советы==========================4. Метод планирования АП С. Спивака (EAP)• 4.1 Назначение метода EAP и его связь со схемой Захмана• 4.2 Структура действий метода EAP Спивака 4.3 Согласование архитектурных слоев по Спиваку• 4.4 Особенности, достоинства и ограничения метода EAP5. Управление изменениями (Change management) как специальный вид деятельности, практически

реализующий изменения архитектуры предприятия. • 5.1. – 5.4. Архитектурные аспекты и особенности нескольких систематических методов управления

изменениями. 6. Другие варианты и примеры применения • Пример практической работы по адаптации Схемы Захмана (2002 – 2003 годы)• Переход к условному примеру реального предприятия • Конкурс архитектурных мастерскихЗаключение Части 1. Задания на самостоятельную работу

Page 13: 1.1-3

-13-

1. Что такое «предприятие» и его архитектура (АП)

• 1.1 Что такое предприятие? • 1.2 Что такое система (и предприятие

как система)?• 1.3 Что такое архитектура

предприятия?• 1.4 Основные «теоретические» подходы

и «практические» дисциплины, интегрируемые в АП

• 1.5 Цели первой части этого курса

Page 14: 1.1-3

-14-

1.1 Что такое предприятие?

Page 15: 1.1-3

-15-

Примеры предприятий

ВОПРОС: Назовите примеры разных предприятий

и приведите их главные характеристики

(то есть, почему они «предприятия»?)

Page 16: 1.1-3

-16-

Что из перечисленного – предприятие?

• Завод бытового электрооборудования

• Салон-парикмахерская

• Коммерческий учебный ИТ-центр

• Высшее военное летное училище

• Генеральный штаб

• Кондитерский отдел универсама

• Министерство торговли

• ОАО «Газпром»

• Репетитор-фрилансер

• Районная поликлиника

• Центральная избирательная комиссия

• РАО РЖД

• Компания NOKIA

• Электронный Татарстан

• Музей изобразительных искусств им. Пушкина

• ФГУП «Почта России»

Page 17: 1.1-3

-17-

Характеристические свойства предприятия:

• Продукт (изделие, услуга)• Миссия• Клиенты (постоянные, потенциальные)• Люди (сотрудники, руководство, владельцы)• Культура (профессиональная, социальная, общая)• ?? Маркетинговые стратегии и планы• ? Основные технологии (знания, умения, машины, )• ? Размещение (контакты, доступ, территориальная

структура ) • ? Партнеры (поставщики, дистрибуторы)• ? Режимы работы и поведение • ??! Способности и практика развития / изменений • ?? История возникновения и развития• ?? Устойчивость (капитал – финансовый,

материальный, интеллектуальный, партнерские связи, и др.)

Идентифицирующие св-ва

Page 18: 1.1-3

-18-

Предприятие -

«одна или несколько организаций либо их частей, объединенные общей миссией и целями по предоставлению некоторого выхода, например услуги или продукта». (на основе стандартов ISO 15704:2000, ISO/IEC 15288:2002, PMBOK Guide и ряда других.)

Заметим, что НИКАКИХ специальных требований к миссии, целям и формам деятельности предприятия не предъявляется.

(Выделить самостоятельно периоды и границы разных предприятий в истории NOKIA.)

Page 19: 1.1-3

-19-

1.2 Система. Предприятие как система

Система – совокупность взаимодействующих элементов, упорядоченная для достижения одной или нескольких поставленных целей

(ISO/IEC 15288:2002 ) ( (а) не говорится о том, что система меняет свои цели и

переупорядочивает себя; (б) классическое определение – см. далее - не говорит о «поставленных» целях, но настаивает на наличии определенной целостности, единства…)

Другие стандарты дополнительно указывают, что в составе систем рассматриваются машины, люди, программное обеспечение.

Закрепим: понятие «система» в общем случае охватывает, например,

- все предприятие в целом, - его ИС, - отдельные станки и механизмы, - выпускаемые на предприятии изделия.

Т.о., ко всем этим видам систем применимы общие правила системного подхода, но самые общие!

Page 20: 1.1-3

-20-

Классы систем

Произвольная система

Система, созданная человеком

Предприятие

Отрасль

Изделие

Авто-мати- зиро-ванная система

Область обсуждения

Page 21: 1.1-3

-21-

Представления систем и их моделей

• Черный ящик (выходы, входы, поведенческие реакции)

• Система и ее границы (структурный подход): ее состав и структура (в том числе, с декомпозицией компонентов)

• Система систем (необходимых для общей цели, но – возможно - имеющих свои цели и конкурирующих)

Предприятие как система специфического класса (моделируется и как черный ящик, и как система систем, и как состав основных компонентов с присущей структурой – НО как

человеко-машинная система с меняющимися целями, социумом, культурой, экономикой, особенностями внешней среды и связей с ней, и др.

Page 22: 1.1-3

-22-

Предприятие – специальный и особо рассматриваемый вид систем:

- важнейший субъект экономической, социальной и производственной жизни,

- заказчик и среда работы человека.

Для тех, кто работает в области развития предприятий, в области создания и/или внедрения ИС для предприятий – предприятие еще и объект приложения сил:

- объект автоматизации / информатизации, - объект реинжиниринга или совершенствования

качества деятельности,и др.

Основная дисциплина: «Инжиниринг предприятия» и ее главная специализированная часть: «Архитектура предприятия»

Page 23: 1.1-3

-23-

Предприятие по ГОСТ Р ИСО/МЭК 15288и по Захману, ISO 14258, ISO 15704

По ISO/IEC 15288 предприятие является субъектом процессов стандарта. «Первый» взгляд на предприятие-систему инициируется в процессе управления инвестициями / портфелем:

• «запускать в производство и поддерживать обоснованные и успешные проекты, способствующие достижению целей организации», «находить новые возможности и формы развития бизнеса, новые соглашения, соответствующие стратегическому плану предприятия и планам для каждого из направлений его деятельности»

• «проекты ведутся в соответствии с планами жизненного цикла систем»Формально нет указаний, ограничивающих рассматриваемую в проекте систему, но

описание стадий и работ подталкивает к восприятию предприятия как субъекта, а системы – как объекта, входящего в его состав или внешнего .

Стандарт разработан ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and system engineering.

По Захману и ISO 15704 предприятие является объектом. Для работы с ним нужен объективный взгляд на него. Предназначен для тех, кто … проектирует предприятие (enterprise designers ), моделирует его и его взаимодействующие части/процессы

ISO 14258 и ISO 15704 разработаны ISO/TC 184, Industrial automation systems and integration, Subcommittee SC 5, Architecture, communications, and integration frameworks

Page 24: 1.1-3

-24-

1.3 АрхитектураВ зависимости от контекста архитектура

системы – это: 1) Многоаспектное описание или план

задуманной или развиваемой системы на уровне ее компонентов, детализированное в достаточной мере для руководства ее воплощением, а также принципы и руководящие материалы, определяющие руководство конструированием и развитием системы во времени.

2) Структура существующей системы как совокупность ее компонентов и их взаимосвязей.

(Глоссарий ФОСТАС, версия 2-08. На основе базовых стандартов по системной и программной инженерии, моделированию и архитектуре предприятий ).

Page 25: 1.1-3

-25-

Активно обсуждается отличие архитектуры – как работы и как дисциплины от технического проектирования

(Надо учитывать особенности языка: в английском отличают ‘construct’ от ‘build’.)

«Lessons from the oldest industry of the world -- "construction" -- have always separated architecture from building. IT needs to ensure this lesson is applied intelligently to its industry.»

«Уроки древнейшей в мире индустрии - строительства (как сооружения чего-л.) – состоят в том, чтобы всегда отделять архитектурную деятельность от непосредственного строительства. В ИТ нужно обеспечить, чтобы этот урок толково применялся и в данной индустрии.»

«А top down, architectural-driven approach … yields the kind of consistency that results in a

portfolio of software assets that can be cross-leveraged. This saves money but perhaps more importantly improves time to market and makes it easier for folks to come up with innovative approaches to achieving business goals»

«When application development teams resist an architectural approach, the result is an overly complex and misaligned IT organization that is poorly positioned to serve the needs of the business».

(Tony Bishop, InfoWorld's The Real-Time Enterprise blog’s author )

Дополнительно, разобрать самостоятельно :

Page 26: 1.1-3

-26-

Кто такой архитектор? Строит ли что-то архитектор?

Главные ценности и особенности архитектурного подхода:

1) взгляд в целом, общая картина ("Big picture")

Page 27: 1.1-3

-27-

Вернемся к вопросу: «Как правильно рисовать и выращивать филина?»

Общую картину рисует архитектор.

«Остальное» - а это реализация и эксплуатация - делают разработ-чики, внедренцы,администраторы, …

Но это только самое начало его работы: он прорисовывает и большое число важных, определяющих деталей!

Page 28: 1.1-3

-28-

ВОПРОСЫ:Что внес архитектор?

Что внесли разработчики?

• Что ценного во вкладе каждого?

• Какова связь между их решениями?

Page 29: 1.1-3

-29-

Главные ценности и особенности архитектурного подхода (продолжение):

2) концентрация на долговременных целях – в противовес сооружению «времянок»

3) комплексность подхода (цели, внешняя среда, функции, эстетика, эргономика, законы и др. регулирование, учет как человеческого фактора, так и "машин" в широком смысле, экономика реализации, возможность практической реализации в указанных условиях)

4) обоснование реализуемости с исключением попыток решать технические конструкторские вопросы «раньше времени» и зарываться в детали

5) контроль за тем, чтобы техническое конструирование и модернизация не нарушали архитектурного замысла

6) качество архитектурных решений на основе использования специальных профессиональных методов работы с комплексом разнохарактерных аспектов

7) понятность и убедительность для высшего менеджмента и людей разных специальностей

Page 30: 1.1-3

-30-

Есть еще одна, определяющая суть архитектурной работы ее особенность:

поиск «стиля организации пространства», формирование этой организации.

И для классической архитектуры и для ЭП это выражается в формировании среды обитания человека.

Например, актуальны поиски наиболее полезной и удобной информационной среды, поиски баланса между архитектурой «слабой связанности»

(гибкость в самых разных отношениях) и «сильной интегрированностью», связываемой с эффективностью (по цене и производительности) на коротком горизонте времени.

Page 31: 1.1-3

-31-

Объективность взгляда на предприятие:

При работе с АПнадо уметь

выйти за пределы предприятия для того, чтобы

взглянуть на него со стороны!

Page 32: 1.1-3

-32-

Page 33: 1.1-3

-33-

Как (и кому) смотреть на предприятие

Page 34: 1.1-3

-34-

Есть и еще что-то, связанное со «стилями организации пространства»

…Например, сейчас актуальны поиски баланса между архитектурой

«слабой связанности» (гибкость в самых разных отношениях) и эффективностью (по цене и производительности)

Наконец, на архитекторе – главная ответственность.

Поэтому у архитектора есть ОБЯЗАННОСТЬ и ПОЛНОЕ ПРАВО

говорить

«я построил!»

Page 35: 1.1-3

-35-

1.4 Основные «теоретические» подходы и «практические» дисциплины, интегрируемые в АП

Системный анализ

Поведенческийподход

Исторический подход

Архитектура предприятия- как дисциплина- как описание предприятия с учетом(а) структуры (б) действий (поведения)(в) развитияпредприятия в целом и его частей

Управление качеством или «Качественный менеджмент»

Стратегическое маркетинговое управление

Инжиниринг предприятия и BPR

Управление организационным развитием и изменениями

Моделирование предприятий и систем

Проектирование информационных систем

Page 36: 1.1-3

-36-

Об используемом толковании взаимосвязи трех используемых подходов

«Системный подход – см. http://dic.academic.ru/dic.nsf/bse/132746/ – направление методологии специально-научного познания и

социальной практики, в основе которого лежит исследование объектов как систем»

Система – см. http://dic.academic.ru/dic.nsf/bse/132725/СистемаСвойства системного подхода:- целостность объекта- «…совокупность проблем методологии системного

исследования существенно превосходит рамки задач общей теории систем…»

- «…не существует в виде строгой методологической концепции: он выполняет свои эвристические функции, оставаясь не очень жестко связанной совокупностью познавательных принципов …»

Это не системотехника (то есть не техника системного проектирования инженерных систем)!

В С.п. иногда включают единство структурного и функционального анализа, и более того – логического и исторического подхода.

Но важно, что т.н. поведенческий, а также исторический подходы имеют и самостоятельное качественно важное значение – безусловно не игнорируя взаимодействие с С.п.

Page 37: 1.1-3

-37-

Плюс к указанным практическим бизнес-дисциплинам: - управление инвестициями и «контроллинговый» подход финансового планирования, - социопсихология и психология труда,

- экология и экологический менеджмент,

и т.д. …

Page 38: 1.1-3

-38-

Современный архитектурный подход

- это методология управления развитием любого предприятия (Enterprise),

• включая анализ текущего и архитектурное проектирование его будущих состояний,

• планирование и контроль проектов перехода к этим состояниям,

• а также организацию и контроль перехода к проектам построения систем уровня предприятия (Enterprise Systems), в том числе и, часто, в первую очередь – информационных систем и ИКТ-систем различного назначения

средствами дисциплины «Архитектура предприятия» (Enterprise Architecture)

Архитектурный подход предполагает

• совместное, взаимоувязанное и согласованное рассмотрение целей и стратегических планов организации,

• внешней и внутренней среды ее деятельности, функций,

• информационно-коммуникационной инфраструктуры,

• прикладных ИКТ-систем

• а также многих других аспектов, характеризующих особенности функционирования предприятия как человеко-машинной социально-экономической системы

Page 39: 1.1-3

-39-

Барьеры, для преодоления которых нужна АП

• Сложность предприятий, их продуктов и их ИТ-систем, невозможность без систематического применения специальных методов охватить их в целом, не потеряв связь с некоторыми важными частностями (и обратно: работать с деталями, не теряя связи с целым),

• Комплексность предприятий, проектов и систем (экономика и финансы, много инженерных дисциплин, человеческий фактор, маркетинговые конкурентные аспекты, соответствие законодательству, и др.)

• Разные люди, которые должны обеспечить вместе успех предприятию или проекту, но которые «говорят на разных языках», не видят проблем, потребностей и возможностей друг друга

Page 40: 1.1-3

-40-

СКВОЗНЫЕ ВОПРОСЫ (их содержание раскрывается и

ответы уточняются по мере изложения курса):

• ЧЕМ ПРЕДПРИЯТИЕ ОТЛИЧАЕТСЯ ОТ ДРУГИХ СИСТЕМ?

• ЧЕМ ПРЕДПРИЯТИЕ отличается от ПРОЕКТА?

• ЧЕМ схема Захмана похожа на периодическую таблицу Менделеева?

• ЧЕМ схема Захмана принципиально отличается от таблицы Менделеева?

• В ЧЕМ работа консультанта в комплексном консалтинговом проекте совпадает с работой Архитектора предприятия

• ЧЕМ работа Архитектора предприятия отличается от работы консультанта

Page 41: 1.1-3

-41-

1.5 Цели первой части этого курса

• Показать нацеленность комплексного архитектурного подхода не на ИТ, а на предприятие любой отрасли и любого масштаба (включая и его ИТ как один из аспектов)

• Показать связь дисциплины «Архитектура предприятия» с другими дисциплинами [на примере программы МБИ] и ее интегрирующую роль в отношении других дисциплин (включая системную инженерию применительно к созданию и применению информационных систем)

• Дать концептуальные сведения и начальный опыт в области архитектурного описания предприятий и вариантов трансформации их архитектур (включая архитектуру ИТ)

Page 42: 1.1-3

-42-

Из программы МБИ (MBA/MBI, Kiiv, 2009):«программа MBI разработана как средство

достижения сильного конкурентного преимущества в бизнесе за счет использования информационных технологий.

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

Page 43: 1.1-3

-43-

Из программы МБИ (MBA/MBI, Kiiv, 2009):

«Главными особенностями выпускников Программы является

наличие у них компетенций стратегического, стоимостного, маркетингового и системного мышления,

глубокое понимание требований потребителей организации, а также

нацеленности на предпринимательство и непрерывные стратегические и технологические инновации.

В программе такой специализации значительная роль будет отведена переходу … от традиционных методов управления ресурсами организации к управлению процессами создания, интеграции и использования ее организационного знания.»

Page 44: 1.1-3

-44-(Graphic courtesy of BAE Systems and INCOSE )

Соотношение смежных дисциплин на предприятиях (INCOSE)

Инженерия предприятия

Методология коллективной распределенной разработки (DCD)

Инжиниринг предприятия и его бизнеса как системы

Системная и программная Инженерия

Методология Архитектуры предприятия

Динамическое моделирование и визуализация (MSV)

Средства и среда MSV

Средства и среда DCD

Капитал и инфраструктура

Управление качеством и совершенствование процессов

Page 45: 1.1-3

-45-

Модули программы МБИ и их связи с АП

• Научные основы бизнеса и менеджмента (Организационное поведение, Управление качеством, Ключевые показатели,…)

• Стратегический менеджмент (Разработка стратегических планов, Управление организационными изменениями, Управление бизнес-процессами, Управление проектами, Управление информационной безопасностью …)

• Управление человеческими ресурсами и корпоративное управление (Развитие человеческого капитала, Управление знаниями, Управление непрерывностью бизнеса, …)

• Стратегический маркетинг (Маркетинговое управление и маркетинговые стратегии, анализ среды и маркетинговая диагностика, панели индикаторов, …)

• Организация ИТ-службы (Диагностика системы управления организации и ее готовности к внедрению корпоративных ИС, Разработка стратегии развития ИСУ, Организация ИТ-службы, ИТ-стандарты, ИТ-аудит, …)

• Эффективное управление ИТ (Сервис-ориентированный подход, Интеграция информационных систем, Эффективность ИТ, …)

Page 46: 1.1-3

-46-

Как соотносятся стандарты рассматриваемых дисциплин

CIMOSA Association, Kurt KosankeDeliverable “Standardisation Final Report” D 5.3.2. Date May 16, 2003(mfg - abbreviation for manufacturing)

Page 47: 1.1-3

-47-

ВОПРОСЫ:Что известно про схему Дж. Захмана?

Что в нее входит?

В каких работах / проектах используется и зачем?

Page 48: 1.1-3

-48-

2. Что такое «Схема Дж. Захмана» с точки зрения дисциплины АП

• 2.1 Почему Схема Джона Захмана (John A. Zachman) появилась именно в 1987-1992 годах

- работы IBM (Дьюи Уокер, Джеймс Мартин, BSP, …)

- дальнейшее развитие технологий, увеличение сложности систем и требовательности к ИТ-проектам

• 2.2 Что такое Схема Захмана в 92 году• 2.3 Принципы и правила Схемы Захмана

1992 года

Page 49: 1.1-3

-49-

2.1 Почему Схема Захмана появилась именно в 1987-1992 годах

Page 50: 1.1-3

-50-

Первый виток развития АП в бизнес-контексте

TQM, Переход к рынку покупателя

• Рынок покупателя• Marketing management • “Business & IT alignment"

• Глобализация• Нестабильные условия бизнеса• Интернет, мобильные ИТ • рост аутсорсинга

Первый вариант cхемы Дж. Захмана(3*6)

Процесс EAP С.Спивака

Полная схема Дж. Захмана (6*6)

Рост сложности человеко-машинных систем

Инженерная психологияв военной и гражданской системной инженерии

Большие (например, в банках) и сверхбольшие проекты

70 – 89 годы 89 – 95 годы

55 – 75 годы 80 – 92 годы

IBM BSP

CPI CMM

Опыт и наследие архитектурного метода в традиционном строительстве

Page 51: 1.1-3

-51-

Один из толчков к появлению схемы Захмана и метода Спивака: необходимость поддержки методики IBM BSP

Дьюи Уокер (Dewey Walker), директор по архитектуре подразделений по Планированию и контролю информационных систем ИБМ в конце 1960-х годов – «дедушка» архитектурных методов. Его внутренние работы и достижения, полученные в ИБМ, позднее стали известны под названием Методика "Business Systems Planning“ – BSP, или «Планирование деловых систем».

Значительную часть документации BSP разработал и написал Дж. Захман. Более важно, что BSP, схемы архитектуры Дж. Захмана, метод EAP Стива Спивака и позднейшие методологии архитектурного подхода объединены одним набором мотивов создания и основных целей своего применения:

(Во третьей части курса: современное понимание АП расширило ее применение на прямую поддержку формирования и воплощения бизнес-стратегии, в том числе, вне обязательной связи с ИКТ.)

N

Для самостоятельной работы: выполнить задание №1 к 14 октября.

Page 52: 1.1-3

-52-

Дж. А. Захман, из предисловия к книге С.Спивака, 1992 год:«The architecture process begins with an understanding of the enterprise and

the data that constitute its information infrastructure. To be most useful, information systems must be derived from this base of knowledge about the enterprise. … Even if we could document the business strategy … a fundamental remained: how to get from those [I.S.] strategy to implementation … Over the years, the strategy matrices and the implementation have remained separated by cavernous, conceptual “black hole” »

«Архитектурный процесс начинается с понимания предприятия и данных, определяющих его информационную инфраструктуру. Для того, чтобы быть наиболее полезными, информационные системы должны быть определены как производные от этой основы знаний о предприятии… Даже в том случае, если мы можем задокументировать бизнес-стратегию… остается основной вопрос: как получить из этой стратегии стратегию реализации … Идут годы, но матрицы стратегий (примеч.: не матрицы BSP!) и реализация остаются разделенными пустотами, концептуальными ”черными дырами”»

N

Page 53: 1.1-3

-53-

1) Потребности реальной работы, которую поддерживала методика BSP, вызвала к жизни Схему Дж. Захмана и метод EAP, воплотившие основы архитектуры предприятия.

2) Схема архитектуры предприятия Дж. Захмана - глобальный стандарт де-факто и лидирующий подход в первом десятилетии XXI века.)

3) Принципы и многие способы, использованные в BSP, на концептуальном уровне вполне работоспособны в консалтинговых проектах и сейчас.

По этой причине BSP используется здесь для показа «живой» концептуальной основы работ по стратегическому планированию ИКТ на предприятии и по проектированию ИКТ предприятия «на верхнем уровне», такой основы, которая не искажена спецификой применения того или иного современного инструментария (например, стандарта или программного средства моделирования).

ПОЧЕМУ СТОИТ ЭТО ЗНАТЬ? N

Page 54: 1.1-3

-54-

Методика BSP - "Business Systems Planning“, IBM, 70-e – 80-e годы ХХ века

• BSP: "структурный подход, помогающий предприятию определить план создания информационных систем, удовлетворяющих его ближайшие и перспективные информационные потребности" (КОТОРЫЕ ИМЕЕТ БИЗНЕС ! – примеч. Е.З.).

• BSP ориентирована на то, чтобы заинтересовать административных работников высшего уровня

• BSP основывается на точке зрения: «информация является ресурсом и должна планироваться в масштабах всего предприятия независимо от того, что она используется на различных ЭВМ и в ряде различных подразделений предприятия».

• Фиксировалось: информационные потребности часто остаются теми же, в то время как само предприятие реорганизуется. Поэтому архитектура информации должна проектироваться независимо от текущей структуры предприятия.

• Также должно учитываться: информационные потребности не являются статическими, и "план" (архитектуру, структуры, содержание и др.) информационных ресурсов надо будет обновлять непрерывно по мере развития предприятия.

(См. Дж. Мартин "Планирование развития автоматизированных систем". "Финансы и статистика", 1984)

N

Page 55: 1.1-3

-55-

Другие задачи BSP: • обеспечить формальный, объективный метод для

руководства, помогающий определить приоритет разработок информационных систем независимо от каких-либо местнических интересов;

• обеспечить разработку долгосрочных систем, экономя капиталовложения, так как эти системы базируются на процессах предприятия, на которые организационные изменения обычно не влияют;

• обеспечить такое управление ресурсами обработки данных, которое служит наиболее эффективному решению задач предприятия;

• содействовать повышению уверенности руководителей в том, что будут созданы информационные системы с высокой отдачей;

• улучшить взаимоотношения между отделом информационных систем и пользователями за счет обеспечения систем, отвечающих требованиям и приоритетам пользователей;

• определить данные как ресурс организации (корпорации), который следует планировать и контролировать, чтобы им мог эффективно пользоваться каждый.

N

Page 56: 1.1-3

-56-

ПРИМЕРЫ ВАЖНОГО из BSP:

- Обеспечение централизованного подхода- Строительные блоки BSP- Шаги анализа, проводимого методом BSP- Источники, обработка и соотнесение с тем, что есть - Беседы (интервью) и обработка их результатов - Стержень анализа BSP – беседы с руководителями - Обработка интервью- Определение приоритетов в реализации - архитектуры - Взвешенные значения приоритетов: «неожиданность» результата

(Изучить в ходе выполнения задания №1 на самостоятельную работу.)

Page 57: 1.1-3

-57-

2.2 Что такое Схема Захмана в 92 году

См. основополагающую работу:Sowa J. F., Zachman J. A. Extending and Formalizing

the Framework for Information System Architecture // IBM S. J. 1992. V. 31. № 3.

Сначала ISA – Information System (IS) Architecture

И только позже, вслед за Стивеном Спиваком –АРХИТЕКТУРА ПРЕДПРИЯТИЯ (АП)(EA - ENTERPRISE ARCHITECTURE)

Page 58: 1.1-3

-58-

ПОЧЕМУ СТОИТ ЭТО ЗНАТЬ?

Схема Дж. Захмана - глобальный стандарт де-факто

уже с первой половины 90-х годови

лидирующий базовый подход в первом десятилетии XXI века.

(Сейчас говорят о схеме Захмана и как об онтологии – благодаря вкладу его соавтора, Дж. Сова в вариант 1992

года и последующему постепенному развитию.Но важнее другие, общие методические правила схемы

Захмана)

Page 59: 1.1-3

-59-

В профессиональной «мастерской» архитектора и аналитика происходит

не полная замена «старых» методов «новыми»,

а накопление и взаимообогащение методов

Багаж архитектора

Багаж архитектора

Кантовать!Бага

ж

архите

кт

ора

1970-198х

1987-1992

1992-1999

2000-2004

2005-2011

Page 60: 1.1-3

-60-

Дж. Захман: о проблемах ИТ-систем предприятия, ставших причиной создания схемы “ISA” (1992 г.)

• ИТ не соответствуют потребностям бизнеса

• Люди предпочитают заняться узким, понятным им вопросом, упуская целое

• Желание «написать и внедрить» программную систему мешает посмотреть на

– ситуацию предприятия на рынке,

– ситуацию внутри предприятия с его реальными потребностями, культурой, ресурсами

и др.

Page 61: 1.1-3

-61-

(продолжение)

В результате –

• ИТ имеют «дырки» (лакуны) и противоречия в информационном и функциональном обеспечении…

• А люди разных специальностей на предприятии не понимают друг друга!

Хотя в большинстве случаев люди твердо уверены, что уж они-то ничего не упустят!

Page 62: 1.1-3

-62-

Дж. Захман позже: какой должна быть модель предприятия на основе его схемы как метамодели

Она должна быть:

• ПРОСТОЙ ДЛЯ ПОНИМАНИЯ, не технической, доступной всем (техническим и нетехническим) руководителям и специалистам,

• ЗАКОНЧЕННОЙ в отношении предприятия так, что каждая проблема соотносится с предприятием в целом.

• СРЕДСТВОМ ОБЩЕНИЯ, инструментом поддержки обсуждений сложных вопросов с использованием относительно немногих и нетехнических слов.

• ИНСТРУМЕНТОМ ПЛАНИРОВАНИЯ, позволяющим лучше принимать решения за счет того, что решение никогда не будет приниматься "в пустоте".

• СРЕДСТВОМ РЕШЕНИЯ ЗАДАЧ, позволяющим работать с абстрактными сущностями выделяя и изолируя отдельные параметры системы без потери ощущения предприятия как целого.

• НЕЙТРАЛЬНОЙ, независимой от каких либо инструментов, благодаря этому каждый инструмент и методология могут быть отображены на схему для того, чтобы явно показать, что они делают и что не делают.

Page 63: 1.1-3

-63-

e.g. DATA

ENTERPRISE ARCHITECTURE - A FRAMEWORK

Builder

SCOPE(CONTEXTUAL)

MODEL(CONCEPTUAL)

ENTERPRISE

Designer

SYSTEMMODEL(LOGICAL)

TECHNOLOGYMODEL(PHYSICAL)

DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)

Sub-Contractor

FUNCTIONINGENTERPRISE

DATA FUNCTION NETWORK

e.g. Data Definition

Ent = FieldReln = Address

e.g. Physical Data Model

Ent = Segment/Table/etc.Reln = Pointer/Key/etc.

e.g. Logical Data Model

Ent = Data EntityReln = Data Relationship

e.g. Semantic Model

Ent = Business EntityReln = Business Relationship

List of Things Importantto the Business

ENTITY = Class ofBusiness Thing

List of Processes theBusiness Performs

Function = Class ofBusiness Process

e.g. "Application Architecture"

I/O = User ViewsProc .= Application Function

e.g. "System Design"

I/O = Screen/Device FormatsProc.= Computer Function

e.g. "Program"

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Business Process Model

Proc. = Business ProcessI/O = Business Resources

List of Locations in which the Business Operates

Node = Major BusinessLocation

e.g. Logistics Network

Node = Business LocationLink = Business Linkage

e.g. "Distributed System

Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics

e.g. "System Architecture"

Node = Hardware/SystemSoftware

Link = Line Specifications

e.g. "Network Architecture"

Node = AddressesLink = Protocols

e.g. NETWORK

Architecture"

Planner

Owner

Builder

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYCONSTRAINED

MODEL(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Sub-

Contractor

FUNCTIONING

MOTIVATIONTIMEPEOPLE

e.g. Rule Specification

End = Sub-conditionMeans = Step

e.g. Rule Design

End = Condition

Means = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business ObjectiveMeans = Business Strategy

List of Business Goals/Strat

Ends/Means=Major Bus. Goal/Critical Success Factor

List of Events Significant

Time = Major Business Event

e.g. Processing Structure

Cycle = Processing CycleTime = System Event

e.g. Control Structure

Cycle = Component Cycle

Time = Execute

e.g. Timing Definition

Cycle = Machine CycleTime = Interrupt

e.g. SCHEDULE

e.g. Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizations

People = Major Organizations

e.g. Work Flow Model

People = Organization UnitWork = Work Product

e.g. Human Interface

People = RoleWork = Deliverable

e.g. Presentation Architecture

People = UserWork = Screen Format

e.g. Security Architecture

People = IdentityWork = J ob

e.g. ORGANIZATION

Planner

Owner

to the BusinessImportant to the Business

What How Where Who When Why

Copyright - John A. Zachman, Zachman International

SCOPE(CONTEXTUAL)

Architecture

e.g. STRATEGY ENTERPRISE

e.g. Business Plan

TM

Zachman Institute for Framework Advancement - (810) 231-0531

Page 64: 1.1-3

-64-

Столбцы и строкиШесть столбцов -- аспекты АП как аспекты деятельности предприятия:A) «ЧТО делается» -- объекты/данные; B) «КАК делается» -- функции/процессы; C) «ГДЕ делается», -- размещение или инфраструктура;D) «КТО делает» -- люди, организационные единицы; E) «КОГДА делается» -- графики событий и работ; F) «ЗАЧЕМ делается» -- стимулы, мотивы и стратегии деятельности.

Шесть строк -- шесть «уровней» представления предприятия: 1) «Планировщик» -- предприятие в контексте бизнес-среды, 2) «Владелец» -- концептуальная модель предприятия, 3) «Дизайнер» -- системная (логическая) модель, 4) «Строитель» -- технологическая (физическая) модель, 5) «Субподрядчик» -- детальная реализация, часто - поблочная и выполняемая локально, «вне контекста» 6) «Функционирующее предприятие» -- представление оператора, пользователя.

Page 65: 1.1-3

-65-

Задание №2:

Прослушать рассказ Дж. Захмана 2008 года о бизнес-архитектуре:

http://www.youtube.com/watch?v=b5ncVbj4OPM

Отметить, на что Захман обращает внимание: люди до сих пор слишком часто сводят «бизнес-архитектуру» к модели бизнес-процессов (а это должна быть полная совокупность моделей второй строки его схемы, включая стратегию предприятия).

Аналогично для «системной архитектуры» – нужен полный набор моделей 3-ей строки.

Как и для «технологической архитектуры» недостаточно модели размещения оборудования!

При этом он говорит о том, что пытаться исправить ситуацию изменением названий строк и столбцов в его таблице – неверно. Старые слова все равно будут многозначными, так что важно – достичь понимания сути.

Page 66: 1.1-3

-66-

2.3 Принципы и правила Схемы Захмана 1992 года

Схема Захмана объявлялась им самим и неоднократно характеризовалась как своего рода «Таблица Менделеева» для АП.

Надо знать:• в чем эта характеристика справедлива, а в

чем – нет (хотя бы для адаптации Схемы),• как пользоваться принципами и

правилами Захмана

Page 67: 1.1-3

-67-

Правила Дж. Захмана 1992 года

Basic Model = Entities and Relationships

Entity

Relationship

Entity

Мета-мета-модель:

(на подобной основе строятся метамодели для современных формализованных описаний семантики предметных областей – т.н. онтологических моделей, особенно в их графических представлениях.)

Page 68: 1.1-3

-68-

ЧТО КАК

ЗАЧЕМ ГДЕ

КОГДА КТО

Правило 1. Столбцы равнозначны по статусу и порядку

Page 69: 1.1-3

-69-

Правило 2. Каждый столбец – простая, базовая модель предприятия

Отвечает на один из базовых вопросов: ЧТО, КАК, ГДЕ, КТО, КОГДА и ЗАЧЕМ (отражая сущности, функции и т.д.) Важны и связи между этими базовыми

моделями.Для каждой базовой модели есть метамодель

(см. Табл. 5)

Например, для ячейки А2 модель: «работник связан с организацией, та – с

клиентом, тот – с продуктом», а метамодель – ER («сущность-связь»).

Page 70: 1.1-3

-70-

Таблица 5. Компоненты обобщенных метамоделей для столбцов A, B, и C

Базовые Столбец A Столбец B Столбец Cэлементы Данные (ЧТО) Функция (КАК) Сеть (ГДЕ)мета-метамодели:

Метасущность Сущность Функция Узел (Entity)

Коннектор Связь Аргумент Канал (Relationship)

Page 71: 1.1-3

-71-

Правило 3. Базовая модель для каждого столбца уникальна

• Метасущности и коннекторы (метасвязи) , используемые в одной колонке, не повторяются в других

( кроме связей между колонками?!) • Сущности и связи уникальны для столбца ЧТО

(т.е. «используются только в нем»)• функции и аргументы – для столбца КАК. • Т.о. ни базовые метасущности ни коннекторы не

повторяются – ни по имени ни по смыслу (Но см. далее на схеме связь EFFECT…).

• Сущности не эквивалентны функциям, связь – аргументу. Но они могут быть связаны друг с другом, так как являются отражениями одного и того же реального мира.

Basic Model = Entities and Relationships

EntityRelationshipEntity

Вопрос: может ли аргумент функции

быть эквивалентен

сущности (из столбца ЧТО)?!

Page 72: 1.1-3

-72-

Примеры схем моделей ячеек

?!

Page 73: 1.1-3

-73-

Правило 4. Каждая строка - ограниченное, уникальное представление или «перспектива»

• Владелец: Имеет дело с ограничениями применения, как эстетическими, так и использования, конечного продукта – в его концептуальном представлении.

• Дизайнер: Имеет дело с ограничениями проектирования, определяемыми законами «физики» или природы при логическом представлении конечного продукта.

• Строитель: Имеет дело с ограничениями строительства, определяемыми реальным состоянием методов и технологий при физическом представлении конечного продукта.

Вопрос: это цепочка передачи требований друг другу? или представления, существующие в любой момент времени параллельно?

Page 74: 1.1-3

-74-

Таблица 6. Изменения значений сущностей АП от строки к строке столбца ЧТО

Строка Представление Базовая сущность АП 2 Владелец Сущность бизнеса («вещь» реального мира) 3 Дизайнер Сущность данных (логическое представление)4 Строитель Сущность технологическая (физическое представление)

Page 75: 1.1-3

-75-

Правило 5. Каждая ячейка уникальна

• Бизнес-сущность может быть только в ячейке A2.

• Сущность данных может быть только в ячейке A3.

• Бизнес-процесс может быть только в ячейке B2.

• Функция приложения может быть только в ячейке B3.

Page 76: 1.1-3

-76-

Примеры схем моделей -2

Page 77: 1.1-3

-77-

Примеры схем моделей -3

Page 78: 1.1-3

-78-

ВОПРОСЫ?

Page 79: 1.1-3

-79-

Правило 6. Совокупность или Интеграция

всех ячеек одной строки задает полную модель

одного представления предприятия(одной «перспективы»)

Page 80: 1.1-3

-80-

Примеры моделей - 4

Структура распределения - работ- прав- ответственности- делегирования

Между- Орг-единицами- Людьми- Машинами- Программными агентами

Page 81: 1.1-3

-81-

Примеры моделей - 5

Распространенные типы моделей: - Диаграммы Гантта- Диаграммы «Событие/переход»(временной аспект поведенческих / событийных моделей)

Page 82: 1.1-3

-82-

Примеры моделей - 6

Одна из групп возможных архитектурных принципов: 1) Одна стратегия должна быть нацелена на как можно большее число целей. 2) Конфликтов по целям и стратегиям не должно быть.

Page 83: 1.1-3

-83-

Схема дерева целей «Цель-стратегия-цель»

Цель 1

Стратегия достижения 1.1

Стратегия достижения 1.2

Показатель выполнения 1.1.1

Метод обеспечения 1.1.1.1

Метод обеспечения 1.1.1.2

Индикатор применения 1.1.1.1.1

Цель 2

Стратегия 2.1

Стратегия 2.2

Показатель 2.1.1

Метод 2.1.1.1

Метод 2.1.1.2

Индикатор 2.1.1.1.1

По сути это – одна из форм

Модели эффективности / результативности (не единственная и часто не самая удачная)

Page 84: 1.1-3

-84-

Доставлять заказы на дом даже

при отсутствии товараОперативноподвозить товар от …

Альтернативные и одновременные стратегии

Обеспечить 50% оборота товара / день

Обеспечить 95% удовлетворение покупателей

Сократить / удалитьредко

продающийся товар

Держать на складе товар,

продающийся хотя бы раз в 2 дня

конфликт

Складское помещение площадью Q

Связь минимум с N поставщикамис доставкой партии за 1 час

Запрет заказа товара, партия которого не распродана за 2 дня

Выполнение заказа за 2 часа после заявки

Page 85: 1.1-3

-85-

ВНИМАНИЕ:

а) Не все стратегии сочетаются

(требуется содержательный конструктивный характер работы с АП !...)

б) Комплексная стратегия индивидуальна!

Page 86: 1.1-3

-86-

ВОПРОСЫ?

Page 87: 1.1-3

-87-

3. Как применять Схему Захмана

• 3.1 Наследование идеи трансформации предприятия

• 3.2 Начальный сценарий Захмана• 3.3 Согласование архитектурных слоев• 3.3 Последующие методы и советы

Page 88: 1.1-3

-88-

3.1 Наследование идеи о трансформации предприятия

Идея BSP :В рассматриваемом тогда (70-е годы) подходе предполагалось получение усовершенствованных процедур работы в том объеме, который был связан с новыми подходами в ИТ. Имелось в виду, что 1) технология баз данных (новая в то время) давала возможность существенно изменить процедуры работы, а также источники информации,2) И ЧТО ОЧНЬ ВАЖНО: сам процесс анализа подталкивал людей ко многим другим изменениям!

Эти идеи 60-х и 70-х для многих еще и сегодня являются «открытием». В частности, при реализации электронных услуг в «Электронном правительстве»

Page 89: 1.1-3

-89-

Аспекты реорганизации предприятия – трансформации его архитектуры

Дж. Мартин указывал:

"Гораздо полезнее рассматривать процедуры организации с точки зрения того, какими они должны быть, а не являются".

Page 90: 1.1-3

-90-

Цель BSP – и цель современного архитектурного подхода

Дж. Мартин писал: "Первые автомобили называли "безлошадными экипажами" и они действительно по форме напоминали экипаж без лошади. Гораздо позднее стали понимать, что машина может иметь другую форму. Аналогично первое радио назвали "беспроволочным телеграфом", не осознавая, что радиовещание ничем не будет напоминать работу телеграфа. Сегодня мы говорим о "безбумажной конторе" и "безбумажном предприятии", но мы строим системы с видеоэкранами и базами данных, которые дублируют существовавшую ранее организацию работы. Со временем возрастет понимание, что базы данных и видеоэкраны делают возможными различные и лучшие формы организации работы."

Таким образом, целью объявлялось проектирование лучшей организации работы на основе и за счет новых ИТ (в частности - за счет анализа информационных объектов, их использования, обнаружения и исключения противоречий в их использовании).

Page 91: 1.1-3

-91-

Изменение предприятия (организации) и анализ будущего

Мартин писал: «Надо заставить аналитиков-пользователей (они же -

бизнес-аналитики - прим. Е.З.) мыслить творчески. Им легче идти по проторенной дорожке документирования сложившегося бумажного потока, чем определять насущные потребности бизнеса. Сегодняшние документы не должны быть для них шорами. Аналитикам-пользователям необходимо задуматься над тем, какие данные важны для нас и что нам может потребоваться в будущем».

Высшее руководство должно считать анализ объектов не просто средством отображения существующей организации в структуру данных. Анализ должен подвести руководство к вопросу о том, как надо изменить организацию или как она может измениться под воздействием внешних обстоятельств.

Page 92: 1.1-3

-92-

Характерная цитата из описания конкретных случаев применения BSP:

“Прошли месяцы, пока мы осмелились признать, что сама структура руководства была неправильной. Требовалась основательная реорганизация подразделений и отделов, чтобы обеспечить жесткий контроль и высокую административную продуктивность. Только функциональный анализ всей организации помог прийти к такому пониманию."

Page 93: 1.1-3

-93-

Другими словами, надо проектировать БУДУЩИЕ, ТРАНФОРМИРОВАННЫЕ процедуры (процессы) работы, схемы организации подразделений, а также базы данных, и т.д.

То есть – желаемую, трансформированную архитектуру, причем в комплексном ее представлении

Page 94: 1.1-3

-94-

Организационное представление

Архитектура деятель-ности (бизнес-архитектура): функции, объекты, субъекты и

показатели деятельности, документы, регламенты, орг.

структуры

Архитектура деятель-ности (бизнес-архитектура): функции, объекты, субъекты и

показатели деятельности, документы, регламенты, орг.

структуры

Системное представление

Системная архитектура: ИС,

приложения и прикладные сервисы,

информационные ресурсы

Системная архитектура: ИС,

приложения и прикладные сервисы,

информационные ресурсы

Техническое представление Техническая

архитектура: программы,

компьютеры, ОС, СУБД, БД, линии связи

Техническая архитектура:

программы, компьютеры, ОС,

СУБД, БД, линии связи

Представление информации и данных

По BSP начинают думать над новой бизнес-архитектурой под влиянием новшеств в системной архитектуре.

Но возможно и иначе!

Views – представления, «перспективы»

Page 95: 1.1-3

-95-

Это – еще одна причина того, что в Схему архитектуры предприятия по Дж.Захману входят разные аспекты предприятия в их разных представлениях (схема здесь - с точностью до порядка столбцов)

ДАННЫЕ

Бизнес-контекст

Б-модель концептуальная

Системная архитектура

Техническаяархитектура

Практика использования

МОТИВЫ ЛЮДИ

Детальная реализация

Бизнес-план

Конкуренты, Стра-тегии

Бизнес-правила

Условия\ действия

read string

TRIGGER ALARM

Умения!

ГРА-ФИКИ

Партнеры

События

t > t1

on event t > t1 . .

ФУН-КЦИИ

СЕТЬ

1. -------2. -------

1. -------2. -------

INDEX

CREATE TABLE

C:>PING

Wait, please

BEGIN BLOCK

Меню

Page 96: 1.1-3

-96-

Продолжение сведений о подходе Захмана -

Последующие методы и советы

Захман: «Модель предприятия должна учитывать изменчивость предприятия и быть средством накопления знаний о нем». Но идея изменчивости предприятия и его архитектуры в 1992 году появилась только в зародыше. Из поддержки будущего практически была объявлена только архитектура в каком-то одном состоянии – «как надо» (“to be”), без отражения траекторий развития предприятия, а преобразования моделей содержательно рассматривались практически только между строками ОДНОЙ МАТРИЦЫ.

Page 97: 1.1-3

-97-

Версии и целевая архитектура по Захману-92

Page 98: 1.1-3

-98-

Другие актуальные концепции в версии 1992 года

• Архитектурный репозиторий как инструмент накопления знаний о предприятии

• Фрактальный подход к описанию предприятия, его продукции и информационной системы, являющейся моделью предприятия и его продукции

Page 99: 1.1-3

-99-

3.2 Начальный сценарий Захмана

В примерах Захмана есть связи внутри строк, НО НЕТ СВЯЗЕЙ МЕЖДУ СТРОКАМИ !!

Объявлялась аналогия с передачей «заказа» и «спецификаций»:

• от планировщика к владельцу дома, • от владельца дома к дизайнеру,• от дизайнера к строителю• и т.д.(фазы процесса традиционного проектирования и

строительства дома)

А есть ли регулярный метод?!

Page 100: 1.1-3

-100-

«Сценарий Захмана»по «вычислению» архитектурных слоев

• Заполнить ячейки первой строки информацией документов предприятия

(а также интервью и др. источников)• Заполнить ячейки второй строки по ее

правилам, беря исходные сведения из соответствующих ячеек предыдущей верхней строки

• Повторить то же для строк 3, 4, 5

Вопрос: для какого состояния, какого момента в жизни предприятия и его архитектуры это делается?

Добротное обследование

«Фишка»Захмана (?!...)

Page 101: 1.1-3

-101-

«Сценарий Захмана»-2• Ограничения аддитивны: ЕСЛИ заданы ограничения

(требования, стандарты) верхней строки, ТО стандарты и другие ограничения, присущие представлениям нижней строки, «добавляются» к ограничениям верхней строки и «тем самым» формируется очередная строка (как ТРАНСФОРМАЦИЯ предыдущей, не детализация)

• Такой способ «вывести» нижние строки из верхних – идеальная картина (в ней есть даже надежда на реверс-инжиниринг, то есть увидев системную модель мы будем знать все про бизнес-архитектуру … чего не бывает)

• Реальные ограничения возможностей нижних слоев, сложности всей картины и др. таковы, что отображения НЕОДНОЗНАЧНЫ (простой «трансляции» не получается)

Page 102: 1.1-3

-102-

Что означает «трансляция» - 1

Планировщик

Владелец

Дизайнер

Строитель

Столбец А, Данные (ЧТО)Базовые: Сущность АП -- Сущность (Entity) Коннектор -- Связь (Relationship)

Business Subject Area

Groups Business Entity

Data Subject Area

Groups DataEntity

Data base / File

Groups Data Records

Перечни и краткие описания релевантных объектов внешней среды предприятияи его самого

Перечни и краткие описания релевантных частей (компонентов) объектов Внешней и внутренней среды предприятия

Состоят из групп

Page 103: 1.1-3

-103-

Планировщик

Владелец

Дизайнер

Строитель

Что означает «трансляция» - 2Столбец B, Функция (КАК)Базовые: Сущность АП Функция Коннектор Аргумент

Business process

Functionprocess

Business function

System process

IS process

InformationSystem

Storedprocedure

Applicationprocess

ApplicationSystem

Перечни (и краткие описания) процессоввнешней и внутренней среды предприятия

Перечни (и краткие описания) релевантных Бизнес-функций(и подфункций)внешней и внутренней среды предприятия

Состоят из

процессов

EffectBusiness Entity

EffectData Entity

EffectData Records

Page 104: 1.1-3

-104-

Если не принимать специальных мер, это -- классический метод «автоматизации того, что существует», либо

–- «лобовое системное и технологическое ИТ-решение»

(порождающее дублирования, низкий уровень гибкости, …)

Page 105: 1.1-3

-105-

Ограничения такого подходаВопрос: Что было бы, если бы однозначная «трансляция» одного слоя

в другой была бы и возможной и единственно верной по идее?!

Что было бы с двумя схожими по продукту и рыночным условиям конкурирующими предприятиями ?!

Могла бы появиться сегодняшняя компания NOKIA? Или система Linux как инновационный продукт особого

виртуального предприятия?!

Page 106: 1.1-3

-106-

3.3 Согласование архитектурных слоев (частных архитектур)

Неоднозначности и необходимость их разрешать – органическое свойство проектирования больших динамичных систем.

Что делать ?!

При этом:строгие границы столбцов Захмана вводились как средство борьбы со

сложностью (и преодоления ригидности моделей и решений, см. комментарии к 3-й версии) и для придания схеме свойств «таблицы Менделеева» (элементарности неповторяющихся ячеек при повторении части свойств ячеек одного столбца)

изначальный язык строк-представлений строк 2,3,4 выбран как универсальный «ER – стиль» (сейчас – стиль диаграмм онтологических моделей)

Однако сложность уменьшается в ограниченном масштабе, так как остается тот

факт, что «все связано со всем»реальные средства моделирования плохо поддерживают такую

«элементарность» моделейпредложенные правила слишком механистичны, а требуется свобода поиска

инновационных архитектурных решений во всех строках схемы

Page 107: 1.1-3

-107-

«Простые советы»Дж. Захман: Обеспечивать постоянное общение

заказчиков/аналитиков/проектировщиков «по вертикали схемы Захмана» для согласования решений на нижних слоях с потребностями верхних

========================Заметм, что ЭТОГО МАЛО. Надо обеспечивать высокий

профессионализм архитекторов в части их способностей: • общаться со всеми категориями Заинтересованных Лиц по

вертикальной оси схемы Захмана для согласований решений, возможно – для ограничений требований нижних слоев в связи с реальными возможностями нижних

• распознавать потребности, стимулы, ограничения ресурсов предприятия всех видов,

• формировать результативное, гармоничное и экономное устройство формируемой архитектуры в условиях неопределенности,

• находить и использовать для этого ПОДХОДЯЩИЕ типовые элементы, полезные шаблоны и перспективные решения,

• адаптировать чужой опыт для удовлетворения потребностей в рамках возможностей,

• учитывать перспективу развития потребностей и возможностей,

• вносить инновации в оправданном объеме

Page 108: 1.1-3

-108-

Соотношение с правилами проектирования системпо ISO/IEC 15288

и проектирования ПО по ISO/IEC 12207

Этот процесс согласования с потребностями определен в ИСО/МЭК 15288 и 12207 как регулярное действие по ПРОСЛЕЖИВАНИЮ решений к требованиям и потребностям, определенным на предыдущих стадиях создания системы

Однако в АП этот процесс должен стать - комплексным, охватывать все существенные аспекты

предприятия (интегрируя их в каждой строке схемы), охватывать все аспекты предприятия, а не только «зафиксированные в ТЗ требования»

- систематическим, встроенным в изменения во всех циклах истории жизни предприятия

- отражать перспективы развития в живой динамике предприятия

Page 109: 1.1-3

-109-

Нужно осваивать и применять конструктивные правила

формирования одних слоев АП при наличии других (или при их отсутствии!)

• Итеративные (сверху вниз и снизу вверх, из любой точки схемы – в разных направлениях)

• Использующие «магазин заготовок» - избыточный для отбора нужных

• Опирающиеся на критерии принятия архитектурных решений (принципы, нормативы, целевые установки, показатели эффективности)

• При этом не отвергающие инновации (оправданные)

Page 110: 1.1-3

-110-

Конец разделов 1 – 3 из 1-й части курса

Вопросы?

Page 111: 1.1-3

-111-

Далее – о развитии АП как на первом витке, так и в последующем

ГлобализацияНестабильные условия бизнесаИнтернет, мобильные ИТ ирост аутсорсинга

Полная схема Дж. Захмана (6*6) CIMOSA GERAM

3D-предприятие

ISO14258

89 – 95 годы

Крах «дот-нетов»Переход в 21 век

BPR

BPI, BPTChange management

93 – 2000 годы

ISO15704

DoDAF TAFIM

Реформы госслужбыСтарт электронных правительств

96 – рубеж веков

Эл. бизнес

FEAF, FEA

TOGAF

Вход в третий

виток (с 2005 г.)

Page 112: 1.1-3

-112-

3-я версия схемы Дж. А. Захмана

Далее отмечены:- Изменения для названий содержания строк и

столбцов по сравнению с версией 2001- Две статьи, описывающие 3-ю версию схемы

и историю эволюции схемы- Изображение схемы 3-ей версии- Статья Дж. А. Захмана и ее примеры для

иллюстрации абстракций и перспектив, как их представил автор в 3-й версии

Page 113: 1.1-3

-113-e.g. DATA

ENTERPRISE ARCHITECTURE - A FRAMEWORK

Builder

SCOPE(CONTEXTUAL)

MODEL(CONCEPTUAL)

ENTERPRISE

Designer

SYSTEMMODEL(LOGICAL)

TECHNOLOGYMODEL(PHYSICAL)

DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)

Sub-Contractor

FUNCTIONINGENTERPRISE

DATA FUNCTION NETWORK

e.g. Data Definition

Ent = FieldReln = Address

e.g. Physical Data Model

Ent = Segment/Table/etc.Reln = Pointer/Key/etc.

e.g. Logical Data Model

Ent = Data EntityReln = Data Relationship

e.g. Semantic Model

Ent = Business EntityReln = Business Relationship

List of Things Importantto the Business

ENTITY = Class ofBusiness Thing

List of Processes theBusiness Performs

Function = Class ofBusiness Process

e.g. "Application Architecture"

I/O = User ViewsProc .= Application Function

e.g. "System Design"

I/O = Screen/Device FormatsProc.= Computer Function

e.g. "Program"

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Business Process Model

Proc. = Business ProcessI/O = Business Resources

List of Locations in which the Business Operates

Node = Major BusinessLocation

e.g. Logistics Network

Node = Business LocationLink = Business Linkage

e.g. "Distributed System

Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics

e.g. "System Architecture"

Node = Hardware/SystemSoftware

Link = Line Specifications

e.g. "Network Architecture"

Node = AddressesLink = Protocols

e.g. NETWORK

Architecture"

Planner

Owner

Builder

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYCONSTRAINED

MODEL(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Sub-

Contractor

FUNCTIONING

MOTIVATIONTIMEPEOPLE

e.g. Rule Specification

End = Sub-conditionMeans = Step

e.g. Rule Design

End = Condition

Means = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business ObjectiveMeans = Business Strategy

List of Business Goals/Strat

Ends/Means=Major Bus. Goal/Critical Success Factor

List of Events Significant

Time = Major Business Event

e.g. Processing Structure

Cycle = Processing CycleTime = System Event

e.g. Control Structure

Cycle = Component Cycle

Time = Execute

e.g. Timing Definition

Cycle = Machine CycleTime = Interrupt

e.g. SCHEDULE

e.g. Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizations

People = Major Organizations

e.g. Work Flow Model

People = Organization UnitWork = Work Product

e.g. Human Interface

People = RoleWork = Deliverable

e.g. Presentation Architecture

People = UserWork = Screen Format

e.g. Security Architecture

People = IdentityWork = J ob

e.g. ORGANIZATION

Planner

Owner

to the BusinessImportant to the Business

What How Where Who When Why

Copyright - John A. Zachman, Zachman International

SCOPE(CONTEXTUAL)

Architecture

e.g. STRATEGY ENTERPRISE

e.g. Business Plan

TM

Zachman Institute for Framework Advancement - (810) 231-0531

Inventory Process Distribution Responsibility Timing Motivation

Identification

Definition

Representation

Specification

Configuration

Instantiations

Page 114: 1.1-3

-114-

Для самостоятельного ознакомления концепций Схемы Дж. А. Захмана

(вообще и в 3-й версии):

John Zachman's Concise Definition of The Zachman Framework™

by John A. Zachmanhttp://www.zachman.com/about-the-zachman-framework

The Zachman Framework Evolution

by John P. Zachman http://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution

Page 115: 1.1-3

-115-

Page 116: 1.1-3

-116-

Из статьиArchitecture Is Architecture Is Architecture

by John A. Zachman• http://www.zachman.com/ea-articles-reference/52-architecture-is-architecture-is-architecture-by-john-a-zachman

Architecture is the set of descriptive representations that are required in order to create an object.

There is a universal set of descriptive representations for describing any or all industrial products.

Page 117: 1.1-3

-117-

“Abstractions” :

• Bills of Material - What the object is made of.• Functional Specs - How the object works.• Drawings - Where the components exist relative

to one another.• Operating Instructions - Who is responsible for

operation.• Timing Diagrams - When do things occur.• Design Objectives - Why does it work the way it

does.

Page 118: 1.1-3

-118-

… out of the total set of relevant descriptive characteristics of the object, we “abstract” one of them at a time for producing a formal, explicit, description

Page 119: 1.1-3

-119-

Perspectives as depicted in the Zachman Framework™

Page 120: 1.1-3

-120-

___________

Вопросы?

[email protected]