Чтобы оценить, насколько информационная модель соответствует модели SID, следует взять все сущности либо только репрезентативную выборку сущностей— в зависимости от того, сколько времени выделено на оценку. При детальной оценке осуществляется проецирование атрибутов информа­ционных сущностей на соответствующие атрибуты сущностей SID. После завершения проецирования можно оценить степень соответствия SID. Об уровнях соответствия SID речь шла в предыдущей главе. Уровни соответ­ствия, или совместимости, позволяют оценить степень соответствия сущнос­ти или группы сущностей ABE SID. Иначе говоря, они помогают выяснить, насколько полно сущность или группа сущностей согласована с соответству­ющей ABE SID, а также определить объем работы, который нужно выполнить, чтобы обеспечить взаимодействие с другим приложением, уровень совмес­тимости которого с SID установлен.

В приведенном ниже примере результаты такого проецирования пред­ставлены в виде таблицы, состоящей из трех колонок: в первой колонке расположены атрибуты информационных сущностей, во второй — атрибуты соответствующих сущностей SID, третья колонка предназначена для коммен­тариев. Пустая ячейка в колонке атрибутов SID означает, что соответствую­щий атрибут сущности SID отсутствует. Это говорит о том, что здесь может стоять новый атрибут SID или атрибут, который представляет конкретное расширение приложения для соответствующей сущности SID. Кроме того, эту таблицу можно использовать при создании расширений для конкретных приложений к схемам XSD SID.

Подробная оценка сущности Абонент

В приведенной ниже таблице представлены результаты проецирования сущнос­ти Абонент (Subscriber) на АВЕ Клиент (Customer) SID.

Проецирование сущности Абонент (система Y) на АВЕ Клиент SID Проецирование сущности Абонент Атрибут сущности Абонент Сущность SiD/атрибут Комментарий НОМЕР АБОНЕНТА Customer ID and CustomerAccount ID = Идентификатор клиента и идентификатор счета клиента В модели (Компания X) у каж­дого клиента только один счет НОМЕР ИНДИВИДУУМА IndividualName formOfAddress = Форма адреса: номер индивидуума Номер индивидуума INDIVIDUAL NUMBER играет роль ключа для поиска в таб­лице с именами индивидуумов ТИП АБОНЕНТА CustomerAccount accountType = Тип счета «Счет абонента» СТАТУС АБОНЕНТА CustomerAccount accountStatus = Статус счета «Счет абонента» ФАМИЛИЯ АБОНЕНТА IndividualName familyName = Наименование абонента: фамилия

Проецирование сущности Абонент
Атрибут сущности Абонент	Сущность SID/атрибут	Комментарий
ИМЯ АБОНЕНТА	IndividualName givenName = Наименование абонента: имя
ВТОРОЕ ИМЯ АБОНЕНТА	IndividualName middleName = Наименование абонента: второе имя (отчество)
ПЕРВЫЙ АДРЕС АБОНЕНТА
ВТОРОЙ АДРЕС АБОНЕНТА
ТРЕТИЙ АДРЕС АБОНЕНТА
ГОРОД АБОНЕНТА	UrbanPropertyAddress municipality = Городской муниципалитет абонента
ГРАФСТВО/ОКРУГ АБОНЕНТА
ПОЧТОВЫЙ ИНДЕКС АБОНЕНТА	UrbanPropertyAddress postcode = Почтовый городской индекс абонента
НОМЕР ДОМАШНЕГО ТЕЛЕФОНА АБОНЕНТА	ContactMediunVTelephonNumber type and number = Тип контактной среды / телефонного номера и теле­фонный номер
НОМЕР РАБОЧЕГО ТЕЛЕФОНА АБОНЕНТА	ContactMediunVTelephoneNumber type and number = Тип контактной среды / телефонного номера и теле­фонный номер
НОМЕР ФАКСА АБОНЕНТА	ContactMediunVTelephoneNumber type and number = Тип контактной среды / номера факса и номер факса
АДРЕС ЭЛЕКТРОННОЙ ПОЧТЫ АБОНЕНТА	ContactMedium/Email Address eMailAddress = Контактная среда / адрес электронной почты: адрес электронной почты
НОМЕР МОБИЛЬНОГО ТЕЛЕФОНА/ПЕЙД­ЖЕРА АБОНЕНТА	ContactMedium/TelephoneNumber type and number = Тип контактной среды / телефонного номера и теле­фонный номер
КРЕДИТНЫЙ СКОРИНГ АБОНЕНТА
ДАТА ПЕРВОНАЧАЛЬ­НОГО ВВОДА ДАННЫХ АБОНЕНТА

