Рубрика: Без рубрики

[slideshare id=32610494&doc=architectureagile-140322100834-phpapp02]

Дорогие друзья! Как вы, возможно, знаете, я покинул позицию Chief IT Architect в компании «ВымпелКом». Предвосхищая вопрос, чем я буду теперь заниматься, я хотел бы сделать несколько анонсов. В ближайшие пару месяцев я не буду работать в режиме full time в какой-либо организации.  Это не значит, что я собираюсь бездельничать, скорее наоборот. На ближайшее время у меня запланировано несколько тренингов, пара консалтинговых проектов и множество встреч с интересными людьми.

Сначала про тренинги. Раньше я уже анонсировал тренинг «Презентация архитектуры ИТ решений: истории в рисунках»,  который состоится 10 апреля 2014 года в ScrumTrek. В двух словах о том, зачем нужен этот тренинг (не читайте описание тренинга на сайте – там слишком многабукв).  Читать далее До свидания, Билайн!

Уважаемые читатели блога. Я буду признателен, если Вы найдете двадцать секунд, чтоб принять участие в небольшом опросе. Вряд ли кто-то станет отрицать важность наличия архитектуры в современном ИТ-проекте. Тем не менее, в подавляющем большинстве проектов архитектура либо оставляет желать лучшего, либо просто отсутствует. Почему так происходит? Читать далее Опрос по архитектуре в ИТ-проектах

Последнее время у меня получаются сообщения из серии о единстве и борьбе противоположностей. Управление изменения Standard+Case approach о взаимопроникновении кейс-менеджмента и традиционного подхода к управлению бизнес-процессами, Что такое DevOps о взаимодействии разработки и эксплуатации ИТ-решений и т.д.

Не стану нарушать традицию и сегодняшнее сообщение об анализе требований с одной стороны и проектировании ИТ решений с другой. Казалось бы, эти функции должны быть очень схожи между собой по подходам и методологии, но на практике различия между ними могут быть существенными. Значительно больше, чем между 1-ым и 2-ым уровнем поддержки в ITSM или между разработкой и эксплуатацией. Практически все традиционные методологии развития ИТ решений ориентированы на подход «сверху вниз». Сначала собираем требования, потом проектируем, реализуем, тестируем, развертываем, уходим на следующую итерацию, добавляем новые требования и т.д. без конца. Архитектура больше ориентирована на восходящий подход (bottom-up approach). У нас есть варианты решений(паттерны), мы прикладываем их к задаче и выбираем тот, который подходит наилучшим образом (см. Еще несколько слов о проектировании). Преимущество первого подхода в полноте реализации требований. Сила второго – в простоте, рациональном использовании ресурсов, более высокой вероятности достижения ожидаемого результата.

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

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

Сегодня ведется огромное количество дискуссий о перспективах корпоративных социальных сетей. Большинство из них замусорено привычным HR-ым жаргоном: вовлеченность, мотивация, лидерство. При этом за общими словами крайне редко можно разглядеть конкретные рецепты того, что именно нужно делать, как сформировать и развивать сообщество. Поэтому в большинстве случаев дело ограничивается тем, что корпоративный редактор или ответственный за группу периодически что-то пишет, а кто-то, вероятно, его читает. Талантливые редакторы, как правило, уходят в PR службу и начинают работать с большим Интернетом. Остальные потихоньку сопровождают ресурс, дожидаясь того момента, когда их самомотивация упадет до нуля. Читать далее Социальные механики

Вернулся с проходившего на ВМиК семинара Евгения Захаровича Зиндера “Влияние развития информационных технологий и способов их делового применения на архитектуру предприятия” (на самом деле, семинар называется еще длиннее, но точное название я, к сожалению, не запомнил). Не стану пересказывать все затронутые темы, их слишком много. Семинар оказался интересным. Иногда совершенно нелишним является подумать о том, что будет с корпоративной архитектурой в перспективе 3-7 лет. Правда ответа на главный вопрос о том, как же изменится орг.стурктура, во что преобразится иерархическая или матричная бюрократия я не получил. Судя по всему каких-то кардинальных изменений не случится. А то, что случится, уже можно в каком-то виде обнаружить в организации сегодняшней.

Наверное, это хорошо. Хорошо потому, что современные корпоративные информационные системы абсолютно не готовы к таким вещам как сетевые бизнес-процессы, сервисная организация работ, да и к аутсорсингу они по большому счету не готовы. Так что некоторый резерв времени у КИСов есть, тем более что давление, побуждающее их к изменениям, они испытывают уже сейчас. Но сегодня только об одном модном слове BYOD (Bring your own device), т.е. использование собственных устройств.

Мне всегда казалось забавным, что тема эта раздувается людьми, намеревающимися продавать средства централизованного управления такими устройствами. Т.е. логика примерно такая: использовать свой iPad на работе можно, но на него необходимо установит специальное ПО, которое позволит его удаленно администрировать, лечить от вирусов, обеспечивать на нем информационную безопасность. Честно говоря, рассуждения такие мне кажутся довольно неразумными. Проблема не в том, что пользователю начнут работать с корпоративными информационными системами с собственных устройств. Проблема в том, что корпоративное ИТ утратит право распоряжаться этими устройствами. Когда у людей не было домашних компьютеров и мобильных телефонов с доступом в Интернет, корпоративная рабочая станция представляла для него ценность. С работы можно было слазить в Интернет, а в обеденный перерыв поиграть в любимую игрушку. За это пользователи готовы были мириться с ограничениями. Когда личные устройства по качеству и производительности стали превосходить рабочие станции причин мериться с неудобствами не стало.

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

Все реже и реже использую RSS-Reader. Думаю, что я не один такой. Поэтому  настроил трансляцию блога в Facebook и Twitter.

• Архитектура ИС в Facebook
• Мой Twitter

Подписывайтесь.

Я решил так назвать ИТ решения, появления которых не могу дождаться уже лет пятнадцать. Все началось в середине 90-х в Инкомбанке. Мне довелось заниматься системами межбанковского финансового документооборота и системами Клиент-Банк. В то время, все нормальные банки проводили межбанковские платежи через ЦБ. Но так как эти банки были нормальные то, разумеется, им это не очень нравилось. Поэтому клиринг (прямые взаимозачеты между банками) казался им перспективной идеей и многие это делали. Электронное взаимодействие с клиентами тоже имело свои особенности. У нас был целый отдел, зарабатывающий на выезде к клиенту, настройке ПО, изготовлению дубликатов ключей цифровой подписи и т.д. и т.п. Работали они неплохо, какую-то денежку зарабатывали. Еще было некоторое количество «подкованных» клиентов, которые норовили внедрить банку свое решение «клиент-банк». У некоторых особо крупных клиентов это получалось. Только вот чинить его к нам они почему-то не приезжали. Читать далее Появится ли B2B Сloud?