ERP, SAP, SOA and other buzzwords

Презентация Sanjiva Weerawarana I'm currently Chairman and CEO of WSO2:

SOA Case Study Contest Special Recognition Winner: NY State Department of Taxation & Finance for e-MPIRE – сплошные кейсы

http://blogs.zdnet.com/service-oriented/?p=2913 – где наши 80%? =)

http://www.ebizq.net/blogs/sdesign/2009/09/5_tips_before_you_embark_on_so.php  — перед тем как начать внедрять

Five best practices for deploying a successful service-oriented architecture

Чего хочет клиент?

These are just 3 examples of questions addressed by the SOA principles. If you cannot answer questions like these, you have some work to do in your service portfolio to enforce the principles more cleanly. If we continue to build systems that abuse service design principles, desired outcomes will suffer. If the service granularity is wrong or if interface and implementation concerns are badly separated, then the service will be less reusable. If business logic and infrastructure concerns are blended, developers can't make changes to systems quickly and easily. Tightly coupled systems are going to get in the way of manageability. 

It's the outcomes, stupid

If SOA is about contributing to business outcomes, then measuring the value of services must start with the desired business outcomes. To be credible and repeatable, metrics must be underpinned with measurements from your runtime infrastructure and service repository.  In her forthcoming paper, Anne will frame the principles and techniques with the benefits from applying each principle and with metrics for demonstrating the impact of applying or neglecting each of them. Stay tuned.

EDI, B2B, SAP and Cloud Computing – интересный блог

http://www.deepmarket.com/technology/how-to-become-an-soa-superhero/ – стань супергероем!

http://blog.hill-it.be/post/2009/08/24/Understanding-SOA-Introduction – в сто сорок восьмой раз не SOA ас!

SOA is about Architecture – еще одно обозрение

Желаю всяческих свершений!

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

Яков Сироткин

Если вы учились в университете на ИТ-специальности, то по нескольким курсам сразу вам сто раз проехали по ушам про “затраты на исправление ошибок, допущенных при проектировании системы”. “Ну как же можно ошибаться, ну опыт же нужен, ну даже если ошиблись – ну софт в конце концов – не пирамиду строим” – думал я. Столкнувшись с данной проблемой face2face я прихожу к выводу, что ошибка проектирования – это “крест”, который потом придется тащить всей команде разработки. Вы будете с трудом менять интерфейс, вклеивать новые функции, пытаться масштабировать решения – но “крест” будет вас преследовать. И это первая проблема с которой вы столкнетесь – проблема мотивации команды, проблема развития системы. Но более глубокой проблемой, которая возникает из-за этой ошибки является нехватка ресурсов для ее преодоления.

С одной стороны проблема – решаема, с другой стороны – система работает, пользователей все устраивает. Вообще, я заметил – рядовых пользователей устраивает “неэффективное” ПО =). Но не суть. Итак, у вас есть “кривоватая” система, которая запущена в эксплуатацию. При этом вас терзают смутные сомнения – “У посла медальон…у Шпака магнитофон…” сносить все и строить заново, либо латать что есть и будь, что будет. Строить все заново – читай сделать тоже самое, только по-новому, но бюджет по это не один вменяемый не даст. Тут уже вопрос профессионализма вылезает. Латать – читай усугублять крест.

Я обозначил проблему. Возможно риторичную =). Пойду искать грааль, выводами – поделюсь…

Продолжаю восхищаться теми, для которых, мы – программисты, консалтеры и консультанты работаем. Пользователь хочет большего от программы, которую он заказывает. При этом он не знает про треугольник проджект менеджера. Ему плевать на реляционную теорию. Он не понимает, что можно и что нельзя. Он входит во вкус.  Он начинает понимать, что к чему. И вот здесь опасность – опасность завалить проект под гнетом его требований. Вы скажете ТЗ, вы скажете аналитики, вы скажете договор, вы скажете планирование. Я скажу – это всё полная …

Кто-то выдвинул идею, что проджект менеджмент – фикция. Если вы руководите проектом с жестко заданным или “умножь время которое нужно программисту на два” временем, то вы им нихрена не руководите, а просто кусаете локти. 99 процентов функционала реализует 1 процент кода – вот Парето, без всякой чепухи.

Поскольку проект – это инженерная задача, то она либо решается, либо не решается. Когда кто-то строит диаграммы Ганта и вбивает атноты в Outlook, думая что это как то спасает или управляет проектом, то он явно ошибается. Вы приходите к Васе: – Вася, вот задача, вот тебе 2 дня на ее решение. А у Васи голова болит, а Вася запарился уже одну и ту же кнопку приклеивать, а Васе хочется новыми технологиями заняться. Вопрос: “Управляем ли Вася?” Нет. Они либо решает, либо вы начинаете метаться в поисках спеца, который еще не факт что поможет. Который возможно будет просто потерей времени.

К чему это все?

Чтобы проект не завалился, его надо начинать раньше! Во всех смыслах, фаст старт, фальстарт, как хотите. Начинайте раньше думать о проблемах, начинайте больше “впаривать” пользователю то, чего он сам хочет. И сразу.

— А вот так мы можем?

— Да

— А вот чтобы так было?

— Да, а время у нас есть?

Пользователь хочет большего, чем вы сможете ему предложит. Задача теперь в том, чтобы не завалиться на бок под весом требований.

Удачи!

Новый отчетный пост о СОА:

Джо как всегда поднимает глобальные темы -http://www.ebizq.net/blogs/soainaction/2009/08/soa_is_ready_for_the_business.php

Chatting from SOA Suite 11g — how BPEL processes can use the XMPP protocol to notify the world by Lucas Jellema – практическое и полезное

http://advait.wordpress.com/2009/08/25/installing-oracle-soa-11g/ – новичкам и любознательным

http://biemond.blogspot.com/2009/08/starting-soa-suite-testcases-from-java.html – и сразу в бой!

http://www.ebizq.net/blogs/sdesign/2009/08/align_your_soa_and_bpm_efforts.php —

Книга Марианны Броадбент (аналитика Gartner) редкий пример, когда обложка не соответствует содержимому (т.е. обложка намного хуже –). Но суть не в этом. Суть в том, что несмотря на управленческую заточку обсуждаемой темы и менеджерских фишек, книга содержит массу интересных примеров и инфы как для руководителей, так и для тех кому просто интересно почему он подчиненный, а он руководитель =).

А поскольку мой мозг при чтении книг, работает примерно так же как и у Лебедева (я почему-то тоже из книги могу запомнить только пару фраз или предложений, которые действительно ценны) мне особенно запала в душу страница номер 62:

По мнению N.Venkatraman из университета в Бостоне, сетевой эпохой управляют три закона. Влияние каждого из них достаточно велико, но их совместное действие усиливает эффект во много раз.

Закон Мура гласит, мощность компьютерных чипов удваивается каждые полтора года.

Закон Гилдера гласит, что полоса пропускания телекоммуникационных соединений удваивается каждые полгода.

Закон Метклафа гласит, что ценность любой сети растет как квадрат числа ее пользователей.

Оказалось, что законов подобных этим очень много. И знать их было бы неплохо. Но пожалуй главная мысль, которая мне запомнилась в книге – Если это можно измерить, значит этим можно управлять! Если подходит к процессу оптимизации бизнес-процессов с этой мыслью в голове, то многие вещи смотрятся по-другому. И главное, что вы сможете объяснить бизнесу почему можно автоматизировать здесь, а почему здесь нельзя. Реинжиниринг становиться проще сам по себе.

Go-gO soldiers, must read!