Известно, что аппетит приходит во время еды, причем принцип работает и в других сферах. Это просто объясняется, поскольку каждая новая информация об объекте увеличивает понимание еще о нем неизвестного, этакий аппетит познания...
Но есть и практическая нехорошая сторона сего явления: в процессе эксплуатации системы возникают новые требования к этой системе. Действительно, разумным подходом к проектированию является покрытие текущих потребностей, игнорирование "функционала впрок", однако, в процессе эксплуатации появляется желание получить новые возможности от той же системы, причем, в опоре на принцип, с которого я начал, предвидеть эти желания на этапе проектирования чего-то нового, доселе не используемого, а может, и неизвестного, - было невозможно.
Здорово, если вы - разработчик своей системы, - это позволяет вам самостоятельно управлять своими желаниями, реализуя их в новых релизах своей системы.
Но если вы несофтверная компания, использующая готовые решения на рынке, немудрено упереться в отсутствие функционала в приобретенном вами продукте, в необходимость писать Feature request-ы и годами ждать исполнения ваших желаний, причем без какой-либо гарантии, что а) ваши требования будут исполнены, б) будут исполнены так как нужно вам, а не среднестатистическому потребителю этого продукта.
Отчасти поэтому идея корпоративных облаков плохо приживается на предприятии. Мне самому несколько печально это осознавать, ибо сам являюсь фанатом этой идеи. К сожалению, я не могу предусмотреть весь комплекс "проверок здоровья", которые должен пройти АРМ пользователя, прежде, чем будет безопасно предоставить доступ к тому или иному корпоративному сервису. Особенно сложно, если этот сервис еще отсутствует. Гарантировано, что при попытке реализовать такую инвентаризацию для доступа к какому-либо из своих новых сервисов, я наткнусь на технические ограничения используемой мной системы удаленного доступа (СУД) с NAC-ом внутри или операционной системы на АРМ, и мне надо будет что-то придумывать, или приостанавливать публикацию этого сервиса, пока любимые мною производители СУД и/или клиентской ОС решат мои проблемы.
Другое дело, если я - Гугл, - я использую свои шлюзы СУД, через которые предоставляю доступ к написанным мною сервисам с АРМ внутри которых крутится моя ОС. Я могу проектировать сервисы сразу для работы в "облачном" режиме, а новые "проверки здоровья" в СУД реализовывать самостоятельно, причем в моей клиентской ОС будут заготовлены интерфейсы для удобной и быстрой проверки.
Но выше я сказал, что сам фанат этой идеи, а значит, мне видны горизонты применимости такого подхода к инфраструктуре, построенной на коробках, доступных на рынке с типовыми функциями, покрывающими потребности среднестатистической компании, где ИТ и ИБ не являются коровым бизнесом.... продолжение следует...
Но есть и практическая нехорошая сторона сего явления: в процессе эксплуатации системы возникают новые требования к этой системе. Действительно, разумным подходом к проектированию является покрытие текущих потребностей, игнорирование "функционала впрок", однако, в процессе эксплуатации появляется желание получить новые возможности от той же системы, причем, в опоре на принцип, с которого я начал, предвидеть эти желания на этапе проектирования чего-то нового, доселе не используемого, а может, и неизвестного, - было невозможно.
Здорово, если вы - разработчик своей системы, - это позволяет вам самостоятельно управлять своими желаниями, реализуя их в новых релизах своей системы.
Но если вы несофтверная компания, использующая готовые решения на рынке, немудрено упереться в отсутствие функционала в приобретенном вами продукте, в необходимость писать Feature request-ы и годами ждать исполнения ваших желаний, причем без какой-либо гарантии, что а) ваши требования будут исполнены, б) будут исполнены так как нужно вам, а не среднестатистическому потребителю этого продукта.
Отчасти поэтому идея корпоративных облаков плохо приживается на предприятии. Мне самому несколько печально это осознавать, ибо сам являюсь фанатом этой идеи. К сожалению, я не могу предусмотреть весь комплекс "проверок здоровья", которые должен пройти АРМ пользователя, прежде, чем будет безопасно предоставить доступ к тому или иному корпоративному сервису. Особенно сложно, если этот сервис еще отсутствует. Гарантировано, что при попытке реализовать такую инвентаризацию для доступа к какому-либо из своих новых сервисов, я наткнусь на технические ограничения используемой мной системы удаленного доступа (СУД) с NAC-ом внутри или операционной системы на АРМ, и мне надо будет что-то придумывать, или приостанавливать публикацию этого сервиса, пока любимые мною производители СУД и/или клиентской ОС решат мои проблемы.
Другое дело, если я - Гугл, - я использую свои шлюзы СУД, через которые предоставляю доступ к написанным мною сервисам с АРМ внутри которых крутится моя ОС. Я могу проектировать сервисы сразу для работы в "облачном" режиме, а новые "проверки здоровья" в СУД реализовывать самостоятельно, причем в моей клиентской ОС будут заготовлены интерфейсы для удобной и быстрой проверки.
Но выше я сказал, что сам фанат этой идеи, а значит, мне видны горизонты применимости такого подхода к инфраструктуре, построенной на коробках, доступных на рынке с типовыми функциями, покрывающими потребности среднестатистической компании, где ИТ и ИБ не являются коровым бизнесом.... продолжение следует...
No comments:
Post a Comment