E-Tunisia / e-consultations: solution architecture

General

 Continuation from the previous post - E-Tunisia / e-consultations: overview

Definition

E-consultations constitute interactive “tell-us-what-you-think” on-line services where ordinary citizens, civic actors, experts, and politicians purposively assemble to provide input, deliberate, inform, and influence policy and decision making.

Privacy considerations

1. Only authorized person can actively contribute (i.e. add some text) in e-consultation services.
2. The identity of the person may is hidden.
3. The enrollment will include the identity verification.
4. Further a person can hide his/her identity under an avatar.
5. The correspondence between an avatar and the identity is secret, but may be disclosed in case of misbehavior. Example: Facebook.

Nomenclature of e-consultation services

 

Maybe this nomenclature is not full yet.

 

Question and answer discussion forums

It is a free form on-going thematic discussion initiated in a community of interests. Each contribution is named. A discussion may be closed (only within the community) or open for everyone (or even to the Internet). Examples: discussions in Linkedin.

On-line polls

A time-bounded questionnaire.

E-petitions or on-line testimonies

A person (or an association) initiates a formal demand to public services. Such a demand should start a process which should lead to a meaningful response. People, other than the initiator, can express their opinion (support or not) about the demand. Example: Reporting Damaged Roads and Paths https://www.contact.act.gov.au/app/answers/detail/a_id/22/~/reporting-damaged-roads-and-paths

E-panels

A time-bounded nominee-only group open discussion on issues of public interest.

Editorial consultations

A time-bounded multi-authoring of a document or a set of documents. There are several options about who can edit the text. A possible option is that many people can contribute to the content via comments and small (editorial) group can modify the text to reflect those comments.

Use of the e-government platform

E-consultation services are applications implemented on top of the e-government platform (see chapter 5). The latter provides different common services for facilitating the implementation of such application and keeping the same look and feel for better user’s experience. Each application is self-contained, developed in accordance with platform’s rules and may evolve without causing negative effects to others. Number of applications within the platform is not limited.

Enabling the public-private partnership

Systematic approach to very critical IT issues such as authorization, data security, access control, etc. clears a way for re-use of available data. It will be possible to estimate how the disclosure of some of those data will effect to the level of protection of remaining data.

Ability to open some data makes possible to employ private investments for improving some applications (it is considered that all applications are developed mainly by centralized capital investments).

Such investment attraction should be estimated for each application.

The big picture of e-government platform

E-consultation services are e-government services. The e-government (as one of its functions) provides (via ICT) to partners (citizens, enterprises, associations, etc.) the governmental services. To introduce the e-government without disturbances to existing governmental applications, it is proposed to position the e-government is a layer between the partners and the existing governmental applications (as shown in figure below).

The partners-facing part of the e-government is a collaborative extranet which is similar to popular social networking tools (Facebook, LinkedIn, etc.) and e-banking. Its main functionalities are the following:

• secure repository for short messages, documents, and video;
• dedicated (including role-based) information and functionality;
• diverse services as small pluggable applications,
• direct channel to the governmental business processes; and
• unified view of central, regional and local governments.

The government-facing part of the e-government is the integration and coordination capabilities which are necessary to fulfill needs of partners.

Important that the whole e-government is separated from the existing governmental environment. This separation means operational and evolution independence.
The common functionality of the e-government platform is presented below.

Expected advantages:

• Quick implementation
• Easier maintenance
• Explicit security
• Uniformity for the users

Implementation principles

• Keep the conceptual integrity.
• Take into account socio-technical aspects, because how you do something is sometimes more important than what you do.
• Unity the infrastructure and reach different mobile tools
• Systematically use open source software
• Provide security at the level of private banking
• Ruthlessly validate the implementation by international experts and hacker groups and political parties
• Develop agile and deploy step-by-step within the common architecture
• Guaranty the total traceability and records management
• Exchange by electronic documents

Infrastructure implications

