Architektura informacji w SharePoint to pojęcie, którego zrozumienie jest kluczowe w przypadku jego wdrożenia. Pierwsze pytanie, które nam się tu nasuwa to o czym w zasadzie mówimy? W kontekście różnych rozwiązań mogą być różne definicje, ale dla mnie Architektura Informacji w przypadku SharePoint to skupienie się na zawartości przechowywanej na tej platformie. Jeżeli ktoś jest bardziej zainteresowany tym tematem to odsyłam na strony Technet. Tam można znaleźć bardziej dogłębne omówienie tego czym jest Architektura Informacji w przypadku platformy SharePoint.
Przechowywaną zawartość tak na prawdę można streścić w czterech punktach:
- Dokumenty
- Strony web
- Posty/Strony
- Zawartość list
Tak na prawdę to praktycznie cała zawartość, która może być przechowywana. Ta zawartość może być układana w uporządkowaną strukturę za pomocą następujących narzędzi, które są tu kluczowe:
No bo czym tak na prawdę jest SharePoint? W tym momencie może paść wiele odpowiedzi i większość będzie z nich prawdziwa, ale SharePoint to przede wszystkim system do zarządzania zawartością. Tu taka mała dygresja. Otóż panuje takie przekonanie, że SharePoint jest bardzo skomplikowanym systemem do zarządzania i programowania. Jest to po części tylko prawda. Dużym problemem jest to, że na jego bazie różne firmy próbują budować praktycznie wszystko. Oczywiście można, tylko po co? Jeżeli napiszemy prawie cały kod od zera, aby mieć na przykład system CRM to po cholerę nam SharePoint? Nie lepiej ten przenieść do oddzielnej aplikacji?
Architektura informacji – Cztery kroki do sukcesu
Do wdrożenia architektury informacji w SharePoint, które zakończy się sukcesem są potrzebne tak na prawdę cztery kroki, przynajmniej z mojego punktu widzenia:
- Pierwszym elementem i moim zdaniem kluczowym jest zdefiniowanie celu, który nam przyświeca i co dzięki temu chcemy osiągnąć. Bez tego elementu, kolejny krok, czyli projektowanie nie będzie miał większego sensu. Musimy wiedzieć czego chcemy, aby móc zaprojektować jak ma wyglądać Architektura informacji w naszym SharePoint. W przypadku SharePoint to może być na przykład szybkie znajdywanie potrzebnych informacji. Przyjęcie założenia, że chcemy SharePointa bo wszyscy go mają to proszenie się o kłopoty.
- Na etapie projektowania musimy się zdecydować jakie elementy wykorzystamy, jakie funkcjonalności będą nam potrzebne do osiągnięcia założonego celu. Na przykład czy i jakie tagi będą nam potrzebne.
- Gdy wiemy co chcemy osiągnąć i w jaki sposób przechodzimy do realizacji naszych założeń.
- Gdy nasza architektura będzie już na miejscu i wszystkie zdefiniowane cele zostaną zrealizowane pozostaje nam zarządzanie naszym rozwiązaniem. I jest to nie mniej ważne niż wcześniejsze trzy punkty. Musimy uczyć naszych użytkowników jak działa nasze rozwiązanie, jak go efektywnie używać. Jednocześnie warto kontrolować czy co niektórzy nie robią nic wbrew przyjętym założeniom, bo może okazać się, że po kilku tygodniach mamy regularny śmietnik zamiast uporządkowanego zbioru informacji
O tym jak praktycznie można to zrealizować będzie już w następnym wpisie.