Afgelopen dinsdag werd voor de vijfde keer Talk About IT in Amsterdam georganiseerd.Talk About IT is een platform voor het delen van kennis en ervaring op het gebied van IT. Het thema van deze editie was ‘hoe maak je een succes van internationale outsourcing?’. Er waren vier sprekers die het thema vanuit verschillende invalshoeken bekeken.

John Blazey, director engingeering van TomTom deelde zijn ervaringen in het opzetten van offshore en nearshore teams. John heeft ervaring met teams in India, China, Polen en nog een aantal landen. Hij onderscheid vier manieren voor offshoring:

1. Black Box: specificaties worden opgesteld, leverancier neemt het project op vaste prijs aan
2. Activity: een bepaalde activiteit wordt uitbesteed, bijvoorbeeld testen
3. New team: een team wordt van scratch samengesteld door een offshore leverancier of zelfstandig
4. Team members: er worden individuen ingehuurd die rechtstreeks aangestuurd worden

Tomtom gebruikt een mix van deze vormen, waarbij John aangaf de meest negatieve ervaringen te hebben met black box outsourcing. Zijn tips:

1. Als je het geld hebt, steek alles dan in het stroomlijnen van communicatie (het bezoeken van elkaar hoort hier bij)
2. Het duurt meestal 6 maanden voordat een nieuw teamlid je bedrijf en systemen volledig begrijpt, investeer deze tijd
3. Houd zelf de interviews met de team leden bij de selectie
4. Beschouw het team als je collega’s.

Hugo Messer, CEO van Bridge Global IT Staffing presenteerde 1 centraal idee: Onze grootste uitdaging is het inleven (empathie) en samenwerken met mensen van over de hele wereld. We hebben op dit moment niet voldoende IT-ers in West Europa en dit tekort zal toenemen door vergrijzing en het kleine aantal IT-afstudeerders. Door talent uit het buitenland te betrekken, kunnen we gemakkelijker de juiste persoon op de juiste posities krijgen. Om dit voor elkaar te krijgen is een aantal onderwerpen belangrijk:

1. Culturele verschillen: deze moeten we accepteren zoals ze zijn, door acceptatie kunnen we om de verschillen heen organiseren.
2. Mindset: de taart wordt al maar groter, banen die verplaatst worden naar het buitenland betekenen niet automatisch verlies van banen in Nederland.
3. Relaties: de gedachte ‘wij’ en ‘zij’ (‘die Oekraieners’) helpt ons niet
4. Gebruik management instrumenten zoals 360 graden feedback, persoonlijke ontwikkelplannen om je offshore team echt bij je te betrekken
5. Stimuleer empathie: tussen je mensen, met je bedrijf, met je product

Chris Smit van Culture Matters gaf ons inzicht in de cultuur verschillen die een rol spelen bij internationale samenwerking. Hij maakte ons bewust van de verschillen die bestaan aan de hand van  vier dimensies van Geert Hofstede (power distance, individualism, masculinity, uncertainty avoidance). Opvallend waren zijn adviezen aan Nederlanders: Wees minder direct; maak geen grapjes (echt niet!), investeer meer tijd in het bouwen van relaties, luister (en stop met praten)  en richt je op details. 

De laatste spreker was Wilco Turnhout van Rapid Circle. Wilco heeft met zijn bedrijf een vestiging opgezet in Pune, India, waar inmiddels ruim 20 mensen werken. Hij deelde zijn ervaringen met het aantrekken van talent. In Nederland is het erg lastig om sharepoint ontwikkelaars te vinden, terwijl ze in Pune wekelijks 10 sollicitaties krijgen van ervaren Sharepoint mensen. Wilco bevestigde dat het investeren van tijd in bezoeken wederzijds, dagelijks skype-overleg en het vieren van successen helpen.  

Related posts:

1. Talk About IT Eindhoven toont hoe ICT op één lijn komt met zakelijke activiteiten
2. Eerste Talk About IT Event groot succes
3. Behendige teams maken productontwikkeling beheersbaar

