Публикация на Facebook ссылки на IT4IT Reference Architecture вызвало большую, но неоднозначную реакцию. Кто-то проявил живой интерес, а кто-то отметился репликами в стиле: «Да кому это нужно! И что это за кружочки с квадратиками?». Выскажу свое мнение. Эталонная архитектура операционной модели деятельности ИТ-подразделения, изложенная в документе, получилась очень неплохой. Визуализация этой архитектуры (см. рисунок ниже) сделана существенно хуже. Чтоб закрыть вопрос с картинками сразу скажу, что синии прямоугольники на картинках обозначают основные функции, а черные круги – объекты данных. Серые и фиолетовые круги – это частные случаи объектов данных (подклассы), обозначающие вспомогательные объекты и воспринимаемые пользователями ИТ-услуг сервисы. Теперь о содержании. Читать далее Структура операционной модели ИТ
Метка: Enterprise architecture
Роль ИТ-архитектора в организации
Несколько месяцев назад я написал заметку Когда, кому и зачем нужна Архитектура Предприятия Справедливости ради надо отметить, что полномасштабный проект по выстраиванию Enterprise Architecture встречается достаточно редко. Намного чаще услуги архитектора бывают востребованы для решения более локальных задач: структурирование приложений, процессов и данных в рамках отдельного продукта, бизнес-функции или направления деятельности организации. В таких случаях обычно говорят об архитектуре ИТ-решения, а человека который её делает называют Solution architect. Одной из задач этого уважаемого эксперта является разработка архитектуры в ИТ-проекте. На прошлом месте работы мы называли эту деятельность High Level Design Но у Solution architect есть еще одна, не менее важная задача – подготовка вариантов решения. О том как это сделать можно почитать здесь Create a solution architecture А я напишу несколько слов о том, почему это важно. Читать далее Роль ИТ-архитектора в организации
BABOK® Guide Version 3 Public Review
Международный институт бизнес-анализа выполнил свое обещание и сегодня разместил у себя на сайте предварительный вариант третьей версии «A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)» для общественного обсуждения. Регистрация предельно простая. Заходите по этой ссылке BABOK® GUIDE V3 PUBLIC REVIEW, нажимаете кнопку “Start your review now” регистрируетесь в привычном бизнес-аналитикам Confluence и читаете/комментируете главную книгу бизнес-анализа. Продлится публичное обсуждение до 11 июля. Вопросы и ответы здесь BABOK®V3 FAQ
Из ожидаемых отличий от предыдущей версии Business Analysis Core Concept Model (BACCM), которая раньше уже обстоятельно обсуждалась, пять перспектив: Agile, Business Intelligence, Information Technology, Business Architecture, Business Process Management и переработанные техники и компетенции. Свое мнение об этих новшествах я ранее уже высказал в сообщении Бизнес-аналитики – друзья, соседи или дальние родственники?
Но, безусловно, новая версия свода знаний по бизнес-анализу требует более глубоко прочтения. Надеюсь, в ближайший месяц у меня найдется достаточно времени, чтоб почитать и пообсуждать все эти вещи. Буду рад услышать и ваше мнение.
Когда, кому и зачем нужна Архитектура Предприятия
Начал работать с одной компанией на тему архитектуры предприятия (Enterprise Architecture) и решил скорректировать своё представление об EA, сделать его понятней и проще. Обычно, датой рождения EA считают публикацию John A. Zachman «A Framework for Information Systems Architecture» 1987 года, хотя сам термин появлялся и в боле ранних работах. Не смотря на то, что архитектура предприятия вещь довольно молодая, она успела уже подпортить себе репутацию. Как и любая другая архитектура, архитектура предприятия не имеет точного определения(см., например, 10 Definitions of Enterprise Architecture), но зато имеет большое число неудачных проектов (см. Gartner Identifies Ten Enterprise Architecture Pitfalls или 8 Reasons Enterprise Architecture Programs Fail). Обычно, после завершения проекта по разработке архитектуры предприятия можно услышать такую фразу: «Мы нарисовали все необходимые картинки, но не имеем ни малейшего представления как извлечь из этого хоть какую-то пользу». Поэтому, давайте проговорим все с самого начала. Читать далее Когда, кому и зачем нужна Архитектура Предприятия
Бизнес-аналитики – друзья, соседи или дальние родственники?
Томительное ожидание выхода третьей версии свода знаний по бизнес-анализу A Guide to the Business Analysis Body of Knowledge (BABOK v3) вызывает у меня противоречивые чувства. (Поэтому я и решил полностью переписать предыдущую заметку.) С одной стороны International Institute of Business Analysis (IIBA) это довольно типичная организация по написанию и продаже дорогих книжек, развитию региональных представительств и многоуровневых систем сертификаций. Все подобные организации, правильнее их было бы назвать сектами, сделаны по одному шаблону. И проблемы у них у всех одинаковые: изменения освещаемой ими темы происходят намного быстрее, чем издаются очередные релизы их главных книжек. Адепты такого кунг-фу сильно рискуют обнаружить абсолютную ненужность приобретенных навыков к моменту достижения черного пояса. Впрочем, каждый зарабатывает, как умеет. С другой стороны контент BABOK мне кажется достаточно содержательным Читать далее Бизнес-аналитики – друзья, соседи или дальние родственники?
Чему ИТ может научить бизнес. Пара замечаний о Product Development.
В компании, из которой я недавно уволился, я не все время работал Главным ИТ архитектором. Несколько лет я проработал менеджером по запуску новых продуктов (value added services). Правда, в определенный момент пришло осознание того, что мы делаем все не очень правильно. Собственно, потому я и перешел в ИТ на позицию архитектора. Архитектор, особенно архитектор предприятия (Enterprise Architect) – это тот человек, который может исправить некоторые ошибки бизнеса (я оставлю за скобками вопрос, кто такой EA и почему в отечественных реалиях такая должность не встречается в бизнес-подразделениях). Я надеюсь, что в будущем компания успешно справится с болезнями роста и скорректирует процессы развития и управления продуктами, но во время моей работы этот процесс был таким, каким он был. Читать далее Чему ИТ может научить бизнес. Пара замечаний о Product Development.
Проект IT Transformation
Наступил месяц декабрь. За окном падает легкий снег и я думаю, теперь уже можно считать, что проект ИТ трансформации у нас, наконец, закончился. Ну, в основном, закончился. У нас нет орг.структуры, у нас нет CIO, нет так же руководителя проектного офиса ИТ, менеджера основного ИТ проекта, нет стратегии, но… зато у нас есть целевая архитектура (target architecture). Не то чтоб совсем актуальная, ну да ладно. Это уже мой третий проект ИТ трансформации, поэтому если кто решил трансформировать свой ИТ, но не знает с чего(или с кого) начать, обращайтесь Читать далее Проект IT Transformation
Стратегия развития корпоративных информационных систем (2)
Тема Стратегия развития корпоративных информационных систем вызвала довольно много откликов на FB, поэтому еще несколько соображений относительно pace layer model. Первое относится к тому, могут ли приложения переезжать из одного слоя в другой. На этот вопрос дается четкий ответ в работе How to Differentiate Governance and Change Management in Your Pace-Layered Application Strategy (19 September 2012 ID:G00237513). Организации должны регулярно пересматривать свой портфель приложений и при необходимости корректировать классификацию той или иной системы. Читать далее Стратегия развития корпоративных информационных систем (2)
Стратегия развития корпоративных информационных систем
Забавные вещи пишут ребята из Gartner относительно стратегии развития приложений. Называется это pace layer model. Если говорить в двух словах, то смысл модели следующий. Организации необходимо иметь три типа бизнес-приложений: system of records, system of differentiation, system of innovation. На мой взгляд, названия не очень удачные. Но дело, разумеется, не в словах, а в подходе, который стоит за этими названиями. Читать далее Стратегия развития корпоративных информационных систем
Почему не все сервисы одинаково полезны
В программировании известен такой архитектурный паттерн как Inversion Of Control. Суть его в следующем. Традиционно, повторно используемый код оформлялся в виде функций, которые впоследствии вызывались из основной программы. Функции оформлялись в виде статических библиотек, динамических библиотек или вообще в виде сервисов. Приходил программист. Брал функциональные требования, реализовывал бизнес-логику в виде отдельной программы, которая при необходимости вызывала эти самые функции. Inversion Of Control переставляет все с ног на голову. Мы пишем готовую программу, внутри которой реализуем повторно используемый функционал. При этом мы предусматриваемые некоторые точки расширения, в которых вызываются функции, реализующие бизнес-логику. В качестве примера можно привести функцию обработки сообщений главного окна приложения Windows именуемую MainWndProc(). В объектно-ориентированном программировании приложение часто наследуется от некоторого базового класса. Читать далее Почему не все сервисы одинаково полезны