Bank 1 Case Study

BABOK: Bank 1 Case Study

Student’s Name

INF80014 Contemporary Issues in Business

Instructor

Date

BABOK: Bank 1 Case Study

Introduction

In this paper, the following knowledge areas of BABOK, i.e., enterprise analysis, elicitation, requirement analysis, and solution assessment and validation, will be applied as a lens when analyzing why the Bank 1 architects were unable to develop stakeholder support and commitment for the enterprise architecture implementation or EAI. The paper will apply the BABOK knowledge areas to show that the competencies linked with regular business analysis can also be used in other areas of IS practice, including enterprise architecture. This discussion will utilize the BABOK knowledge areas as a guiding tool for interventions in relational challenges between stakeholders and IS practitioners.

Case Study Description

The focus of the case study was examining the clash between architects contracted by Bank 1 to implement the Banks new strategy to make changes to its existing enterprise infrastructure. The key players and actors of this process included the bank’s executives, architects, and other bank stakeholders. The Architects were primarily involved in two main activities. First of all, they selected new hardware and software products to build the platforms and systems that have been specified in the enterprise architecture plans. This task was to run from June 2011 to December 2011. The architects presented the plans for their selected software and hardware products, including the work products, to senior executives within the bank’s business divisions to gain approval. The other main activity that the architects had been involved in was the Architecture Review Board. In mid-2011, the CIO set up the Architecture Review Board tasked with reviewing the software and hardware changes proposed by new and existing new technology projects within the bank. Some of the architects’ problems included not liaising with technology and business stakeholders when selecting the various software and hardware products. They believed that they should not focus on the business process and that their role was to first and all define the technology components and the implementation plans. The architects believed that they were supposed to build the technical capabilities the best way they knew how irrespective of what the business wanted. This led to some pushback from other stakeholders that felt that their views and preferences were not incorporated in the project. This discussion will apply the BABOK knowledge areas as an effective lens to analyze why the Bank I architects could not nurture stakeholder support and commitment for the enterprise architecture implementation or EAI.

Knowledge Areas of the BABOK

The acronym BABOK stands for Business Analysis Body of Knowledge and is associated with the following organizational bodies: business process management, agile development, and business architecture and business intelligence. It is a universally accepted standard developed after a rigorous consensus-driven standards process (Tătaru & Fleacă, 2019). It incorporates the collective experience and wisdom of experts in various fields from across the globe. It provides definitions of knowledge and skills needed by business analysis professionals that cover the key knowledge areas of a business analysis competency model (Nkomo & Marnewick, 2021). I believe that BABOK is necessary in evaluating and analyzing this case study because it contributes knowledge and practice from experts on business intelligence and architecture. It is, therefore, a viable tool to be used as a lens in this case study that discusses Enterprise Architecture Implementation. The knowledge areas of BABOK are business analysis planning and monitoring, elicitation and collaboration, requirements life cycle management, strategy analysis, requirements analysis, design definition, and solution evaluation.

Business Analysis and Planning

The architects got significant stakeholder support for the deliverables to be produced. This was done during the initial meetings with executives during the six months before the project formally commenced. However, there was no significant stakeholder support on the process to be followed, techniques to be used, and how the enterprise architecture implementation would be monitored. This was because the architects mainly believed that they should concentrate on the project’s architectural goals. They mapped the main architectural objectives to the available commercial-off-the-shelf hardware and software products. These were generic products that were not tailor-made to any specific project. They mostly worked amongst themselves and did not seek any external input from key stakeholders in the business after initial approval. The criteria they used emphasized performance and architectural goals that represented significant improvements to the existing bank’s technological portfolio. The organization’s technology and business staff were not involved during the design of the evaluation template. As a result, while these criteria could have reflected the architects’ concerns and values, they only represented a partial understanding of the requirements since they took minimal consideration of what was critical to the business, particularly when choosing the new hardware and software products.

Elicitation and Requirements Management and Communication