To cover the population, it is necessary to establish a network of social computing centres. The latter may be located at local community premises (e.g. a public library, “hotel de ville”, etc.). Those centres may also provide wireless access points.

Possible next actions

1. Validate of this architecture
2. Organise wide consultations with all involved partners
3. Solicit the feedback from international experts
4. Launch the feasibility study

Thanks,
AS

E-Tunisia / e-consultations: overview

Continuation from the previous post - E-government for Tunisia (E-Tunisia) : Help to move forwards

We, the people, are the government

E-consultations constitute interactive “tell-us-what-you-think” on-line services where ordinary citizens, civic actors, experts, and politicians purposively assemble to provide input, deliberate, inform, and influence policy and decision making. E-consultation is complimentary to existing practices.

E-consultations are also more formal and structured than discussions in the informal virtual public sphere. They tend to have a set duration, agenda, employ the use of moderators, with topics for discussion pre-defined by the host.

There are five common types of e-consultations:

1. question and answer discussion forums
2. on-line polls
3. e-petitions or on-line testimonies
4. e-panels
5. editorial consultations

Usual challenges:

1. population coverage
2. integrity
3. visibility
4. transparency and disclosure obligations are vital (with confidentiality only applying on matters of a personal nature)
5. usual distrust towards new electronic applications
6. balance of central and local power

Local challenges:

1. 10 million people
2. huge diversity in education and income
3. political instability
4. lack of a comprehensive Internet infrastructure

Local opportunities:

1. the top African country in the UN e-government study 2010
2. high level of the IT local resources

Solution architecture will be another post .

Thanks,
AS

E-government for Tunisia (E-Tunisia) : Help to move forwards

It has been proven that the deployment of e-government [E-government is the use of information and communication technologies (ICTs) to improve the activities of public sector organisations] brings the following advantages:

• streamlining of the interactions of the citizens and business with the central, regional and local governments;
• increase in the performance of workers at governmental agencies;
• reduction in the possibilities for corruption.

How can an e-government implementation help Tunisia (which is already the top African country according to the UN e-government survey) to move forwards at this moment in its history?

Which e-government services (out of about 1000 items in e-government catalogues) should be the first priority?

Today, it appears that Tunisia urgently needs a much improved handling of political rights, provisioning of social security and, in general, establishment of trust between the population and the public sector organisations. Bearing this in mind, a list of potential e-government capabilities by domain could be the following.

Political domain:

• E-consultation as an umbrella for different means of expressing the voice of the people (similar to direct democracy): e-polls, e-voting, etc.  -- E-Tunisia / e-consultations: overview
• Transparency of the legislative powers (e.g. parliament, deputies, decisions)
• Easy access to the legal knowledge base
• Authorization of demonstrations
• Voting rights (different levels, as well as expatriates)

Social domain:

• Management of who is legible for different types of social support (“welfare”, social housing, etc.)
• Management of correct provision of social support

Citizen-to-government and business-to-government communication domain:

• Transparency of the governmental business processes with respect to promised deadlines, use of objective rules, and traceability of internal work
• Use of electronic means for exchange through secured documents

Potential benefits for African countries:

• Many elements of this e government project will be applicable in many African countries

Potential benefits for donor countries:

• Test some e-government solutions in a green-field project

Potential contribution from the development community:

• Coordination and help with overall architecture / technical solutions

Thanks,
AS

Linkedin: In one word, what is the single largest problem facing #entarch?

A quick statistical analysis of the responses (with some categorization, e.g.” cacophony” -> “chaos” -> “confusion”) in the linkedin discussion "In one word, what is the single largest problem facing Enterprise Architecture?" http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=43593317&gid=36781&commentID=45630743&trk=view_disc

• 373 unique replies from unique people (the first reply is used if not explicitly specified)
• signal to noise ratio is almost 1 to 4

So, a possible resume about the EA status is “immature (discipline, practice, etc.) with problems in many aspects (acceptance, people, tool, definition, etc.) which is requested to deliver results with higher speed”. Maybe executability will help?

