Учебный курс: ИТ архитектура предприятия
В преддверии Нового года принято строить планы и загадывать желания. Я собираюсь в начале 2012 года собрать имеющиеся у меня материалы в учебный курс по архитектуре информационных систем организации. Краткая презентация курса выглядит примерно так:
Я не собираюсь пересказывать учебник по UML или учить вас рисовать диаграммы в нотации Archimate. Мы не будем моделировать корпоративные java приложения и разбираться в тонкостях отображения объектно-ориентированных моделей в реляционной базе данных. Цель этого курса выделить базовые техники ИТ архитектуры, востребованные в современной организации. Разобраться что, когда и главное зачем должен делать сотрудник, занимающий должность ИТ архитектора. Как применить теоретические наработки архитектуры предприятия (Enterprise architecture), подходы к моделированию информационных систем, руководства по процессам управления ИТ к задачам и операционным процессам современной компании.
В программе курса:
1. Ретроспектива программных архитектур. Возрастание сложности корпоративных информационных систем: непрерывные инновации; разрозненность унаследованных приложений; устаревание технологий. Изменения в бизнесе: слияния и поглощения; процессный подход к управлению организацией; интеграция информационных систем предприятия с системами поставщиков и заказчиков.2. Роль архитектуры в процессах управления ИТ. Моделирование и инвентаризация ИТ-услуг и ИТ-ресурсов. Задачи архитектора в процессах управления изменения, управления релизами информационных систем, инцидентами, дефектами и проблемами.
3. Предпосылки возникновения сервис-ориентированного подхода в архитектуре:
- объектно-ориентированный анализ и проектирование информационных систем;
- открытые интернет-стандарты взаимодействия бизнес-приложений, SOAP и RESTful веб-сервисы;
- архитектура предприятия, средства управления бизнес-процессами, интеграция приложений.4. Проектирование архитектуры сложных ИТ решений, включающих согласованные изменения нескольких информационных систем и построение композитных приложений. Создание высокоуровневого дизайна решения. Декомпозиция бизнес-процессов по системам. Разработка программных интерфейсов. Планирование инфраструктуры, развертывания и сопровождения. Задачи архитектора на разных фазах традиционного ИТ проекта. Кросс-проектная деятельность. Оптимизация портфеля проектов.
5. Основные информационные системы организации. Финансовые и учетные системы. Системы управления персоналом, документооборота и коллективной работы. Приложения для поддержки взаимоотношений с клиентами, поставщиками и заказчиками. Интернет-сайт и корпоративный портал. Мобильные приложения. Технологии интеграции приложений. Сервисная шина предприятия, системы управления бизнес-процессами и бизнес-правилами, управление основными данными.
Надеюсь, основное учел. Буду признателен за добавления, советы, акценты и замечания!
1. Разница между системным и бизнес-архитектором
2. Обоснование архитектурных решений
3. Влияние бизнес-модели на enterprise arch
4. Business patterns: data-driven VS process-driven apps
5. Обоснование ROI решений
6. Влияние enterprise arch на бизнес-модель
7. Описание и документирование arch (points of view, проекции, роли, etc)
Идея прекрасная. Это будет внутренний, корпоративный курс, коммерческий курс, или доступная для широкой публики публикация, наподобие курсов intuit.ru?
В гл. 4-ю напрашивается хотя бы краткое упоминание о широко известных в узких кругах архитектурных методологиях TOGAF, GERAM, DoDAF и т.п. При полном раскрытии эта тема тянет на отдельный (и, может быть, не один) курс.
Планирование вычислительных мощностей серверного парка, ЦОДы, корпоративные вычислительные сети и т.п. вопросы – Вы хотите раскрыть их в разделе “планирование инфраструктуры” гл.4?
Павел, спасибо за комментарий.
В первую очередь, я должен сделать внутренний курс. Отработаю его на нашей компании, на России и операторах связи из СНГ. Отработаю тайминг, практические задания и постараюсь сделать внешний курс. Запрос от учебных центров у меня на такой курс уже есть.
Согласен, что нужно добавить архитектурные фреймворки. Планирую остановиться на TOGAF в связке с Archimate. Действительно, большая тема, в полтора-два часа проработать её будет тяжело. Может быть отдельным учебным днем в курсе следует делать.
Это же верно и для инфраструктуры. В п.4 я планировал затронуть только capacity и планирование развертывания решения в конкретном проекте. Хотя ориентироваться буду, конечно же, на запросы. Архитектура инфраструктуры – большая тема.
Евгений, спасибо за содержательный отклик.
п. 7 – обязательно включу; как минимум в разделы “ретроспектива” и “проекты”
п.п. 2,5 – неочевидные но, безусловно, интересные. В принципе, они присутствуют у Gartner-а и в некоторых материалах IBM. При обосновании архитектурных решений, я бы делал акцент на освещение вопроса с различных точек зрения (перекликается с п.7), ну и кончено: “архитектура, как выбор объекта для инвестиций”
п.п. 1,3,6 – тоже подумаю. Вопрос в том, что бизнес-архитектор, для большинства компаний, персонаж вымышленный, обитающий то ли в HR, то ли в департаменте по стратегии.
п. 4 – безусловно
Еще раз спасибо!
У меня следующие предложения:
1. переформулировать пункт №5, так как может сложиться впечатление, что Вы планируете обучать людей финансовым или HR-системам. Но скорее всего Вы планируете обрисовать типовые домены (предметные области), с которыми придется столкнуться архитекторам, не так ли?
2. учить создавать что-то с нуля это конечно всегда интересно
Но с нуля никто подобные архитектуры ни описывать, ни создавать не будет. Думаю разумно было бы с самого начала в архитекторов закладывать навыки и знания о методиках анализа и эволюционирования архитектур (ATAM, SAAM, etc.). Про это в программе курса вообще ни слова?
3. из 2) вытекает еще более важная задача – научить архитекторов управлять бизнес-требованиями (вряд ли найдется иная кандидатура на эту задачу), выполнять анализ текущих архитектур и органичный их тейлоринг.
Про анализ требований и методики анализа архитектуры замечание ценное. Уделю этому какое-то внимание, хотя бы потому, что требования тоже надо как-то структурировать, привязывать к подразделениям (бизнес-функциям). В общем, без вариантов использования не обойтись.
Относительно переформулирования п.5 – спасибо. Согласен, что может сложиться ошибочное представление.
А наш CIO при разработке HLD еще хочет видеть анализ зрелости используемых/планируемых технологий с учетом того, на каком этапе жизненного цикла (по Gartner) эти технологии находятся. Мы например ухитрились в 2007 году (с другим CIO
) приобрести “свежий” на то время продукт HP Open View 5.1 и построить на нем основные ITSM процессы, а в 2011 Hewlett Packard уже снимает его с поддержки и предлагает “мигрировать” на принципиально другой HP Service Manager.
Это я к тому, что хорошо бы и анализ рисков как-то осветить…