Проецирование сущности Абонент
Атрибут сущности Абонент	Сущность SID/атрибут	Комментарий
ДАТА ПОСЛЕДНЕГО ИЗМЕНЕНИЯ ДАННЫХ АБОНЕНТА
ССЫЛКА НА РЕСЕЛЛЕРА АБОНЕНТА		Только для интернет-клиен­тов: промо-код
ДЕНЬ РАСЧЕТОВ АБОНЕНТА	CustomerAccountBillCycle billCycle = Цикл рассчета клиента: расчетный цикл
ДАТА АКТИВАЦИИ АБОНЕНТА	PartyRole validFor/startDateTime = Роль стороны: время оценки / начала цикла абонента
ДАТА ИНАКТИВАЦИИ АБОНЕНТА	Party Role validFor/endDateTime = Роль стороны: время оценки / завершение цикла абонента
РЕСЕЛЛЕР СЧЕТА АБОНЕНТА		Флажок показывает, что счет клиенту выставлять не надо
НОМЕР ТЕЛЕФОНА АБОНЕНТА		Не используется
НОМЕР РЕСЕЛЛЕРА	PartyRoleAssotiation assotiationType and involvesPartyRole = Связь роли стороны: тип связи и включение роли стороны	Внешний ключ реселлера
СЕАНС ПОЛЬЗОВАТЕЛЯ: СОЗДАТЬ АБОНЕНТА		Имя приложения или логин клиента (CSR), которое/ который создает клиента

Эта детальная оценка (при сравнении с АВЕ Клиент SID) позволила опреде­лить, что сущность Абонент (Subscriber) достигла соответствия третьему уровню SID, а по некоторым характеристикам — четвертому уровню. Уровень 3 служит базовым уровнем, на котором должно обеспечиваться соответствие по отде­льным сущностям.

Свойства примечаний

Теперь можно перейти к анализу примечаний, относящихся к этой подробной оценке. Из приведенного выше примера видно: сущность Абонент имеет два атрибута, что указывает на некоторое превосходство используемой информаци­онной модели над моделью SID. В ABE SID Клиент отсутствуют атрибуты КРЕДИТ­НЫЙ СКОРИНГ АБОНЕНТА (SUBSCRIBER CREDIT SCORE) (общий атрибут, присущий клиентам) и СЧЕТ РЕСЕЛЛЕРА КЛИЕНТУ (SUBSCRIBER BILL RESELLER), который опре деляет, нужно или не нужно выставлять счет клиенту.

Возможности повышения совместимости

Кроме того, сейчас можно оценить возможности повышения совместимости.

В приведенном выше примере отмечено, что для улучшения соответст­вия информационной модели модели SID специалист по информационной архитектуре может рассмотреть возможность введения в эту модель кон­цепции «Сторона / Роль стороны» (Party /Party Role). Такая совместимость окажется полезной, если в рамках данного приложения роли «Стороны» (ин­дивидуума или организации) могут быть разными (например, «Абонент» или «Сотрудник»).

Кроме того, специалист по информационной архитектуре может разделить адрес абонента на дополнительный набор атрибутов, которые соответствуют атрибутам почтового адреса в модели SID, а именно: номер улицы, название улицы и т. д.

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

Таким образом можно получить общую сводку оценок по отдельным сущностям, которая становится базисом для разработки плана действий на будущее.

Раздел 3.3. Краткосрочные и долгосрочные планы

использования SID

На основании результатов детальной оценки можно разработать рекоменда­ции по использованию SID в рамках целевой организации. Подробнее об этом говорилось в главе 3, и такие рекомендации можно ввести в план дей­ствий компании в отношении использования SID.

Ниже мы приводим пример подобных рекомендаций.

5/0 как часть среды интеграции приложений

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

