Skip to main content

With a RASP in my Throat

Rangan 550x599 05jun14

Before joining ICANN, people had told me that it is unlike any other organization. Coming – as I did – from global companies like Samsung, Walmart, Bank of America and most recently, Edwards Lifesciences, I asked myself whether it could be that different.

It has been about 100 days since I came onboard ICANN. And I have learned a great deal. Yes, ICANN is different in many ways. And no, ICANN is similar to many other environments in which I have served. For me, it is a combination of a commentary on what ICANN does and where it is on the growth-maturity curve.

Best-sellers have been written about what to do (and what not to do) in the first 100 days. My own 'mantra' is to meet with a cross-section of at least 100 people in the community and in the new organization; understand the needs of the community that the organization serves; understand how it creates and delivers value; and, last but not least, understand the fit and finish required of the IT function and my role in this microcosm. I have now met with well over that target number of 100 people – from the community, the Board, and the staff.

Within short three weeks of joining ICANN I attended ICANN 49 in Singapore. Coming back from the event, I was feeling rather overwhelmed by the variety and depth of interactions that occurred at the meeting. This new information seemed to just float in my mind, with no peg-board as a backing to anchor it.

In Singapore and later back in Los Angeles, ICANNers shared with me how the organization had grown through the years. They explained ICANN's roots, as well as its evolution in scope and capabilities. A peg-board was starting to take shape in my mind. Over the last two months, I have met with three to four people nearly every day. Time and interactions have helped greatly. I feel like I now have a peg-board on which to anchor thoughts. Many of those previously floating pieces have settled into validated parking spots in my mind.

Clearly ICANN must provide a wide variety of services to the broad ICANN community. Our global, multi-stakeholder community is large in dimension, diverse in requirements and unique in segmented needs. Given the nature of the Internet, with which we are so closely associated, both the portfolio of services and their uninterrupted availability are key ICANN deliverables. Technology is the key to translate and deliver these services. I feel that I am now starting to understand – viscerally – the critical nature of the IT (and my own) role at ICANN.

As I take stock of my domain of accountability, it reminded me somewhat of my early days at and with's ecommerce group. Those were places and times when the topics of integrated services-portfolio and global, uninterrupted services-availability were frequently discussed. It occurred to me that, just like those organizations in other fields, ICANN is progressing through a maturity curve.

The RASP in my throat is not because of all the talking. It is a useful four-letter acronym to reflect what needs to be done to mature IT-enabled services. It stands for Reliability, Availability, Scalability and Performance. Growing organizations eventually get to a point where they have to look back, retro-RASP their services, and then proceed ahead. My assessment of ICANN's IT-enabled services clearly indicates that it is time to do so at ICANN.

I have proposed and started to execute a five-step program to retro-RASP our portfolio of IT-enabled services. These steps are as follows:

  1. For the next two-to-three year period, increasingly focus IT investments, especially in non-project, RASP-oriented work: This will help strengthen meta-processes.

  2. Create an umbrella of policies that govern IT activities: This will help create a stage for a uniform approach to IT projects and services-delivery initiatives.

  3. Institute a robust Product Management and Product Development mindset: ICANN will benefit from the discipline that this mindset brings with it.

  4. Exercise a more formal Design Verification and Testing (DVT) methodology: As with the third step, this methodology is proven to yield reliable and dependable software.

Steps one through four will take time to implement and to take root. It may be a year before we can get holistic improvements. And a couple of years more before these changes reflect themselves in a portfolio of robust services. But, as the saying goes, every journey starts with that first step.

Meanwhile, in the short-term we will:

  1. Inventory and assess the portfolio of community-facing IT-enabled services: We will look at the data behind the service, alongside the protection-mechanisms in place. And depending on what we find, take the needful remedial actions – of course, after informing the impacted segment(s) of the community.

For me, RASP is more than a concept. It is a state of mind. Dynamic organizations in rapidly-changing environments embrace RASP as their de-facto mindset. From my point of view, ICANN is ready to start walking on a path to a more mature plateau of IT-enabled services delivery. As I start leading the staff towards this plateau, I am increasingly confident of the path that we need to chart. The goal is clear. It is to ensure uninterrupted IT-enabled services for the benefit of our diverse, global, multi-stakeholder community.

The very nature of the community we serve literally spells "one size does not fit all." So while the goal is clear, we will – as with any journey – periodically calibrate our progress and our milestone achievements with feedback and inputs from the community. That way, the community serves as our globally distributed listening-posts and eyes. In this regard, we are all on the same journey together, assisting one another towards a common, value-denominated destination.

In a year's time, we should be able to look back and say that the meta-processes that govern services-development are largely completed. Remediation of community-facing services, if vulnerabilities are detected during assessment, should be well underway. In two years, we should look forward to the meta-processes maturing – with practiced repetition – to the point of being taken for granted. And in three years, we should expect projects to leverage these underpinnings as a matter of course, rather than as a retrofit. Yielding better defined services and better global availability of these services based on planned design.

As I leave the starting blocks and begin this marathon effort, I feel excited and enthusiastic. The IT core-team at ICANN is knowledgeable. We are selectively adding talent and capabilities in areas that need to be bolstered. I like the RASP in my throat! And would love to get feedback from the ICANN community. Are we tracking?


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."