Problem pozornie prosty: jak doprowadzić do współpracy dwa skrajnie różne światy IT - operacje zarządzające usługami (ITSM) i rozwój zarządzający projektami (n.p. PMI)? Tak go przynajmniej naszkicował Bartosz Górczyński prezentujący wczoraj zagadnienie Potrzeby ITSM wobec PM. Słuchając wczorajszego wykładu doszedłem do wniosku, że to co w świecie małych organizacji jest trywialne, w rzeczywistości dużych korporacji nie musi być wcale takie oczywiste.
Jak to działa w rzeczywistości małej organizacji? (przykład z praktyki - 2007) Każdy projekt ma swojego kierownika i zespół projektowy. W skład zespołu projektowego wchodzi osoba z operacji (zwykle administrator), który konsultuje wszelkie pomysły zespołu projektowego i wspomaga realizację zadań w części operacyjnej. Na przykład organizuje środowisko rozwojowe tak, aby było identyczne z planowanym środowiskiem produkcyjnym. Mamy zatem ścisłą współpracę pomiędzy operacjami a rozwojem realizowaną przez "oficera łącznikowego" z operacji. Co ciekawe (sprawdzone!) "oficer łącznikowy" często tak utożsamia się z projektem, że "przepycha" pomysły rozwojowe w swoim pionie (operacyjnym) nawet na przekór swoim kolegom.
Dlaczego nie zastosować tego w dużych organizacjach? (Jeśli ktoś ma czas posłuchać całości podobnego seminarium z Poznania zapraszam na YouTube).
Jest nawet taka inicjatywa o nazwie DevOps, która wygląda dokładnie jak wyżej opisany przykład. Jest nawet "profesjonalna" nazwa naszego oficera łącznikowego pomiędzy operacjami i rozwojem: Release Coordinator.
A co Wy o tym sądzicie?
środa, 21 listopada 2012
sobota, 10 listopada 2012
Big Data Matters
W ostatni piątek odbyło się seminarium Large Data Infrastructures for US Government and Industry. Oprócz ciekawostek na temat realiów rynku informatycznego w USA jeden ze słuchaczy zadał pytanie: "When we should talsk about BigData?". Odpowiedź prowadzącego prezentację Lee Turnera była zaskakująco szczera: "I don't know!". Podpowiedź organizatora seminarium Pawła Płaszczaka z GridWiseTech była następująca: "BigData to dane, którymi na aktualny stan technologii nie da się zarządzać za pomocą trywialnych narzędzi." Niestety ta definicja mnie nie usatysfakcjonowała. Dlaczego? Ponieważ według niej zawsze mieliśmy i będziemy mieć do czynienia w informatyce z BigData, a jakość jednak aktualnie ten termin się pojawił podobnie jak Cloud!
Na podstawie mojego doświadczenia twierdzę, że BigData wiąże się ze specyficznymi strukturami baz danych, z którymi mamy do czynienia od momentu istnienia "user-generated content". Specyfika tych struktur polega na tym, że baza danych daje się podzielić na dwie części. Jedna z nich ma składa się z kilku tabel (zwykle nie powiązanych kluczami obcymi z pozostałą częścią bazy), które swoim rozmiarem odstają od reszty bazy. Przykładowo:
Dodatkowo te największe tabele cechuje wysoka dynamika wzrostu. Zarządzanie taką strukturą danych za pomocą tradycyjnych silników relacyjnych baz danych nie jest ekonomiczne. Rozwiązania o bogatej funkcjonalności zaprojektowane do zapewniania transakcyjności obliczeń zatrudniamy do stosunkowo dużej liczby prostych zapytań na ogromnych wolumenach danych. Dlatego powstały rozwiązania (Hadoop, MapReduce), które wykonują operacje na tej części bazy dużo efektywniej niż tradycyjna relacyjna baza danych. Dla mnie to właśnie jest BigData.
Na podstawie mojego doświadczenia twierdzę, że BigData wiąże się ze specyficznymi strukturami baz danych, z którymi mamy do czynienia od momentu istnienia "user-generated content". Specyfika tych struktur polega na tym, że baza danych daje się podzielić na dwie części. Jedna z nich ma składa się z kilku tabel (zwykle nie powiązanych kluczami obcymi z pozostałą częścią bazy), które swoim rozmiarem odstają od reszty bazy. Przykładowo:
- średnia liczba wierszy w tabelach 5 mln
- średnia liczba wierszy w 2 wybranych tabelach 100 mln
- średnia wielkość większości tabel kilkanaście MB
- średnia wielkość 2 wybranych tabel 75 GB
Dodatkowo te największe tabele cechuje wysoka dynamika wzrostu. Zarządzanie taką strukturą danych za pomocą tradycyjnych silników relacyjnych baz danych nie jest ekonomiczne. Rozwiązania o bogatej funkcjonalności zaprojektowane do zapewniania transakcyjności obliczeń zatrudniamy do stosunkowo dużej liczby prostych zapytań na ogromnych wolumenach danych. Dlatego powstały rozwiązania (Hadoop, MapReduce), które wykonują operacje na tej części bazy dużo efektywniej niż tradycyjna relacyjna baza danych. Dla mnie to właśnie jest BigData.
czwartek, 8 listopada 2012
IT-Capacity@Oracle Day
Witam,
dzięki uprzejmości Pana Pawła Płaszczaka z GridWiseTech miałem przyjemność uczestniczyć w konferencji Oracle Day w Warszawie. Temat IT-Capacity pojawił się na porywającej prezentacji Pawła jako jedna z metryk biznesowych oferowanych w ramach innowacyjnej usługi Oracle Care. Usługa ma wesprzeć długo oczekiwany przełom w relacjach pomiędzy biznesem a IT. Dzięki niej dyrektor IT może w sposób czytelny dla zarządu firmy przedstawić stan infrastruktury IT i uzasadnić niezbędne inwestycje. Usługa pozwala na gromadzenie i wizualizowanie danych o trzech kluczowych obszarach wyzwalających wydatki na IT:
dzięki uprzejmości Pana Pawła Płaszczaka z GridWiseTech miałem przyjemność uczestniczyć w konferencji Oracle Day w Warszawie. Temat IT-Capacity pojawił się na porywającej prezentacji Pawła jako jedna z metryk biznesowych oferowanych w ramach innowacyjnej usługi Oracle Care. Usługa ma wesprzeć długo oczekiwany przełom w relacjach pomiędzy biznesem a IT. Dzięki niej dyrektor IT może w sposób czytelny dla zarządu firmy przedstawić stan infrastruktury IT i uzasadnić niezbędne inwestycje. Usługa pozwala na gromadzenie i wizualizowanie danych o trzech kluczowych obszarach wyzwalających wydatki na IT:
- poziomie ryzyka
- kosztach
- pojemności infrastruktury IT
Taka informacja pokazana on-line i zrozumiała dla Zarządu powinna pomóc zdobyć finansowanie infrastruktury IT. Zachęcam do zapoznania się z informacjami handlowymi na ten temat - sam jestem ciekawy i nie omieszkam zajrzeć do broszury.
Subskrybuj:
Posty (Atom)