На приведенном ниже рисунке показан пример частной схемы XML, пред­ставляющей расширения к XSD Клиент SID для конкретной компании. Затем эта XSD используется для определения полезной нагрузки сообщений для операций, которые влияют на объект Клиент-Абонент (Customer Subscriber). XSD — это объединение ряда сущностей SID, включая Роль Стороны (Party Role), Имя инди­видуума (Individual Name), Городской адрес абонента (Urban Property Address), Клиент (Customer), Счет клиента (Customer Account) и Цикл расчета клиента (Customer Account Bill Cycle).

Фрагмент XSD Абонент (Subscriber)
(КОМПАНИЯ X)

<xs: compiexTypc - nr-г,. "SIBCustomer">

<xs:oomplexContent>

<xs: restriction base "SIDBusCu:Customer">

<xs:sequence>

<xs:element n.:="customer I D" t y: ="xs:string" nr. - able-"true" m. ar. Occu r 5 - " 0 " / >

<xs: element. ■ •4-="customerStatus" ' yn ="xs:string" nil. nl 1- "true" m-j.-.Ot I'ur - "£>"/>

</xs:sequence>

</xs: restriction>

</xs:complexContent>

</xs:complexType>

<xs:complexType n. rirv "Customer">

<xs:сопрIexContent>

<xa: extension ="Syst. emYSI DBusCu: SIDCustomer">

<xs: sequer. ce>

<xs:element гы-if=="CustomerAccount" t yr ="Syst. ernYS:DBusCu: CustomorAccount" а_ - Lai - c "true" r._.nOee_rs; "0"/>

<xs:element па: -"InciividualName" typ — "SystemYSIDBusCu: Individual Kamo" n ; ' u. le="true" j.: : ;.;="0"/>

<xs:element папе-"UrbanPropertyAdaress"

; yp^="SystemYSIDBusCu:UrbanPropertyAddress" I — "true" ninOcrur ="0"/>

<xs: element nr. me. - "home Phor. cNumbe r " type-"SystemYS. DBusCu: Te. ephoneNumber" n:. - las: .«—"true" г : nOc - :;-я="0"/>

<xs:element • • -*"workPhoneNumber" 1 y:.;="Syste:nYSIDBusCu:

Те 1 ephoneNumber" ni. iVo..,: "true" n •:: v - s-"0"/>

<xs:element. ="t'dxNumber" ’ yie="SystemYSIDBusCu:

FaxNumber" n___ .н і, -"true" r.-.Oc - . -"0"/>

<xs: element n•=»-•- "emailAddress" ' ype - "SystemYSIDBusCu:

F. maіIContact" 1 ,,i■ l-="lrue" nine - u: ="0"/>

<xs:element r"mobilePagerNumber" typ. -"SystemYSIDBusCu: TelephoneNumber" 1 1.•—"true" rr no.- • -.="0"/>

<xs:elemer. t n. -"PartyRole" ■ 1 ^"SystemYSIDBusCu:

PartyRole" n. =u le="true" mir. Ot. turs="0"/>

<xs:element. 1 —"CuatomerAccountBillCycle"

-yv, "SystemYSIDBusCu:CustomerAccountBillCycie" "true" :ті.-cur ;-"C"/>

<xs:element пз“,е="reNuraber" 1 yr —"SystemYSIDBusCu: PartyRoieAssociation" n. ll-"true" r. inOccurs="0"/>

<xs : elerre-r. t n - • "CustomerExteneions" typ - "SystemYSIDBusCu:

Customer&xtensions" nil'.»! ie="true" 1 .0■ .u ="0"/>

</xs:sequence>

</xs:extens ion>

</xs:complexContent>

</xs:complexType>

На следующем рисунке показана XSD, содержащая сведения о полезной на­грузке сообщений для изменения информации о сущности Абонент (Subscriber),

Изменение фрагмента XSD Абонент
(Subscriber)

<xsrcomplexType naro "ChangeSubscriber">

<xs: cotr. pl exCon ten t>

<xs:restriction і "SystemYSIDBusCu:Customer">

nill -"true"

</xs:sequence>

<xs:element.. ="Custoir. erAccount" ="SystemYOpsSIDBusCu: ChangeSubscriberAccount* ‘ - "true" rr' "0"/>

<xs:element ;■ •• ="IndividualName" у.■ ="SystemYSIDBusCu: IndividualName" ru - .at;a-"true" ninCrcur "0"/>

<xs:element ri..: --="UrbanPropertyAddress"

