Timpul trece, știința evoluează, cerințele oamenilor cresc, adaptarea la schimbări în orice domeniu devine cerință de bază. În același timp, așteptările sunt în creștere dacă vine vorba despre calitate, accesibilitate, securitate și nu în ultimul rând cost.
Industria de IT din ultimi ani a adus în discuție necesitatea sau inutilitatea arhitecturii de software sau arhitecților de software.
În articolele ce vor urma doresc să abordăm câteva teme legate de domeniul arhitecturii de software și cel al rolurilor de arhitect software, business, IT etc. Vom încerca să schițăm un proces de lucru care să ne ajute la crearea unei arhitecturi. Vom aborda cerințele unui document SAD (software architecture document), ce Framework-uri putem aplica (4+1 View model, Togaf, Zachman), uneltele ce se pot folosi și desigur niște noțiuni care țin mai mult de Business, resurse umane şi comunicarea cu alții.
Cuvântul în sine provine din limba latină architectura, adaptat la rândul său din cuvântul grecesc arkhitekton. Acesta este un cuvânt compus din arkhi (lider, șef, cel pe care se poate urma) și cuvântul tekton (constructor, artizan, creator, planificator, maestru în domeniu).
În IT primele noțiuni au apărut în ani 60, urmând ca după ani80 când deja sistemele au ajuns la o complexitatea ce necesita organizare și planificare mai eficientă, dezvoltatorii au început să exploateze avantajele de a planifica intenționat structura soluțiilorîn diferite domenii. Au început să definească soluții comune pentru probleme specifice sau repetabile, reutilizabile.
Să nu uitam ca în `79 a apărut primul calculator personal (Apple II) care aducea cu el VisiCal (predecesorul lui Excel ). În 1981 apare MS-DOS, iar în 1983 apare Word din bucătăria firmei Microsoft.
Până la finele anilor `90 s-au tot definit metodologii, teorii, "best practice"- uri în diferite domenii din industria IT și structuri comune refolosibile. În 1995, Philippe Kruchten definește modelul arhitectural de "4+1 View" unde descrie vederile (view) :logical view, development view, process view, physical view și scenarios (cunoscut și sub numele de use case view).
Punctul culminant l-au adus anii 2000 când cunoștințele și teoriile acumulate au început să se aplice în practică. Momentan suntem participanți activi la aplicarea și popularizarea necesității arhitecturilor software și metodologiilor aferente.
Din studiile realizate de IEEE am selectat graficul de mai jos care oferă o vizualizare completă a evoluției arhitecturii software.
Arhitectura software poate fi definită în termeni generali ca structura de nivel superior a unui sistem. În cartea Software Architecture in Practice, Third Edition, apărută în 2012 la Addison-Wesley (autorii Bass, Clements și Kazman) se definește în următorul format:
_"Arhitectura este rezultatul unui set de decizii de afaceri și tehnice. Schița (desing) în momentul creării este influențat_ădin mai multe părți, astfel și execuția va fi influențată de schimbări în funcție de mediul din jur pe care arhitectul trebuie să cunoască."
["An architecture is the result of a set of business and technical decisions. There are many influences at work in its design, and the realization of these influences will change depending on the environment in which the architecture is required to perform."]
Maturitatea domeniul de arhitectură software
O altă definiție din aceeași lucrare este: "Arhitectura software a unei aplicații sau sistem este structura sau structura sistemelor, ce combină elemente de aplicații, proprietățile vizibilității externe a acestor elemente și relația între ele."
IASA (The Global IT Architect Association) definește noțiunea de IT arhitectură ca: "Arta sau știința schițării (design) și arta de a livra strategie tehnologică utilă."
Dar arhitectura software poate fi considerată ca un mediu de facilitare de discuții a alegerii unei soluții de aplicații între solicitanții aplicației (business owner, stackeholder) și cei care vor livra, astfel încât să se ia decizii fundamentale de creare de aplicații care pe parcurs vor ajuta ca produsul finit să aibă factori de cerințe satisfăcătoare tuturor. Dintre acești factori menționăm: eficiență de cost, extensibilitate, modularitate, adaptabilitate, scalabilitate, securitate, calitate etc. .
Concluzionând, putem considera arhitectura software ca mediul de definire a structurilor, elementelor și a relațiilor.
Scopul unei arhitecturi de software poate fi diferit, de la caz la caz în funcție de necesitățile specificațiilor inițiale. Totuși se poate defini un subset de scopuri comune care vizează:
Lista se poate extinde după dorințele fiecăruia, e important ca la final să se răspundă la întrebările:
Planul de arhitectură SAD (Software Architecture Document) .
Putem considera că o arhitectura software este încadrat într-un ecosistem organizațional ce e întreținut de sisteme care la rândul lor sunt compuse din aplicații, hardware, structura de organizație, surse și structuri de informații.
Nivelele de arhitectură din IT se pot structura astfel:
Sperăm că prin acest prim articol am reușit să vă introducem într-un domeniu complex precum cel al arhitecturii software.