Solution and Details of the Case Study Project
Background to the EA Practice
As part of continuous efforts to transform the organization to a more resilient and modern enterprise, the ADNOC EA Practice was established in 2012 with a strong belief in the role of people in transformational efforts. Accordingly, a federated practice with the various domains (Business, Data, Application, Technology, and Security) was established with architecture expertise belonging to the various functional verticals within the IT division and the Corporate Support function, in addition to six core EA Team members. The EA capability is spearheaded by the EA Team Leader who reports to Vice-President IT (who is also the CIO) through the IT Planning and Strategy Manager.
The EA Practice evolved in an evolutionary manner like any other practice through stages like resource mobilization, upskilling of the team, and creation of strategy/scope/vision. In the initial stages there was no repository of data and no standards. The EA Practice worked towards creating the foundations for architecture by setting up tools and standards. The EA Practice currently uses a tool called UNICOM System Architect™. This tool – originally called IBM® Rational® System Architect, a state-of-the-art tool when initially acquired in 2012 during the time when the EA Practice at ADNOC was started – has limited capabilities and hence the EA Practice is evaluating to replace it with a state-of-the-art EA Tool soon.
The TOGAF Standard, a standard of The Open Group [TOGAF 2022] was adopted to establish the EA Practice. The TOGAF Standard provides a holistic and structured approach to the enterprise beyond IT. Initial phases included a tailoring of the Architecture Development Method (ADM) to suit the organizational context and maturity and establish a methodical approach to architectural projects. That was followed by the acquisition of an EA Management platform to help capture and communicate the architecture. Figure 3 depicts the tailored ADM methodology by ADNOC’s EA Practice.
As the EA Practice matured, it started to engage in each project and institutionalized the practice of architecture-oriented thinking for each project. At any point, the EA Practice team is spread across multiple projects that are at different stages of their lifecycle. APM was one such project under continuous improvement efforts that was taken up by the EA Practice team starting August 2019. Accordingly, and given that the project was initiated and conceptualized by the EA Team, the ADNOC Onshore Architecture Development Method (AADM) and the content framework were a natural fit for this purpose.
Creating and applying a framework that directly addresses the inefficacies in the drilling portfolio provides a unique opportunity to dig deep into the applications supporting the portfolio and understand the dynamics of user productivity and satisfaction. By asking the right questions, the stakeholders can articulate and share their experience, concerns, and aspirations enabling a better understanding of the portfolio. This leads to the identification of improvement areas that can be implemented through a structured roadmap. With this understanding, the EA Team introduced a framework to assess the applications that support the drilling portfolio from functional and technical perspectives in collaboration with business and IT stakeholders.
The motivation behind this project is to use EA to create a business tool to address the accumulated inefficacies in business capabilities by establishing a framework that takes a holistic view of the applications underlying these capabilities. The efficiency of organizational capabilities is directly impacted by the quality of the applications that automate their business processes and support them. The continuous accumulation of applications introduces technical, operational, and financial burden to the organization if the fitness of the applications is not jointly assessed by all stakeholders concerned. Due to rapid business change, applications quickly became outdated resulting in decreased productivity and declined user satisfaction.
The project concept for APM that was executed at ADNOC is depicted in Figure 4.
Project Phases and Activities
The details of the project activities and tasks for each phase of the project are listed in Table 1.
Table 1: Project Phases and Activities
| Project Phase | Activity/Task |
|---|---|
Scope Identification |
The project team used the capability model to identify a target portfolio. After various assessments, the drilling portfolio was selected due to its significance. |
Assemble the Team |
The project core team comprised of the EA Team support by the Business Relationship Management Team (BRM Team) from the IT Planning and Strategy department of the IT division. The extended team was the IT Drilling Solutions team from the IT division along with the Subject Matter Experts (SMEs) from the drilling business function. |
Development of Assessment Criteria |
The project team drafted the assessment criteria that cover the technical and functional perspectives of the applications. The criteria were circulated for review by all stakeholders, and their feedback was discussed and incorporated as applicable. |
Technical Assessment |
Technical assessments were conducted with the IT custodians of the applications in four workshops. The focus was on base technology alignment, modernization, extensibility, and technical execution. Each one of these criteria was given a score and supported by a rationale. The final score and comments were endorsed by the IT custodians. |
Functional Assessment |
Functional assessments were conducted in joint workshops attended by IT custodians and drilling SMEs. The assessments covered strategic fit of the application, information quality (input, output, correctness, and timeliness), functional value (productivity, capability support, utilization, and uniqueness), and user satisfaction (training, ease-of-use, documentation, interface, application performance, and IT support). Each one of these criteria was given a score and supported by a rationale. The final score and comments were reviewed and endorsed by all attendees. |
Develop Dashboard |
The collected information was reviewed by the core project team, the IT custodians, and the drilling SMEs to ensure accuracy. A dashboard was developed and made available to all stakeholders concerned. |
Develop Implementation Roadmap and Execution |
Based on the findings, a set of recommendations were made and discussed; accordingly, a roadmap was created and endorsed by all stakeholders. The execution of the roadmap started soon after the assessment was complete. |
During these project phases, the team used the Baseline (as-is) Architecture, which was developed during earlier iterations, to define the future improvements which were then formalized into a set of recommendation during Phase E: Opportunities & Solutions. The recommendations were grouped into work packages and prioritized into a roadmap with clear ownership and endorsement in Phase F: Migration Planning.
The implementation oversight took place in Phase G: Implementation Governance, and the implementation updates were reflected into the Baseline Architecture as appropriate in Phase H: Architecture Change Management. The details of the architecture phases within the project and the activities therein are listed in Table 2.
Table 2: Architecture Phases and Activities
| Architecture Phase | Activity/Task |
|---|---|
Phase A: |
Through a series of workshops, the following goals were accomplished:
|
Phase B: |
By leveraging the capability model (developed in an earlier iteration), the following goals were accomplished:
|
Phase C: |
Selection of target applications and the aspects that need to be assessed were developed. |
Phase D: |
Finalize the technology aspects to be assessed pertaining to the underlying technologies of the applications in scope. |
Project Tools and Techniques
UNICOM System Architect*
This was a tool used as the repository to hold Architecture Building Blocks (ABBs):
-
Architecture Viewpoints[1] §13: Stakeholders, Architecture Views, and Viewpoints.] as the viewpoint library for the project deliverables and concrete views
-
Stakeholder Management Technique as an approach to manage the varying interests and often conflicting priorities of the stakeholders
Capability Modeling
This key model was created internally by the EA Team part of the foundational as-is cycle. It was the main tool that enabled the EA Team to select the candidate portfolios for assessment. It provided a functional view of the project scope and helped in promoting the project among senior stakeholders as a business rather than a technical initiative. The business process capability model is highlighted in Figure 6 and summarized in Table 6: Learning Aspects and Lessons LearnedTable 5.
Dilemma – Options/Alternatives
During the project there were three instances where the project team faced dilemmas and had to evaluate the alternatives to choose the right fit option for the purpose. These are described hereunder.
The Right Approach to Select the Pilot Application Portfolio
The project team considered two methodologies for selecting the right application portfolio for the pilot project. The dilemma was between a value stream approach versus a capability-based mapping approach. Every one of the stakeholders understood the business capabilities as a common foundation and hence capability-based mapping [Yilmaz] was chosen as the right approach over the value stream approach.
Data Gathering Mode from Stakeholders
Customer satisfaction surveys coupled with the annual demand cycle and ad hoc requirements were used to capture the level of customer satisfaction and customer demands. While this resulted in an indication of how these applications are viewed by their users, it never provided a 360-degree analysis of the functional and technical aspects of the solution. Most importantly, these surveys provided an aggregated or averaged personal view but never a common view of the results and benefits into which everyone buys. Hence, additional information regarding the applications is necessary to understand the full perspective of applications. With respect to gathering this additional information, workshop versus questionnaire to gather this data was a fundamental decision to be made: either choose workshops and risk the project timeline or use questionnaires and sacrifice the open dialog. The workshop approach was selected to maximize the value of the open conversation among the business stakeholders and the IT stakeholders. This approach paid off during the workshops as it provided the users with different insights that they didn’t previously have.
Tool/Mechanism to Communicate Project Findings and Outcomes
The next dilemma was how to communicate the project findings. The options were to either use the EA platform, which is limited in visualization and less directly used by the business stakeholders, or use an alternative option. Since the user interface and experience of UNICOM System Architect was not conducive for use by all stakeholders, the Microsoft® PowerBI® software tool was used to develop drilling analysis and roadmap dashboards (architecture views) based on the content from the Architecture Repository. It was a platform that most stakeholders are familiar with, and accordingly facilitated the discussion and acceptance of the models. This helped communicate the project outcomes easily.
Project Stakeholders and their Activities
The various stakeholders who worked on the project and their roles are described in Table 3. From this, the level of intensity of various tasks can be gauged together with the amount of coordination and agreement that is required in enabling the success of APM projects.
Table 3: Stakeholders and their Roles in the Project
| Stakeholder(s) | Role in the Project |
|---|---|
Drilling Management |
Validate project outcome, commit resources. Worked with them by participating in drilling meetings and sharing the final project outcome with IT Management and Project Sponsorship to commit IT resources. We worked with IT Management to seek the project endorsement, seek direction, endorse the project roadmap, and approve the findings and recommendations. |
IT Drilling Solutions Team |
Review the assessment criteria, participate in workshops by providing technical expert judgment, articulate productivity inhibitors, and commit to roadmap initiatives. Project team worked with them at various stages of the project during formal and informal meetings, most importantly during the early stages of the project to explain the purpose of the project and after the workshops during the recommendation endorsements. |
Drilling SMEs |
Review the assessment criteria, participate in workshops by providing functional expert judgment, articulate productivity inhibitors and key pain points, review and endorse the findings and recommendations. The project team worked with them during various stages of the project for promoting the concept and explaining the project expectations. Informal discussions were also done for the purpose of building the relationship and to clarify the project findings. |
BRM Team |
Review the assessment criteria, participate in workshops and review project findings, commit to roadmap initiatives. BRM is under the IT Planning and Strategy department. Accordingly, the project team had a high level of collaboration with them. |
EA Team |
These were the core members of the project team. They were involved to conceptualize and promote the APM practice, design the evaluation criteria, promote the solution within IT and targeted business units, propose recommendations, develop reports, facilitate workshops, and develop the roadmap and implementation oversight. |
Project Facts and Insights
Table 4: Project Insights: Size and Stakeholder Details
| Stakeholder Departments | Drilling, Dom (BAB), User Support (Drilling), Engineering (BAB/NEB), Drilling Operations, Equipment, Well Services, Business Planning, Drilling Services (Planning & Cost Estimation), Reservoir Engineering (Surveillance) Management, Operation Subsurface Management, IT Application Corporate, IT Drilling Solutions, Business Relationship Management, Enterprise Architecture |
|---|---|
Project Budget |
In-house project (only resource cost based on extent of participation) |
Outcomes and Benefits
The project resulted in the following outcomes:
-
Improved understanding of the applications due to the knowledge captured for the following elements:
-
Application versus functionality mapping
-
Obsolete/duplicate applications (which were eventually retired)
-
Application interfaces
-
-
Improved understanding of applications in turn led to improvements in productivity and efficiency of the users
-
APM roadmap which led to optimization via retirement and/or consolidation; this outcome resulted in the following quantitative benefits:
-
License cost reduction
-
Reduced maintenance and infrastructure costs
-
Lesser operating and administrative expense
-
Project Output/Artifact Samples
Capability Model
The capability model contains the core and supportive organizational capabilities (organization on a page). Refer to Figure 6 to understand how a capability model may look. The capabilities are mapped to underlying applications.
The full list of business functions and applications is masked due to the business sensitivity of this information. However, in summary the various capabilities of ADNOC are mapped to underlying applications and categorized as Core and Support Capabilities as depicted in Table 5.
Table 5: Summary of Core and Support Capabilities for ADNOC Onshore
| Core Capabilities | Support Capabilities |
|---|---|
Exploration and Development Production and Operations Drilling Engineering Health & Safety (HSE) |
Human Capital Corporate Planning and Strategy Finance Human Capital and Supply Chain Security and Governance Services and Relations IT and Telecom |
Drilling Portfolio Analysis Dashboard
This model was developed to summarize how the portfolio is “seen” by the various stakeholders. Besides the functional and technical fitness of the applications in the portfolio, it contains information on utilization, capability support, and user satisfaction among many others. This is a key deliverable that was fed into the drilling transformation roadmap. Figure 7 shows a snapshot overview of an application and Figure 8 provides a snapshot of the summary of the application portfolio in scope.
Drilling Transformation Roadmap
The roadmap outlines the execution plan for the endorsed recommendations along with their owners. Figure 9 and Figure 10 depict a snapshot of the APM roadmap and recommendations status, respectively.
The project objectives were successfully met. The project provided new insights to IT and business stakeholders alike. Now there is a better understanding of the stakeholders’ behavior. The project roadmap was endorsed and implemented. Some of the implemented recommendations included:
-
Retirement of some applications
-
Providing the business users with some autonomy via self-service Business Intelligence (BI) reports
-
Upgrading technology components
The project findings were presented to the Drilling Management and additional phases of the project were requested. Some recommendations are being implemented on other portfolios as well.
Key Learnings
-
Complex problems can be addressed by simple solutions. This accentuated the power of architectural thinking in looking at problems holistically and asking the right questions.
-
Breaking organizational silos is imperative for the enterprise’s progress. Having a common endorsed view of the portfolio has also helped all stakeholders see how others perceive the problem.
-
It was recognized that this customer-centric approach to architectural projects produced higher value and higher acceptance rates, leading to higher chances of success as they bring positive change to the stakeholders concerned. This resulted in demands to apply this framework to other organizational capabilities.
Opportunities for Improvement
Table 6: Learning Aspects and Lessons Learned
| Learning Aspects | Details of Lessons Learned and Improvements Proposed |
|---|---|
Communication Management |
The workshops sometimes steered outside of their defined scope because of the different levels of stakeholders who participated in the sessions. Despite extensive communication, there could be emphasis on specific aspects to remove the unnecessary ambiguity associated with the project. This is one area of opportunity for improvement to enable reduced delays and scope creep. |
Outcome Management |
This project iteration was exploratory in nature. However, the future iterations should have upfront focus on some areas while keeping the exploratory nature. |
Expectations Management |
Purpose and expectations need to be reiterated time and again. At times it was tempting for some stakeholders to use the workshops to articulate specific requirements which deviated the agenda of the meetings. |
Change Management |
This project can be viewed as an attempt at using architectural thinking to increase customer satisfaction. There is a need for a holistic effort to promote the concept and establish EA as a game-changing capability to accentuate the impact of institutionalizing the EA capability. |
Strategic Value with Organization-Wide Adoption
Besides the direct outcome of the project, the key benefit of the project is emphasizing the role of architectural thinking and how it can look beyond processes and technology and focus on the human aspect. The project:
-
Demonstrated how little improvements can change the way business stakeholders perceive applications
-
Created short feedback loops that help maximize the return on investment
-
Recommended having continuous business justification practices to be implemented using stage gates where business need must be present throughout the application development; i.e., stop development if the justification is no longer valid
-
Recommended implementing value-assurance practices that ensure the application continues to deliver the anticipated value after its release
While subjectivity cannot be eliminated for such problems, it can be minimized. Collectively, the project provided the facts behind the portfolio which enabled decision-making beyond the recommendations proposed by the project. This is a paradigm shift from doing what we ‘think’ is right, to doing what ‘is’ right, and is aligned with the business needs.
The following benefits were recognized within the IT department as well.
With a focused application delivery, and a clear description of the problem and pain areas:
-
IT can have better alignment with the business and address issues in a more focused manner
-
IT can also prioritize their work based on high-value features
-
IT is enabled with better decision-making about the applications due to better understanding of application usage rates and patterns and the reasons behind their existence; some such decisions are:
-
Retiring some unused applications and saving operational costs
-
Minimal investment in applications to improve their utilization
-
Rejuvenate some applications with minor updates
-
The architectural approach employed in the project was endorsed by all key stakeholders. This led to a common user-friendly and visual platform for fact-based decision-making. It was recognized that this customer-centric approach to architectural projects produces higher value and has higher acceptance rates which leads to higher chances of success as they bring positive change to the stakeholders concerned. This resulted in demands to apply this framework to other organizational capabilities.
The future roadmap includes a periodic assessment of the portfolios and the inclusion of financial and operational perspectives to the exercise carried out with the stakeholders concerned.
Innovation and Impact
ADNOC Onshore is still pioneering this capability among the group and within the United Arab Emirates (UAE). Over the last decade, the EA Team introduced innovative solutions to organizational challenges bringing efficiencies the organization as well as promoting EA as a practice and a pivotal organizational capability.
At the practice level, the EA Team is transforming the architectural capability within the organization to support the overall transformation of the organization. It is working hard to reshape the architectural effort by growing from the traditional EA to an outcome-driven architectural practice capable of supporting ADNOC, to delivery on the Oil & Gas 4.0 mission.
The project benefits were communicated internally and at the group level as part of EA communications planning. They were also used to kick-start the assessment of other portfolios which made acceptance much easier. In addition, the following messages were communicated to show how the project helped to establish EA as a change enabler:
-
It is a unique project that leverages EA to address organizational efficiencies
-
It is a strong belief of the project team that this is a must-have project for organizations looking for ways to address inefficiencies in their business capabilities
The outcome of the project made it desirable among management, which resulted in demands to roll it out to other organizational capabilities. The inclusive nature of the project speaks to the intention of having EA as an enterprise-wide capability.
The project was introduced to the organization as a customer-centric EA initiative. It leveraged previous work done by the EA Team through multiple iterations to capture the as-is landscape and progressed it into a value-adding project. While the project added direct value to the targeted portfolio, it proved that architectural thinking can be used to address challenges like risk mitigation, customer-centricity and satisfaction, application modernization, IT-business alignment, and promoting IT as a business partner.