The Factors affecting Institutionalisation of Enterprise Architecture in the Organisation

Tiko Iyamu Department of Informatics

Tshwane University of Technology Pretoria, South Africa

iyamut@tut.ac.za

Abstract— Despite impressive technical advances in tools and methodologies and the organizational insights provided by many years of academic and business researches, the underperformance of Information Technology (IT) remains.

In the past and even today, organizations experience difficulty in managing technology, changing from system to system, implementing new technology, maintaining compatibility with existing technologies, and changing from one business process to another. These problems impact significantly on business performance and will continue to do so if not addressed. As a result, many organizations have deployed EA in an attempt to address these challenges. However, the design and development of EA has proven to be easier than its institutionalization. The study explored the development and implementation of EA to determine the factors, which are barriers to its institutionalization. Two case studies were conducted.

Keywords-Institutionalization; EA; Deployment; Factors

I. INTRODUCTION Over the years, there have been efforts to improve IT

operations, most critically, its relationship with the Business and its role in the vision and strategy of the organization. This has led to improvement in the processes and activities in the computing environment of many organizations. According to [1], the areas include systems development methods, project management, and in the development of information systems and technology strategies. Despite these efforts, some organizations still find it difficult to realize the full potential of their IT investments and others are considered woeful. Unfortunately, none of these efforts seem to have solved the problems of how to ensure that the organization’s goals are properly met, and that the best value is achieved from investments in new information technology infrastructure [2, 3].

EA is a technical mechanism which defines the role of the business, information, technical and application architectures that best enable the business needs of the enterprise, and it provides the migration plan, which moves the enterprise from the current to the future architecture. This definition is provided to guide the study.

In the last decade, EA has become a popular topic of debate and discussion in recent years, primarily in the IT industry but also elsewhere. Despite the interest, it is very difficult to find an organization that has successfully

designed, developed, implemented and institutionalized the EA concept. In some organizations, EA has been well developed as a blueprint but was never implemented [4], while other organizations experienced problems during implementation [5, 6]. In a similar study, [7] points out that “Many organizations face complex and unwielding challenges in assessing and articulating the components required in the implementation of EA in their organizations.” Institutionalization of EA has not been a smooth process. This is attributed to the importance attached to the subject.

In this study, institutionalization is the process where a practice is assimilated into the norm. It is not easily disassociated, dismantled or re-designed. Callon refers to institutionalization as the degree of irreversibility, which depends on (i) the extent to which it is subsequently impossible to go back to a point where that translation was only one amongst others and (ii) the extent to which it shapes and determines subsequent translations [8].

The general expectation is that EA is a promising means of reducing the development cycle time and cost, thus improving quality, and leveraging existing efforts by constructing and applying multi-use and reuse of assets such as patterns, components, and frameworks [5]. The study explored whether, in practice, there is conspiracy which makes EA difficult to be delivered more successfully than one is led to believe by debates and discussions [9, 10].

As such, the problematisation, development and implementation of EA are critical to the success or failure of its institutionalization. The enrolment of employees in the implementation of EA primarily dictates its competitive advantage particularly in large organizations. EA is fundamental to IT strategy, which is the most important component of the computing environment.

Some of the challenges in the deployment of EA include skill-set. According to [11], not everyone is an architect. Other challenges include the lost of alignment between IT and Business.

The study adopted a case study, interpretive research methodology.

II. RESEARCH APPROACH Two organizations, a financial institution and a

government institution, were selected on the basis that each provides a good example of an organization subject to

2009 IEEE Conference on Commerce and Enterprise Computing

978-0-7695-3755-9/09 $25.00 © 2009 IEEE

DOI 10.1109/CEC.2009.57

221

change, and each provides some evidence of success and failure of institutionalization of EA.

TABLE I. CASE STUDIES DEMOGRAPHY

Job Title Company A Company B Senior 5 4 Technology Junior 4 3 Senior 4 3 Business Junior 3 3

Total 16 13 As illustrated in Table 1 above, the financial institution is