A reader remarked about my recent article on Salesforce.com, “Frankly, this looks like a plug for Scrum.” Well, yes.

If there was a Nobel Prize for management, and if there was any justice in the world, I believe that the prize would be awarded, among others, to Jeff Sutherland, Ken Schwaber and Mike Cohn for their contributions to the invention of Scrum. Until recently, like most people, I had never heard of Scrum. This is not surprising, as it is rarely mentioned in general management textbooks or discussed in business schools. I came across Scrum several years ago, almost by accident.

My discovery of Scrum

At the time, I was working on a book focused on resolving an old management conundrum: how do you combine rapid innovation with disciplined execution? I was proceeding by asking people if they knew about any such workplaces where this was already happening.

I surprised to find that an unusually high proportion of the workplaces that I heard about were in software development. Initially I didn’t pay it any attention. After all, these were geeks, and they talked in a strange, barely comprehensible vocabulary. What could I possibly learn about management from people who had, I imagined, gone into computing because they preferred machines to people?

A colleague, Hans Samios, a manager at Intergraph Corporation in Alabama, contacted me and suggested that I check out what was happening in software development firms, under the names of Agile and in particular, the practices known as Scrum. I had never heard of Scrum, but I decided to check it out.

The history of Scrum

I learned that the first full implementation of Scrum had occurred in 1993 when Jeff Sutherland along with John Scumniotales and Jeff McKenna implemented Scrum at the Easel Corporation.

They drew on the inspiration of the classic 1986 HBR article “The New New Product Development Game,” where Takeuchi and Nonaka had compared a new holistic approach to innovation to the sport of rugby, where the whole team “tries to go to the distance as a unit, passing the ball back and forth”. This paper in turn drew on a long experience of iterative methods.[1]

In 1995, Sutherland and Schwaber jointly presented a paper, ”The SCRUM Development Process,” at Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) Conference ‘95 in Austin, Texas, its first public appearance.

In 2001, Sutherland, Schwaber, and fifteen colleagues got together in Snowbird, Colorado, and drafted the Agile Manifesto, which became a clarion call to software developers around the globe to pursue this radically different type of management.[2]

Since then, Sutherland, Schwaber, and their colleagues have gone on to generate thousands of high-performance teams in hundreds of companies all around the world under the labels of Scrum and Agile.

Other important contributions to the Scrum practices were made by Mike Cohn with the development of user stories as the principal tool for describing client-oriented goals of work, along with the development of story points as a way of measuring the quantity of work and the velocity of teams.

What are the practices of Scrum?

When I checked out what was going on in these companies, I could see that underneath the cover of an esoteric terminology, these software developers had discovered a solution to the problem of combining disciplined execution of high-level intellectual work with continuous innovation.

If you extract the practices of Scrum from the esoteric vocabulary in which it is expressed for software developers (“sprints”, “burndown charts”, “product owner”, “scrum-master”) it comprises in essence the following core practices:

1. Organize work in short cycles:
2. The management doesn’t interrupt the team during a work cycle.
3. The team reports to the client, not the manager:
4. The team estimates how much time work will take:
5. The team decides how much work it can do in an iteration:
6. The team decides how to do the work in the iteration:
7. The  team measures its own performance:
8. Define work goals before each cycle starts:
9. Define work goals through user stories:
10. Systematically remove impediments:

None of these practices is by itself new. What is new is doing all the practices together in a disciplined way of getting all work done.

When the practices are generalized in this way, beyond software development, they can be collectively described as dynamic linking, to distinguish them from the traditional practices of hierarchical bureaucracy, where individuals reports to bosses to produce outputs.

Teams using the practices that Sutherland and his colleagues had pioneered have been unexpectedly productive. These were not just improvements where the teams were just slightly better than the norm. The best teams routinely obtain productivity increases of 200 to 400 percent, changes that are potentially industry-disruptive improvements.

Some mixed implementation results of Scrum

