Nostaligia time.
I should've spoken out long ago. I am not happy with the National Services Delivery Gateway (NSDG, a.k.a the Gateway)... and it is partly my fault too.
Every time I had an opportunity to say it bluntly, I chickened out, equivocated and settled for tact instead of calling that oft useful digging implement by its real name. I may be forgiven for my hesitation; for I was a party to its adoption in India when I proposed and defended it in a peer-review forum (some time in 2001, I think); and then supported the first interim-implementation for the MCA21 project.
At a high level, it was pretty close to the UK Online Gateway. So when the time came to get down to details - while writing the specs for the Gateway in MCA21 as well as taking part in the India One Gateway project, my program leader was probably surprised that I wanted to deviate from the UK Online Gateway. I tried to convince him that the "by then already 6+ year old design" was not the best thing. On a long night walk in Delhi, I lost the argument with a smooth "I am sure the KPMG-UK consultants knew what they were doing" thrown at me. Hurt, I distanced myself from that project for many years. Others did what they were probably told - to copy the original as best as they could. The result is our NSDG in its current form.
Over the years, many people asked me to elaborate on why I proposed the concept in the first place. I have always defended the concept (quite rightly so) - and refrained from answering any more than I was asked. They never asked; and I never spoke of what I might've done differently.
Fast forward to the present. Here, I present my thoughts on what is right and what is wrong with our NSDG. Readers will have to judge for themselves whether I am off my rocker.
The concept is correct. In that, I am convinced beyond any doubt. Time has not altered this. I will skip all the usual already-well-articulated benefits of the Gateway (reiterated recently in a letter by Sh. R Chandrashekhar to all state Chief Secretaries) - such as security, interoperability, guaranteed-delivery, etc.. I will get straight to the point in plain (non-EA) terms.
It is correct because it aligns correctly to the functional representation (how it works) and structural representation (how it is) of the Government. Intuitively speaking, it recognizes real-world boundaries and brings them into the solution architecture (model?) as close to reality as possible - hence making the model as stable as can be.
Note: In "process terms", close-to-real-world must not be interpreted as the "as-is" process. In fact all models must be validated against "re-engineered processes" - even when the modeling must precede process re-engineering (hint: iterative approach)
In EA terms, it correctly aligns the Solution Architecture level elements to the corresponding Enterprise Architecture level elements, without disturbing anything in the Segment Architecture. Of course, this cross-layer alignment is a general principle that applies to all forms of modeling - not just EA. Do it any other way, and you will face frequent earthquakes of the IT-kind.
Therefore, I appeal to the folks at DIT: Stop. Reverse. Recreate from scratch. I am sure you will get it right this time.
I should've spoken out long ago. I am not happy with the National Services Delivery Gateway (NSDG, a.k.a the Gateway)... and it is partly my fault too.
Every time I had an opportunity to say it bluntly, I chickened out, equivocated and settled for tact instead of calling that oft useful digging implement by its real name. I may be forgiven for my hesitation; for I was a party to its adoption in India when I proposed and defended it in a peer-review forum (some time in 2001, I think); and then supported the first interim-implementation for the MCA21 project.
At a high level, it was pretty close to the UK Online Gateway. So when the time came to get down to details - while writing the specs for the Gateway in MCA21 as well as taking part in the India One Gateway project, my program leader was probably surprised that I wanted to deviate from the UK Online Gateway. I tried to convince him that the "by then already 6+ year old design" was not the best thing. On a long night walk in Delhi, I lost the argument with a smooth "I am sure the KPMG-UK consultants knew what they were doing" thrown at me. Hurt, I distanced myself from that project for many years. Others did what they were probably told - to copy the original as best as they could. The result is our NSDG in its current form.
Over the years, many people asked me to elaborate on why I proposed the concept in the first place. I have always defended the concept (quite rightly so) - and refrained from answering any more than I was asked. They never asked; and I never spoke of what I might've done differently.
Fast forward to the present. Here, I present my thoughts on what is right and what is wrong with our NSDG. Readers will have to judge for themselves whether I am off my rocker.
The concept is correct. In that, I am convinced beyond any doubt. Time has not altered this. I will skip all the usual already-well-articulated benefits of the Gateway (reiterated recently in a letter by Sh. R Chandrashekhar to all state Chief Secretaries) - such as security, interoperability, guaranteed-delivery, etc.. I will get straight to the point in plain (non-EA) terms.
It is correct because it aligns correctly to the functional representation (how it works) and structural representation (how it is) of the Government. Intuitively speaking, it recognizes real-world boundaries and brings them into the solution architecture (model?) as close to reality as possible - hence making the model as stable as can be.
Note: In "process terms", close-to-real-world must not be interpreted as the "as-is" process. In fact all models must be validated against "re-engineered processes" - even when the modeling must precede process re-engineering (hint: iterative approach)
In EA terms, it correctly aligns the Solution Architecture level elements to the corresponding Enterprise Architecture level elements, without disturbing anything in the Segment Architecture. Of course, this cross-layer alignment is a general principle that applies to all forms of modeling - not just EA. Do it any other way, and you will face frequent earthquakes of the IT-kind.
Product lifecycle management of the NSDG is also good. There is constant, laudable endeavor in the project to identify and fix the problems; as well as improvise and make the Gateway more and more useful. For example, the redundant sign-the-envelope part is now optional. I am told that the multi-hop end-to-end routing delays problem has been resolved at the design level. This way, many of the original design flaws have apparently been corrected to a large extent. The concept has been expanded to include NSD, SSDGs and Domain-specific Gateways. Clearly the heart is in the right place.
There have been many people and organizations that have debated and blamed the Gateway as an exercise in architectural "idealism" that must bend to accommodate (read: compromise in favor of) practical implementation issues. I am told even the first bastion of the Gateway has been allowed to fall - by way of allowing bypass of the gateway. I have no doubt that the arguments must've been compelling; for the problem is very subtle in nature - and diagnosis defies any but the most seasoned EA practitioners. In my case, a lucky coincidence helped me. I had started from scratch without the burden of knowing what UK Online was and was able to compare my solution to the present to arrive at the diagnosis.
If these detractors read on, I am sure most will agree that the problem is not with the concept or the architecture.
If these detractors read on, I am sure most will agree that the problem is not with the concept or the architecture.
So where then, is the problem?
IMHO what really needs to be recognized is this. NSDG works best when it's core is ultra-lean and ultra-efficient with near-zero value adds in its functionality. The more feature-rich you make it, the more "sub-projects" you add to it, the more difficult it becomes to keep the core ultra-lean / ultra-efficient. The IIS, IIP, IGIS etc., are already needlessly complex, making the core already unwieldy. All the creative add-ons such as the NSD, SSDG, Domain-specific Gateways, etc., perpetrate and aggravate an already bad situation.
In that sense, the real problem with the NSDG has been in its design. The protocols are bloated. (hint: No protocol should attempt to do things that are already done / best-done in other layers). The components are bloated (as opposed to lean-and-mean) due to the efforts of making them feature-rich (hint: Middleware design principles are counter-intuitive to most application software designers).
Therefore, I appeal to the folks at DIT: Stop. Reverse. Recreate from scratch. I am sure you will get it right this time.
Have just got linkedup to your musings..nice to read you...
ReplyDeleteAs a term, any Gateway relates to a 'boundary' and to what goes through!!. From that perspective, the fundamental logic of having a Gateway and its consequent relevance to the cause, depends upon What is being channelised(public services), from Whom(Govt) and Alternative routes(porous boundary). There is a need to get these basics right. The technical architecture layers (EA, SA,...) being a 'slave' to the need/process, are easier to decide/configure.
@Ajay: True, we need to get the basics right. Unfortunately, for many problems (like that of Government EA), it is not easy to even figure out what are the right basics ... and then comes the challenge of convincing steadfast "Argumentative Indians". I think, the people who contributed to the scenarios I mentioned in this context - all meant well. Each were, however, thoroughly convinced about the correctness of their approach. Not an easy situation.
ReplyDelete