IT-встречи в Таллине (на русском)

case-study. В шкуре архитектора.

Игорь Меньков предложил кейс, который позволит немного размять мозги 🙂 Как раз для настоящих джедаев!

Так вот: Клиенту требуется система, которая будет обрабатывать различные документы, связанные с бизнес процессами. Все формы документов должны быть доступны работникам компании из любой точки мира в любой момент времени.

Формы документов могут со временем меняться:
·         содержание форм
·         бизнес логика
·         валидации

При заполнении и обработке документов используются вспомогательные данные:
·         Классификаторы
·         Дополнительные данные для бизнес логики

Вспомогательные данные также могут со временем меняться.

При изменении формы документа или вспомогательных данных, указывается, действуют ли эти изменения также на уже существующие документы, или только на вновь созданные.

Задачка (предварительно надеть шляпу архитектора):

1. Какую платформу можно использовать для разработки данной системы?
2. Какие будет общий технический дизайн (на уровне шаблонов проектирования) реализации требований, приведенных в данном описании?
3. Какая должна быть команда, которая будет работать над проектом?
4. В чем должна быть ваша роль, как архитектора в этом проекте? Или ее отсутствие с обоснованием.
5. Какие будут затраты на поддержку системы после ее внедрения?

Дополнительная информация:
1. Задача является абстрактной.
2. Каждый участник может задать один дополнительный вопрос здесь в посте.
3. Уровень детализации решения каждый участник задает для себя сам. При желании, можно обосновать почему был выбран именно такой уровень детализации.

Дерзайте! Как водится у нас, лучшему ответу придумаем какой-нибудь приятный бонус! Ну и место в первом ряду на предстоящей встрече 🙂 Ответы сюда или на мейл Igor тчк Menkov [a] helmes.ee

Назад

Devclub 29.09.09 — для затравки :)

Далее

О мотивации

