In terms of naming standards, Sessions (2007) refers to the Gartner Enterprise Architecture Framework (GEAF) as a practice as opposed to taxonomy, process or methodology. Gartner, however, refers to the term „methodology‟ or „framework‟. The GEAF as illustrated in Figure 2.8 below is a proprietary framework resulting in very little guidance available in the literature on how the methodology should be used. The success of the GEAF lies in the intersection of the business owners, information specialists and the implementers of technology in an organisation (Sessions, 2007). The GEAF is represented by the intersection of four layers, namely, business relationships, business processes, patterns, and bricks, with various domains as part of technical and information architecture (Keltikangas, 2006). Bricks are the lowest level and represent components used to implement architectural patterns. The architectural patterns consist of technological components which assist in fulfilling the business processes on the next highest level. The information architecture encompasses the data, application, integration and point of access domains. The technical architecture includes the infrastructure, systems and security domains.
43
Figure 2.8: The Gartner Enterprise Architecture Framework (Keltikangas, 2006)
Based on stakeholder analysis presented in the case of TOGAF and FEA, the GEAF will require collaboration between business and IT role players such as executives and architects on the same scale and level. This collaboration is not possible without support of specific collaboration and the team-work skills and competencies of the actors involved in implementing EA in the organisation. Examining the available literature on GEAF, no evidence could be found of any recommended skills and competencies which could potentially contribute to a more successful outcome using GEAF.
The above discussion on The Zachman Framework for Enterprise Architecture, TOGAF, FEA and GEAF as well-known and popular alternative approaches to EA, illustrates the absence of non-technical skills and specifically EI in these EA tools. The alternatives provide for relationships between various stakeholders driving business – IT alignment. This gap in the EA literature illustrates the limited value placed on non-technical skills by the IT community. The main schools of thought on EA, according to Lapalme (2012), are discussed in the following section.
44 2.3.5 Schools of thought on Enterprise Architecture
Lapalme (2012) contends that three main schools of thought on EA are found in the literature. These are Enterprise IT Architecting, Enterprise Integrating and Enterprise Ecological Adaptation. Enterprise IT Architecting involves aligning the IT assets of an organisation through strategy, design and management. In this school of thought Lapalme (2012) sees EA as the glue that holds business and IT together. Enterprise Integrating as a school of thought on EA involves designing all the facets of an organisation to facilitate execution of enterprise strategy by maximising the overall coherency between all its facets, including information technology. In this case, Lapalme (2012) views EA as linking strategy and execution. The Enterprise Ecological Adaptation school of thought entails fostering organisational learning by designing all the facets of an organisation, including relationship with and adaption to the environment. Enterprise strategy creation and organisation design are also included in this school of thought. In this third category, Lapalme (2012) views EA as a means to achieve innovation and sustainability. Lapalme (2012) does provide some indication of skills needed by the enterprise architect in each of these schools of thought.
In the Enterprise IT Architecting school, the enterprise architect is seen as a planner and designer with primary challenges being communication and getting buy-in from stakeholders for his plans of the future organisation. Focus is placed on technical competence and engineering knowledge as EA skills. Lapalme (2012) does not provide any indication of which non-technical skills are required from the enterprise architect to successfully communicate and acquire buy-in from stakeholders for his future plans. No reference is made to EI either.
In the Enterprise Integrating School, the enterprise architect is seen as a facilitator. The enterprise architect needs to be able to facilitate small groups, collaborate with business and IT, and apply systems thinking. Lapalme (2012) argues the enterprise architect needs facilitation skills, systems thinking, and illustration and collaboration skills. This is progression from absence of non-technical skills to some level of non-technical skills. Lapalme (2012), however, does not refer to EI required in the role of enterprise architect.
In the Enterprise Ecological Adaptation School, the enterprise architect is seen as a nurturer. Lapalme (2012) contends the enterprise architect needs to be able to build dialogue between business and IT stakeholders, assist the audience with making sense of proposed architecture,
45
and facilitate large groups. No reference is made to which non-technical skills or EI are required from the enterprise architect.
2.3.6 Conclusion
The above examination of enterprise architecture frameworks, as well as schools of thought on enterprise architecture, illustrates the absence of the human in enterprise architecture tools widely used by business and IT stakeholders to address, amongst others, business – IT alignment. Various taxonomies, frameworks, methodologies and practices are available to assist business and IT role players with aligning business and IT strategies. However, a gap in the literature exists with regard to the non-technical skills and competencies required of the IT professionals who need to use these EA tools in order to align business and IT. The human is neglected in the EA literature, with very little guidance provided on which „human‟ skills, characteristics or competencies IT professionals such as the CIO, enterprise architects, business analysts, systems analysts and project managers require to foster dialogue and collaborative relationships among business and IT. These „human‟ skills and competencies, amongst other constructs, will be explored in the next section.