Category Archives Modeling

Robert-Jan Streng

Logistiek Denken: De moeder van Agility

No Comments »

Het denken in dynamische systemen heeft aan het eind van de zestiger jaren van de vorige eeuw – wellicht aangezwengeld door een toenemend gebruik van stimulerende middelen – een grote vlucht genomen. Twee belangrijke exponenten daarvan waren “de Club van Rome” (milieudenkers avant la lettre, de jongste generatie moet dat maar even opzoeken op Wikipedia) en een spel dat op MIT is ontwikkeld onder de naam “The Beer Game”. Een in de basis simpel spel dat een keten simuleert van een producent van bier (noem dat nooit een fabriek maar een brouwerij) tot aan de uiteindelijke consument. Deze keten bestaat uit verschillende schakels die allemaal hun uiterste best doen om te doen waar ze goed in zijn: distribueren, verkopen, transporteren. En je raadt het al: deze keten is niet in staat om om te gaan met veranderingen in de vraag. Simpel gezegd: ze maken elkaar allemaal hartstikke gek, praten elkaar de put in als het niet nodig is, en beginnen euforisch met extra productie op de dag dat de klant besluit te minderen met zijn bierconsumptie. Zie de raakvlakken met de huidige economie, begrippen als het “zweepslageffect” komen hier uit voort.

Nu wil ik er niet al te veel over kwijt want je moet het zelf ervaren. En met dank aan collega’s Han Koper en Bern Klomp kunnen onze klanten zelf ervaren hoe dat in zijn werk gaat: een perfect element van een heidag, mooi in te kaderen in het Agile denken. We hebben lange speeltafels, een heleboel kleine biervaatjes, en een compleet verhaal op Factsheet. Het spel duurt zo’n 2 a 3 uur en is daarna een mooie gelegenheid om een biertje te drinken. Oja: halverwege het spel vragen we de deelnemers hoe je nu wél Agile kunt worden, en dat mogen ze dan meteen uittesten.

Wie durft?

Kees Kranenburg

A Legacy You Don’t Want to Inherit

No Comments »

Today many companies are still dogged by their so-called legacy applications. The past decades hundreds, if not thousands applications were developed with the use of nowadays outdated programming tools. The use of these outdated tools has resulted in poorly supported business processes.

In our rapidly changing world companies need to be able to adapt their business processes quickly. The main incentives for this being the integration of business processes, business process redesign because of mergers, and the selling-off of parts of companies. Most business processes have become accessible to customers and third-party businesses by means of web applications.

In case of legacy applications this has not been easy because the structure of most legacy applications isn’t compatible with today’s (internet and mobile) technology. Moreover, after decades of changes and fixes the internal workings of many legacy applications have become almost undecipherable and the usually outdated system documentation doesn’t alleviate this situation either.

To add to the problem suitably experienced personnel with sufficient knowledge of obsolete programming tools are hard to come by.  The last few years various specialist IT journals reported a shortage of qualified IT personnel. European Commissioner Neelie Kroes fears also a great scarcity of app developers in the European ICT market.

For outdated programming tools this problem is bigger still because the reservoir of suitable employees is not going to increase – which company is going to train its personnel in any other language than for example Java or C#? Moreover, many developers of legacy applications together with the employees who service these applications will retire in the not too distant future. It is a safe prediction that the shortage of employees capable of operating these outdated programming tools will become much bigger than currently is the case.

To solve these problem, we should automate the automation. In my blog ‘Wanted: The Software Industry Architect’, I plea for the appliance of Model Driven Development (MDD) practices to increase software development productivity. Moreover, the same MDD concepts and practices can be used to transform the legacy code to a service-oriented architecture to be deployed in a PaaS / SaaS platform.

To summarize the approach: The legacy application is analyzed and any obsolete code is eliminated. Next the more interesting parts of the application such as data entities and business logic are identified and transformed to a more abstract higher level model. This model is optimized which means that new functionality is added and the model is tailored to make the application suitable for deployment in the Cloud. The models are documented using state-of-the-art tools in a PaaS environment. It is this model that, on the basis of MDD principles, is used to newly generate and transfer the application to a Microsoft Azure platform or Java Cloud platform.

