Portal Guidelines v1_CD

Document Sample
Portal Guidelines v1_CD Powered By Docstoc
					Standards, Policies
and Guidelines -
Portal Guidelines


Version 1.0

August 2003
Standards, Policies and Guidelines -
Portal Guidelines


TABLE OF CONTENTS

1   INTRODUCTION                                                                                                                      3

     1.1 Objective .................................................................................................................. 3

     1.2 Scope ........................................................................................................................ 4

2   PORTAL OVERVIEW                                                                                                                   5

     2.1 What is a portal and why do we need one anyway? .................................................. 5

     2.2 Key Features of a Portal ........................................................................................... 6

3   PORTAL ARCHITECTURES                                                                                                              9

     3.1 Introduction ............................................................................................................. 9

     3.2 Thin Clients.............................................................................................................10

     3.3 Remote Method Invocation (RMI) Clients...............................................................12

     3.4 Fat Client.................................................................................................................14

     3.5 Cross between Clients..............................................................................................15

4   SOLUTION PLANNING                                                                                                                17

     4.1 Types of Portals.......................................................................................................17
          4.1.1 Government to Citizens (G2C)                                                                                         17
          4.1.2 Government to Businesses (G2B)                                                                                       18
          4.1.3 Government to Employees (G2E)                                                                                        18

     4.2 Requirements of the Different Types of Portals.......................................................19

     4.3 Information Sources and Connectors ......................................................................23

     4.4 Portal Client and Server Application.......................................................................26
          4.4.1 Client Hardware                                                                                                      26
          4.4.2 Client Software                                                                                                      27
          4.4.3 Network                                                                                                              28

     4.5 Which portal approach is most appropriate for me?...............................................29
          4.5.1 Build it yourself                                                                                                    29
          4.5.2 Using portal software                                                                                                29



File name: Portal Guideline
Version 1.0                                                                                                               Page 1 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


          4.5.3 How to select a portal solution                                                                                   30

5   SECURITY CONSIDERATIONS                                                                                                       32

     5.1 Authorisation...........................................................................................................33
          5.1.1 Authentication                                                                                                    33
          5.1.2 Access control                                                                                                    36

     5.2 Asset protection .......................................................................................................36

     5.3 Accountability .........................................................................................................38

     5.4 Assurance ................................................................................................................38

     5.5 Availability ..............................................................................................................39

     5.6 Suggested Security Checklist...................................................................................40

6   MANAGEMENT OF THE PORTAL                                                                                                      42

     6.1 Challenges for the Management ..............................................................................42
          6.1.1 Strategic Tasks                                                                                                   43
          6.1.2 Site Management Tasks                                                                                             44
          6.1.3 Content Tasks                                                                                                     45
          6.1.4 Auditing and Maintenance Tasks                                                                                    46

     6.2 Electronic Publishing...............................................................................................48
          6.2.1 Content Generation                                                                                                48
          6.2.2 Online Publishing Tools                                                                                           48

     6.3 Branding .................................................................................................................49

7   SUMMARY                                                                                                                       50

8   GLOSSARY OF TERMS                                                                                                             51




File name: Portal Guideline
Version 1.0                                                                                                             Page 2 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    1       Introduction

            This document consists of a set of guidelines regarding the development of
            portals for the use, management and technical staff.           This document has been
            produced to support the initiatives identified in the ICT Strategic Plan for the
            Malaysian Public Sector.


            The contents of this document was achieved through the consolidation and
            references of materials published by various e-Government units around the
            globe.


    1.1     Objective


            The objective of this document is to create a greater awareness in agencies of
            the various components that form portals. It also aims to create a thought
            process in the initial stages when a portal solution is being considered.


            These guidelines are intended to deliver the strategic thrust stated in the ICT
            Strategic Plan where government information and services should be of a high
            quality, easy to use and inclusive. These information and services should be
            presented from single point. Although content and presentational style may
            vary greatly, but that basic technical features and good management practice
            should not.


            Agencies should be accountable for their adherence to the guidelines, and
            where necessary justify any deviation. Compliance with the guidelines should
            be subjected to reviews.




File name: Portal Guideline
Version 1.0                                                                             Page 3 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    1.2     Scope


            In adopting these guidelines, agencies should be aware of the following
            objectives:
            •   Electronic publishing via the Internet should be placed alongside other
                media as a means of providing information and services to the public,
                including citizens and businesses. This implies that the senior management
                of the various agencies should ensure that the necessary skills for
                professional   electronic   publication   are   identified    and   the   necessary
                resources are provided. Issues relating to publication on the Internet should
                be addressed with the same attention as publication on traditional media.
                There should be clear identification of responsibilities for ensuring the
                accuracy, legal compliance and currency of information on Public Sector’s
                government web-sites;
            •   There could also be requirements for content, including the need to comply
                with cross governmental policies on various information and publishing
                issues;
            •   There should be consideration for publication format as there should
                generally be inclusive as possible. This means having full regard for the
                fact that many users might be accessing sites using relatively old equipment
                or low bandwidth and may have a visual or other disability;
            •   Pages that make up the portal should be as convenient and easy to use as
                possible. They should be designed in such a way as to minimise download
                times wherever possible, and should take full account of the different levels
                of competency which members of the public may have reached in use of the
                Internet. Agencies should continuously study the user requirements and be
                aware of how best to provide their information and services best; and
            •   Government sites should be identifiable as such and should be properly
                linked together.




File name: Portal Guideline
Version 1.0                                                                               Page 4 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    2       Portal Overview

            A portal provides a single point of access to diverse information and
            applications, secure interactions, a customisable interface, personalised content
            and much more. Many portals exist, including enterprise information portals,
            business-to-business    marketplaces,     employee   workspaces and public Web
            portals. Regardless of the type of portal in use, the general requirements for all
            portals are the same. All portals require:
            •   A scalable infrastructure that can change with business expansion;
            •   A flexible and powerful presentation framework that produces an aesthetic
                interface; and
            •   A framework on which to build portal components easily.


    2.1     What is a portal and why do we need one anyway?


            A portal is a tool for managing a company's intellectual assets, it's information
            content, and it’s data. It takes this huge, largely unmanaged, mishmash of
            information and organises it, categorises it, personalises it, and then presents it
            to you at the right time and in the right context.


            For example, if you need information on one of your customers, you should be
            able to see all of the information that is relevant for you in one concise
            location. You shouldn't have to search through multiple systems such as an
            accounting package or a contact manager, or sift through paper documents and
            your file server just to find the things that you need. They should be organised
            and presented to you when it is most appropriate.




File name: Portal Guideline
Version 1.0                                                                          Page 5 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    2.2     Key Features of a Portal


            Portal software come in so many forms, shapes, and sizes that we felt it is
            important to do some level setting.         It should be made clear that most portal
            solution does not provide all of the features listed but it is good to ensure that
            as part of your portal solution contains most of it. We have categorised and
            listed some of the features typically found in a portal:
            •   Personalization
                  - Preferences
                  - Push-pull based information (subscription)
                  - Events
                  - Filters
                  - Personal profiles
                  -   Customisation
                           § Visual views
                  - Behaviour analysis
                  - Proactive help
                  - Suggestion learning
            •   Categorisation
                  - Organising taxonomy
                  - Index-crawl
                  - Auto classify
                  - Summarise
                  - Clustering
            •   Extraction
                  - Feeds
                  - Hubs
                  - Metadata manager
            •   Search
                  - Federated search
                  - Concept based