Elicitation and collaboration describe how the architects contracted for the project work with business stakeholders to elicit the key requirements. It allows them to understand the stakeholder concerns and needs. This BABOK knowledge area addresses ongoing communication and collaboration during the project analysis activities (Sousa et al., 2018). The architect’s task list for this particular knowledge area is made up of the following: preparation of the elicitation activities, meeting the stakeholders and carrying out the elicitation activity, documenting, confirming, and recording the elicitation results, and finally confirming and communicating elicitation results with the key stakeholders. The architects’ approach only enabled elicitation of stakeholders’ requirements when they met the stakeholders to conduct the elicitation activity. They only met the directors and executives at the beginning of the project. Once the project commenced, the architects were only consulting amongst themselves. Their requirements management approach could be described as a pragmatic and aloof approach. They only concentrated on the architectural and technological aspects of the project. They did not get insights on how to tweak the project according to the platform users’ unique requirements and demands as the project progressed.

Enterprise Analysis

In enterprise analysis, the architects are supposed to plan how to approach the business analysis effort. This stage includes templates, processes, and activities used when performing enterprise analysis in a specific context (Tătaru & Fleacă, 2019). These monitoring and planning activities are expected to take place throughout the lifecycle of the project. The architects did not make room to understand and realize that stakeholder requirements could change during the project. They isolated themselves from the bank employees, thus forming a wall between themselves and critical stakeholders.

Requirements analysis and solution validation and assessment

Requirement analysis, solution assessment, and validation describe how the architects should progressively elaborate, define, refine, organize, and prioritize the bank stakeholders’ requirements (Nkomo & Marnewick, 2021). In essence, the architects should take the elicited information and make sense of it to derive the real project requirements. Solution validation and assessment concentrate on assessing and validating proposed solutions before, during, and after the project’s life cycle. The architects’ attention in this case study should have been on the value that the solution would deliver to the bank and its stakeholders. The architects’ isolationist approach prevented them from understanding that the stakeholder requirements could change since they only took views from a small clique of stakeholders, the directors. They also failed to progressively monitor any business environment changes that could have elicited stakeholders’ preferences. The architects wrongly assumed that the initial project agreement with the directors is cast in stone or rigid and should not be flexible in design and scope. In principle, the architects understood the kind of solution that the business wanted but failed to incorporate the critical needs of other stakeholders. The EAI is one solution since it only solved the architectural or technological problem without incorporating the business and personnel solutions. This shows that enterprise architecture is difficult to formulate and change since it has numerous stakeholder interests and works in a dynamic business environment.

Why architects could not build stakeholder support and commitment

The key points from the analysis are that the architects were wrong in isolating themselves and only consulting amongst themselves. Their practices inhibited them from building a collaborative relationship with stakeholders since they put a lot of distance between them and the bank’s stakeholders. It is important that IS practitioners build collaborative relationships to ensure they accurately diagnose the problem and prescribe a working solution according to all the business and stakeholder needs (Nkomo & Marnewick, 2021). The outcome of failure by IS practitioners to give adequate attention to objectives, priorities, and stakeholder assumptions is that the project may fail to live up to its expected deliverables.

What you would do differently as an IS practitioner

As an IS practitioner, I would include a representative from different business stakeholders in our consultation rooms. This would enable me and other involved in the project to constantly have a finger on the pulse of the organizational needs and changing requirements. It would ensure that all the deliverables match the stakeholder preferences and business needs.

Conclusion

This assignment has enabled me to learn more about applying BABOK knowledge areas to enterprise architect implementation. It has provided me with an insight into the critical practices that should not be overlooked in the BABOK knowledge areas. I realized that a functioning new architectural infrastructure might fail to meet an organization’s expectations if the stakeholders are not involved throughout its development and deployment.

References

Nkomo, A., & Marnewick, C. (2021). Improving the success rate of business process re

engineering projects: A business process re-engineering framework. South African

Journal of Information Management, 23(1), 1-11.

Sousa, P., Tereso, A., Alves, A., & Gomes, L. (2018). Implementation of project management

and lean production practices in an SME Portuguese innovation company. Procedia

computer science, 138, 867-874.

Tătaru, I. M., & Fleacă, E. (2019). Technologies for Modeling Business Processes. FAIMA

Business & Management Journal, 7(2), 31-41.