■-УР-. • "SystemYSIDBusCurUrbanPropertyAddress" nLi:-:-.-. o-"true" :r. inOc•:•. "C"/>

<xs:element n-ii • ="homePhoneNumber" .:-'H="systemYSIDBusCu: TelephoneNumber" n: . і at. c-"true" minO-:i:urs-"0/'/>

<xs:element ru-.i ■ ="wor kPhoneNumber" ypi-="SystemYSIDBusCu: TelephoneNumber" n: . і ac_<: - "true" min. ccurs "0"/>

<xs :element n-.r*=.="f axNumber" : yp~ ="Sys temYS 1 DBusCu: FaxNumber" r. il. abl -"true" _nOc: -"0"/>

<xs:element ri --.--"ета і 1 Address" • r - -"SystemYSIDBusCu: Eir. ailCor. tact" .. 1 lai-i- -"true" rr :c. -"C"/>

<xs:eiement -"mobilePagerKurr. ber" t:y; • -"SystemYSIDBusCu:

TeiephoneNumber" n! ="t. rue" ="0"/>

<xs:element . "PartyRole" . "SystemYSIDBusCu:

Party Role" і abl-="true" rv, .:s="0"/>

<xs:clement - "CustomerAccountBillCycle"

•yp-="SystemYSIDBusCu:CustomerAccountBiliCycle" . true" ="Q"/>

<xs:element "reNumber" тур-:-"SystemYSIDBusCu:

Pa r t yRo 1 e Assoc і a t і on" r 1 —"true" :m :.Oc::.j • .-:="0"/>

<xs:element n-:-.r> "CustomerExtensions" . "SystemYSIDBusCu: CustomerExtensions" r і 1 at1 -;="true" г nOcou1s="0"/>

</xs:sequence>

</xs:restrict ion>

</xs:complexContent>

</xs:comp 1 ex? ype>

которая используется как часть прикладного программного интерфейса API для изменения сущности Абонент в пределах (Системы Y) и/или приложения парт­нера. Обратите внимание на то, что атрибут идентификации клиента (customerlD) является обязательным.

Группа оценки может включить или встроить в отчет полную выборку схем XSD, из которых извлекались фрагменты, наряду с документами XML.

Долгосрочная цель состоит в разработке структуры интеграции приложений на базе SID, которая использовалась бы для интеграции внутренних корпора­тивных приложений. Например, при взаимодействии с приложением для управ­ления запасами (Inventory Management Application, IMA) можно использовать прикладные программные интерфейсы API, основанные на схемах XML SID, для ослабления связей между приложениями. Ослабление связи между приложени­ями позволяет защитить интерфейсы API от внутренних изменений в схеме базы данных в приложении.

Раздел 4. Анализ архитектуры реализации с точки зрения TNA

Раздел 4.1. Для чего оценивается архитектура реализации

В этом разделе отчета должны быть представлены результаты оценки общей архитектуры реализации и предложены меры для обеспечения ее соответ­ствия принципам TNA NGOSS. Оценка должна включать следующее:

• оценку совместимости используемой архитектуры реализации и TNA NGOSS;

• определение плана действий для повышения этой совместимости.

Раздел 4.2. Оценка архитектуры реализации

Введение

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

Например, можно ограничить рамки оценки лишь приложениями А, В и С внутри компании, причем только аспектами безопасности, политики, ин­теграции и производственного процесса. Если не позволяет время или нет возможности провести экспертные консультации, группа оценки может на­меренно исключить из оценки методологию реализации, применение сце­нариев использования и др.

Ниже приведен пример сводной оценки текущего статуса.

Сводка приложений

Многие приложения в составе корпоративного решения являются устаревшими системами, созданными согласно конкретным спецификациям (как на основе собственных разработок, так и тех, которые были предложены внешними про­вайдерами).

В приведенной ниже таблице представлены целевые корпоративные прило­жения, характер каждого приложения (пакетное/устаревшее) и другая обобщен­ная информация о приложениях.

