В нашем предыдущем посте мы описали атрибуты решения для открытых сетей. В этом посте мы расскажем о том, что, несомненно, является “Святым Граалем” открытых сетей: о функциональной совместимости. Интероперабельность определяется следующим образом:
”Интероперабельность — это характеристика продукта или системы, интерфейсы которой полностью понятны для работы с другими продуктами или системами, в настоящее время или в будущем, как при внедрении, так и при доступе, без каких-либо ограничений
Википедия Https://ru.wikipedia.org/wiki/Совместимость
В конечном счете, совместимость означает, что я могу свободно заменять компоненты, т.е. если у меня есть компонент X в моем открытом сетевом решении, то в будущем я могу свободно заменять его компонентом Y.
Сегодня Компоненты сильно различаются по этой способности в зависимости от любого из “форм-факторов” компонентов, которые мы описали в этом посте. Но не только технологические компоненты играют важную роль в нашей концепции функциональной совместимости.
По определению, чтобы обеспечить высокую степень взаимодействия, мы должны иметь возможность свободно заменять компоненты в каждом из них. о тех аспектах открытости, которые мы описали здесь.
Давайте кратко рассмотрим каждый из них по очереди.
Вероятно, наиболее очевидной и наиболее часто используемой стратегией обеспечения функциональной совместимости является определение и/или принятие стандартов. Это касается как тех стандартов, которые официально установлены органами по стандартизации (стандарты “де-юре”), так и тех, которые установлены неофициально в результате доминирования на рынке или повсеместного использования (стандарты “де-факто”).
Идея открытых стандартов на самом деле не означает замену различных стандартов друг другом (хотя решение проектировщикам, вероятно, следует учитывать затраты на переключение стандартов на этапе проектирования). Использование открытых стандартов означает выбор одного стандарта для конкретной функциональной области решения и доведение уровня соответствия до этого стандарта, что позволяет свободно переключать компоненты в рамках этой функциональной области решения.
Это сложная тема, которую мы рассмотрим в следующем посте.
С точки зрения интеграции программного обеспечения, интерфейсы прикладного программирования (API) являются фундаментальным способом достижения функциональной совместимости. Существует несколько аспектов “открытости” API:
Возможность свободно менять партнеров является ключом к открытым системам, но необходимо учитывать несколько факторов:
К сожалению, было много случаев, когда поставщики пытались (и преуспевают) в том, чтобы привязаться к клиентам на долгосрочную перспективу. Эта форма “поиска ренты” порождает недоброжелательность и порождает множество защитных мер, некоторые из которых являются экстремальными и противоречат идее “беспроигрышного исхода”.
Ранее мы обсуждали открытый исходный код, но не рассматривали его с точки зрения совместимости. Открытый исходный код отвечает требованиям Open Partners к прозрачности технологий — он доступен для всех и, следовательно, прозрачен. Хотя для расширения знаний о новом поставщике могут потребоваться усилия, компоненты с открытым исходным кодом часто имеют множество источников поддержки, знаний и ресурсов, которые могут помочь в этом процессе.
Как упоминалось в предыдущем посте, открытые операции означают, что операционные процессы являются гибкими и открытыми для изменений, открытыми для взаимодействия, и прозрачный. Вкратце, это краткое описание DevOps.
Мы рассмотрели парадигму DevOps в предыдущей статье. Практика открыта, когда новые поставщики могут подключиться без проблем и значительных накладных расходов. Существует четкий переход от бизнеса к разработке и эксплуатации, что позволяет новым поставщикам быстро наращивать добавленную стоимость. Использование общих концепций, инструментов и практики позволяет новым поставщикам очень быстро понять, где они находятся.
Из вышесказанного мы можем видеть, что все атрибуты открытых решений обеспечивают совместимость. Большинство бизнес-кейсов и проектных планов содержат оценку рисков, а иногда и финансовые положения для покрытия издержек, связанных с изменениями, которые могут произойти в ходе проекта: отказ партнера, или часть технологии, или какой-либо другой аспект решения повлечет за собой затраты и задержки по мере выбора, проверки и интеграции новых компонентов в раствор.Единственным реальным критерием функциональной совместимости является то, что эти рисковые события, если они происходят, на порядок менее сложны и затратны, так что резервы на возможные риски могут быть уменьшены или устранены. Мы знаем, к чему стремиться, но, увы, мы еще далеки от этого этапа. В этом посте мы рассмотрели некоторые проблемы, которые приводят к такому ошибочному предположению. Мы расскажем больше в нашем следующем посте.
Следите за обновлениями.
Узнайте больше
О создании реальных открытых сетей. Часть 2 – Взаимодействие: Святой Грааль впервые появился на Aptira.