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.