File name: Portal Guideline
Version 1.0                                                                           Page 6 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


                  - Content mining
                  - Full text
                  - Connection to:
                          § Structured data
                          § Unstructured data
                          § Business intelligence
                          § External content
            •   Applications
                  - Application components
                  - Line of Business applications
                  - Horizontal applications
                  - Custom applications
            •   Collaboration
                  - Community knowledge exploitation
                  - Asynchronous Personal Information Manager
                  - Synchronous Personal Information Manager
                  - Centralised repositories
                  - Distance learning
            •   Transaction
                  - Transaction management
                  - Workflow
            •   Common Core Portal Services
                  - Single sign-on
                  - Directory integration
                  - Security
                  - Access control rights
                  - Secured delivery
                  - Authentication
                  - Permissions
                  - Administration




File name: Portal Guideline
Version 1.0                                                     Page 7 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            The list above highlights the more common areas under the portal heading.
            Newly discussed areas such as integration of pervasive devices have are not
            covered here.




File name: Portal Guideline
Version 1.0                                                                   Page 8 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    3       Portal Architectures


    3.1     Introduction


            It is important to select and understand the right architecture to drive the
            portals. The selection of the right architecture allows effective and efficient
            connection from client to back end servers.


            This section describes the different ways in which portals can be configured
            based on business case requirements, the advantages and disadvantages of each
            configuration, and the selection process that leads to a certain configuration.


            The first step in the decision finding process for a business case is to decide on
            the portal’s configuration. The selection of the portal’s configuration is further
            based on the type of client selected to solve a business case requirement.


            The type of client selected can also depend on different criteria for a specific
            business environment, such as:
            •   Topology strategy of the enterprise;
            •   Number of connections to deploy;
            •   Number of different file formats to display;
            •   Workstation capabilities (hardware prerequisites);
            •   Number of back end systems; and
            •   Number of back end systems to be accessed by an individual user at one
                time.


            The following types of portal configuration for clients are available:
            •   Thin clients;
            •   Remote Method Invocation (RMI) clients;
            •   Fat clients; and



File name: Portal Guideline
Version 1.0                                                                                   Page 9 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •   Cross between clients.


    3.2     Thin Clients


            The easiest way to deploy an application for a large number of clients is to
            develop an application that runs on a Web browser. The Web application can
            be either a Java applet or an application with pure HTML output using a Web
            Application Server.


            The benefit of the Portal thin client is the fast deployment of the client, where it
            only requires the installation of a Web browser (which guarantees platform
            independence). Additional viewers to display the content of the back end
            systems may still be needed if the process of converting images does not take
            place on the Web server or middle server.


            The thin client does not have to be directly attached to the LAN where the back
            end systems reside. It only needs a reasonable network connection bandwidth
            to connect to the application server that should be located near the back end
            systems.




File name: Portal Guideline
Version 1.0                                                                          Page 10 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            A simple scenario could look like the one in the diagram below.

                                        P r e s e n t a t i o n




         B u s in e s s            L o g i c   a n d        B a c k e n d       C o n n e c t o r s




                                      B a c k e n d          S y s t e m    s



                                                      r d
                   S e r v e r s                  3         P a r t y       C o n t e n t   M a n a g e r



                                                Diagram 1


            The client only talks to the Application Server, which does either a federated
            search or a query to a specific back end system through the connectors where
            usually provided by most portal based solutions. With a custom written
            connectors, various back end databases and application can also be an integral
            part of the query.


            This configuration reduces the communication protocol to HTTP between the
            client and the application server. Which means that the clients can easily be
            separated from the critical resources with a firewall.


            Having all the client’s requests handled by one application server, it can be a
            bottleneck, and it may be necessary to have load balancing implemented at the
            server side.




File name: Portal Guideline
Version 1.0                                                                                  Page 11 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    3.3     Remote Method Invocation (RMI) Clients


            A Remote Method Invocation (RMI) client has no runtimes installed locally. It
            depends on the middle layer server(s). An RMI server is needed to connect the
            workstation to the back end systems. The RMI allows the client to call runtimes
            on the RMI server as a result it provides an opportunity to share common
            runtimes.


            It should be noted that if your client application is not written in Java you
            couldn’t use the RMI configuration. As most solution vendors offer Java based
            solutions, it is possible to apply this technique without locking onto a specific
            vendor.


            RMI enables the programmer to create distributed Java technology-based
            applications, in which the methods of remote Java objects can be invoked from
            other Java virtual machines, possibly on different hosts.


            A Java technology-based program can make a call to a remote object once it
            obtains a reference of the remote object, either by looking up the remote object
            in the bootstrap naming service provided by RMI or by receiving the reference
            as an argument or a return value.




File name: Portal Guideline
Version 1.0                                                                       Page 12 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




                                       Presentation




               Business Logic and Backend Connectors

                                                                  R u n t i m e / P r o g r a m s




                                     B a c k e n d S y s t e m s



                                                 3   rd   Party
                       Servers                                           Content Manager




                                              Diagram 2


            The benefit of having a RMI client is the centralized approach of keeping the
            required runtimes on middle servers instead of installing runtimes on each
            client that needs to access the application. The RMI client just needs to know
            which RMI server it should talk to when an EIP request is submitted.


            For occasional search requests, the RMI client configuration with a single mid
            level server is acceptable, but for high volume requests you should consider a
            more involved middle level environment.




File name: Portal Guideline
Version 1.0                                                                                 Page 13 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    3.4     Fat Client


            A fat client runs independently of the middle tier server. All the necessary back
            end system runtimes, including the federated runtimes, are installed locally and
            the client accesses the back end systems directly.


            Therefore, it does not use the RMI server and depends on the portal runtimes
            installed on the client itself. For federated searches, it uses the local federated
            layer. Whenever a new system is added to the back end systems or an existing
            runtime is upgraded, all the clients have to be updated with the new and
            modified runtimes.



                                             P r e s e n t a t i o n




               B u s i n e s s           L o g i c   a n d       B a c k e n d             C o n n e c t o r s



                                                                             P o r t a l   A d m i n i s t r a t i o n


                                            B a c k e n d          S y s t e m s



                                                        3   rd   P a r t y             C o n t e n t     M a n a g e r
                         S e r v e r s



                                                     Diagram 3


            The most beneficial reason for this type of fat client configuration is to improve
            response time, because the middle tier server is omitted. The clients may
            require large or faster hardware configurations, and should have a reasonable
            network bandwidth to the back end systems and the portal database server.