Nevertheless, despite the enormous potential that individual teams and departments have shown with Scrum, the overall picture ofimplementation has been quite mixed. More than 70% of Scrum implementations have failed to achieve their goals.

Most of these implementations with mixed results, which Sutherland derisively calls “Scrum-butt”, are examples of a failure to implement the full array of Scrum practices. When only some of the practices are implemented, such doing the work in short cycles but interrupting the team during the cycle, the potential gains in productivity don’t occur.

In part these problems of implementation have flowed from the way Scrum is sometimes viewed and introduced.

For instance, according to the Wikipedia, “Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.”

When you try to embed Scrum as a project management framework within a larger setting of a traditional management of hierarchical bureaucracy, there are inevitable tensions. Usually the prevailing culture of hierarchical bureaucracy is triumphant.

This experience sometimes leads people to believe that Scrum is just another management fad that didn’t work.

What the experience really shows is the opposite: that hierarchical bureaucracy is a work culture that no longer fits the marketplace of 2011. Scrum works. It’s the traditional management culture that doesn’t work.

The potential of Scrum as a different way of managing

The real question is: what can you accomplish if you execute Scrum well? The answer is now apparent with the results shown by Salesforce.com, which has been growing by 41% over a sustained period, and whose CEO, Marc Benioff, has been identified by Forbes as the most valuable CEO on the planet.

A turning point for Salesforce.com came in 2006, when the leadership realized that as the firm had grown, innovation in the firm had started to slow down. Instead of doing what most firms do, i.e. trying harder with more-of-the same kind of management, Salesforce.com adopted adifferent kind of management: Scrum.

That was the point of my article Six Common Mistakes That Salesforce.com Didn’t Make.

Unlike many firms that have tried to implement Scrum, the leadership at Salesforce.com saw that Scrum involved not just the adoption of a new business process, or a framework for managing software development, but rather as a fundamental transformation of the way work was managed in the company. They realized that they were introducing a new  way of thinking, speaking and acting in the workplace for both managers and workers. They committed to it boldly and the results have been extraordinary.

Application of Scrum beyond software

The success of software development at firms like Salesforce.com [CRM], along similar customer-driven iterative methods in auto manufacture at firms like Toyota, has led to the spread of this different way of managing to related fields.

• The Quality Software Engineering group at IBM [IBM] is responsible for software development processes and practices across the company. As part of the effort to promulgate Scrum in developing software, an iterative process of working was adopted for doing change management.
• At the Chicago software firm Total Attorneys, iterative work patterns were so successful that they spread to the staff of call centers: small cross-functional teams work in cycles of three weeks.
• At the Danish software firm, Systematic, iterative methods have been spreading from software development to other parts of the firm.
• At the Swedish software firm Trifork, iterative methods have spread from software development to conference management.
• And OpenView Venture Partners, a Boston-based venture capital firm, has expanded client-driven iterations into consulting and finance.

Once a firm sees the dramatic benefits of small client-driven iterations in one area, it becomes natural to ask: Why not do all work in this fashion?

What to call these radically different management practices? In manufacturing, they are known as Lean. In software development they are known as Scrum and Agile. When they are applied to management in general, none of those terms is really applicable, as they carry the baggage of their origins in software and manufacturing.  The Agile Manifesto for instance dwells on the goal of work as “working software”, which is fine for software development, but not relevant to other sectors.

Scrum, Agile and Lean are in effect subsets of a radical shift in management more generally, or what I have called radical management.

________________________

Steve Denning’s most recent book is: The Leader’s Guide to Radical Management: Reinventing the Workplace For the 21st Century(Jossey-Bass, 2010).

[1] The early history of iterative approaches in software development is described in detail by Craig Larman and Victor Basili in “Iterative and Incremental Development: A Brief History.” Computer, 2003, 36(6), 47–56. Iterative approaches to work build on the 1930s work of Walter Shewhart, a quality expert at Bell Labs who proposed a series of short plan-do-study-act (PDSA) cycles for quality improvement: Shewhart, W. Statistical Method from the Viewpoint of Quality Control. New York: Dover, 1986. (Originally published 1939.)

