Czy architektura korporacyjna jest tylko dla dużych organizacji?

Kategoria II

Obecnie zakładanie start-upów w Polsce stało się modne. Wynika to z faktu, że na rynku pojawiło się sporo pieniędzy pochodzących z Unii Europejskiej (w tym w szczególności z Programu “Innowacyjna Gospodarka”), ponadto funkcjonuje spora liczba funduszy inwestycyjnych nastawionych na branżę IT/internetową. W sieci i na spotkaniach branżowych można spotkać się z informacjami, że warto takie start-upy tworzyć np. zgodnie z metodyką “Lean Startup“. Pytanie, czy w organizacji typu start-up, będącej na początku swojego “cyklu życia” – co siłą rzeczy powoduje, że jest ona niewielka – może być przydatna koncepcja architektury korporacyjnej? Pierwszy sondaż przeprowadzony wśród architektów korporacyjnych wskazuje, że NIE. Wynika to z faktu, że wiele osób postrzega architekturę korporacyjną przez pryzmat rozbudowanych (ciężkich) ram architektonicznych i konieczności trzymania się “na sztywno” zasad nadzoru/ładu architektonicznego.

Ja jednak wolę rozumieć architekturę korporacyjną jako obraz (master plan) stanu docelowego korporacji (Gartner od dawna przestrzega, aby nie utożsamiać architektury korporacyjnej z opisem stanu “as-is”), przygotowanego na pewnym poziomie szczegółowości. Stanowić on może podstawę współpracy pomiędzy osobami odpowiedzialnymi za  planowanie biznesowe (obejmujące tworzenie wizji, strategii i pryncypiów); osobami odpowiedzialnymi za operacje biznesowe  (w ich gestii znajduje się struktura organizacyjna, procesy i dane biznesowe); osobami odpowiedzialnymi za automatyzację biznesu (poprzez wprowadzanie rozwiązań IT i zasobów informacyjnych), osobami odpowiedzialnymi za infrastrukturę techniczną biznesu (taką jak systemy operacyjne, serwery aplikacyjne, systemy zarządzania bazami danych, sprzęt teleinformatyczny).

Przy tak sformułowanej definicji architektury korporacyjnej nie ma słowa o wielkości organizacji, dla której ma ona powstać. Jeśli już, to właśnie mniejsze firmy (na początku swojego cyklu życia) mogą potrzebować master planu do prowadzenia nieustannie trwających projektów technicznych,  bardziej niż większa organizacja, która może pozwolić sobie na zmarnowanie pewnej ilości pieniędzy na nieprzydane oprogramowanie.