Имя приложения	Готовое или разработанное самостоятельно	Основная технология	Методы интеграции	Процессный подход	Подход на основе управления безопасностью/ ПОЛИТИКОЙ	Комментарии (например, в отношении масштабируе­мости и производитель­ности)
Система X	Разработано самое тоятельно	Java, .NET, ASR. COM (??), SQL Server	SOAP через HTTP, ссылка на ASP, MSMQ	В пределах приложения	Служба Active Directory	XML выделяет до 0,5 Мб на сеанс. Нагрузка распределяется по серверам портала
Система У	Разработано самое тоятельно	Java, .NET, ASR. COM (??}, SQL Server	SOAP через HTTP, ссылка на ASP MSMQ	В пределах приложения	Служба Active Directory
Отказ 2 (Обработка отказов)	Разработано самое тоятельно	SQL Server, ASR .COM	COM+, ссылка на ASP	В пределах приложения	Служба Active Directory
Banner	Кастомизиро­ванный OPAL	Согласно OPAL	Согласно OPAL	В пределах приложения	Служба Active Directory	Согласно ONYX
Блокировка	Разработано самостоятельно	SQL Server, .NET, IIS, SQL Server	SOAP через HTTP, CD для новых адресов	В пределах приложения	Служба Active Directory
Обратный ракурс	Пакет заказной (кастомизиро­ванный)	Solaris Oracle с сохранением процедур	Вызовы Oracle, FTP	В пределах приложения	Из приложения	Масштабируемость и гибкость не определены
Оценка	Пакет	Oracle	FTP	В пределах приложения	Из приложения
Выставление счетов	Разработано самостоятельно		MSMQ	В пределах приложения	Из приложения	Проблемы производительности и масштабируемости. Операци­онное окно ограничено. Бил­линг выполняется ежедневно. Нагнать упущенное сложно (если необходимо). Регулярно требуется восстановление Индекса базы данных, так как это снижает время расчета на 30 мин.
Запись	Разработано самостоятельно	SQL Server	FTP	В пределах приложения	Из приложения
Подключение	Разное	Разное	Обмен внутренними сообщениями	В пределах приложения	Из приложения
Инвентари­ зация	Разработано самое тоятельно	Solaris, Oracle	WebLogic, J2E, SOAP	С помощью централизо­ванного управления (Orchestrator)	Служба Active Directory
Персонал	Пакет	Solaris, Oracle	XMLRPC	В пределах приложения	Из приложения

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

Проблемы конвертирования наследуемых данных

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

Производительность и масштабируемость

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

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

В качестве приблизительной оценки можно использовать утверждение пер­сонала о том, что система загружена на 50-60%, хотя значительные объемы данных в системе нуждаются в конвертации.

В настоящее время в компании используется большое число серверов и программ на базе Microsoft. Однако в некоторых случаях все же возникают про­блемы, связанные с эффективностью и производительностью. На стадии испыта­ний находится новый 64-битовый SQL-сервер, который должен обеспечить по­вышение производительности.

Обновление систем

Для миграции на новую версию программного продукта требуются значительные усилия и затраты, связанные с планированием; кроме того, система длительное время находится в простое. На крупные обновления переходят путем прямого переключения (direct cutover). Например, для недавнего внедрения новой версии потребовалось шесть дней (по плану). Эта реализация системы не содержала компонента для конвертирования данных.

Хотя су шествуют некоторые наработки в подготовке промежуточных патчей, этот процесс пока нельзя назвать зрелым. Чтобы выполнить запрос на изменения вне релиза крупной версии, требуются особые усилия — вот почему этого ста­раются избежать.

Такой перенос также часто осложняется особенностями архитектуры реше­ния и используемых технологий.

Раздел 4.3. Анализ архитектуры реализации сточки зрения концепции TNA NGOSS

В этом разделе дается оценка имеющейся архитектуры с точки зрения при­нципов и правил TNA NGOSS. При этом принимаются во внимание следую­щие принципы NGOSS:

• решения имеют раздельные цепочки бизнес-процессов;

• решения содержат многократно используемые компоненты;

• компоненты имеют четко определенные контрактные интерфейсы;

• решения имеют общий коммуникационный механизм;

• решения реализуются в виде слабо связанных распределенных систем.

Ниже приведен пример комментариев в рамках подобной оценки.

Отделение бизнес-процессов от компонентов

Анализ принципов

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

• повторное использование бизнес-процессов

• многоуровневые бизнес-процессы

• повышенную гибкость

• общую картину бизнес-процессов.

Анализ •

Во многих приложениях бизнес-процессы встроены в отдельные приложе­ния. В частности, приложения X и Y имеют прочно встроенную цепочку процес­сов, причем приложение управляет и пользовательским, и системным интер­фейсом.

