Beste antwoord
Er zijn geen formele definities van deze rollen die algemeen als standaard worden aangenomen door organisaties, dus er zal veel variatie en gelokaliseerde context zijn.
Als algemene richtlijn gebruik ik de volgende definities:
- Technisch architect – Een specialist op naar infrastructuur, netwerken en beveiliging.
- Solution Architect – Een generalist die verantwoordelijk is voor projectgebaseerde oplossingen die rekening houden met alle aspecten van een oplossing (bijv. bedrijfsimpact, applicatiewijzigingen, gegevens- en informatieoverwegingen en de technologie die ondersteunt alles), en hopelijk ook overwegingen van klanten.
- Principal Architect – Iemand met een bredere reeks verantwoordelijkheden dan de bovenstaande rollen. Dit kan gericht zijn op een zakelijk domein, een groter werkprogramma of de hele onderneming. Het wordt ook vaak gebruikt door adviesbureaus om een niveau van (ervarings) superioriteit ten opzichte van andere architecten in het team te suggereren. Ze zullen normaal gesproken algemene zorgen hebben in plaats van zich te concentreren op één architectuurdomein, zoals infrastructuur, maar dat is niet altijd het geval.
Ik hoop dat dat helpt. Het is belangrijk te onthouden dat er geen geaccepteerde standaarden, dus de termen zelf zijn specifiek voor de omgeving waarin ze worden gebruikt.
Antwoord
Ten eerste is het belangrijk om softwarearchitectuur te onderscheiden van louter best practices. Een goede software-engineer is misschien uitstekend in codering, uitstekend en gedetailleerd in zijn aanpak, en heeft veel inzicht in het probleem, maar is nog steeds geen goede architect.
Op zijn minst een goede architect moet de volgende vaardigheden hebben:
Een architect is uitstekend in het oplossen van problemen . Probleemontleding is de vaardigheid die nodig is om een probleem op vrijwel elk niveau te zien en het op te splitsen in de stappen en stukken die nodig zijn om het te implementeren. Een goede softwarearchitect kan een uitspraak doen als Onze luchtverkeersleidingssystemen zijn inadequaat en we hebben een beter ontwerp nodig en kent de vragen die gesteld moeten worden om het probleem op te splitsen in haalbare componenten, om die componentdoelen op te splitsen in haalbare deelprojecten , en deze deelprojecten opsplitsen in haalbare programmeertaken. Een goede architect kan deze dingen op elk niveau of elke schaal doen, van het bedenken van een softwareproject met een miljard regels tot het begrijpen van de beste manier om een algoritme te implementeren om met onbetrouwbare koppelingen om te gaan. Schaal is niet relevant omdat het proces altijd hetzelfde is.
Een architect begrijpt interfaces . Interfaces, in de vorm van protocollen, functiebibliotheken, klasse-interfaces of schemas, zijn het belangrijkste hulpmiddel dat nodig is om de complexiteit van projecten te beheren als er onafhankelijke contractanten en uitvoerders zijn. Door het proces te kennen van het definiëren van heldere, ondubbelzinnige interfaces die logisch compleet zijn, kan een architect veel mensen in staat stellen om stukjes van systemen te bouwen die gemakkelijk met elkaar kunnen worden verbonden om een groter doel te bereiken.
Een architect begrijpt dat complexiteit de vijand is , en beheerst de programmeertools en paradigmas die nodig zijn om de complexiteit van alle componenten te verminderen, de complexiteit van interfaces te verminderen en een minimale of geen redundantie van de implementatie te garanderen van functie. Ze kunnen snel algoritmen en implementaties herkennen die te specifiek of te algemeen zijn, en degenen die zich ontwikkelen begeleiden om componenten te maken die precies de juiste functie vervullen. Vaak zijn de tools voor het beheren van complexiteit zaken als het verbergen van gegevens, objectgeoriënteerd programmeren, zelfvaliderende systemen en uitgebreide testplannen voor standaardinterfaces. Maar een goede architect is niet dogmatisch over tools en technologieën omdat ze een uitgebreid academisch begrip hebben van de onderbouwing en redenen waarom het verbergen van gegevens werkt, en waarom bepaalde talen goede ontwerpprincipes ondersteunen en andere niet.
Een architect is een goede communicator, een goede en productieve schrijver en documentor , en is goed in het spreken van de programmeertaal en de gemeenschappelijke taal van degenen die belanghebbenden zijn in het ontwerp van het systeem. Naast goede communicatie kan een goede architect concrete redenen geven voor programmeerpraktijken in plaats van meningen, en geeft hij inzicht aan zijn team in plaats van argumenten. Ze geven een sterke voorkeur aan en zoeken de mening van de gebruiker over geschiktheid voor die van henzelf of de programmeurs die bij het project betrokken zijn.
Een goede architect is een goede leider en is uitstekend in het verwerven van het respect van alle technische mensen ze werken met .Meestal betekent dit dat ze een hoog vaardigheidsniveau hebben, in meerdere talen hebben gewerkt en eerder architect zijn geweest, of hebben aangetoond dat ze in staat zijn om systeemontwerpen te maken die flexibel zijn gebleven ondanks veranderingen.
Veel definities bevatten een reeks modewoorden, met de nadruk op methodologieën zoals datagestuurd ontwerp, agile programmeren, specifieke talen, platforms en toolkits. Dit zijn huidige labels voor verschillende technieken waarvan de basis goed moet worden begrepen, niet geaccepteerd omdat momenteel in zwang. Dus in veel opzichten zijn de belangrijkste vaardigheden van een architect ervaring, intelligentie, bereidheid om hard te werken en een praktische rol te spelen, een goede intuïtie en het vermogen om problemen op te lossen met behulp van logica, zodat als industrie-modewoorden komen en gaan, hun ontwerpen blijven nuttig en relevant.
Mijn bovenstaande definitie omvat met opzet geen projectmanagement, planning en managementvaardigheden. De rol van de architect is om goede systemen te creëren, niet om teamproblemen of budgetten op te lossen. In feite is het het beste als degenen met budgetten en teamproblemen gewoon belanghebbenden zijn die helpen bij het definiëren van een van de beperkingen waarmee de architect te maken heeft, net zoals als het deel uitmaakte van hun ontwerpprobleem.