File name: Portal Guideline
Version 1.0                                                                                                 Page 14 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    3.5     Cross between Clients


            The cross between clients is a mixture of the RMI client and the fat client. A
            mixture of RMI client and fat client is used when some back end systems are
            connected through a RMI server, and the other back end systems are connected
            directly from the client.

                                          P resentation




             B u s i n e s s L o g i c a n d B a c k e n d C o n n e c t o r s

                                R u n t i m e / P r o g r a m s

                                                                      Portal Administration


                                          B a c k e n d S y s t e m s



                                                     3   rd   Party
                       Servers                                             C o n t e n t M a n a g e r

                 Fat Client                         R M I


                                                 Diagram 4


            The above diagram demonstrates that the 3rd Party application and databases
            are connected through the use of a RMI client and the other servers are
            connected via a fat client.


            The first question that may come to your mind is when would I need to do this?
            The combination of RMI client and fat client makes sense:
            •    When the client installs the objects for accessing back end systems, and
                 uses the RMI client for objects that are seldom used
            Or




File name: Portal Guideline
Version 1.0                                                                               Page 15 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


        •     When the client is separated physically from some of the back end systems
              and there is a requirement to reduce the amount of stations that need to be
              connected to the WAN.




File name: Portal Guideline
Version 1.0                                                                    Page 16 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    4       Solution Planning


    4.1     Types of Portals


            A portal application can be classified into one of the three types of portals they
            are:


    4.1.1   Government to Citizens (G2C)


            G2C portals connect the government with their customers. Government could
            use portal technology to combine content, commerce, and community for their
            customers to provide easy of use.


            Many eCommerce sites transition from pure commerce sites to portals by
            integrating related information and applications to attract and retain customers.
            One kind of the G2C portals is the emerging CRM self-serving portals that
            allow customers to get information about them and to manage them. The G2C
            portals offer the following benefits to both government and citizens:
            •      Attract and retain users by delivering integration and convenience on
                   information access that relates to the customer activities with the
                   government;
            •      Increase user satisfaction and maintain customer relationship by integrating
                   citizen relationship information with government services and information
                   offerings; and
            •      Provide increased convenience to citizens via multiple access channels like
                   Internet and call centers, and via integrated views and access to users’ own
                   account information.




File name: Portal Guideline
Version 1.0                                                                         Page 17 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    4.1.2   Government to Businesses (G2B)


            The G2B portals focused on providing close integration with businesses.
            Electronic Market makers like e-Marketplace, e-Exchange, and many auction
            sites and services falls under this category. The G2B portals aim at streamlining
            the business processes and transactions between government and businesses,
            and increasing the efficiency.      They serve as central hubs for institutional and
            business exchange transactions when dealing with the multiple government
            agencies. G2B portals offer the following benefits to the government and
            businesses:
            •   Streamlined business processes and efficiency between the government and
                businesses (e.g. taxation, licensing etc.);
            •   Provide increased convenience to businesses via single point of contact
                achieved through the integration of the various agencies operations; and
            •   Increase return on investment for both government and businesses through
                the exchange of timely information between the two parties.


    4.1.3   Government to Employees (G2E)


            G2E Portals are a kind of fast emerging portals that targets the government
            employees.     A large amount of information, business processes and procedures,
            and applications exist in the government today. Capturing, sharing, organising,
            searching     for    information,   and   integrating     the    business   processes   and
            information are the requirements for the G2E portals. G2E portals offer the
            following benefit to the Government and their employees:
            •   Leverage        knowledge   within    the     organisation   by   sharing   information
                resources;
            •   Provide unified business views of information and data;
            •   Integrate business processes and procedures, and applications;
            •   Provide employees with organisation tools and environment for their daily
                work and life, for example, a Human Resources portal;


File name: Portal Guideline
Version 1.0                                                                                 Page 18 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •   Increase return on investment by delivering information and applications to
                be better used by their employees; and
            •   Pull expertise within an organisation through collaboration, filtering, and
                advanced information mining.


    4.2     Requirements of the Different Types of Portals


            The three types of portal applications have distinct requirements. These
            requirements can be addressed by the following dimensions:
            •   User and Applications – defines the type of users that will be for the
                specific type of portal and the applications they will look for.
            •   Access point and client type – address the access methods that the users
                will use to obtain information and services and the type of application or
                software that they will be using.
            •   Information sources and applications – the nature of information that the
                users will be looking for through the portals.
            •   Security and Availability – addresses the basic security and availability
                each type portal requires.
            •   Size and Performance – defines the estimates of size the and the
                performance requirements of each of the different portals.
            •   Portals Capabilities – address the basic capability of the portals from the
                perspective of the different types of users.


            The table below outlines these dimensions of the business requirement for each
            kind of portal application.




File name: Portal Guideline
Version 1.0                                                                        Page 19 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




                         G2C                     G2B                   G2E
  Users and              • Customers of a        • Business entities   •   Corporate
  applications             corporation or          logistics and           employees and
                           service                 procurement             business partners
                           organisation          • Buyers and
                         • Customer                suppliers
                           relationship          • eCommerce
                           applications            transactions
                         • eCommerce
  Access point and       • Via internet using    • Via VPN over        •   Via corporate
                           web browsers            Internet                intranet
  client Type
                         • Different levels of   • Mostly Web          •   Web browsers
                           browsers                browsers                clients
                                                 • Same levels of      •   Same level
                                                   Browsers                browsers
  Information            • Product and           • Product catalog     •   Large amount of
  sources and              services related        eCommerce               heterogeneous
                           information           • Transactional           information
  Applications             sources               • Involving               sources
                         • Media libraries         multiple business   •   Search
                           online content          entities            •   Update
                           services                                    •   Sharing
                         • eCommerce
                           involving
                           customer and one
                           corporation


                                           Table 1




File name: Portal Guideline
Version 1.0                                                                      Page 20 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




                              G2C                     G2B                      G2E
  Security and                • Require network       •   Require network      • Corporate
  Availability                  security                  security               intranet
                                (firewalls) to            (firewalls)            security
                                protect the portal        protect the portal   • User and group
                                site from illegal         site from illegal      level Access
                                access                    access                 management
                              • Require strong        •   Require strong       • Availability
                                encryption to             encryption to          requirement
                                protect customer          protect customer       differs on
                                privacy                   privacy                different
                              • High availability -   •   Regular business       information
                                24 hours / 7 days         hour availability      sources
                                                          is minimum
  Size and                    • Most corporate        •   Small to medium      • Small to
                                portals have small        number of              medium
  performance
                                to medium                 concurrent users       number of
                                number of                                        concurrent
                                concurrent users                                 users
                              • Some large                                     • Performance
                                pervasive portal                                 requirement
                                services, like                                   differs by
                                news and stocks,                                 applications
                                have large
                                number of
                                concurrent users
                                and require fast
                                response times


                                        Table 1 (continued)




