Bästa svaret
Det finns inga formella definitioner av dessa roller som allmänt antas som standard av organisationer, så det kommer att bli mycket variation och lokaliserat sammanhang.
Som en allmän guide använder jag följande definitioner:
- Teknisk arkitekt – En specialist inom områden som är inriktade till infrastruktur, nätverk och säkerhet.
- Lösningsarkitekt – En generalist som ansvarar för projektbaserade lösningar som tar hänsyn till alla aspekter av en lösning (t.ex. affärspåverkan, applikationsändringar, data- och informationshänsyn och tekniken som stöder allt detta), och förhoppningsvis också kundöverväganden.
- Huvudarkitekt – Någon med bredare ansvarsområden än ovanstående roller. Detta kan fokuseras på en företagsdomän, ett större arbetsprogram eller ett helt företag. Det används ofta av konsultföretag för att föreslå en nivå av (erfarenhets) överlägsenhet över andra arkitekter i teamet. De kommer normalt att ha generalistiska bekymmer snarare än att fokusera på en enda arkitekturdomän som infrastruktur, men det är inte alltid fallet.
Jag hoppas att det hjälper. Det är viktigt att komma ihåg att det finns inga accepterade standarder, så själva termerna är specifika för den miljö de används i.
Svar
Först är det viktigt att skilja programvaruarkitektur från helt enkelt bästa praxis. En bra programvarutekniker kan vara utmärkt på kodning, utmärkt och detaljerad i sitt tillvägagångssätt och ha en hel del insikt i problemet, men kan ändå inte vara en bra arkitekt.
Åtminstone en bra arkitekten bör ha följande färdigheter:
En arkitekt är utmärkt vid problemnedbrytning . Problemnedbrytning är den färdighet som krävs för att se ett problem på praktiskt taget vilken nivå som helst och dela upp det i de steg och delar som är nödvändiga för att genomföra det. En bra programvaruarkitekt kan ta ett uttalande som ”Våra flygtrafikstyrningssystem är otillräckliga och vi behöver en bättre design” och känner till frågorna för att börja sönderdela problemet i komponenter som kan uppnås, att sönderdela dessa komponentmål till uppnåeliga delprojekt. och sönderdelar dessa delprojekt i uppnåbara programmeringsuppgifter. En bra arkitekt kan göra dessa saker på vilken nivå eller skala som helst, från att föreställa sig ett miljaradsprojekt till att förstå det bästa sättet att implementera en algoritm för att hantera opålitliga länkar. Skalan är irrelevant eftersom processen alltid är densamma.
En arkitekt förstår gränssnitt . Gränssnitt, antingen i form av protokoll, funktionsbibliotek, klassgränssnitt eller scheman är det primära verktyget som behövs för att hantera komplexiteten i projekt när det finns oberoende entreprenörer och implementerare. Genom att känna till processen för att definiera skarpa, otvetydiga gränssnitt som är logiskt kompletta kan en arkitekt ge många människor möjlighet att bygga delar av system som enkelt kan anslutas för att uppnå ett större mål.
En arkitekt förstår att komplexitet är fienden och behärskar de programmeringsverktyg och paradigmer som är nödvändiga för att minska komplexiteten i alla komponenter, för att minska komplexiteten i gränssnitt och säkerställa minimal eller ingen redundans vid implementering funktion. De kan snabbt känna igen algoritmer och implementeringar som är för specifika eller för generiska, och vägleda dem som utvecklas för att skapa komponenter som utför precis rätt funktion. Ofta är verktygen för att hantera komplexitet saker som att dölja data, objektorienterad programmering, självvalideringssystem och omfattande testplaner för standardgränssnitt. Men en bra arkitekt är inte dogmatisk om verktyg och tekniker eftersom de har en omfattande akademisk förståelse för grunden och skälen till att datadölj fungerar och varför vissa språk stöder goda designprinciper och andra inte.
En arkitekten är en bra kommunikatör, en bra och produktiv författare och dokumentator , och är bra på att tala programmeringsspråket såväl som det gemensamma språket för dem som är intressenter i systemets design. Tillsammans med god kommunikation kan en bra arkitekt ge konkreta skäl för programmeringsmetoder snarare än åsikter och ger insikt till sitt team snarare än argument. De gynnar och söker starkt användarens uppfattning om lämplighet för det av deras egna eller de programmerare som är inblandade i projektet.
En bra arkitekt är en bra ledare och är utmärkt för att få respekt för alla tekniska personer de arbetar med .Vanligtvis innebär detta att de har en hög skicklighet, har arbetat på flera språk och varit arkitekt tidigare eller har visat sin förmåga att skapa systemdesigner som har förblivit flexibla inför förändringar.
Många definitioner innehåller en rad modevärden som betonar metoder som datadriven design, smidig programmering, specifika språk, plattformar och verktygssatser. för närvarande på modet. Så på många sätt är arkitektens främsta färdigheter erfarenhet, intelligens, villighet att arbeta hårt och ta en praktisk roll, god intuition och förmågan att bryta ner problem med hjälp av logik så att när industriens slagord kommer och går, deras design förblir användbar och relevant.
Min definition ovan inkluderar avsiktligt inte projektledning, schemaläggning och ledningsförmåga. Arkitektens roll är att skapa bra system, inte att lösa teamproblem eller budgetar. Det är faktiskt bäst om de med budgetar och teamfrågor helt enkelt är intressenter som hjälper till att definiera en av de begränsningar som arkitekten måste hantera, precis som om det var en del av deras designproblem.