Silvius alignment model

Silvius (2007) defines business – IT alignment as “the degree to which IT applications, infrastructure and organization, the business strategy and processes enables and shapes, as well as the process to realize this” and argues that IT efficiently and effectively supporting the business strategies and processes is key to organisational success. Silvius (2007) is of the opinion that alignment can be viewed as either a state or a process. State refers to the level of alignment achieved while process refers to the activities required to contribute to a specific state of alignment. Specific pragmatic tasks are recommended to achieve alignment, opposed to the traditional model approach.

Subsequent to conducting focus groups with practising CIOs in the industry, Silvius (2007) proposes a list of alignment practices. The creation of an overview of the current enterprise application portfolio is recommended to raise awareness of the cost of IT. Centralisation of procurement contracts will assist in organising buying power. The formalisation of project governance will assist with project authorisation, prioritisation and scheduling as well as stakeholder management. The creation of standards, for example, software and hardware standards is recommended to achieve economies of scale and control. Rationalisation of the enterprise application portfolio is recommended to obtain cost savings in support of effectiveness and efficiency.

Silvius (2007) determined that CIOs view business – IT alignment as probably more dependent on a clear vision, and awareness of business executives of IT, as well as IT management skills, as on a methodology. Business – IT alignment is seen as a dialogue between business and IT. It is collaboration, more than business proscribing to IT. Business – IT alignment directly relates to the maturity of the relationship between business and IT. It involves business and IT in a healthy partnership with open-ended effective communication.

29

Achieving the above state of business – IT alignment requires business and IT professionals to be equipped with specific skills and competencies to be able to foster this relationship. This requirement is not referred to by Silvius (2007), and no mention is made of specific skills and competencies required.

2.2.7 Conclusion

The above examination of SAM theory and models introduces the human element in business – IT alignment. Luftman and Brier (1999) argue that people management skills are critical to ensure that relationships are built and maintained. They refer to the traditional focus on technical skills when recruiting and developing IT professionals and argue that organisations are starting to include interpersonal skills such as active listening, negotiation and team building in the education of their IT professionals. In summary, neither Luftman and Brier (1999) nor Luftman (2003) refer to the EI construct, or any of the elements of any of the EI models reviewed in this literature survey, as a suggested element potentially contributing to business – IT alignment.

Reich and Benbasat (2000) introduced the concept of social alignment and stressed the importance of communication between business representatives and IT executives. Smaczny (2001) supports the importance of communication by suggesting a fusion between business and IT functions. Silvius (2007) also supports the importance of communication and dialog between business and IT executives and also stresses the importance of a mature relationship between the two parties.

However a gap in the SAM literature exists with regard to the non-technical skills and competencies required of IT professionals in order to align business and IT. The human is neglected in the SAM literature, with very little guidance provided on which „human‟ skills, characteristics or competencies are needed to advance business – IT alignment.

Various popular approaches to EA as a method to address, amongst others, business – IT alignment, will be explored in the next section. EA frameworks, as well as schools of thought on enterprise architecture, will be explored in terms of the human in enterprise architecture tools widely used by business and IT stakeholders.

30 2.3 Enterprise Architecture

The concept of EA was born in the late 1980s to address aspects such as developing an overall architectural vision for an organisation, system complexity, poor business – IT alignment, cost, agility and reducing time-to-market (Lucke et al., 2010). Various approaches to EA have been developed in an effort to address these challenges and specifically the business – IT alignment challenge. The Zachman Framework for Enterprise Architecture, The Open Group Architectural Framework (TOGAF), The Federal Enterprise Architecture and the Gartner Methodology are arguably the most well-known and popular alternatives generally in use (Sessions, 2007). These alternatives, however, do not address the skills and competencies required by the IT professionals who utilise these EA tools to achieve business and IT alignment. This gap in the literature could potentially lead to the ineffective utilisation of EA tools. This could result in inappropriate decisions, which could negatively impact business – IT alignment.

There is contention in the literature on whether some of these approaches should be named a framework, approach, methodology, or ontology – as well as other alternatives (Sessions, 2007). The next section will explore each of the above alternatives in more detail. Mention will be made of the appropriate terminology if relevant to the particular approach. For the purpose of exploring the alternatives, the term approach will be used. Before exploring approaches to enterprise architecture in more detail, it is appropriate to define the term „enterprise architecture‟.

Most definitions of EA include describing an organisation in terms of its information, applications and technology, and linking those to the organisation‟s business strategy (Stenzel, 2007). The Open Group (2012) views an enterprise as a collection of organisations that has a common set of goals. An enterprise can be a complete organisation or a division or department of an organisation. Sessions (2007:5) defines architecture as “the fundamental organization of a system embodied in its components, their relationship to each other, and to the environment, and the principles guiding its design and evolution”. Enterprise architecture is defined as an architecture where the relevant system is the complete organisation, including all the business processes, technologies and information systems (Sessions, 2007:5). The Open Group (2012) argues that enterprise architecture can include all of the information and technology services, processes, and infrastructure in an organisation.

The Zachman Framework for Enterprise Architecture, The Open Group Architectural Framework (TOGAF), The Federal Enterprise Architecture, and Gartner Methodology, as well as the

31

Information Management Body of Knowledge Framework (IMBOK), are discussed in the next section.