File name: Portal Guideline
Version 1.0                                                                          Page 21 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




                         G2C                   G2B                 G2E
  Portal Capabilities    • Navigation/Presen   • Transaction       •   Navigation/
                           tation                mgmt.                 Presentation
                         • Personalization     • Auction support   •   Personalization
                           Profiles-based      • Catalog service       o Profiles-based
                           Rules based         • Navigation            o Rules based
                           observation         • Notification          o Observation
                         • Application         • Workflow          •   Notification
                           integration           integration           o Events
                         • Search                                  •   Workflow
                         • Syndicated                                  integration
                           content                                 •   Application
                         • Transaction                             •   Integration
                           mgmt.                                   •   Collaboration
                         • Catalog service                         •   Index-crawl
                         • Support of                              •   Aggregation
                           pervasive devices                       •   Search
                           like cell phones                        •   Cluster/
                                                                       categorize
                                                                   •   Information
                                                                   •   Connectors
                                                                   •   Syndicated
                                                                       content


                                   Table 1 (continued)




File name: Portal Guideline
Version 1.0                                                                 Page 22 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    4.3     Information Sources and Connectors


            Content servers are the information sources for a portal solution. The content
            servers and applications must be identified and documented. This includes the
            back-end server platform, server name and configuration, access control, and
            storage format. The business actions taken on the content must also be
            identified. This includes search requirements, update capability, and parameters
            for the actions.


            The connectors will be needed to achieve the connection to the back-end
            servers.    Connectors   can   be   defined     software   component   that   enables
            transformation of information from one system to another, resulting in two
            systems communicating. In this case the systems that hold the information
            sources with the portal solution. When connectors are installed on the local
            machine, they are called local connectors. However, when the connector cannot
            be installed on the local machine, it can be configured to access a connector
            located on another machine. These connectors are called remote connectors.


            The objective of these connectors is to obtain support from the back-end. Some
            solutions have their own connectors that ease the information flow from the
            information sources


            An understanding the characteristics of each connector is important, as it
            provides the basis of delivering the portal services. The following table aims to
            briefly describe what connectors should be used for the required type of
            services.


            Words of caution, what is described are some of the basic portal services, for a
            complete portal solution that meets business requirement a detail portal
            requirement study must be conducted. The result of the study would provide a
            clear view of what connectors will be needed.



File name: Portal Guideline
Version 1.0                                                                          Page 23 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



       Portal Services                                  Connectors that could address need
       Connection to back-end servers                   Will depend on the solution adaptors/
                                                        connectors.
           • Content Manager family of                  Portal Software should have ability to
             servers                                    connect to Back-end either natively or
          • Information Catalog                         remotely
          • Extended Search servers
          • Document Managers
       Remote administration configurations             Administration database and
       connections to back-end servers                  administration adaptors/connectors


       Administration of users and privileges,          Administration database and
       and user mapping for back-end servers            administration adaptors/connectors
       Mapping of back-end server entities to           Administration database and
       federated entities                               administration adaptors/connectors
       Federated parametric searching against           Administration database and
       multiple back-end servers                        administration adaptors/connectors
       Support of multimedia content                    Content viewers connectors/adaptors and
       conversion, viewing, and streaming               OOAPI (Object Oriented Application
                                                        Program Interface)


                                              Table 2




File name: Portal Guideline
Version 1.0                                                                              Page 24 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




       Portal Services                             Connectors that could address need
       Text Search using linguistic search         Text Search server and
       against content manager                     Adaptors/Connectors
       Image search against Content Manager        Image search server and
                                                   adaptors/connectors
       Document oriented workflow                  Adaptors/connectors to a Workflow
                                                   Software
       Categorization, summarization, and          Information Mining adaptors/connectors
       advanced text search using n-gram           abilities
       methods on all federated content servers
       Web crawling, indexing, and searching       Information Mining adaptors/connectors
       of intranet Web sites                       abilities
       Searching internet through Web search       Extended Search adaptors/connectors
       engines                                     which may require extended Search
                                                   servers which usually not packaged with
                                                   most portal software packages
       Searching against file systems on LAN       Extended Search adaptors/connectors
                                                   which may require extended Search
                                                   servers which usually not packaged with
                                                   most portal software packages


                                      Table 2 (continued)




File name: Portal Guideline
Version 1.0                                                                        Page 25 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    4.4     Portal Client and Server Application


            Portal solutions typically use a multi-tier Client/Server architecture. Both the
            client program and the server application can be developed using a variety of
            technologies and languages ranging from Java, C++, and ActiveX.              Client
            access to portal services can be classified into the categories (i.e. G2C, G2B,
            G2E) defined Section 4.1.


            The choice of the portal client and server application is based on the audience
            of the portal, the complexity of the solution, and the requirements for security
            and support.


            These different types have distinct requirements on the client and servers. This
            will have impact on customers and government agencies. The following
            sections and tables will outlines these differences.


    4.4.1   Client Hardware


            This deals with the hardware components on the user end. The selection of the
                                                           n
            type of architecture should consider the followi g.


     Component                Thin Client             RMI Client           Fat Client
     PC Hardware              Minimum as long         Large enough to      Large enough to
                              web browser can         run a few programs   run the client
                              run                     required by the      programs required
                                                      web-server/middle    by the server
                                                      layer servers        applications

                                                 Table 3


            The selection of the type of portal architecture should take into consideration
            the capability of the hardware components. There are instances where users are




File name: Portal Guideline
Version 1.0                                                                         Page 26 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            unable to up-grade their hardware to receive the information and services
            provided, hence the best option will be the thin client. There are also instances
            where security and point-to-point connectivity is a major concern, hence fat
            client will be the option.


    4.4.2   Client Software


            This addresses the software elements that are present in the user-end (i.e.
            Citizens, Business, Employees). Therefore to achieve the result of the listed
            components the requirements of the architecture are as follows:


       Component               Thin Client            RMI Client              Fat Client
       User Interface          Standard Web           Standard web            Custom built
                               Browsers               browsers plus           with graphical
                                                      additional runtimes     interface and user
                                                      programs                libraries
       Document                If no special viewer   If no special viewer    Document
       Viewing                 is used, the server    is used, the server     conversion in the
                               must know how to       must know how to        client for viewing
                               convert the            convert the
                               document for           document for
                               viewing in the         viewing in the
                               browser.               browser.
                               Use of a special       Use of a special
                               browser                browser plug-in
                               plug-in can speed      can speed up the
                               up the                 viewing but
                               viewing but            requires
                               requires               administrative
                               administrative         work
                               work



                                                 Table 4




File name: Portal Guideline
Version 1.0                                                                            Page 27 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    4.4.3   Network


            This addresses the connectivity that exists between the information provider of
            information and services (i.e. government) and the recipients (i.e. citizens,
            businesses and employees). Hence it is important to consider the implication of
            the architecture has on the network components. As these components will play
            an important role in the effective delivery of information and services to the
            users.


       Component              Thin Client            RMI Client          Fat Client
       Protocol and           HTTP protocol is       TCP/IP is the       TCP/IP is the
       Middleware             the minimum no         minimum, will       minimum,
                              additional             depend on the       special
                              middleware             runtime programs    middleware is
                              required               installed at the    often required,
                                                     web/application     for example
                                                     servers.            database
                                                                         adaptors
                                                                         connection to
                                                                         the back-end
                                                                         databases
       Connectivity           Only direct            Only direct         Direct
                              connection to the      connection to the   connection to
                              web server             application/web     the back end
                                                     servers             servers required

                                                  Table 5




