Het is met de economische waarde van programmacode net als met onroerend goed. De belangrijkste drie bepalende factoren zijn: locatie, locatie en locatie. Waar (en hoe lang) de programmeercode wordt gebruikt bepaalt de levensduur en de waarde van deze code.
Kijken we naar de leeftijd van alle in nog in bedrijf zijnde software, vermoed ik dat 90 procent – van alles wat ouder is dan 25 jaar – draait in de database zelf, niet in middleware- of front-end-applicaties. In moderne crm- en erp-systemen wordt systeeminrichting gedaan in de applicatie. Structurele ‘customization’ van de applicatie zelf is nooit mogelijk. Hierdoor zijn de gemaakte attributen van de inrichting vaak ‘second class citizens’ in de web-api van de applicatie in vergelijking tot de basisfunctionaliteit zelf. Soms zie je allerlei configuratie/implementatie-attributen zelfs alleen maar terug in de gui’s/frontends. Gevolg is dat je bij iedere front-end-migratie weer heel veel configuratie opnieuw mag doen en dat de configuratie niet overal beschikbaar voor is, maar op zijn best als data en nooit als dynamiek in de structuur.
Daar waar de applicatie zelf gebruik moet maken van web-api’s kan dat ook niet ver genoeg achter in de database gebeuren. Een dramatische versimpeling kan worden gecreëerd door een http-webrequest stored procedure beschikbaar te maken in de database. In T-SQL kan dit met een clr stored procedure in C#. In andere databases zullen ongetwijfeld soortgelijke oplossingen mogelijk zijn.
Programmastappen
Door de bedrijfsprocessen en overige vakmaterie van de toepassing zoveel mogelijk in te bedden in de database, kan de web-api middleware zich beperken tot het assembleren van algemene scripts die gebruik maken van de in de betreffende database aanwezige stored procedures. In powerautomation/flow gebouwde middleware kan daardoor het aantal programmastappen worden terug gebracht tot onder de tien, twintig, terwijl halen en brengen van en naar de database in opvolgende stappen vaak tot trage en hopeloos complexe structuren leidt.
Door de vakmaterie-deskundigen van de opdrachtgever al in het vroegste stadium bij de ontwikkeling van de stored procedures te betrekken, kan het project functioneel haast in zijn structuur worden ge-customized, niet uitsluitend op implementatie/inrichtingsniveau. Een uitgelezen manier om kroonjuwelen en het tafelzilver van elk project volkomen tijdloos te maken.
Veel Intellectueel Eigendom (IP) zit ingesloten in code omdat dit reversed engineering bemoeilijkt want softwareleveranciers halen nu eenmaal meer economische waarde uit hun code door het gebruiksrecht middels licenties te regelen. Hierdoor hebben applicatieportfolio’s overlappende functionaliteiten omdat bedrijfsgegevens veelal opgeslagen liggen in een variëteit aan bestandsformaten die allerlei computerprogramma’s nodig hebben doordat de syntaxis en semantiek voor ontsluiting van de informatie in de broncode opgesloten zit. En natuurlijk zijn stored procedures in de databaselaag efficiënter maar steeds meer data werd ongestructureerd opgeslagen omdat alles in databases stoppen problemen met de schaalbaarheid en de onderhoudbaarheid opleverde. Van de 25 jaar oude code werd veel geschreven vanuit een ‘loosly coupled’ paradigma waarbij een query via een http-webrequest misschien niet efficiënt is maar wel flexibel.
@Oudlid, inzake dat laatste (http-webrequest niet efficiënt, wel flexibel), als je in allerlei formaat opgeslagen bedrijfsgegevens ontsluit door er een webAPI omheen te bouwen (dat concludeer ik uit je suggestie inzake flexibel) is het voor workflow en robotic process automation nog steeds waardevol steeds een volle 3-tier architectuur als client van die webAPI’s te hebben (en de API’s zoals gezegd aanroept vanuit de database). Wat een niet-menselijke client ook doet met een API, er moet iets met de resultaten gebeuren. Het opvraagresultaat is hoogstens bij mensen voor vluchtige inzage. Het voordeel ontstaat juist doordat je een client bouwt op een volledige applicatie-architectuur, althans dat is een van de invalshoeken van waaruit je het kunt bekijken. Iedere volwaardige 3-tier applicatie kun je aan de achterkant tot client laten verworden zonder dat het interfereert met de bestaande opbouw ervan. Iedere applicatie blijft aan de voorkant applicatie en wordt zo aan de achterkant client. Overigens kun je CLR-stored procedures prima beschermen tegen reverse engineering. Die ontwikkel je precies zo als code voor de middle-tier. Ook scripts kun je waarschijnlijk wel beschermen. Maar scripts worden steeds weer on-the-fly geassembleerd en zijn weg zodra ze hebben gelopen. Als je het resultaat hebt afgevangen, kun je het nog steeds niet assembleren. Op die manier je IP beschermen lijkt me ook niet meer zinvol. Als je in staat bent commercieel en technisch aan de slag te gaan met het gestolene, bouw je het liever zelf en wordt je door compilatie eventueel echt niet tegen gehouden.
Rob,
Reversed engineering van bedrijfsprocessen gaat – zoals je zelf zegt – om het optimaliseren van de verwerking. Bijvoorbeeld door conform de Theory of Constraint de onnodige stappen weg te nemen of de inefficiënte stappen te verbeteren wat uiteindelijk dus alleen maar kan als er geen black boxes in je stack zitten. Leveranciersafhankelijkheid aangaande programmacode bemoeilijkt de pogingen om de transactiekosten in je stack te verlagen en dat geldt natuurlijk ook als je alles probeert vast te leggen in stored procedures omdat dit je afhankelijk maakt van een bepaalde database. Natuurlijk is elke workload min of meer uniek maar telkens statische informatie opvragen door ieder keer de gehele stack door te gaan kan economisch nogal onvoordelig kan zijn. En ik ben het dus met je eens dat het terug brengen van stappen in de stack een economisch voordeel brengt maar ik heb mijn twijfels over de weg die jij wilt volgen.
@Oudlid – reverse engineering (het ontrafelen van de werking van een apparaat of computerprogramma zonder de beschikking te hebben over de bouwplannen volgens https://www.encyclo.nl/begrip/Reverse_engineering ). Het gaat m.i. nooit om optimaliseren van verwerking. Dat zou je er hoogstens onder bepaalde beperkende omstandigheden eventueel mee kunnen doen. Ik dacht dat je eraan refereerde m.b.t. bescherming van intellectueel eigendom en daar heb ik inhoudelijk op gereageerd. mvg Rob.
Rob,
Aangezien je de definitie van reversed engineering opgezocht hebt weet je ook dat het een legale manier van IP kopieëren is. En ja, ik wees op de wijze waarop code beschermd wordt en waarom dat innovatie beperkt. Veel open source licenties verlenen daarom toestemming om de broncode voor een efficiëntere implementatie aan te passen of om nieuwe functionaliteit toe te voegen. Meestal met een teruggave verplichting. Ik pleit niet voor Open Source maar geef alleen maar aan dat CAPEX hiervan een korte afschrijvingstermijn heeft waardoor je vaak sneller kunt innoveren in je bedrijfsprocessen. Daar tegenover ligt de OPEX wel hoger door de DIY in ontwikkelingen waardoor we op het dilemma van kopen of zelf doen komen. Natuurlijk is de hybride oplossing waarbij je een pakket koopt om er vervolgens maatwerk van te maken ook mogelijk maar vaak loop je dan weer vast in allerlei contractuele interties die de innovatie vertragen en de onderhoudskosten verhogen.