Maybe this all sounds very utopian to you – deduce high level models from legacy software applications and generate from these models new Cloud applications. So, it will be worthwhile to follow the research project ARTIST in which a consortium of ten leading academic and industry organizations are exploring the appliance of MDD for legacy transformation to the Cloud.

Kees Kranenburg

Model Driven Development maakt Agile Offshoring mogelijk

No Comments »

Gedreven door het huidige economische klimaat heeft offshoring bij veel organisaties volop aandacht. Offshoring betekent het uitvoeren van gedistribueerde software ontwikkelprojecten, waarbij afstanden en tijd-, taal- en cultuurverschillen tussen projectteams belangrijke obstakels zijn. Om die obstakels te omzeilen, vallen veel IT organisaties terug op de klassieke watervalmethode van systeemontwikkeling.

Projectteams in verschillende landen kunnen hierdoor opeenvolgend en schijnbaar autonoom werken aan hun ontwerp-, bouw- of testdeelproject. Communicatie tussen de teams onderling en de opdrachtgever beperkt zich tot de overdrachtsmomenten van deliverables. Pas tijdens de acceptatietest wordt de kloof die tijdens het project is ontstaan tussen de – door voortschrijdend inzicht gewijzigde –  implementatiedoelstellingen van de opdrachtgever en de uiteindelijke software levering pijnlijk duidelijk.

De noodzaak van kostenbesparing door offshoring herintroduceert zo een werkwijze in systeemontwikkeling waarvan de tekortkomingen al sinds de jaren ’80 van de vorige eeuw bekend zijn. Anno 2013 past een lineaire, contact- en communicatiearme ontwikkelaanpak niet bij de marktgerichte dynamiek van de hedendaagse, moderne bedrijfsvoering. Verschillende Agile ontwikkelmethodieken zijn al geruime tijd voorhanden om met die dynamiek om te gaan, maar lijken vooralsnog lastig te combineren met offshoring.

Eerder heb ik in deze blogs Model Driven Offshoring geïntroduceerd. Bij model driven development wordt het structuurmodel van de applicatie gegeneerd, maar de lastig te genereren business logica wordt in de praktijk meestal handmatig geprogrammeerd. Door dit programmeerwerk uit te voeren op een offshore locatie, worden kosten bespaard. Model Driven Offshoring combineert zo de voordelen van een hoge productiviteit en lage arbeidskosten. Uit ervaring hiermee  blijkt dat Model Driven Development tevens het gebruik van moderne Agile methodieken in offshored ontwikkelprojecten mogelijk maakt. Projectsturing op basis van “business value” en evaluatie van frequent opgeleverde werkende software releases door leverancier en opdrachtgever staat daarbij centraal.

Eén multidisciplinair ontwikkelteam van Nederlandse en Indiase medewerkers ontwikkelt deze software releases. Ontwerp-, ontwikkel- en testtaken worden tussen medewerkers en locaties verdeeld en deels parallel in plaats van gefaseerd uitgevoerd. Model Driven Development levert hierbij de eenduidige systeemarchitectuur en het structuurmodel aan het gedistribueerde projectteam, waardoor een agile projectinrichting mogelijk is. Wijzigingen in business logica kunnen snel worden geïmplementeerd, ondanks de afstand en de taal- en cultuurverschillen in het team. Dit architectuurkader wordt aangevuld met continuous integration als leidend programmeerprincipe, ondersteund door build- en testomgevingen die ook voor de opdrachtgever toegankelijk zijn. Continuous integration garandeert dat business logica na implementatie direct kan worden getest door leverancier én opdrachtgever. De bezwaren van langdurige geïsoleerde software ontwikkeling op een verre locatie buiten het zicht van de opdrachtgever, worden door deze agile offshoring aanpak weggenomen.

Daarom is mijn vraag in 2013: agile offshoring: durf u het aan? Ik zie jouw reactie graag tegemoet.

Ronald Streekstra

The Four Laws of Simplicity, and How to Apply Them to Life

No Comments »

Last week I came across an article with the above title. While reading, it crossed my mind what would happen if we would substitute the last word for Enterprise Architecture. First let me give you an idea of the article.

read more

Ronald Streekstra

Als je vandaag wilt begrijpen, moet je op zoek gaan naar gisteren

No Comments »

