Bedste svar
Der er ingen formelle definitioner af disse roller, der er bredt vedtaget som standard af organisationer, så der vil være meget variation og lokaliseret kontekst.
Som en generel vejledning bruger jeg følgende definitioner:
- Teknisk arkitekt – En specialist inden for områder, der er justeret til infrastruktur, netværk og sikkerhed.
- Løsningsarkitekt – En generalist, der er ansvarlig for projektbaserede løsninger, der tager højde for alle aspekter af en løsning (fx forretningspåvirkning, applikationsændringer, data- og informationshensyn og den teknologi, der understøtter det hele), og forhåbentlig også kundeovervejelser.
- Hovedarkitekt – En person med et bredere sæt ansvarsområder end ovenstående roller. Dette kan fokusere på et forretningsdomæne, et større arbejdsprogram eller en hel virksomhed. Det bruges også ofte af konsulentfirmaer til at foreslå et niveau ((erfaring)) overlegenhed i forhold til andre arkitekter i teamet. De vil normalt have generalistiske bekymringer snarere end fokuseret på et enkelt arkitekturdomæne som infrastruktur, men det er ikke altid tilfældet.
Jeg håber, det hjælper. Det er vigtigt at huske, at der er ingen accepterede standarder, så udtrykkene er specifikke for det miljø, de bruges i.
Svar
For det første er det vigtigt at skelne mellem softwarearkitektur og simpelthen bedste praksis. En god softwareingeniør kan være fremragende til kodning, fremragende og detaljeret i deres tilgang og have stor indsigt i problemet, men stadig ikke en god arkitekt.
I det mindste en god arkitekt skal have følgende færdigheder:
En arkitekt er fremragende til problemnedbrydning . Problemnedbrydning er den færdighed, der er nødvendig for at se et problem på stort set ethvert niveau og nedbryde det i de trin og stykker, der er nødvendige for at implementere det. En god softwarearkitekt kan tage en erklæring som “Vores lufttrafikstyringssystemer er utilstrækkelige, og vi har brug for et bedre design” og kender de spørgsmål, der skal stilles for at begynde at nedbryde problemet til opnåelige komponenter, for at nedbryde disse komponentmål i opnåelige delprojekter , og nedbryde disse delprojekter til opnåelige programmeringsopgaver. En god arkitekt kan gøre disse ting på ethvert niveau eller målestok fra at forestille sig et billion-line softwareprojekt til at forstå den bedste måde at implementere en algoritme på for at klare upålidelige links. Skala er irrelevant, fordi processen altid er den samme.
En arkitekt forstår grænseflader . Grænseflader, hvad enten de er i form af protokoller, funktionsbiblioteker, klassegrænseflader eller skemaer er det primære værktøj, der er nødvendigt for at styre kompleksiteten af projekter, når der er uafhængige entreprenører og implementatorer. Ved at kende processen med at definere skarpe, entydige grænseflader, der er logisk komplette, kan en arkitekt give mange mennesker mulighed for at opbygge stykker af systemer, der let forbinder for at nå et større mål.
En arkitekt forstår, at kompleksitet er fjenden og behersker programmeringsværktøjerne og paradigmerne, der er nødvendige for at reducere kompleksiteten i alle komponenter, for at reducere kompleksiteten af grænseflader og sikre minimal eller ingen redundans i implementeringen funktion. De kan hurtigt genkende algoritmer og implementeringer, der er for specifikke eller for generiske, og vejlede dem, der udvikler sig, for at skabe komponenter, der udfører den helt rigtige funktion. Ofte er værktøjerne til styring af kompleksitet ting som dataskydning, objektorienteret programmering, selvvaliderende systemer og omfattende testplaner for standardgrænseflader. Men en god arkitekt er ikke dogmatisk med hensyn til værktøjer og teknologier, fordi de har en omfattende akademisk forståelse af grundlaget og grundene til, at data gemmer sig, og hvorfor visse sprog understøtter gode designprincipper, og andre ikke.
En arkitekt er en god kommunikator, en god og produktiv forfatter og dokumentator og er god til at tale programmeringssproget såvel som det fælles sprog for dem, der er interessenter i systemets design. Sammen med god kommunikation kan en god arkitekt give konkrete grunde til programmeringspraksis snarere end meninger og tilbyder indsigt til deres team snarere end argument. De favoriserer og søger brugerens mening om egnethed til det af deres egne eller programmørerne involveret i projektet.
En god arkitekt er en god leder og er fremragende til at vinde respekt for alle de tekniske folk de arbejder med .Normalt betyder det, at de har et højt niveau af færdigheder, har arbejdet på flere sprog og har været arkitekt før eller har demonstreret deres evne til at skabe systemdesign, der er forblevet fleksible i lyset af ændringer.
Mange definitioner inkluderer en række buzzwords, der understreger metoder som datadrevet design, agil programmering, specifikke sprog, platforme og værktøjssæt. Disse ting er aktuelle mærker til forskellige teknikker, hvis grundlæggende skal forstås godt og ikke accepteres, fordi de er i øjeblikket på mode. Så på mange måder er arkitektens hovedfærdigheder erfaring, intelligens, vilje til at arbejde hårdt og tage en praktisk rolle, god intuition og evnen til at nedbryde problemer ved hjælp af logik, så når industriens buzzword kommer og går, deres design forbliver nyttige og relevante.
Min definition ovenfor inkluderer bevidst ikke projektledelse, planlægning og ledelsesfærdigheder. Arkitektens rolle er at skabe gode systemer, ikke at løse teamproblemer eller budgetter. Faktisk er det bedst, hvis de med budgetter og teamproblemer simpelthen er interessenter, der hjælper med at definere en af de begrænsninger, arkitekten skal håndtere, ligesom hvis det var en del af deres designproblem.