19 комментариев

  1. «должны быть доступны из любой точки мира в любой момент времени», мне кажется — совершенно надуманное и незначительное требование, которым стоит пренебречь в данном случае.
    иначе ничего кроме web-интерфейса не получите.

    • +1.

      ниже, правда, есть пометка, что мол задача абстрактная

    • Игорь Меньков

      Не все так однозначно. 🙂 Web-технологии бывают разные. Плюс, не забываем про возможность работы в offline mode на толстом клиенте. Хотя в целом, да требование незначительное.

  2. а ещё можно было бы уточнить, какого рода бизнес-процессы предполагаются

    • Игорь Меньков

      Бизнесс-процессы сильной роли не играют, но для чистоты эксперемента предложу такой вариант:
      поскольку речь все же идет о документах, то автоматическое заполнение(вычисление) отдельных частей документа, используя дополнительные данные.

  3. Я думаю что для этого подойдёт Microsoft SharePoint.
    Архитектора я вижу как Lead Programmer.

    На J2EE можно тоже самое сделать но больше времени на разработку пойдёт, но обслуживание будет дешевле.

    А доступность в любой точки мира – это веб Interface может быть с Java-Applet-ом.

    Хотя может быть всё и не так 🙂

  4. Juri Mulenko

    если документ понятие нечто абстрактное — т.е. не является эксель\ворд документом, а скорее набором полей, формул расчета и т.д.(условно назовем метаданными), то от шарика толку мало. я конечно не знаток его. но кажется мне что как MOSS так и WSS позволяют работать исключительно с Office документами. Используя его мы только загоняем себя в более строгие рамки. Плюс вопрос лицензирования клиентов, не совсем уверен что Sharepoint как платформа то что нужно. Новые клиенты = новые лицензии.
    У меня вот конкертный вопрос — «документом» является таки офисный файл, или это все таки то что я описал выше(метаданные)

  5. Игорь, уточните пожалуйста утверждение «могут со временем меняться», особенно в контексте валидаций и бизнес-логики. Кто конкретно будет отвечать за отражение в инфосистеме происходящих в реальном мире изменений сущностей и правил: её конечные пользователи (некие power users, пусть даже со специальным обучением и правами) или же команда разработчиков в рамках работ по дальнейшему развитию и поддержки?

    И, поскольку можно задать только один вопрос, пишу вопрос который может быть задаст кто-то другой: Игорь, вы упоминаете «бизнес-логику» как часть форм документов и «дополнительные элементы бизнес-логики» как часть вспомогательных данных. Между этими сущностями есть некое конкретное принципиальное различие, или же вы так хотите сказать, что «абсолютно любая часть инфосистемы может измениться в течение её срока жизни»?

    Спасибо!

    • Игорь Меньков

      Давно ждал этого вопроса. 🙂 “Могут со временем меняться” для меня в данном задании ключевое требование для «поскрипеть мозгами». Пока что, в присланных решениях этот вопрос не был технически подробно описан, хотя большой проблемы это не составит — решение будет оцениваться в целом, это только один из ньюансов.

      Итак, “могут со временем меняться” означает, что de facto изменения будут. Как часто, зависит от бизнеса клиента и изменениях в бизнесе, которым он занимается. Вообщем, you never known.

      Соответсвенно, будет ли строится система умеющая все (и тогда хотелось бы знать как) или ее будет поддерживать команда разработчиков (и тогда хотелось бы знать сколько) — это выбор ваш, как архитектора.

      Второй вопрос:
      Предполагается, что бизнес-логика будет использовать впомогательные данные. Причем как бизнес-логика, так и вспомогательные данные могут менятся со временем. Как пример:
      в бизнес-логике прописано правило как по вводимым в документ параметрам высчитать некий
      результат и записать его в определенную часть документа.

      Что может поменяться:
      1. Само правило — какие параметры брать, куда записать результат (форма ведь тоже может поменяться)
      2. Дополнительные данные, т.е. данные напрямую влияющие на высчитиваемый результат.
      3. Правило может с какого-то момента больше не действовать.
      4. И т.д.

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

      Т.е. “абсолютно любая часть инфосистемы может измениться в течение её срока жизни” скорее верно, чем нет. Но! Оцениваться все же будет рациональный подход к решению задачи. 🙂

  6. Ну если документ представить как обычную Application с TextBox-ми + какой-то Template для отображения. И хранить только основную информацию важную для отображения формы и для бизнес логики.
    А любой документ можно представить как Word, но нужно ли это, зависит от того что это за документ и как он будет использоваться, а писать что-то с расчётом на будущее очень сложно так как угадать нельзя.
    «При изменении формы документа или вспомогательных данных, указывается, действуют ли эти изменения также на уже существующие документы, или только на вновь созданные.» — Это я думаю делаеться как версия документа с документом сохраняеться версия его и гдето в базе храниться Template для него и каждый новый документ наследует старый Template+ новые навороты, получаеться обычный OOP.

    • Juri Mulenko

      С версионированием понятно. да без него никак, тут вопрос сугубо технический и имеет несколько вариантов решения.
      Я думаю выражу большинство невысказанных мнений:
      — Наиболее интересную проблему поднял Захар с точки зрения расширяемости — конечные user’ы должны иметь возможность относительно небольшими усилиями менять логику(все судорожно насилують гугль на предмет BRMS), представление и т.д.
      — С технической точки зрения тут интересно как будет выглядеть связь м-у логикой(расширямой!) , представлением(расширяемым!!) и хранением(расширяемым!!!).
      — В конечном варианте безусловно выиграет тендер тот, кто сумеет предложить решение, позволяющее реализовать больший функционал за меньшее кол-во затрат.
      — И ежу понятно, что писать с нуля используя програмную платформу(J2EE, .NET, LAMP, ROR), пусть даже с кучей дополнительных библиотек — верный проигрыш, хотя с технической точки зрения — это безусловно интересно.
      — Задача скорее на опыт и знание. Надо провести ресёрч — что есть на рынке. Зуб даю такие платформы есть, со своим скриптовым языком, или редактором правил, базой, секурити и т.д. SAP, Axapta, 1C — в них в каждом должны быть модули отвечаюшие за документооборот. Кто в этом соку варился, ау? Дайте знать если есть что подходящее 🙂
      — Я не совсем понимаю что значит «абстрактная задача». С одной стороны архитектор должен обеспечить приемлимый технический уровень решения. С другой стороны — пренебрегать финансовой стороной вопроса тоже нельзя. Надо «посадить» клиента иглу(по мотивам речи Захара), да так, чтоб он сам подставил вену.

      • Игорь Меньков

        Захару в очередной раз respect, копает глубоко.

        По поводу того подойти к этой задаче технически или экономически — это, IMHO, определяет в какую сторону движется человек (geek vs manager). Прием именно в том случае, если выбранное решение ему интересно решать именно в этот контексте. Хотя это безусловно не является аксиомой. Сделал такой вывод опираясь ислючительно на свой опыт.

        «Я не совсем понимаю что значит “абстрактная задача”».
        Абстрактная, т.к. это некая компиляция из втречавшихся мне требований при разработке разных систем. Т.е. абстракность задачи заключается в том, что я не пытаюсь с помощью devclub’а выиграть некий тендер или найти решение для проблемы, стоящей передо мной в данный момент. 🙂 Вообщем, отмазался. 😀

      • «И ежу понятно, что писать с нуля – верный проигрыш. »

        А вот не факт. Любой agile-настроенный сектант знает, что клиент никогда не знает чего он хочет. По-это эволюционный подход может оказаться таки намного дешевле и качественней. Всё зависит от самого клиента — насколько он туп чтобы заплатить за всю платформу целиком и сразу.

        • Juri Mulenko

          А вот я избалован готовыми продуктами. Пусть проект агильный, пусть клиент метается, надо смотрет что есть готового и исходить из этого. Если есть какое-то (в идеале опен-сорс) решение, пусть даже платное, к какой-то подзадаче, то task #1 опробовать его в минимальном прототипе. Из моей практики в подавляющем боль-ве случаев расходы на интеграцию конкретной библиотеки оказывались от 10% до 200 раз(!!!) дешевле, чем создание своей альтернативы.

    • Игорь Меньков

      Уточню данный момент: «…а писать что-то с расчётом на будущее очень сложно так как угадать нельзя». Все же предпологается, что клиент занимается вполне конкретным бизнесом, т.е. угадать нельзя детали, это верно. Но некую domain model сделать уже можно в самом начале и отталкиваться от нее.

  7. kaznachei

    Игорь, до какого числа принимаются ответы?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*

Работает на WordPress & Автор темы: Anders Norén