i
The Codification of an Enterprise
Architecture Framework in a Global
Mining Company
Submitted by
Anton van Wieringen
Student number: 12318388
Supervisor:
Prof. RA Lotriet
Potchefstroom Business School
October 2012
i
ACKNOWLEDGEMENTS
With this I extend my thanks for the support received form the following people during the duration of the study.
My wife for her help and support during the duration of my studies.
My family and friends for their help and support.
My study leader, Prof. Ronnie Lotriet for the help, support and guidance through the research process.
My language editor, Ricky Hunt.
Statistical consultation services at Northwest University.
ii
TABLE OF CONTENTS
ACKNOWLEDGEMENTS ... I
LIST OF FIGURES ... V
LIST OF TABLES ... VI
LIST OF GRAPHS ... VII
LIST OF ABBREVIATIONS ... VIII
ABSTRACT ... IX
CHAPTER 1 ... 1
NATURE AND SCOPE OF THE STUDY ... 1
1.1 INTRODUCTION ... 1
1.2 BACKGROUND ... 1
1.3 PROBLEM STATEMENT ... 9
1.4 SIGNIFICANCE OF THE STUDY ... 10
1.5 RESEARCH OBJECTIVES ... 11 1.5.1 PRIMARY OBJECTIVE ... 11 1.5.2 SECONDARY OBJECTIVES ... 11 1.6 RESEARCH METHODOLOGY ... 11 1.6.1 LITERATURE STUDY ... 11 1.6.2 EMPIRICAL RESEARCH ... 12 1.7 SCOPE OF STUDY ... 12
1.7.1 LIMITATIONS OF THE STUDY ... 12
1.8 LAYOUT OF THE STUDY ... 13
CHAPTER 2 ... 14
THE STUDY OF ENTERPRISE ARCHITECTURE ... 14
2.1 INTRODUCTION ... 14
2.2 CONTEXT ... 14
iii
2.3 THE HISTORY OF ENTERPRISE ARCHITECTURE ... 21
2.4 A REVIEW OF THE MOST PROMINENT EA FRAMEWORKS ... 23
2.4.1 THE ZACHMAN FRAMEWORK ... 23
2.4.2 TOGAF ... 26
2.4.3 FEDERAL ENTERPRISE ARCHITECTURE (FEA) ... 32
2.4.4 GARTNER /META PROCESS ... 36
2.5 PROBLEMS ASSOCIATED WITH THE IMPLEMENTATION OF EA ... 37
2.6 THE ORGANISATION... 39
2.7 STATUS QUO ASSESSMENT CRITERIA REGARDING THE CODIFICATION OF EA ... 42
2.7.1 ALIGN THE IT STRATEGY TO THE BUSINESS STRATEGY ... 42
2.7.2 COMMUNICATE IT’S VISION AND VALUE ... 43
2.7.3 GUIDE IT INVESTMENT AND DESIGN DECISIONS ... 43
2.7.4 CHANGE BUSINESS AND INFORMATION SYSTEMS BEHAVIOUR ... 43
2.8 SUMMARY ... 45
CHAPTER 3 ... 45
EMPIRICAL STUDY ... 45
3.1 INTRODUCTION ... 45 3.2 RESEARCH QUESTION ... 46 3.3 HYPOTHESIS ... 46 3.4 RESEARCH METHODOLOGY ... 47 3.5 RESEARCH DESIGN ... 47 3.5.1 STATISTICAL APPROACH ... 483.5.2 RELIABILITY AND VALIDITY ... 49
3.6 SAMPLING DESIGN ... 49
3.7 DATA GATHERING ... 50
3.8 STRUCTURE OF THE QUESTIONNAIRE ... 50
3.9 RESPONSE RATE... 51
3.10 RESEARCH FINDINGS ... 51
3.10.1 SECTION A:PROFILING OF THE OPERATING ENVIRONMENT ... 52
3.10.2 SECTION B:GENERAL QUESTIONS ABOUT THE OPERATIONAL ENVIRONMENT ... 53
3.10.3 SECTIONS C AND D:NEW PROJECTS AND TECHNOLOGY APPROACHES AND BUSINESS ARCHITECTURE 56 3.10.4 SECTION E:TECHNOLOGY-SPECIFIC QUESTIONS ... 58
3.10.5 SECTION F:APPLICATION-SPECIFIC QUESTIONS ... 59
3.10.6 SECTION G:DATA-SPECIFIC QUESTIONS ... 59
3.10.7 FURTHER STATISTICAL ANALYSIS ... 61
iv
CHAPTER 4 ... 63
CONCLUSION AND RECOMMENDATIONS ... 63
4.1 INTRODUCTION ... 63 4.2 MAIN FINDINGS ... 64 4.3 STUDY EVALUATION ... 65 4.3.1 PRIMARY OBJECTIVE ... 65 4.3.2 SECONDARY OBJECTIVE ... 66 4.4 RECOMMENDATIONS ... 66 4.5 FURTHER RESEARCH ... 67 4.6 CONCLUSION ... 68
BIBLIOGRAPHY ... 68
APPENDIXES ... 71
5.1.1 APPENDIX A... 71 5.1.2 APPENDIX B... 76 5.1.3 APPENDIX C ... 78 5.1.4 APPENDIX D ... 113 5.1.5 APPENDIX E... 135v
LIST OF FIGURES
Figure 2: CIO survey on IT strategies ... 18
Figure 3: Current stages of EA in companies... 19
Figure 1 The timeline of architecture frameworks ... 22
Figure 4: The two-dimensional Zachman framework ... 25
Figure 5: The architecture development method ... 28
Figure 6: The enterprise continuum ... 31
Figure 7: Segment map of the federal government ... 33
Figure 8: Top management structure for K&IT ... 40
vi
LIST OF TABLES
Table 1: The set of architectural representations prepared over the process of constructing a building ... 15 Table 2: Generic extrapolation of architectural concepts ... 16 Table 3: Summary of Gartner case study best practices for implementing EA .... 43 Table 4 Correlation between questions C3 and D2 ... 62
vii
LIST OF GRAPHS
Graph 1: The geographical split of global survey participants ... 52
Graph 2: The number of operations at which survey participants have worked ... 53
Graph 3: The perceived level of complexity for current technology projects ... 54
Graph 4: Alignment of regional tactical plans to the K&IT strategy ... 54
Graph 5: The level at which regional tactical plans are documented ... 55
Graph 6: The level of architectural compliance testing ... 55
Graph 7: The percentages of technology projects driven by K&IT ... 56
Graph 8: The extent to which business dictates which technology is used ... 57
Graph 9: The extent to which sites will be able to recover their environment during disasters... 58
Graph 10: The extent to which application interfaces are documented ... 59
Graph 11: Availability of authoritative data sources ... 60
Graph 12: The extent to which data are duplicated for use in multiple systems .. 60
Graph 13: How often business requirements are identified before a technology project starts ... 61
Graph 14: How often business analysis is performed before implementation of new technology ... 62
viii
LIST OF ABBREVIATIONS
AD: Active directoryADM: Architecture development method AV: Anti-Virus
BPF: Business Process Framework CAR: Continental Africa region CIO: Chief information officer DR: Disaster recovery EA: Enterprise architecture
FEA: Federal enterprise architecture ISS: Infrastructure shared services
ITIL: Information technology information library IT: Information technology
K&IT: Knowledge and information technology SAR: South Africa region
SOE: Standard operating environment SP: Systems for People
TAFIM: Technical Architecture Framework for Information Management TOGAF: The Open Group Architecture Forum
ix
ABSTRACT
With its headquarters in Johannesburg, South Africa, the mining house has 20 operations on four continents and several exploration programmes in both established and new gold-producing regions around the world , including exploration offices that serve in the region of about 10 000 direct IT users. The purpose of this research is to understand the prerequisites required to achieve the tactical objectives identified in the 2011 Knowledge & Information Technology strategy and effectively implement an enterprise architecture framework at the mining house. Growing emphasis on the board and executive committee’s understanding of IT, which is primarily driven by corporate governance and with recent enactment of the new Companies Act, good governance is no longer just recommended but is enforced and requires annual reporting. Growing compliance requirements as governments and legal entities become more aware of the dependencies that are created through the evolution in IT.
The Knowledge & Information Technology department mission is to provide the IT tools necessary for people to do their jobs, the ecosystem to translate data into wisdom, and, in doing so, deliver value to the mining house shareholders, employees, and business and social partners.
The vision of the Knowledge & Information Technology department is that the employees of the mining house will have access to secure, common IT infrastructure and systems that support business processes, deliver value and that create opportunities for the sharing of best practices, great ideas and technologies, and the reduction in duplicated effort, waste and inefficiencies. Because of the disparate status of information systems and technology in the mining house, there is a need for better and more comprehensive standardisation of the global systems and technology environment. These efforts are important for the planning and delivery of key initiatives within the strategy as defined. The first
x
formal reference to information systems architecture was made in 1987 by J.A. Zachman in an article that was published in the IBM Systems Journal. In the extract of the article written by Zachman, he explains: “With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of a system” (Zachman, 1987).
Focus on delivering business objectives that are identified by the business. It is important that EA teams understand their enterprises and their strategies and goals. It is also important that they understand the CIO’s strategy and how it aligns with the organisation’s strategy. The categorisation of EA in the mining house has not been attempted before. Enterprise architecture is systemic by nature and by default relies on an inclusive approach, which implies that codification should consider the IT organisation as a whole. Various components were identified that could contribute to the successful codification of EA in the mining house. Benchmarking EA activities throughout the global organisation and understanding the deficiencies or perceived maturity levels will assist in choosing an effective way forward for the codification of an organisation-wide EA.
Empirical study assists in achieving this objective, and along with the dissertation statement it is critical to the success of a dissertation. The study fills a gap in that it aims to deliver or guide the tactical outputs supporting the K&IT strategy. The K&IT strategy, in turn, supports the business strategy with the aim of maximising returns to shareholders.
Codifying EA would simplify complex technology environments and clarify the vague knowledge that currently exists of the environment. This premise relies on strong governance to guide compliance and ultimately simplify the management of IT and increase its value contribution to business. Lastly, the implementation of EA in the mining house should ultimately enhance the Knowledge & Information Technology strategy and effectively support the business strategy to maximise returns to shareholders.
1
CHAPTER 1
NATURE AND SCOPE OF THE STUDY
1.1 Introduction
The purpose of this research is to understand the prerequisites required to achieve the tactical objectives identified in the 2011 Knowledge & Information Technology strategy and effectively implement an enterprise architecture framework at the mining house.
1.2 Background
With its headquarters in Johannesburg, South Africa, the mining house has 20 operations on four continents and several exploration programmes in both established and new gold-producing regions around the world. The mining house employed 62 046 people, including contractors, in 2010 and produced 4.52Moz of gold (2009: 4.60Moz), which generated $5.3bn in income (2009: $3.8bn). Capital expenditure in 2010 amounted to $1.015bn (2009: $1.027bn). On 31 December 2010, the mining house’s ore reserve totalled 71.2Moz(AngloGold-Ashanti, 2011).
Focused on returns
The mining house maximise the returns delivered to shareholders throughout the economic cycle by producing gold safely, responsibly and efficiently (AngloGold-Ashanti, 2011).
The company’s vision is “to be the leading mining company. The mining house’s mission statement is: To create value for our shareholders, our employees and our business and social partners through safely and responsibly exploring, mining and marketing our products. The primary focus is gold and we will pursue value-creating opportunities in
2
other minerals where we can leverage our existing assets, skills and experience to enhance the delivery of value (AngloGold-Ashanti, 2011).
This vision and mission are to be achieved by following a set of values that has been defined by the business and employees alike.
Safety is our first value
We treat each other with dignity and respect
We value diversity
We are accountable for our actions and undertake to deliver on our commitments.
The communities and societies in which the mining house operates will be better off for mining house having been there
We respect the environment
This vision, mission and values were part of the new business strategy as created by the chief executive of the mining house in March 2008.
The core strategies are: People are the business
Grow the business
Manage the business as an asset portfolio
Maximise margins
Deliver sustainable outcomes
To achieve this new strategy the business was restructured and several supporting initiatives and projects were implemented. The first was “business process framework (BPF)”, which, in layman’s terms, governs the way in which work is planned, implemented and ultimately governed. The second major initiative is Project ONE. Project ONE is about a shift of culture in the mining house, and it is the medium through which such initiatives will be communicated. Project ONE is linked to the mining house’s mission, vision and values. It is an entity and a brand on its own that should be used for communication. It involves all of the above initiatives that are strategically aligned with
3
The mining house’s vision of being the leading mining company(AngloGold-Ashanti, 2011)
Information technology (IT) function forms part of these initiatives with a twofold goal — to respond to the business requirements in alignment with the business strategy and to respond to the governance requirements in line with the board’s direction(Crocker, 2012).
Senior vice-president of knowledge and information technology at the mining house, contextualised the new IT strategy based on three drivers(Crocker, 2012):
How changes and initiatives within the business shaped the IT requirements and the expectation for IT to deliver to these requirements.
Understanding the abilities and frailties of the mining house IT context and the organisational structure that delivers in the current environment.
Understanding external IT contexts with the aim of identifying external factors that influence the delivery of IT functionality in the business.
The business driver
The Project ONE initiative drives improvement on all levels in the company and is built on two projects, namely the business process framework (BPF), which aims to standardise and improve a range of processes across the business, and systems for people (SP), which aims to create an organisation with the requisite capabilities to deliver the desired progress.
Both BPF and SP are dependent on IT applications to support the newly aligned processes that are central to achieving the business’ strategy. Project ONE not only supports these initiatives but is also responsible for creating an aligned approach in other critical functions of the business — such as safety, maintenance and procurement on a global level — and is not just a sequestered, regional drive for improvement.
4
The Project ONE initiative has given rise to significant improvements in various key business outputs. This being said, cost-reduction efforts remain a focus for the business, which implies that efficiency will remain a key deliverable. A further requirement will be to support optimisation through innovation and technology as a way for other departments and functions to be more efficient.
From a compliance perspective, the new Companies Act (REPUBLIC-OF-SOUTH-AFRICA, 2009) enforces King III. As a result certain IT elements in Chapter 5 of the King report on corporate governance (King, 2009) are no longer considered good practice and have thus become statutory, but the board still requires aspects of the business’ activities and status to be reported (Crocker, 2012).
The mining house IT driver
The mining house has operations at roughly 30 locations in Africa, North America, South America and Australia, including exploration offices that serve in the region of about 10 000 direct IT users.
The primary infrastructure interconnecting the mining house’s locations and employees include the wide area network (WAN) directory services and active directory (AD), which are disseminated by the company’s Knowledge & Information Technology (K&IT) department. The infrastructure is supported and managed by outsourced services providers, namely Orange Business Services and Dimension Data for WAN and AD respectively.
Other core operational infrastructure varies significantly as no standards apply or standards are not being followed. Some of the physical infrastructure in the Continental Africa region (CAR) needs to be replaced. Certain WAN links will need to be upgraded to support the “One ERP” initiative. But most of the remaining infrastructure in other regions is in an acceptable state.
5
The application layer is diverse and there is little commonality across the different regions. With Project ONE, a business-intelligence system that acts as a single reporting system, there are some exceptions where there is commonality in the application of the work-management system (BPF), but these are not the norm. Other commonalities exist between systems where the same requirement existed and due review process resulted in the selection of the same solution.
The external IT driver
External IT drivers are primarily focussed at understanding forces that external IT factors will exert on to the business and the resulting expectations IT will be expected to deliver on.
The main drivers or forces as identified by Crocker (2011) are:
Growing emphasis on the board and executive committee’s understanding of IT,
which is primarily driven by corporate governance. With recent enactment of the new Companies Act, good governance is no longer just recommended but is enforced and requires annual reporting.
Growing compliance requirements as governments and legal entities become more aware of the dependencies that are created through the evolution in IT.
Increasing risks associated with IT security. According to Namestnikov, the last quarter of 2011 saw an increase in hacker and hacktivist groups attacking corporate networks. These include, but are not limited to, the Italian cyber police, the FBI, Mitsubishi Heavy Industries and Vanguard Defence (Namestnikov, 2011).
Consumerisation, which, as defined by the Business Dictionary, is “the process of enterprise technology being changed or influenced by new technologies emerging from consumer markets into professional arenas. Certain types of smartphones, for example, began as a consumer product and are now used extensively in corporate environments, military contexts and other professional spheres”a (ANON, 2011).
6
“Cloud” computing, which “is a style of computing where scalable and elastic IT-related capabilities are provided as a service to customers using internet technologies”(Cearley, 2010).
Centralisation and/or adoption of shared services, which is a form of “internal outsourcing” that provides corporates with the ability to achieve major cost reductions by making use of a single provider within the business to design and manage IT services(Fujitsu, 2007).
Mobility — with increasing capabilities of mobile devices the expectations of users have increased, as have expectations of using these capabilities to perform work.
Increased information holdings. The amount of information that requires storage is ever increasing. Coupled with compliance, this can become ungainly and costly to maintain and support.
Social media. Crocker defines social media as applications that promote communication between individuals founded on the content or pleasure they generate. The most familiar examples of these are Facebook and Twitter (Crocker, 2012).
The K&IT strategy
The new K&IT strategy was drafted and accepted by the board during the last quarter of 2011. Crocker presented the below mission, vision and strategies with the associated tactical plans to assist the delivery of the strategic objectives (Crocker, 2011).
Mission
To provide the IT tools necessary for people to do their jobs, the ecosystem to translate data into wisdom, and, in doing so, deliver value to the mining house shareholders, employees, and business and social partners.
Vision
Employees of the mining house will have access to secure, common IT infrastructure and systems that support business processes, deliver value and that create opportunities
7
for the sharing of best practices, great ideas and technologies, and the reduction in duplicated effort, waste and inefficiencies.
Strategies with the associated tactical plans as communicated by Crocker (2011):
Align IT and the business
Align our applications so they deliver full value to the mining house.
Align our core, global infrastructure and make it capable of delivering oneERP o 2012 actions:
Establish an infrastructure shared-services governance structure Establish an infrastructure shared-services organisation
Establish infrastructure technical architecture (enterprise architecture)
Establish infrastructure technical-architecture standards
Implement the mining house’s standard operating environment (SOE) for desktop / laptop
Understand IT risks and manage them effectively o Current actions
Review current standards and policies
Develop basic evaluation process for IT disaster recovery (IT DR) o 2012 actions
Develop IT security policy
Develop required IT security-related standards
Align AV software system and centralise management
Develop software-licensing management solution (commercial and compliance)
Empower our people to increase their productivity
Enable the business to share knowledge and information that is consistent, accurate, aligned with the business and available to all
Get the IT basics in place o Current actions
8
Convert SAR change-management process to a mining house-wide process
Develop approach to enterprise architecture codification o 2012 actions
Perform CobiT maturity assessment
Determine CobiT processes to target for initial implementation in 2012 Develop Enterprise Architecture (TOGAF phases C and D)
Develop a incident-management process
Establish oneERP support organisation and necessary IT infrastructure library (ITIL) processes to underpin it
Really understand our overall IT costs
o Consolidate 2012 IT plans across the mining house o Perform IT costs benchmark in quarter 3
o Develop action plan based on IT costs benchmark findings o Develop mining house-wide IT cost plan for 2013
Improve IT organisational alignment
Get the IT right resources and the maximise their contribution
Be innovative to improve IT efficiency and effectiveness o Current actions
o Review options for email in cloud
Enterprise architecture
As part of IEEE-Std-1471-2000, the Institute of Electrical and Electronics Engineers define architecture as “the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution (IEEE-SA Standards Board, 2000).
Because of the disparate status of information systems and technology in the mining house, there is a need for better and more comprehensive standardisation of the global systems and technology environment. These efforts are important for the planning and delivery of key initiatives within the strategy as defined(Preiss, 2007).
9
The codification of technical and systems / applications architecture with in the mining house is an immediate requirement and tactical delivery driving two strategic deliverables as stated above:
“Align our core, global infrastructure and make it capable of delivering oneERP” Establish infrastructure shared-services organisation
Establish infrastructure technical architecture (EA) Establish infrastructure technical architecture standards
“Get the IT basics in place”
o Develop approach to EA codification o Develop EA (The-Open-Group, 2011)
1.3 Problem statement
The categorisation of EA in the mining house has not been attempted before. Enterprise architecture is systemic by nature and by default relies on an inclusive approach, which implies that codification should consider the IT organisation as a whole. According to Ackoff (Ackoff, 1995), systems can be defined from a systemic point of view as wholes that consist of two or more parts and those parts have three properties:
Each part of the system can affect the behaviour or properties of the whole.
None of the essential parts can have an independent effect on the defining function of the whole.
Every sub-system or collection of parts can affect the behaviour or properties of the whole.
The same three properties can be applied to EA.
The mining house is a global enterprise, and therefore its size and complexity pose several issues and challenges.
10
The first problem is the narrow knowledge base of EA in the IT fraternity of the mining house. EA in itself requires extensive effort from all employees involved in IT to realise its value. But if the value is not understood, all efforts to introduce EA into the business will be met with resistance.
The second problem is language diversity. The mining house functions in a melting pot of cultures and languages, the most predominant being French, Spanish, Portuguese and English, and most communication and documentation occur in these languages. But the standard EA frameworks are available only in English. It will be challenging to get the same consistent message across to all incumbent EA contributors. Inconsistency will prevent any realisation of value.
The third problem is the inability of current staff levels to meet the output required to achieve the categorisation of EA within the business.
The fourth problem is that the scope of full EA is difficult to control. The aim to deliver certain components of a specific EA framework will trigger the requirement of other components. Although a sequential approach is critical to achieve the objective, any dependencies can stymie the whole process(Jonkers, 2004).
1.4 Significance of the study
The study fills a gap in that it aims to deliver or guide the tactical outputs supporting the K&IT strategy. The K&IT strategy, in turn, supports the business strategy with the aim of maximising returns to shareholders.
The study will provide guidance to the team responsible for the implementation of the EA effort in the mining house.
The first objective would be to get a clear indication of the approach that should be taken to implement EA.
The second objective would be to have an accurate understanding of the dependencies that exist and that will be created through the process of implementing an EA framework.
11
Lastly, the implementation of EA in the mining house should ultimately enhance the K&IT strategy and effectively support the business strategy to maximise returns to shareholders.
1.5 Research objectives
1.5.1 Primary objective
The main objective of this study is to find the best method to codify EA in the mining house.
1.5.2 Secondary objectives
Secondary objectives of the study would include:
Describe a meta-model for EA in the mining house.
Identifying and developing processes to support the EA initiative in the mining house.
Identifying the steps that will lead to value maximisation.
1.6 Research methodology
1.6.1 Literature study
A literature study will be done on EA. The study will focus on the following fields:
EA frameworks.
Systems theory and its relation to EA.
The organisation of EA.
12
1.6.2 Empirical research
The empirical research will be done by means of a quantitative and qualitative study based on questionnaires, case studies and interviews.
The qualitative and quantitative research will be done with global team member in the company to ensure an accurate representation of EA is used for the study. The knowledge gain is to be tested against the mining house K&IT environment and population(Levine, 2008).
A quantitative review of the environment will be done to measure the impact of the study, and some statistical analysis will be done to measure metrics such as availability of infrastructure, applications and services.
1.7 Scope of study
The field of study for this research is EA within the global gold-mining enterprise. The research focuses on the required approach that should be followed to codify enterprise architecture. Only this single mining house was considered in this study.
1.7.1 Limitations of the study
The greatest limitation of the study is that it focuses on only one global mining company, albeit the world’s third-largest gold producer. It would have been optimal to test the hypothesis and codification approach with more than one truly global gold producer. Other global enterprises that could be considered within the scope of the study could include Barrick Africa and Goldfields, but the likelihood of those players finding themselves in the same strategic position is slim and the study most probably would not fit their immediate needs.
13
1.8 Layout of the study
The remainder of the research paper will be structured accordingly: Chapter 2 presents the literature study review and empirical research. It will discuss “systems theory” and its relation to EA, and an in-depth review of EA will be done to illustrate how it will support and help to deliver against the strategic objectives and ultimately maximise returns for shareholders. The results of the analysis will be presented in Chapter 3. In the final section, Chapter 4, the conclusion and recommendation will be presented.
14
CHAPTER 2
THE STUDY OF ENTERPRISE ARCHITECTURE
2.1 Introduction
In this section EA will be investigated by setting context around EA and understanding the requirement for EA in organisations. The history of EA will also be reviewed and four of the prominent EA frameworks namely Zachman, TOGAF, FEA and the Gartner meta model will be investigated. The mining house environment will also be reviewed and a brief look will be taken into components that were identified by Gartner(2007).
2.2 Context
The first formal reference to information systems architecture was made in 1987 by J.A. Zachman in an article that was published in the IBM Systems Journal. In the extract of the article written by Zachman, he explains: “With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of a system” (Zachman, 1987). Zachman references the field of classical architecture as analogous to information systems architecture and uses the processes contained in classical architecture to explain the process followed for complex information system architecture.
Zachman uses the following generic set of architectural representations to explain the process of constructing a traditional building (Table to follow on next page).
15
Table 1: The set of architectural representations prepared over the process of constructing a building
Representation Nature / Purpose
Bubble charts Basic concepts for building: Gross sizing, shape, special relationships, architect / owner mutual understanding.
Architect’s drawings
Final building as seen by the owner. Floor plans, cutaways, pictures. Architect / owner agreement on building. Establish contract.
Architect’s plans Final building as seen by the designer. Translation of the owner’s view into a product.
Contractor’s plans
Final building as seen by the builder. Architect’s plans constrained by laws of nature and available technology. ‘How to build it’ description. Directs construction activities.
Shop plans Subcontractor’s design of part / section. Detailed stand-alone model. Specification of what is to be constructed.
Building Physical building.
(Source: Zachman, 1987)
Zachman(Zachman, 1987) states that these architectural components may be generic to the process of building any complex engineering product. Zachman supports this hypothesis by comparing it with the building process of military airframes in the following way:
16
B. Work breakdown structure equals “architect’s drawings or the owner’s view”. C. Engineering design equals “architect’s plans or the designer’s view”.
D. Manufacturing engineering bill of materials equals “contractor’s plans or the builder’s view”.
E. Assembly and fabrication drawings equal “shop plans a detailed view”.
F. Machine tool representation (the machine view) is an extra step that depicts a computer-generated model of the design.
G. Aeroplane equals “building” the final product.
The above example is further explained in Table 2 below, extracted from the article written by Zachman(Zachman, 1987).
Table 2: Generic extrapolation of architectural concepts
Generic Buildings Aeroplanes Information systems
Ballpark Bubble charts Concepts Scope / objectives
Owner’s representation Architect’s drawings Work breakdown structure
Model of the business (or business description) Designer’s representation Architect’s plan Engineering design / bill of materials
Model of the information system (or information system description) Builders representation Contractors plans Manufacturing
engineering design / bill of materials
Technology model (or technology-constrained description)
17 representation drawings Machine language representation - Numerical code programs Machine language description (or object code)
Product Building Aeroplane Information system
(Source: Zachman, 1987)
The construct of using generic architecture to explain systems and systems theory is not new and was initially used by Ackoff (Ackoff, 1995) to explain systemic thinking. Ackoff (Ackoff, 1995) defines a system as a whole that has one or more defining functions and that consists of two or more parts that satisfy three conditions:
Each part of the system can affect the behaviour or properties of the whole.
None of the essential parts can have an independent effect on the defining function(s) of the whole.
Every sub-system or collection of parts can affect the behaviour or properties of the whole and none has an independent effect.
Thus, a system is a whole that cannot be divided into independent parts. This definition has certain implications that should be considered.
The first of these implications is that the product of a system is based in the interaction between the different parts of a system and not the function of the parts taken separately.
The second is that when a system is disassembled, it is not only the system that loses its defining properties but also the parts that lose their defining properties.
When improving the performance of the different parts of a system, the performance of the whole is not improved.
18
Systems theory or systemic thinking supports the logic of a holistic enterprise architecture approach.
2.2.1 The need for EA
According to Gartner(Blosch, 2012), the top priority for CIOs has been to deliver solutions that generate business value for the organisation. This has been the case since Gartner started its surveys in 2003 — to support business objectives with sound IT operating activities that are managed and ran professionally. There is an increased requirement that IT organisations and the EA teams within companies help businesses to reach their goals (Blosch, 2012).
Figure 2 below gives a high-level indication of the top strategies employed by CIOs in large organisations. The strategies identified in 2012 are key components of a codified EA environment.
Figure 1: CIO survey on IT strategies
(Source: Blosh, 2012)
Gartner (Blosch, 2012) realises that business is becoming more complex. Business can, however, not be competitive without the use of technology. Gartner states that EA plays
19
a critical role in business achieving its objectives. Gartner did further research indicating that 46% of the companies in its survey are looking to start or restart their EA initiatives(Blosch, 2012).
Figure 3 on the following page gives an indication of the different stages of codification in companies as researched by Gartner(Tucker, 2005).
Figure 2: Current stages of EA in companies
(Source: Blosh, 2012)
As part of an interview with a group of CIOs, Gartner further identified four areas on which enterprise architects should focus (Blosch, 2012).
Focus on delivering business objectives that are identified by the business. It is important that EA teams understand their enterprises and their strategies and goals. It is also important that they understand the CIO’s strategy and how it aligns with the organisation’s strategy. Gartner identified the following actions for EA teams to follow to achieve this:
o An enterprise context analysis should be conducted to make sure the strategy context and goals are fully understood.
20
o Liaise with the CIO to ensure the IT strategy will support the business strategy.
o Ensure project identification forms part of the EA governance model and that key stakeholders are involved with resource allocation.
Use EA to develop business capabilities such as global collaboration during critical business incidents. The current labour action in South Africa is a good example of this. It is the responsibility of the CIO to look forward and identify business drivers that should be supported by the IT organisation with the aim of enabling technology that will support these business drivers. It is the role of the EA team to support the CIO in identifying and integrating the short-term projects with the longer-term views, and by so doing create the business capabilities that are required by the business. The EA team should focus on the following:
o Start by analysing the business strategies.
o Develop a project portfolio and IT portfolio and put in the effort required to support the business strategy.
o Manage standards and processes to ensure that all projects contribute to the strategy and vision.
Create the information architecture. It is import that information is readily available and accurate. Business is dependent on current and relevant information that will be able to support the business strategy. The EA team should focus on the following:
o Work with stakeholders to build a decision model or matrix capable of identifying what information and stakeholders are required to make decisions within the business.
o Look further than the current information environment for data; possibilities include suppliers and partners.
o Make sure information is represented correctly to the business, and work with the CIO and business intelligence teams to achieve this.
Simplify the IT base. Many CIOs are striving for a lower cost base. This can be achieved by either integrating or simplifying the support base and IT base. The savings can then be reapplied to support the business drivers. CIOs generally
21
depend on the enterprise architects to achieve this. The EA team should focus on the following to support this area:
o Ensure that all technology initiatives support the IT strategy.
o The technology architecture team should identify areas of possible consolidation.
o Identify where new technology can be used innovatively to support all levels of business.
In a paper published by Gartner in 2005, a statement is made that EA is a business-driven process that is being used by IT management to indicate the required information systems and technology that can effectively and efficiently support the business requirements. The EA shows the systemic and technical relationships that exist between applications, infrastructure and business users.
2.3 The history of enterprise architecture
Zachman’s influence in the field was noticeable in the earliest attempts by the US department of defence’s attempt to create an EA framework. It was known as the technical architecture framework for information management (TAFIM) and was introduced in 1994 (Sessions, 2007). The attempt to formalise technical projects within business was noticed by the US Congress, which in 1996 passed a bill known as the Clinger-Cohen Act (Clinger, 1996), also known as the Information Technology Management Reform Act. The act mandated that the federal agency takes action to improve the effectiveness of all IT investments. A chief information officer (CIO) council was created to assist in the governing of this process.
The CIO council began work on its first major initiative during April 1998, and its efforts were directed at the creation of the Federal Enterprise Architecture Framework (FEAF), version 1.1 of which was released in September 1999. During the same period the TAFIM methodology were also retired. In 2002 the CIO council approached the government’s Office of Management and Budget where the methodology was renamed to the Federal Enterprise Architecture (Sessions, 2007).
22
The work that was done on TAFIM was turned over to the Open Group, which in turn grew the framework to what it is currently known as — the Open Group Architecture Framework (TOGAF).
In 2005, Gartner, one of the leading consulting and research houses, acquired the Meta Group, a leading research and advisory group that was successful in the field of enterprise architecture. The acquisition followed attempts by Gartner to build its own enterprise architecture framework. The two companies moulded earlier ideas and work that was already done to form the Gartner Meta process.
Figure 1 on the following page shows a graphic timeline of when the different architecture frameworks were introduced.
Figure 3 The timeline of architecture frameworks
(Source: Session, 2007)
What is an enterprise?
TOGAF defines an enterprise as a collection of organisations with a common set of goals, but it further defines enterprise in the context of enterprise architecture as the total enterprise that is compiled of all its IT service processes. This can also be associated with a specific domain within the organisation(The-Open-Group, 2011).
23
TOGAF further indicates that confusion often arises from the evolving nature of the term “enterprise”, as extended enterprise often includes partners, suppliers and customers. Should the aim be to include the extended enterprise vendors, partners and customers will need to be included in the enterprise architecture effort (The-Open-Group, 2011).
2.4 A review of the most prominent EA frameworks
There are several prominent enterprise architecture frameworks that are employed by organisations with the aim of giving structure to their EA efforts. The review below gives a brief overview of these frameworks.
2.4.1 The Zachman framework
The EA framework, as it applies to large companies, is simply a logical taxonomy that can be used to codify and classify a descriptive representation of the enterprise or company as a whole. These representations are usually for the management of the company and well as new initiatives.
Zachman explains the framework based on two dimensions to build a matrix of viewpoints and artefacts:
The first dimension of architecture caters for different artefacts based on the different viewpoints of all stakeholders involved in the development of the architecture. Every stakeholder involved in the architecture requires a complete set of information, but the completeness of information is defined differently for each stakeholder. For example, the owner of a new house will value a full description of the functionality and layout of the different sections within his house as well as the aesthetics of the house; the builder, on the other hand, will be more driven by descriptions of cable- and water-reticulation systems and support structures. As Zachman said in his original article: “Each of the architectural representations differs from the others in essence, not merely in level of detail” (Zachman, 1987).
24
The second dimension is a descriptive focus on the artefact itself, which implies the ‘what, how, where, who, when and why’ of the architecture. This dimension is not dependent on the first dimension as all stakeholders will have their own viewpoints on the ‘what, how, where, who, when and why’.
The two dimensions help to form a holistic view of the architecture as a whole. None of the viewpoints or artefacts is more important or critical than the others but merely indicate the different components that need to interact to form a functioning whole.
Zachman made the following statement to support this view: “We are having difficulties communicating with one another about information systems architecture because a set of architectural representations exists instead of a single architecture. One is not right and another wrong. The architectures are different. They are additive and complementary. There are reasons for electing to expend the resources for developing each architectural representation. And there are risks associated with not developing any one of the architectural representations” (Zachman, 1987). The diagram depicting these two dimensions can be viewed on the following page, followed by a brief explanation thereof. The full page of the framework can also be viewed in Appendix E.
25
Figure 4: The two-dimensional Zachman framework
(Source: Zachman, 2009)
As can be seen from Figure 4 above, there are a total of 36 unique viewpoints that are generated through the different levels of inference. Figure 4 further shows the 36 intersecting cells in a Zachman grid — one for each meeting point between a player's perspective (for example, a business owner) and a descriptive focus (for example, data). As one moves horizontally (left to right) in the grid, one sees different descriptions of the system — all from the same stakeholder’s perspective. As one moves vertically in the grid (top to bottom), one sees a single focus, but the player from whose perspective we are viewing that focus changes.
26
The second suggestion of the Zachman architecture framework is that an architecture can be considered a complete architecture only when every cell in that architecture is complete. A cell is complete when it contains sufficient artefacts to fully define the system for one specific player looking at one specific descriptive focus.
When every cell is populated with appropriate artefacts, there is a sufficient amount of detail to fully describe the system from the perspective of every stakeholder looking at the system from every possible angle (descriptive focus).
Zachman doesn't give much assistance in deciding if the future architecture we are creating is the best architecture possible. For that matter, Zachman doesn't even provide an approach to show a need for a future architecture. For these and other issues, it is necessary to look at other enterprise architecture frameworks.
2.4.2 TOGAF
The Open Group Architecture Forum, better known as TOGAF, bases its architecture on four dimensions, namely business architecture, application architecture, data architecture and technical architecture.
The list below provides an explanation of the different architecture dimensions (The-Open-Group, 2011).
Business architecture describes the business value chain.
Application architecture describes the design of applications and their interacting attributes.
Data architecture explains how data is stored, managed and accessed.
Technical architecture explains the hardware and software that is used to support application and data architectures and their interactions with each other.
The TOGAF model is successfully employed by the following companies:
Rio Tinto
27
Oracle Corporation
The architecture development method (ADM)
The TOGAF architectural framework is primarily supported by the architecture development method (ADM). The ADM is the process the Open Group uses to build and construct EAs (Sessions, 2007). The model in Figure 5 below shows the flow of the ADM model, which forms the core of the TOGAF framework as described by the Open Group.
28
Figure 5: The architecture development method
(Source: Sessions, 2007)
The TOGAF process supports the Zachman framework very well and should rather be viewed as a methodology or process that can be followed to implement enterprise architecture in any organisation and function. Zachman (1987) in essence guides architectural codification, whereas TOGAF stipulates the process of creating it.
TOGAF assumes the premise that no methodologies or frameworks are followed in the organisation and provides a vertically integrated value chain for new architectural requirements.
29
The ADM consists of eight phases after the preliminary phase. These phases are described below.
The preliminary phase gives context to the architecture process and allows an opportunity to create common understanding and get business buy-in from stakeholders. The enterprise architect should make sure everybody is comfortable with the process and that there is common understanding among stakeholders. This is also the period in which the architect has the opportunity to alter or change the process to suit the organisational culture. The preliminary phase is also the phase in which the foundation governance framework is established.
Phase A, architecture vision: This phase is usually initiated with a request for
architecture. It defines the business requirement of the architecture. Outcomes of this phase should include budgets, scope constraints that should be considered, and all stakeholders that are involved. It is critically important that all stakeholders sign off on phase A to ensure alignment and commitment to the defined scope and target architecture.
Phase B, business architecture: Phase A will be the primary input for phase B, but
phase B will identify the gaps that exist between what is currently in place and what should be created (or architected). Phase B requires detailed analysis of the current situation and target architecture. Through this process a detailed gap analysis should also be completed.
Phase C, information system architecture: Phase C is a detailed analysis of the
information systems architecture. TOGAF has defined a nine-step process to aid this phase of the ADM.
Build a baseline data-architecture description.
Asses and confirm principles, reference models, viewpoints and tools.
Create architecture models, including logical data models, data-management process models, and relationship models that map business functions.
30
Conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders.
Review qualitative criteria (for example, performance, reliability, security and integrity).
Complete data architecture.
Conduct checkpoint / impact analysis.
Perform gap analysis.
Phase D, technology architecture: Phase D focuses on the infrastructure that is
required to support the information system architecture. This task is usually completed by the technical team.
Phase E, opportunities and solutions: Phase E evaluates the implementation
possibilities and opportunities that may exist. Through this phase it is also important to identify the small wins that could add immediate value to the business and address some of the pressing requirements that may exist.
Phase F, migration planning: During this phase the priority for migration and the
associated risks for every project are identified. This phase is closely related to and dependant on phase E.
Phase G, implementation governance: This phase requires the management of issues
and risks that are identified during the previous phases. The governance component will also ensure that the correct criteria are adhered to when implementing architectures.
Phase H, architecture change management: This phase acmes itself on adding and
cumulating any changes that were made to the environment. These changes are written back into the repository and should be available for future reference.
31
The enterprise architecture continuum
TOGAF views enterprise architecture as the range of architectures starting from generic to highly detailed. TOGAF refers to this as the enterprise architecture continuum. The ADM provides the process or method of driving the architecture from generic to specific. TOGAF refers to the different levels in the enterprise continuum as the foundation architecture. It is the most generic system architecture and is common to most organisations and environments. Industry architecture relates to specific industries in which businesses operate, such as the mining industry. The ADM focuses on organisational architecture and creates the relationship between the enterprise continuum and the ADM.
Figure 6: The enterprise continuum
(Source: Sessions, 2007)
TOGAF is not prescriptive in the way the enterprise continuum is applied. TOGAF does not provide structured templates that should be complied with but rather gives the enterprise the ability to morph and structure the ADM according to its needs. One of the prerequisites of the ADM is to review the components of the ADM and to ensure that the components are applicable to a specific organisation.
32
TOGAF merely provides a reference methodology that can be followed to achieve EA for an organisation.
2.4.3 Federal enterprise architecture (FEA)
The federal enterprise architecture presents as the most complete architecture framework as it has both a taxonomy and an architectural process that can be followed so it can be viewed as either a methodology or an outcome of the architectural process (Sessions, 2007).
The FEA is, however, described as architecture model that consists of five reference frameworks, namely: business, service, components, technical and data. But the FEA goes somewhat further in providing a perspective on how enterprise architecture should be viewed. The FEA includes the above-mentioned set of reference models as well as the process for creating an enterprise architecture, a migration process to move from pre-EA to post-EA, a taxonomy that helps to catalogue assets and methods to measure the success of the architecture implementation and the business value that were derived. From this, it is clear the FEA is an extensive EA approach. The FEA was, however, designed for a governmental organisation and does not strictly apply to the private sector, but it is the only framework that comprises all the different processes and architectural components(ANON, 2001).
The FEA builds its view based on the fact that organisations are the combination of different segments, which can include departments such as human resources and administration. It further classifies these segments into two categories, namely the core mission-area segment and the business-services segment. The core mission-area segment describes segments or departments of the business that are core to the functional operation and revenue-generating ability of the business. The business-services segment can be viewed as foundational to most organisations and most listed companies will be supported by a human resources department and a financial or accounting department or segment.
33
The FEA recognises another EA asset — an ‘enterprise service’, which is something that spans the political limitation that which may be associated with other segments or functions. Security is a good example of a service that spans the whole organisation. The fact that segments are defined globally facilitates their reuse across political boundaries. One can map out the usage of segments across the political boundaries of the enterprise and then use that map to seek opportunities for architectural reuse. As shown in the figure on the following page (Figure 7), there are many departments (the vertical columns) that are used in multiple organisations, and any or all of these are good candidates for sharing.
Figure 7: Segment map of the federal government
34
FEA reference frameworks
The aim of the five reference frameworks is to create common understanding among peers with the purpose of supporting communication, cooperation and collaboration across boundaries.
It further helps to address and define a framework that is capable of describing elements of the FEA in a consistent fashion. The five reference models are:
1. The business reference framework: This framework represents the business view of several functions within the operating environment. The business reference model allows for systems extrapolation and will add or provide better understanding to the role of a business function in a specific environment, as well as which subsystems are contained within it and which systems are supported by it.
2. The components reference framework: This framework gives a more analytical view of the environment by explaining which technology or IT system supports which business function or requirement, and describes how it is being technically achieved.
3. The technical reference framework: This framework defines the technology standards that should be applied throughout the organisation and how the technology is applied in the organisation. Bi-directional traffic on firewalls will happen only when the origin and destination can be specifically defined.
4. The data reference framework: This framework defines the ways in which data is described and referenced in the business. As an example, data should be normalised and not repeated; the same data should rather be referenced.
5. The performance reference framework: This framework defines the way EA value is measured. A good example of this would be to have a metric in place that measures how well technology supports the business requirements as stipulated by the business.
35
The FEA process
The FEA process centres on the creation of segment architecture for a subset of the complete EA. The overall development process for the FEA is described briefly below (Session, 2007).
The four steps are:
Step 1: Define a simple, terse vision of the department and reference it back to the organisational plan, also referred to as the “architectural analysis”.
Step 2: Define the desired architectural state of the department or function. Define and document the performance metrics, consider different design options and develop an EA that is inclusive of business, data, application and technology architecture.
Step 3: Finance and investment strategy — work on efforts to get the projects financially supported.
Step 4: Programme management. This is a crucial component of delivering EA. The effective delivery of projects will assist the effective implementation of the EA strategy. The mere implementation of EA does not guarantee it is done effectively. The FEA addresses this by introducing metrics to measure successful implementation.
There are three main categories the FEA engages to measure the maturity level of the EA implementation.
1. Architectural completion: Measure the maturity level of the completed architecture in the organisation.
2. Architectural use: How well the architectural processes are used in the organisation to support and guide architectural decision-making.
3. Architectural results: The business benefits that are being gathered by the organisation as a result of the EA implementation.
36
Based on the results gathered from the maturity assessment, a rating is assigned to the department and organisation, which is then categorised accordingly:
Green: The organisation’s level of implementation is fairly high. It also scores high with its use of architectural processes and there are reasonable levels of value generated from its implementation.
Yellow: The organisation has implemented EA and it rates well in either the architectural use or the architectural results.
Red: The organisation has either not implemented EA or the implementation has not yet reached completion.
2.4.4 Gartner / Meta process
Gartner describes EA as nouns rather than a term. This implies that the presence of EA in an organisation represents a constant effort to build, maintain and continue to EA in the organisation. Previous, outdated architecture that adds little value to the organisation, the taxonomy or processes becomes useless and arbitrary.
Gartner believes that EA comprises three stakeholders, namely: business owners, information specialists and technology implementers. It is Gartner’s view that these three components can find synergy and work together towards a common business goal that supports business objectives and will ultimately deliver business value. EA can be viewed as successful only if you have achieved this.
It is Gartner’s view that EA should start with the business strategy and what the business wants to achieve, and it should not be focused on the current situation of the business. To use an analogy to illustrate this — when renovating a house, it is a good idea to know what should change and what the objectives are, but it is not necessary to keep extensive documentation on everything you remove or demolish.
Gartner’s recommendation is to start with the business strategy and focus on the business drivers. Gartner further suggests that the approach be kept simple and transparent without making use of complex, ambiguous terms and enterprise-related
37
jargon. The main aim of the EA should be to ensure that everyone involved shares the same vision for the business and the supports efforts to achieve this.
It is important that the business is aware of the magnitude of change that comes with the effective implementation of EA. Once a shared vision has been established, it will be possible to consider the business, data, application and technology architectures for the vision and scope. The shared vision will guide the different architectures with the aim of supporting the shared vision. These architectures should be prioritised to ensure the business drivers are continuously supported.
Gartner chooses a strategic approach to EA over a technology-based approach. Central to Gartner’s process is the business’ vision and how it plans to achieve it. Gartner often refers to this approach as the “just enough” or “just in time” approach.
2.5 Problems associated with the implementation of EA
Although it is common practice for most large enterprises to have an EA department or structure in place, CIOs in most cases do not fully utilise its availability and do not benefit from the functional outcomes that can be realised through EA. Gartner believes that if the CIO is not sufficiently involved in the EA process, the functions will simply be perfunctory and enjoy little or no benefit from EA The lack of proper metrics to benchmark EA in organisations further obscures the value of true EA in large organisations (Tucker, 2005). Gartner further indicates that the EA processes are often viewed as an obstruction to business achieving its goals and are hence avoided by many CIOs.
The implementation of EA is not always met with great anticipation. EA has been used by organisations for more than 10 years and yet has led only to a misleading and malleable set of terms and references (Gaver, 2011).
Gaver (2011) illustrates this sway by referencing some of the common jargon used in the EA real:
