Beste svaret
Det er ingen formelle definisjoner av disse rollene som er allment vedtatt som standard av organisasjoner, så det vil være mye variasjon og lokalisert kontekst.
Som en generell guide bruker jeg følgende definisjoner:
- Technical Architect – En spesialist innen områdene til infrastruktur, nettverk og sikkerhet.
- Løsningsarkitekt – En generalist som er ansvarlig for prosjektbaserte løsninger som tar hensyn til alle aspekter av en løsning (f.eks. virksomhetspåvirkning, applikasjonsendringer, data- og informasjonshensyn og teknologien som understøtter det hele), og forhåpentligvis også kundehensyn.
- Rektor Arkitekt – Noen med bredere ansvarsoppgaver enn rollene ovenfor. Dette kan fokuseres på et forretningsdomene, et større arbeidsprogram eller en hel bedrift. Det brukes også ofte av konsulentfirmaer for å foreslå et nivå av (erfaring) overlegenhet over andre arkitekter i teamet. De vil vanligvis ha generalistiske bekymringer i stedet for å fokusere på et enkelt arkitekturdomen som infrastruktur, men det er ikke alltid tilfelle.
Jeg håper det hjelper. Det er viktig å huske at det er ingen aksepterte standarder, så ordene i seg selv er spesifikke for miljøet de brukes i.
Svar
Først er det viktig å skille programvarearkitektur fra bare beste praksis. En god programvareingeniør kan være utmerket på koding, utmerket og detaljert i sin tilnærming, og har mye innsikt i problemet, men fremdeles ikke en god arkitekt.
I det minste, en god arkitekt skal ha følgende ferdigheter:
En arkitekt er utmerket til problemnedbrytning . Problemnedbrytning er den ferdigheten som er nødvendig for å se et problem på praktisk talt alle nivåer og bryte det ned i trinn og biter som er nødvendige for å implementere det. En god programvarearkitekt kan uttale seg som «Våre lufttrafikkontrollsystemer er utilstrekkelige og vi trenger bedre design» og kjenner spørsmålene vi må stille for å begynne å spalte problemet i oppnåelige komponenter, for å spalte disse komponentmålene til oppnåelige delprosjekter. , og dekomponere disse delprosjektene i oppnåelige programmeringsoppgaver. En god arkitekt kan gjøre disse tingene på alle nivåer eller skalaer, fra å se for seg et milliardlinjeprogramvare til å forstå den beste måten å implementere en algoritme for å takle upålitelige lenker. Skala er irrelevant fordi prosessen alltid er den samme.
En arkitekt forstår grensesnitt . Grensesnitt, enten det er i form av protokoller, funksjonsbiblioteker, klassegrensesnitt eller skjemaer er det viktigste verktøyet som trengs for å håndtere kompleksiteten i prosjekter når det er uavhengige entreprenører og implementører. Ved å kjenne prosessen med å definere skarpe, entydige grensesnitt som er logisk komplette, kan en arkitekt gi mange mennesker muligheten til å bygge deler av systemer som enkelt kobles for å oppnå et større mål.
En arkitekt forstår at kompleksitet er fienden , og behersker programmeringsverktøyene og paradigmene som er nødvendige for å redusere kompleksiteten i alle komponenter, for å redusere kompleksiteten i grensesnitt, og sikre minimal eller ingen redundans i implementeringen av funksjon. De kan raskt gjenkjenne algoritmer og implementeringer som er for spesifikke eller for generiske, og veilede de som utvikler seg for å lage komponenter som utfører akkurat den rette funksjonen. Ofte er verktøyene for å håndtere kompleksitet ting som skjuling av data, objektorientert programmering, selvvaliderende systemer og omfattende testplaner for standardgrensesnitt. Men en god arkitekt er ikke dogmatisk om verktøy og teknologier fordi de har en omfattende akademisk forståelse av grunnlaget og årsakene til at datahulling fungerer, og hvorfor visse språk støtter gode designprinsipper og andre ikke.
En arkitekt er en god kommunikator, en god og produktiv forfatter og dokumentator , og er flink til å snakke programmeringsspråket så vel som det vanlige språket til de som er interessenter i systemets design. I tillegg til god kommunikasjon, kan en god arkitekt gi konkrete grunner til programmeringspraksis i stedet for meninger, og gir innsikt til teamet sitt i stedet for argumentasjon. De favoriserer og søker brukerens mening om egnethet til det av sine egne eller programmererne som er involvert i prosjektet.
En god arkitekt er en god leder og er utmerket til å få respekt for alle de tekniske menneskene de jobber med .Vanligvis betyr dette at de har et høyt dyktighetsnivå, har jobbet på flere språk, og har vært arkitekt før, eller har demonstrert sin evne til å lage systemdesign som har holdt seg fleksible i møte med endringer.
Mange definisjoner inkluderer en rekke buzzwords, med vekt på metoder som datadrevet design, smidig programmering, spesifikke språk, plattformer og verktøysett. Disse tingene er nåværende merkelapper for forskjellige teknikker hvis grunnlag må forstås godt, ikke akseptert fordi de er for tiden på moten. Så på mange måter er arkitektens viktigste ferdigheter erfaring, intelligens, vilje til å jobbe hardt og ta en praktisk rolle, god intuisjon og evnen til å bryte ned problemer ved hjelp av logikk slik at når industriens moteord kommer og går, deres design er fortsatt nyttige og relevante.
Min definisjon ovenfor inkluderer ikke bevisst prosjektledelse, planlegging og ledelsesevner. Arkitektens rolle er å lage gode systemer, ikke å løse teamproblemer eller budsjetter. Det er faktisk best hvis de med budsjetter og teamproblemer bare er interessenter som hjelper til med å definere en av begrensningene arkitekten må håndtere, akkurat som hvis det var en del av deres designproblem.