Метка: REST

Как понять, что вы разговариваете с настоящим ИТ-архитектором

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

Как нам разобраться кто из них настоящий ИТ-архитектор, суждениям которого можно доверять, а чьи рекомендации стоит перепроверить? Я бы не стал делить ИТ-архитекторов на настоящих и фейковых. Внимание к архитектуре системы, решения или организации в целом – это уже хорошо. Тем не менее, полезным будет иметь некоторую шкалу, характеризующую уровень доверия к предложенным тем или иным экспертом архитектурным решениям(architecture decision). Примерно так же, как в свое время Леонард Ричардсон предложил использовать модель уровней зрелости для проверки соответствия API архитектурному стилю REST. Продолжить чтение «Как понять, что вы разговариваете с настоящим ИТ-архитектором»

Клиентский опыт и архитектурный стиль RESTful

Разговоры о Customer Experience (опыте клиентского взаимодействия) ведутся уже так долго, что вряд ли способны привлечь чьё-либо внимание. Особенно внимание айтишников. Мол, это вообще не к нам. Есть специально обученные люди – дизайнеры, которые всё сделают правильно и непременно улучшат этот самый клиентский опыт. Архитектурный стиль RESTful, описанный Роем Филдингом аж в 2000 году в диссертации Architectural Styles and the Design of Network-based Software Architectures, привлечет не большие внимание тех же самых айтишников. Всё  ведь и так понятно. JSON поверх HTTP  — вот и весь RESTful. Давайте все же разберемся, о чем этот архитектурный стиль и как он связан с опытом клиентского взаимодействия. Продолжить чтение «Клиентский опыт и архитектурный стиль RESTful»

Тренинг: микросервисная архитектура

UPD 6/12/2017 Ссылка на группу в telegram: https://t.me/msa_training 

Микросервисная архитектура – это новый подход к созданию, развитию и эксплуатации распределенных информационных систем, состоящих из множества независимых компонент.

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

HATEOAS: реализация функций в RESTful API

Я не знаю кто и когда придумал аббревиатуру HATEOAS, означающую Hypermedia As The Engine Of Application State. Выглядит она страшно, а звучит непонятно. В общем разбираться с тем что это такое и зачем оно нужно совершенно не хочется. Из-за этого потенциал, заложенный в архитектурный стиль REST и позволяющий создавать довольно интересные программные интерфейсы остается не раскрытым. Но обо всем по порядку. Продолжить чтение «HATEOAS: реализация функций в RESTful API»

Архитектура частного облака

PartlyCloudy1На протяжении нескольких лет тема облачных вычислений (cloud computing) была целиком и полностью спекулятивной. Вероятно, причиной тому являлся приоритет бизнес-модели над технологиям. Технологические лидеры, безусловно, рассказывали широкой общественности о том,  что же такое облако; поясняли, что облака бывают публичные, частные и гибридные, но за всеми этими разговорами отчетливо виднелись длинные уши маркетинга и продаж. И желание у персонажей, которых я назвал «технологическими лидерами» было только одно – вместо лицензий и проектов продавать услуги. Причем не так как раньше, не услуги по разработке программного обеспечения, а услуги, оплачиваемые постоянно, в ходе всего жизненного цикла. На сегодняшний день ситуация поменялась. Покупка услуг по подписке стала привычным делом. Мы стали покупать не только услуги ЖКХ или пакеты услуг связи, но и музыку по 169 рублей в месяц в Apple Music. Вероятно, скоро можно будет подписаться  на месячный пакет еды в близлежащем супермаркете. В общем, тема бизнес-модели стала неактуальной. Пришло время поразбираться в технологиях. Продолжить чтение «Архитектура частного облака»

Несколько замечаний относительно Open Digital API

