EURIM 2009 Annual General Meeting at the House of Lords

Yesterday I was at the Palace of Westminster, or rather the House of Lords, for the 2009 Annual General Meeting (AGM) of EURIM, the European Information Society Group, which “brings together politicians, officials and industry to help improve the quality of policy formation, consultation, scrutiny, implementation and monitoring in support of the creation of a globally competitive, socially inclusive and democratically accountable information society”.

I brought up three points with the EURIM Board, firstly the disparity of R&D; spending by Industry sector (and the fact that in the UK 75% of all business R&D; is done in the manufacturing industry alone, an industry provides just 13% of the GDP of the UK), secondly I asked what EURIM’s position was in response to EU Information Society Commissioner Viviane Reding’s call for the US to hand over control of ICANN so it can be overseen by an independent international tribunal, and thirdly in regards to the UK stimulation package and it’s support, or rather lack of, the UK’s ‘Digital Infrastructure’ (more on this topic in a separate article as I’d planned for it to be one of my pieces on the economic recovery of the UK).

All three were well received, and I especially enjoyed a discussion that arose around the ‘Professionalism in IT’ agenda, and it’s likely resurgence as a topic of interest across the major stakeholders in the UK after a relatively quiet period of activity.

After the meeting I continued the conversation about IT Professionalism with Michael Gough, Head of Government Affairs at EDS and ex-Chief Executive of the National Computing Centre (NCC) where he spent eight highly productive years (Steve Markwell has taken over the reins of CEO). Of course during his tenure the NCC was one quarter of the “Prof IT Alliance“, an alliance of interested parties looking at supporting the IT Professionalism agenda (along with Intellect, the BCS, and the e-Skills Council UK, the sector skills license holder for IT and Telecoms skills).

I also spoke with industry friends and peers (including those from IBM, Microsoft, Atkins, and others), as well The Lord Renwick, EURIM President, and Dr David Wright, EURIM Deputy Secretary General.

Almost everyone asked about the Oracle acquisition of Sun, and I had to say that due to SEC rulings we wouldn’t be seeing any integration until the deal was sanctioned by the US Government. This sort of thing is the norm in large scale mergers and acquisitions born out of the US and everyone who asked were understanding of this.

The next EURIM event I’m due at is with the Conservative Technology Forum entitled “The Future of the NHS IT Program” event, where we are due to partake in a forum hosted Guy Hains, EMEA CSC Alliance, Pearse Butler, Dir UK Healthcare CSC, Dr Glyn Hayes, President of the Primary Health Care Specialist Group of the BCS, and Stephen O’Brien MP, the Shadow Minister for Health. More on the CSC Alliance here: http://www.csc.com/cscalliance

I took a few photographs yesterday whilst around and about Westminster and from within the Main Hall (the only place guests are allowed to take photos whilst in the Houses of Parliament), and thought that I’d share them with you too.

Links for this article:

Industry contributions to the UK economy and investment in R&D; by industry

My biggest concern about the UK economy is in two very related areas, firstly the imbalance of industry contributions to UK GDP, and secondly the imbalance of investment in innovation in those industries.

When I speak about the imbalance of industry contributions to UK GDP I’m actually talking about which industry sectors are contributing to the UK GDP.

Over the last few years the GDP of the UK has been around £1.2 to £1.3 Trillion (where 1 Trillion equates to 1,000 Billion); this is traditionally circa $2.35 Trillion for those of you who prefer dollar notation.

If we break down GDP contributions as percentages the most obvious point to be made is that Services makes up the majority at over 75% of the GDP contribution to the UK economy (and up until the credit crunch circa 40% of GDP contribution were from Financial Services alone). Manufacturing as an industry sector currently supports just 13% of the UK GDP (as a comparison the USA is circa 19% and Germany is circa 23%) and the actual amount is around £150 Billion. The rest is made up of Agriculture (hovering at 1% and just below) and ‘other’ Industry.

It occurs to me that frankly this isn’t a particularly balanced model; especially when it comes to global recessions such as the one we find our selves in now which, because of our dependence on single industry sectors, affects us so adversely. And nor is it particularly self sustaining.

I’m not alone in thinking this, Warren Buffet warned long ago that the UK’s over reliance on it’s service sector exposed the economy to a higher risk of recession, and George Soros has recently been quoted in the UK press that his concern about the recovery of the UK economy is it’s dependence on the financial services industry.

Sir John Rose, Chief Executive of Rolls-Royce, and one of the UK’s most inspiring business leaders, is vocal about the UK’s need to balance it’s industries contribution to it’s GDP, he has this to say on the subject:

“This country needs a broad portfolio of assets.” adding “There is an over dependence on financial services. If you are a one-trick pony, you have to hope that people continue to like your trick. If they stop liking it, you become pet food.” and “…the credit crisis gives a unique opportunity to start answering questions about how this country should be earning its living in the 21st century.”

You may agree or disagree, or perhaps you’d be interested in what the spread and distribution of UK GDP contributions from differing Industries should or could be, something I believe needs a certain amount of consideration and planning, something you’d imagine would be in the UK’s “Industrial Strategy”, which according to key experts, sadly, does not exist as a coherent and authoritative source. What is key to me is that we collectively recognise the imbalance and look at what it means and what our options might be, including attempting to encourage or stimulate other areas of the economy where appropriate.

All of this brings me to the second, related area, and probably the one that I find more worrying as I increasingly think about the future of the UK economy; that is the imbalance of investment in innovation across the industry sectors in the UK.

Circa 75% of all UK business Research and Development is in Manufacturing alone. Let me restate that another way to bring the point clearer. 75% of all investment in R&D;, innovation and future offerings is done in a single industry sector which contributes just 13% of the economy. Genuinely this worries me a great deal, because therefore, 87% of the economy (which is not manufacturing, and is predominantly services) is contributing just 25% of the entire amount being invested in the future. Yes that’s right, nearly 90% of the UK economy will be dependant on a quarter of the total investment in innovation. This does not look like a good investment on the future state of the economy to me. Nor does it give me a warm and fuzzy feeling when it comes to the future of non-manufacturing businesses either, and lets be clear here, the future of the service industry.

These two points could be playing off against each other of course, in that industry contributions to the economy need to be rebalanced, possibly with a larger (or even, much larger) contribution from manufacturing. And that subsequently the imbalance in terms of investment in R&D; across industry could possibly be less of a worry than I currently imagine.

