🔊 Take a moment and listen

Embarking on massive e-Governance programmes for Governments the worldover to bring about a   perceptible change in the very system of governance should not be taken as a matter of course alone – that of planning and implementation. It should be necessarily viewed more than that. As such, to make any e-Governance programme a success there is a dire need to have an architecture in place that is live and adaptable to the changing world, or else…

Most strategic programs around the world are launched with implementation as the backdrop.  Companies, agencies and Governments are purely result focused. Somewhere in the mad rush to  have the programme running, the technology working and seeing tangible results – the focus is lost from planning to implementation. The fundamental questions as to why such a program  initiated in the first place is simply not given a thought afterall. Was the current technology being  used just to do something that might be beneficial, or was it to have a process in place to solve  pressing uses, improving transparency and providing value to the citizens for years to come? A  process that is forever evolving with the changing needs of its customers and which is in line with  technology. Agencies look at technology as a means to achieve better return on investment.  Technology is evolving so fast that something, which is in vogue today, is redundant before it  could even be implemented. Agencies are focused on using technology to reduce cost and improve  the service levels. However, there is no mechanism to identify redundant technology investments once the program gets rolling. Thus the sole purpose for which investment in technology was done is rather defeated.

Technology is just a means to the end – not the end in itself. And, what’s important is the vision  and how the vision is translated into actionable strategies and tactics – the process that evolves with evolving technology and customer needs.

Problems during implementation

As such, it therefore becomes critical for Governments embarking on massive e-Governance  programs to have an architecture in place that is live and adaptable to the changing world. It may however be noted that many governments around the world took the path to implementation only  to realise a couple of years down the line that they were facing common problems such as Post-Modernisation problems, Paving Cowpaths, Redundant buying, Program Management,  Islands of Automation, and Poor cyber security.

In Post Modernization problems, few agencies had business-driven enterprise architecture; a roadmap that showed what IT investments will be used to better performance. Agencies automated management problems instead of leveraging e- Governance to fix them while paving  Cowpaths. Multiple agencies bought the same item instead of driving economies of scale or  creating one-stop points of service thus making buying redundant. Program Management also  faced problems as few delivered on time or within budget. Citizens had to deal with multiple  agencies to get service instead of going to a single point of service website or call centre thus  creating Islands of Automation. Poor cyber security was also a major problem wherein IT  security was seen as an IT or funding issue instead of agency management issue.

Redressing of issues

Finally, after much debate and discussion a mandate was set and a two-pronged approach was  arrived at to address the above issues that include Agency e-Government progress, Modernisation  Blueprint – Enterprise Architecture, Business Cases – Capital Planning and Investment Control, IT Program Management, IT Security, and Multi-agency e-Government Initiative Involvement.

The OMB (Office of Management & Budget) came out with the following fundamentals that all US agencies must comply to:

• Fundamentals for success in applying Web Services – Identify common functions,  interdependencies, interrelationships, and evaluate barriers to information sharing; Implement in  a way that addresses both the opportunities and risks of a “networked” environment; and, Leverage technologies to achieve benefits of interoperability while protecting societal values of  privacy and intellectual property rights etc.
• End-to-End Digital service delivery – Developing a modernisation blueprint includes  Component-based enterprise architecture that addresses the business lines, data, information, and  technology necessary to meet our missions; CIO Council/OMB Analysis identifying internal/ external interrelationships and interdependence at each layer; Within and across departments. Besides, Privacy and security are key components of this architecture. There is a need to eliminate  investments in redundant IT capabilities. The service delivery mode should be that of ‘Unify and Simplify’ one thus necessitating shared investments and process integration to leverage common  components in making government citizen-centred and driving results. Common business  functions are a necessity, and Vertical or horizontal integration needed to perform.

The Clinger-Cohen Act of 1996 mandated that Federal Agencies develop and maintain an enterprise  architecture. The Federal Enterprise Architecture Framework (FEAF) was established  in 1999 by the Chief Information Officers in response to this mandate.

As per the FEAF document – this Framework allows the federal government to organise federal  information on a federal wide scale, promote information sharing among Federal Organisations,  help Federal Organisations develop their architectures and their IT investment processes quickly,  and serves citizens needs better, faster and cost effectively.

Construction of FEAF

The FEAF consists of four levels. The first level provides a high level description of the above  components, and the next three levels extensively describe these components in detail. The fourth level also provides a logical structure for classifying and organising the artifacts. This logical structure is actually a tailored version of the Zachman Framework.

FEAF Levels I Thru III

Level I is the highest-level view of the FEAF (the FEAF describes this as the view from 20,000  feet). This level introduces the eight components needed for developing and maintaining the  Federal Enterprise Architecture, as follows: (i.) Architecture Drivers – external stimuli that cause  the Federal Enterprise Architecture to change; (ii.) Strategic Direction – ensures that changes are consistent with the overall Federal direction; (iii.) Current Architecture – the current state of the  enterprise; (iv.) Target Architecture – the target state for the enterprise within the context  of the strategic direction; (v.) Transitional Processes – processes that apply the changes from the current  architecture to the target architecture in compliance with architecture standards such as  various decision making or governance procedures, budgeting, engineering change control etc.;  (vi.) Architectural Segments – subsets or smaller enterprises within the total Federal Enterprise;  (vii.) Architectural Models – provide the documentation and the basis for managing and  implementing changes in the Federal Enterprise; (viii.) Standards – standards (some of which  may be made mandatory), voluntary guidelines, and best practices, all of which focus on  promoting interoperability.

The FEAF Level II (view from 10,000 feet) and Level III (view from 5,000 feet) provide more  details on the information to be captured. Architecture drivers (which include business and design  drivers) act as a catalyst to drive the current (‘as is’) architecture to a target (‘to be’) architecture.  The target architecture should realise the strategic direction, including vision and principles.  Transitional processes move the architecture from current to target state. Standards are also involved in this process. Architectural models form the core of the information captured. System  Architect is a viable tool for capturing all of the architectural information, and providing it in a repository.

Finally, Level IV (the view from 1,000 to 500 feet) of the FEAF identifies the kinds of models that  describe the business, data, applications and technology architectures. A specific set of artifacts,  methods and approaches on how the business architecture is supported by the three design  architectures (data, applications, and technology) begins to evolve. The FEAF at Level IV provides  a matrix of artifacts to capture. This matrix is actually a cut-down version of the Zachman Framework.

The Zachman Framework

The Zachman Framework for Enterprise Architecture is an approach for documenting and/or  developing an enterprise-wide information systems architecture. Developed by John Zachman, this framework provides multiple perspectives of the overall architecture and a categorisation of  the artifacts of the architecture. The Zachman Framework is actually a matrix of 36 cells covering  the entire aspect of an enterprise. The enterprise is then split that into six perspectives, starting at  the highest level of business abstraction going all the way down to implementation. The  framework can contain global plans as well as technical details, lists and charts. Any appropriate  approach, standard, role, method or technique may be placed in it.

Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter, Instagram.