Architectuur als architectuur                        Architecten, ontwikkelaars, testers en beheerders blijken vaak eiland...
taal                                                                                                       archItectuur   ...
als houtskoolschets om aan de hand van              of aangepaste ICT-services op basis van de         kunnen de bouwstene...
architectuur7. Presentatieservices      7.1                             7.2   Webcontent                            Portal...
projectmanager neemt de bouwstenen die in         kennen van de deployable units de indeling        generieke en specifiek...
Samenvatting                                                                                                              ...
Upcoming SlideShare
Loading in …5
×

Artikel iti 2010_nr_10._architectuur_als_taal

476 views
399 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
476
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Artikel iti 2010_nr_10._architectuur_als_taal

  1. 1. Architectuur als architectuur Architecten, ontwikkelaars, testers en beheerders blijken vaak eilandbewoners. Ieder afzonderlijk bepalen ze de functionaliteits- en kwaliteitsrisico’s van informatiesystemen en ieder voor zich streven ze naar risicobeheersing. Door architectuur als taal te hanteren is integrale beheersing van de risico’s in de gehele levenscyclus van ICT‑services mogelijk. Bart de Best V oor veel organisaties is het on- In de praktijk worden daartoe diverse projecten en changes betrokken disciplines denkbaar dat de businessservi- methoden en best practices gebruikt. Voor en hun taal, objecten en producten. ces zonder ondersteuning van architectuur wordt vaak gebruikgemaakt ICT-services worden uitgevoerd. van TOGAF, DYA en de NORA. Bij project­ De problemen Vanwege deze afhankelijkheid van ICT- management is Prince2 een best practice die Binnen veel project- en beheerorganisaties services is risicomanagement van groot veel ingezet wordt. Voor testmanagement werkt een ICT’er met slechts één methode of belang. Risicomanagement onderkent en wordt vaak TMap (NEXT) gebruikt. Uiteraard best practice. Hierdoor is het mogelijk om de beheerst risico’s in zowel projecten als chan- worden voor beheer de bestpracticemodellen kennis en kunde binnen het eigen referen- ges, die veranderingen aanbrengen in de ITIL, ASL en BiSL ingezet. Voor systeemontwik- tiekader goed te ontwikkelen. Aan de andere ondersteuning van de businessservices. Het keling wordt behalve met RUP steeds vaker kant is hierdoor een eilandcultuur ontstaan gaat dan vooral om het risico van functiona- met agile methoden zoals SCRUM gewerkt. en ziet elke discipline de ander als blackbox. liteits- en/of kwaliteitsgebreken. In figuur 1 is een overzicht gegeven van de bij Deze ontkoppeling lijkt een natuurlijk verschijnsel, want iedere discipline heeft haar eigen taakstelling, verantwoordelijk- heid en bevoegdheid in de levenscyclus van een ICT-service. Hierdoor zijn echter onder Servicemanagement Principes en Architectuur meer de volgende problemen ontstaan: CI’s modellen σσ Er is sprake van miscommunicatie door de diversiteit aan talen die gesproken Taal: ITIL Taal: TOGAF worden in de betrokken disciplines. Object: CI’s Object: modellen ICT-services Product σσ De architectuurmodellen en -principes Producten: SLA’s, RFC’s, … Producten: requirements Breakdown principes, modellen, RA, PSA, … Structure vormen slechts tot op zekere hoogte een Testplannen basis voor de functionele decompositie Deployable binnen de projecten. Dit vermindert de Testmanagement Units Projectmanagement mogelijkheden van de architectuurcon- trol in projecten. σσ De definities van de objecten (bouwste- Taal: TMap (NEXT) Taal: Prince2 Systeemontwikkeling nen, deployable units, testbasis, configu- Object: informatiesysteem Object: deliverables Producten: testplannen, Producten: projectbrief, ratie-items et cetera) binnen de gehan- testcases, testresultaten PID, PBS, faseplannen , … (defecten ) … teerde methoden en de best practices Taal: Agile Object: programmatuur zijn niet aan elkaar gekoppeld. Tevens Producten: SAD, sprint, zijn er grote verschillen in granulariteit deployable units, … (mate van gedetailleerdheid). Daardoor is het lastig om te controleren of iedere dis- Figuur 1  Eilanden van risicobeheersing ten behoeve van de ICT-services. cipline de objecten volledig en juist heeft 8  december 2010  IT-Infra
  2. 2. taal archItectuur vertaald naar het eigen werkgebied. steeds op één of meer fasen in de levenscy-σ Kwaliteitverbetering binnen het ont- clus van een ICT-service. Veel organisaties wikkelproces is niet eenvoudig doordat hanteren de werkwijze die in de volgende incidenten in de productieomgeving niet paragrafen wordt besproken. goed te herleiden zijn tot de artefacts uit het ontwikkelproces. Architectuurσ Er wordt geen synergie gehaald uit het De laatste jaren is het binnen de ICT- feit dat alle methoden en best practices architectuur een best practice om voor een mogelijkheid bieden om risico’s te een project een zogeheten Project Start onderkennen en te beheersen. De inspan- Architectuur (PSA)-document op te stellen. ning van de diverse specialisten levert Een PSA bevat de architectuurmodellen en dus geen toegevoegde waarde op voor de -principes die het kader vormen voor het ont- andere disciplines. Vooral de kennis en wikkelproces, met als basis het beleid en de kunde van de diverse specialisten worden requirements vanuit de business. De risico’s niet goed overgedragen, wat onnodig die architecten hiermee willen beheersen, gebreken in functionaliteit en kwaliteit zijn verhoging van complexiteit, realisatie van het eindproduct veroorzaakt. van voorzieningen die al bestaan, een wild- groei in het applicatie- en infrastructuur-Als architectuur als taal wordt gehanteerd, portfolio en natuurlijk afwijkingen van deworden de onderstaande negatieve effecten architectuurontwerpen van de serviceverle-voorkomen: ning (SOLL-situatie).σ In de nazorgperiode ontstaan incidenten die voorzien en voorkomen hadden kun- Projectmanagement nen worden. De projectmanager neemt de PSA in hetσ De implementaties gaan gepaard met project mee als een deliverable die door de de nodige change requests om correc- projectarchitect wordt opgeleverd. Deze ties aan te brengen op de opgeleverde PSA dient als startpunt voor de functionele functionaliteit. decompositie. Verder wordt binnen een pro-σ De SLA-normen in de productieomgeving ject een projectrisicomethode gehanteerd, staan onder druk. zoals een AK-analyse (Afhankelijkheid Kwetsbaarheidanalyse), die per te realiserenDit artikel beschrijft hoe organisaties de product een risicoclassificatie geeft. Deze ri-genoemde methoden en best practices mo- sicoduiding levert de systeemontwikkelaarsmenteel vaak toepassen. Ook geeft het aan en testers een instrument om te focussen ophoe architectuur als taal is in te zetten om bepaalde risico’s. De risico’s die projectma-de problemen op te lossen. nagement wil beheersen, zijn het niet halen van de doelen die gesteld zijn aan functiona- Samenhang methoden en best liteit en kwaliteit van de te leveren produc- practices ten zoals verwoord in het Project InitiationOmdat alle methoden en best practices hun Document (PID). Natuurlijk vallen hier ookeigen begrippenkader (taal) en objectbe- de tijd- en geldrisico’s onder, maar die vallenschrijvingen hebben, kijkt iedere specialist buiten het betoog van dit artikel.door zijn eigen bril naar de werkelijkheid.Hierbij ligt de focus voor het beheersen Systeemontwikkelingvan de functionaliteits- en kwaliteitsrisico’s De systeemontwikkelaars hanteren de PSA It-Infra december 2010 9
  3. 3. als houtskoolschets om aan de hand van of aangepaste ICT-services op basis van de kunnen de bouwstenen als individuele ser-architectuur b ­ ijvoorbeeld de agile ontwikkelmethode testresultaten en een lijst met generieke vices worden gedefinieerd. Een voorbeeld van SCRUM de gewenste functionaliteit incre- acceptatiecriteria. Deze acceptatiecriteria deze plaat is figuur 3. Hierin is tevens aange- menteel te ontwikkelen. Elke sprint (ont- zijn generiek omdat ze gelden voor alle ICT- geven welke bouwstenen nieuwe en welke werptracé) heeft een maximale duur van services. Tevens wordt aan de business een aangepaste producten bevatten. bijvoorbeeld vier weken. Een belangrijk advies voor inproductiename gegeven in het Zo kunnen ook voor applicaties, beheer- product is hierbij het Software Architecture Change Advisory Board (CAB). processen en bedrijfsprocessen bouwste- Document (SAD), dat de houtskoolschets om- Verder administreren de beheerders nenplaten opgesteld worden. Voor elke ap- zet in een kader voor de sprints. In het SAD de door projectmanagement of change­ plicatie wordt een unieke bouwstenenplaat wordt de te realiseren functionaliteit opge- management opgeleverde producten als con- opgesteld. De lagen van de plaat zijn gene- deeld in deployable units (softwaremodules). figuratie-items (CI’s) in de servicedesktool. Op riek maar kennen meestal unieke bouwste- Tevens worden er use cases opgesteld. De ri- basis van deze CI’s worden incidenten, proble- nen. Processen kunnen ingedeeld worden in sico’s die door deze aanpak van systeemont- men, changes en releases geadministreerd. diverse lagen, bijvoorbeeld voor strategische, wikkeling beheerst worden, betreffen vooral Het risico dat vanuit servicemanagement tactische en operationele processen. Tevens het niet maakbaar en haalbaar zijn van de onder­ end wordt, is het niet kunnen realise- k kunnen de producten die door deze proces- functionaliteit en kwaliteit binnen het ter ren van de servicenormen in de SLA. sen worden voortgebracht als laag worden beschikking gestelde budget. opgenomen, net als (groepen van) use cases. Werkwijze met architectuur als Alle bouwstenenplaten zijn onderdeel van Testmanagement taal het PSA. De testers hanteren testmethoden zoals De kern van het probleem is gelegen in het Het definiëren van één taal om te kun- TMap NEXT om risicogebaseerd te testen. verschil van taalgebruik en het niet spreken nen communiceren is echter niet genoeg. De De gevonden defecten worden in een testtool van elkaars taal. Daardoor wordt kennis over partijen die zijn betrokken bij het ontwikkel- geadministreerd op basis van de onderkende risico’s inefficiënt en ineffectief gedeeld. De proces en de beheerprocessen moeten deze deployable units. Testmanagement heeft als oplossing is dan ook dat de eilanden mid- bouwstenentaal ook daadwerkelijk hante- doel om vast te stellen dat de hardware en dels een soort Esperanto worden samen­ ren. Hiervoor is het nodig dat het hanteren software is opgeleverd conform de testba- gesmeed tot één totaalsysteem (figuur 2). van bouwstenen ingebed wordt in alle me- sis (waaronder bijvoorbeeld een ontwerp). Dit Esperanto kan worden ingevuld door thoden en best practices van de levenscyclus Testmanagement wil dus het risico beheer- architectuurbouwstenen te definiëren voor van een ICT-service. In de volgende paragra- sen dat de hardware en software in de pro- de bedrijfsprocessen, de beheerprocessen, de fen staat hoe dit kan worden bereikt. ductieomgeving gebreken vertonen als ge- applicaties en de infrastructuur. volg van een inadequaat testtraject. Voor het landschap van de infrastructuur Architectuur kan bijvoorbeeld een plaat worden samen- In de PSA worden alle bouwstenenplaten Servicemanagement gesteld waarin de te bieden ICT-services als opgenomen. Hierbij wordt tevens de impact De beheerorganisatie accepteert de nieuwe lagen worden opgenomen. Per servicelaag aangegeven. Dit gebeurt door in elke bouw- stenenplaat per bouwsteen te vermelden of deze binnen scope of buiten scope is voor het project. Voor de bouwstenen binnen scope Risicobeheersing vereist communicatie wordt aangegeven of deze nieuwe, gewij- zigde of ongewijzigde producten omvatten (figuur 3). Tevens wordt per bouwsteen aan- Architectuur gegeven wat de functionele en non-functio- Servicemanagement nele requirements zijn. Ditzelfde geldt voor de bouwstenenplaten van de applicaties en Bouwstenen de bedrijfsprocessen. Op deze wijze biedt een PSA een hecht kader voor het ontwikkelpro- Testmanagement Projectmanagement ces en is architectuur goed in staat om con- trol uit te oefenen op alle disciplines in het ontwikkelproces. Systeemontwikkeling Projectmanagement De projectmanager neemt de PSA niet op als deliverable van het project, maar ge- bruikt haar als basis voor het PID. De PSA Figuur 2  De eilanden samengesmeed tot één systeem, met architectuurbouwstenen als taal. wordt dus eerder opgesteld dan het PID. De 10  december 2010  IT-Infra
  4. 4. architectuur7. Presentatieservices 7.1 7.2 Webcontent Portal Hosting services service6. Applicatieservices 6.5 6.6 6.7 6.1 6.2 6.3 6.4 6.8 Individuele Groep Applicatie Webzoek Index Webcontent Document Rapportage personalisatie personalisatie platform service service service service service service service service5. Dataopslagservices 5.1 5.2 5.3 5.4 5.5 5.6 Document Applicatie Web content Account Sleutel Back-up data opslag data data data opslag opslag service service service service service service4. Platformservices 4.1 4.2 4.3 4.6 4.4 4.5 4.7 4.8 Fysieke Besturings Scaling Integrity Authenticatie Authorisatie Input Output platform systeem load balancing check service service service service service service service service3. Communicatieservices 3.1 3.2 3.3 3.4 Webserver Applicatie Database Integration communicatie communicatie communicatie broker service service service service2. Netwerkservices 2.1 2.2 2.5 2.3 2.4 Netwerk Named IP Internet IDS DMZ verkeer resolution connectie service service service service service1. Beheer- en exploitatieservices 1.1 1.6 1.2 1.3 1.4 1.5 1.7 1.8 Computer- Licentie- 3rd Party Monitor Log- alerting Uitwijk Werkplek OTAP ruimte certi caat Support service service service service service service service Bouwstenen Bouwstenen Bouwstenen Bouwstenen met met aangepaste met bestaande buiten nieuwe producten producten scope productenFiguur 3  Een bouwplaat voor het infrastructuurlandschap, met impactkleuring. IT-Infra  december 2010  11
  5. 5. projectmanager neemt de bouwstenen die in kennen van de deployable units de indeling generieke en specifieke acceptatiecriteria.archItectuur de PSA zijn beschreven als producten op in de van de bouwstenen en werken die verder De specifieke acceptatiecriteria zijn bedoeld Product Breakdown Structure (PBS) of geeft uit. Hierdoor ontstaat een goede tracering om te toetsen of de tegenmaatregelen voor per product uit de PBS aan welke bouwsteen van de functionele decompositie van archi- de onderkende risico’s het gewenste effect het betreft. Dit biedt de architecten de mo- tectuurontwerp naar functioneel ontwerp. hebben. Voor zover acceptatiecriteria niet gelijkheid om te controleren of de scope van Dit geldt ook voor de (non-)functionele re- zijn getest door testmanagement, zal de het project compleet is. Tevens kunnen zij zo quirements. Het SAD geeft hiermee dus op beheerorganisatie deze testen op basis van controleren of de functionaliteit per project- applicatieniveau verdieping aan de PSA. Op vooraf opgestelde acceptatietestplannen. De fase een consistent geheel vormt. Vervolgens deze wijze kunnen de architecten snel en testresultaten van de (acceptatie)testplan- organiseert de projectmanager drie risico- eenduidig zien of de PSA wordt nageleefd en nen maken duidelijk welke risico’s niet zijn analysesessies van elk een uur met de archi- kunnen zij bijvoorbeeld de interfaces tussen beheerst. De business wordt op basis hiervan tecten, ontwerpers, systeemontwikkelaars, de deployable units en de gekozen oplossin- in het CAB geadviseerd om de nieuwe of aan- testers en beheerders. De eerste sessie betreft de businessrisico’s, de tweede de applicatie- risico’s en de derde de infrastructuurrisico’s. Als voorbereiding voor een sessie bepaalt De kern van het probleem is gelegen elke deelnemer zelf het risico van elke bouw- steen door de betrokken blanco bouwstenen- in het verschil van taalgebruik plaat in te kleuren. De bouwstenenplaten en het niet spreken van elkaars taal kunnen dus behalve voor de impactbepaling ook voor de risicobepaling gebruikt worden. De betekenis van de kleuren van de bouwste- gen voor de (non-)functionele requirements gepaste ICT-service wel of niet in productie nen verschilt daarbij per toepassing. controleren. Per sprint wordt de risicolijst te nemen. Een bouwsteen wordt rood gekleurd bij gecontroleerd. Tevens wordt per sprint een Verder kunnen de beheerders op basis een hoog risico, geel bij een medium risico aanvullende risicoanalysesessie gehouden van de bouwstenen de CI’s classificeren. Zo en groen bij een laag risico. Bouwstenen die met alle betrokkenen. Alle use cases of groe- kan in de servicedesktool een attribuut aan buiten scope zijn, worden grijs gekleurd. pen van gelijksoortige use cases worden dan het CI toegevoegd worden dat beschrijft voor Hierbij wordt rekening gehouden met de im- grafisch afgebeeld op de betrokken applica- welke bouwsteen het CI is ingezet. Hierdoor pactbepaling van de architecten (figuur 3). tie- en infrastructuurbouwstenen.1 Hierbij kan architectuur de ingezette producten per Tijdens de risicosessies wordt eerst de impact kunnen vooral risico’s ten aanzien van de bouwsteen bewaken. Tevens kan op basis van bepaald. Hierop kunnen namelijk nog cor- non-functionele requirements in kaart wor- de bouwstenenplaten de impact van nieuwe recties van toepassing zijn. Daarna worden den gebracht. Deze worden op dezelfde wijze changes beoordeeld worden. De per bouw- de verschillen tussen de risicokleurenplaten geadministreerd en beheerst als eerder be- steen aangegeven risicolijst en risicoweging besproken. Als is vastgesteld welke bouwste- schreven onder ‘Projectmanagement’. kunnen als basischecklist gebruikt wor- nen rood of geel zijn, wordt bepaald welke den voor de risicoanalyse van deze nieuwe risico’s aanleiding zijn voor deze inkleuring. Testmanagement changes. De hieruit voortgekomen risico’s worden op- De bouwstenen vormen voor de testers een Doordat de CI’s gerelateerd worden genomen in de risicolijst en geclassificeerd bijzonder belangrijk instrument. Aan de aan incidenten, problemen, known errors, op basis van de kans en de impact. Tevens hand hiervan kunnen zij de scope van het changes en releases, is impliciet ook de re- wordt per risico bepaald welke preventieve testgebied aangeven. Tevens zijn per bouw- latie gelegd met de diverse bouwstenen. en correctieve maatregelen mogelijk zijn. steen de (non-)functionele requirements, Op basis hiervan kan problemmanagement Na het bepalen van de eigenaar wordt aan risico’s en tegenmaatregelen bekend. Dit vaststellen voor welke bouwstenen de kwa- de business gevraagd welke risico’s zij wil- vormt een solide basis om in het master- liteitsbeheersing van testmanagement wel len beheersen, welke mitigeren en welke testplan de focus te definiëren voor de testin- of niet effectief genoeg is. Tevens kan de oor- nemen. spanning. Tevens vormen de bouwstenen zaak van het niet halen van servicenormen Op basis van deze risicosessies bevatten een belangrijk attribuut van de logische en als gevolg van incidenten herleid worden de bouwstenen, die als product in de PBS zijn fysieke testcasedefinities in de diverse test- tot de gewijzigde bouwstenen en van hier- opgenomen, dus informatie over de impact, plannen. Tot slot geeft de bouwsteenclassifi- uit tot de gebreken in het ontwikkelproces. de gewogen en vastgestelde risico’s, de te- catie de mogelijkheid om het succes van de Eén keer per kwartaal wordt een problem- genmaatregelen, de betrokken producten risicobeheersing grafisch te rapporteren. managementrapportage opgesteld waarin én de (non-)functionele requirements. staat aangegeven welke bouwstenen de Servicemanagement meeste gebreken hebben. Voor deze bouw- Systeemontwikkeling De beheerorganisatie hanteert voor de accep- stenen wordt in projecten extra aandacht De ontwerpers hanteren voor het onder- tatie van nieuwe of aangepaste ICT-services gevraagd. 12 december 2010 It-Infra
  6. 6. Samenvatting Column security mattersIn de levenscyclus van een ICT-service zijndiverse disciplines werkzaam om te komentot het gewenste resultaat. Er ontbreekt in Gevaar onder dede diverse methoden en best practices vandeze disciplines een gemeenschappelijke kerstboomtaal om de functionaliteits- en kwaliteitsri-sico’s adequaat te onderkennen en beheer-sen. Daardoor ontstaan tal van problemen G ezellig. De boom staat al, de lichtjes branden weer. Glaasje erbij, voeten op tafel. Nee, mij kan niets gebeuren. Natuurlijk staat er een emmer water naast dedie eenvoudig voorkomen kunnen worden. boom. Voor als de boom in de fik vliegt. Ik heb al lang geenEen Esperanto dat alle werelden bij elkaar echte kaarsen meer, maar die emmer, die hoort erbij. Verderkan brengen, is het werken met architectuur- heb ik, voor de zekerheid, een brandblusser paraat. En debouwstenen. Om deze taal effect te laten sor- kinderen dragen, gelijk de familie Von Trapp in The Sound ofteren moeten de bouwstenen verankerd wor- Music, kleding gemaakt van oude branddekens.den in alle methoden en best practices die Uit onderzoek van een voormalige staatsbank blijkt dat hetgehanteerd worden in de levenscyclus van mkb bedrijfsrisico’s consequent te laag inschat. Dit betrefteen ICT-service. Hiermee wordt niet alleen vooral risico’s van brand, langdurige ziekte, wanbetaling ende controlfunctie van architectuur versterkt, ICT-risico’s.maar is tevens een hefboom gevonden om Is dat bij u ook zo? Stelt u zich uw worstcasescenario voor.risico’s in het ontwikkelproces veel effectiever Waarvan ligt u wakker? Neem bijvoorbeeld de frauderendeen efficiënter te onderkennen en te beheer- controller. Of het faliekant mislukken van de invoering vansen en daarmee gebreken in de functionali- een nieuw informatiesysteem.teit en kwaliteit van de nieuwe of gewijzigdeinformatiesystemen te voorkomen.Met dank aan de vele reviewers, met name Zou uw bedrijfLouis van Hemmen (Bitall), Stephen Klomp (Sogeti),Andre Wessels (ROC van Twente), Henk van Garderen na drie maanden(Robert Hunter), Vince Mathu (Gemeente Almere),Jane ten Have (APG AM), Bram Abbekerk (Belasting­ nog bestaan alsdienst), John Wolthuis (ICT4People), Fred Ros (Rijks­ uw grootste klantauditdienst), Edwin Edang (Edang Management Consultancy) en Alexander Dortland (Proximity failliet ging?Softworks). H et faillissement van uw grootste klant is ook een leuke. En het uitbranden van een dataruimte. Zou uw bedrijf dan na drie maanden nog bestaan? Zijn er voldoende buf- fers? Is er een alternatieve werkwijze? Die drie maanden is een praktijkwaarde: als er in drie maanden niets te impro- viseren is, lukt dat ook in een jaar niet. Mijn onder-de-boomopdracht voor u is: verzin uw drie erg- ste nachtmerries. Deze risico’s vormen de Top Drie voor uw risicomanagement voor 2011. Deze risico’s pakt u aan. En over een halfjaar verzint u weer nieuwe hoofdpijnscenario’s. Nee, ik heb geen echte boom, maar zo’n saai, brandveilig Voetnoot namaakexemplaar. Vroeger noemden we dat een kunst-1.  B. de Best, ‘Verzekeraar beheerst de risico’s boom. Maar ja, ‘kunst’ is een linkse hobby en dat mag nietvan SOA’, IT Beheer Magazine 2007, nr. 9. meer. Dus ik noem dezelfde boom nu ‘duurzaam’. Probleem opgelost. Fijne feestdagen en een veilig 2011. Meer lezenσσ B. de Best, Beheren onder Architectuur, Dr. ir. Paul Overbeek RE NGN, 2008. Combineert een eigen praktijk met docentschappen aan de universiteitenσσ B. de Best, Acceptatiecriteria, SDU, Erasmus, Tilburg en Amsterdam (www.ois-nl.eu of Paul.Overbeek@ois-nl.eu). tweede druk.Drs. ing. Bart de Best RI (bdebest@sca-alliance.com). IT-Infra  december 2010  13

×