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

Часть открытой системы, выполняющая некоторую функцию и входящая в состав того или иного уровня, называется объектом.

Правила, по которым осуществляется взаимодействие объектов одного и того же уровня, называются протоколом (методика связи).

Протоколы определяют порядок обмена информацией между сетевыми объектами. Они позволяют взаимодействующим рабочим станциям посылать друг другу вызовы, интерпретировать данные, обрабатывать ошибочные ситуации и выполнять множество других различных функций. Суть протоколов заключается в регламентированных обменах точно специфицированными командами и ответами на них. Каждый уровень подразделяется на две части:

- спецификацию услуг;

- спецификацию протокола.

Спецификация услуг определяет, что делает уровень, а спецификация протокола - как он это делает.

Причем, каждый конкретный уровень может иметь более одного протокола.

Большое число уровней, используемых в модели, обеспечивает декомпозицию информационно-вычислительного процесса на простые составляющие. В свою очередь, увеличение числа уровней вызывает необходимость включения дополнительных связей в соответствии с дополнительными протоколами и интерфейсами. Интерфейсы (макрокоманды, программы) зависят от возможностей используемой ОС.

Два основных класса определений архитектур ИС - определения «конструктивные» и «идеологические»

Идеологические:

- “Архитектура ИС - это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой”

- “Архитектура ИС - это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения”

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

Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:

- что делает система ;

- как эти части взаимодействуют;

- где эти части размещены.

- на какие части она разделяется;

Таким образом, архитектура ИС является логическим построением, или моделью. Как же она влияет на совокупную стоимость владения? Через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т.п. - т.е. через то, что мы называем инфраструктурой ИС. Итак, инфраструктура включает решения не только по программному обеспечению, но также и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах.

По всей видимости, число проектов, в которых архитектура системы сознательно выбирается, относительно невелико. Естественно, архитектура будет наличествовать в любом случае, другое дело, что она может не конструироваться и не выбираться сознательно.

Несмотря на то, что большинство методологий подчеркивают важность архитектуры, ни одна не дает внятной методики ее выбора. Причины этого таковы:

- Фирменные методики навязывают, с разной степенью настойчивости, фирменную же архитектуру и инфраструктуру (таковы, в частности, Oracle CDM и MSF);

- XP фактически отрицает осознание архитектуры, что оправданно для некрупных проектов, выполняемых небольшой командой (1-3 пары программистов).

Вопросы разработки архитектуры довольно подробно рассматриваются в традиционных методиках. Проблемами этих подходов, на наш взгляд, являются:

- невозможность оценить качество разработанной архитектуры;

- ориентированность на архитектуру программной системы и дистанцирование от того факта, что система состоит не только из программных, но также и технических средств и людей;

- разделение процессов технико-экономического обоснования системы, разработки бизнес-процессов и разработки архитектуры системы;

- отсутствие привязки к бизнес-целям и целям использования системы.

В результате осмысления имеющихся методик нами были сформулированы следующие требования к методике выбора архитектуры. Методика должна:

- отражать связь архитектуры и совокупной стоимости владения;

- отражать итерационную природу разработки ИС;

- иметь своей целью выбор архитектуры системы в целом, а не только ее программной составляющей;

- связывать разработку архитектуры, бизнес-анализ и технико-экономическое обоснование в едином процессе.