Disclose: executability is my choice.

Thanks,
AS

Enterprise patterns: Petit Informaticien (PI) for "What is the key to getting business value from IT?"

As reply to EBIZQ.net question "What is the key to getting business value from IT?" http://www.ebizq.net/blogs/ebizq_forum/2011/07/what-is-the-key-to-delivering-business-value-with-it.php

I use the algorithm or enterprise pattern “petit informaticien” (PI):

-1) learn the big picture
0) prepare an initial set of tools to implement incrementally business solutions within that big picture
1) systematically visit the users (similar to “milking tour”)
2) listen their needs
3) map their needs into the big picture
4) quickly deliver maybe-not-perfect-but-useful business solution
5) get the feedback
6) improve business solutions
7) sharpen tools

Thanks,
AS

Enterprise patterns: CAPS

A quote from my previous blogpost http://improving-bpm-systems.blogspot.com/2011/07/1-relationships-between-enterprise.html about Enterprise Architecture (EA) and cloud computing: Ideally, a cloud-optimised solution is a set of interrelated and interconnected services which are good cloud citizens (or highly cloudable).

This blogpost describes a pattern Cloud-Aware Processes and Services (CAPS) to deliver cloud-friendly solutions instead of monolithic applications. The importance of this pattern is demonstrated by the recent post “All cloud roads lead to applications” http://news.cnet.com/8301-19413_3-20075526-240/all-cloud-roads-lead-to-applications/. This blogpost is based on the materials from my book http://www.improving-BPM-systems.com/book.

BPM helps to deliver cloud-friendly distributed systems

Enterprise BPM systems/solutions (see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html) architected with a multi-layer implementation model (see the figure below) can serve as an example of cloud-friendly distributed systems.

In this model, each layer is a set of services, each of which addresses particular concerns. The services are cloudable.

The business data layer comprises many pieces of information – names, dates, files, etc. – which are stored in existing repositories (e.g. databases, document management systems, web portals, directories, e-mail servers, etc.). Services at this layer are stateless, contain no business logic (although they may contain some access logic) and, usually, co-locate with their underlying databases. They are highly cloudable.

The business objects layer comprises the many objects specific to a particular business, e.g. a business partner, a product, etc. This layer hides the complexity for manipulating the objects, which are actually collections of data together with any dependencies between them. Again, services at this layer are stateless, contain no business logic (although they may contain some technical transformation logic), and are implemented as simple compositions. They too are highly cloudable.

The business routines (or regulations) layer comprises the actions which must be carried out on the business objects to perform the business activities. Services at this layer are stateless and implemented as complex compositions. The latter are defined in a normal programming language (e.g. Java, Python), an interpretive language (e.g. Jython) or, even, in BPEL. A specialised environment (actually a service called a “robot”) may be needed to execute these services, but this “robot” is rather cloudable.