[2] For the twelve principles behind the manifesto:http://agilemanifesto.org/principles.html.

Source: http://blogs.forbes.com/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/

Related posts:

1. Sprint: De 12 stappen van de Creatiespiraal in Scrum
2. Behendige teams maken productontwikkeling beheersbaar

De appelbomen in de kwekerij hier vlakbij waarvan hun vruchten gebruikt gaan worden in Echte Limburgse Kruutje (appelstroop) beginnen weer bloesems te krijgen. Maar voordat dit product bij u op tafel staat zullen vele stappen genomen moeten worden en moeilijkheden overwonnen. Het moeilijkste werk wordt door de boom gedaan. Deze zal de vruchten moeten voortbrengen die gebruikt gaan worden.

Uiteindelijk heeft de boom geen keus, het zit in zijn lot ingebakken om appels te maken. Ook in het realiseren van onze wensen doorlopen wij mensen dezelfde stappen als de boom doet voor zijn voortbrengende werk. Scrum is een cyclisch framework dat de Creatiespiraal vanuit zichzelf lijkt te volgen, wat gemaakt lijkt te zijn met de Creatiespiraal in gedachten.

In de lente ontwaakt de boom, maakt zich klaar voor de zomer. De bloesems dragen een belofte in zich, een verbeelding van warme dagen vol zon. Weldra zullen ze appels gaan dragen, zullen ze de kleine vruchten met al hun kracht omzetten tot vruchten. Totdat het tijd is om de appels te laten gaan en uiteindelijk de bladeren te laten vallen in de herfst. Gedurende de winter trekt een boom in zichzelf terug, rust hij uit om in een nieuw jaar weer een nieuwe voortbrengende cyclus te doorgaan.

Dit beeld van vruchtbomen is het beeld van Marinus Koope, uitgedrukt in ‘De Creatiespiraal‘. Het omschrijft hoe dromen en verlangens van mensen tot uiting komen via wens naar werkelijkheid. Hoe ideeën ontstaan in de winter, hoe ze langzaam tevoorschijn komen in de lente, tot wasdom in de zomer en hoe uiteindelijk de herfst het tijd wordt om te genieten van de resultaten.

Deze cyclus herhaalt zich, continu. Elke cyclus bouwt voort op de volgende. Goede, energieke cycli dragen beloften in zich voor de toekomst, slechte, donkere, cycli het verlangen om het af te sluiten en opnieuw te beginnen.

Elke sprint doorloopt de twaalf stappen van de Creatiespiraal. Elke stap verbeeldt een van de activiteiten en de gebeurtenissen die een team ervaart tijdens een sprint, gedurende het project, de uitvoering.

Lente, zomer, herfst en winter zijn terug te vinden in een sprint. Zoals het jaar verdeelt is in twaalf maanden, zo is de Creatiespiraal verdeelt in twaalf stappen. Daar waar de maanden gedreven door de wetten van de natuur, ongeveer even lang duren duren de stappen in Scrum natuurlijk niet even lang. Sommige duren slechts uren, anderen dagen, maar het zijn dezelfde stappen.

Laten we de stappen volgen en ontdekken hoe we ze terug vinden in een sprint.

1. wensen

Het begint bij wensen, bij verlangen, bij willen. Scrum heeft al een prachtige lijst daarvoor, de backlog lijst. De backlog list is niets anders dan een lijst van wensen, van dromen. De backlog list is dus geen lijst van eisen, geen requirements document, maar een levende lijst van verlangens van wat het product zou moeten kunnen. De wensen zijn actueel en aangepast aan waar we nu staan. De wensen rijpen op deze lijst. Er hoeft nog geen rekening gehouden te worden hoe ze gerealiseerd moeten worden, dat komt later wel!

2. verbeelden

De sprint begint, met de sprint planning. De product owner legt uit aan het team welke wensen hij heeft en wat het zou betekenen. Hier ontstaat het sprint doel, de visie, het eindbeeld. De rest van de sprintstaat tot doel dit eindbeeld te gaan halen. Bij latere stappen gedurende sprint vallen we terug op de hier geschetste verbeelding om weer te bedenken 
waarom we eigenlijk doen wat we doen.

