Is een ontwerper en applicatie programmeur nodig?

[HawVer]

In een gemiddelde bedrijfsadministratie kom je dezelfde concepten tegen. Je hebt entiteiten, je wilt gegevens vastleggen over de entiteiten, je wilt die gegevens verwerken zodat er informatie ontstaat, exporteren importeren, rapportages op draaien en dan hebt je het eigenlijk wel gehad.

Wat zijn wat technische zaken waar je over na moet denken? Hoe geef ik de mogelijkheid om die entiteiten te definiëren? Hoe geef ik de mogelijkheid om gegevens vast te leggen over die entiteiten? En het meest belangrijke, hoe geef ik de mogelijkheid om die gegevens te verwerken tot zinvolle informatie? Geef de mogelijkheid voor de belangrijkste verwerkingen. Stel ik heb een tool waarmee ik dit allemaal vrij makkelijk kan doen.

Functioneel gezien draai ik zo een bedrijfsapplicatie in elkaar. Waarom heb ik eigenlijk nog een ontwerper nodig? Ik maak meerdere concepten, laat de beste kiezen en ik ben klaar. Desnoods ga ik samen met mijn klanten zitten en draai ter plekke een applicatie in elkaar. Wat ik als software vendor nodig heb is iemand die een beetje abstract kan denken en de markt kent en voila, de discipline van de ontwikkelaar en de ontwerper maak ik overbodig met mijn tool.

Mijn vraag is: waarom niet/wel? Wat is jullie visie hierop? Is het een utopie of wel degelijk haalbaar?
Overigens ik ben functioneel ontwerper voor een software bedrijf.

[Domdo]

Meestal kom ik toch iets ingewikkelder software tegen dan even wat entiteiten opslaan en exporten / weergeven.

Een ontwerper heeft in mijn eigen pas ook echt zin als die persoon ook veel (niet alles) van alle mogelijke onderdelen af weet zodat het ontwerp in ieder geval goed bedacht zonder dat halverwege blijkt dat het eigenlijk niet kan.

[Herko_ter_Horst]

Je mist nog een belangrijke component in je tool: gedrag.

Je kunt wel een beetje CRUD doen en wat rapportjes genereren, maar daarmee heb je nog geen software die een specifiek bedrijfsproces ondersteunt. De toegevoegde waarde van een bedrijf bestaat uit wat het bedrijf kan doen met de data, informatie en rapporten die het heeft. Liefst zonder dat die rapporten nodig zijn, aangezien die ook geen doel op zich zijn, maar een middel om beslissingen te kunnen nemen, activiteiten te kunnen ontplooien en dergelijke.

Het gedrag zul je moeten programmeren - of configureren.

Een utopie is het zeker niet: ik werk voor een bedrijf dat dit in de praktijk brengt. Met generieke tooling kunnen we een specifiek bedrijfsproces modelleren en dit model executeren in een eveneens generieke runtime-omgeving.

Voorbeeld van een applicatie die op deze manier gebouwd is voor het ministerie van VROM: https://www.omgevingsloket.nl/

Ook CRUD en rapportages: vergunningsaanvragen opslaan en verwerken; maar ook met gedrag: op basis van de modellen geautomatiseerd adviezen kunnen geven, beslissingen kunnen nemen, e.d.

En: door de klant zelf te configureren en door de klant-van-de-klant (in dit geval: de burger) te bedienen. Komt geen ontwerper of applicatieprogrammeur van ons aan te pas. Wij leveren ondersteuning in de vorm van kennisarchitecten en -modelleurs - en niet te vergeten trainingen, om de klant zoveel mogelijk zelf de controle te geven.

Ik mag vast geen reclame maken, maar vertaal "wees geïnformeerd" in het Engels en je hebt de naam van het bedrijf

[ Voor 6% gewijzigd door Herko_ter_Horst op 03-12-2010 19:28 ]

[Verwijderd]

HawVer schreef op vrijdag 03 december 2010 @ 16:30:
Desnoods ga ik samen met mijn klanten zitten en draai ter plekke een applicatie in elkaar.

Als ik jouw verhaal zo lees, heb je alleen maar te maken gehad met vrij simpele applicaties. Meer een soort geautomatiseerde notitieblokjes met wat kleine rapportage mogelijkheden.

Als alles zo simpel en snel ging als je voorsteld, zou je al zo ongeveer millionair moeten zijn

En de Tool waar je het over hebt, wat is dat dan?

Herko_ter_Horst schreef op vrijdag 03 december 2010 @ 19:14:
En: door de klant zelf te configureren en door de klant-van-de-klant (in dit geval: de burger) te bedienen. Komt geen ontwerper of applicatieprogrammeur van ons aan te pas. Wij leveren ondersteuning in de vorm van kennisarchitecten en -modelleurs - en niet te vergeten trainingen, om de klant zoveel mogelijk zelf de controle te geven.

Ik weet niet waar dit in geconfigureerd wordt, maar denk toch echt dat het "ding" wat je configureerd/inricht toch echt ontworpen en geprogrammeerd moet worden. Daarbij zal je nooit en te nimmer al je klanten wensen zo standaard kunnen implementeren en zal het "ding" daarin mee moeten groeien.

.

[ Voor 45% gewijzigd door Verwijderd op 03-12-2010 19:37 ]

[HawVer]

Domdo schreef op vrijdag 03 december 2010 @ 18:22:
Meestal kom ik toch iets ingewikkelder software tegen dan even wat entiteiten opslaan en exporten / weergeven.

Eens, het is een vereenvoudigd beeld om je een idee te geven.

Herko_ter_Horst schreef op vrijdag 03 december 2010 @ 19:14:
Je mist nog een belangrijke component in je tool: gedrag.

Je kunt wel een beetje CRUD doen en wat rapportjes genereren, maar daarmee heb je nog geen software die een specifiek bedrijfsproces ondersteunt. De toegevoegde waarde van een bedrijf bestaat uit wat het bedrijf kan doen met de data, informatie en rapporten die het heeft. Liefst zonder dat die rapporten nodig zijn, aangezien die ook geen doel op zich zijn, maar een middel om beslissingen te kunnen nemen, activiteiten te kunnen ontplooien en dergelijke.

Het gedrag zul je moeten programmeren - of configureren.

Een utopie is het zeker niet: ik werk voor een bedrijf dat dit in de praktijk brengt. Met generieke tooling kunnen we een specifiek bedrijfsproces modelleren en dit model executeren in een eveneens generieke runtime-omgeving.

