Enterprise architecture (EA) has provided organizations with powerful frameworks with which to plan, manage, model and coordinate the alignment of organizational IS/ IT portfolios with organizational strategy. However, for the benefits of EA to be realized, it needs to also contribute to the process of implementing the specified systems and platforms. Whilst implementation was seen by early authors as an integral aspect of the EA process, it has since generally been ignored by authors, or investigated through an ontological lens of discreet technical architecture activities that does not account for the social context of an EA implementation (EAI). Drawing on an actual case study of an EAI in a large Australian financial services organization, I examine the importance of the EAI process to the delivery of the systems and platforms specified in the EA plans and highlight an alternative perspective that has the potential to sensitize scholars and practitioners appreciate to the social context of an EAI.
TopCase Study Description
Bank1 is a large Australian bank and operates internationally. The EA process was initiated by the architects in response to a change in strategic direction of the organization. In Bank1, the architects are structurally differentiated from the business and are situated in the technology function. They are also structurally differentiated from other technology units due to their strategic and IS/ IT portfolio design focus (as distinct from operational support and project delivery focus. Once the EA plans were approved by the executives of the business and technology, the architects began to select the hardware and software products that would realize the changes to the IS/ IT portfolio specified in the EA plans and to develop an implementation schedule for the delivery of those products into operation. As the architects owned the EA process, they were responsible for building support and commitment for the selected technology products with business and technology stakeholders. All technology projects at Bank1 are funded by the business and are staffed by specialist technology staff. It was therefore critical that the architects build connections with stakeholders from both the business and technology in order to realize the IS/IT portfolio improvements described in the EA plans.
The architects at Bank1 viewed their EAI role in technical terms and their objectives were to select new systems and develop implementation plans to deliver those systems into operation. The practices of the architects effectively created an impermeable boundary around them and made it difficult for information to flow into and out from the architecture team. When selecting the software and hardware products, the architects mapped key architectural objectives to available commercial- off-the-shelf (COTS) software and hardware products. Working amongst themselves, they developed evaluation templates and criteria to help them assess the suitability of various COTs products. The criteria emphasized architectural and performance goals (i.e. strategy alignment, flexibility, scalability, interoperability) which represented important improvements to the existing architecture of Bank1’s technology portfolio. However, business and technology staff were not involved in the design of the evaluation criteria and whilst these criteria may have reflected the values and concerns of the architects, they represent a partial understanding of requirements since they take little account of what is important to the business, especially when selecting new software and hardware products (cost versus benefit, manage costs, continue to make a profit, etc.). The architects also paid little attention to the concerns and information needs of technology and technology project staff and did not engage with them. They would not discuss the selected technology products with technology project staff which meant that the business and technology were potentially investing in and implementing technology products that would be replaced by the EAI. The architects also made it difficult for people to engage with them as their preferred method of communication was via a wiki. The architects were virtually inaccessible to technology staff and gave little consideration to their expert understanding of the existing architecture and its technology components.
When the architects presented the plans for the selected hardware and software products and the programs of work to the senior executives of the business divisions for approval, these executives were reluctant to commit to funding the hardware and software products and the programs of work specified by the architects, and eventually the implementation of the EA was abandoned altogether. Consequently, there was no overarching technology vision at Bank1 and the business divisions developed and implemented their own architectures for their own particular needs rather than the requirements of the organization.