Думать на правильном уровне - это важно

Руководитель: "Система гибкая, и это хорошо. Система гибкая, и это плохо."

Перевод: "Система даже и близко не делает того, что нужно. Фактически мы не знаем, что она делает."

Вот как Кэвин Бевинс объясняет природу системной гибкости.

Давным-давно, когда Земля была юной и динозавры — ах, пакетная обработка на мэйнфреймах — правили миром, вы выбирали себе основного производителя, обычно IBM или Digital, который и определял вашу техническую архитектуру.

Вся стратегия бизнеса IBM фактически строилась вокруг управления архитектурой. Даже если вы покупали мэйнфрейм Amdahl, контроллеры Memorex и терминалы Telex, компания IBM все равно определяла архитектуру. "Управление технической архитектурой" означает покупку и модернизацию компонентов, запланированных IBM.

Затем IBM опоздала на корабль, уходящий к локальным сетям, или на корабль, может, и не опоздала, да все остальные в это время отправились в аэропорт. SAA потерпела неудачу, и мы заменили свои глобальные сети SNA на TCP/IP. Открытые системы и появление огромного числа производителей предоставили вам возможность самим управлять своей архитектурой. Теперь вы должны сами с ней справляться. Будьте осторожны, когда просите о...

Но вернемся к разработке нашего плана интегрированной информационной системы. План интегрированной ИС, как вы его назовете, состоит из целей компании (Company Goals), технической архитектуры (Technical Architecture) и человеческого фактора (Human Factors). Цели компании мы уже обсуждали (см. выпуск № 4 рубрики "Директору", Computerworld-Россия от 29 сентября 1998 года. — Прим. ред.). В данной статье речь пойдет о технической архитектуре.

Для того чтобы правильно определить техническую архитектуру, надо думать на правильном уровне, а это труднее всего. Техническая архитектура описывает вашу системную среду в терминах функциональных строительных блоков и их взаимодействия, не касаясь конкретных элементов или проводки. "Системы, которые помогают нам управлять своей информацией" — это слишком неопределенно; "Sybase, работающая на зеркалированных серверах AIX" — чересчур подробно, слишком привязано к конкретной технологии.

Что касается управления данными, возможно, вы скажете что-то вроде "мы будем поддерживать РСУБД для мэйнфреймов и распределенную объектно-реляционную базу данных. Мы также будем поддерживать любые другие системы управления данными, встроенные в нашу унаследованную среду, но при этом использовать благоприятные возможности, чтобы настраивать их в соответствии со своей предпочтительной архитектурой. В некоторых случаях мы можем также остановить свой выбор на не удовлетворяющих этим условиям технологиях, встроенных в готовые или пакетные решения".

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

На вашем информационном уровне не принимайте во внимание свои системы управления базами данных. СУБД — это платформа, так же как и другие компоненты аппаратного и программного обеспечения, которые вы используете для создания приложений и управления информацией, — "хостовые" компьютеры, серверы, операционные системы и СУБД, все сетевое оборудование, ваша офисная АТС и программное обеспечение, которое вы используете для управления ими.

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

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