Figure 1 Implementation architecture overview
Let us put this architecture in the evolution context. For the long time, e-government implementation architecture was portal-centric and its applications (blue "emabas") were extensions for some internal applications as show in Figure 2.
Figure 2 Implementation architecture – portal-centric stage
The proposed e-government implementation architecture is actually, the introductory architecture which introduces necessary flexibility. E-government applications may span several existing applications as shown in Figure 3.
Figure 3 Implementation architecture – introductory stage
As existing applications are evolving, they will be replaced by processes and services as well thus creating transitional application architecture as shown in Figure 4.
Figure 4 Implementation architecture – transitional stage
With converting all previously monolith applications into processes and services, the target application architecture will be reach as show in Figure 5. E-government applications will be just connections to a cloud of governmental services.
Figure 5 Implementation architecture – target stage
And, moving e-government to the really e-social system, the application architecture will morph into a social cloud interacting with the government service cloud as shown in Figure 6. The latter serves as a platform for social, professional, private, voluntary and other services to be integrated into e-social system.
Figure 6 Implementation architecture – e-social system stage
For existing e-government systems the evolution from the introductory architecture upwards does require primarily the systematic use of BPM and SOA. Green-field e-government initiatives may start from the target architecture.
All stages form a sort of ladder for step-by-step evolution as shown in Figure 7.
Figure 7 Implementation architecture – all stages as a ladder