Pull to refresh

Comments 8

UFO just landed and posted this here
Я как раз старался ответить на вопрос о массовой разработке софта по SaaS модели — это когда SaaS-сервисы будет делаться также массово как сейчас сайты или десктопные приложения.
И конкретно хотел сосредоточился на проблемах, которые ждут разработчиков — web-студии, в этом сегменте. Т.е. чтобы правильно оценили ожидающие их бизнес-риски.
UFO just landed and posted this here
Почему же я путаю? Я реально понимаю что такое SaaS-модель распространения программного обеспечения и никак не привязываю ее только к сайтам и порталам и только к вебу.
Ключевое слово — «модель». Соответственно, не совсем корректно название статьи. Статья не отвечает ни на какой вопрос, поскольку сам вопрос поставлен не верно.

SaaS нельзя заниматься, SaaS можно применять к тому или иному продукту.
Ту или иную модель доставки и оплаты ПО можно либо использовать, либо нет. И зависит это прежде всего от продаваемого продукта, а не от рынка, на котором он продается.

Поскольку модель эта новая, появились новые продукты, которые ранее просто не могли появиться. Они стали популярны и всем стало интересно модное слово SaaS. Зачастую, люди путают причинно-следственную связь, тянутся за модным трендом и пытаются использовать данную модель там, где она не нужна. Автор пытался объяснить, почему по SaaS -модели не предоставляются продукты, которые предоставляются по-другим моделям, и сделал вывод, что это рынок не готов. А дело не в рынке, а в продуктах.
бизнеса СНГ еще не готов отдать «куда-то, кому-то» коммерческие данные

Есть варианты, что готов, в частности в областях где автоматизация чаще всего ограничивается таблицами в Exel и документами в Word, максимум БизнесПак. Но возникает проблема, что может не иметь права отдавать эти данные, так как они ещё и персональные данные клиентов. И он, как минимум, должен получить согласие клиентов на обработку ПДн третьим лицом, ИП Чернышев В. М, например :). И если бизнес мне доверяет, хотя бы потому, что я несу перед ним ответственность всем своим имуществом, то с клиентами проблематично. Про то, что я свой сервис должен сертифицировать по куда большей степени защиты в силу и большего числа субъектов ПДн, и большей географической распространенности, чем мои клиенты, и сам выступать оператором персональных данных, вообще молчу. Куда проще внедрять «коробочные» интранет-решения, предоставляя софт и его поддержку, а не софт-как-сервис.
По поводу персональных данных — есть риски из-за не проработанности законодательства.
Но если ваш сервис предоставляет услуги, скажем бинарной обработки данных — т.е. данные не предоставляются как БД (закон распространяется только на персональные данные в виде БД), а как поток бинарных данных, то эта проблема отпадает. Есть соглашение, не помню ссылки, но есть, которое исключает провайдеров, операторов почтовых сервисов, сервис Whois из под действия данного законодательства.
Может где-то сработает, но суть системы учёта как раз в базе данных. А юридическое определение базы данных несколько отличается от привычного в технической среде. Грубо говоря, файл data.sqlite.gpg, хранящийся на сервере и синхронизируемый между клиентами а-ля ДропБокс для нас просто бинарный файл, а для надзорных и контролирующих органов — это база данных с не сертифицированной криптографической защитой. Да и вообще суть SaaS тогда нивелируется до автоматического предоставления клиента и зеркалирования (с блокировками) бинарных данных, с которыми клиент работает как с БД, а планировался именно как frontend. Да и вообще неясно, может ли это быть реализовано в рамках обычного браузера. Были идеи типа использовать localStorage для хранения данных и WebSoket на сервере для синхронизации, но ни до чего хорошего не додумались, чтоб не нарушать закона.
Sign up to leave a comment.

Articles