Это является нарушением принципов TNA NGOSS и может иметь следующие негативные последствия:

• затруднения в обслуживании бизнес-процесса, его фрагментарный харак­тер;

• трудности, связанные с повторным использованием бизнес-процессов;

• увеличение накладных расходов, вызванных обслуживанием и поддерж­кой бизнес-процессов;

• трудности в связи с интеграцией и многократным использованием компо­нентов.

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

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

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

Выводы

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

Рекомендация 1:

Компании следует выполнить исследование, провести идентификацию, выбрать и реализовать подходящий инструмент централизованного управления (orchest­ration tool), который будет использоваться для описания бизнес-процессов и управления компонентами с помощью этих бизнес-процессов. Этот инструмент должен помочь созданию архитектуры NGOSS, и потому необходимо, чтобы он поддерживал принципы и правила TNA NGOSS.

Рекомендация 2:

Реализация централизованного инструмента управления должна проводиться поэтапно, с учетом возможного развития и тех зон, которые требуют значитель­ных эксплуатационных расходов. То есть этот инструмент нужно использовать таким образом, чтобы получить максимум выгод за минимальное время.

Рекомендация 3:

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

Рекомендация 4:

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

Рекомендация 5:

При выборе этого инструмента можно учитывать и приведенную ниже рекомен­дацию 6.

Аспекты интеграции

Анализ принципов

Решение NGOSS зависит от сервисов, которые поддерживают работу архитекту­ры и механизмов, обеспечивающих взаимодействие компонентов. В рамках NGOSS они определяются как:

• сервисы, обеспечивающие общую структуру;

• сервисы, обеспечивающие структуру OSS;

• базовые, сервисы обеспечивающие структуру;

• базовые механизмы;

• общий коммуникационный механизм;

• механизм вызова.

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

Анализ и рекомендации

В рамках решения существует много разнообразных методов интеграции и об­мена данными. Отсутствие общего коммуникационного механизма не только усложняет архитектуру, но и усиливает отклонения от политик, принципов и стандартов в процессе интеграции.

Рекомендация б:

Настоятельно рекомендуется усовершенствовать коммуникационный механизм в рамках решения (Система Y). Очень важно при этом, чтобы принимались во внимание другие сервисы и механизмы, являющиеся необходимой частью архи­тектуры NGOSS, — в той мере, в какой они могут соответствовать общему ком­муникационному механизму.

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

• чтобы провести необходимые описания, требуются высококвалифициро­ванные специалисты;

• этот процесс отнимает много времени и не позволяет воспользоваться полученными ранее результатами;

• при использовании этого метода описания контрактов происходит значи­тельное число ошибок, а также упускаются скрытые элементы (например, поведенческие характеристики).

Рекомендация 7:

В пределах данного решения описание контрактов необходимо выполнять с помощью шаблона NGOSS TMF053B. Это обеспечит единообразное документи­рование всех характеристик определения интерфейса.

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

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

Следует помнить, что принципы и политики NGOSS не зависят от исполь­зуемых технологий. Их цель — предоставить в распоряжение пользователя лучшие методы, при этом они не имеют чрезмерно инструктивного харак­тера. Следует также подчеркнуть, что мы говорили здесь не просто об ис­пользуемых технологиях, а о том, насколько они соответствуют политикам и стандартам, предлагаемым NGOSS.

[1] Облачные вычисления (англ, cloud computing) — технология распреде­ленной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис. — Прим. ред.

[2] Открытое программное обеспечение — способ разработки ПО, при котором исходный код создаваемых программ открыт и общедоступен для просмо­тра и изменения. — Прим. ред.

Американская компания, которая известна своими автомобилями с аль­тернативными источниками питания. —Прим. ред.

[4] Примерно 4645 кв. м. — Прим. ред.

[5] Термин tryvertising происходит от слов try (попробуй) и advertising (реклама). — Прим. пер.

Тапас — традиционные испанские закуски и блюда, которые подаются маленькими порциями, иногда «на один укус». — Прим. ред.

[6] Концепция «эффективного оператора» применяется в отношении не только операторов связи, но и поставщиков оборудования, системных интеграторов, а также независимых поставщиков программного обеспечения. —Прим. авт.