Всем привет!

Данная статья является первой частью моего туториала по разработке достаточно необычного WSGI сервера. В данной статье я поясню теоретическую часть своей задумки.

Основная аудитория — начинающие разработчики, знакомые с Python но желающие познать дзен работы http протокола.

Готовы? Пошли под кат.

Перерыв тонны материала по текущему видению интернета вещей, сделал вывод — мы пытаемся объять необъятное. Авторитетные компании изобретают новые технологии коммуникаций, стандарты передачи данных, операционные системы и “железо” для умных устройств, забывая о первоначальной цели — о конечном потребителе. А наиболее прибыльным конечным потребителем является не “гик”, умеющий за час собрать умный чайник на новомодной платформе стоимостью >200$, а рядовой обыватель с довольно простыми потребностями:

1. Контроль;
2. Получение оперативной информации;
3. Аналитика.

При этом устройства из мира интернета вещей должны быть:

1. Максимально дешевыми;
2. Максимально автономными;
3. Простыми в развертывании и использовании;

Цель статьи — обозначить функциональные границы решения инфраструктуры интернета вещей в рамках текущих технических возможностей и согласно текущих потребностей конечного потребителя.

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

• Бизнес, который ставит целью извлечь максимальную выгоду от внедряемой автоматизации;
• Подрядчик, цель которого извлечь материальную выгоду от внедрения;
• Собственная команда разработки заказчика, которая стремится к минимизации трудозатрат и ответственности;
• Конечные потребители системы, которые имеют потребность защиты от изменений.

И разность целей зачастую приводит к несостоятельности продукта, «сваренного» в данном котелке противоречивых идей.
В данной статье на наглядном примере рассмотрим негативные процессы, к которым приводит противоречивость целей. Рассматриваемый в нашем кейсе проект – внедрение ERP системы.

Всем привет.
Цель данной статьи: презентовать одну из накопившихся в моем сознании идей и протестировать ее на живучесть. Знаете, как в гибких методологиях – делают прототип и показывают его заказчику. Я решил поступить схожим образом, а именно: взял ключевой функционал и описал его в виде пользовательской истории.

Перед презентацией продукта необходимо описать предметную область.
Свой продукт позиционирую как инструмент для «инкубации» идей. В последнее время стало модным понятие «инкубатора стартапов», но что делать тем, кто еще не дорос от идеи до стадии стартапа? В связи с этим у меня родилось предположение – многие идеи умирают, оставаясь без поддержки сильной команды. Задача понятна, проблема обрисована.

Для первой итерации я предлагаю инструмент для инкубации идей и поиска персонала, который в дальнейшем может вырасти до полноценного сервиса, предлагающего следующий ряд услуг:
1) Бизнес и системный анализ идеи;
2) HR менеджмент и поиск персонала для стартапа.
3) Поиск интересных проектов для соискателя.

Заранее прошу прошения за краткий и не очень полезный топик, но пришло время хотя-бы для себя расставить точки над И.
На данный момент работаю в проекте интеграции известной и мега дорогой ERP системы в текущий информационный ландшафт предприятия. Помимо сжатых сроков, отсутствия компетентных консультантов, а в следствии качественной документации и общего виденья системы у нас возникает ряд серьезных трудностей.
Основная проблема заключается в том, что время когда подрядчик с красивой улыбкой рассказывал как замечательно влезают все наши процессы в их систему прошло. Теперь же идет ожесточенная борьба за место под солнцем, а именно — кто должен делать автоматизацию, того что нет в их системах. Начинаются серьезные бои за покупку новых модулей, которые не были предусмотрены бюджетом, но без которых нам будет очень плохо.
Одна из причин такого коллапса — со стороны предприятия не было эксперта по данным системам, который на начальной стадии проекта мог бы спустить с небес на землю ошарашенных великими возможностями системы пользователей и сказать свое фэ некоторым обещаниям подрядчика.
Если у кого был крупный проект внедрения ERP системы, прошу под кат ответить на несколько вопросов.

Скажу сразу – я начинающий архитектор, который переучивается данному ремеслу с системного администрирования.

В данной статье не будет рассуждений на следующие тематики:

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

Вводную часть начну с моего ограниченного понимания места архитектора в крупной компании.

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