Voorbeeld van een applicatie die op deze manier gebouwd is voor het ministerie van VROM: https://www.omgevingsloket.nl/

Ook CRUD en rapportages: vergunningsaanvragen opslaan en verwerken; maar ook met gedrag: op basis van de modellen geautomatiseerd adviezen kunnen geven, beslissingen kunnen nemen, e.d.

En: door de klant zelf te configureren en door de klant-van-de-klant (in dit geval: de burger) te bedienen. Komt geen ontwerper of applicatieprogrammeur van ons aan te pas. Wij leveren ondersteuning in de vorm van kennisarchitecten en -modelleurs - en niet te vergeten trainingen, om de klant zoveel mogelijk zelf de controle te geven.

Ik mag vast geen reclame maken, maar vertaal "wees geïnformeerd" in het Engels en je hebt de naam van het bedrijf

Het gedrag is inderdaad een belangrijk punt, ik denk ook dat je daar meteen het lastigste raakt van hele proces. Met name als je het configureerbaar probeert te maken. Wordt het dan niet veel te abstract en complex voor de burger om daar mee te werken?

[ Voor 77% gewijzigd door HawVer op 03-12-2010 21:14 ]

[Dido]

Als die tool inderdaad alles kan wat je beschrijft, en daarbovenop ook daadwerkelijk alle situaties aankan die je tegenkomt, en je klanten kunnen hun bedrijfsprocessen goed specificeren, dan heb je inderdaad geen ontwerper en applicatieprogrammeur meer nodig.

Behalve dan het team dat de tool onderhoudt

Nog even los van het feit dat ik van de drie genoemde voorwaarden de eerste onwaarschijnlijk vind, de tweede godsonmogelijk en de derde een utopie.

[CH4OS]

Omdat een programmeur eigenlijk vooral de backend van een programma schrijft en een ontwerper de voorkant; wat de gebruiker dus krijgt te zien en er mee moet werken... Het zijn twee totaal verschillende specialisaties, ongeacht wat voor programma je hebt. Of het nu een CRM of ERP pakket is om wat voorbeelden te noemen...

Een programmeur denkt daardoor totaal anders dan een ontwerper. Een ontwerper bezit (als het goed is) kennis over hoe gebruikers om kunnen gaan met een pakket. De programmeur schrijft alleen de code, zodat een functie daadwerkelijk doet waar ie voor geschreven is.

Of ik volg jouw vraag niet zo...

[ Voor 32% gewijzigd door CH4OS op 03-12-2010 21:01 ]

[Verwijderd]

Nu heeft TS het volgende bij codeproject staan:
"I design software for a ERP software vendor in the Netherlands. "

Dus helemaal gek zal ie niet zijn (of hij is gevallen met de gladheid afgelopen dagen).

Wat is de achterliggende gedachte achter je vraag?

[HawVer]

Verwijderd schreef op vrijdag 03 december 2010 @ 19:23:
[...]


Als ik jouw verhaal zo lees, heb je alleen maar te maken gehad met vrij simpele applicaties. Meer een soort geautomatiseerde notitieblokjes met wat kleine rapportage mogelijkheden.

Salarisverwerking en verwerking van belastingaangiftes

Als alles zo simpel en snel ging als je voorsteld, zou je al zo ongeveer millionair moeten zijn

En de Tool waar je het over hebt, wat is dat dan?

Ik geen een vereenvoudigd beeld om het idee duidelijk te maken

[...]

Ik weet niet waar dit in geconfigureerd wordt, maar denk toch echt dat het "ding" wat je configureerd/inricht toch echt ontworpen en geprogrammeerd moet worden. Daarbij zal je nooit en te nimmer al je klanten wensen zo standaard kunnen implementeren en zal het "ding" daarin mee moeten groeien.

Ja mee eens, het is een zelfgebouwde tool door het bedrijf waar ik werk. De tool moet geprogrammeerd worden en ontworpen worden. Ik doel hier echt op de applicatie programmeur/ontwerper. Diegene die met de tools en bouwstenen een applicatie moet gaan bouwen.

[Herko_ter_Horst]

Verwijderd schreef op vrijdag 03 december 2010 @ 19:23:
[...]

Ik weet niet waar dit in geconfigureerd wordt, maar denk toch echt dat het "ding" wat je configureerd/inricht toch echt ontworpen en geprogrammeerd moet worden. Daarbij zal je nooit en te nimmer al je klanten wensen zo standaard kunnen implementeren en zal het "ding" daarin mee moeten groeien.

De tool moet zeker ontworpen en geprogrammeerd worden (gelukkig wel, anders had ik nu geen baan ). De tool is echter zó configureerbaar, dat we er ontzettend veel diverse bedrijfsprocessen mee kunnen modelleren en direct uitvoerbaar kunnen maken. En ja, er zijn grenzen, we hebben geen magisch systeem, maar we blijken het meeste aan te kunnen zonder maatwerk. Dus voor onze klanten bouwen we geen softwaresystemen/applicaties meer waarvoor we ontwerpers/programmeurs nodig hebben. We doen het met een architect, kennismodelleurs en trainers, die de klant helpen het systeem zelf in te richten en aan te passen. We gaan dus ook weer weg.

Omdat niemand het beter verteld dan onze klanten: YouTube: Automatisering Gids | Webcast

Uit het feit dat in INDiGO een wetswijziging met "ons" systeem binnen 1 dag door de klant zelf i.p.v. in 9 maanden door een legertje consultants doorgevoerd kan worden, blijkt wel dat het overgrote gedeelte van de "traditionele" automatiseringsaanpak is verdwenen.

[ Voor 10% gewijzigd door Herko_ter_Horst op 03-12-2010 21:32 ]

[Verwijderd]

HawVer schreef op vrijdag 03 december 2010 @ 21:20:
Ja mee eens, het is een zelfgebouwde tool door het bedrijf waar ik werk. De tool moet geprogrammeerd worden en ontworpen worden. Ik doel hier echt op de applicatie programmeur/ontwerper. Diegene die met de tools en bouwstenen een applicatie moet gaan bouwen.

ah ok, ik was in de gedachte dat je met ontwerper de ontwerper van de tool bedoelde, en de appl.progr. de programmeur van de tool.

Bij ons (leverancier van WMS/DMS/ECMS, mag geen naam noemen maar Opel heeft er een kleine auto naar vernoemd) hebben die mensen waar jij op doelt een andere functienaam.

Is allemaal meer aan de implementatie kant, en hebben wij dus Implementatie specialisten etc. zitten.

