Докеры, контейнеры и прочие микросервисы. Как DevOps меняет жизненный цикл ПО

ContainersАйтишники довольно сильно разобщены. Разработчики информационных систем, системные администраторы, эксперты по большим и маленьким данным, специалисты, отвечающие за ИТ-процессы и пр. глубоко копают, но каждый в своем направлении. И в каждом из этих направлений регулярно происходят те или иные революционные изменения. Например, в заметке об Open Digital API я немного затронул тему микросервисов. Вроде бы хорошая идея. Но поинтересуйтесь у разработчика, в чем заключается конкретная польза такого подхода, и в ответ вы услышите набор общих фраз. Или другой пример – PaaS. На вопрос, чем частное облако отличается от виртуализации, следует примерно такой ответ: в частном облаке вы выделяете себе виртуальную машину самостоятельно, без участия администратора, а простая виртуализация – это когда вас пару месяцев мурыжат заявками и согласованиями (подробнее см. Призрак Digital на пороге вашего офиса). В принципе, данный ответ верен. Но зачем пользователям самостоятельно создавать себе виртуальные машины? Ответ понятен если вы хостинг-провайдер, но зачем это нужно в обычной корпоративной среде? Для того, чтоб найти ответы надо собрать все вместе и PaaS и microservices и жизненные циклы разработки и эксплуатации программного обеспечения. По отдельности оно не работает Читать далее


DocFlow2015: не хватает простых идей

7104r_banner_240x120_newЯ немного настороженно отношусь к большим форумам типа DocFlow. Доклады на таких мероприятиях делать сложно, т.к. аудитория довольно разная. Каждый пришел со своими ожиданиями. Кто-то по делу, кто-то по привычке, а кто-то просто от работы отдохнуть. В такой ситуации  тема выступления должна быть максимально простой, понятной широкому кругу слушателей, но не банальной. Поэтому сегодня я не выступал, а походил по секциям и послушал чужие доклады. И в этом качестве мне решительно не хватило простых, но интересных концепций, идей, вызывающих wow-эффект.  А ведь в теме ECM/СЭД таких идей огромное количество. И на каждой из них можно выстроить ценностное предложение для клиента Читать далее


Так ли уж близки корпоративная архитектура и бизнес-процессы?

capabilityРаз уж мы в предыдущей заметке BABOK Guide v3 techniques map заговорили о новых техниках бизнес-анализа, то стоит о некоторых из них написать немного подробней. Начнем с бизнес-архитектуры, которая представлена теперь в своде знаний отдельной перспективой (раздел 11.4) и парой новых техник Business Capability Analysis (раздел 10.6) и Business Model Canvas (раздел 10.8). О второй технике я немного писал в заметке Чему ИТ может научить бизнес. Пара замечаний о Product Development и сейчас не стану останавливаться на ней подробно. А вот про business capability стоит поговорить. Тем более, что есть интересный нюанс. Читать далее


BABOK Guide v3 techniques map

babokGuideГотовясь к чтению курса «Анализ требований и проектирование решений» в рамках программы ВШБИ Повышение операционной эффективности бизнеса, я решил поискать в Интернет картинку с перечислением основных техник бизнес-анализа (В недавно вышедшей третьей версии BABOK Guide их стало пятьдесят штук). Погуглив, как следует, подходящей картинки я так и не обнаружил. К счастью так сложилось, что последние пару месяцев мы на работе постоянно занимаемся рисованием картинок в стиле business capabilities map. Правда рисуем мы на таких картинках вовсе не capabilities, но сути это не меняет. В общем, не обнаружив подходящей, картинки я решил нарисовать её сам.  Читать далее


О заполнении шаблона описания архитектуры решения

deployment-node-composition-nestedОписание архитектуры ИТ-решения не самая простая практика. И уж точно не следует приступать к её освоению с заполнения шаблона описания архитектуры. Тем не менее, такого рода шаблоны существуют и кто-либо из представителей заказчика информационной системы не редко требует описать архитектуру. Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором, и потому я возьму на себя смелость дать несколько рекомендаций о том, как это следует делать. Обычно, в качестве шаблона используются производные от RUP-овского Software Architecture Document скачать который можно, например, здесь. Существенно реже можно встретить TOGAF-овский Architecture Definition Document и уж вряд ли вам попадется ISO-шный Architecture description. Поэтому ориентироваться будем на первый шаблон. Читать далее


Structured Wiki. Время собирать ссылки

dbpedia-linksЭто сообщение отличается от остальных заметок блога. Мне понадобилась страница для сбора и некоторого структурирования информации о технологиях управления знаниями, которые сочетают в себе подход реляционных баз данных и хранилищ в виде гипертекста.  Постараюсь сильно не злоупотреблять англоязычными статьями и сопровождать ссылки небольшими аннотациями Возможно, кому-то этот набор аннотированных ссылок будет полезным. Остальные же могут просто пропустить это сообщение и перейти к следующему. Читать далее


Корпоративный поиск. Находим правильную метафору

etter-tmНесколько лет назад случилась со мной поучительная история. Генеральный директор компании, в которой я тогда работал, встречалась с новыми сотрудниками. Как это принято в подобных случаях разговор было теплый и искренний, а молодые сотрудники не только радовались первым дням работы в такой большой и яркой организации, но и высказывали отдельные критические замечания. Среди таковых отмечалась абсолютная невозможность найти какие-либо актуальные инструкции и распоряжения, регламентирующие работу сотрудников. Думаю, никого из читателей этого блога не удивит то, что поручение устранить это досадное недоразумение получила дирекция информационных технологий. Неубедительные попытки рассказать, что на интранете уже есть похожая функция, но ей просто никто не пользуется, желаемого эффекта не принесли и в компании появился проект по организации корпоративного поиска.

В качестве причины того, почему молодые сотрудники не могут быстро найти нужные инструкции и распоряжения рассматривались две гипотезы. Одна принадлежала мне, другая – нашему CIO. Мое предположение заключалось в том, что издающие распоряжения руководители мало заботятся о том, чтоб кто-либо узнал об их существовании. Все усилия тратятся на то, что подготовить, согласовать и утвердить распоряжение. На что-либо большее сил у людей уже не остается. Потому свежеизданное распоряжение закидывают в дальний угол, где найти его достаточно проблематично. Вариант исправления этой ситуации, по моему наивному мнению, заключался в том, чтоб научить людей публиковать такого рода документы на едином централизованном ресурсе. Правильно их классифицировать, указывать зависимости между документами, назначить ответственных за категории и темы и т.д. В общем, типичный подход присущий архитектору информационных систем. Предположение нашего CIO, человека намного более опытного, заключалось в том, что никто описанной выше ерундой заниматься не будет и единственное возможное решение – простая, удобная в использовании и релевантная система корпоративного поиска. Именно это решение и легло в проект. Читать далее


Отслеживать

Настройте получение новых записей по электронной почте.

Присоединиться к ещё 99 подписчикам