referred to as “Company A” and “Company B” the government institution. There were 450 and 180 employees in the computing environments of Company A and Company B, respectively.

The questionnaire was designed to elicit individual and group involvement and understanding, and how the subject matter is practiced in the organizations. The case material has been drawn by different means including questionnaires, structured interviews [10] with some of the key players, documentary sources and ad hoc observational and experience-based notes.

As shown in Table 1, the number of interviewees varied, based on the size of the organization. A set of balanced respondent demographics was a key factor in achieving a true reflection of the situations. Targeted respondents were from different units and were at various levels of the structure within the Business and IT departments. They included Analysts, IT Architects, IT Managers, IT Project Managers, IT Executives, Business Managers, Network and Systems administrators.

This paper focuses on the factors, which are barriers to institutionalization of EA in the computing environment and the entire organization. In such a context, an interpretive research approach [12, 13] is appropriate in order to understand influences from the perspective of social context within the organization.

The study has three lines of investigation. Firstly, the research uses an interpretive perspective to investigate the relationship between technical and non-technical factors in the development and implementation of EA. Secondly, it investigates the organizational structure within the computing environment in the development and implementation of EA. This area of investigation was more carefully phrased because of the sensitive nature of the subject. Finally, the study focuses on the influencing factors in the practice of EA.

Qualitative research approach was selected mainly because it allows for clarification from respondents to questions from the researcher, while the researcher, through close interaction with interviewees, can develop a deeper understanding of the situation. Qualitative research, it has been argued, is a very useful method for complex situations [14].

The research questions were analyzed at two (macro and micro) interconnected levels. The macro-level addresses issues on how EA is developed and implemented in the

organization that deploys it. At the micro-level, the implementation of IT strategy is analyzed from the perspective of its institutionalization. The empirical data of the study were analyzed and the results are presented in the section, which follows.

III. ANALYSIS OF EA DEPLOYMENT Through the interpretive approach, data from the two

case studies were combined in the analysis, as well as in the presenting of the results. The focus was the barrier to institutionalization of EA in the organizations.

The study revealed that EA is typically developed and implemented with the intention of significant benefits at the level of strategic information technology implementation and business engineering. Also, in practice, the organization expected EA to enable rapid change in an enterprise’s business processes and activities. The deliverables of EA were primarily carried out through its domains - Enterprise Business Architecture (EBA), Enterprise Information Architecture (EIA), Enterprise Technical Architecture (ETA) and Enterprise Application Architecture (EAA).

Each of the component architectures provided a unique view of the enterprise leading to its own capabilities. In both organizations, the EBA was intended to provide the tools, models, techniques, and participants to manage the impact of change on business processes and partners. According to [15], this practice is supported by EIA to enable the management of change on information exchange; the ETA, to enable the management of change on technology infrastructure, and the EAA, to enable the development and portfolio management of application.

In the development and practice of EA, special skills were needed. Not all IT specialists can be architects without the opportunity to learn and practice the tools and techniques required. A lack of skill implies both the inability to perform competently as well as the inability to recognize and deliver the full potential of EA. Even where the process was understood, there was evidence that the potential and objectives of EA were not realized. It thus appears that experience of successful architecture will be important in achieving future success.

When it came to EA, there was feeble relationship between the IT and Business departments of the organizations. This was as a result of the hierarchical structure of the organizations. Some of the employees protected their domain from control being taken over by the EA team. Consequently, there was no sufficient input from the business during development and implementation of EA. As a result, there was more concentration and focus on the Technology and Application architectures than Business and Information architectures. This has led to more investment on both Technology and Application Architects than other domain architects.

The analysis of the empirical data revealed that simply defining EA exposes gaps in business processes and strategy, information technology and systems strategy, and the relationship between Business and IT departments of the organization. The process obliges employees to confront difficult questions and make hard decisions they had

222

previously managed to avoid, such as redeployment of certain employees who did not have appropriate skill for the position they hold. This was to make easy and possible the institutionalization of EA in the organizations.

