ИТ: легче на поворотах
все японские банки брали с кли-
ентов комиссионные за пользова-
ние банкоматами — как своими,
так и чужими. Банкоматы стояли
в отделениях и доступны были толы
ко в часы работы банка. В $Ып$е
1
хотели, чтобы люди могли снимать
деньги или совершать другие опе-
рации бесплатно и круглосуточно,
но понимали, что при традицион-
ной сетевой архитектуре — вроде
той, что построили у себя конку-
ренты, этого не достичь. Собрали
проектную группу из сотрудников
бизнес- и И Г-подразделений. Они
подробно определили, что банк
хочет предложить клиентам, пос-
ле чего разбили задачу на макси-
мально простые составные части.
Это позволило найти новые более
эффективные решения. К примеру,
в
обычно банкоматы соединялись
с системами бэк-офиса специальны-
ми дорогостоящими каналами. Но
ведь с тем же успехом в этих целях
можно пользоваться и интернетом.
Конечно, интернет-канал был не
так надежен, как специальная ли-
ния, однако разработчики нашли
простой выход из ситуации: сделать
систему с двумя подключениями
к интернету, которые обслуживают-
ся двумя разными провайдерами.
При сбое одного канала происхо-
дит автоматическое переключение
на другой. Эта система оказалась
надежнее, чем действующая в боль-
шинстве банков, да и стоила она
в десять раз дешевле. Новый метод
работы позволил $Ып$е
1
создать
сеть круглосуточных банкоматов,
которые предоставляли более ши-
рокий набор услуг, чем банкома-
ты конкурентов, и брали гораздо
меньшие комиссионные.
Другой пример поразительно
простого решения этой же коман-
ды — способ предотвращать сбои,
возникающие из-за утечки памяти.
Утечка может произойти в любой
операционной системе, если при-
ложение после завершения задачи
не высвобождает память. Когда сво-
бодной памяти становится слишком
мало, система теряет стабильность
и может аварийно завершить ра-
боту. Для защиты обычно разра-
батывают отладчики и сложные
средства управления памятью, но
они не лают стопроцентной гаран-
тии. И БНіпвеї не стали бороться
с утечкой памяти, а просто запрог-
раммировали систему на частые
перезагрузки — это было хотя
и топорное, но эффективное и не-
дорогое решение.
О
каком бы компоненте — раз-
работанном своими силами или
полученном от внешнего постав-
щика — ни шла речь, одним из
главных требований, которые пе-
ред программистами ставил Двн-
веди, была возможность повторно
использовать его в других проектах
БЫпзег Разработчики подробно
описывали назначение каждого
модуля и обеспечивали ему стан-
дартный интерфейс, который де-
лал модуль совместимым с любой
существующей или будущей про-
граммой. К примеру, менеджеры
и ИТ-специалисты банка быстро по-
няли, что для целого ряда банков-
ских услуг необходимо проверять
кредитоспособность клиента. По-
этому было решено создал» единый
модуль проверки. В целом свыше
90% программных компонентов
БЫп$е
1
применяется более чем
в одном месте ИТ-системы.
Планируя ИТ-проект, важно
во главу угла ставить цели
ближайш его будущ его.
Последовательность модульно-
го принципа. Все вроде бы знают,
что компьютерные программы
н ИТ-системы должны состоял» из
модулей, но саму идею модульнос-
ти часто понимают неверно. Даже
если разработчик утверждает, что
отдельные части его программы —
модули, приложение не становится
от этого модульным. Необходимо
четко разграничивать интерфейсы,
тогда, разрабатывая или дорабаты-
вая один модуль, вы не затрагиваете
другие. Проектируя корпоратив-
ные системы, это часто упускают
из виду. К примеру, в одной авто-
мобильной компании несколько
команд программировали разные
модули — считалось, что все вместе
они создают модульную систему.
Но одна из этих групп занималась
только интерфейсами и постоянно
в них что-то меняла. После каждого
усовершенствования всем опаль-
ным приходилось тратить уйму
времени на то, чтобы переделывать
уже сделанное. Вместо того чтобы
предотвращать эффект карточного
домика в своей системе, компания
его всякий раз вызывала.
При настоящей модульной ар-
хитектуре программисты могут
решать локальные задачи, не за-
трагивая [заботу целого. Если инфра-
структура состоит из небольших бло-
ков, то развивать ее гораздо проще:
в нее можно быстро встроить стан-
дартное решение или новый компо-
нент, созданный своими или сторон-
ними программистами, и ставить
новые версии отдельных модулей,
когда система уже функционирует.
Метод, при котором проблему ре-
шают, разбивая на части, не только
ускоряет работу. Он позволяет вы-
брать наименее затратный вариант
для каждой подзадачи и ослабить
воздействие сбоев в отдельных мо-
дулях на всю систему. Кроме того,
когда четко определены функции
конкретных модулей и интерфей-
сов, проще разрабатывать ком-
поненты, которые подходили бы
и для других приложений.
112
Harvard Business Review
Россия
Сентябрь 2008 I hbr-russia.ru
предыдущая страница 115 Harvard Business Review Russian 2008.10 читать онлайн следующая страница 117 Harvard Business Review Russian 2008.10 читать онлайн Домой Выключить/включить текст