[ Voor 4% gewijzigd door Verwijderd op 03-12-2010 21:31 ]

[Dido]

Helemaal gek zou ik hem niet willen noemen, maar de vraag doet me een beetje denken aan de gedachtengang die veel leden van wat ik regelmatig als "overhead" betitel erop nahouden als het om het bouwen van software gaat.
Het soort manager dat serieus voorstelt om een generieke component te ontwikkelen waarmee we elke willekeurige webservice zouden kunnen implementeren. Want dan zou je je data op een uniforme manier kunnen ordenen.
Of de variant die weken discussieert over het al dan niet enablen van een tekstinvoerveld als de ingevoerde tekst door andere keuzes niet meer gebruikt gaat worden, maar vervolgens wel voorstelt om op 1 scherm een keuze uit drie mogelijkheden een keer als combobox, een keer als setje radiobuttons en een derde keer als vrij tekstveld te implementeren. Om uiteindelijk met een schermdesign aan te komen waar de honden geen brood van lusten, en te verwachten dat je de volledige backend inclusief datamodel in een week werkend hebt.
Iemand die als functioneel applicatieverantwoordelijke de requirements specificeert als "het moet gewoon werken", maar geen antwoord heeft op de vraag wat de gebruiker wil, welke use-cases van belang zijn of ueberhaupt waar de data vandaan moet komen.
Mensen die een 20-pagina's tellend document doorsturen met een een hoop xml erin als documentatie van een webservice, en zich afvragen waarom die niet even snel geimplementeerd kan worden (omdat ze na 20 keer nog steeds niet begrijpen dat daarvoor een paar details nodg zijn als een adres waarop die service benaderd kan worden, en een setje credentials.
Mensen die een applicatie laten maken die op geen enkele standaard manier te integreren is in bestaande clients, geen budget meer hebben om die applicatie aan te passen en dan gaan klagen dat degenen die de integratie moeten verzorgen hun werk niet doen.

Die mensen verdenk ik er vaak van dat ze zich, terwijl ze onder Windows hun Office-documenten bewerken, afvragen waar zo'n programmeur nu helemaal goed voor is.

(Sorry als dit iets teveel op een rant is gaan lijken. )

[HawVer]

Verwijderd schreef op vrijdag 03 december 2010 @ 21:17:
Nu heeft TS het volgende bij codeproject staan:
"I design software for a ERP software vendor in the Netherlands. "

Dus helemaal gek zal ie niet zijn (of hij is gevallen met de gladheid afgelopen dagen).

Wat is de achterliggende gedachte achter je vraag?

Gelukkig niet gevallen. Ik ben niet helemaal gek nee. Goed om het wat concreter te maken. Er wordt inderdaad georiënteerd op een tool waarbij je niet meer de software gaat schrijven maar de software modelleert. We hebben een afdeling die zich met name bezig houdt met tooling. Dat is de 'studio' waar in gemodelleerd gaat worden. En een afdeling die in de toekomst met 'de studio' gaat werken. Ik zelf ben actief op de afdeling waar het ontworpen wordt. Die studio tool is een succes, kan er verder niet zoveel over vertellen. Alleen nu was aan ons de vraag om ons te oriënteren op de werkwijze van de ontwerpers en welke tools ze nodig hebben. Dus ik denk ik gooi het hele idee eens op tweakers.net, kijken wat zij er van vinden. Is het een utopie, een droombeeld om alles te kunnen modelleren? Als je het model maar ondersteund met een applicatie heb je geen ontwikkelaar nodig die zich bezig houdt met het slepen en pleuren van invoerveldjes en tot op de ifjes nauwkeurig. De functie van de ontwerper en ontwikkelaar komt een stuk dichter naar elkaar toe.

Herko_ter_Horst schreef op vrijdag 03 december 2010 @ 21:26:
[...]


De tool moet zeker ontworpen en geprogrammeerd worden (gelukkig wel, anders had ik nu geen baan ). De tool is echter zó configureerbaar, dat we er ontzettend veel diverse bedrijfsprocessen mee kunnen modelleren en direct uitvoerbaar kunnen maken. En ja, er zijn grenzen, we hebben geen magisch systeem, maar we blijken het meeste aan te kunnen zonder maatwerk. Dus voor onze klanten bouwen we geen softwaresystemen/applicaties meer waarvoor we ontwerpers/programmeurs nodig hebben.

Hoe werkt dat dan? Wordt het proces gemodelleerd en vervolgens omgezet naar software? Werk je echt verwerkingstaak gestuurd, zeg maar een proces met input en output of kun je het echt onderbrengen in een model?

We doen het met een architect, kennismodelleurs en trainers, die de klant helpen het systeem zelf in te richten en aan te passen. We gaan dus ook weer weg.

Dat is wel een erg geniale functienaam ja. Dat is eigenlijk wat je doet. Je bent niet zozeer meer bezig hoe de software er uit moet komen te zien maar je bent bezig kennis te modelleren tot een zinvolle, bruikbare structuur.

[ Voor 30% gewijzigd door HawVer op 03-12-2010 21:38 ]

[Verwijderd]

Herko_ter_Horst schreef op vrijdag 03 december 2010 @ 21:26:
[...]
We gaan dus ook weer weg.

Om nooit meer terug te komen?

Bij ons in de software (WMS gedeelte) kan de gebruiker (na training) zelf wel z'n processen inrichten/definieren (grafisch). Dit wordt ook vaak gedaan door of met onze mensen. Er hoeft idd niet voor iedere "solution" een programmeur aan het werk.

[ Voor 40% gewijzigd door Verwijderd op 03-12-2010 21:46 ]

[HawVer]

Dido schreef op vrijdag 03 december 2010 @ 21:31:

(Sorry als dit iets teveel op een rant is gaan lijken. )

Haha heerlijk herkenbaar. Daar heb ik gelukkig niet zoveel last van. We kennen het begrip hier ook. Het heet het doe slim object. Het object die alles oplost en alles mogelijk maakt.

[Herko_ter_Horst]

HawVer schreef op vrijdag 03 december 2010 @ 20:53:
Het gedrag is inderdaad een belangrijk punt, ik denk ook dat je daar meteen het lastigste raakt van hele proces. Met name als je het configureerbaar probeert te maken. Wordt het dan niet veel te abstract en complex voor de burger om daar mee te werken?

Als je met "de burger" de burger uit het voorbeeld dat ik noemde bedoelt, dan ja.

Maar die bepaalt het gedrag niet, dat doet onze klant ("de burger" is de klant-van-de-klant, d.w.z. de eindgebruiker van de door onze klant gemaakte applicatie). En onze tool (die we vast niet geheel toevallig ook "Studio" noemen) staat de klant toe in zijn eigen terminologie te modelleren. Dit blijkt in de praktijk snel aan te leren te zijn. Daardoor zijn onze klanten in staat heel snel het generieke model te relateren aan hun eigen situatie. De complexiteit verdwijnt echter niet: zeker bij grote organisatie met ingewikkelde (beslis)structuren, wetgeving en veel stakeholders (zoals de IND) is het juist de grip op de complexiteit die onze tool biedt, die maakt dat klanten er zo blij van worden. Voor de klant-van-de-klant wordt de complexiteit wél sterk gereduceerd, omdat die te maken krijgt met een "intelligente" applicatie, waarin uitleg over beslissingen en adviezen een natuurlijke "bijwerking" zijn van het model waar de gebruiker via de applicatie mee interacteert. Prominent op onze website staat dan ook "Embrace Complexity" .

[...]

Hoe werkt dat dan? Wordt het proces gemodelleerd en vervolgens omgezet naar software? Werk je echt verwerkingstaak gestuurd, zeg maar een proces met input en output of kun je het echt onderbrengen in een model?

Het proces, maar ook alle beslissingen/regels, events waar op gereageerd moet worden, artifacten (documenten, rapporten, e-mails, afspraken, notities) die gegenereerd moeten worden als aan bepaalde voorwaarden is voldaan, etc. worden gemodelleerd. De modellen worden vervolgens uitgevoerd door een generieke runtime-omgeving. Er wordt dus geen codegeneratie of iets dergelijks gedaan. De Studio is generiek, de Server is generiek. Alles daar tussenin zit in de modellen van de klant.

Nou ja, vrijwel alles: uitsluitend enkele technische zaken (wat is het adres van de mailserver, waar staat de database, dat soort dingen) worden op een andere manier geconfigureerd.

Verwijderd schreef op vrijdag 03 december 2010 @ 21:42:
[...]

Om nooit meer terug te komen?

Hehe, nee gelukkig niet. Sowieso blijven we betrokken voor support en aanvullende trainingen. Daarnaast worden we gelukkig vaak teruggevraagd omdat de klant nog meer processen met onze software wil gaan modelleren en executeren.

[ Voor 60% gewijzigd door Herko_ter_Horst op 03-12-2010 22:04 ]

[The Eagle]

ERP applicatieprogrammeur / ontwerper / architect meldt

Waar de programmeur alleen de code klopt, gaat de softwareontwerper een stukje verder en een stukje minder ver. Een ontwerper heeft genoeg kennis van de gebruikte tooling / programmeertaal om de (on)mogelijkheden te kennen, en een daarop gebaseerde applicatie te ontwerpen die rekening houdt met de eindgebruikers, eisen en wensen aan functionaliteit, etc etc. Als de ontwerper zijn werk goed heeft gedaan hoeft de programmeur eigenlijk alleen nog maar code te kloppen. Vaak zal de ontwerper de programmeur ook voor ruggespraak gebruiken; dat is immers de specialist vwb de (on)mogelijkheden van de taal / tool

Waar TS een beetje naar zoekt is (denk ik) een term als SOA. Het lijktiig vergelijkbaar te zijn. Bij een SOA wordt niet specifiek naar een applicatie (en dus tooling) gekeken, maar naar het bedrijfsproces wat er op moet komen te draaien. En dan blijkt dat sommige (onderdelen van) een proces door meerdere gebruikte en gekoppelde softwarepakketten afgehandeld kunnen worden, maar bij de ene configureerbaar is en bij de andere van scratch geprogrammeerd moet worden, of iets wat er tussenin zit. En dan moet je dus afwegen wat het beste is - wat zeker niet per definitie betekent dat het pakket waar het volledig configureerbaar is het ook daadwerkelijk gaat afhandelen

Ik werk zelf veel met Oracle technologie. Laatst nog met Oracle BPEL en ESB aan de slag geweest, en volgens mij lijkt het sterk op het concept wat TS beschrijft. Wellicht interessante materie: http://www.oracle.com/us/technologies/soa/index.html

[burne]

Herko_ter_Horst schreef op vrijdag 03 december 2010 @ 19:14:
Voorbeeld van een applicatie die op deze manier gebouwd is voor het ministerie van VROM: https://www.omgevingsloket.nl/

Leuk om dat hier tegen te komen, ook al is het off-topic. Ik beheer het spul waar dat op draait. Net een halve dag conversiescripts zitten testen voor de nieuwe release.

[CyBeRSPiN]

TS geeft het al aan, voor een gemiddelde bedrijfsapplicatie waarbij je een goed ingerichte CASE tool voorhanden hebt kun je wel af met een een programmerende (eigenlijk eerder configurerende) ontwerper. Maar zodra er maar 1 requirement buiten het straatje van wat die tool kan genereren valt dan ga je al nat, en moet je nee verkopen of een programmeur maatwerk laten maken (of de tool laten uitbreiden).

Voor de 13 in een dozijn applicaties zal het allemaal wel richting out of the box, door de klant in te stellen worden, maar ik verwacht dat er altijd een losse analist en een programmeur nodig zijn voor de meer specialistischer IT.

Bedenk ook: er is een tegenstrijdig belang voor de IT industrie om zo'n tool te willen maken, als die tool bestaat dan gaan klanten er zelf mee aan de slag, zonder dure en uitlopende uitbestede IT projecten

[ Voor 16% gewijzigd door CyBeRSPiN op 12-12-2010 22:22 ]

[Freeaqingme]

CyBeRSPiN schreef op zondag 12 december 2010 @ 22:16:Bedenk ook: er is een tegenstrijdig belang voor de IT industrie om zo'n tool te willen maken, als die tool bestaat dan gaan klanten er zelf mee aan de slag, zonder dure en uitlopende uitbestede IT projecten

Ook dan heb je mensen nodig die verstand hebben van die tool, en in staat zijn om abstract te denken en de bedoelingen aan een computer(systeem) duidelijk te maken. En zolang computers niet de turingtest doorstaan blijven die mensen nog wel even nodig. Uiteindelijk gaat men steeds verder in het programmeren - wie programmeert er vandaag de dag nog met ASM (het gaat om 't aantal, niet om of jij 't wel/niet doet )?

[YopY]

quote: gang-ster

Wat doet overigens een applicatiebeheerder? Ik heb echt geen idee wat zo iemand zou moeten doen en wie dat naampje heeft bedacht.

*halve applicatiebeheerder meldt zich*

Een applicatiebeheerder is een specialist in één specifiek softwarepakket. Ons bedrijf heeft bijvoorbeeld een administratieprogramma waar alle producten in beheerd worden - algemene productinformatie, maar ook zaken als productieprocessen, 'blauwdrukken' (als je het zo wilt noemen), etc. Daar hebben we ook één of twee applicatiebeheerders voor, die leveren diensten van het helpen met het gebruik van het product voor de eindgebruikers tot het uitpoepen van rapporten door middel van SQL queries (Oracle). Ze onderhouden het contact met de leverancier van de applicatie, geven feature / change requests door en testen ze, en ga zo maar door.


Overigens, ja, SQL is ook een (relatief eenvoudig in gebruik zijnde) rapportagetool / taal, die ook nog eens veel sneller in te voeren is dan een grafische tool - en het hoeft niet eens lastiger te leren zijn voor de eindgebruiker. Als die nu het gebruik van een grafische omgeving om (effectief) een query op te bouwen moet leren of een tekstuele, maakt op zich niet zoveel uit. En als je de gebruiker geen onbeperkte toegang wilt geven, d'r zijn mogelijkheden om zo'n query van te voren na te kijken, of als het echt nodig is een domein-specifieke taal eromheen te bouwen die eenvoudig te vertalen is naar SQL.

En nu ben ik nieuwsgierig, wordt dit in de praktijk wel eens toegepast? Ik weet toevallig dat ze bij een nogal grote Neerlandsche voetbalsite een rapportagetool hebben dat niet veel meer was dan een dropdown met opgeslagen SQL queries en een eenvoudige visualisatie daarvan dat sowieso al tien jaar voldoet - die worden door de databasebeheerder en de webmaster gebruikt, op aanvraag van de redactie die wel eens statistieken op hun website wil plaatsen.

Ook hebben ze een invoertool waarbij ik verdenk dat ze een soort van One Tool wouden implementeren, door allerlei 'generieke' objecten / classes te definiëren waar je een datatype en een waarde kon invoeren. Natuurlijk niet te onderhouden en validatie van wat voor niveau dan ook ontbrak / ontbreekt volledig, dus ik kan zo'n werkwijze niet adviseren, maar eenzelfde idee leek het wel.

[Freeaqingme]

YopY schreef op maandag 13 december 2010 @ 20:29:
[...]
En nu ben ik nieuwsgierig, wordt dit in de praktijk wel eens toegepast?

Wij laten gebruikers door middel van dropdownboxes een gebruiker z'n data selecteren. Intern wordt dit (uiteraard) gewoon omgezet naar een query. Deze queries worden (als de gebruiker dat wil) opgeslagen in de database als string. Om deze later weer te weergeven halen we die door een zelfgeschreven tokenizer, en parsen we dit weer naar de dropdownboxes.

Voor geavanceerde gebruikers bestaat er de mogelijkheid om deze queries zelf aan te passen, maar ook dan halen we ze door een tokenizer om te kijken of er geen data geselecteerd wordt waar geen toestemming voor is.

Is dat een beetje wat je bedoelde?

[majoh]

Altijd leuk dit soort topics.

Na nu een jaar of 6 applicatie ontwikkelaar te zijn, vind ik het wel een heel erg simpele stelling. Mijn antwoord zou zijn: Ja, die zijn nodig.

Natuurlijk ligt het er aan wat voor soort applicatie je schrijft, en in wat voor soort domein je je bevind. In een simpele omgeving waar je een simpel programma moet maken wat een beetje data op slaat, en waar de gebruiker duidelijk kan vertellen hoe dat moet en wat voor soort rapportage erbij hoort, dan zou je kunnen volstaan met een enkel persoon die het geheel in elkaar klopt.

Maar als je ever verder denkt en kijkt naar wat ingewikkeldere applicaties / processen binnen een bedrijf dan is het allemaal niet zo simpel. Klein voorbeeld uit mijn ervaring. Twee grote multinationals die zijn samen gegaan, waarbij twee verschillend werkende backends zijn die voorlopig niet samengevoegd worden. Op deze backends draaien meerdere applicaties voor klanten en intern gebruik. Deze applicaties moeten al wel samen gevoegd worden tot 1, waarbij er dus twee backends achter blijven zitten. Daarnaast zal er in de toekomst wel overgegaan worden naar 1 backend systeem waarbij dit nieuwe systeem natuurlijk makkelijk te integreren moet zijn met de verschillende applicaties.

Kijkend naar dit voorbeeld en het werk wat er moet gebeuren zou je nooit kunnen volstaan met een persoon die even wat bedenkt. Aangezien het verschillende lagen zijn, verschillende teams, verschillende bedrijven, verschillende manieren van werken, op de toekomst voorbereid moet zijn en het ook nog eens een bedrijfskritische applicaties zijn...

[Herko_ter_Horst]

Verwijderd schreef op dinsdag 14 december 2010 @ 01:35:
[...]

Ik ben een nieuwsgierig individu en ik heb misschien niet overal ervaring mee, maar dat houdt me niet tegen om me nieuwe dingen eigen te maken. Ik weet als geen ander dat er specialismes bestaan en dat het efficiënter kan zijn om iets door een ander te laten doen, maar dat wil niet zeggen dat ik het niet kan. Door een labeltje te plakken op jezelf beperk je alleen maar jezelf, doordat je zelf gaat geloven dat je niet buiten dat labeltje ook iets kunt doen.

Nu laat je conclusies volgen uit aannames die niet kloppen. Ik heb veel interesses, maar ik ga ook geen koe slachten om aan m'n biefstukje te komen, dat laat ik aan een slager over. Dat wil niet zeggen dat ik het niet zou kunnen...

Door een labeltje op te plakken, geef je aan waar je goed in bent of waar de focus van je interesses ligt (op een bepaald moment). Dat wil niet zeggen dat je zo'n labeltje voor altijd op hoeft te houden of dat je niet meerdere labeltjes op zou kunnen hebben of dat je dingen niet zou kunnen. In projecten van enige omvang is het echter wel handig dat je taken over labeltjes kunt verdelen, om efficiënt te kunnen werken. Daarnaast is het ook handig om te voldoen aan de verwachtingen die zo'n labeltje schept: noem je jezelf "software developer" met verstand van object orientatie, maar kun je nog geen == van een equals() onderscheiden, dan val je gauw door de mand.