In one of the case studies, the organization formulated a policy to guide the deployment of EA into institutionalization. The policy was to ensure successful design, development, implementation and maintenance of EA, through fundamental principles. These principles were basic philosophies which were intended to guide the process from the problematisation to institutionalization stages. The principles apply to all the domains of EA. They provided guidelines and rationales for the constant examination and re-evaluation of technology and systems plans. This approach is however not new; it is supported by [16]. The principles were generally derived from an intensive discussion with senior IT and Business Managements, then validated in discussions with the highest IT Committees. Non-technical factors such as financial budget, personal or group interests and the capability of the organization influenced the formulation of these principles.

The primary object of the institutionalization of EA was to provide methods, processes, disciplines, and organizational structures to create, manage, organize, and use models for managing the impact of change. The research finds, in both case studies that typically organizations did not take a holistic view, and that the practice of EA was deficient when measured against the organizations’ requirements. This has been acknowledged and was attributed to a manifestation of lack of cooperation and understanding between the individual Business and IT departments of the organizations. In Company A, one of the senior managers expressed his frustration as follows:

“I’d lock all architects and senior business management in a room for a week or two, and only allow them out once I was satisfied they understood each other’s role. Once the appreciation for each other’s contribution is understood, I’d expect a less expedient approach towards “establishing business capability” and in this climate, architecture would have a better chance of being able to contribute to its full potential.”

The sequence of the EA development phases - business visioning (extracted from business strategy), defines and refines the respective domains, EBA, EIA, ETA and EAA. This was conveyed in a logical sequence of development, which was based on relationships and dependencies of these phases, rather than a linear sequence of events.

The scope of EA was therefore the union of the enterprise, the business engineering and development that was applied to it, and the technical domains that supports it. Thus the scope of EA was defined through a pragmatic need: the need to design and redesign as well as continuously as was intended, to improve the functioning of the organization.

During the study, it became evident that EA defines the scope, scale and nature of required changes within an organization and that it helps to identify the resources that must become involved. There were validation points or checkpoints during the development and implementation of EA. These were influenced by factors, which result to

negative and sometimes positive outcomes. This was the case in both companies. But it was more visible in Company B, where an architect opined as follows:

“I’d change the way we fund technology initiatives. I’d make silo’s illegal. I’d teach “community” concepts to the business and attempt to demonstrate the value of synergy. I’d get greater CEO support - he needs to understand that architecture really is a business issue, not a technology thing. I’d financially reward those that pursue properly architected routes and disincentives those that don’t. I’d either centralize architecture (ALL the interrelated disciplines) probably physically or at worst establish a capacity to govern all architecture teams as if they were a single unit. And I’d make architecture a mandatory.”

The study indicates that problems routinely experienced in organizations include a perception of poor value for money from IT investments. It revealed that this was as a result of poor linkage and alignment between the strategic goals and IT investments of the organizations. When the business environment is dynamic, and when unavoidable change is forced upon the organization an inability to link exploitation of IT investments with changes to strategic business goals leads to greater difficulties.

IV. RESULTS The above analysis was interpreted and the results

presented as follows: This study examined the development, implementation

and practice of EA in two organizations. This was done to establish and determine the barriers to the institutionalization of EA in the organization which deploys it. As revealed by the analysis, there are four key elements in the development and implementation of EA. They include adaptation, innovation, uniformity and alignment:

A. Adaptiveness EA requires adaptiveness. This enables it to effectively

and efficiently build, maintain, and apply the entire domains of EA. It is more beneficial when it is applied uniquely to specific needs of the organization, depending on its business strategies, architectural maturity, priorities, organizational culture, and political environment.

B. Innovation The EA engineers innovations through its processes, and

activities in the organizations. Each of the various domains (as defined by the organization) of EA has their various deliverables in relation to innovations. The primary aim of the continuous innovations was to enhance competitive advantage of the organization’s businesses, processes and activities.

C. Uniformity EA provides a uniform process and procedure for

selecting technology infrastructure, of documenting the current business, the future business, and the gap between the two. This is important and applies to the autonomous business units of organizations. It begins from project initiation and problematisation to implementation stages.