However I really don’t expect for manufacturing to make up 75% of the GDP contribution anywhere in the future, and I’m still very concerned about the lack of investment in R&D; in the Services industry of the UK. I’d really like better awareness of the issue as a whole, and perhaps go so far to look for more focused stimulation from Government to encourage investment in R&D; in the Services sector.

Recently the CBI’s Innovation, Science and Technology (IST) committee have been working on a number of upcoming white papers, and I have been vocal in having the above issues brought to light in those. Thankfully I got a great of support from the other members of the IST, especially those who are working in the Services sector. I’ll let you know when the white papers I’ve mentioned are available from the CBI web site.

So in a nutshell what am I saying? Firstly let’s investigate and hopefully work towards a more balanced, recession proof economy, with a bigger contribution from high value and “just in time” manufacturing, if it is viable, and secondly let’s see more investment in R&D;, innovation and the future from the Services industry. To achieve any of this we’ll need significant support from Government departments like DBERR and DIUS, followed by the Treasury, to act as sponsors, and finally some Government assistance, whether that be legislation, stimulation, or something softer (the current favourite doing the rounds across the political parties is that of the ‘nudge’ as exemplified by Richard Thaler and Cass R. Sunstein, in their book “Nudge: Improving Decisions About Health, Wealth, and Happiness”).

Please Note: All data in this piece comes from these sources, in this order, the Economist ‘Pocket World in Figures (2009 Edition)’, the Economist magazine, the CBI, the IoD, and the BBC. Furthermore, despite manufacturing making up 13% of the UK economy, the UK is still the sixth largest manufacturer in the World (although there are some very big gaps between the economic output of the top five and the UK, and so I may very well touch on the state of the UK manufacturing industry in the future).

Links for this article:

DBERR’s views on the future growth of the UK economy ‘New Industry, New Jobs’

Are you concerned about the state of the UK economy in the future, because I know I am, so I’ll be exploring some of the issues being faced by the UK economy, especially when it comes to science, technology, engineering and industry contributions to the UK’s GDP in my next few articles. …..

Links for this article:

]]>

Cloud Relationship Model (en Francais)

Récemment, Eric Bezille compris le modèle de mon “Cloud Relationship Model” article dans son blog “Sur les pas du premier Camp Cloud à Paris …».Recently Eric Bezille included the model from my ” Cloud Relationship Model ” article in his blog post ” Sur les pas du premier Cloud Camp à Paris… “. And I thought I’d translate the article into French for Philippe’s readers. Et j’ai pensé traduire l’article en français pour les lecteurs de Philippe. I’ve had to use electronic translation (Google, actually) as I’m afraid my written and spoken French isn’t quite good enough to be able to do it manually in a reasonable amount of time. J’ai eu à utiliser la traduction électronique (Google, en fait) que je crains que mon français écrit et parlé est pas tout à fait assez bon pour être en mesure de le faire manuellement dans un délai raisonnable. I haven’t had time to translate the model itself, but you are more than welcome to recreate, reuse and distribute it, although I’d hope you would attribute the original version to me at this site. Je n’ai pas eu le temps de traduire le modèle lui-même, mais vous êtes plus que bienvenu pour recréer, de réutilisation et de la distribuer, mais je l’espère vous attribuer la version originale pour moi à ce site. Please let me know if there are any outstanding translation issues and I’ll amend them when I can. S’il vous plaît laissez-moi savoir s’il ya des questions de traduction en suspens et je vais les modifier quand je peux.

This article was originally a guest post I did recently for Stewart Townsend over at Sun Startup Essentials describing the cloud relationship model I had developed as an artefact when discussing cloud computing. Cet article a été invité récemment post, je n’ai plus de Stewart Townsend à Sun Startup Essentials décrivant le modèle de relation de nuages j’avais développé comme un artefact de calcul lors de l’examen de nuages.

I wanted a simply model which I could share with people and use as a discussion point, whilst still capturing the major areas of cloud computing which I considered most pertinent.  I developed this model about six months ago and have since found it useful when talking with people about cloud computing. Je voulais tout simplement un modèle qui je pourrais partager avec les gens et utiliser comme point de discussion, tout en capturant les grands domaines de l’informatique de nuages que j’ai jugé plus pertinent. J’ai développé ce modèle il ya environ six mois et ont depuis trouvé utile lorsque l’on parle avec les gens sur les nuages de calcul.

Here’s the model and I’ll go though it’s major elements below. Voici le modèle et je vais bien que les principaux éléments ci-dessous.

¨C11C¨C12C¨C13C¨C14C¨C15C¨C16C

¨C17C¨C18C

Major Cloud Communities Major Cloud Communautés

¨C19C¨C20C¨C21C

In the cloud there are three major participants: Dans les nuages, il ya trois principaux participants: ¨C22C

  1. the Cloud Providers; building out Clouds, for instance Google, Amazon, etc. Effectively technology providers. les fournisseurs de Cloud, la construction des nuages, par exemple Google, Amazon, etc efficacement les fournisseurs de technologie. ¨C24C¨C25C
  2. the Cloud Adopters / Developers; those developing services over the Cloud and some becoming the first generation of Cloud ISVs.  I have included Cloud “Service” developers and Cloud ISV developers together. les adoptants Cloud / développeurs, ceux de développer des services sur le Cloud et de certains de devenir la première génération de Cloud ISVs. J’ai inclus Cloud “Service” développeurs et éditeurs de logiciels de développeurs Cloud ensemble. This group are effectively service enablers. Ce groupe de services sont effectivement des facilitateurs. ¨C27C¨C28C
  3. Cloud “End” Users; those using Cloud provisioned services, often without knowing that they are cloud provisioned, the most obvious example of which are the multitude of Facebook users who have no idea there favorite FB app. Cloud “fin” des utilisateurs; ceux qui utilisent les services Cloud provisionné, souvent sans savoir qu’ils sont des nuages provisionnés, l’exemple le plus évident dont la multitude d’utilisateurs de Facebook, qui n’ont aucune idée de là favorite FB app. is running on AWS. est en cours d’exécution sur AWS. These are the service consumers. Ce sont les services aux consommateurs. ¨C30C¨C31C

¨C33C

I think it’s important to talk about these communities because I keep hearing lots about the Cloud Providers, and even more about the issues and ‘needs’ of the Cloud adopters / developers, but very little in terms of Cloud “End” Users.  In a computing eco-system such as this where “services” are supported by and transverse technology providers, service enablers and service consumers an end to end understanding of how this affects these reliant communities is required. Je pense qu’il est important de parler de ces communautés parce que je continue à l’audience sur les lots Cloud fournisseurs, et plus encore sur les questions et les «besoins» des adoptants Cloud / développeurs, mais très peu en termes de Cloud “fin” des utilisateurs. Dans un le calcul de l’éco-système de ce genre où les “services” sont pris en charge par les fournisseurs de technologie et transversal, le service des facilitateurs et les consommateurs un service de bout en bout la compréhension de la façon dont cela affecte les communautés dépendantes est nécessaire. Obvious issues such as SLAs for end users and businesses which rely upon high availability and high uptime from there cloud providers come to mind; however other “ilities” and systemic qualities come to mind such as security, and that’s before looking at any detailed breakdown of functional services. Évidente des questions telles que la SLA pour les utilisateurs finaux et les entreprises qui s’appuient sur la haute disponibilité et haute disponibilité à partir de là, les fournisseurs de nuages viennent à l’esprit, mais d’autres “ilities” et systémique qualités me viennent à l’esprit, comme la sécurité, et que l’avant de chercher à tout ventilation détaillée des services fonctionnels. ¨C34C

The point here is that the cloud adopters / developers and interestingly the cloud “watchers” (ie the press, media, bloggers and experts) would be mindful to remember the needs and requirements of genuine end users; for myself it’d certainly be invigorating to hear more on this topic area. Le point important ici est que le nuage adoptants / développeurs et intéressant le nuage “observateurs” (c’est-à-dire la presse, les médias, les blogueurs et experts) sont conscients de se rappeler les besoins et les exigences de véritables utilisateurs finaux, pour moi ça sera certainement vivifiant pour en savoir plus sur ce sujet. ¨C35C¨C36C

Billing / Engagement Models Billing / Fiançailles Modèles

¨C37C¨C38C¨C39C

Simon Wardley , a much more eloquent public speaker than myself, does a wonderful pitch which includes a look at the different “as a Service types” which he boils down to being a load of “*aaS” (very amusing, and informative, try and catch Simon presenting if you can). Simon Wardley, un public beaucoup plus éloquent orateur que moi, fait un merveilleux terrain qui comprend un regard sur les différents types de service »dont il se résume à être une charge de” * AAS “(très amusant et instructif, essayez Simon et les prises de présenter, si vous le pouvez).

I wholeheartedly agree that there is a large amount of befuddlement when it comes to the differing “aaS” types and sub-types, and new ones are springing up relatively frequently, however I also think it’s important to not ignore the differences between them. Je suis entièrement d’accord qu’il ya une grande quantité de befuddlement quand il s’agit de la différence “ AAS” types et sous-types, et de nouveaux voient le jour assez fréquemment, mais je crois aussi qu’il est important de ne pas ignorer les différences entre eux. ¨C40C

For me, and many others, I think first popularised by the ” Partly Cloudy – Blue-Sky Thinking About Cloud Computing ” white paper from the 451 Group, the differing “aaS” variants are identified as billing and engagement models.  That white paper also postulates the five major Cloud Computing provider models, into which the majority of minor “aaS” variants fall.  They are: Pour moi, et bien d’autres, je pense que le premier popularisé par “Nuages épars – Blue-Sky Thinking About Cloud Computing” livre blanc de la 451 groupe, les différents “* AAS” variantes sont identifiées comme étant des modèles de facturation et d’engagement. Ce livre blanc aussi les cinq principaux postulats Cloud Computing fournisseur de modèles, dans lequel la majorité des mineurs “* AAS« variantes automne. Ce sont: ¨C41C

  1. Managed Service Provision (MSP); not only are you hiring your service from the cloud, you’ve someone to run and maintain it too. Fourniture de services gérés (MSP), non seulement vous votre service de recrutement des nuages, vous avez quelqu’un d’exécuter et de maintenir aussi. ¨C43C¨C44C
  2. Software as a Service (SaaS); pretty much ubiquitous as a term and usually typified by Salesforce.com , who are the SaaS poster child. Software as a Service (SaaS), un peu comme un terme omniprésent et souvent caractérisée par Salesforce.com, qui sont les affiches SaaS enfant. ¨C46C¨C47C
  3. Platform as a Service (PaaS); the application platform most commonly associated with Amazon Web Services. Platform as a Service (FQA), la plate-forme d’application les plus couramment associés à Amazon Web Services. ¨C49C¨C50C
  4. Infrastructure as a Service (IaaS); Infrastructure as a Service (IAAS); ¨C52C¨C53C
  5. Hosting 2.0 Hosting 2.0

¨C56C

One of the best breakdowns and visual analysis of this space is the model in Peter Laird’s ” Understanding the Cloud Computing/SaaS/PaaS markets: a Map of the Players in the Industry ” article which is well worth a read. Un des meilleurs pannes et l’analyse visuelle de cet espace est le modèle de Peter Laird de «Comprendre le Cloud Computing / SaaS / Paas marchés: une carte des joueurs de l’industrie” l’article qui est très intéressant à lire. ¨C57C¨C58C¨C59C¨C60C

Major Architectural Layers Major couches architecturales

¨C61C¨C62C¨C63C

Also included in the diagram are the major architectural layers that are included in each of the above billing / engagement models offered by the Cloud providers. Également inclus dans le diagramme sont les principales couches architecturales qui sont inclus dans chacune de ces facturation / l’engagement des modèles offerts par les fournisseurs de Cloud. They are: Ils sont: ¨C64C¨C65C

  1. Operations; and this really is operations supporting functional business processes, rather than supporting the technology itself. Opérations, et cela est vraiment fonctionnel des opérations de soutien des processus d’affaires, plutôt que de soutenir la technologie elle-même. ¨C67C¨C68C
  2. Service layer; made up of application code, bespoke code, high-level ISV offerings. Service couche composée de code, code sur mesure, haut niveau de l’offre des éditeurs de logiciels. ¨C70C¨C71C
  3. Platform layer; made up of standard platform software ie app. Plate-forme couche composé de plate-forme standard des logiciels c’est-à-dire environ. servers, DB servers, web servers, etc., and an example implementation would be a LAMP stack. les serveurs, les DB serveurs, serveurs Web, etc, et un exemple de mise en œuvre serait une LAMP pile. ¨C73C¨C74C
  4. Infrastructure layer; made up of (i) infrastructure software (ievirtualisation and OS software), (ii) the hardware platform and server infrastructure, and (iii) the storage platform. Infrastructure couche composée de (i) des logiciels d’infrastructure (ievirtualisation OS et logiciels), (ii) la plate-forme matérielle et infrastructure de serveur, et (iii) de la plate-forme de stockage. ¨C76C¨C77C
  5. Network layer; made up of routers, firewalls, gateways, and other network technology. La couche réseau, composé de routeurs, firewalls, passerelles, et d’autres technologies de réseau. ¨C79C¨C80C

¨C82C

This rather oversimplifies the architecture, as it’s important to note that each of the cloud billing / engagement models use capabilities from each of the above architectural layers; for instance their can be a lot of service simply in managing a network, however these describe the major architectural components (which support the service being procured), not simply ancillary functions, effectively what are the cloud providers customers principally paying for. Cet excès de l’architecture, plutôt, comme il est important de noter que chacun des nuages de facturation / d’engagement de l’utilisation des modèles de capacités de chacune de ces couches architecturales, par exemple, peut leur être très simplement dans la gestion de service d’un réseau, mais elles décrivent les principales éléments d’architecture (qui soutiennent le service d’approvisionnement), et non pas simplement des fonctions auxiliaires, de manière efficace ce que les nuages sont principalement les fournisseurs de clients pour le paiement. ¨C83C¨C84C

Delta of Effort / Delta of Opportunity Effort de Delta / Delta de chances

¨C85C¨C86C¨C87C

This is much more than the ‘gap’ between the cloud providers and the cloud users, wherein the cloud adopters / developers sit, the gap between the cloud providers and the end cloud users can be called the delta of effort, but also the delta of opportunity. C’est beaucoup plus que le «fossé» entre les nuages et les nuages des utilisateurs, que le nuage adopteurs développeurs s’asseoir, l’écart entre le nuage et les utilisateurs de la fin des nuages peut être appelé le delta de l’effort, mais aussi le delta du occasion. ¨C88C

It is the delta of effort in terms of skills, abilities, experience and technology that the cloud adopter needs to deliver a functional service to their own “End Users”.  This will be potentially a major area of cost to the cloud adopters. Il est le delta de l’effort en termes de compétences, les capacités, l’expérience et de la technologie que le nuage adoptant doit fournir un service fonctionnel à leur propre “End Users”. Ce sera peut être un domaine majeur de coût pour le nuage adoptants. But it’s also the delta of opportunity;in terms of ‘room’ to innovate. Mais c’est aussi le delta de l’occasion, en termes de «chambre» à l’innovation. ¨C89C

The more capability procured from the cloud provider (ie higher up the stack as a whole), the less you have to do (and procure) yourself.  However the less procured from the cloud provider the more opportunity you have engineer a differentiating technology stack yourself.  This itself has it’s disadvantages because the cloud adopters / developers could potentially not realise the true and best value of their cloud providers infrastructure. La capacité d’approvisionnement plus le nuage de fournisseur (c’est-à-dire en haut de la pile dans son ensemble), moins vous avez à faire (et acheter) vous-même. Toutefois, le moins obtenus à partir de la nuée fournisseur le plus vous avez la possibilité de différenciation ingénieur technologie pile-vous . Ce qu’il est lui-même a des inconvénients car les nuages adopteurs développeurs pourraient ne pas réaliser la véritable et la meilleure valeur de leur nuage les fournisseurs d’infrastructures. ¨C90C¨C91C

I suspect that there is an optimum level, around the Platform Layer, which abstracts enough complexity away (ie you don’t have to procure servers, networks, implementation or technology operations staff), but also leaves enough room to innovate and produce software engineered value.  Arguably the only current successful cloud provider, based upon market share, perception, revenue and customer take up, is Amazon Web Services (AWS) who provide a PaaS offering. Je pense qu’il ya un niveau optimal, autour de la plate-forme de couche, qui résumés complexité assez loin (c’est-à-dire vous n’avez pas à acheter des serveurs, des réseaux, la mise en œuvre des opérations ou de technologie), mais laisse aussi assez d’espace pour innover et produire de l’ingénierie du logiciel valeur. doute le seul fournisseur actuel succès des nuages, sur la base de la part de marché, la perception des recettes et des clients de prendre place, est Amazon Web Services (AWS) qui fournissent une offre Paas. ¨C92C¨C93C¨C94C¨C95C

Summary Sommaire

¨C96C¨C97C¨C98C

Hope you enjoyed the article, in summary if developing cloud services or even building out a cloud infrastructure I would recommend that you focus on your users and if your a cloud provider, your users’ users; remembering that only a certain percentage of those users will be customers (I won’t getting into discussing Chris Anderson’s 5% recommended conversion rate for the long tail , however I would recommend understanding what some of those calculations might be). Espérons que vous avez aimé cet article, en résumé, si le développement des services ou encore des nuages à la construction d’infrastructures d’un nuage, je vous recommandons de vous concentrer sur vos utilisateurs, et si votre fournisseur d’un nuage, vos utilisateurs, les utilisateurs; de se souvenir que seul un certain pourcentage de ces utilisateurs être des clients (je ne vais pas entrer dans la discussion Chris Anderson recommandé 5% du taux de conversion pour la longue queue, mais je recommande la compréhension de ce que certains de ces calculs pourraient être). ¨C99C

If you’re looking to develop services over the cloud, think carefully about where you and your teams skills lie, and where would you most want them focusing there efforts; working on installing and tuning operating systems and application platforms or writing business value focused applications and services, before choosing at which level to engage with your cloud provider(s). Si vous cherchez à développer des services sur le nuage, la réflexion sur l’endroit où vous et vos équipes les compétences se trouvent, et où vous le plus envie de les y concentrer les efforts, le travail sur l’installation et le réglage des systèmes d’exploitation et plates-formes d’application ou de rédaction de la valeur axée applications et des services, avant de choisir à quel niveau de dialoguer avec votre fournisseur de nuage (s). ¨C100C¨C101C¨C102C¨C103C

I haven’t mentioned enterprise adoption of cloud based services, and that’s because I’d like to post that in the near future in a different article. Je n’ai pas mentionné l’adoption d’entreprise de services basés sur les nuages, et c’est parce que je voudrais pour écrire que dans un avenir proche dans un autre article. ¨C104C

Hope you enjoyed the article and all the best, Espérons que vous avez aimé l’article et tous les meilleurs, ¨C105C¨C106C

Wayne Horkan ¨C107CWayne Horkan ¨C108C

¨C109C¨C110C¨C111C ¨C114C¨C115C

Links for this article:

]]>

Cloud Relationship-Modell (in Deutsch)

Kürzlich Philipp Strube meiner ursprünglichen genannten “Cloud Betreuungsmodell” Artikel in seinem Blog-Post “Paas, IAAS, Saas: Den Überblick zu behalten ist wie immer ein Problem für sich”.Recently Philipp Strube mentioned my original ” Cloud Relationship Model ” article in his blog post ” Paas, Iaas, Saas: Den Überblick zu behalten ist wie immer ein Problem für sich “. And given all the traffic it’s generated I thought I’d translate the article into German for Philippe’s readers. Und da der gesamte Verkehr ist es, die ich dachte, ich übersetzen den Artikel in Deutsch für Philippe Leser. I’ve had to use electronic translation (Google, actually) as I’m afraid my written and spoken German isn’t quite good enough to be able to do it manually in a reasonable amount of time. Ich habe die Verwendung elektronischer Übersetzung (Google, eigentlich), wie ich fürchte, mein Wort und Schrift Deutsch ist nicht gut genug sein, um es manuell in einer angemessenen Höhe der Zeit. I haven’t had time to translate the model itself, but you are more than welcome to recreate, reuse and distribute it, although I’d hope you would attribute the original version to me at this site. Ich habe nicht genug Zeit hatte, um das Modell selbst, aber Sie sind mehr als willkommen zu neu, Wiederverwendung und zu verteilen, auch wenn ich hoffe, Sie würden Attribut der ursprünglichen Version für mich auf dieser Seite. Please let me know if there are any outstanding translation issues and I’ll amend them when I can. Bitte lassen Sie mich wissen, wenn es alle noch ausstehenden Fragen und Übersetzung ich ändern, wenn ich kann.

This article was originally a guest post I did recently for Stewart Townsend over at Sun Startup Essentials describing the cloud relationship model I had developed as an artefact when discussing cloud computing. Dieser Artikel war ursprünglich ein Gast-post Ich habe vor kurzem für Stewart Townsend über auf Sonntag Startup Essentials beschreiben die Wolke Modell hatte ich als ein Artefakt bei der Erörterung Wolke Computing.

I wanted a simply model which I could share with people and use as a discussion point, whilst still capturing the major areas of cloud computing which I considered most pertinent.  I developed this model about six months ago and have since found it useful when talking with people about cloud computing. Ich wollte ein Modell, das einfach konnte ich mit Menschen und die Verwendung als Diskussion, während die Aufnahme noch die wichtigsten Bereiche der EDV-Wolke, die ich als besonders wichtig. Ich habe dieses Modell an etwa sechs Monaten und haben gefunden, da es für sinnvoll, wenn im Gespräch mit Menschen über Wolke Computing.

Here’s the model and I’ll go though it’s major elements below. Hier ist das Modell, und ich gehe auch wenn es die wichtigsten Elemente aufgeführt.

Major Cloud Communities Major Cloud Gemeinschaften

In the cloud there are three major participants: In den Wolken gibt es im wesentlichen drei Teilnehmer:

  1. the Cloud Providers; building out Clouds, for instance Google, Amazon, etc. Effectively technology providers. die Cloud Provider; Gebäude aus Wolken, zum Beispiel Google, Amazon, etc. effektiv Technologieanbietern.
  2. the Cloud Adopters / Developers; those developing services over the Cloud and some becoming the first generation of Cloud ISVs.  I have included Cloud “Service” developers and Cloud ISV developers together. die Wolke Adopters / Entwickler, die Entwicklung von Diensten über den Wolken und einige werden die erste Generation der Cloud ISVs. Ich habe Cloud “Service”-Entwickler und ISV-Cloud Entwickler zusammen. This group are effectively service enablers. Diese Gruppe tatsächlich Dienstfunktionen.
  3. Cloud “End” Users; those using Cloud provisioned services, often without knowing that they are cloud provisioned, the most obvious example of which are the multitude of Facebook users who have no idea there favorite FB app. Cloud “End”-Nutzer, die mit Cloud bereitgestellten Dienstleistungen, oft ohne zu wissen, dass sie Wolken vorhanden, das offensichtlichste Beispiel für die sich die Vielzahl der Facebook-Benutzer, die keine Ahnung haben, es Lieblings-FB App. is running on AWS. läuft auf AWS. These are the service consumers. Es handelt sich um den Dienst der Verbraucher.

I think it’s important to talk about these communities because I keep hearing lots about the Cloud Providers, and even more about the issues and ‘needs’ of the Cloud adopters / developers, but very little in terms of Cloud “End” Users.  In a computing eco-system such as this where “services” are supported by and transverse technology providers, service enablers and service consumers an end to end understanding of how this affects these reliant communities is required. Ich denke, es ist wichtig, darüber zu sprechen, weil diese Gemeinschaften ich viel über die Anhörung Cloud-Provider, und noch mehr über die Probleme und Bedürfnisse “der Wolke Anwender / Entwickler, aber nur sehr wenig in Bezug auf die Ableitung von” End “-Benutzer. In einer Eco-Computing-System wie diesem, wo “Dienstleistungen” werden von Quer-und Technologie-Anbietern, Service-Enabler und Service der Verbraucher ein Ende zu Ende zu verstehen, wie sich diese auf dieser Reliant Gemeinden erforderlich ist. Obvious issues such as SLAs for end users and businesses which rely upon high availability and high uptime from there cloud providers come to mind; however other “ilities” and systemic qualities come to mind such as security, and that’s before looking at any detailed breakdown of functional services. Offensichtliche Fragen wie SLAs für Endnutzer und Unternehmen, die sich auf hohe Verfügbarkeit und hohe Verfügbarkeit von dort Wolke Anbieter kommen in den Sinn, aber andere “ilities” und systemischen Eigenschaften kommen in den Sinn wie Sicherheit, und das ist, bevor man eine detaillierte Aufschlüsselung der funktionsfähigen Dienste.

The point here is that the cloud adopters / developers and interestingly the cloud “watchers” (ie the press, media, bloggers and experts) would be mindful to remember the needs and requirements of genuine end users; for myself it’d certainly be invigorating to hear more on this topic area. Der Punkt hier ist, dass die Wolke Anwender / Entwickler und interessanterweise der Wolke “Watchers” (dh der Presse, Medien, Blogger und Experten) würden darauf achten, nicht vergessen, den Bedürfnissen und Anforderungen der Endnutzer echten, für mich würde es sicherlich belebend zu hören, mehr zu diesem Thema werden.

Billing / Engagement Models Billing / Engagement Models

Simon Wardley , a much more eloquent public speaker than myself, does a wonderful pitch which includes a look at the different “as a Service types” which he boils down to being a load of “aaS” (very amusing, and informative, try and catch Simon presenting if you can). Simon Wardley, eine sehr viel beredter Redner als ich, hat eine wunderbare Tonhöhe, die einen Blick auf die verschiedenen “als Service-Typen”, die er läuft darauf hinaus, dass eine Last von “ Aas” (sehr witzig und informativ, versuchen Fang und Simon, die, wenn Sie können).

I wholeheartedly agree that there is a large amount of befuddlement when it comes to the differing “aaS” types and sub-types, and new ones are springing up relatively frequently, however I also think it’s important to not ignore the differences between them. Ich voll und ganz zustimmen, dass es eine große Menge von befuddlement, wenn es darum geht, die unterschiedlichen “ Aas” und Sub-Typen und neue Boden relativ häufig, aber ich denke, es ist wichtig, nicht über die Unterschiede zwischen ihnen.

For me, and many others, I think first popularised by the ” Partly Cloudy – Blue-Sky Thinking About Cloud Computing ” white paper from the 451 Group, the differing “aaS” variants are identified as billing and engagement models.  That white paper also postulates the five major Cloud Computing provider models, into which the majority of minor “aaS” variants fall.  They are: Für mich und viele andere, ich glaube, von der ersten popularisierte “teilweise bewölkt – Blue-Sky Thinking About Cloud Computing” weißen Papier aus dem 451-Fraktion, die unterschiedlichen “* Aas” Varianten sind als Rechnungs-und Engagement Modelle. Das Weißbuch postuliert auch die fünf größten Anbieter Cloud Computing-Modelle, in denen die Mehrheit der minderjährigen “* Aas” Varianten fallen. Sie sind:

  1. Managed Service Provision (MSP); not only are you hiring your service from the cloud, you’ve someone to run and maintain it too. Managed Service Providing (MSP), nicht nur die Mieten Sie Ihren Service aus der Wolke, die Sie jemandem zu laufen und sie zu pflegen.
  2. Software as a Service (SaaS); pretty much ubiquitous as a term and usually typified by Salesforce.com , who are the SaaS poster child. Software as a Service (SaaS), so ziemlich allgegenwärtig als Begriff und in der Regel gekennzeichnet durch Salesforce.com, wer sind die SaaS-Poster Kind.
  3. Platform as a Service (PaaS); the application platform most commonly associated with Amazon Web Services. Platform as a Service (Paas); die Anwendung Plattform am häufigsten im Zusammenhang mit Amazon Web Services.
  4. Infrastructure as a Service (IaaS); Infrastructure as a Service (IAAS);
  5. Hosting 2.0 Hosting 2,0

One of the best breakdowns and visual analysis of this space is the model in Peter Laird’s ” Understanding the Cloud Computing/SaaS/PaaS markets: a Map of the Players in the Industry ” article which is well worth a read. Eines der besten Pannen und visuelle Analyse von dieser Stelle ist das Modell in Peter Laird’s “Understanding the Cloud Computing / SaaS / Paas Märkte: eine Karte der Player in der Industrie” Artikel, das lohnt sich lesen.

Major Architectural Layers Major Architectural Ebenen

Also included in the diagram are the major architectural layers that are included in each of the above billing / engagement models offered by the Cloud providers. Auch in der Grafik sind die wichtigsten architektonischen Schichten, die in jedem der oben genannten Billing / Engagement Modelle von der Cloud-Anbieter. They are: Sie sind:

  1. Operations; and this really is operations supporting functional business processes, rather than supporting the technology itself. Operations, und das ist wirklich funktionellen Maßnahmen zur Förderung von Geschäftsprozessen, sondern als Unterstützung der Technologie.
  2. Service layer; made up of application code, bespoke code, high-level ISV offerings. Service-Schicht, aus der Anwendung Code, maßgeschneiderten Code, High-Level-ISV-Angebote.
  3. Platform layer; made up of standard platform software ie app. Plattform Schicht; aus der Standard-Plattform-Software, dh App. servers, DB servers, web servers, etc., and an example implementation would be a LAMP stack. Server, DB-Server, Web-Server, usw., und ein Beispiel dafür wäre eine LAMP-Stack.
  4. Infrastructure layer; made up of (i) infrastructure software (ievirtualisation and OS software), (ii) the hardware platform and server infrastructure, and (iii) the storage platform. Infrastruktur-Schicht, die sich aus (i) Infrastruktur-Software (ievirtualisation und OS-Software), (ii) die Hardware-Plattform-und Server-Infrastruktur und (iii) die Speicherplattform.
  5. Network layer; made up of routers, firewalls, gateways, and other network technology. Network Layer; aus Routern, Firewalls, Gateways und andere Netzwerk-Technologie.

This rather oversimplifies the architecture, as it’s important to note that each of the cloud billing / engagement models use capabilities from each of the above architectural layers; for instance their can be a lot of service simply in managing a network, however these describe the major architectural components (which support the service being procured), not simply ancillary functions, effectively what are the cloud providers customers principally paying for. Diese eher übermäßige der Architektur, wie es ist wichtig zu beachten, dass jeder der Wolke Abrechnung / Engagement Modelle verwenden Fähigkeiten aus jedem der oben genannten architektonischen Schichten, zum Beispiel ihre kann eine Menge Service einfach in die Verwaltung eines Netzes, aber diese Beschreibung der wichtigsten Architektur-Komponenten (die Unterstützung der Service werden soll), nicht einfach Nebendienstleistungen Funktionen, wirksam sind, was die Wolke Anbieter hauptsächlich Kunden bezahlen.

Delta of Effort / Delta of Opportunity Delta Aufwand / Delta von Opportunity

This is much more than the ‘gap’ between the cloud providers and the cloud users, wherein the cloud adopters / developers sit, the gap between the cloud providers and the end cloud users can be called the delta of effort, but also the delta of opportunity. Dies ist viel mehr als die “Lücke” zwischen der Wolke und den Wolken Benutzer, dass die Wolke Anwender / Entwickler sitzen, die Kluft zwischen der Wolke und den Ende Wolke Benutzer kann die Delta-Aufwand, sondern auch das Delta der Chance. ¨C88C