File name: Portal Guideline
Version 1.0                                                                       Page 28 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




    4.5     Which portal approach is most appropriate for me?


            Some of the approaches in implementing portal solutions are:


    4.5.1   Build it yourself


            This method is best used when the interface needs are not complex or not user
            configurable. This is a relatively inexpensive approach if similar interface will
            are used for all users. What users see, are primarily filtered, based on an access
            control rights, not by screen element selection.


            Once these basic features of a portal have been formalised, building the portal
            on your own will be a bit more expensive.           It is suggested that agencies and
            departments focus on utilising the off-the-shelf software.


    4.5.2   Using portal software


            Utilising portal software is an excellent way to add features with significant
            value and, typically a value for price. It is impossible to develop the features
            provided by these products for anywhere near what they will cost you to
            purchase and implement. The key is finding the product with the right fit, so
            you are not paying more for features that you do not need.


            The market is full of portal software providers. Unfortunately, only a few will
            survive the fight for market share. Therefore, it is essential that you chose the
            right vendor and software platform. The key factor is that to ensure that the
            solution have the following key capabilities:
            •    Personalisation;
            •    Layout management with a dynamic drag and drop Web based interface;
            •    Configuration management;


File name: Portal Guideline
Version 1.0                                                                           Page 29 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •    Content management;
            •    Subscription services to content providers;
            •    A very flexible and extensible development environment; and
            •    Integration capabilities to existing databases.


    4.5.3   How to select a portal solution


            To select a portal solution, it is essential to look at the companies’ track record
            and also to get clarification on these questions:
            •    How many installations do they have?
            •    How big are the installations?
            •    Does it use open standards?
            •    Does it use our company standards?
            •    Does it integrate with a standard directory service?
            •    How well does their product integrate with the solutions from commonly
                 used software packages?
                     o Does it integrate with their products?
                     o Can it utilize their APIs?
            •    Does it have the features we need now?
            •    Does it have the features we will need in the future?
            •    Is the product forward thinking? Will its direction support our needs into
                 the future?
            •    Is the future direction of the product aligned with that of the company?
            •    How difficult is it to extend the solution with custom programming?
            •    Does it provide an easy to use interface?
            •    Do our end users like the look and feel of the product? Are they
                 comfortable with it?
            •    If the vendor we purchase from should fail, what is our exposure?
                 -     Is the code open enough that we should be able to continue to support
                       ourselves until moving to another vendor is economically feasible?



File name: Portal Guideline
Version 1.0                                                                                 Page 30 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


                 -   What is the likelihood that they will be acquired by one of the ‘big
                     four’ or another large player, giving either the product a new lease on
                     life or a migration path to another product?




File name: Portal Guideline
Version 1.0                                                                      Page 31 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    5       Security Considerations

            Security requirements have not really changed — security has always been
            about risk management. Managing risk is a business decision based on a
            cost/benefit analysis. The amount of security will depend on the assessment of
            the risks and not the benefit realized through implementation. The decision to
            apply security will involve a series of decisions and policies, not a binary
            declaration to "do" security or not. Which, and how many, of the security
            mechanisms you use will depend in part on the nature of the application you're
            working with and the business value of the transactions. Usually the amount of
            money you spend on technology to protect your assets, coupled with the cost of
            managing and maintaining that technology, must be less than the values of your
            assets for you to stay in business.


            The security requirements include:
            •   Authorisation.
                How do you ensure that users are who they claim to be? How do different
                elements in the system locate and determine whether to trust one another?
                How do you enable new employees, customers or business partners to
                access existing systems without major changes to existing security
                infrastructure? Whose identity should be used to determine authorisation:
                the end user, the server, or some other entity?
            •   Asset Protection
                Can you keep data confidential and private when it's stored and when it's
                traveling across relatively un-trusted networks? How can you be sure that
                the data doesn't change while it's stored or in transit?
            •   Accountability
                How can you can tell who did what and when? How can you ensure, and
                prove, that the requests and results are not altered, inadvertently or
                maliciously?




File name: Portal Guideline
Version 1.0                                                                     Page 32 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •   Administration
                Can you define the security policy? Can you ensure that policies are
                consistent across all elements of applications, systems, platforms, and
                networks?
            •   Assurance
                Can you convince yourself that the system keeps its security promises?
                How can you ensure that the infrastructure and application resources
                including systems, networks, and data are not presently under attack?
            •   Availability
                How do you prevent attacks on elements of the system that cause
                disruptions in service? How do you design for fault tolerance and ensure
                that applications and data are restored in the event of a serious failure? How
                can you keep the system up and running 7 X 24 and also make needed
                modifications to the application, the systems, and the enterprise network?


    5.1     Authorisation


            Only authorised users should be able to gain access to systems, applications,
            data and services, no matter where they are located. There are two essential and
            interrelated   aspects   to   authorisation:    authentication   and   access    control.
            Authentication is the process of proving that a user or other entity is authorised
            to use a particular system privilege. Access control is the act of checking
            whether an authenticated user’s privileges permit the execution of a particular
            operation on a particular protected resource.


    5.1.1   Authentication


            An important step in building secure e-Government applications is to define
            who can run the application, and ensure that the users are who they claim to be.
            This was not a priority during the initial stages, because the information posted
                                                                            -Government is
            on the Web was there for all to see and use. But the concept of e


File name: Portal Guideline
Version 1.0                                                                             Page 33 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            different. You need to authenticate the employees, businesses and citizens who
            subscribe to the information or services, employees who access internal
            systems from remote locations via the public Internet, or business partners who
            are tightly integrated into your supply chain and backend systems. Non-
            repudiation is also required. Non-repudiation is the ability to provide proof of
            the origin or delivery of data to protect the sender against a false denial by the
            recipient that the data has been received — or to protect the recipient against
            false denial by the sender that the data has been sent.


            There are many types of authentication mechanisms. These mechanisms
            include user ID and password, one-time pass tokens, digital certificates, and
            biometrics. Because Public Key Infrastructures (PKIs) are emerging as one of
            the technologies for trusted e-business applications, it is direction of most top
            tier vendors to implement and increasingly rely on PKI for e-business
            solutions.


            PKI capabilities help create and manage asymmetric cryptographic keys or
            public/private key pairs required by applications. The following major PKI
            components provide the necessary capabilities to establish, maintain, and
            protect trusted relationships.
             •   Certification     Authority    (CA) creates and signs digital certificates,
                 maintains a list of certificates that have been revoked before the expiration
                 date (certificate revocation lists), makes these certificates and revocation
                 lists available, and provides an interface for administrators to manage
                 certificates.
             •   Registration Authority (RA) evaluates the credentials and relevant evidence
                 that a person requesting a certificate is who they claim to be. The RA
                 approves the request for issuance of a certificate by a CA.
             •   A digital certificate binds an entity's identification to its public key and is
                 issued by the Certification Authority. Digital certificates, based on the




