Да, подход, конечно, сервисный. Мы предоставляли свои знания, опыт и компетенцию в виде сервиса. И конечно, нам сказали «хотим Warehousing».
Насчет дальнейшего — все было не совсем так :) Не было со стороны заказчика ни планирования, ни аналитиков. Выше уже описал, скопирую сюда тоже:
Просто в проекте который достался нам, ТЗ не было. И представители заказчика считали что оно и не нужно. Аджайл же. Естественно, в начале мы завели разговор о ТЗ, но проанализировав структуру команд и уровень компетенции в команде заказчиков, поняли что ТЗ ждать просто не от кого.
В результате мы максимально тщательно постарались уяснить себе желаемый результат, изучили систему и архитектурные решения системы, разработали требуемую архитектуру, составили план работ и приступили, собственно, к работам.
Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
Agile и ТЗ — богатая тема :) Можно смело писать отдельную статью-холивар :) Лично я не считаю что Agile ИСКЛЮЧАЕТ ТЗ. Не думаю что и заказчик занимал какую-то суровую позицию по поводу ТЗ в Аджайле. Просто в проекте который достался нам, ТЗ не было. И представители заказчика считали что оно и не нужно. Аджайл же. Естественно, в начале мы завели разговор о ТЗ, но проанализировав структуру команд и уровень компетенции в команде заказчиков, поняли что ТЗ ждать просто не от кого.
В результате мы максимально тщательно постарались уяснить себе желаемый результат, изучили систему и архитектурные решения системы, разработали требуемую архитектуру, составили план работ и приступили, собственно, к работам.
Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
Прекрасное продолжение прекрасной темы, спасибо. Из опыта моей компании могу сказать что нам удавалось построить работу без ТЗ таким образом, что все в итоге остались довольны. Сразу скажу, что клиент, взятый в качестве примера — это не мелекий стартап, а огромная немецкая(!) компания, старающаяся внедрять у себя принципы Agile-thinking, которые в понимании компании-заказчика делают ТЗ не только ненужным, но и вредным. Проект был суровым энтерпрайсом — Data Warehousing, ETL, MDM и Metadata. Т.е. области, в которых наличие не просто ТЗ, но детального системного анализа считается необходимым.
Решение было очень простым — чистый time&materials, почасовая ставка (близкая к потолочной, но без всякого умножения на три). Разумеется, люди которые работали на клиента были весьма опытными разработчиками, полностью готовыми к ситуации и относились к изменениям генеральной линии как к «любой каприз за ваши деньги».
Все закончилось хорошо :) Справедливости ради надо сказать что проект здорово облегчала рабочая атмосфера и философия клиента ( все крайне спокойно, никакого прессинга ), а так же тот факт, что суть проекта предполагала работу в основном на уровне архитектуры системы, без глубокого погружения в бизнес-логику.
Хорошая статья, радует трезвый подход к созданию мобильных приложений — я в последние годы продвигаю ровно такую же идеологию в своих проектах. Вдобавок к перечисленным преимуществам гибридной унифицированной разработки, добавлю еще значительный cost cut и как следствие — серьезное снижение общей стоимости владения.
Но самое интересное в другом. Вы упомянули Bootstrap. Который я могу скачать и использовать в своих проектах. В вашей статье рассказано какие вы молодцы, потому что сделали UI Kit и разрабатываете на его основе. Наверняка большинству прочитавших очень интересно, дадите ли вы комьюнити свой UI Kit, как Твиттер дал Bootstrap, и если да — то когда это случится?
Спасибо за лестный отзыв! По поводу второго поста скажу следующее:
1. Панацеи абсолютно от всех бед и болезней не существует и не может существовать в принципе. Мы лишь выбираем инструмент для наведения порядка в отдельно взятом учреждении, использующим нашу систему. Все, чего мы хотим добиться — избавить клиента от страха что скоро все упадет и дать ему возможность без осложнений развивать новые финансовые сервисы и продукты.
2. Цитата содержит много причитаний, и вздохов по старым добрым временам, но при этом не оперирует фактами. Факты же заключаются в регулятивных требованиях к банку, которые четко прописаны в условиях получения лицензии. Выше я немного написал о Capital Adequacy Ratio. Если есть интерес к теме — можно ознакомиться с подробностями, начиная с википедии.
Как человек, работавший и в качестве разработчика, и в качестве члена менеджмент борда финансовых организаций, могу вас заверить что написать доступным книгу о произволе и вседозволенности банков — хороший способ сделать себе имя среди обывателей и заработать денег. Однако в реальности банкам живется вовсе не так сладко — за их финансовыми показателями пристально следят регуляторы, и создавать деньги из воздуха раздавая их направо и налево им не позволяют. Возможно об этом тоже стоит написать статью — я вижу что вырисовался очередной стереотип :)
Замечательный эксперимент, делающий честь любому гику! На мой взгляд будущее носимых устройств в целом связанно именно с такими гаджетами, считывающими электрические потенциалы с мышц.
Одна из причин, почему Google Glass застопорился — человек чувствует себя идиотом, когда ему приходится разговаривать с очками. И он прав — в компании других людей это действительно выглядит, мягко говоря, странно. В паре же с Myo и подобными датчиками, он может взаимодействовать с носимыми устройствами без голоса, что действительно делает их подобием продолжения человека.
Именно об этом я и говорю. В HFT ( а это, кстати, не только роботы, но и биржи, и агрегаторы ликвидности) во главе угла — скорость, и никто не будет тратить машинное время на реализацию general ledger. Поэтому и архитектуры — совершенно другие.
Так и есть — для репортов реального времени, реализации бизнес-продуктов вроде кредитов и многих других кейсов — это скорее плюс по производительности. Так что наша система будет быстрее чем подавляющее большинство существующих. Но там где требуется действительно высокая скорость — например при том же HFT — разумно использовать архитектуру, где во главе угла скорость, а не надежность. Но никто не мешает в масштабах всей системы использовать ее в связке с архитектурным слоем, имеющим двойную запись.
Когда лежит почта — все конечно бегают и ругаются, кричат о том что бизнес параллизован и.т.п. Но при этом катастрофы, как правило, не случается. Когда сбой дает торговый сервер — катастрофа вполне реальна — например, не закрытая вовремя позиция может причинить убытки на многие сотни тысяч долларов.
Разумеется мы не претендуем на то что первые это придумали. Скорре мы хотим собрать все здравые и полезные идеи в продукт, который позволит бизнесу нормально работать и развиваться. Отсюда и упор прежде всего на надежность и 24/7. Так что наше ядро — вполне себе Oracle + Java. C развитием продукта подумываем о реализации лайт-верии на open-source стеке, но на сегодняшний день наиболее эффективна реализация на оракловском стеке.
Вам не кажется, что компании бывают разные — и по сфере деятельности, и по бизнес-модели? В готовке лапши можно и совсем без IT — главное чтобы лапша была вкусной. Современный же банк — это в очень значительной мере его IT. Если брать упомянутый выше HFT — то это уже IT на все 90%.
Кроме того, если ошибка одного программиста может привести к краху и банкротству финансового учреждения — как тогда вы будете измерять вклад IT?
Нет. Описаный вами механизм можно было бы рассматривать в случае организации failover, либо для масштабирования. Множественные базы мы не рассматриваем сейчас вообще.
У нас суть в том что само состояни счета имеет дебет и кредит. Т.е. это не просто некая величина в единственном поле. Соотвественно к этому подходу в полной мере применяются принципы бухгалтерского учета и двойной записи.
Возможно мне надо было провести четкое разделение терминов. Ведь транзакция в базе данных и бухгалтерская транзакция — совсем не одно и то же. В статье идет речь о пользе реализации последних.
Верно. В общем и целом — чем серьезнее и крупнее банк — тем больше будут убытки в случае падения, и соответственно — тем большее внимание он уделяет качеству и надежности.
Иногда это приводит к прямо противоположному эффекту — банк настолько дорожит стабильностью, что превращается окаменелость. Например, OLTP написан на COBOL в 80х, крутится на мейнфрейме. Изменения в нее вносятся очень редко и неохотно. В таких банках если уж случается проблема — то банк может стать на пару суток. Не в последнюю очередь потому что разбираться с проблемой попросту некому — COBOL сейчас мало кто знает, а уж что и как происходит в ядре — и вовсе сакральное знание.
А вообще вся статья о том что надежность финансовых учреждений с технической стороны — куда ниже чем принято думать.
Не вижу разницы. Компания — это не в последнюю очередь — люди, которые в них работают. И если программисты, аналитики и архитекторы не смогли выстроить надежную систему — ощущать это будет вся компания. В итоге именно у компании будут проблемы, а не у программистов.
Спасибо за интерес! Проблем в отрасли хватает, и лучшим ответом тут будут, пожалуй, отдельные статьи. Например эта посвящена одной из конкретных проблем. Но базируется она, на мой взгляд, на более фундаментальной проблеме, а именно — у большинства разработчиков довольно узкий кругозор. И вследствие отсутствия знаний в смежных дисциплинах ( математика, экономика, логистика ) — конечные решения страдают теми проблемами, которые в отдельных отраслях были решены порой многие века назад.
Этому пороку может быть подвержен и архитектор, и его Steering Committee — организация, акцептирующая изменения в крупных банках. Т.е если в процессе своего карьерного роста от разработчика до архитектора последний не интересовался предметной областью — он не увидит в рассматриваемой реализации ничего крамольного.
Относительно VoltDB — я рассматривал ее для одного проекта, но больше из академического интереса. Основной причиной, по которой VoltDB едва ли в самое ближайшее время получит широкое распространение в финансовом секторе — ее относительная новизна и недостаточный уровень поддержки и тестирования совместимости. Поэтому для процессинга — ни один здравомыслящий технический директор взять ее не рискнет. Т.к. для этих задач ORACLE предоставляет несравненно более высокий уровень надежности, гораздо более мощные средства разработки, а преимущества в скорости процессинга — во-первых неочевидны, т.к. в случае bulk-операций ORACLE порой выигрывает, во-вторых, почти всегда могут быть решены масштабированием того же ORACLE — решения.
Исключением могут быть проекты, где не критична высокая надежность ( есть и такие ). Но и в этом случае я выбрал Redis. Не исключено, что с развитием этой базы ситуация изменится.
Концепция близка к event sourcing, но все же не сказал бы что это он в чистом виде. У нас general ledger система — концепция куда более старая чем event sourcing, но так и не ставшая модной по причине того, что программисты как правило ничего не знают о принципах учета. Хотя по-хорошему, должны были бы, т.к. это серьезно повысило бы качество разработки во множестве приложений.
Наша система не несет никакого ультра-нового решения, которое мы сами изобрели — на это мы не претендуем. Задача которую мы перед собой ставим — собрать подходящие концепции и реализовать на их основе решение, которое будет работать в первую очередь надежно, стабильно и с хорошей для большинства задач скоростью.
Насчет дальнейшего — все было не совсем так :) Не было со стороны заказчика ни планирования, ни аналитиков. Выше уже описал, скопирую сюда тоже:
В результате мы максимально тщательно постарались уяснить себе желаемый результат, изучили систему и архитектурные решения системы, разработали требуемую архитектуру, составили план работ и приступили, собственно, к работам.
Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
Решение было очень простым — чистый time&materials, почасовая ставка (близкая к потолочной, но без всякого умножения на три). Разумеется, люди которые работали на клиента были весьма опытными разработчиками, полностью готовыми к ситуации и относились к изменениям генеральной линии как к «любой каприз за ваши деньги».
Все закончилось хорошо :) Справедливости ради надо сказать что проект здорово облегчала рабочая атмосфера и философия клиента ( все крайне спокойно, никакого прессинга ), а так же тот факт, что суть проекта предполагала работу в основном на уровне архитектуры системы, без глубокого погружения в бизнес-логику.
Но самое интересное в другом. Вы упомянули Bootstrap. Который я могу скачать и использовать в своих проектах. В вашей статье рассказано какие вы молодцы, потому что сделали UI Kit и разрабатываете на его основе. Наверняка большинству прочитавших очень интересно, дадите ли вы комьюнити свой UI Kit, как Твиттер дал Bootstrap, и если да — то когда это случится?
1. Панацеи абсолютно от всех бед и болезней не существует и не может существовать в принципе. Мы лишь выбираем инструмент для наведения порядка в отдельно взятом учреждении, использующим нашу систему. Все, чего мы хотим добиться — избавить клиента от страха что скоро все упадет и дать ему возможность без осложнений развивать новые финансовые сервисы и продукты.
2. Цитата содержит много причитаний, и вздохов по старым добрым временам, но при этом не оперирует фактами. Факты же заключаются в регулятивных требованиях к банку, которые четко прописаны в условиях получения лицензии. Выше я немного написал о Capital Adequacy Ratio. Если есть интерес к теме — можно ознакомиться с подробностями, начиная с википедии.
Как человек, работавший и в качестве разработчика, и в качестве члена менеджмент борда финансовых организаций, могу вас заверить что написать доступным книгу о произволе и вседозволенности банков — хороший способ сделать себе имя среди обывателей и заработать денег. Однако в реальности банкам живется вовсе не так сладко — за их финансовыми показателями пристально следят регуляторы, и создавать деньги из воздуха раздавая их направо и налево им не позволяют. Возможно об этом тоже стоит написать статью — я вижу что вырисовался очередной стереотип :)
Одна из причин, почему Google Glass застопорился — человек чувствует себя идиотом, когда ему приходится разговаривать с очками. И он прав — в компании других людей это действительно выглядит, мягко говоря, странно. В паре же с Myo и подобными датчиками, он может взаимодействовать с носимыми устройствами без голоса, что действительно делает их подобием продолжения человека.
Кроме того, если ошибка одного программиста может привести к краху и банкротству финансового учреждения — как тогда вы будете измерять вклад IT?
У нас суть в том что само состояни счета имеет дебет и кредит. Т.е. это не просто некая величина в единственном поле. Соотвественно к этому подходу в полной мере применяются принципы бухгалтерского учета и двойной записи.
Возможно мне надо было провести четкое разделение терминов. Ведь транзакция в базе данных и бухгалтерская транзакция — совсем не одно и то же. В статье идет речь о пользе реализации последних.
Иногда это приводит к прямо противоположному эффекту — банк настолько дорожит стабильностью, что превращается окаменелость. Например, OLTP написан на COBOL в 80х, крутится на мейнфрейме. Изменения в нее вносятся очень редко и неохотно. В таких банках если уж случается проблема — то банк может стать на пару суток. Не в последнюю очередь потому что разбираться с проблемой попросту некому — COBOL сейчас мало кто знает, а уж что и как происходит в ядре — и вовсе сакральное знание.
А вообще вся статья о том что надежность финансовых учреждений с технической стороны — куда ниже чем принято думать.
Этому пороку может быть подвержен и архитектор, и его Steering Committee — организация, акцептирующая изменения в крупных банках. Т.е если в процессе своего карьерного роста от разработчика до архитектора последний не интересовался предметной областью — он не увидит в рассматриваемой реализации ничего крамольного.
Относительно VoltDB — я рассматривал ее для одного проекта, но больше из академического интереса. Основной причиной, по которой VoltDB едва ли в самое ближайшее время получит широкое распространение в финансовом секторе — ее относительная новизна и недостаточный уровень поддержки и тестирования совместимости. Поэтому для процессинга — ни один здравомыслящий технический директор взять ее не рискнет. Т.к. для этих задач ORACLE предоставляет несравненно более высокий уровень надежности, гораздо более мощные средства разработки, а преимущества в скорости процессинга — во-первых неочевидны, т.к. в случае bulk-операций ORACLE порой выигрывает, во-вторых, почти всегда могут быть решены масштабированием того же ORACLE — решения.
Исключением могут быть проекты, где не критична высокая надежность ( есть и такие ). Но и в этом случае я выбрал Redis. Не исключено, что с развитием этой базы ситуация изменится.
Наша система не несет никакого ультра-нового решения, которое мы сами изобрели — на это мы не претендуем. Задача которую мы перед собой ставим — собрать подходящие концепции и реализовать на их основе решение, которое будет работать в первую очередь надежно, стабильно и с хорошей для большинства задач скоростью.