frameworx9 декабря этого года TMForum опубликовал пресс-релиз о выходе первого Digital Service Toolkit, предназначенного для организации взаимодействия между абонентами и компаниями (операторами и поставщиками услуг) для построения цифровых сервисов и поддержки интернета вещей (Internet of Things). Toolkit представляет собой набор руководств по построению партнерских продуктов и услуг, шаблоны построения бизнес-моделей и организации операционного взаимодействия и спецификации программных интерфейсов. Наверное, наиболее интересно выглядят именно рекомендации по построению бизнес-моделей, собранные в руководстве Online B2B2X Partnering Step by Step Guide, включающем набор готовых шаблонов и примеров, по  разработке ценностного предложения (Customer Market Proposition), бизнес-модели, контрактов на совместное предоставления услуги, финансовой и операционной модели. Но мы поговорим о другом: эталонных архитектурах, моделях данных и спецификациях программных интерфейсов. Продолжить чтение «Несколько замечаний относительно Open Digital API»

Как варианты использования определяют архитектуру системы

Давным-давно когда компьютеры были большими, данные маленькими и о Big Data еще никто не слышал, а каналы связи узкими и не очень длинными Эдгар Кодд предложил реляционную модель данных. Очевидно, что за сорок с лишним лет многое изменилось. Можно долго перечислять появившиеся технологии но, в конечном счете, важным является совсем не это. Технологические изменения привели к изменению сценариев использования (use case) информационных систем. Люди взаимодействуют с компьютером совершенно иначе, чем в стародавние времена.

Продолжить чтение «Как варианты использования определяют архитектуру системы»

Facebook Graph API

Я довольно давно не затрагивал тему adaptive case management. Не затрагивал, не потому что она мне стала не интересной. Просто последние несколько месяцев у меня очень много работы, связанной с практической реализацией ИТ поддержки такого рода процессов. В первую очередь, речь идет о процессах решения телеком инцидентов. Это тысячи тикетов ежедневно, необходимость оперативного доступа к данным о клиентах, договорах, адресах подключений, данным по сетевому оборудованию и предоставляемым сервисам. Все это по-разному работает для разных типов услуг, линий бизнеса, в разных информационных системах. Этот практический опыт подтверждает мои предыдущие наблюдения. Если бы мне сейчас пришлось писать Adaptive Case Management Manifesto я бы начал с того, что гибкость бизнес-процессов достигается разделением приложений для совместной работы и приложений управления данными.
Продолжить чтение «Facebook Graph API»

Масштабируемость RESTful web-сервисов

Representational State Transfer это не только эффективный стиль для архитектуры данных и приложений. Безусловно, очень удобно, когда у каждого информационного ресурса есть неизменный URL.  Такую гиперссылку можно сохранить или переслать коллеге, избавив информационные системы от повторного поиска. Но придумывался REST, как впрочем и HTTP, не только для этого. Основная задача этой архитектуры заключалась в построении масштабируемых многоуровневых приложений. Не смотря, на очевидность и простоту этой архитектуры, очень многие разработчики корпоративных информационных систем её не понимают (или делают вид, что не понимают). Поэтому, очередной взгляд на эту архитектуру. На этот раз с точки зрения инфраструктуры. Продолжить чтение «Масштабируемость RESTful web-сервисов»

Мобилизация корпоративных информационных систем и дилемма инноватора

Если бы лет пять назад вы спросили программиста, будет ли в будущем его приложение работать на андроиде то, в лучшем случае, он счел бы вас эксцентричным фанатом «Звездных войн». Сегодня вопрос предоставления сотрудникам доступа к корпоративной информационной системе с мобильных устройств звучит вполне обыденно. Вопрос не в том, предоставлять ли такой доступ, а скорее — как это сделать. Очевидный ответ на него: разработать для приложений мобильные клиенты – мне представляется нечестным и трудно реализуемым. На протяжении последних пятнадцати лет мы регулярно переписываем свои корпоративные системы. Сначала мы переписывали их в архитектуру клиент-сервер, потом переписывали на Java, затем готовили к проблеме 2000. С появлением серверов приложений мы снова их переписывали. Продолжить чтение «Мобилизация корпоративных информационных систем и дилемма инноватора»