Действительно о SOA в последнее время говорят все кому не лень. SOA - это модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизованными интерфейсами. Расшифровывается как Service Oriented Architecture. Считается, что за этим подходом будущее и он вылечит все беды прошлого.
Попробую просто объяснить, в чем чудо.
Идея состоит в том, чтобы перестать создавать большие программные комплексы, а начать делать небольшие абсолютно независимые компоненты (сервисы) и собирать их в большой комплекс (архитектуру) под задачи конкретного клиента. Плюсы очевидны:
1) Каждый сервис можно отдельно развивать и быстро доставлять клиенту
2) Тестировать нужно только сервисы, в которых вносились изменения
3) Сами сервисы клиент может брать от разных поставщиков (выбирая лучшее на рынке, отказываясь от плохих поставщиков в пользу хороших)
Уровень зависимости клиентов от поставщиков IT-решений и риски IT-проектов многократно понижаются, а скорость решения бизнес задач во много раз возрастает.
Сказать хорошо, а сделать трудно. Многие компании вложили огромные деньги и время, чтобы создать новые поколения своих продуктов в соответствии с SOA-подходом.
У компании IBM есть собственный стандарт оценки SOA зрелости продуктов. Называется он Service Integration Maturity Model (SIMM). Там 7 уровней зрелости. Оценивается возможность интегрируемости продуктов с внешней средой. Нижние уровни – низкая, верхние – высокая. Достаточно сказать, что для нашей компании, чтобы добраться со своими продуктами с 3 до 6 уровня зрелости потребовалось 5 лет и более 20 млн. долл.
Сервисы на верхнем уровне зрелости работают с внешней средой по контракту. В соответствии с этим контрактом они не только делают то, что от них ожидают, но и гарантируют производительность, качество и многие другие вещи. Это происходит по аналогии с материальным миром. Например, мы карандашная фабрика, а сервис – это поставщик древесины. Нас интересует не только количество древесины, но и качество (количество сучков), сроки поставки, порода дерева, размеры партии и прочее. От программного сервиса мы ждем, что он будет работать с нужной скоростью при оговоренном количестве запросов и требований к технике. Мы хотим в случае развития сервиса и отмирания старых методов, чтобы у нас было время перейти на новые методы, а старые в это время работали... Все это предмет договора и разработчик обязан его соблюдать, а не только поставлять нам новые функциональные возможности.
Но основное чудо не в этом. Главное в том, что имея набор сервисов мы можем начать относиться к автоматизации не как к внедрению чего-то большого, неповоротливого и независимого, а как к внедрению системы описывающей и позволяющей управлять реальными бизнес-процессами, потому что можем вызывать сервисы в последовательности соответствующей реальной работе сотрудников организации.
Автоматизируя реальные процессы организации, мы можем без вмешательства разработчиков оптимизировать процессы (сокращать издержки) или совершенствовать процессы (развивать бизнес). А это есть основные задачи любой организации. То есть внедрение SOA систем на высоком уровне зрелости создает сильнейшее преимущество для любой организации в скорости реагирования на потребности рынка и в эффективности деятельности.
Комментарии 4
Коротко и по делу. Позволяет очень быстро погрузиться в тему.
здесь вы отождествляете программный комплекс экономике в целом, а компоненты - её субъектам. а моэно сопоставить ПК организму, компаниии, всякий раз находя полезные аналогии
Появление таких стандартов как CMMN/Adaptive Case Management дают почву для применения этой бизнес-модели на практике.
Я придерживаюсь позиции легкости управления, нежели красивого интерфейса и инструментариев для моделирования. Этих продуктов уже достаточно на рынке, - и рынок хочет управлять и оптимизировать бизнес-процессы, а не только рисовать квадратики и стрелочки ради получения регламентов и должностной иерархии на предприятии.