Wij werken bijvoorbeeld met scrum teams. Het team is verantwoordelijk voor de oplevering van een werkpakket. Binnen het team zitten mensen met verschillende labeltjes (functioneel ontwerper, software architecten, software engineers, test engineers, technical writers). Als er binnen een werkpakket een bepaalde taak ligt, kijken we op basis van labeltjes bij wie we die taak het best kunnen neerleggen. Mocht die persoon al tot over z'n oren in het werk zitten, dan schakelen we een ander teamlid in, op basis van expertise en interesse. Die persoon zal het werk misschien minder efficiënt kunnen doen, of het minder interessant vinden, maar hij of zij kán het wel (tot op zekere hoogte: je moet onze technical writers geen Java-code laten schrijven, dat is iets te ver uit hun interessesfeer).

Er is in elk geval geen sprake van beperkingen, puur van interesse en expertise. We hebben geen belang bij "computergurus" die overal wel een beetje verstand van hebben, maar als je ze vraagt ergens echt productief op te worden, niet thuis geven.

[...]

Oh, natuurlijk de "domeinexperts". Als ik een ding geleerd heb uit machine learning onderzoek, dan is het wel dat "domain experts" bijna altijd het onderspit delven vergeleken met de algoritmen die toegang hebben tot dezelfde data. Mensen zijn zo inconsistent en vaag als maar zijn kan. In de wetenschappelijke literatuur proberen ze dit dan nog een beetje netjes op te schrijven (om de experts niet te kwetsen), maar verder zou ik er niet te veel waarde aan hechten.

De vraag is hoe het komt dat computerexperts mensen uit andere domeinen altijd zo vaag en inconsistent vinden. Omgekeerd (in mijn ervaring) vinden "zij" "ons" maar nodeloos pietje-preciezerig en onbegrijpelijk. Het probleem is dat we elkaars taal niet spreken. Dit heeft ook vaak tot gevolg dat software de taal van de gebruiker niet spreekt. Waarom zou iemand die op basis van wetgeving wil kunnen beslissen of een vreemdeling ons land binnen mag, moeten weten hoe je een server inricht of een webapp installeert? Waarom willen "wij" de regels die die persoon gebruikt om beslissingen te nemen opschrijven in een taal die die persoon niet machtig is (C of Java ofzo)?

Tja, ik vind dat als je besluit om een computer te gebruiken in je bedrijf dat het dan misschien ook wel handig is als je weet wat je ermee kunt en wat de voor-en nadelen van computers zijn. Overigens wordt van ons wel verwacht dat we ons wel aan elk domein aan kunnen passen (en dat kunnen we ook).

Competentie is gedefinieerd als het succesvol kunnen uitvoeren van je werk. Als je elke keer je computer niet meer kunt gebruiken, doordat er een virus op je machine zit en daardoor ook een gedeelte van het bedrijf plat legt, dan ben je dus per definitie niet competent.

De vraag van de TS (en ook mijn voorbeelden) gaan in feite over de mogelijkheid om de gebruiker de computer te laten "programmeren" in zijn eigen taal. Het gaat over de mogelijkheid om zaken vooraf zo in te richten, dat geen "computer"-kennis meer nodig hebt op het moment dat voor een niet-computergerelateerd doel een applicatie wilt laten draaien.

Dat die computer (na 50 jaar ontwikkeling) nog steeds niet alles doet wat de gebruiker wil - zonder dat hij zich druk hoeft te maken over virussen - is "onze" schuld, niet die van de gebruiker.

Als je niets met computers te maken hebt, dan hoef je dus nog niet eens te weten waar de aan-knop zit.

