Yves Chaix

Yves Chaix


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.


rss  subscribe to this author

Ervin Antonio Mendoza López

Ervin Antonio Mendoza López


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."


rss  subscribe to this author


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:

  • model existing—mainly manual—processes (AS-IS),
  • redesign processes (TO-BE) assuming that all required documents can be eliminated by accessing the corresponding public registry as a service,
  • eliminate unnecessary steps—usually the result of manual execution - differentiating simple processes (no human intervention) from complex processes—long-running, manual intervention—and define sub processes for undo or compensation operations,
  • redesign the data to be managed by the new process and make sure it has a legal foundation,
  • identify all adjustments to existing laws or regulations necessary to support reengineering,
  • design and build online user application (and corresponding back-office task list where work flow is used),
  • add all new candidate common public-administration agnostic services in the central, cross-domain eGov service inventory,
  • identify, design and build whatever non-agnostic services is not yet covered by the central common service inventory,
  • design and build whatever public registry is managed by the process, as an IT public registry-type service,
  • design task or orchestrated task service for the execution of the administrative process,
  • apply service-orientation and all governance standards and guidelines,
  • etc.

The expected benefits are obvious to all SOA (eGov and not eGov) professionals:

  • The automation of any administrative process should only require the additional development of the process corresponding task or orchestrated task service, the specific IT public registry and some non-agnostic logic, proper to highly specific or complex administrative processes,
  • All administrative processes will progressively interoperate through their respective IT public registries, freeing citizens from having to act as unwilling messengers between the administrations to hand-carry papers—mainly registry certification—as evidentiary document,
  • Development costs and time-to-market will be considerably reduced and operational agility as well as ROI will significantly increase through the use of public administration-specific agnostic IT services,
  • Common IT services (catalogs, public IT repositories, task and entity services, common to all the administrative processes) will belong to a central unique cross domain service repository, while institutional domains will retain control over their own, non-eGov-agnostic domain inventory, for their local use only,
  • IT-business alignment, federation and interoperability will be considerably increased and—as a whole— eGov will become quite neutral in terms of vendor platform since each institutional domain can continue using its preferred development platform (as long as it allows the institution to interoperate with the public IT registries in the eGov-wide cross-domain service inventory).

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:

  • Persons registry
  • Land property registry
  • Consumers' complaints registry

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:

  • Eliminate the need for citizens to present physical documents since all necessary public IT repositories will eventually be available as services,
  • Increase the benefits to users (for example, by creating a unique Notification service and At Home Delivery administrative units (presently not existing in Nicaragua),
  • Reduce the expected delivery time by reducing development effort mainly to the user front-end app and to the building of the respective public IT repository,
  • Allow on line execution of the automated processes,
  • Allow standardization of all administrative processes architectures.

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:

  • Power of Attorney (Create/Modify/Read/Cancel/Revoke)
  • Administrative Process Catalog (Create/Modify/Read/Suspend)
  • On Line Payment (Create/Modify/Cancel/Revert)
  • At Home Delivery (Execute/Cancel)
  • Administrative Notification (Plan/Execute)
  • Citizen Profile (Create/Modify/Read/Close)
  • Citizen Administrative Record (Create/Update/Read/Close)
  • Notary Registry and Notary Protocol (Create/Add/Read)
  • Administrative Board Sessions (Plan/Execute/Close)
  • Administrative Resolution (Create/Update/Read/Close)
  • On-Site Survey or Inspection (Request/Plan/Execute/Update/Report)
  • Incoming/Outgoing Documents (Create/Receive/Send/Track/Recall)

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:

  • Physical Addresses (not yet implemented in Nicaragua)
  • Evidentiary Document (to support administrative processes)
  • Legal Instruments
  • Citizen Profile
  • Extensions of Public Registry (certification, marginalia, preventive annotation)
  • Administrative Transaction,
  • Bank Domiciliation
  • Process Certifications (administrative products generated by an administrative process)
  • Persons Registry (Physical or Legal)
  • Administrative Organization
  • Professional Activities
  • Reference Data Catalog
  • Geographic Information Catalog
  • Postal Zones
  • Administrative Process Catalog
  • Reference Value Catalog
  • Universal Product Catalog
  • Administrative Banking Domiciliation

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

  • Create Personal Administrative File
  • Manage Paper Personal File
  • Manage Personal File Folio
  • Send Physical Document
  • Receive Physical Document

Domain Entity services

  • Case (as in Administrative Case)
  • Administrative Ruling
  • Administrative Ruling Certification
  • Incoming-Outgoing Document
  • Personal Digital File
  • Field (On-site) Inspection
  • Administrative Decision Session

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:

  • Catalog services: Big unknown as of yet. Most catalogs are actually simple linked lists, others are used to provide reference values for boxes on forms, but all can be managed in one single value validation service, although this solution will obviously create a single point of failure. However, some catalogs have been only partially identified as candidate and have more complex structures, like the administrative structures for all the countries in the world, or a really useful and intelligent product catalog, or the fauna and flora catalogs, the administrative structure of the government, etc. An estimated 10 catalogs per institution leads to some 500 candidate catalogs and possibly many more. Catalogs as a service are specifically designed to be highly intensive in Read and low on Create and Update with no Delete.
  • Public IT registries as a service: We have identified that there are roughly 2.1 administrative processes (Create/Modify and Read) to one Public IT Registry. Our review of the Nicaraguan administrative processes catalog reveals that 1,100 processes manage some 500+ public IT registries. Public IT registries can be quite intensive in Create, Read and Update but normally, in the public administration, do not offer delete, and sometimes not even logical delete. Public IT registries are sometimes aggregated from local government registries (i.e., the Birth registry, or the Land Cadaster). Public IT registries will need frequently to be accessed by domain applications applying a specific Registry Local Cache (new) design pattern, Redundant Implementation, Decomposed Capability and others, to allow administrative applications to operate even if the record cannot be validated in the father-public IT registry (for example, emergency health services which HAVE to be given, even if the patient does not carry or have ID).

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:

  • a centralized SGPO to govern the central cross-domain service inventory for the e-government (which would also govern the domains for those institutions with a low SOA / e-government maturity level) and,
  • a federated SGPO for those domains having reached the required maturity level as defined by the central SGPO.

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.

Other Findings

    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.