71490 Consultancy on the NEAt and eGIF Initiatives of the Royal Government of Bhutan Submitted By Shahani Markus Weerawarana, Ph.D. (Short Term Consultant – World Bank) Table of Contents 1 Introduction......................................................................................................................3 2 Background......................................................................................................................3 3 NEAt & eGIF Project EOI.................................................................................................3 4 The G2C Project..............................................................................................................6 5 The NEAt & eGIF Project TOR and RFP.........................................................................7 6 Creating a Core Team.....................................................................................................9 7 Field Visit to Bhutan......................................................................................................11 8 Summary........................................................................................................................14 S.A.B.M. Weerawarana Page 2 1. Introduction The Royal Government of Bhutan (RGoB) is planning on developing a National Enterprise Architecture (NEAt) and electronic Government Interoperability Framework (eGIF) catered towards local needs, yet leveraging international best practices. This project was initiated by the Department of Information Technology & Telecommunications, under the Ministry of Information & Communications, which is the apex body for all ICT related activities within the RGoB. Since this department lacked overall expertise in NEAs and eGIFs, I was contracted as a World Bank Short Term Consultant to help them with this process. The interactions between Mr. Jigme Tenzing, (Head, Applications Division, Department of Information Technology, Ministry of Information & Communications, Bhutan) and myself, th began via email contact on the 25 of October 2010. The primary modes of communication were restricted to electronic mail and occasional phone calls. I th th made a field visit to Bhutan for 7 days, from June 17 – June 25 , 2011. 2. Background Bhutan is a democratic constitutional monarchy (since 2008), and has a total population of less than 700,000 people living in predominantly rugged mountainous terrain. About 70% of the population living in rural communities. Bhutan has a civil service of over 22,000, which is divided into 10 Ministries, 18 Autonomous Agencies, and 4 Constitutional bodies. The country is divided into 20 Dzongkhags (districts), and 205 Gewogs (blocks). 3. NEAt & eGIF Project EOI During the initial communications, Mr. Jigme Tenzing indicated that the EOI for the NEAt and eGIF project had already been developed and that a draft RFP was almost complete. He also indicated that they needed reviews of these documents urgently since rd they were planning on sharing the RFP with potential consultants by November 3 . I provided my feedback on the EOI immediately, primarily indicating aspects that could be included as well as highlighting aspects that seemed too vague. Since one of the additions I suggested was the inclusion of a Government Interoperability Maturity Model, I also shared a research paper that elaborated on this concept. I discussed the potential complexity and risk of this initiative as well. An excerpt of my general feedback is given below in Figure 3.1. S.A.B.M. Weerawarana Page 3 The approach to constructing the NEA and eGIF should include an “iGovernment� view as well. In general, developing an NEA and eGIF are significantly time consuming activities. In fact, I am fairly sure that the stipulated 1 year would not be sufficient for this purpose. Thus, it is important that a proper approach is adopted, so useful services and solutions can also be built systematically whilst the overall frameworks are being finalized and detailedout. For this, it would be important to ensure the following: • The information domains are properly identified earlyon. • Along with the identification of the information domains within the RGoB, the ownerships and security levels should also be determined, including the information ownership responsibilities for each domain. • The information domain identification will also greatly reduce the complexity of re- engineering the government processes by providing a clear picture of the information flows that would be necessary to enable various government processes (and resultant citizen services). • • The entire process should be based on a suitable Government Interoperability Maturity Model, so that the progress towards interoperability by each government organization can be measured. • Such a Maturity Model should include the measurement of capabilities for vertical information integration and horizontal information interoperability at each vertical level. • Such a model would also ensure a clear understanding of the existing levels of interoperability and integration within government organizations (and the associated information domains). Figure 3.1: Excerpt of General Feedback on EOI In addition to the specific feedback I gave on the EOI document, this general feedback reflected my initial concerns about the immense complexity of embarking on a joint NEA and eGIF creation initiative. At that point in time, there also seemed to be an apparent lack of immediate practical usage of these frameworks, which had the risk of making this largescale initiative a mere theoretical exercise. However, this assumption proved to be invalid as I later learned about the existence of the G2C project. Thus, on the contrary, the G2C project prompted a greater urgency towards the establishment of these frameworks. S.A.B.M. Weerawarana Page 4 Another concern of the Bhutan team, was the confusion around the terms “EA� and “SOA� a very common scenario due to the plethora of widely varying definitions in existence with respect to these terms. An excerpt of my attempt to clarify these terms to them, is given in Figure 3.2 below. EA and SOA are two separate things. An Enterprise Architecture is a 'complete expression of an enterprise". It is not technical in nature and its main purpose is to relate organizational mission, goals & objectives to business tasks, activities & relations and to the technology or IT infrastructure required to execute them. Since this is a very complex and daunting task for any type of organization, there are various frameworks that have been designed to support such endeavors namely, the Zachmann Framework, TOGAF, EIF etc. The problem is that EAs end up being overly complex and very difficult to fathom, once completed. Hence, from a practical point of view, it can appear to be a useless exercise. However, there are many "interpretations" of the meaning of an EA. Your EOI clearly states what RGoB envisions as an EA, which is somewhat limited in scope in comparison to some other NEA endeavors. This is in fact a positive approach since the end result could be reduced complexity and greater usability. I would be somewhat concerned if the potential partners indicate that they intend to use "heavy duty" frameworks such as Zachmann or TOGAF etc., and thus, we would need to ensure that the entire endeavor does not become a meaningless theoretical exercise. As per the description in your EOI, the eGIF you have requested is actually the "usual" bottom half of a typical EA. It is a very important aspect. SOA (Service Oriented Architecture) is a lower level software architectural pattern or style that is used to implement a large number of distributed system solutions. Many technical solutions that are implemented nowadays are in the form of distributed systems. Such distributed systems can be designed based on several architectural patterns such as ClientServer, PeertoPeer, EAI (Enterprise Application Integration) and SOA etc. Of these, SOA has proven to be a very powerful and useful architectural pattern, since it naturally models realworld situations in an easytounderstand, easytoimplement, easyto- maintain, and highly looselycoupled manner. S.A.B.M. Weerawarana Page 5 Clearly, as with any kind of technical solution design, an SOA based design will only prove to be highly effective if it is aligned with the enterprise's/organization's requirements or needs. Hence, it is absolutely critical to have a solid, holistic, businesslevel view of the entire enterprise from a current and future perspective. In fact, this is ideally what an EA should deliver. Unfortunately, many EA initiatives have been unsuccessful in achieving this goal. From these brief explanations I hope you will be able to get a sense of EA, eGIF, SOA etc., and how the complexity would increase as these concepts are mapped onto a "national" level collection of enterprises such as a government. In a nutshell, an SOAbased solution implementation will give you capabilities and services that would execute the business processes detailed in an EA/eGIF. So you theoretically need both, SOA and EA/eGIF! That said, there are shortcuts that any organization/country could and should take.... Figure 3.2: Excerpt of EA vs. SOA explanation 4. The G2C Project Soon after these discussions, Mr. Jigme Tenzing informed me of the existence of another parallel initiative – the outsourcing of the development of more than 100 public services (G2C project) with an intended date of completion of June 2012. Quite correctly, he raised his concerns regarding the critical decisions that needed to be taken at this stage for the services, so that there would not be any major changes in the future, once the EA and eGIF were completed. The services were to be developed using a SOA approach, with singlesignon for the Community Center operator who would be operating the services on behalf of the citizens. My initial reaction to this parallel initiative was that a pragmatic approach should be adopted to deal with the obvious complications that would arise. As I gathered more details, I realized that Bhutan had a few National Databases already in existence. I considered this to be an excellent situation, and indicated that it did not S.A.B.M. Weerawarana Page 6 matter that they are currently limited to the parent organizations, since that is an aspect that can be quite easily solved technically, provided the agencies are willing to share the information in their repositories. I noted that the requisite security levels could be easily implemented as well and that these databases could essentially be viewed as "information domains". With that perspective, I pointed out that we could begin to see how the information would need to flow, both vertically (local community center to national database) and horizontally (between agencies). At this juncture, Mr. Jigme Tenzing and I had a lengthy phone conversation to discuss the overall impact of the NEAt eGIF project and the G2C project, and I tried to convey to him the vision and alignment that could be achieved by both initiatives, using the Sri Lankan experience of LankaGate and LIFe as examples. In particular, I suggested many important aspects that they should include in the G2C project RFP, in order to ensure that this alignment between the two initiatives would be possible. 5. The NEAt & eGIF Project TOR and RFP Mr. Jigme Tenzing subsequently sent me the draft TOR and RFP for the NEAt & eGIF project for my feedback. He specifically requested advice on the amount of persondays this project would entail. After careful review of the documents, I sent my feedback, an excerpt of which is given in Figure 5.1 below. I would strongly recommend that you first do the following in order to determine the approximate persondays. 1. The scope specified in the TOR is very important, yet very broad. If you ask a consultant firm to do it in that manner, there would be a high probability of failing to meet the expectations/deliverables. Hence, try to breakdown the overall scope of work into smaller segments, with distinct, clear deliverables for each segment of work. Ideally, this should be done for both the EA component and the eGIF component. • As a technique, start with very large items of work and then gradually break them down into smaller tasks. Make sure that you define a clear deliverable for each task, however small it may be. 2. You will find that it would be much easier to estimate the effort for these smaller segments of work. You will also discover that some work items need to be done concurrently and some would need to be done serially. Hence, place each scope segment on a rough timeline, with the potentially concurrent items grouped together. S.A.B.M. Weerawarana Page 7 • When you estimate the work effort, try to specify "when" you think the task should be completed according to the timeline. Don't be too worried about the persondays initially. • Once you have figured out the "completion timeline" for each task, then you can roughly estimate the size of the team that would be necessary to do this work. This would directly translate to persondays for each task. 1 Now you can add up the total number of persondays, and you will also have a fairly clear idea of the overall timeline as well as the intermediate deliverables. 2 Ideally, you could add the intermediate deliverables into the TOR, to give the potential bidders a very clear idea of your expectations. Keep in mind, that historically, very large projects have a tendency to fail when given to just a single consultancy firm. So, by specifying several intermediate targets/deliverables, you will be able to practically enforce an incremental process with feedback loops, which is a best practice in IT projects. Figure 5.1: Excerpt of Feedback on draft TOR and RFP Yet, despite all this feedback and guidance on related literature I sensed that there was an obvious state of confusion regarding the scopes and relationships between the EA & eGIF project and the G2C project. As Mr. Jigme Tenzing pointed out, the more they read, the more gray the distinction between EA and eGIF became. Although this lack of clarity was a problem to them, it was also an indication to me that the Bhutan team was reaching a deeper level of understanding – since with an indepth perspective, the differences between EA and eGIF do indeed become very vague and upto individual interpretation. In the interest of maintaining their sense of confidence in the initiative and explaining to them that this was a natural progression of confusion, I once again provided feedback regarding this lack of clarity. An excerpt of this feedback is given in Figure 5.2 below. This is lack of clarity is partly because you are requesting for both an EA and an eGIF. There is considerable overlap between the typical definition of these two initiatives, when considering them separately. So, when they are combined and done together, it is necessary to figure out exactly 'what part belongs' to the EA and 'what part belongs' to the eGIF. S.A.B.M. Weerawarana Page 8 One way to think about this is to figure out 'who' would be primarily using the EA and 'who' would be primarily using the eGIF. Generally, the EA should be targeted at nontechnical government officials, BPR specialists etc. The eGIF should be targeted at the more technicallysavvy people and particularly at the 'implementors'. So, in addition to specifying open standards, the identification of common data elements and their structures would be very important here. Specifying these aspects is what enables interoperability. Particularly, it would help existing applications to 'translate' or 'transform' the data that they intend exchanging, to the common interchange format. For example, it is in the description of data elements in an eGIF that the meaning of 'address' would be defined, in addition to specifying how the 'address' data element would be represented (its structure/subfields etc.), and the associated XML schema portion that specifies the 'namespace' and the 'format' information. However, 'what is in an eGIF' is very contextual and is dependent on what else is already present or planned to be defined in each situation. But fundamentally, an eGIF should provide most of the information necessary to enable interoperability of data between organizations - which means, at the very least, the details of the services (WSDL), the semantics of the data elements (data descriptions and ownership) and the details of data elements (XML schema with namespaces) should be present. In many cases, governments or organizations who want to achieve interoperability and provision of services fast, delay on the NEA and focus only on the eGIF. In fact, that is the strategy adopted in Sri Lanka. However, at some point, an overall idea of existing and planned processes and information flows would be very important (NEA or something similar). Figure 5.2: Excerpt of Feedback on Lack of Clarity in EA and eGIF 6. Creating a Core Team Mr. Jigme Tenzing and Mr. Lobzang Jamtsho (ICT Officer, Dept. of Information Technology & Telecommunication, Ministry of Information and Communications, Bhutan), then started discussing the creation of a core team that would work with me on the RFP for the NEAt and the eGIF. They shared the profiles of shortlisted officers and requested my opinion. S.A.B.M. Weerawarana Page 9 My primary concern lay in the shortlisted team members' seemingly low exposure to eGIF and NEA concepts. An excerpt of my feedback along these lines is given below in Figure 6.1. Looking through the list, I could gather that most of them are ICTsavvy. However, I don't see much evidence of them being exposed to, or being trained in eGovernment concepts, interoperability, integration etc. This is of course not surprising, since these are specialized areas. The concern is that they may not have the necessary background to make certain judgment calls. Also, they may not have a general understanding of similar eGovernment initiatives and case studies, including awareness of typical pitfalls. We had a similar issue in Sri Lanka as well which is why we introduced an 'MBA in eGovernance' program at the University of Moratuwa, which turned out to be the first such program in Asia. You could consider providing a similar training to these team members as well probably not an MBA which would take too long, but maybe a shorter, tailor- made certificate course or diploma course in eGovernance. I am aware that you face time & resource challenges. However, I urge you to seriously reconsider your existing priorities. It is crucial to recognize the importance of increasing relevant knowledge of future eGovernance champions of Bhutan, as well as their capability to continue their learning, engage in research, have constructive discussions, and make informed decisions. This may ultimately be a key to the success of the NEAeGIF initiative. It would be a primary strategy to avoid future unnecessary expenditure and to ensure Bhutan's ability to efficiently take their eGovernment initiatives forward with confidence and selfreliance. I will try my best to provide the relevant background information/learnings when I meet the team. But this would be grossly insufficient when viewed from a longterm perspective. Figure 6.1: Excerpt of Feedback on Training the Core Team In addition to these opinions on the importance of ensuring sufficient background knowledge in eGovernance within the core team, I also provided feedback on the core team's composition, as requested by Mr. Jigme Tenzing. An excerpt of this feedback is given below in Figure 6.2. S.A.B.M. Weerawarana Page 10 As far as team composition is concerned, in general, it is very difficult to select people just based on their qualifications & experience etc., as you have listed in the spreadsheet. I hope you will have the opportunity to talk to each one of them. Then you can shortlist them based on the following: (1) their attitude towards this initiative, (2) their interest in learning more about eGovernment & Interoperability, (3) their keenness in participating in this entire process, and (4) their enthusiasm in being a champion of this initiative within their organizations. If they display all these attributes, there would be a high likelihood of them being effective in the core team. Figure 6.2: Excerpt of Feedback on Core Team Composition 7. Field Visit to Bhutan th th I visited Bhutan from the 18 of June 2011 to the 25 of June 2011. This field visit turned out to be extremely valuable in terms of my being able to systematically educate the core team on background concepts. This led to a clearer understanding of the NEA and eGIF initiative amongst the team members as well as its relationship with the ongoing G2C project. Using Sri Lankan examples, other case studies and extracts from research papers, I was able to convey important best practices as well as an enhanced “way of thinking� with respect to the implementation of eGovernment projects. The subsequent brainstorming sessions and discussions with the team members showed that many of them had internalized these concepts very well, and that they were able to effectively apply the best practices in their scenario. During the field visit, I also got an opportunity to review the G2C project architecture and to highlight certain concerns with the G2C project vendor's team over a teleconference. We discussed many points and reached potential resolution on many aspects which were important from a “farreaching impact' perspective. I specifically tried to nudge the G2C vendors towards defining “information services� as web services instead of just the process based web services as in the current design. Through this meeting, I was able to demonstrate to the G2C team members, how Bhutan should “take ownership� of their project, instead of allowing the vendor to 'dictate the path'. I shared many research papers with the core team members. I was also able to have many indepth discussions with Mr. Jigme Tenzing on a variety of topics related to EA, SOA, eGIF, procurement, etc. particularly with respect to pragmatic approaches that could S.A.B.M. Weerawarana Page 11 be adopted to enhance the effectiveness of eGovernment initiatives and the efficiency of the procurement processes. To this end, after a fairly indepth literature survey, I shared and discussed the importance aspects of the following papers: Interoperability 1 “Government Worth Having: A briefing on interoperability for government leaders�, by Theresa A. Pardo and G. Brian Burke, Center for Technology in Government, University at Albany, SUNY. October 2008. 2 “eGovernment Interoperability: Overview�, United Nations Development Programme (UNDP) Regional Centre in Bangkok. 2007. Available at http://www.apdip.net/projects/gif/GIF- Overview.pdf. 3 “eGovernment Interoperability: Guide�, United Nations Development Programme (UNDP) Regional Centre in Bangkok. 2007. Available at http://www.apdip.net/projects/gif/GIF- Guide.pdf. 4 “eGovernment Interoperability: A review of Government Interoperability Frameworks in Selected Countries�, United Nations Development Programme (UNDP) Regional Centre in Bangkok. 2007. Available at http://www.apdip.net/projects/gif/GIFReview.pdf. 5 “Interoperability Framework Version 2.0�, National eHealth Transition Authority (NEHTA), NSW, Australia, August 2007. 6 “Improving Government Interoperability: A capability framework for government managers�, by Theresa A. Pardo and G. Brian Burke, Center for Technology in Government, University at Albany, SUNY. October 2008. 7 “Maturity levels for interoperability in digital government�, by Petter Gottschalk, Government Information Quarterly, August 2008. Published by Elsevier. 8 “Towards Standardising Interoperability Levels for Information Systems of Public Administrations� by Demetrios Sarantis, Yannis Charalabidis, and John Psarras, eJETA Special Issue on “Interoperability for Enterprises and Administrations Worldwide�, 2008. Information and iGovernment 9. “From Electronic Government to Information Government�, by Viktor MayerSchonberger and David Lazer, “From egovernment to igovernment: governance and information technology in the 21st century�, editors; Viktor Mayer Schonberger and David Lazer, MIT Press, 2007. 10. “UN eGovernment Survey 2008 – From eGovernment to Connected Governance�. Publication of the United Nations, New York. ISBN 9789211231748. 2008. S.A.B.M. Weerawarana Page 12 11. “Enterprise Knowledge Management: The Data Quality Approach�, David Loshin, Chapter 2 “Who Owns Information?�, published by Morgan Kaufmann; 1st edition (January 22, 2001). 12. “Information Engineering in Support of Multilateral Joint Operational Interoperability�, by Éric Dorion and AnneClaire BouryBrisset, of Defence R&D Canada, in Command and Control Research and Technology Symposium, 2004. Enterprise Architecture 13. “A Better Path to Enterprise Architectures�, by Roger Sessions, prepared for Microsoft Corporation, March 21, 2006. 14. “Comparison of the Top Four Enterprise Architecture Methodologies� by Roger Sessions, CTO of ObjectWatch Inc., 2007. 15. “NASCIO Enterprise Architecture Maturity Model�, by the National Association of State Chief Information Officers (NASCIO), Version 1.3, December 2003. 16. “Service Oriented Architecture: An Enabler of the Agile Enterprise in State Government�, Research Brief by the National Association of State Chief Information Officers (NASCIO), May 2004. Software Engineering 17. “Chaos Report� by The Standish Group, 1995. 18. “Trends in IT Value� report by The Standish Group. Available at http://www.standishgroup.com, 2008. 19. “Supply and Installation of Information Systems SingleStage Bidding�, published by The World Bank, December 2008. 20. “Introduction to the Enterprise Unified Process�, whitepaper summary of the book “The Enterprise Unified Process: Extending the Rational Unified Process� by Scott W. Ambler, John Nalbone, and Michael Vizdos, published by Prentice Hall PTR, February 2005. 21. “SDSA: An Agile Approach to eGovernment Solution Procurement and Development�, Shahani Markus Weerawarana, Kanchana Thudugala and Wasantha Deshapriya, eAsia Conference 2009. 22. “LankaGate: An Integration, Mediation & Delivery Platform for eGovernment Services�, Shahani Markus Weerawarana, Eranga Jayasundera, Kanchana Thudugala, Crishantha Nanayakkara, Wasantha Deshapriya and Sanjaya Karunasena, eAsia Conference 2009. S.A.B.M. Weerawarana Page 13 Towards the end of the week, after most of the knowledge sharing sessions were completed, we were able design a highlevel framework for the Bhutanese eGIFs. The ideas for this framework were mainly derived from the Greek eGIF framework. In addition, the framework that we formulated included ideas from other eGIF case studies. Based on this framework we had a productive discussion on how the Information Domains could be identified and how the initiative could be partitioned, for procurement purposes. We designed the overall structure of the first RFP (of a series of RFPs) and Mr. Jigme Tenzing was able to complete writing many parts of the document. In the end, we all felt a great sense of satisfaction and relief that there was a clear approach and purpose to the entire initiative and that it was well aligned with the ongoing eGovernment initiatives. Personally, I feel that the highlevel Bhutanese eGIF framework design that we formulated can easily rank as one of the best examples in the world today. It will be very interesting to follow its gradual implementation. 8. Summary Overall, during this entire consultancy, whilst helping the Bhutanese team understand the requisite background and techniques related to EAs and eGIFs, I attempted to guide them along the following best practices: • Develop a vision by addressing the following questions: • What are we trying to achieve? • How does it fit into the rest of the eGovernment ecosystem? • Who are the stakeholders? • What are the critical aspects? • Who are the owners of the underlying information domains? • What are the resultant information flows? • • Formulate a highlevel architecture / framework in order • to communicate, • to understand the challenges, • to have an overall direction, • to understand the vision as a "sum of parts". • • Focus on a iterative / incremental solution development approach as a, • projectization strategy, • procurement strategy, • implementation strategy, • deployment strategy, and a • strategy to recover from project failure. S.A.B.M. Weerawarana Page 14