223

D. Alignment The analysis revealed that EA will not work if there is no

understanding between the Business and IT Managements. The lack of cooperation manifests itself to rivalry on many issues including in the methods and selection of technology, Business process standard, Governance approach and Assessment criteria. This has a serious influence on the practice of EA in the organization.

Only when the above identified key elements are made norm through the EA that institutionalization becomes feasible. Unfortunately, other critical factors influence and impact the above key elements of EA in its success or failure. The interrelationship between the key elements and critical factors are illustrated in Fig. 1 below. If not well managed, the manifestations of these factors could derail the institutionalization of EA in the organization that deploys it. The factors discussed below.

Barrier EA

Element Organizational Structure

Adaptiveness

Economic Investment Administrative Process

Innovation

Organizational Politics

Uniformity

Technical Capability Business Buy-in

Alignment

Figure 1. Barriers to Institutionalization.

The analyses of the case studies revealed the following factors as the impediments and barriers to the institutionalization of EA in the organizations:

A. Organisational Structure Design, development, implementation and support of EA

require a deep understanding of technical needs and business vision and requirements. As business processes change, projects are initiated and technology grows, it becomes hard to structure an organization to provide effective feedback loops which run between these constituencies. Although EA is intended to address this very area, if the organization is predisposed to managing them badly in all circumstances, then EA will not be an effective solution.

Employees use the enactment of power to manoeuvre activities and processes within the organizational structure. Power as mandated was exercised to protect individual and group interests rather than the interests of the organization in the practice of EA.

B. Economic Investment Supporting EA requires an economic investment,

particularly if EA operates as cost-centre. Many organizations find it difficult to institute appropriate measures to fund their cost-centre because the benefits are only indirectly evident, and rarely are they evident as simple

financial benefits. Most architects are not able to articulate, translate and quantify their work into monetary value. This could be attributed to non-immediate realization of their contributions. As a result, its value is hotly contested by the business stakeholders.

C. Administrative Process The nature of EA as a process oriented makes it

inevitable to align with the administrative process and the structure of the organization. However, it is difficult to catalogue, archive, and retrieve the “as-is” (or silo) architectures across multiple business units within large organizations. Although it is common to scavenge small classes or functions opportunistically from existing programs, architects often find it hard to consolidate suitable architecture outside of their immediate area. This could be achieved through effective and efficient administration of processes and activities. A domain manager (manages specialized architects) who report to the Chief Architect or Chief Technology Officer is therefore recommended.

D. Organisational Politics Employees both in the IT department and in the Business

units often view architects with suspicion. This is because they resent the fact that they may no longer be empowered to make key technology and related decisions. They also perceive a threat to their job security and resource control. There is also rivalry between architects and other IT specialists over domination.

These factors manifest themselves to acts of organizational politics, which result in lack of trust and cooperation. The factors have a negative impact on the relationship between the Business and IT departments on one hand and on the other, between the IT specialists and Architects.

E. Technical Capability EA efforts often and frequently fail because architects

lack the appropriate skills, and the enterprise at large lacks the competencies necessary to deploy EA. Most Architects are appointed on the basis of their seniority in the organization. For instance, architects often lack knowledge of, and experience with, fundamental design patterns in the domain they are assigned to.

As a result many of the Architects lack the abilities, knowledge or skills required to effective deploy EA. This was attributed to lack of awareness to narrowness in vision, leading to very different interpretations and definitions of EA. This leads to incompatible views about the full range of EA processes and phases that are required and deprives the participants of any possibility to achieve best practice, through a failure to take the holistic view of what must be done. This makes it hard for them to understand how to implement the EA frameworks and components effectively.

F. Business Buy-in Strategy for communication with the Business is critical.

Poor communication with the business leads to a general view that architecture is not important. If EA is not

224

understood, the business always finds difficulty in getting “buy-in” into the concept. As a result of lack of buy-in, EA will always fail to achieve its aims and objectives.

