Archief - De (on)zin van IT architectuur
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
the_fox
Legacy Member
2 full-time developers voor een open-source pakket te onderhouden... Die ga je al niet snel vinden, en die gaan er (gezien het verloop binnen de IT) ook niet lang zitten. Dus je moet quasi constant aanwervingen doen en interne opleidingen geven voor je custom-built oplossing. Ik zie daar geen ROI in eerlijk gezegd. Om nog maar te zwijgen over een aantal dingen die in de open-source wereld schering en inslag zijn. Wat als een deel van de core contributors opeens beslist om te forken? Een deel van de paketten die je gebruikt worden opeens ondersteund in de ene fork, de andere in de andere fork... Of het project sterft een stille dood...Radiance zei:
En daar benoem je net deel van het probleem: Bedrijven die 5j geleden al een ontwikkeling hadden gingen dus niet voor open-source gaan. Bedrijven (en dan heb ik het over grote en geen KMO's of startups) gaan nooit kiezen voor iets dat 5j geleden nog niet bestond.Radiance zei:Dat was nu net het doel van het topic, deze discussie voeren5 jaar geleden had je zwart (big vendors met 60% markup, support contracten etc..) of wit (open-source, unsupported, gratis). Wel vandaag heb je ook de keuze uit 50 tinten grijs
Short-term ROI kan zo misschien behaald worden, maar op lange termijn verkiest men liever zekerheid.
Exact, grote bedrijven gaan bijna nooit voor cutting-edge software of open-source omdat alles eerst getest en goedgekeurd moet worden alvorens het in een productieomgeving toegepast wordt. Ik ga mensen ook gewoon vierkant uitlachen als ze zeggen dat ze een update van een open-source pakket de dag na release uitrollen in een productieomgeving. Zo werkt het nu eenmaal niet.Nineshots zei:
en @paradijsappel: niks maakt zijn klanten zo speciaal, wat hij beschrijft is de normale gang van zaken.
Nineshots
Legacy Member
Farma industrie is een simpel voorbeeld. Het is niet van technisch niet mogelijk zijn. Het is gewoon volgens de regels dat dit nu niet mogelijk is.
En in de toekomst, mag er al een heel zware verandering gebeuren op vlak van testing mogelijkheden waarbij het zou kunnen.
Op dit moment is het niet mogelijk om alles automatisch te laten testen, daar staat de technologie nog niet ver genoeg voor.
Dan moet de regelgeving ook nog eens volgen, dus het is sowieso niet voor morgen.
Ik denk niet dat enig van mijn toekomstige klanten dit nog zal klaarspelen in de tijd dat ik werk.
En in de toekomst, mag er al een heel zware verandering gebeuren op vlak van testing mogelijkheden waarbij het zou kunnen.
Op dit moment is het niet mogelijk om alles automatisch te laten testen, daar staat de technologie nog niet ver genoeg voor.
Dan moet de regelgeving ook nog eens volgen, dus het is sowieso niet voor morgen.
Ik denk niet dat enig van mijn toekomstige klanten dit nog zal klaarspelen in de tijd dat ik werk.
eniac
Legacy Member
RadicalAtheist zei:
Interessante reply dit, wou er toch even op antwoorden. Ik ben zelf ook architect (integratie, solution architect). Ik kom vanuit een ontwikkelaars-achtergrond, en ik merk dagelijks dat dit me wel degelijk helpt bij het uittekenen van oplossingen.
Echter, praktische ervaring of niet, een architect die een oplossing uittekent die onmogelijk geïmplementeerd kan worden heeft zijn job niet naar behoren gedaan. Een architectenjob is geen ivoren-toren-job, maar wordt helaas in de praktijk echt te vaak wel zo uitgevoerd. Communicatie is gewoon belangrijk. Een architect moet veelvuldig overleggen met ontwikkelaars, system engineers, analisten, ... om zeker te zijn dat de oplossing de gekende requirements afdekt en ook kan geïmplementeerd worden. En als de ideale case niet kan geïmplementeerd worden, dat het een best effort oplossing wordt en de verwachtingen van business tijdig bijgesteld worden.
Natuurlijk maken mensen fouten, of gewoon foute assumpties. Dat is soms een persoonlijke fout, maar soms kan je ook zaken gewoon niet weten op voorhand. Een oplossing uittekenen die gegarandeerd alle toekomstige requirements zal ondersteunen is niet eenvoudig aangezien je toekomstige requirements nog niet kent. Dus worden wel eens foute beslissingen gemaakt. Het is dan gemakkelijk om achteraf te zeggen "aha, zie je wel!".
Meer met betrekking tot de eigenlijke discussies, enkele punten:
1. de officieel geëtaleerde licentieprijs kan ver, HEEL ver van de prijs liggen die uiteindelijk op het contract komt te staan (ben hier nu bezig met een dossier waarin de totaalprijs van een IBM stack echt wel voordelig uitkomt - ik heb het over IIB & MQ, API Connect, App Connect)
2. accountability. Sommige ondernemingen verliezen bakken geld per minuut dat er downtime is. SLA's zijn dan nodig, en niet iedereen staat te springen om die op open source producten te bieden.
3. niet iedereen heeft voldoende kennis in huis of, misschien pijnlijk: vertrouwen in de competentie van de aanwezige resources, om de boel up & running te houden bij problemen, die willen onmiddellijk kunnen escaleren
4. sommige up-and-coming producten zijn rationeel en effectief gewoon beter dan bestaande big-vendor producten. Je kan daar dan voor kiezen, competenties opbouwen, implementeren... En een jaar later worden die overgekocht door een big vendor, worden de interessantste zaken verwerkt in het big vendor product en vervolgens is je leuk framework EOL. Daar sta je dan.
5. de keuze voor een product kan in niet onbelangrijke mate beïnvloed worden door de product stack of ecosysteem dat errond hangt. Ja, nu heb je misschien enkel B2B tooling nodig, maar misschien is het interessant om in de studie op te nemen of er vendoren zijn die ook een goede APIM oplossing hebben
TL;DR de beslissing voor een bepaald product of tool is zelden een beslissing die enkel wordt gemaakt op vlak van capabilities.
Goede discussie sowieso.
eniac
Legacy Member
BA is voor mij iemand die ver van het technische staat, die input verzamelt van de business/gebruikers om business requirements en processen uit te tekenen.RadicalAtheist zei:
Functioneel analist vertaalt naar functionele requirements.
Solution architect definieert de applicatieblokken en componenten, beschrijft integraties en gegevensstromen, kan datamodellen opstellen, ...
Five-seveN
Legacy Member
eniac zei:
Kun je geloven dat ik mensen kan die die 3 jobs tegelijk zelf moeten doen + ook de databases nog aanmaken, applicatie programmeren, testen, documenteren, installeren en support geven? Welliswaar op kleinere schaal, en niet zonder slag of stoot. Maar het is wel mooi te zien hoe een "groot bedrijf" zoiets organiseert zoals jij beschijft, op de ideale manier. Heb je zo nog functies? Wat volgt er na de solution architect?
Mooncat
Legacy Member
Deze discussie gaat volgens mij eerder over IT governance in plaat van enkel IT architecture. IT governance gaat over het inrichten van IT om waarde te creëren voor de business en diezelfde business te ondersteunen. Dat vertaalt zich in aspecten zoals organisatiestructuur, keuze van systeemlandschap, opzetten van processen en procedures, beheren van controles, strategische controle van assets, regulatory compliance, enzovoort. Voor een bedrijf kan het een stuk goedkoper zijn om te werken met OpenERP, maar dat management toch bewust kiest voor het veel duurdere SAP omwille van businesscontinuïteit, support, security en eenvoud van beheer (van dezelfde systemen). Dat zijn dingen die moeilijk in monetaire waarde uit te drukken zijn, maar wel een grote invloed kunnen hebben op het maken van dergelijke keuzes.
Een IT architect is voor elk groot project een significante meerwaarde op voorwaarde dat die met de voeten in de modder staat en geen theoretische positie bekleedt. Ik opereer als release manager in een gigantisch project waar er eigenlijk amper of geen IT architect aanwezig is en dat laat zich gevoelen in twijfelachtige technische beslissingen die ten koste gaan van onderhoudbaarheid en herbruikbaarheid van code, performantie en andere technische aspecten. Ik moet bijvoorbeeld ook een cut-overplan maken van de go live waar de operationele werking (zowel business als IT) tijdelijk wordt stopgezet, gebufferd, live gaat met het project en dan wordt alles hernomen. Erg leuk als je niet eens weet welke applicaties er allemaal gebruikt worden en wat de onderlinge interfaces zijn.
Een IT architect is voor elk groot project een significante meerwaarde op voorwaarde dat die met de voeten in de modder staat en geen theoretische positie bekleedt. Ik opereer als release manager in een gigantisch project waar er eigenlijk amper of geen IT architect aanwezig is en dat laat zich gevoelen in twijfelachtige technische beslissingen die ten koste gaan van onderhoudbaarheid en herbruikbaarheid van code, performantie en andere technische aspecten. Ik moet bijvoorbeeld ook een cut-overplan maken van de go live waar de operationele werking (zowel business als IT) tijdelijk wordt stopgezet, gebufferd, live gaat met het project en dan wordt alles hernomen. Erg leuk als je niet eens weet welke applicaties er allemaal gebruikt worden en wat de onderlinge interfaces zijn.
eniac
Legacy Member
Dieter85 zei:
Typisch is het BA > FA > solution architect > technical lead > developers > testers
Technical lead doet de diep technische analyse van de componenten die de SA definieert.
Maar idd, doorgaans vind je enkel in grotere projecten afzonderlijke profielen die deze functies invullen. In projecten van iets kleinere schaal zie je meestal BA & FA rollen door dezelfde persoon ingevuld worden, en architect en technical lead.
Nog verder doorgedreven en je zit bij analist-programmeur. Heb ik vroeger eigenlijk ook nog gedaan, dat ging dan over projectjes die we met 2 of 3 man deden en die een doorlooptijd van 2 maand hadden.
the_fox
Legacy Member
Ah, de ideale wereld waar er geen klanten zijn!eniac zei:
Hangt niet enkel af van de grootte van de projecten maar ook wel van het type project vind ikeniac zei:
Als je vasthangt aan een bepaalde technologie, is de solution architect al niet nodig. In veel gevallen vind ik ook dat BA & FA perfect samen te nemen zijn, ook in grotere projecten.eniac
Legacy Member
the_fox zei:Ah, de ideale wereld waar er geen klanten zijn!
Natuurlijk wel, maar die maken niet per se deel uit van het projectteam. Het spreekt toch een beetje voor zich dat er een uitvoerige dialoog moet zijn met de klant.
Hangt niet enkel af van de grootte van de projecten maar ook wel van het type project vind ik
Mja, hoe groter het project, hoe groter de kans dat het niet bij 1 technologie blijft. Ook hoe groter het project, hoe groter de kans wordt dat de verschillende disciplines uit elkaar getrokken worden.
Over samen nemen van BA en FA: kan zeker, maar in een project met een team van een analist of 8, of meer, kan het zeker zinvol zijn om beide rollen uit elkaar te houden. Van rol switchen is niet altijd efficiënt.
Maar inderdaad, kan zeker samen en heb ik al vaak gezien.
Nineshots
Legacy Member
eniac zei:
Bij ons ligt het anders. We hebben 2 stromen. De FA stroom. En de developers -> technical stroom.
En als je solution architect wil worden, moet je beide stromen beheersen en daarnaast ook BA kunnen.
Zo vind ik het wel nog een logische structuur, want op die manier heb je ook de beste kennis om het datamodel te schetsen enzo.
Maar vaak wordt dit ook gedelegeerd aan de technical lead, waarna de SA het bekijkt en aanpast waar nodig.
Dus solution architect staat het hoogste bij ons. Van daar kan je wel naar project manager gaan, maar dat vind ik dan weer iets anders. Een nieuwe stroom eigenlijk.
FA hoger plaatsen dan technical lead gaan we niet doen, het zijn 2 verschillende jobs. Ik denk zelfs dat de technical leads meer verdienen bij ons, want ze brengen ook meer op.
jack|herrer
Legacy Member
Bij ons is het net iets anders.
In project:
- product managers: marketing en komen met een wens
- Lead designers: zijn BA's. Doen feasability, ballpark en leiden projectteam(interne afdelingen, leveranciers) om tot een high level design te komen dat ze schrijven
- BA leveranciers: doen impact analyse van hun kant en leveren quote.
- Technical leads: detailed design
- Devs
- Testers
Daarnaast loopt er nog een PM mee voor de financials en leveranciers contacten
nuiten projecten om heb je dan domain architecten die roadmaps uitschrijven en end2end designers (ook BA) die e2e waarborgen
In project:
- product managers: marketing en komen met een wens
- Lead designers: zijn BA's. Doen feasability, ballpark en leiden projectteam(interne afdelingen, leveranciers) om tot een high level design te komen dat ze schrijven
- BA leveranciers: doen impact analyse van hun kant en leveren quote.
- Technical leads: detailed design
- Devs
- Testers
Daarnaast loopt er nog een PM mee voor de financials en leveranciers contacten
nuiten projecten om heb je dan domain architecten die roadmaps uitschrijven en end2end designers (ook BA) die e2e waarborgen
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.