3. geloven

Het team snapt wat de product owner wilt, vult de product owner aan, droomt met hem mee. De product owner krijgt vertrouwen in dat wat hij wil kan en begrepen wordt. Het verbeelden wordt geloven, door hem en het team.

4. uiten

Iedereen denkt het te kunnen, de selectie uit de backlog list wordt vastgelegd. Dit gaan we doen, dit gaan we maken! De product owner verlaat de sessie en begint al te vertellen wat er deze keer aan zit te komen. Wellicht is niet iedereen gelijk enhousiast, wellicht hadden anderen liever gehad dat het iets anders was geworden, maar dit is het, dit gaat het worden.

5. onderzoeken

Het team gaat onderzoeken, gaat ontwerpen, gaat bedekenen. Hoe moeten we dit maken, welke dingen moeten we doen, wat gaan we veranderen. De product owner heeft zijn droom kenbaar gemaakt, maar staat natuurlijk het team bij om te helpen verder te onderzoeken en aan te scherpen, te veranderen opdat de verbeelding haalbaar is.

6. plannen

Allles heeft tot nu toe plaats gevonden in de fantasie. Het zijn slechts droombeelden, vergezichten, schetsen op een whiteboard. Het wordt tijd om te kijken hoe deze droom om te zetten naar werkelijkheid. Taken worden gemaakt, ingeschat en sommigen onder ons verdelen zelfs al wie wat zou gaan doen. En, ondanks de weerstand die ‘wij’ massaal lijken hebben gekregen tegen plannen, helpt het wel om daadwerkelijk te zorgen dat het gaat gebeuren.

7. beslissen

De plannen zijn gemaakt, de uren zijn geteld. Kan het wensbeeld inderdaad gemaakt worden, durft het team het aan? Zo ja dan geeft het team zijn commitment af aan de product owner. “Ja, dit kan, we kunnen het en we gaan ons er hard voor maken om het inderdaad te doen”. Door de vorige stappen is het team naar dit moment toegegroeid, het is geen moeilijke stap meer. Sla je de vorige stappen over dan merk je hier de twijfel, de angst, ‘kunnen we het wel?’

8. handelen

Nu wordt het tijd om te gaan doen wat wat we in de vorige stappen gezaaid hebben. Het product wordt verder ontwikkeld, het creatieve proces manifesteert zich, iedereen zet zijn talenten in om het doel te gaan halen.

9. volharden

Er komt een moment dat het tegen valt. Zelfs met alle voorgaande stappen hoeft het niet te gaan zoals gedacht. Het werkt niet zoals bedacht, het duurt langer, het is moeilijker en de deadline lijkt altijd weer sneller te komen dan gewenst. Het ‘geloven’ van stap 3 lijkt naïef, onzinnig. De voorgaande voorbereidende stappen lijken onzinnig, verspillend en verkwistend. Door terug te grijpen op de verbeelding, op het doel, kan er weer grip gekregen worden, kan er weer een nieuw pad ontdekt worden en is stap 8 weer in zicht.

10. ontvangen

Genieten van het behaalde resultaat is een belangrijke inspirator voor toekomstig werk. De sprint review is het moment om aan iedereen te laten zien wat het werken opgeleverd heeft, om nieuwe ideeën op te doen en te genieten van het succes.

11. waarderen

Gedurende de sprint is er nieuw gebied ontdekt, zijn teamleden gegroeid, maar er zijn ook dingen onbesproken gebleven, er zijn dingen blijven liggen. Het is tijd geworden om te te evalueren wat er gedaan is. Is er gerealiseerd wat er gedroomd is? Kan het de volgende 
keer anders, beter. De retrospective biedt de mogelijkheid om de volgende keer beter aan te sluiten bij de verbeelding, of de verbeelding beter te laten aansluiten aan de aanwezige capaciteiten.