File name: Portal Guideline
Version 1.0                                                                         Page 34 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


                 X.509v3 standard, enable Internet applications and other users to verify the
                 identity of an entity.
             •   PKIX, (the X.509 standard), defines the contents of public key certificates,
                 but certificates produced by one vendor product may not interoperate with
                 other vendor's because X.509 does not define the formats of the certificate
                 entries and other necessary provisions.
             •   Digital signature is a block of data created by applying a cryptographic
                 signing algorithm to some data using the signer's private key. Digital
                 signatures may be used to authenticate the source of the message and to
                 assure message recipients that no one has tampered with a message since
                 the time it was sent by the signer.
             •   Kerberos is an open standard designed to provide strong authentication by
                 using    secret-key      cryptography.    Kerberos   provides   authentication    and
                 delegation for back-end systems and other vendor platforms in the
                 heterogeneous enterprise network. Used primarily for secure interoperation
                 of existing systems, Kerberos is complementary to the role played by PKI
                 infrastructure for user authentication.
             •   Single Sign On enables the use of existing systems with minimal
                 disruption to existing infrastructure and applications. This enables users to
                 access Web resources and other back-end systems using existing Web user
                 names. This support makes it much easier to integrate with existing
                 applications without modifying the application's existing user database.
             •   Directory Services, based on the Lightweight Directory Access Protocol
                 (LDAP), define and implement a common schema for users and groups.
                 The directory service is the point of integration for user authentication
                 among products. The positive effect is that it has reducing administrative
                 costs and complexity. A user can be defined once within an enterprise, and
                 information about that user can be accessed in a consistent manner by
                 multiple different applications.




File name: Portal Guideline
Version 1.0                                                                                 Page 35 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    5.1.2   Access control


            Once a user's identity has been authenticated his or her access privileges must
            be determined. An authenticated user does not necessarily have any
            permissions to access applications within an e-business domain or resources
            within an application. Permissions are granted by setting up Access Control
            Lists (ACLs) on a resource such as a Web page and then evaluating the kind of
            access requested to determine if the requester has permission. Access is then
            granted or denied. e-Business applications may scale to dozens or hundreds of
            Web servers and potentially tens of millions of end users. The administration of
            ACLs can be very complex if they must be configured on each Web server
            system. Authorization to back end data or subsystems must be handled as well,
            including systems that have existing authorization mechanisms.               In addition,
            authorization to other key e-business resources such as objects and message
            queues must be incorporated.


    5.2     Asset protection


            Access control protects data when authorization rules can be set in a secure
            system environment capable of enforcing access control policy. When data
            must travel outside of a secure system environment, it needs to be protected so
            that the policies governing its use cannot be violated. Asset protection includes:
            •   Secure communications, ensuring data privacy, data integrity, and origin
                authentication.
            •   Secure storage of data (often encrypted) on systems where physical security
                may not be in effect.
            •   Protection of the keys that in turn are used to protect the assets.




File name: Portal Guideline
Version 1.0                                                                               Page 36 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


        Secure communications are implemented using a number of authentication and
        encryption technologies based on PKI.


            •   Secure Sockets Layer (SSL)
                This protocol is part of the Framework's network infrastructure. This
                protocol      uses   encryption    and     authentication       techniques   to   ensure
                communications between a client and a server remain private and to allow
                the client to identify the server and vice versa.
            •   Virtual Private Network (VPN)
                SSL     is    not    the   only    mechanism        available    for   creating   secure
                communications between systems. The Framework also supports Virtual
                Private Networks (VPN) through its implementation of IETF IPSec (RFC
                2401) and related standards. VPN differs from SSL in that it creates a
                secure channel between two TCP/IP hosts over which multiple TCP/IP
                connections can be established.
            •   Secure Multipurpose Internet Mail Extensions (S/MIME)
                Most e-mail client and server programs using Internet systems such as
                SMTP send e-mail as clear text. The Framework supports Secure
                Multipurpose Internet Mail Extensions (S/MIME), a specification for
                secure electronic messaging, to prevent the interception and or forgery of e-
                mail.
            •   Secure Electronic Transaction (SET)
                This protocol, developed jointly by Visa, MasterCard, IBM, and other
                technology providers, is used to protect the transfer of bankcard payment
                information over open networks like the Internet.


            Private keys and shared secrets, once acquired, must be protected. End-to-end
            security must include consideration of the security of the end user device.
            Private keys stored on a personal computer disk file may be stolen via access to
            the file system or outright theft of the device.




File name: Portal Guideline
Version 1.0                                                                                  Page 37 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    5.3     Accountability


            A system needs to log all attempts to access corporate resources to ensure that
            the system is secure. This logging can also facilitate management decisions by
            allowing analysis of use patterns.


    5.4     Assurance


            An e-business must provide assurance that the infrastructure and application
            resources, including systems, networks, and data, are protected with regard to
            confidentiality and integrity. This includes protecting the enterprise network
            and systems from various forms of attack, and also requires that the
            communications between the consumer or business partner and the application
            to be secure and confidential. A solution architect can choose from this set of
            mechanisms based on the specific security requirements for the solution.


            •   Boundary protection
                This is the logical and physical separation of the Internet and internal IT
                systems discussed in the Demilitarize Zone (DMZ) section. It is often
                accomplished by using two firewalls, one on each side of the Web server or
                other bastion hosts inside the DMZ. Firewalls police "who" enters and
                leaves an enterprise network and "what" gets in and out.
            •   Intrusion detection
                Where the firewall emphasizes network protection, intrusion detection
                services emphasize detection. With an approach that emphasizes buffer
                networks such as DMZs or extranets, it is essential that detection services
                are deployed to complement protection services. Should a DMZ or extranet
                be compromised, there is a need to detect that fact early, and take necessary
                actions to prevent the launching of a further attack into the private network.
            •   Virus detection




File name: Portal Guideline
Version 1.0                                                                               Page 38 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


                The other intrusion threat comes in the form of viruses. Computer viruses
                                                                 -mail attachments, from
                can enter your systems in a variety of ways: via e
                software installs, from files brought by employees from home, etc. They
                can quickly proliferate from system to system, user to user and cause
                damage to data, applications and networks. Viruses must be identified
                quickly, isolated, and damage repaired.


    5.5     Availability


            Availability is the ability to access data and resources whenever you need them.
            A robust system architecture is needed to enable you to adapt to just about any
            circumstance. Disasters do occur, and you must be able to quickly recover. This
            may mean distributing critical functions and data throughout different physical
            locations. Not only should the systems and networks have the technical
            capability to ensure availability, there must be a well defined and tested plan in
            place to allow your operations to continue as "normal". Applications should
            take advantage of multiple fault tolerance and high availability features and
            functions built into most platforms including support for RAID Storage and
            high availability cluster support. In addition, there are several mechanisms
            provided by the software technologies and products that supports this area
            which, includes:
            •   Load balancing requests among HTTP, FTP or other TCP-based servers,
                file systems.
            •   Replication for Web and other files, directory systems, mail, collaboration,
                and workflow database.
            •   Backup and Restore/Recovery for data systems including files, ERP
                applications, e-mail, and databases.
            •   Key recovery, a process and supporting technology for recovering keys that
                are lost, forgotten, stolen, or otherwise unavailable to persons who
                legitimately need them.