It is the delta of effort in terms of skills, abilities, experience and technology that the cloud adopter needs to deliver a functional service to their own “End Users”.  This will be potentially a major area of cost to the cloud adopters. Es ist das Delta der Anstrengungen im Hinblick auf die Fertigkeiten, Fähigkeiten, Erfahrungen und Technologien, dass die Wolke Anwender braucht, um eine funktionale Service für ihre eigenen “End User”. Dies ist möglicherweise ein wichtiger Bereich der Kosten für die Wolke adopters. But it’s also the delta of opportunity;in terms of ‘room’ to innovate. Aber es ist auch das Delta der Möglichkeit, im Hinblick auf die “Zimmer”, zu innovieren.

The more capability procured from the cloud provider (ie higher up the stack as a whole), the less you have to do (and procure) yourself.  However the less procured from the cloud provider the more opportunity you have engineer a differentiating technology stack yourself.  This itself has it’s disadvantages because the cloud adopters / developers could potentially not realise the true and best value of their cloud providers infrastructure. Die Fähigkeit, die aus der Wolke-Anbieter (z. B. die weiter oben in der Stack als Ganzes), desto weniger müssen Sie tun (und Beschaffung) selber. Doch die weniger die aus der Wolke Anbieter die Möglichkeit haben Sie ein Ingenieur differirende Technologie-Stack selbst . Dieses selbst hat seine Nachteile, weil die Wolke Anwender / Entwickler möglicherweise nicht, die wahre und beste Wert ihrer Wolke Anbieter Infrastruktur.

I suspect that there is an optimum level, around the Platform Layer, which abstracts enough complexity away (ie you don’t have to procure servers, networks, implementation or technology operations staff), but also leaves enough room to innovate and produce software engineered value.  Arguably the only current successful cloud provider, based upon market share, perception, revenue and customer take up, is Amazon Web Services (AWS) who provide a PaaS offering. Ich vermute, dass es ein optimales Niveau, um die Plattform-Layer, die Abstracts genug Komplexität entfernt (dh Sie müssen nicht beschaffen Servern, Netzwerken, der Durchführung oder der Technologie Operationen Mitarbeiter), aber auch genügend Spielraum für Innovation und Herstellung von Software-Engineering Wert. die wohl nur die aktuellen erfolgreiche Anbieter Wolke, die sich auf Marktanteil, Wahrnehmung, Einnahmen und Kunden nehmen, ist Amazon Web Services (AWS), die eine Paas bieten.

Summary Zusammenfassung

Hope you enjoyed the article, in summary if developing cloud services or even building out a cloud infrastructure I would recommend that you focus on your users and if your a cloud provider, your users’ users; remembering that only a certain percentage of those users will be customers (I won’t getting into discussing Chris Anderson’s 5% recommended conversion rate for the long tail , however I would recommend understanding what some of those calculations might be). Hoffen, dass Ihnen die Artikel, in der Zusammenfassung, wenn die Entwicklung Wolke oder sogar Ausbau der Infrastruktur eine Wolke Ich würde empfehlen, dass Sie sich auf Ihre Benutzer und wenn Ihr Provider eine Wolke, die Benutzer “Benutzer; Erinnerung, dass nur ein bestimmter Prozentsatz der Nutzer Kunden werden (ich werde nicht immer in der Diskussion Chris Anderson, 5% empfohlen, Conversion-Rate für den langen Schwanz, aber ich würde empfehlen, zu verstehen, was einige dieser Berechnungen werden könnten).

If you’re looking to develop services over the cloud, think carefully about where you and your teams skills lie, and where would you most want them focusing there efforts; working on installing and tuning operating systems and application platforms or writing business value focused applications and services, before choosing at which level to engage with your cloud provider(s). Wenn Sie zur Entwicklung von Diensten über den Wolken, sich genau überlegen, wo Sie und Ihre Teams Fähigkeiten liegen, und wo würden Sie am meisten wollen, dass sie sich es Bemühungen, auf die Installation und Tuning-Betriebssysteme und Plattformen Antrag schriftlich oder geschäftlichen Nutzen sich Anwendungen und Dienstleistungen, vor der Wahl, auf welcher Ebene, sich mit Ihrem Provider Wolke (n).

I haven’t mentioned enterprise adoption of cloud based services, and that’s because I’d like to post that in the near future in a different article. Ich habe nicht erwähnt Unternehmen Annahme Wolke Dienste, und dass deshalb, weil ich möchte, dass die Post in der nahen Zukunft in einem anderen Artikel.

Hope you enjoyed the article and all the best, Hoffen, dass Ihnen die Artikel und alles Gute,

Wayne Horkan
Wayne Horkan

Links for this article:

Simon Wardley responds to my “Cloud Relationship Model” article

Simon Wardley, Software Services Manager at Canonical UK and noted Cloud Computing expert and public speaker, responds to my article “Cloud Relationship Model“, with specific mention of my paraphrasing of a talk I saw him give; and thereby explains the history behind the “*aaS” double entendre.

Seriously though, the number of heads on the “*aaS” Hydra continues to grow, and Simon’s comment soon focuses upon the genuine need for a stable and standardised taxonomy, something I agree with wholeheartedly, along with a little bit of temperance and cool-headedness when it comes to thinking up and announcing more “*aaS” classifications…

Comment

Alas I cannot claim that joke to be my own.

Back in early 2007 when I gave a talk at ETECH, I described the changes in the industry as a continued shift of the computing stack from a product to a service based economy.

At that time I often categorised the computing stack into three layers – software, software platform and hardware (back from 2006). Whilst I had made comments that the software layer was really about applications and therefore SaaS should have had a more unfortunate acronym, this was not my true crime nor the origin of the joke.

The problem was that whilst SaaS and HaaS had been in common usage, the mid layer was known as SaaS Platform. This neither fitted neatly into the naming convention nor was it correct, as this layer of the stack contained many framework elements. So I started to describe this as the framework layer and FaaS seemed to be the obvious choice.

Hence at OSCON in Jul’07 I described the stack as a trio of SaaS, FaaS and HaaS.

Robert Lefkowitz (in a later talk at OSCON’07) warned us that this trio of “oh so wrong” nomenclature would lead to a whole lot of “aaS” and hence the joke was born.

Well Robert, as always, was spot on. In the last few years we’ve seen a plethora of different “aaS” terms (at last count it was about 16, including multiple versions of DaaS). The last few years has seen a constant exercise in revisionism.