An emphasis on technical architecture increases lack of interest and understanding of EA by the business. Arising from these factors is new pressure on IT departments to improve value for money, but many would argue the IT department has no means to achieve it because of the gulf between it and the business. EA addresses this gap, but if it is not supported or sponsored by the business then it – the EA – will also fail and the problems will remain.

Many organizations face complex and unwieldy challenges in assessing and articulating the changes necessary in their organizations. This includes the factors, which influence the practice of EA across the entire organization. If an organization is to be successful in bridging the context gap between development and implementation of EA, a mechanism must be deployed to articulate the impact of the influencing factors on the enterprise.

The factors revealed above are critical to the success or failure of EA, which create barriers to the institutionalization of EA in the organization.

V. CONCLUSION The contribution of the study arises from implications for

the key stakeholders, sponsors and architects responsible for the deployment of EA in the organization. They need to understand the factors impacting the institutionalization of EA, in which they wholly play parts and more importantly, how to mitigate against the risk posed by these factors.

A further contribution of this study is its aim to be of significance to decision makers, managers and employees of the organization within the computing environment. It is expected that the key contribution will arise from the understanding of the fundamental elements through which EA impacts change. Through this, a better understanding of the contribution of non-technical factors in the deployment of EA will be gained.

Also, academia needs to take cognizance of the dynamics and causes of what, why and how EA could be institutionalized in practice.

REFERENCES [1] M.A. Cook, (1996). Building enterprise information

architectures: reengineering information systems, Prentice-Hall, Inc., Upper Saddle River, NJ.

[2] S. Gibson, (1998). Evangelizing about Enterprise Architecture, PC Week, 09/21/98, vol. 15, Issue 38, p78.

[3] J.A. Zachman, (1996). Enterprise Architecture: The View Beyond 2000, Conference Proceedings, Warehouse Repository Architecture Development 7th International Users Group Conference, Technology Transfer Institute.

[4] F. Armour, S. Kaisler and J. Bitner, (2007). Enterprise Architecture: Challenges and Implementations. HICSS, 40th Annual Hawaii International Conference, System Sciences, vol. Issue, pp. 217 – 217

[5] S.H. Spewak, (1992). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology, John Wiley & Sons Inc., New York.

[6] T. Iyamu, “Strategic Approach used for the Implementation of Enterprise Architecture: A Case of Two Organisations in South Africa,” Proc. Informatics and Semiotics in Organisations (ICISO 09), IFIP Press, April 2009, pp. 100-108,

[7] J.A. Zachman, (1987). A framework for information systems architecture, IBM System Journal, vol. 26, no. 3, pp. 276-292.

[8] M. Callon, (1991). Techno-economic networks and irreversibility. In: J. Law, (ed.), A sociology of monsters. Essays on power, technology and domination, pp. 132 – 164. London; Routledge

[9] R.W. Watson, (2000). An Enterprise Information Architecture: A Case Study for Decentralized Organizations. HICSS, p. 7059, 33rd Hawaii International Conference, System Sciences, vol. 7.

[10] R.K. Yin, (1994). Case Study Research, Design and Methods, 2nd ed., California, Newbury Park; Sage Publications.

[11] B. Burke, (2007). The Role of Enterprise Architecture in Technology Research, Gartner Inc. publication.

[12] W. Orlikowski AND J.J Baroudi, (1991). Studying Information Technology in Organizations: Research Approaches and Assumptions, Information Systems Research, vol. 2, no. 1, pp. 1 – 31.

[13] G. Walsham, (2006). Doing Interpretive Research, European Journal of Information Systems, vol. 15, no. 3, pp. 320-330.

[14] M.D. Myers, (1997). Qualitative Research in Information Systems, MIS Quarterly, vol. 21, no. 2, pp. 241 – 242.

[15] D.W. McDavid, (1999). A standard for business architecture description, vol. 38, no. 1. Enterprise Solutions Structure. IBM Systems Journal.

[16] R. Youngs, D. Redmond-Pyle, P. Spaas, and E. Kahan, (1999). A standard for architecture description, vol. 38, no. 1, Enterprise Solutions Structure.

225