File name: Portal Guideline
Version 1.0                                                                        Page 39 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    5.6     Suggested Security Checklist
            The following table is a suggested list of security activities that could be
            checked. This will ensure that the important elements of security is not left out.


  ACTIVITY                                                                               DONE
  Implement a thorough and aggressive security policy that is reflected
  throughout your business, including firewall configurations, access
  controls and employee communications.
  Conduct a security awareness campaign to regularly remind employees of
  their security responsibilities (via Web-based certification or regular
  emails, for example).
  Install a firewall on outside borders, as well as internal, between human
  resources and engineering departments, for example. Be sure to change
  the default settings, which can be easily defeated.
  Use intrusion detection software. This is like having burglar alarms and
  motion detectors, but for your network. Just as with the firewall, it's
  important to have intrusion detection on external and internal networks
  Distribute antivirus software. The best antivirus systems will have an easy,
  effective update mechanism to ensure thorough coverage.
  Establish rules for password selection. Determine clear guidelines for
  passwords (such as six characters with at least one numeral) and an easy
  way to verify whether or not a password is acceptable. Passwords should
  also be changed periodically.
  Perform security audits on a regular basis. These should be unannounced
  and random -- some electronic, some physical; some stealthy, and others
  blatant. The goals of these audits are to get into the target system, access
  valuable data if possible and determine if the intrusion was even noticed


                                               Table 6




File name: Portal Guideline
Version 1.0                                                                               Page 40 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines




  ACTIVITY                                                                    DONE
  Designate someone as the main network security contact and determine
  clear procedures for reporting and responding to security issues.
  Employees should clearly understand who to report incidents to and that
  they should report all incidents that seem to breach the security policy.
  Ensure that system administrators stay aware of security advisories and
  make security-related changes in a timely manner. These are the folks on
  the front lines, so they need to be as proactive as possible and in a
  position to react quickly to security issues.
  Have a clear policy for action when an employee leaves for any reason.
  Actions to take quickly include disabling an ex-employee's building and
  computer access, deleting or redistributing computer accounts, and
  changing all passwords and access codes that employee may have
  known.
                                        Table 6 (continued)




File name: Portal Guideline
Version 1.0                                                                   Page 41 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    6       Management of the Portal

            An effective portal is one of the means for delivering an organisation’s
            business strategy. The management of the portal will be simple if there is
            integration between electronic publishing and the business units whose material
            is presented through it. Within that strategy, it is essential to ensure that the
            various management tasks that are necessary for effective use of websites are
            identified and that responsibility for their completion is clearly allocated and
            understood.


    6.1     Challenges for the Management


            It is essential that senior management take at least as close an interest in the
            electronic    publication      of     information      and   provision     of    services   as    in
            conventional channels. There should be senior member of each agency with
            specific responsibility for the overall management of his/her agency’s online
            presence.


            This   section    identifies        four   sets   of    issues   for     the    development      and
            implementation of online publishing strategies, namely
            •   strategic – what is the site for?
            •   responsibility – who is the owner and who is responsible?
            •   site management – how is the service to be acquired and provided?
            •   content – how will material be provided and presented online?
            •   auditing and maintenance – how should the usage and performance of the
                site be monitored?


            In some smaller agencies, it may be possible for one person to take on
            responsibility for both strategic issues and practical implementation of the
            website. This is the traditional webmaster role. It is recommended that
            departments and agencies move away from this model. The complexity of the


File name: Portal Guideline
Version 1.0                                                                                        Page 42 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


                electronic publishing task and its increasing importance for the business of
                government suggests that there is likely to be a requirement for a formal
                structure below the supervising board member.


                It is recommended that there should be a Senior Editor or editorial board with
                responsibility for the overall management of the site or sites which together
                make up the department’s online presence. They should work with the rest of
                the department and in some cases other agencies to ensure the integration of
                online and other business processes. There should be an individual or a team to
                monitor maintenance of standards of sites, especially where responsibility for
                putting up information is widely diffused in the organisation. The precise
                structure of these relationships, and the size and number of the teams involved
                is likely to vary greatly depending on agencies need.


    6.1.1       Strategic Tasks


                The strategic tasks that should be addressed are:
            •     Identification of the portal‘s place in the agencies overall communications
                  strategy
            •     Identification of the audience for the portal, where possible on the basis of
                  market research or dialogue with client groups
            •     Understanding and responding to users’ satisfaction with the site
            •     Provision of resources, especially staff with the necessary skills, for the
                  website team
            •     Integration of the website with business processes, which might include
                  electronic dealings with the public, publication of information, recruitment
                  and consultation.
            •     Integration of the portal into the department’s strategy for open government
                  and freedom of information
            •     Integration of the Internet site with the departmental intranet and other
                  agencies systems where required


File name: Portal Guideline
Version 1.0                                                                           Page 43 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •     Monitoring the development of the site and its success as a means of
                  meeting departmental objectives
            •     Creation of future online strategy


    6.1.2       Site Management Tasks


                Site Managers should have regard to:
                a) Technical     specification   in    support   of   the    business     aims,     including
                   specification of server requirements, overall specification of website design
                   and maintenance;
                b) Procurement including tendering and selection of suppliers, commissioning,
                   intellectual property rights clearance, monitoring contractors’ work and
                   sign off;
                c) Ensuring the quality of the site complies to the pre-set standards and most
                   importantly the government’s vision of meeting the citizens;
                d) Building the team and establishing relationships within the organisation.
                   The Senior Manager/person in charge should lead in identifying key staff
                   with responsibility for site management, design, publishing standards and
                   development of the site. There should be clear and effective liaison with:
                   •   Senior management
                   •   Press and off-line publications specialists
                   •   Policy teams
                   •   Information providers and authors
                   •   Front-line staff providing services to the public
                   •   Systems, network and intranet managers
                   •   Departmental training personnel
                   •   Other agencies (where needed)
                e) Online      help.   The   senior    manager/person       in   charge     should     make
                   arrangements for an effective online help service for users of the site, which
                   should be easily accessible through other channels provided by the agencies




