Archive Page 9
Готовил обзорную презентацию по простым и незамысловатым CMDB решениям. Выкладываю всем интересующимся:
Больше про CMDB, а так же его место в управлении ИТ-инфраструктурой можно прочитать здесь и тут.
Самые полезные ресурсы и материалы можно найти в закладках – CMDB, http://delicious.com/tag/cmdb, http://delicious.com/tag/itil.
Также по ITIL тематике можно скачать данный торрент.
Заключительный вопрос. Верно ли утверждение: чем мощнее компьютер, тем быстрее на нем можно решить данную задачу?
Заключительный ответ. Нет, это не верно.
Всем нам знакома эта пирамида памяти:
этот закон Мура:
о котором стоит говорить, не забывая про закон Амдала:
Производительность вычислительной системы, состоящей из связанных
между собой устройств, в общем случае определяется самым
непроизводительным её устройством.
Все вышесказанное я привел к тому чтобы показать какими аппаратными возможностями обладает любой современные прикладной программист, разрабатывающий коммерческий, пользовательский софт. И опять обратиться к теме, в которой старшее ИТ-поколение с ностальгией говорит о программах, работающих на 16 Кб памяти. Или же еще более искушенная часть низкоуровневых программистов, которые действительно делают "красивые, алгоритмичные" программы.
Но и это не главная мысль поста о которой мне недавно подумалось. Моя мысль — чем ниже минимальные требования к системе, тем качественнее она будет сделана и как следствие лучше работать. Да, пожалуй это очевидно в одних случаях, и не очевидно в других, но тем не менее. Половина косяков и багов современных систем, возникает из-за а) снизившейся квалификации среднего программиста (средний программист = кодер) и б) а может и а) =) обширных, доступных ресурсов. И ресурсы в данном случае это не только мощные пользовательские машины, но и богатые современные IDE, RADы и прочие dev. tools. Программирование как деятельность упростилось, кадровый дефицит привел к снижению "порога" входа в софтверную деятельность (я имею ввиду профильность и уровень образования, а также опыт работы).
Количество строк кода и реализация алгоритмов стало неважно из-за быстроты процессоров и транзакций в СУБД. Все это привело к неоптимальности работы алгоритмов и как следствие — снижению качества работы программы. Ведь, на мой взгляд, из 2х одинаковых программ, лучше работать будет та, для которой минимальные требования конфигурации аппаратных и системных средств значительно ниже. Одно дело накодить, имея в запасе пару гигов оперативы, а другое дело для 16 Кб.
В чем соль? Заказывать и принимать систему надо заведомо на более заниженных аппаратных и системных требованиях. Не 3 Гига, а 1, не выделенка, а диалап, не двухядерных, а хотя бы 3ий или средний атлончик AMD. Чем агрессивнее среда, тем качественее программа. Тем лучше алгоритм, тем выше надежность, тем сложнее процесс тестирования и дольше этап проектирования.
В каком то плане, вы как заказчик системы должны крутиться в треугольнике:
Кол-во багов и ошибок (качество) — Возможности АС и ПС (ресурсы) — Стоимость ПО (деньги + время).
А расставить приоритеты — дело каждого.
Нам выпала великая честь — жить в перемену времен.
Борис Борисович Гребенщиков (День Радости)
Она сказала, они стали волноваться...
Вообще разговаривать о чем-либо технологичном, новейшим и доселе необузданном в период кризиса — дело не благодарное, ненужное, да и не до этого нам сейчас, когда Европа мерзнет, мы сливаем нефтеденьги из резерва, и все говорят что это только начало...
Но все же хотелось обратиться к посту аналитика the Burton Group Anne Thomas Manes, которая провозгласила что мол хватит товарищи buzzwordами заниматься, врать и придумывать:
It’s time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our vocabulary.
и нарисовала картинку перед которой я не устоял от копипаста:
и много еще чего, почитайте и комменты тоже. Dan Foody ее поддержал. А MikeKavis так вапще всем напомнил про архитектуру =)))
Реакция SOA экспертов последовала незамедлительно. И я в принципе с ними со всеми согласен:
David Linthicum — However, this failure does not diminish the need for SOA. Indeed, most enterprise architectures are a mess and are getting messier as the years go by. Moreover, if you just look at the inefficiencies within the current IT infrastructure you can easily make a case for SOA.
Joe McKendrick — SOA is a philosophy, methodology, and set of best practices or patterns that shapes the way enterprises and government agencies address problems through IT. You can kill off the associated technologies and products, but not the ideas and practices. It would be like declaring the sudden death of Agile development, business process management, data integration, re-engineering, or zero-based budgeting.
D Nickull — SOA is architecture that is focused on services as the abstract action boundary between (business) needs and (business) capabilities. As such, the form of architecture known as SOA that captures that blueprint and relates it to business services is not dead and will survive well into the next decade. SOA IS NOT DEAD!
Andrej Koelewijn — SOA is only dead if you interpreted SOA as creating Web Services and building composite applications with BPEL. And yes, that is pretty stupid. And, unfortunately, quite common. I’ve seen simple applications being build with lots of BPEL processes, resulting in very complex, hard to deploy, and hard to manage applications. With bad performance. And, even worse, hard to change. Nothing agile about it.
Steve Jones — So in a recession you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach. If that isn't SOA then I don't know what is. So in reality its the «other» SOA that is dead, not the SOA of today.
Andy Mulholland — So you want my prediction for 2009? It will be the resurgence of SOA, used more as Services Oriented Business Architecture, does this surprise you? Well remember the history of Client Server in the 1990-96 period. Many who tried it for projects with a background of Mainframe and Mini Applications couldn’t see the value in splitting the client and server logic and abandoned it. It took a new generation of developers familiar with PCs and Networks designing a new generation of applications, like ERP, to show what its true value was. Seems awfully like what I hear today about trying and adopting SOA.
Другие комментарии в пользу ЭсОЭй собрал InfoWorld
Вся эта дискуссия очень напоминает холивар о понимании SOA, который был и будет продолжаться. Ведь как написал один из участников обсуждения в комментах к посту Анны:
Hopefully SOA isn't dead but the chronic misunderstanding in the marketplace about SOA is.
Все-таки 2009 будет еще насыщенней чем 2008 =))).
Ну а в завершении хочется привести ссылку на пост-отзыв Miko Matsumura:
I’m indifferent to whether we continue to call it SOA or not, lets just keep building the future together.
или по-нашему — будем живы, не умрем
Есть в студии Лебедева такой арт-директор — Рома Воронежский, и есть у Ромы сайт. Так вот пару месяцев назад, как вы заметили, сменился у Яндекса логотип. Мне тоже на первый взгляд показалось не очень. А кто-то даже свой вариант стал предлагать. Но сегодня кто вспомнит какой логотип был у Яндекса пару месяцев назад?
Позволю себе процитировать Ромин текст. Рецензия на все «пользовательские отзывы» (начало читайте на сайте):
... Да, так вот. Есть теория, которая, похоже, объясняет феномен. Она называется «меня не спросили». Да-да-да. Дело-то не в том, что вы логотип поменяли, а в том, что поменяли его без моего ведома, без моего согласия, без моего участия. Я ведь тоже умею в фотошопе, я ведь тоже пользователь, у меня, черт возьми, тоже есть мнение! А вы его проигнорировали. Вы мне дали понять, что я дурак, непрофессионал, быдло. А на самом деле я умный, я угадал, что это шрифт Myriad Pro, я могу сам сделать лучше гораздо — но сделал кто-то другой, и получил, наверное, кучу бабла. А я не получил. И поэтому я сейчас докажу вам, что вы зря, ох, зря меня не спросили. Сейчас я вам все расскажу, все, что я думаю и о логотипе, и о том, кто его вам за миллион евро нарисовал.
По-моему, это все объясняет.
Если бы авторы отзывов участвовали в создании логотипа, ну или хотя бы выбирали его голосованием, потока ругани просто не было бы. Ощущение причастности помешало бы. ...
Это пожалуй, главная деталь, которую упускают все редизайнеры, ребрендингеры, Рембра(э)нды =), а самое главное внедренцы. Мы не спрашиваем, а просто устанавливаем функционал. «- Теперь работать будет по-нашему. Учитесь, там все тоже самое, просто кнопки зеленые и иконки стеклянные». И получаем неприятные проблемы со стороны людей, бизнес-пользователей. Их не спросили, им не сказали, за них все решили.
Понятное дело, что никто не будет менять функционал, переделывать GUI или разрабатывать настройки. Понятное дело, что всем не угодишь. Но, мы всегда можем создать ощущение причастности в создании, ощущение того, что систему внедряют для пользователя, а не для топов. Что их, этих юзеров и ламеров слушают. А они за это ставят галочки, что система работает, и удобно даже =)
Как же сделать сотрудников причастными (лояльным будет более правильно) к созданию системы (хотя бы на уровне иконок и цвета progress bar'а)? Мне приходит на ум только внутрикорпорационное анкетирование. Создаем тестик, пару десятков вопросов, типа «Иконка приложения должна быть похожа на ...» и все — «Спасибо что заполнили анкету! Разработчик обязательно учтет ваше мнение.»
— Что-то не так? Ну вы знаете, большинство решило, что они будут зелеными, извините. — Да, голоса распределились поровну и мы решили, что кнопка будет нажиматься теперь вот так...
Муляж и обман? Да. Но все же, сколько сэкономленных ресурсов и сил при окончательном внедрении системы!
Приходят в компанию, а уходят от начальника.
Народная мудрость.
— Да у них постоянная текучка. — Да, это у всех, в любой компании. Что ж поделать. Даа. Даа.
Текучка кадров есть действительно в каждой компании, корпорации, ПБОюЛе или ИПе. Но удивительно, что директора и менеджеры к этому относяться как к должному. Может просто стоит признаться что ваша компания не лучшая на рынке? Может стоит относиться к сотрудникам более внимательно?
Ситуация в ИТ такова (опять таки на свой вкус). Есть 4 возрастных категории специалистов — до 25, 25-30, 30-35, после 35. Посмотрим на каждую из них через призму «текучести», т.е. вероятности смены работы. Я думаю что все согласятся (есть исключения конечно) с тем, что чем человек старше, тем меньше всего ему хочется менять работу...спец с возрастом 30-35 лучше будет работать на своей менеджерской позиции, хотя его уже давно многое не устраивает... Можно с уверенностью сказать, что самыми текучими являются выпусники и молодые специалисты. Вот о них я и хочу сказать (и сам таковым являюсь — ). Что побуждает сменить работу? Деньги? Да. Интерес? Да. Да много чего...факт в том, что люди уходят туда где лучше. В лучшую фирму, компанию, контору. А раз уходят, значит ваша компания не лучшая на рынке. Значит там, куда они уходят — признают их цену и опыт.
В этом споре, очень, очень много исключений и областей где это не сработает. Но, скажем если программист из одной софтверной компании уходит в другую со сходным профилем работ — это уже автоматом должно заставить задумываться? Почему к ним? Да — они сильнее, богаче, у них клиенты лучше. И что? Что вам мешало предложить менеджерскую позицию для этого человека? Хочешь больше получать — ну давай, вот тебе права и должность, пробуй, сделай это для нашей компании...
Дело все-таки в менеджменте, в этом peopleware, во внутренних процессах, в организационном построении и способности к «человеческому масштабированию»...
чуствую что где-то ошибаюсь, но пока так...