For mere end to år siden meldte jeg mig frivilligt som betatester til Sun Microsystems Certified Enterprise Architect for J2EE (Java 2 Platform, Enterprise Edition) Technology eksamen. Jeg kiggede på den planlagte pensum og så værdien i certificeringen, så jeg besluttede at gå efter den. Fire måneder og meget hårdt arbejde senere modtog jeg mit certifikat og badge i posten, næsten som om jeg var blevet medlem af en meget udvalgt fanklub! Var det det værd? Med et ord, ja. Mit ligefremme mål var certificering, men jeg blev glædeligt overrasket over, at certificeringsprocessen åbnede mine øjne for ideer og tilgange, som jeg simpelthen ikke havde haft tid til at undersøge i trængsel og travlhed i mit daglige job. Jeg fortsætter med at engagere mig med Sun om eksamensindholdet og strukturen og er i øjeblikket eksaminator til testen. I denne artikel deler jeg mine erfaringer og vælger også hjernen til Mark Cade, hovedudvikler af Suns J2EE arkitekteksamen. Læs videre, hvis du vil blive en Sun-certificeret J2EE-arkitekt.
Hvorfor blive certificeret?
Kort sagt, enhver certificering er kun så god som det tildelende organ. I vores tilfælde er det tildelende organ Sun, firmaet bag J2EE. Det gør certificeringen af støbejern i min bog. Mange andre certificeringer er tilgængelige fra forskellige Java-leverandører, men Sun ønsker at certificere og godkende arkitekter til J2EE-platformen, ikke til applikationsserveren X, Y eller Z.
Generelt diskuteres værdien af certificering - hvad enten det er fra et universitet eller en virksomhed - ofte i vores branche. Jeg har ikke brug for et certifikat for at blive praktiserende softwareingeniør hverken i USA eller i Europa, i modsætning til de fleste andre erhverv. Fantastisk, siger nogle. Vores unikke hackerkultur ændrer den måde, verden fungerer på. Vi lever eller dør af vores kodningsfærdigheder, ikke af en eller anden tørret institutions opfattelse af os. Boo, siger andre. Fly-by-night-kodere producerer ikke-standardkode og udokumenterede, ufleksible systemer, der ofte ikke er robuste nok.
Begge lejre har gyldige argumenter. Men min mening er klar: Jeg ser værdien i branchesponserede certificeringer. Og alt andet lige vurderer jeg en certificeret J2EE-arkitekt højere end en ikke-certificeret arkitekt. Der er langt flere svage ikke-certificerede arkitekter end svage solcertificerede arkitekter.
Hvad eksamen er
Lad os være stumpe: J2EE-arkitektcertificeringseksamen er en meget god måde at differentiere dit CV på. Kandidater, der konstant sørger for, at de er hurtige til de nyeste teknologier og har afgørende certificeringer i deres valgte teknologier, er vel motiverede mennesker, der tilføjer værdi til deres virksomheder, både som enkeltpersoner og som holdspillere. Som Sun's Cade siger, "Certificering giver dig mulighed for at få din fod i døren. Hvis for eksempel rekrutterere ser på to kandidater til en arkitektstilling, og den ene har certificeringen, og den anden ikke, hvem tror du de vil overveje først? "
Det kan faktisk være sjovt at arbejde hen imod certificering. Har du nogensinde ønsket at undersøge et bestemt afsnit af Unified Modelling Language (UML) eller Enterprise JavaBeans (EJB) -specifikationen eller ønsket at opdatere på et designmønster, du ikke har brugt i et stykke tid? Jeg brugte min certificeringsrevisionstid til at gøre mig selv til en bedre arkitekt. Del 2 lod mig for eksempel evaluere UML-modelleringsværktøjer, jeg havde kløet for at prøve, mens del 1 gav mig muligheden for at uddybe de forretningsintegrationsaspekter, som jeg ikke havde brugt før, som skærmskrabning og ældre integration. J2EE-certificering er bestemt ikke let - det er hårdt arbejde. Men hvis du kan lide at være J2EE-arkitekt, vil du nyde certificeringsprocessen. Der er en ægte følelse af præstation, når du har bestået eksamen.
Hvad eksamen ikke er
Jeg spurgte Cade, hvad certificeringen ikke kunne teste. Hans svar i en nøddeskal: "Certificering er ikke en erstatning for erfaring." Som Yoda måske siger, "en eksamen laver ikke en arkitekt." Forsøg ikke at starte dig selv med en J2EE-arkitektcertificering, hvis du ikke har færdighederne til at bakke det op. For det første vil du kæmpe for at bestå eksamen, og for det andet er det en anvendt færdighed at være J2EE-arkitekt; hvis du ikke har know-how, bliver du hurtigt eksponeret.
Et andet punkt er, at arkitekteksamen er subtilt forskellig fra Suns andre Java-certificeringer. "Arkitekteksamen er mere abstrakt, ligesom arkitektur er. Programmøreksamen tester, om en person forstår sproget. Udviklereksamen tester, om en person kan anvende sproget for at løse et problem. Og arkitekteksamen tester, om en person kan bruge hans viden til arkitekt en løsning, som en udvikler kunne implementere, ”forklarer Cade.
Typisk kandidatprofil
Den typiske succesrige kandidat falder i to hovedgrupper: stærke senioringeniører, der allerede er arkitekter i alt undtagen navn, og veletablerede arkitekter, muligvis fra andre teknologidiscipliner, der bruger arkitektcertificeringen til at krydse tog til J2EE eller simpelthen børste op deres J2EE ekspertise.
Java-færdigheder vil ikke være et problem for en succesrig kandidat. Snarere er udfordringen at vise, at du kan udtænke og kommunikere et robust og korrekt J2EE-softwaredesign til et givet problem. Andre vigtige færdigheder inkluderer evnen til at forstå, at der ikke altid er et perfekt svar på hvert givne problem, og til at forsvare dit foreslåede design sammenhængende og sammenhængende til en eksaminator.
Eksamen anatomi
Eksamen er opdelt i tre sektioner, der hver er designet til at teste et andet aspekt af dine færdigheder. Figur 1 illustrerer de nødvendige trin for at blive en Sun-certificeret J2EE-arkitekt.
Del 1
Del 1 består af 48 multiple choice-spørgsmål, der dækker alle aspekter af virksomhedsapplikationsdesign med stærkt fokus på EJB-specifikationen og arkitekturen. Del 1 tester dig om emner fra designmønstre til EJB-specifikationens kerneinterfaces. Du har brug for at kende EJB indefra og ude - de forskellige typer, deres livscyklusser. Du skal forstå EJB-containere og potentielle EJB-faldgruber. Du har også brug for en stærk forståelse af andre J2EE-teknologier, som f.eks. JavaServer Pages (JSP), servlets, Java Database Connectivity (JDBC) og XML-support. Lær de vigtigste designmønstre og deres grupperinger; genkende dem fra deres UML "signaturer." Business-to-business (B2B) arkitekturspørgsmål kan også komme frem.
Du skal bestå del 1, før du flytter til del 2.
Del 2
Del 2 er hjertet i eksamen. I dette afsnit skal kandidater indsende deres J2EE-baserede løsninger til et givet forretningsscenarie. Af åbenlyse grunde kan jeg ikke afsløre de faktiske anvendte forretningsscenarier, det er tilstrækkeligt at sige, at de indeholder både B2C (business-to-consumer) og B2B-aspekter. Der er ikke meget forberedelsesarbejde, der kan udføres her; du skal blot bruge dine praktiske færdigheder til at udvikle en J2EE-baseret løsning. Tydelig kommunikation er afgørende; du skal overbevise eksaminatoren om, at du ved hvad du laver. Antag ikke noget. Alle leverede diagrammer skal være UML-kompatible.
Del 3
I del 3 skal kandidater besvare en række spørgsmål om deres del 2-indlæg. Disse spørgsmål undersøger din evne til at analysere dit design objektivt og sikrer også, at du har indgående kendskab til dit foreslåede systems nøgleaspekter, herunder vedligeholdelsesevne, ydeevne og skalerbarhed. Dine svar på disse spørgsmål vil være tilgængelige for den samme eksaminator, der korrigerer din del 2-indsendelse, og han vil krydshenvise de leverede svar med den indsendte løsning for at evaluere dine essaysvar.
Eksamenstips
Lad os komme ned til messingstifterne. Hvilket råd kan jeg tilbyde potentielle kandidater? Her er de bedste fejl, jeg har set i del 2 og del 3 indsendelser. Jeg fokuserer ikke på del 1, da det er en ligetil valg med flere valg; enten kender du de rigtige svar, eller ikke. Figur 2 viser de vigtigste aspekter af både vellykkede og mislykkede eksamensindgivelser, baseret på feedback fra direkte eksaminator siden J2EE-arkitekteksamen blev lanceret.
Top indsendelsesfejl
- Mangler helt eksamenspunktet. Eksamen er designet til at teste dine færdigheder som J2EE-arkitekt. Al din indsats bør fokusere på at løse det givne forretningsproblem og ikke være fastgjort i møtrikker og bolte i esoteriske J2EE-problemer. Sikker på, er du også velkommen til at adressere disse punkter, men lad ikke din forretningsløsning lide under dette.
- Slurvet indlæg. Sun forventer, at folk bruger mellem 30 og 40 timer på at arbejde på eksamen. Med den tid skal dine indsendelser ikke indeholde typografier, uklare UML-diagrammer, ufuldstændige argumenter / begrundelser og manglende leverancer. Vær stolt af din løsning og sørg for, at det er din bedste indsats.
- Alt for komplekse indlæg. Nogle kandidater går i overdrive og forvandler et godt styret virksomhedssystem til det næste Amazon.com. Gå tilbage og sørg for, at din indsendelse er så detaljeret som muligt, men ikke alt for. Overflødigt indhold forringer den overordnede standard og gør det sværere for din eksaminator at tildele karakterer.
- Ufuldstændige / utilstrækkelige svar til del 3. Mange kandidater lægger simpelthen ikke nok kræfter i del 3 (essayspørgsmålene). Sørg for at give komplette svar, og sikkerhedskopier dem med referencer til bestemte dele af din foreslåede arkitektur. Og bemærk, at det er godt, at din applikation er god, fordi den er J2EE-baseret, ikke udgør et tilstrækkeligt forsvar af standardsystemkarakteristika, såsom skalerbarhed, vedligeholdelsesevne og ydelse.
Endelig, hvis du ikke består eksamen, skal du lære af dine fejl. Hvis du mener, at du har den rigtige profil, og at du mislykkedes på grund af dårlig eksamensmetode eller forberedelse, skal du lægge den bag dig og omgruppere. Alle indlæg modtager en oversigt over, hvor karakterer er tildelt og trukket. Brug dette til at identificere svaghederne i din indsendelse. Når du først har løst disse svagheder, skal du sende den igen.
Lad os se på de fælles kendetegn ved vellykkede indsendelser på bagsiden.
Vellykkede indsendelsesegenskaber
- Korrekt forberedelse og tilstrækkelig tid brugt på indsendelser. Succesrige kandidater forstår, hvad de bliver bedt om at give, og gør det derefter. Det er så simpelt. En god teknik til del 2 er konstant at spørge dig selv, om du arbejder på, hvad du skal være. Forbliv disciplineret. Forstå spørgsmålene og bliv på rette spor.
- Klare, kortfattede indlæg. Vellykkede indsendelser kan variere i længde, men indholdet bestemmer, om du består eller ikke. Et nyttigt tip er at spille djævelens advokat med hvert afsnit i din indsendelse. Hvor er svaghederne? Hvis du ikke havde skrevet det, ville du forstå det? Bed en kollega om at gennemgå din løsning, inden du sender den. Det er forbløffende, hvad et andet par øjne kan fange.
Med hensyn til del 2 skal du ikke hænge på, hvilket modelleringsværktøj du bruger til at generere de angivne UML-leverancer. Klarhed og korrekthed bør være dine hovedmål. Ethvert værktøj, du vælger, er fint, så længe du holder fast ved de angivne leverancer (f.eks. En hovedindeks.html-side).
Fremtidige eksamener
Som afspejling af de fremskridt, J2EE og dets indbyggede teknologier fortsætter med at gøre, er arkitekteksamen selv under revision. Den opdaterede eksamen dækker J2EE 1.4, J2EE designmønstre, Java Connector Architecture (JCA) og designmetoder såsom Rational Unified Process (RUP) og ekstrem programmering (XP). Andre planlagte udvidelser til det nuværende format inkluderer en feedbackmekanisme, der gør det muligt for eksaminatorer at forespørge kandidater om specifikke punkter i deres arkitektur.
Den fornyede eksamen involverer ikke ansigt til ansigt interviews med potentielle kandidater. Som Cade siger, "Meget af at være arkitekt er i stand til at kommunikere dine ideer skrevet og mundtligt. Vi kan fange den skriftlige del af kommunikationen, men vi kan ikke vurdere kandidater på deres verbale evner. Derfor skal arbejdsgivere have et grundigt interview behandle."
Et interessant fænomen er, at løsninger, der er indsendt til del 2 i løbet af det sidste år, har ændret sig, selvom selve eksamenen ikke har gjort det. Fremkomsten af webtjenester og et skridt mod en mere modulær, servicedrevet tilgang til arkitektur generelt afspejler sig i de typer af løsninger, kandidaterne indsender. Det repræsenterer for mig en af arkitekteksamenens reelle værdier. Det fortsætter med at forblive relevant, selvom de foretrukne teknikker og underliggende teknologier ændrer sig og modnes.
Sig din mening
Forhåbentlig har du nu en klarere fornemmelse af Suns J2EE-arkitektcertificering og forstår, hvorfor jeg mener, det er værd at forfølge. Det er hårdt arbejde, men belønningen er, at du efter en vellykket afslutning bliver en bedre arkitekt. Arkitekteksamen er i øjeblikket ved at blive revideret for at holde trit med J2EE-platformen, og Sun glæder sig over dit input til eksamensindholdet og strukturen.
Hvis du har nogle ideer til, hvordan du forbedrer eksamen, vil jeg meget gerne høre dem. Brug JavaWorld feedbackformular (se Ressourcer) for at sende os dine tanker. Det er en fantastisk måde at hjælpe med at påvirke den næste fase af arkitektcertificeringsprocessen.
Sektionen Ressourcer nedenfor indeholder nyttige links til at komme i gang. Eksamen er ingen erstatning for praktisk arkitektonisk oplevelse, men det er et godt supplement til den oplevelse, især hvis du omfavner certificeringsarbejdet som en mulighed for at udfylde huller i din viden. Hvis du i øjeblikket arbejder hen imod eksamen, held og lykke! Hvis ikke, hvorfor ikke?