Whilst the distinction between the layers of the computing stack is valid and meaningful, especially in context of the shift from products to services, what is not meaningful is the constant creation and recreation of terms.

Fortunately we now seem to be settling down to a three layer stack of application, platform and infrastructure – though I’m sure there is going to be more arguments.

This is why I argue the one thing we need in cloud computing today is a stable taxonomy.

Good post by the way.

Simon W

Sun Microsystems, Dynamic Infrastructure and the Register

Sun’s Dynamic Infrastructure is a Suite of Services, enabled by technology, and is just one of the ways that we can help you move toward a virtualized datacenter platform that fully exploits our expertise in IT architecture and process automation, enabling agility through the extremely flexible, efficient and secure deployment of the IT infrastructure.

It’s being going for at least three or four years, possibly even longer, and is led by Jason Caroline, who also spent time looking after Sun’s “Solution Delivery Network” (SDN, or what Scott used to call “a great big freking web tone switch”), and is currently involved in some of the work around Sun’s Cloud Computing offerings. You can learn a whole lot more about Sun’s Dynamic Infrastructure initiative here: http://www.sun.com/service/dynamicinfrastructure/

You’d probably be unsurprised to find that our Datacentre Virtualisation, Consolidation and Efficiency practice is one of our most repetitively successful lines of business in the UK and Ireland; and is enabled by the great delivery team that have assembled over the years in the UK Sun Services organisation (I even worked with them myself more than a few times whilst I was part of Sun’s Professional Services organisation).

Over the last couple of days I’ve been getting more than a little bored by all the articles on the Register going on about IBM’s Dynamic Infrastructure initiative, especially as if you’d imagine from the articles no-one had ever combined the words “Dynamic” and “Infrastructure” before and because of the relative closeness of some of the messaging (and yes, you could argue the initiatives are totally different but my gripes are to do with the above).

You may think I’m going over the top here, but really, six articles in the last two days, each mentioning “Dynamic Infrastructure”, is going a bit far. I couldn’t resist leaving the following comment on the article most focused upon the initiative in the hope that that leaves the aforementioned a little more balanced…

http://www.theregister.co.uk/2009/04/29/ibm_storage_apr09/comments/

Don’t want to rain on your parade but…

…Sun have been talking about ‘Dynamic Infrastructure’ for a few years now, in a similar light, you’d almost imagine someone might have read their press releases and material too.

More here: http://www.sun.com/service/dynamicinfrastructure/

Is syndication and responses a measure of blogging success?

Given that today marks the 5th year of http://blogs.sun.com (or just “bsc” to us Sun bloggers), and that it was this month two years ago that I published my first blog article (entitled “And finally“, an opinion piece on Gartner’s top ten predictions from 2007), I thought it would be nice to explore what “success” was in terms of blogging.

The most obvious indicator is large and regular readership, but I can’t imagine that that is all there is to it. The next most obvious criteria might be opinion setting, but measuring this seems troublesome and unscientific at that moment (until at least further semantic web infrastructure is in place to better relate meme flow across the Internet, although saying that Autonomy have an excellent visual analysis tool which is an early leading example in this field, the problem with this current non-semantic web model is that you have to generate meta-data by supposition, some of which is irregular at best).

Inward and outbound links are a major contributing factor in the calculation of Google’s “PageRank” algorithm, but I expect this to change significantly in the next few years as two things occur, increasingly effective “Search Engine Optimization” (SEO) techniques which will require modification to Google’s rating criteria, and the rise of the semantic web as increasing amounts of meta-data is included with unstructured data across the Internet, driving up implicit relationships between information.

And that leaves me with syndication and pieces written in response to your articles. Frankly I’m not sure that you can qualify syndication as a measure of success of your blog, but I do think it’s a good indicator of how far your message is being spread. I’m still uncomfortable with this, as I would prefer something more Empirical, however I think it may be about the best ‘soft’ indicator we have at the moment.

So using syndication of, and responses to, my articles, as a potential leading indicator, I correlated the following list. Historically I would have used Technorati to generate this information, but Technorati is suffering from some real issues lately, it’s page layout has become befuddled, and worst of all it’s not capturing (even remotely) the responses to my articles, subsequently I used Google Analytics’ “Referring Sites” breakdown instead (the list below isn’t remotely exhaustive, so if there is anything missing you’d like me to add let me know).

Elephant in the room

Or is that “Elephant on the table” I’m never quite sure which of the two you should use, but whichever is the case you’ll be unsurprised to know that it turns out for regulatory and legislative reasons we as individuals should demonstrate caution and discretion about blogging about ‘you know what’ or writing about ‘you know who’ or ‘them’ either. So there we go, that’s why there’s less of ‘that sort of thing’ than you’d probably like.

In the absence of opinion pieces coming out of the http://blogs.sun.com community it’s best to stick with the official updates which can be found below.

The early history of packet switching in the UK

Read an excellent article the other week in the IEEE’s Communications Magazine on the UK’s contribution to early packet switching and what would evolve into Ethernet and the Internet.

At the moment you have to be an IEEE member to view the article, however it’s an excellent piece, especially for those interested in the history of communications and technology, as well as the UK’s contribution to the field.

I was particularly interested to read about the barriers the UK teams had, especially when it came to support from the UK communications and technology ecosystem of the time and the incumbent Government. Despite the gap in time some of the issues were surprisingly similar to those present today.

Here’s the abstract from the IEEE site:

In this issue of the History Column we bring you an article by Prof. Peter Kirstein, one of the original contributors to early packet switching. We are probably all familiar with the history of the Internet, beginning with its genesis in the American-developed ARPAnet of the late 1960s and early 1970s. We may be less familiar with the contributions of British researchers, as well as those in other countries such as France, at about the same period of time, who worked closely with American researchers as well as independently in developing the packet-switching technology so fundamental to the Internet. Prof. Kirstein recounts the early activities by British engineers, led by Donald Davies of the National Physical Laboratory, the British Post Office, those of his own group at University College London, and others as well. He also ties this work into ongoing activities in the United States at the time. In future History Columns we plan to have similar articles by U.S. packet-switching pioneers on their own early activities in the field. This series of articles on the genesis of the Internet should be of great interest to all communication engineers. We commend the article following to your attention.

For those not in the IEEE, who are thus excluded from reading this excellent article, the BBC has a nice online piece about the UK’s contribution to early packet switching technology, with particular reference to British mathematician Dr. Donald Davies at the UK’s National Physical Laboratory (NPL), accompanied by some nice video clips too.