1. Jobe Bacwadi is a Senior Manager
for Norms and Standards,
specializing in Software
Development, Architecture and
Standards. He is currently employed
by States Information Technology
(SITA), a public sector company. His
experience crosses private, public
and government sectors.
Jobe has wide range of extensive
experience
from
software
development,
architecture
to
leadership - built from first-hand
experience successfully adapting and
applying frameworks such as COBIT,
FEA, CMMI, TOGAF and more in the
real world!
Email: jobe.bacwadi@sita.co.za
WHEN e-GOVERNMENT IS
NOT e-GOVERNMENT
Author: Jobe Bacwadi
Date:
20 February 2014

2. If the employees still have to capture information from on-line forms
completed by the internet or mobile user, can one really say e-Government has
been achieved?
CIOs who do not see the impact of office work when employees are bombarded with piles and piles
of forms to capture sees only one side of the coin. Historically employees had problems of capturing
piles of forms completed manually, then you can imagines how much piles they will have to deal
with when those forms are completed online. There have also been mistakes of capturing manually
completed forms, then you can imagine how those mistakes can multiply when the piles of forms
have multiplied. In fact in this case one can say e-Government has brought more problems than
solutions. Remember the forms completed on-line are also printed for information capturing into the
database.
What Courses this Problem?
Lack of communication is the main course of this problem. Engagement of relevant stakeholders
who are the custodians or owners of databases. This hits back on leadership:
-
Lack of architecture:
o Developers may have successfully delivered a not so useful product to employees,
and also a useful product on the eyes of internet user who does not know that the
requested service is:
 Probably not captured; or
 Probably lost;
o Without architecture you have obviously not engaged enough on the benefits of the eGovernment application;
o Without architecture you have obviously not engaged with relevant database owners
for automatic capture of data, rather than give employees the task of printing forms
and capture.
 How can we call printing and capturing forms and their data e-Government?
 Printing of these forms may course bottlenecks on capturing (if there are
bottlenecks on manual forms which are usually not so many per day, what
about thousands of expected online forms?).
 Can we be certain that all online forms have their data captured? What
mechanisms does the employee use to make sure all forms are captured?
 How do we answer to the internet user who claims to have completed the
forms yet his/her data cannot be found?
o Without architecture, you have obviously not have agreement on data sharing:
 How can you validate internet user’s information without checking it against,
for example, home affairs?
 Can we agree on data sharing in such a way that when forms are submitted
online then most process will auto-complete?
o Without architecture you have obviously not engaged enough with stakeholders,
industry and research on the knowledge of what exists? What other countries do
about it, etc?
o There are many things that can help with successful e-Government if you have a good
architect.
 Good architect will always help you spend less and achieve more:
 By understanding your vision;

3. 
-
By buying into your strategy and have IT aligned to it:
o Focus on strategy objective, risk and security.
o Define principles for each strategy point. All IT deliverables will
be aligned to these principles, therefore an alignment to
strategy.
o Discuss principles with technical teams. For example, look at
this point in a strategy: “Most of our customers will come from
rural areas and hence we will take advantage of technology”.
The principle matching this strategy could be: “All IT services
are accessible via SOAP and RESTFul”. This principle already,
when discussed with senior developers, gives direction that a
rigid code will not be tolerated. SOAP and RESTful make sharing
of information easier; for example with SOAP or RESTful
information can be easily configured to be delivered via SMS to
reach rural areas.
 Good architect will give you a good architecture document which will
help you reduce costs by:
o Acquiring the right products first time;
o Reduce over-budgeting of projects by delivering the right work
packages in the correct order.
Lack System Architect
o Good system architect should help business achieve more with less. Good system
architect usually focus on the model of systems development below (my examples
are .NET and JEE because I have used them before but other technologies are
available and hence I am not promoting these two):
ORACLE
SQL Sever
JEE or .NET
SOAP or
RESTful
DB2
o In fact the above diagram is where development by experts should end. In this way
we can hire a small number of highly experienced developers just to make services
available via SOAP or RESTful, i.e. to deliver the above model.
o Then we can hire less experience developers to use these SOAP or RESTful services to
create client services like websites, mobile applications and SMS. Developers will tell
you it is easy to create client services rather than to produce them via JEE and .NET.
In fact, according to diagram below, these less experienced developers only see SOAP

4. or RESTful services. A good system architect will separate the SOAP/RESTful
developers from SOAP/RESTful users to deliver client applitions.
Mobile
SOAP or
RESTful
Clients
Developments
Web Browser
Other Devices
What should you do to achieve real e-Government?
Leaders who understand the business strategy and technology are assets to any organization. Such
leaders lead by example. There are a lot of employees who come to work just to earn their salary.
Look at the two side views of an airplane wing below. In View A, the air is flowing nicely over the
wing and the plane will fly smoothly. In View B, some air on top of the wing make a U-turn and
circulates on top of the wing and it will course the plane to stall and eventually crash. This is
because of the positioning of the wing.

5. If a wing represent the leader and airflow represent the employees, the leader in View A uses
his/her technology knowledge to position himself/herself so that the employees can help him/her fly.
The leader in View B lack technical skills and will eventually stall and crash the plane because
his/her positioning has allowed some employees to go in circles (idling).
Hence a knowledgeable leader will align technology to business challenges as the pilot with the
correct skills will be able to align the wings so that the plane can fly. To fly smoothly means you
must engage business on the benefit of the outcome and engage technology on how to realise the
benefits. In the case where the leader engaged only technology then benefits will usually be
assumed. Hence if we look at e-Government from the internet user perspective only then we have it
wrong. The same internet user may have completed the online forms thinking his/her application
went through not knowing that the application is probably not captured or lost.
Recommendation
e-Government is only achievable by employing the right skills who will be able to engage business
on benefits and technology on enablement, i.e. the right skills on all level of architecture, from
enterprise to system, architecture.