12. ontspannen

Tijd om tot rust te komen, om even te ontspannen en te genieten. De tijd tussen de retrospective en de volgende sprint planning waar de volgende cyclus van de spiraal weer opnieuw begint. De tijd om dingetjes uit te zoeken, om even te proberen wat er nog is blijven hangen in je hoofd als experiment. Nieuwe verlangens, nieuwe ideeën ontstaan in dit gebied.

Bron:
http://www.scrummaster.nl/2011/04/03/sprint-de-12-stappen-van-de-creatiespiraal-in-scrum/

Related posts:

1. Scrum Is A Major Management Discovery
2. Behendige teams maken productontwikkeling beheersbaar

80% van de ERP implementatieconsultancy verdwijnt!

Related posts:

1. PPP: Going to the Cloud
2. 80% van de ERP implementatie consultancy verdwijnt!
3. De CIO is dood, leve de Master Operational Strategist

Going to the cloud

Related posts:

1. PPP: 80 % van ERP implementatieconsultancy verdwijnt!
2. 80% van de ERP implementatie consultancy verdwijnt!
3. De CIO is dood, leve de Master Operational Strategist

2010 was het jaar waarin de term ‘cloud computing’ vereenvoudigd werd tot ‘cloud’. Ook werd duidelijk dat het bij cloud, SaaS en XaaS (Paas, DaaS, IaaS) eigenlijk allemaal om het zelfde idee draait – toegang tot een set aan computerdiensten online die je naar wens kunt uitbreiden of terugbrengen.

Toch blijven er een hoop onduidelijkheden ontstaan. Maar de diensten van grote leveranciers als Microsoft, Amazon, Oracle, Citrix en VMware geven wel aan wat binnen IT onder cloud verstaan wordt. Wat hebben we verder afgelopen jaar over cloud geleerd wat we we eerder niet wisten of waar misschien nog onduidelijkheid over bestond?

1. Er is weinig verschil tussen externe en interne clouds

Vorig jaar ontstonden veel vragen over het bouwen van clouds. Moet je ze binnen je eigen firewall houden of kun je cloud-diensten ook zonder problemen buiten de ondernemingsgrenzen huren?

Omdat het dezelfde data en applicaties blijven – of ze nu op servers staan binnen de firewall, ergens in de cloud of alleen in de cloud tijdens piekbelasting – blijft het risico voor de onderneming ook hetzelfde.

Om deze reden kiezen meer bedrijven voor het bouwen van hybride clouds dan voor een volledig interne of externe oplossing, zegt virtualisatiegoeroe Chris Wolf. Niet private of publieke cloud, maar hybride cloud wordt de norm.

“Met interne clouds heb je de voordelen van het delen van resources en efficiency, maar krijg je niet het voornaamste voordeel van elasticiteit”, aldus Wolf.

2. Waar zijn clouds van gemaakt? Van kleine clouds.

In 2010 probeerden veel cloud-leveranciers de virtualisatiehype te temperen om VMware’s oplossing voor ‘end-to-end cloud computing’ te dwarsbomen – een visie waarin virtuele infrastructuren cloud-gebaseerd delen van resources en management mogelijk maken en deze kunnen uitbreiden naar buiten de firewall.

‘Traditionele’ cloud-leveranciers – voor zover je daarover kunt spreken natuurlijk – kiezen voor een andere benadering. Zij bieden applicaties, storage, compute power en andere diensten via een internetverbinding, zonder daarvoor een virtuele infrastructuur binnen de grenzen van de onderneming te vragen.

Beide maken gebruik van virtualisatie. Daar zijn beide kampen het over eens. Beide oplossingen worden bijna altijd gebouwd binnen datacenters, hosted infrastructuren, virtuele serverparken of drijven zelfs op complete cloud-diensten van andere leveranciers.

3. Clouds maken IT-beheer niet overbodig

Cloud computing maakt IT-diensten in zoverre abstract dat de gebruikers ervan niet weten op welke hard- en software ze draaien en wie de servers beheert waarop hun applicaties staan.