The business execution layer carries out the business processes. The principal service at this layer is a business process execution engine. It executes business processes which are rather explicit compositions (e.g. SAP uses a BPMN subset as a language for executable business processes – see http://improving-bpm-systems.blogspot.com/2011/06/first-impression-sap-netweaver-bpm-tool.html). Any business process execution engine is a stateful service, but each business process instance can be executed independently. Hence, this service is cloudable. Also, business processes are modelled taking into consideration the concept of idempotency (see http://improving-bpm-systems.blogspot.com/2011/07/1-relationships-between-enterprise.html).

The business monitoring layer analyses the execution of the business processes. A large amount of data (events and audit trails produced as the result of execution) is treated to extract any correlations and meaningful information. Services at this layer are both stateful and stateless, but they mainly operate in the “background” and thus are rather cloudable.

The business intelligence layer implements enterprise-wide planning, performance evaluation and control actions applied to the business processes. Services at this layer are cloudable.

A tip to remember the layers is the following: Data, Objects, Routines, Execution, Monitoring, Intelligence – DO-RE-MI.

The multi-layer implementation model and some technologies

The figure below shows the relation of the multi-layer implementation model to some other technologies. Normally, some services are accessible from a portal or workplace. They “float” in an Enterprise Service Bus (ESB). The latter is used only for service-to-service connections at the technical level. Ideally, an ESB should be based on a solid computing basis which can be provided by a grid, modern virtualisation infrastructure or cloud computing.

Extra considerations about the composition of services (or integration)

Some of the services mentioned above can be qualified as compositions of other services. In addition, interactive services from a portal or workspace are also, in general, compositions. For example, a user may invoke different services whilst staying on the same page (thanks to AJAX).
Any composition of services may manipulate business data and thus may disclose them. The following considerations may help to reduce the risks related to data disclosure:

• prefer stateless services for compositions;
• remove the business logic from stateful services (e.g. business execution shall not contain any business logic, only routing logic – follow the practical process pattern DBL, slide 22, http://www.slideshare.net/samarin/towards-executable-models-within-bpm-presentation);
• pass references, not values;
• encrypt data and keep structure in clear text;
• keep robots in the GOLD, ORANGE or GREEN zone types, and be ready to move them to the BLUE zone type (for information about zone types, see http://improving-bpm-systems.blogspot.com/2011/07/1-relationships-between-enterprise.html).

 

To greater agility

The multi-layer implementation model is a tool which helps an enterprise to design process-enabled solutions

• in business terms, but not in terms of IT tools,
• via the combination of services,
• in a structured way, and
• with a high level of built-in flexibility.

In my experience, the multi-layer implementation model and the modelling of executable business processes (see http://www.slideshare.net/samarin/towards-executable-models-within-bpm-presentation) are pillars for agility. Today they can be reinforced by cloud computing, and so it is now possible to achieve synergy (and thus even greater agility) between

• Business Architecture (via BPM and executable business processes),
• Application Architecture (via SOA and the multi-layer implementation model) and
• Technical Architecture (via cloud computing).

And of course, it is the responsibility of EA that all of above-mentioned architectures work together.

Thanks,
AS

Relationships between Enterprise Architecture (EA, #entarch) and #cloud computing

Big picture

The effective use of cloud computing at the enterprise level is a two-way street:

1. the use of cloud should be architected for the needs and realities of a particular enterprise and
2. the application portfolio, technologies, etc. used in an enterprise should be adapted to achieve the full potentials of cloud computing.

In general, EA deals with a system of systems. In general, those systems are distributed – each of them is an interrelated and interconnected set of business artefacts [events, rules, processes, documents, etc.] and technical artefacts [servers, OSes, databases, storage, applications, etc.] spread over the network. With cloud computing, the network become rather versatile (many zones with different characteristics) and transparent (easy to move some artefacts from one zone of the network to another).

Considering that EA knows all artefacts and (ideally all) relationships between them, EA should also know the impact (implementation time, risks, cost, performance, etc.) of particular allocation of some artefacts into some zones to optimise (easy to create, easy to operate, easy to maintain and easy to evolve) the allocation of all artefacts.

A simple allocation model

Let us consider cloud as a set of the following zone types (they are named using different colours):

1. classic on-premises computing centre – zone type GOLD;
2. on-premises private cloud – zone type ORANGE;
3. off-premises and enterprise-managed private cloud – zone type GREEN;
4. off-premises and service-provider-managed private cloud – zone type BLUE;
5. public cloud zone type (off-premises and service-provider-managed by definition) – zone type VIOLET.

Although, some of these zone types (e.g. the VIOLET one) may never exist in a particular enterprise, all of them are listed for completeness. The BLUE and VIOLET zone types are built with a set of trusted service providers. The term “zone types” is used because an enterprise may have several zones of the same type (e.g. more than one provider for VIOLET zones).

The allocation of artefacts to zone types is governed through a decision framework which provides a set of rules for putting a particular artefact into a particular zone type. See http://improving-bpm-systems.blogspot.com/2011/12/enterprise-pattern-cloud-ready.html

Practically all artefacts may be in any of these zone types. During the continuous virtualisation of technical artefacts, almost all of them may be moved from the GOLD to ORANGE and GREEN zone types and then to the BLUE and VIOLET zone types. Artefacts, like applications, may be transformed before the move or not.

The decision framework takes into account factors such as

• data sensitivity,
• security of data,
• network latency,
• the intensity of use,
• artefact architecture,
• the technologies involved,
• dependencies between services,
• SLAs,
• BCDR requirements,
• the existing zone (including its operating cost and risks),
• the target zone (including its operating cost and risks),
• the cost of moving,
• etc.

Also, the decision framework reflects the business strategy, e.g. an organisation which anticipates a rather aggressive decentralisation shouldn’t promote the use of the ORANGE zone type.

The artefacts (business and technical) mentioned above are actually services which implement related artefacts, and sometimes there is a trivial dependency between business and technical artefacts. For example, business documents (business artefact) are implemented by Enterprise Content Management (ECM) services (technical artefacts) which require a database, file storage, application server, backup, monitoring, etc. (technical artefacts).

Services are useful for building cloud-optimised solutions

Ideally, a cloud-optimised solution is a set of interrelated and interconnected services which are good cloud citizens (or highly cloudable). In reality however, there are still many classic monolithic applications which are actually conglomerates of many potential services and therefore it is not easy to evaluate how cloudable they are. For this reason, any approaches for replacing monolithic applications (existing and/or new) by coordinated sets of services are very welcome. Some of the related concepts are mentioned below.

Services (defined as explicitly-defined and operationally-independent repeatable units of functionality that create a particular result) and, especially, stateless services are the best candidates for clouds (i.e. they are highly cloudable) – just add more instances but be careful about dependencies.

SOA (defined as an architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services) is a way of thinking in terms of services (e.g. large, more functional, services are assembled from small, less functional, ones).

Enterprise Service Bus (ESB) is the best way to provide universal connectivity (mentioned in the previous paragraph). But, it is necessary to avoid trying to solve all integration problems with an ESB – see http://www.slideshare.net/samarin/example-use-of-bpm-to-monitor-an-esbcentric-integration

Idempotency (defined by Wikipedia as the property of certain operations to be applied multiple times without changing the result) applied to services helps to build reliable compositions of services – see the IRIS pattern from my book. Recently, the power of idempotency was demonstrated in April’s AWS issue – see http://www.twilio.com/engineering/2011/04/22/why-twilio-wasnt-affected-by-todays-aws-issues/. Also, note that the SAP BIT420 training course has an example of idempotent services.

The functioning of any enterprise is the coordination of many activities (human and automated) – see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html. Considering that the majority of those activities are actually invocations of services, it is possible to say that the functioning of the enterprise is the coordination of many services via different techniques: token-based, rule-based, event-based, data-based, manual-based, etc. If all coordination is made explicit (via BPM), this will provide the necessary information about all static and some dynamic relationships between services.

Typical questions about cloud computing

The following provides a typical list of enterprise-wide concerns relative to cloud computing.

• How can we know if cloud computing is even appropriate for our company?
• Which systems, applications and business processes are the best candidates for cloud outsourcing?
• How can we effectively manage the interrelationships between systems, business processes and data we want to outsource with those that will remain in-house?
• What would be the most effective cloud configuration for our company (private, public, hybrid, community, etc.)?
• How do we protect sensitive agency data in the cloud?
• How do we comply with industry records management requirements in a cloud environment?
• What’s the best way to assess and manage our company’s risk profile in a cloud environment?
• What are the actual costs of our IT operations today? What cost savings can be expected by transitioning to cloud computing?
• How well are our current corporate IT investments performing? What performance improvements are possible in a cloud environment?
• Where do we start? What are the steps to get from where we are today to a cloud environment?

It is clear that the simple allocation model (in which the decision framework is filled by your rules) and the ability to deliver solutions as a set of services will be of considerable help to address systematically those concerns.

Thanks,
AS