File name: Portal Guideline
Version 1.0                                                                                       Page 44 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    6.1.3   Content Tasks


            There should be clear understanding within the agencies where responsibility
            lies for providing content for the website, and in what form it should be
            presented to the web team. Ideally, there should be a high degree of integration
            between content production in electronic form and conventional departmental
            activities.


            In any case, the web team should be equipped to provide technical support for
            the creation of electronic content. The team should ensure that high standards
            of editing and proof-reading of material for the site are maintained and may
            play a role in suggesting new formats for material for the site to those
            responsible for content provision. The team should establish clear and rigorous
            creative, design, and implementation standards and enforce adherence to them.
            The team must monitor closely that material is up to date. The team should
            monitor compliance with these guidelines.


            Agencies should also consult the department that deals with legal affairs within
            the public sector. The team should be able to assist content creators in finding
            advice on copyright, data protection, electronic signature and other legal issues.
            The Senior Manager or development team should ensure that arrangements are
            in place for:
               •      Prompt liaison with server host
               •      Updating the site
               •      Adding and removing material, if necessary at short notice
               •      Version control of the material on the site
               •      Technical design and specification
               •      Search engine registration and testing
               •      Programming and scripting
               •      Receiving     and   responding    to     email   enquiries   and    web    form
                      submissions


File name: Portal Guideline
Version 1.0                                                                               Page 45 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    6.1.4   Auditing and Maintenance Tasks


            The dynamic nature of the Internet environment makes it essential for the web
            team to carry out frequent monitoring of the performance and use of the portal
            and ensuring high standards are maintained. It is also important that regular and
            authoritative reports on performance and usage are available to senior
            managers or the designated committee. Some of the task that could be initiated
            are:
            •      Ensure that arrangements are in place for the following analysis and where
                   necessary for maintenance of the appropriate standards of performance;
            •      Standards of performance over a modem connection 28.8 / 56.6 kbps over a
                   typical domestic ISP. To simulate access experience of a large number of
                   users:
                      o     Check the use of different browsers and screen resolutions, and with
                            features such as scripts and images disabled;
                      o     Link checking. Broken links should be fixed within one working
                            day;
                      o     Server statistics archiving and monitoring;
                      o     Monitoring error messages;
                      o     Traffic analysis, focussing on peak times (to assess bandwidth
                            requirements) and dead times (should essential maintenance require
                            the site being down for a short time);
                      o     Server log file analysis.




File name: Portal Guideline
Version 1.0                                                                            Page 46 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •   The minimum information that should be required from hosts are statistics
                for:
                  o Page impressions;
                  o Unique visits;
                  o Successful requests;
                  o Unsuccessful requests;
                  o Most frequently visited pages;
                  o Least frequently visited pages;
                  o Top entry pages (as some experienced users may not enter through the
                       main page);
                  o Most referred sites.


            This information should be used to identify the most popular content, to review
            the navigation system (e.g. identifying orphaned pages) and referring sites, to
            audit responses to web-inspired e-mail and electronic forms and to assess the
            effectiveness of marketing/pr campaigns. The information is also likely to be
            useful as a source of information on server performance, the quantity of
            documents requested, visitors’ electronic distribution, the number of visitors
            and the platforms which visitors use, including browsers and screen resolution.


            In addition it is recommended that web teams should:
            •   Give more importance to unique users and page impressions than to hits.
                Look into more personalisation factors;
            •   Take as much notice of error logs as of any other statistics;
            •   Determine who is using the site the most;
            •   Collect information from usage statistics on the types of browser which are
                being used to access the site. This will help tailor the pages to be viewed
                effectively. Use this as an improvement opportunity;
            •   Determine the data transfer as it will determine what to place on the pages
                (less graphics, more text etc.);
            •   Archive logs for as long as possible.


File name: Portal Guideline
Version 1.0                                                                             Page 47 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


    6.2     Electronic Publishing


            In order to create and maintain a website that fulfils e-government objectives,
            each agency must look very carefully at its existing publishing processes.
            Government websites will need to be updated frequently and maintained
            constantly. This requires the creation of a centre of excellence for electronic
            publishing. The following section aims to provide guidelines for content
            production and publication.


    6.2.1   Content Generation


            While information for publication within government is generally created
            electronically, the primacy given to conventional publishing often means that
            material does not always reach the web team in electronic format. Where late
            corrections are made to texts, there is a real risk that there is no authoritative
            electronic copy. If there is to be rapid, accurate and accessible electronic
            publishing, agencies should adopt publishing strategies, which establish an
            authoritative electronic version of documents as a basis for both the electronic
            and paper versions of texts.


            Information for the website should be provided and preferably created in an
            electronic format which can easily be translated into formats stated in the
            Interoperability Framework (i.e. MyGIF).


    6.2.2   Online Publishing Tools


            There are many different publishing tools for publication of all sorts of data.
            Departments and agencies may need to create graphics and other media types
            in conjunction with any programming and interface design tools required. The
            following could be some of the tools required to achieve this:
            •     Text Editors – to write codes and edit large detail contents



File name: Portal Guideline
Version 1.0                                                                        Page 48 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines


            •     HTML Editor - to write code more efficiently (many of these now come
                  with web publishing tools)
            •     Graphics Editor to produce, manipulate and modify images (e.g. Photo
                  editors)
            •     FTP Software to send pages to the server
            •     Email Software to receive and reply to website-generated email and forms


            Site management tools usually have functions of HTML and text editors, FTP
            software, link management tools and web statistics packages.


            Publishing static data on small websites is easy, but for larger websites it is best
            avoided. Therefore using the dynamic data publishing method is encouraged.
            The choice of publishing methods is left to the judgement web teams.


    6.3     Branding


            Branding is important as a means of informing users that they are using a
            government site. It should be used to give assurance that the information on the
            site is comprehensive, accurate and reliable. Branding should also be used to
            give citizens and business of the Malaysian Government presence on the
            Internet.


            In developing sites, departments should consider and refer to:
            •   Guidelines recommended or issued by the JITIK about branding. This
                guidance      will   be   developed   in   consultation   with   the   e-government
                champions
            •   Any principal that online branding should usually build on the strengths of
                existing offline branding. The portal should support the brand, not own it.
            •   The need to ensure that sites should convey whole of government as well as
                departmental and agency branding. At the simplest level, this should be
                achieved through links to the key pages


File name: Portal Guideline
Version 1.0                                                                               Page 49 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    7       Summary

            When developing portals developers/evaluators should be aware of the
            elements discussed to insure that they are able to deploy a suitable solution that
            will address their business/operation needs.


            The appendix provided at the end of this document is a summary of the
            elements discussed, which could be used as a reference checklist.         The list
            presented is by not means complete, but it is a first step towards a better
            understanding of what ingredients are needed for a well design people centric
            portal.




File name: Portal Guideline
Version 1.0                                                                        Page 50 of 51
Date 17/08/2003
Standards, Policies and Guidelines -
Portal Guidelines



    8    Glossary of Terms

        List of abbreviations and acronyms used for easy reference.


        Abbreviations and Acronyms used

        RMI                   Remote Method Invocation

        HTML                  Hyper Text Markup Language

        G2C                   Government to Citizens

        G2B                   Government to Businesses

        G2E                   Government to Employees

        DMZ                   Demilitarize Zone

        TCP/IP                Transmission Control Protocol/ Internet Protocol




File name: Portal Guideline
Version 1.0                                                                      Page 51 of 51
Date 17/08/2003

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:2/27/2012
language:
pages:52