Dit betekent niet dat je niet hoeft te weten hoe het werkt, zegt analist Bob Laliberte. Als je zelf een goede cloud wilt hebben, moet je nog steeds zorgen voor het beheer van server, storage en netwerken om de applicaties die binnen je cloud draaien te optimaliseren. Zonder een foutbestendige infrastructuur werkt cloud computing niet optimaal en daar zitten gebruikers natuurlijk niet op te wachten.

4. Kleine onderdelen maken groot verschil

Virtualisatie zorgt ervoor dat je verschillende applicaties en besturingssystemen op dezelfde hardware kunt draaien en dat deze software ook ‘denkt’ dat ze hun eigen dedicated hardware tot hun beschikking hebben. Het probleem hiervan is volgens IDC-analist Gary Chen dat de software ook denkt dat ze hun eigen netwerkinterface en input/output bus tot hun beschikking hebben.

Op een server met veel besturingssystemen, is de bottleneck niet langer de maximale snelheid waarmee de data tussen een server en externe opslag verplaatst kan worden, maar draait het om het aantal bits dat door tegelijkertijd door een databus verplaatst kan worden.

Dit is de reden achter de toenemende populariteit van Virtual I/O en leidt tot iets wat Forrester-analist John Rymer ‘gedistribueerde virtualisatie’ noemt. Hierin worden I/O, geheugen en andere componenten abstract gemaakt voor henzelf, maar ook voor besturingssystemen. Specificaties van virtuele servers staan hierdoor niet langer vast, maar veranderen naar mate wat de applicatie op dat moment vraagt.

5. Het jaar van de virtuele desktop moet nog komen

2010 leek voorbestemd om het jaar van de virtuele desktop te worden. Microsoft, VMware en Citrix vochten alledrie om klanten, maar konden niet voldoen aan eisen van de trend die eerder door analisten werd voorspelt.

In plaats de gehele firma te standaardiseren op virtuele desktops, kosten de meeste bedrijven alleen voor virtuele oplossingen op plekken waar dat het meeste zin heeft.

In 2010 groeide de vraag naar DaaS wel, maar het was niet de tsunami die IDC voorspelde, zegt analist Ian Song.

Twee redenen voor het uitblijven van grootschalige DaaS-implementaties zijn de complexiteit ervan en de lage ROI van desktopvirtualisatie vergeleken met servervirtualisatie.

Ook hadden bedrijven meer interesse voor het virtualiseren van desktops op tablets, smartphones en andere non-pc apparaten. Dit zal voor 2011 ook de grootste trend zijn, verwacht Song. “We gaan daarover nog veel horen.”

Bron: http://computerworld.nl/article/12524/5-wetenswaardigheden-over-cloud-computing/2.html

Related posts:

1. Leveranciers voeden de angst voor cloud
2. Cloud computing helpt Europese economie er weer bovenop
3. Kroes wil strengere regels cloud computing

Voorspelde je in 2009 dat Ubuntu de jarenlange hegemonie van Red Hat als voornaamste Linux-distributie zou doorbreken, dan zou je recht in je gezicht zijn uitgelachen. Toch is het Ubuntu gelukt om iedereen te verbazen. Dit is voor een groot deel te danken aan de ontwikkelaars en de toename in gebruik van cloud-diensten.

Net als anderen reageerde ook ik verbaasd op een onderzoek van Eclipse waarin naar voren kwam dat het gebruik van Ubuntu sterk is gegroeid, met name op de desktops van ontwikkelaars en productieservers.

Respondenten gaven drie keer vaker aan Ubuntu te gebruiken dan dat zij voor concurrenten RHEL (Red Hat Enterprise Linux) of Fedora kozen. Hoewel dit verrassend klinkt, kan deze uitkomst worden verklaard door het feit dat Ubuntu gratis is en wordt gepositioneerd als gebruiksvriendelijk desktop-alternatief voor Windows. Daarnaast is RHEL bedoeld als betaald product voor met name servers.

