Yves is an IT Consultant living in Nicaragua and specializing in eGovernment and service-oriented architecture (SOA) systems and solutions. Yves is currently a SOA Certified Professional (SOACP), Consultant, Analyst and Architect. He also acts as the moderator for the LinkedIn group dedicated to the "Prentice Hall Service-Oriented Computing Series from Thomas Erl".
Yves co-authored the Spanish SOA Manifesto and the Spanish version of the Annotated SOA Manifesto. He co-authored, with a group of French and Belgian SOA experts, the French versions of these documents as well. Yves is also responsible for translating the "SOA Principles of Service Design" book as well as the SOA Glossary into Spanish.
Ervin Antonio Mendoza López is a Nicaraguan IT professional working for the Systems Department in the Nicaraguan Energy Institute. He is a researcher in eGovernment and Service-Oriented Architecture (SOA) systems and solution. He authored a master´s thesis titled "Analysis of a Service Oriented Architectural Pattern for Implementing the Administrative Processes of the Nicaraguan Public Administration."
A Standard Design Pattern for eGov Administrative Processes Published: January 20, 2015 • Service Technology Magazine Issue LXXXVIII PDF
Abstract: This publication describes the conception, design, validation and use of a standard common pattern for automating e-Government (eGov) administrative processes and covers the normal common activities of public administrative processes—theoretically of any size—representing an estimated 80% of development requirements. This study was carried out on Nicaraguan Public Administration which manages around 1,200 administrative processes. If 80% of the logic of each of these processes can be automatized with the services proposed pattern, the savings can be considerable.
This study identifies basic services following the mainstream SOA service models: entity, task, orchestrated task and utilities and also identifies two potential new service models, the catalogs and the public IT registries. In addition, it also identifies a new candidate design pattern, the Hybrid Service Inventory design pattern but does not elaborate on it.
With thousands of administrative processes to automate, the public administrations of most e-governments would benefit from a standard, common design for the automation of their administrative processes, particularly if they have adopted SOA and if the pattern is based on a number of reusable and agnostic services, part of a common enterprise-wide service inventory.
Automation of administrative processes typically requires the following steps:
The expected benefits are obvious to all SOA (eGov and not eGov) professionals:
After assessment of multiple administrative processes over several years, a common process model was originally identified, based on some 20 agnostic reusable services. The proposed process and the corresponding candidate services and capabilities were modeled and then submitted to three different institutions of the Nicaraguan government to be applied to one administrative process each.
The processes were then subjected to the previously described reengineering steps and submitted to each institution for review. Although eGov is not yet being implemented in Nicaragua, this was presented to the institutions as a preliminary study to be generalized in the future for the automation of their respective services.
Eventually, the selected administrative processes (criteria for pre-selection are not covered here) were:
The To-Be Activity Model for a Typical Administrative Process
The following activity diagram models common or typical tasks of an administrative process. The "entry" and "do" are actually used to model calls to standard IT services capabilities.
Once reengineered, the proposed (To-Be) model is expected to:
The Common Services Subset (for Administrative Processes)
Task and Orchestrated Task Services
All administrative services end up having one or several task or orchestrated task services. In some cases, the process is simple enough to be executed via an entity service capability—for example, a ReadCurrencyRate—while others can be executed as an online workflow without human intervention, or require an online orchestrated task service. These capabilities are modeled as task services because most actually require multiple activities and tasks for their execution. The standard pattern itself identifies the following common task services:
Entity Services (Including Catalogs)
In most cases, the candidate task or orchestrated task services will match at least one, or many entity services (not listed to reduce redundancy). For example, the Create Online Payment (as a task service) will compose On Line Payment and several others (Citizen Profile, Administrative Transaction, Bank Domiciliation, and the interoperation with the different supported Banking WS wrappers).
However, in addition to the matching duple task service, entity service, a number of additional candidate entity services have been identified:
Above is a total of 18 entity services plus the additional 12 task entities implicit in the 12 task services, which will be needed in the cross domain inventory.
But several additional services (12) have been identified as being in domain inventories, which are not hosted in the cross domain inventory, but are necessary for the process automation. These are:
Domain Task services
Domain Entity services
Altogether, we have now identified 42 IT services which can be used to automatize administrative processes, and also, two new specific entity service models: the catalogs and the public repository.
It is highly probable that, once this pattern is implemented in full scale, many of these services may have to be decomposed, or new ones created.
Utility Services are left out for the purpose of this paper, i.e. IAM, Security Token, Encryption, Hashing, Nonce, Identity Credential, Perimetral Guard, etc. services, that total over 20 security services altogether, but bring the total to more than 60 IT services.
Issues and Findings Raised by this Model
New Service Models
We already mentioned that this model made apparent that eGov needs at least two new service models (and the corresponding layers and SDLC activities). Both have specific requirements for their analysis and design which make them candidates for creating two custom entity service layers:
Public Registries as a Referential Integrity Hierarchical Design Pattern
It has been found quite useful, conceptually, to look at Public IT registries as members of a virtual database, global to the whole public administration, with the same referential integrity rules as those of a physical RDBMS. This creates a natural, logical implementation hierarchy for the services—since they must be implemented according to their public IT registry hierarchy- which is useful for eGov implementation roadmap. It does not make much sense to start an e-Health application if the Public Persons Registry (or something similar) has not been created. This can become quite an issue when stakeholders or decision makers are only interested in the final product and do not want to hear about anything in between.
The Hybrid Service Inventory Design Pattern
This finding arises from the unavoidable necessity of creating an Enterprise Service Inventory to govern all the reusable agnostic services for the public administration but at the same time, acknowledge that each domain (institution) within the e-government could actually benefit from governing its own domain service inventory. The institutions would govern all the services that are actually agnostic to their own domain but non-agnostic to the electronic government cross-domain service inventory. This is basically an attempt at merging both Domain and Enterprise Service Inventories into a third one, which leads to another finding related to the SOA governance model.
The Hybrid SOA Governance Model for Electronic Government
The authors cannot pretend to make a recommendation for electronic government of the size of EU or the US, because of their lack of in-depth familiarity with such complex SOA initiatives. But less complex public administrations (at the state level or for smaller countries) will probably be faced with two options: the SOA Governance Program Office (SGPO) centralized domain and the SGPO federated domain models. A possible solution to this duality would be, again, a (hybrid) combination of both:
This might go a long way to smoothing feathers in the domain IT Offices (or maybe not). In fact, this hybrid SGPO model would actually and logically match the Hybrid Service Inventory design pattern described previously since each type of inventory has to be governed independently.
All four proposed standard services, derived from the common pattern, were assessed as useful and received the grade "To be implemented" by the reviewers in the institutions.
Significant contributions (increase of design quality) were achieved with respect to on-going traditional type developments by applying this and other SOA patterns.
However, even the most sophisticated IT analysts and architects have difficulties designing a To-Be administrative process in the abstract. They tend to limit their comments to limited improvements of the current (As-Is) process and shy from a full scale reengineering.
As Nicaragua is getting close to initiate a completely SOA-based e-Government initiative, we look forward to demonstrating the practical benefits of this pattern and the associated benefits and findings. We know that the implementation of this pattern will need more validation but we hope it will impact favorably reengineering of the Public Administration processes and achieve their alignment with IT Services identified in the pattern and, thus, reduce operating costs and increase efficiency in the Public Administration.
Additional work such as the study of the Hybrid Service Inventory design pattern and its Governance Model may yield additional findings.