Hoewel ik zelf niet zo’n wandelaar ben, heb ik de afgelopen jaren toch heel wat wandelingen gemaakt door diverse IT-landschappen. Dit gaat vaak op een intuïtieve manier. Je verkent de omgeving, een kaart is vaak niet voorhanden of verouderd, vervolgens zie je iets interessants en je prikt eens verder. Langzamerhand bouw je een mentale kaart op. Hoewel best leuk om te doen, kost dit al back-trackend opbouwen van een kaart best veel tijd

In de filmindustrie maakt men gebruik van Storylines om een verhaal inzichtelijk te maken. Dit is een techniek waarbij op de horizontale as de tijd staat en op de verticale as staat de cast. Als de cast met elkaar interacteert, worden ze bij elkaar geplaatst. Hieronder een voorbeeld uit Lord of the Ring.

Click to enlarge (http://xkcd.com/657/large/)

Deze techniek is te vertalen naar IT. Een onderzoeksafdeling van de Universiteit van California heeft het gebruikt om code wijzigingen bij de ontwikkeling van een applicatie te visualiseren. Het vergelijken van “foto’s” van diverse applicaties geeft inzicht van hoe complex de ontwikkeling van een applicatie is. Het verschil met de film storyline is dat de applicatie plaat gegenereerd is in plaats van getekend. Als bron voor de applicatie plaat worden programmeur-commits op het versiebeheer systeem gebruikt. Links zie je de ontwikkeling van Ant, recht die van python.

http://www.michaelogawa.com/research/storylines/

Een tweede toepassinggebied zie ik op een iets grotere schaal. Als we de actoren vervangen door applicaties en ontmoetingen van acteurs met connecties door systemen dan kunnen we evolutie van een  systeemlandschap in kaart brengen. Om de grafiek geautomatiseerd te kunnen genereren, hebben we een beschrijvende bron nodig. Dit zou heel goed een Archimate beschrijving kunnen zijn of een CMDB met daaraan toegevoegd een vorm van versiebeheer. En dat levert je niet alleen een kaart maar ook begrip over hoe het zo ontstaan is en dan vind ik wandelen in eens weer veel leuker.

*De titel is een citaat van Pearl Buck.
Kees Kranenburg

Model Driven Offshore

2 Comments »

Model Driven Architecture (MDA) gave software modeling and software generation a new impetus. Developed by the Object Management Group, MDA succeeded in defining a framework for software engineering. To many of us, MDA is a familiar concept. First, a high-level system model is developed. Next, system requirements are modeled. Finally, with the system requirements acting as a base, the software is generated, rendering a complete and working application.

However, the MDA model is considered to be somewhat academic. This is why software engineers prefer to talk about Model Driven Development. Applying a model-driven approach can drastically enhance the whole software engineering cycle, from analysis through to maintenance. The application generator, for example, is already used during the system specification phase enabling working system versions to serve as prototypes. Designing and programming have been replaced by modeling and generating. Therefore, the software engineer no longer has to deal with cumbersome technical platform details, resulting in an improved productivity and improved quality, and a less complex application maintenance process.

One of the shortcomings of Model Driven Development is generating the business logic. Tools can nowadays generate software based upon data structure models, i.e. using Unified Modeling Language. They generate retrieve, update, delete and query functions, including key constraints, referential integrity, mandatory attributes rules, some validation rules, enforced update and delete constraints, browse synchronization between parent and child relations, and a default user interface. But these tools are deficient in handling the business logic. One of the reasons for this is the lack of an international standard for defining business rules. This implies that the business rules specifications have to be coded manually.

Business logic is usually specified in Word documents, and coding them is done by hand in, for example, C# or Java. As we know, programming in C# or Java is very labor-intensive and expensive when done in Europe. However, when something is labor-intensive, we prefer to source these activities in low-cost offshore delivery centers. This is how the Model Driven Offshore concept was born. It combines the benefits of Model Driven Development with the benefits of off shoring.

Model Driven Offshore – a pun or the near future?

Ronald Streekstra

Everything you wanted to know of TOGAF but were afraid to ask

No Comments »

Jan Dietz en Jan Hoogervorst hebben in het artikel An Enterprise Engineering based Examination of TOGAF het architecture framework van The Open Group ook wel bekend als TOGAF geëvalueerd.

Persoonlijk heb ik gemengde gevoelens bij TOGAF. Aan de ene kant is het goed dat we het vakgebied enterprise architectuur professionaliseren maar aan de andere kant vraag ik me af of we daar een boek van ruim 700 pagina’s voor nodig hebben. Met veel plezier heb ik tijd vrijgemaakt om de 20 pagina tellende evaluatie te lezen.

De evaluatie geeft aan dat TOGAF onvoldoende duidelijke definieert wat nu eigenlijk termen als architectuur, framework, principes en governance betekenen. Vervolgens leggen de auteurs een theoretisch kader neer waarmee ze die termen een eenduidige betekenis geven. Hierbij gebruiken ze onder meer de Enterprise Engineering methode als basis. Tenslotte evalueren ze aan de hand van dat theoretisch kader TOGAF waaruit blijkt dat TOGAF onvoldoende duidelijk in zijn definitie is en vragen ze zichzelf af wat dat zegt over de architecturen die je er mee creëert.

Ik zie de evaluatie vooral als een waarschuwing richting TOGAF dat er meer nagedacht moet worden over de fundamenten. Want op losse fundamenten bouw je geen stabiel framework. Hierbij moeten we vooral ook kijken naar het ontstaan van TOGAF. Heel veel architecten hebben een klein stukje bijgedragen aan het geheel, om het geheel dan onderling consistent op te leveren is een flinke uitdaging. Het artikel geeft goed aan dat TOGAF op dit gebied nog meer sturing nodig heeft. Hopelijk helpt de TOGAF evaluatie in formelere definities binnen The Open Group.

“To TOGAF or not to TOGAF” is NOT the question

Graag plaats ik TOGAF en het artikel in een wat breder perspectief. Want of het praktijk gebaseerde TOGAF of het theoretisch doortimmerde Enterprise Engineering nu de waarheid is, beiden gaan uit van de maakbaarheid van een organisatie. read more

Erik Vermeulen

Enterprise architectuur voor meer flexibiliteit

No Comments »

In 2006 deed het Atos Consulting Trends Institute onderzoek naar de stand van zaken rondom het gebruik van enterprise architectuur in Nederland. Toen concludeerden wij dat er nog een flinke uitdaging lag om enterprise architectuur in samenhang te ontwerpen en niet te verdrinken in details. Ook zagen wij dat enterprise architectuur grotendeels toebehoorde aan het IT-domein maar dat de business steeds meer te zeggen kreeg over enterprise architectuur.

Ook vroegen we ons af wat de motivatie is om te investeren in enterprise architectuur. De meeste respondenten gaven toen aan dat het belangrijkste doel is om de flexibiliteit van de organisatie te vergroten en zo beter in te spelen op toekomstige veranderingen en ontwikkelingen.

In 2010 hebben we opnieuw onderzocht hoe het staat met de toepassing van enterprise architectuur in Nederland. Hierbij waren we met name op zoek naar de trends.

Een opvallende trend is de motivatie om te investeren in enterprise architectuur. Wij verwachtten dat de crisis de nodige uitwerking zou hebben op de opdracht voor de enterprise architecten. De verwachting was dat het aandeel efficiëntie in 2010 aanzienlijk hoger uit zou komen dan in 2006. Immers, veel organisaties moesten hard ingrijpen als antwoord op de sterk teruglopende inkomsten.

Maar tot onze verrassing blijkt dit niet zo te zijn. Sterker nog, de respondenten geven aan dat flexibiliteit als hoofddoel om enterprise architectuur toe te passen anno 2010 nog verder is toegenomen en dat efficiëntie juist is afgenomen. En, in het verlengde hiervan, er is ook niet gesneden in het aantal enterprise architecten. De populatie enterprise architecten is – in tegenstelling tot de architecten in brede zin – ook op sterkte gebleven.

Goed nieuws dus voor enterprise architectuur. Het lijkt erop dat het vertrouwen in de strategische bijdrage van enterprise architectuur is geworteld in de bestuurskamer. Door te investeren in enterprise architectuur kunnen organisaties de wendbaarheid vergroten zodat conjuncturele ontwikkelingen beter kunnen worden opgevangen. Een slanke organisatie kan sneller een markt binnentreden en er weer uit verrekken en kan sneller resources herpositioneren.

Kosten besparen doe je niet alleen door te snijden in de uitgaven maar ook door te investeren in een wendbare organisatie die grip weet te houden op dure complexiteit. Want dweilen is een stuk minder vervelend als de complexiteitskraan dicht zit.

Het gehele onderzoeksrapport is te vinden op de enterprise architectuur pagina van Atos Consulting

Kees Kranenburg

Het einde van one-size-fits-all applicatiebeheer

No Comments »

Hoeveel applicaties heeft een bedrijf in gebruik? Al snel te veel om op te noemen. Sommige daarvan draaien al jaren in trouwe dienst, andere komen net kijken. Elk van die applicaties vraagt om een ander soort applicatiebeheer.

Met de opkomst van beheermodellen als ITIL, ASL en IT Service CMM is het beheren van infrastructuur en applicaties geprofessionaliseerd. Geïndustrialiseerde werkwijzen, al dan niet gecombineerd met global sourcing, worden steeds meer toegepast. De geprofessionaliseerde en geïndustrialiseerde werkwijze biedt vele voordelen, maar het vereist ook een goed begrip en kennis van hoe deze werkwijze in te zetten en in lijn te brengen met de eisen van de organisatie.

Parallel aan professionalisering en industrialisatie van IT neemt de vraag naar flexibiliteit toe. Dit is het gevolg van toenemende dynamiek in marktomstandigheden en daarop aanpasbare bedrijfsvoering. Verbetering van de wendbaarheid legt extra eisen op aan het beheren van het IT- en applicatielandschap. read more

Ronald Streekstra

Building Architecture in a day

No Comments »

Een leuke manier om de structuur van een stad te visualiseren is afgelopen jaar gepubliceerd door de universiteit van Washington. Op basis van foto’s op het web van een stadsdeel wordt van elk foto bepaald waar hij genomen is en wat er te zien is van het onderwerp. Door heel veel foto’s samen te nemen onstaat er een driedimensionaal beeld van het onderwerp.

 
 
 
 

Rome

Rome

 

…we consider the problem of reconstructing entire cities from images harvested from the web. Our aim is to build a parallel distributed system that downloads all the images associated with a city, say Rome, from Flickr.com. After downloading, it matches these images to find common points and uses this information to compute the three dimensional structure of the city and the pose of the cameras that captured these images. All this to be done in a day…
 
Dit deed me denken aan het in kaart brengen van de ist-situatie in een IT-landschap
 
Application Portfolio Scan (APS)
 
ATISAPS is een aanpak om applicatielandschappen in kaart te brengen. Om deze aanpak te ondersteunen heeft Atos Origin een tool, een fototoestel zo je wilt, ontwikkeld: Het Atos Tool voor Inventariseren en Scoren (ATIS). ATIS is een web-based tool, waarmee informatie over applicaties vanaf diverse locaties verzameld en bij elkaar gebracht kunnen worden. Om een beter beeld te krijgen van een applicatielandschap wordt tijdens de analyse van de verzamelde informatie worden doorgaans architectuurmodellen gemaakt van de applicaties en hun omgeving. We gebruiken hiervoor de taal ArchiMate en het tool Architect® van BiZZdesign, maar het modelleren blijft een arbeidsintensief werk! Atos Origin en BiZZdesign hebben daarom de samenwerking gezocht. Op basis van een nieuwe import functie heeft BiZZdesign een module ontwikkeld die de informatie uit ATIS leest en importeert in het Architect tool.
 
Integrale Configuratie Management (CMDB)

Afgelopen jaar is een integrale content management database geimplementeerd waarin naast de ATIS foto’s ook ruimte is voor gegevens uit configuratie en asset management systemen voor infrastructuur (uit Configuration Management Databases) en Business Processen (uit BPM repository). Deze CMDB bevat daarmee de relevante informatie over infrastructuur, applicaties en bedrijfsprocessen en de onderlinge relaties. Het centrale model is zo ontworpen dat van hieruit een ArchiMate repository wordt gegenereerd voor het BiZZdesign Architect® tool. Met behulp van Architect® kunnen specifieke views worden gemaakt. Met deze views is het mogelijk om met diverse belanghebbenden (stakeholders) interactief door het hele technische en bedrijfslandschap te navigeren om lternatieven te evalueren en uiteindelijke besluitvorming voor te bereiden. Op basis van deze views kan met goed inzicht worden besloten.
 
Ronald Streekstra
met dank van Hans van Drunen voor de APS en CMDB tekst