На неделе выступал перед довольно масштабной аудиторией наших разработчиков. Так как развитием ИТ систем в нашей компании занимается несколько сотен человек, то недостатка в слушателях не было. Выступая, затронул новую для себя тему. Похоже, об этом я еще нигде не рассказывал.
Итак, зачем компании нужна сервис-ориентированная архитектура Читать далее Одна из ошибок при переходе от инхауса к аутсорсингу
Рубрика: Software architecture
Почему Oracle APEX
Что делает нормальный программист, не испорченный разговорами об архитектуре предприятия и презентациями о системах управления бизнес-процессами, когда к нему приходит пользователь с пачкой excel-файлов и говорит: «Надо бы как-нибудь автоматизировать!». Немного похмурив брови и почесав затылок, программист говорит: «Нужно базу данных писать, начальника». Так делали наши деды и, возможно, так же будут поступать наши внуки. Если, конечно, SalesForce к тому времени не утащит все наши данные в облако(см. http://www.database.com/) Читать далее Почему Oracle APEX
Oracle Application Express
Есть вещи, о существовании которых не знаешь, не помнишь или просто не задумываешься
[slideshare id=1554612&doc=applicationexpressvaluepropositionforcustomers-124456216456-phpapp01] Читать далее Oracle Application Express
ArchiMate – друг архитектора?
Здесь на каждого по три истины
И на всех одно заблуждение
(с)Зимовье зверей
От всех экспертов, занимающихся архитектурой предприятия, окружающие ожидают примерно одного и того же – картинок. Переплетенных стрелочками квадратиков, взгляд на которые волшебным образом расставит все по своим местам. Я уже писал о том, что в моём понимании архитектура предприятия – это внутрикорпоративный веб-сайт, на котором широкий круг экспертов создает и редактирует странички с описанием процессов, приложений, основных информационных объектов и связывает их гиперссылками в сообщении Архитектура предприятия в формате SemanticWeb и продолжаю придерживаться мнения, что архитектура это не картинка, не книжка и не презентация, а социальный интранет-сайт. Тем не менее, люди хотят картинок. Потому, вопрос выбора графической нотации вряд ли когда-либо исчезнет. Читать далее ArchiMate – друг архитектора?
Заказная разработка vs. коробочные решения
Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.
Эталоном процессов эксплуатации промышленных решений является ИТ-сервис менеджмент (ITSM). Helpdesk-и, отстроенная система управления инцидентами и дефектами и т.д. и т.п. Однако, для заказной разработки весь этот айтил-майтил, не то чтобы совсем не подходит,… просто не эффективен. Причины следующие:
Во-первых, люди, которые делают заказную разработку, как правило, являются ответственными профессионалами, испытывающими гордость за созданное решение. И поэтому, разработчики заказных систем готовы отвечать за результат своего труда и поддерживать свое решение и днем и ночью и в выходные и в праздники. Вытеснение таких разработчиков из продуктивной среды, замутнение коммуникаций формализованных процессами инцидент менеджмента и управления дефектами, приводит к тому, что мы не используем это благородное чувство ответственности. Это момент психологический.
Во-вторых, как известно, заказная разработка заключается в создании некоторого уникального продукта, созданного и используемого единожды. С другой стороны, ключевым фактором эффективности ИТ-процессов является экономия на объеме. Сервисная служба эффективна потому, что у разных пользователей возникают одинаковые проблемы, которые можно консолидировать, классифицировать и исправить. Т.е. выгода в том, что для большинства обращений мы уже заранее знаем, почему болит и как лечить. Вся эта логика не особо работает для заказной разработки, которая по определению уникальна. И проблемы в ней уникальны. И разобраться в этом может только тот, кто их создал.
Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется
Архитектор SOA
На прошлой неделе я три дня посвятил обучению на курсе Архитектор SOA Содержательную оценку курсу давать пока не хочу. Пожалуй, самое интересное, что я из него вынес это то, как организовать бизнес на пустом месте. Томас Эрл, в соавторстве с другими уважаемыми экспертами написал дюжину толстых книг про SOA http://www.soabooks.com, организовал школу сервис-ориентированной архитектуры http://www.soaschool.com , договорился с Prometric о проведении экзаменов http://www.soacp.com и продолжает развивать тему SOA. Лейтмотивом всей этой бурной деятельности, на мой взгляд, является тезис о том, что SOA – это не об интеграции приложений, а о том, как избежать интеграции приложений. О том, почему интеграция это долго, дорого и всегда рискованно я рассказывать здесь не стану, а интересующихся, переадресую к статье Глеб Ладыженский. “Интеграция приложений такая, как она есть”
Вернемся к SOA. Тем временем у самой SOA дела идут не столь хорошо, как у SOASystems Inc. Главное свое обещание – избавить нас от интеграции бизнес-приложений она не исполнила. И одна из причин тому чисто технологическая. SOAP и WS-* порождают интеграционных задач больше чем решают. Надежды на изменении ситуации к лучшему и достижению цели SOA, пусть хоть не в полном объеме, связаны теперь с RESTful Web services. Не обманут ли нас в очередной раз? Вообще-то, могут и обмануть. Просто интерфейсы бывают плохие и хорошие. А о том, почему одни интерфейсы лучше других я напишу в следующий раз
«Точечная застройка» и «промышленные» решения
В отечественной сфере бизнес-приложений существует одно, на мой взгляд, достаточно неприятное заблуждение, связанное с так называемыми «промышленными» решениями. Заблуждение это состоит в том, что предпочтение надо отдавать не заказной разработке программного обеспечения, а готовым решениям от крупных поставщиков. Вернее, заблуждение состоит в ответе на вопрос почему это следует делать. Обычно считается, что приобретя готовое решение его можно быстро и дешево внедрить, т.к. все уже заранее запрограммировано добрым вендором. В реальности получается, что купленное решение надо долго и мучительно дорабатывать, кастомизировать, интегрировать в уже существующую ИТ-инфраструктуру и так далее и тому подобное. В итоге, решение конкретной задачи длится дольше и обходится дороже, что приводит к довольно серьезному противодействию внедрения такого рода платформ в будущем. В чем же истинная причина того, что такого рода решения все еще покупаются?
Еще несколько слов про CHG
Перечитал своё вчерашнее сообщение. Наверное, не очень понятно, почему я пишу о JIRA в контексте управления изменениями (change management). Всё очень просто: у кого чего болит… У меня сейчас болит это самое управление изменениями.
Налог на три буквы
На днях я отметился в комментариях к блогу Андрея Колесова на тему И снова… СЭД, ECM, ИТ Причина моей спонтанной покупки реплики, в общем-то довольно банальная. Я не люблю абстрактных рассуждений о СЭД, ECM, BPM, ERP, ESB и тем более о СОА, но в силу профессии вынужден постоянно находиться в облаке тегов этих терминов. И вот приходишь после работы домой, садишься читать Google Reader, а там опять трехбуквенные сокращения… Читать далее Налог на три буквы
SOA обманула аналитиков
Под таким заголовком прошел очередной круглый стол CNews посвященный сервис-ориентированной архитектуре. Я так и не понял, кто и каким образом подчитал, что SOA-решения продаются существенно лучше прогноза. Но дело не в этом. Термин SOA по-прежнему жив, по крайней мере, в нашей стране. О нем действительно продолжают говорить, а значит эта тема до конца не раскрыта. Потому, позволю себе еще один «подход к снаряду». Читать далее SOA обманула аналитиков