Toch dekt deze uitleg niet de enorme toename in het gebruik van Ubuntu op servers. Een onderzoek van Eclipse (uit 2009) wijst uit dat Ubuntu (12 procent) Red Hat (13,1 procent) op de hielen zit wat betreft gebruik op productieservers.

Ontwikkelaars lijken overtuigd

In de meest recente studie van Eclipse is gebruik op desktops onder ontwikkelaars gestegen van 14,5 procent in 2009, naar 18,3 procent in 2010. Daarnaast verslaat Ubuntu met 12,6 procent nipt het gebruik van Red Hat, dat daalde naar 12,5 procent.

In een ander onderzoek analyseerde RedMonk-analist Stephen O’Grady de data van Hacker News, bestaande uit 1,7 miljoen vermeldingen. Volgens O’Grady is deze dataset interessant omdat deze data niet alleen representatief is voor ontwikkelaars wereldwijd, maar ook omdat het om een gemeenschap van technische professionals gaat die altijd op de trend vooruit lopen.

In deze vermeldingen wordt Ubuntu volgens O’Grady 10.000 keer genoemd. Bij elkaar opgeteld kennen Red Hat en Fedora slechts 2500 vermeldingen.

Al jaren geldt dat ontwikkelaars ambassadeurs zijn van de technologie die zij gebruiken. Ze worden niet voor niets dikwijls aangemerkt als indicator voor technologie die ondernemingen in de toekomst zullen gaan gebruiken.

Cloud computing

Een ander cijfer dat in het voordeel van Ubuntu werkt is cloud computing. Doordat Canonical al in een vroeg stadium partnerships met open-source leveranciers als Eucalyptus gesloten heeft, is Ubuntu de facto Linux-distributie bij cloud-implementaties geworden.

Cijfers van Amazon, over het gebruik van besturingssystemen binnen de EC2-cloud, bevestigen dat Ubuntu voorop loopt. Niet alleen Red Hat en Fedora delven het onderspit, ook CentOS en Windows kunnen niet op tegen de populariteit van het OS van Canonical.

Bron: http://computerworld.nl/article/12509/hoe-houdbaar-is-het-succes-van-ubuntu.html

Related posts:

1. Leveranciers voeden de angst voor cloud
2. Cloud computing helpt Europese economie er weer bovenop
3. Kroes wil strengere regels cloud computing

80 % van ERP implementatie consultancy verdwijnt!
(dit is een van de redenen, voor ERP in de cloud te kiezen)

Vaak wordt er gezegd dat de Cloud alleen geschikt is voor generieke applicaties als E-mail en collaboratie (Webex). Niets is minder waar. ERP-applicaties zijn uitermate geschikt om uit de Cloud te halen. De implementatierisico’s zijn veel kleiner, daar gemiddeld de implementatie consultancykosten met gemiddeld 80 % omlaag gaan. De doorlooptijd tot 1/5 wordt gereduceerd. De flexibiliteit wordt vergroot en de leveranciers innoveren continu. Foute invoer kan worden gereduceerd, door het vastleggen van data aan de bron.

De verlaging van de vereiste consultancy en het niet beschikbaar hebben van een SaaS-versie zijn vaak de redenen dat bestaande ERP-partijen, huiverig tegenover de Cloud staan  en vaak de nadelen benadrukken zonder op de voordelen in te gaan. Het is echter evident dat de opmars van de Cloud niet meer te stoppen is. We kunnen dus beter stilstaan bij het verbeteren van de minder positieve aspecten van de Cloud dan de ontwikkelingen pogen tegen te houden. Een snelle implementatie van ERP-in de Cloud kan resulteren tot het werkelijk waarmaken van de eeuwige IT-belofte; verhoging van de flexibiliteit, de productiviteit en het werkelijk verkrijgen van competitief voordeel.

Related posts:

1. Waar moet je zijn voor Nederlandse cloud?
2. Cloud computing helpt Europese economie er weer bovenop
3. Kroes wil strengere regels cloud computing