Twintig jaar geleden bestond een cursus computergebruik voor eindgebruikers uit een stukje hardwarekennis en een cursus BASIC (toch op z'n minst om een "LOAD" commando te kunnen geven). Om toentertijd een computer wat nuttigs te laten doen, moest je kunnen programmeren. Tegenwoordig bestaat zo'n cursus uit "hoe zet ik het ding aan" en een introductie Windows: zelf programmeren om een computer wat nuttigs te laten doen hoeft niet meer: de abstractie van de computerhardware is wat dat betreft inmiddels ver genoeg gevorderd, d.w.z. de taal die de computer spreekt, sluit (nog maar net) voldoende aan bij de taal die mens spreekt om eenvoudige zaken te kunnen doen.

Zo'n zelfde ontwikkeling is nu gaande m.b.t. grotere, kennis-gedreven systemen. De tijd dat je een legertje consultants naar binnen kon schuiven en dan 2-5 jaar onder de pannen was, is binnenkort voorbij. Je hoeft niet meer eindeloos te (laten) programmeren/inrichten door "vreemden" die jouw taal niet spreken. In de software die wij maken, kun je de "taal" (en dan bedoel ik niet Nederlands of Engels) die gebruiker wil spreken, configureren. Hierna kan de gebruiker in zijn eigen taal de applicatie samenstellen.

De kennismodelleurs binnen ons bedrijf (de mensen die de klant te spreken krijgt) kennen geen Java, weten niet hoe ze een server moeten inrichten. Ze praten met de klant over wet- en regelgeving, vergunningen, beslissingen; over brieven die uit het systeem moeten komen rollen, stukken die gearchiveerd moeten worden, etc. Niet over database-schemas, web-applicaties of Java code.

De abstractie komt weer een stapje hoger te liggen: dichter bij de gebruiker.

*knip*

Ik heb geen algoritmen op mijn naam staan, simpelweg omdat ik van mening ben dat alles al is uitgevonden. Het is de rest van de mensheid op een klein groepje mensen na, dat hier nog achter moet komen.

Dit maakt een hoop duidelijk: jij bent van mening dat computers en software goed genoeg zijn, omdat jij het snapt. Jij vindt waarschijnlijk ook dat een wit pijltje op een 2D scherm via een muis bewegen of op een plankje knoppen indrukken om letters op datzelfde scherm te krijgen een manier van werken is die perfect aansluit op hoe mensen in elkaar zitten en wensen te interacteren met apparaten.

Helaas voor jou zijn we pas twee stappen onderweg in een marathon. De huidige computers en software zijn zo weinig compatible met mensen, dat het bijna niet leuk meer is. Gelukkig voor "ons" als IT-specialisten (tenminste: degenen die dit wel inzien) betekent dat, dat het leukste nog moet komen. En niet dat "alles al is uitgevonden". Als ik dat zou dat zou denken, zou ik direct een ander werkveld zoeken...

[ Voor 17% gewijzigd door MueR op 16-12-2010 10:34 ]

[alwinuzz]

Stel je maakt een generieke tool waarin je het domein definieert, het gedrag beschrijft enz.

Zit je dan niet gewoon op een hoger/abstracter niveau het softwareproduct te programmeren?

[Stoffel]

alwinuzz schreef op woensdag 15 december 2010 @ 03:05:
Stel je maakt een generieke tool waarin je het domein definieert, het gedrag beschrijft enz.

Zit je dan niet gewoon op een hoger/abstracter niveau het softwareproduct te programmeren?

Ook bekend als het Inner Platform Effect. Ik heb tientallen projecten gedaan in soortgelijke domeinen, en ben nog nooit een situatie tegen gekomen waarbij het probleem volledig in een dusdanig generiek systeem viel te vangen. In het begin leek het er soms op, maar er kwamen altijd wel requirements opduikelen waardoor het systeem dusdanig te configureren moest zijn dat het gewoon begon te lijken op de programmeertaal waar het in gemaakt was. Dat wil je zeker niet.

[Verwijderd]

Stoffel schreef op woensdag 15 december 2010 @ 16:03:
Ook bekend als het Inner Platform Effect. Ik heb tientallen projecten gedaan in soortgelijke domeinen, en ben nog nooit een situatie tegen gekomen waarbij het probleem volledig in een dusdanig generiek systeem viel te vangen. In het begin leek het er soms op, maar er kwamen altijd wel requirements opduikelen waardoor het systeem dusdanig te configureren moest zijn dat het gewoon begon te lijken op de programmeertaal waar het in gemaakt was. Dat wil je zeker niet.

*knip*

Dit effect wordt veroorzaakt, doordat bedrijven graag hun eigen 'platform' willen hebben. Dan zijn er mensen die specifiek naar hun APIs gaan programmeren en voor ze het weten zijn de kosten om te switchen naar een ander platform te hoog => $$$ voor bedrijf die het 'platform' gemaakt heeft.

Een andere methode is een platform te maken dat zo ongelooflijk slecht in elkaar zit, maar wel werkt (PHP) en dan 10 jaar later eens besluiten iets betere tools ervoor te bouwen (die voor zover ik weet nog steeds erg slecht zijn).

In sommige bedrijven (het zou me niets verbazen als elk softwarebedrijf van zeg meer dan 100 werknemers op een bepaald moment zijn eigen Turing-complete taal heeft bedacht door een serie van hacks) worden nieuwe adhoc programmeertalen bedacht puur en alleen, omdat iemand zijn ego wilde vereeuwigen; er is geen enkele reden voor het uitvinden van allerlei kansloze tools die geen tientallen manjaren er al in hebben zitten als je niet daadwerkelijk een nieuw algoritme implementeert, of iets met een daadwerkelijk nieuwe toegevoegde waarde (een nieuw type garbage collector telt niet).

Er zijn overigens wel methodes om op een redelijke manier de syntax (je kunt grafische representaties van symbolen ook zien als syntax) van een programmeertaal uit te breiden, zoals de technologie geïmplementeerd in Racket (maar ook hier zijn er weer genoeg redenen waarom het een berg afval is als geheel product al doen ze wel een hele hoop dingen beter dan de meeste programmeertalen).

Voorbeeldje: als je nieuwe syntax in dit systeem definieert, dan worden syntaxfouten al automatisch gemeld voor de nieuwe syntax. Dat gaat je met een aanpak als "we parsen gewoon even deze string" al een stuk meer moeite kosten. Het gevolg is dat als iemand iets in Racket zou maken er geen hoop ellende wordt geproduceerd, maar die ellende lijkt ingebakken te zitten in tools die vergelijkbare taken verrichten in C of PHP. Het punt is dus niet dat het niet kan, maar mensen doen het niet, omdat het teveel moeite kost.

In het kort, al die 'platformen' zouden gewoon bibliotheken (dll/so/whatever) moeten zijn en geen walled gardens, zoals ze nu ook op Facebook geloof ik aan het doen zijn met een soort van kansloze vervanger van email.

[ Voor 197% gewijzigd door NMe op 16-12-2010 12:40 ]

[HawVer]

Stoffel schreef op woensdag 15 december 2010 @ 16:03:
[...]


Ook bekend als het Inner Platform Effect. Ik heb tientallen projecten gedaan in soortgelijke domeinen, en ben nog nooit een situatie tegen gekomen waarbij het probleem volledig in een dusdanig generiek systeem viel te vangen. In het begin leek het er soms op, maar er kwamen altijd wel requirements opduikelen waardoor het systeem dusdanig te configureren moest zijn dat het gewoon begon te lijken op de programmeertaal waar het in gemaakt was. Dat wil je zeker niet.

Als je veel hetzelfde soort business rules hebt dan kun je kiezen om de businessrules vast te leggen. Voordeel bij het definiëren is dat je je niet druk hoeft te maken om de techniek. Dat wordt namelijk al voor je afgehandeld. Maarreh kun je eens een voorbeeld geven waarbij de requirements dusdanig waren dat ze niet generiek waren vast te leggen?

[MueR]

Dit topic gaat even dicht. Ik ga even wat posts van kleuters verwijderen.

En weer open. Er wordt vanaf nu on-topic gediscussieerd. We gaan niet meer op de man spelen.

[ Voor 42% gewijzigd door MueR op 16-12-2010 10:56 ]

[Janoz]

HawVer schreef op donderdag 16 december 2010 @ 09:10:
[...]

Als je veel hetzelfde soort business rules hebt dan kun je kiezen om de businessrules vast te leggen. Voordeel bij het definiëren is dat je je niet druk hoeft te maken om de techniek. Dat wordt namelijk al voor je afgehandeld. Maarreh kun je eens een voorbeeld geven waarbij de requirements dusdanig waren dat ze niet generiek waren vast te leggen?

Even inhaken op deze DSL discussie..

Het is ook niet onmogelijk om die requirements generiek vast te leggen. De vraag is wat je daarmee bereikt. Vaak heb je dan een platform gecreëerd dat geen enkele meerwaarde biedt boven het onderliggende platform, maar waar vervolgens wel erg specialistische kennis voor nodig is aangezien het alleen binnen die klus/organisatie gebruikt wordt. En dan doe ik zelfs nog de aanname dat de opzet goed gegaan is en er niet links en rechts een paar verkeerde ontwerp en/of implementatie vergissingen gemaakt zijn.

Generieke 'uitdruk oplossingen' zijn er al genoeg en die zijn over het algemeen een stuk beter dan degene die je zelf kunt bedenken. De kracht haal je juist uit een specifieke toepassing. Een DSL die als eisjuist niet generiek moet zijn, maar puur binnen dat domein blijft.

Ik heb nog niet zo heel lang geleden op een project gezeten waarbij we op basis van wetgeving af moesten leiden waar iemand recht op had. Daarvoor hebben we logisch programmeren gebruikt en een laag bovenop drools gebouwd. Deze was redelijk specifiek voor dat domein. Het grote voordeel was vervolgens wel dat elk stukje wet en regelgeving een rechtstreekse koppeling had met een stukje DSL code. Door deze mapping konden we duidelijk aantonen welke regelgeving al wel en welke nog niet geimplementeerd was. Ook was vervolgens redelijk simpel te bepalen of die regelgeving ook correct geimplementeerd was.

[Creepy]

Commentaar op MOD acties NIET in dit topic. Daar is Feedback op moderatie binnen de Devschuur voor. Ook ik heb wat moeten verwijderen.

[HawVer]

Janoz schreef op donderdag 16 december 2010 @ 11:42:
[...]

Even inhaken op deze DSL discussie..

Het is ook niet onmogelijk om die requirements generiek vast te leggen. De vraag is wat je daarmee bereikt. Vaak heb je dan een platform gecreëerd dat geen enkele meerwaarde biedt boven het onderliggende platform, maar waar vervolgens wel erg specialistische kennis voor nodig is aangezien het alleen binnen die klus/organisatie gebruikt wordt. En dan doe ik zelfs nog de aanname dat de opzet goed gegaan is en er niet links en rechts een paar verkeerde ontwerp en/of implementatie vergissingen gemaakt zijn.

Een belangrijk probleem waar we nu tegen aan lopen is dat de ontwikkelomgeving uitgefaseerd wordt. Het platform waar we tijden in gewerkt hebben voldoet voor ons niet meer. De uitgever geeft geen ondersteuning meer op het product en dus zullen we over moeten. Nu zitten we in een situatie waarin een groot deel van de business rules vastliggen in de broncode en ook deels in de Gui. Als je over wilt stappen naar een andere ontwikkelomgeving dan zul je alles opnieuw uit moeten werken of over moeten zetten. Het gaat hier om een stabiele applicatie waar ruim 10 jaar ontwikkelwerk in zit door een stevig ontwikkelteam.

Als je kiest voor een aparte database met de businessrules dan heb je die afhankelijkheid niet meer. De techniek doet er niet toe. Dat is een andere afdeling met hun eigen kennis. Stel dat je ontwikkelomgeving weer uitgefaseerd wordt, dan kun je een nieuwe applicatie ontwikkelen die je businessrules aan kan. Dat is de belangrijkste winst, de investeringen die je nu doet zijn geborgd voor de toekomst.

Generieke 'uitdruk oplossingen' zijn er al genoeg en die zijn over het algemeen een stuk beter dan degene die je zelf kunt bedenken. De kracht haal je juist uit een specifieke toepassing. Een DSL die als eisjuist niet generiek moet zijn, maar puur binnen dat domein blijft.

Ik vind dat inderdaad een heel belangrijk punt. Ga je het wiel opnieuw uitvinden. Probleem hier is dat je op zoek gaat naar een specifieke oplossing die zo dicht mogelijk bij het 'optimale beeld' komt. en niet het optimale beeld zelf is!

Ik heb nog niet zo heel lang geleden op een project gezeten waarbij we op basis van wetgeving af moesten leiden waar iemand recht op had. Daarvoor hebben we logisch programmeren gebruikt en een laag bovenop drools gebouwd. Deze was redelijk specifiek voor dat domein. Het grote voordeel was vervolgens wel dat elk stukje wet en regelgeving een rechtstreekse koppeling had met een stukje DSL code. Door deze mapping konden we duidelijk aantonen welke regelgeving al wel en welke nog niet geimplementeerd was. Ook was vervolgens redelijk simpel te bepalen of die regelgeving ook correct geimplementeerd was.

Wat bedoel je met een laag drools? Dit lijkt wel wat op de oplossing waar wij naar streven. Alleen we gaan wel zo een brede markt bedienen dat ik me afvraag of het niet voor een grotere groep toepasbaar kan zijn? Waar we mee bezig is de fiscale wetgeving. Dat veranderd meerdere keren per jaar. Dat wil je niet verspreid in allemaal losse source bestanden hebben. Wat een hel is dat elke keer als je dit volledig moet aanpassen.

[Janoz]

HawVer schreef op donderdag 16 december 2010 @ 13:38:

Wat bedoel je met een laag drools?

http://www.jboss.org/drools

[Woy]

Als ik het goed begrijp is dat een beetje een Java tegenhanger van Windows Workflow Foundation?

[Verwijderd]

TS, mijn vorige werkgever verkocht Microsoft AX / Dynamics-systemen. Dat vond ik al overkomen als dingen zo generiek mogelijk neerzetten en er dan vervolgens iets omheen kunnen bouwen dat het toch redelijk bruikbaar maakte. Die gasten gaan een dagje, of 2, naar een klant en er staat een systeem (hoeven daarna nooit meer iets te doen en lopen wel binnen). Bedoel je het een beetje in die richting?

Ik ben ook al jarenlang geinteresseerd in hoe je zulk soort dingen met zo min mogelijk arbeid kunt neerzetten, maar het is ook best tricky.

[ Voor 34% gewijzigd door Verwijderd op 28-12-2010 11:27 ]

[Verwijderd]

Je kan in hoge mate van de applicatie programmeur af. Het nadeel is dat dit tot zover alleen kan met tooling die beperkend is qua inzetbaarheid. Zo werkten we op UTwente met een tool van Mendix en niet-programmeurs (enkele buitenlandse studenten) wisten daar iets moois in te bouwen; vooral handig voor web services en proces/ketenintegraties. Er zijn echter legio toepassingen waar je een andere aanpak wilt gebruiken.
Je ziet echter dat dat bedrijfje het breder inzetbaar wil maken. Wie weet waar dergelijke programma's de IT gaan brengen.

En je hebt altijd programmeurs nodig om dergelijke tools te bouwen

Zolang je het doel en context maar goed voor ogen hebt kun je al veel.

[ Voor 38% gewijzigd door Verwijderd op 28-12-2010 13:59 ]