#begin
Learning Unit (LU) 6 dives deep into the trenches of strategic and operational changes that affect EA as a whole. We will look at how to manage changes, how to monitor the EA, and what beneficial purposes come with EA documentation and the dynamics of IS alignment in the context of IT and EA. Let’s take a look.
Using A CO-Evolutionary IS-Alignment Approach To Understand EMR Implementations
I think we hit the jackpot on this one! This paper is written by, not just one, but four out of four authors from the OU itself! This is great! The paper builds on co-evolutionary IS-alignment (COISA) theories and argues that current approaches to business-IT alignment in hospitals should be conceptualized, particularly regarding modern EMR implementations.
But what the heck is this COISA you might wonder, well in the paper the authors describe that: “COISA implies that alignment is a continuous process including two-way interactions between business, IT and external parties and between strategic and operational alignment processes”. And may provide a holistic understanding of interrelations between different stakeholder groups and strategic operational alignment processes.
In this paper the authors aim to assess how COISA can be used to gain knowledge of the dynamic capabilities in hospitals and they seek to refine and validate COISA theory for organizations facing complex decisions.
The authors also provide us with some definitions that may come in handy not just reading this paper but also future papers:
| Alignment process | working definition |
| Strategy formulation | The process of defining strategic objectives that the organization wants to achieve. |
| Strategy implementation | The process of setting up and maintaining structures to ensure that strategic objectives are realized in the operational context of the organization. |
| Enterprise Architecture Management |
The process of managing an organization’s architecture. |
| IT implementation | The process of embedding an IT solution within an organization. |
| IT usage | The process of employing a system to perform a task. |
Next they provide some information about the research design and method, which I’m definitely not going to repeat. You should read it yourself. They also present a very nice visual about which stakeholders are involved in each alignment process. This is a really great and readable visualization. It shows a quite a bit similarities among the hospitals that were involved in the research process.
This research indicates that: “COISA is suitable to demonstrate and visualize the alignment process interactions during EMR implementations and provides an insight into the interrelations between strategic and operational alignment and co-evolution between stakeholders”. They found that co-evolution takes place within all processes in all case hospitals and they found evidence of interrelations between the different processes. But, the level of interrelations differed among the case hospitals.
Another very interesting finding was that doctors, and nurses where involved and had executing roles in all processes. This feels intuitive to me since they are the subject matter experts and thus are able to provide some hands-on information.
Main contributions of this research are that COISA theory is a great framework to investigate and visualize different stakeholder perspectives and interrelations between strategic and operational contexts. Furthermore, they refine and empirically validate their COISA model in an EMR implementation and thus add to the knowledge base of Business and IT-alignment (BITA) generally and COISA specifically.
Designing an Artifact for Informal Control in Enterprise Architecture Management
This paper explores the use of nudging in the form of labels to drive awareness for EA. Nudging means that decision making of local entities may be changed by altering the way in which choice alternatives are presented. A label is a form of nudging, like a energy label for a house, or a ‘sustainable’ label on food packaging. These labels try to encourage people to go for the best options in a non-invasive way.
I really like this idea and it’s applicability with EA. So this research tries to define labels and attach them to certain artifacts, technologies, services or products used in a company. This may drive employee decision-making for the better.
The research question this paper aims to answer is the following: “How should an Enterprise Architecture Label be designed and implemented so that local decision makers opt for alternatives favoring an enterprise-wide perspective“.
The label they came up with really looks like a common label used in housing here in The Netherlands. It has simple levels A to F which match with 5 components: 1) Match to target architecture, 2) Match to technology targets, 3) Average age of application, 4) Costs per IS user in domain, 5) End user satisfaction. You should check out the paper to view the label yourself!
From the research it appears that ALL interviewees supported the idea of introducing the label to trigger an assimilation of a decision-making practice that considers an enterprise-wide perspective. This label would be a very effective trigger to start discussions among stakeholders.
From this the researches conclude that an EA Label is an appropriate extensions to promote enterprise-wide decision-making.
I thought this paper was a nice read, and encourage you to read it as well.
Embedding EAM into operation and monitoring
This third “paper” is a chapter from a book called: Strategic Enterprise Architecture: Challenges, Best Practices and future Developments, Management for Professionals by F. Ahlemann et. al. I remember that I wrote a blog about starting this course and that we would use this book. In the first lecture it became clear that the teachers thought that the book was a bit outdated and thus we don’t use it anymore. So we have only one chapter now apparently.
The chapter is about how to run EA, managing operational changes, monitoring EA and using EA documentation and other management implications. This chapter aims to answer three questions: 1) How should operational changes be managed, 2) How should the enterprise architecture be monitored, 3) Which further beneficial purposes can EA documentation be used.
They start of explaining that operational changes need to be ACID: Atomic, consistent, isolated and durable. I think everyone working with databases knows this acronym. This is often used to describe robust database transactions. The authors say that EA supports ACID in several ways: EA analysis techniques help check and approve the consistency and isolation of requirements. If the EA documentation is updated after implementation, it contributes to atomic and durable changes.
The first thing you need to do is to collect the changes, then assess the changes because they are probably EA relevant. EA-relevant changes either have significant impact on an EA component by modifying its characteristics, or entails significant side-effects in other EA components. Lastly, you must implement the change if deemed acceptable.
The monitoring of EA can be difficult for organizations. The authors describe that many organizations still struggle to define suitable key performance indicators (KPIs) for EA monitoring. Defining KPIs is popular in fact-based management approaches, yet studies reveal that even EAM forerunners are still at an early stage, either defining EA-related KPIs or running simple EA reports. Currently, IS and IT infrastructure layer monitoring are among the most advanced EA monitoring areas, but are often undertaking by means of fairly simple KPIs.
Next they describe the concept of an EAM Cockpit to track KPIs related to the most important aspects and EA initiatives. This cockpit has 3 jobs: 1) The EAM cockpit must monitor the EA impact in business terms, which is the EA’s efficiency and effectiveness at achieving business and IT goals. 2) The EAM cockpit should track the EA’s current status, with a specific focus on EA conformance with defined targets and the enforcement of architecture principles and guidelines. 3) The EAM cockpit should also capture EAM adoption in the organization by measuring EAM-related activities and skills. They also provide a very nice visual of this cockpit but you should check it out yourself if you have access to the book.
Then they get into describing how you should use EA documentation. The authors note that many EA initiatives begin by modelling and documenting the organization’ architectures yet most EA documents are only used during such initiatives and only by the EA architects. Benefits of these documents outside the EA initiatives and other stakeholders can also greatly benefit from these documents.
The authors provide a nice table of the different stakeholders and how they might benefit from EA documentation. Again, if you have the book, check it out. Main points where to use the EA documentation include, but are not limited to, business continuity and risk management and compliance management. The first is about recover operations in case a disaster or emergency hits. Business continuity consists of three phases: 1) analyze and develop a comprehensive contingency plan; 2) provide procedures to ensure continuous operations; 3) conduct ongoing analysis to improve business continuity management. They also specifically note to make dependency graphs of your architecture. This way you can easily see what goes down in certain situations. The latter is about adherence to regulatory guidelines and principles as well as internal data protection and security standards.
The chapter ends with some implications for management: 1) EA-relevant changes must be evaluated! 2) existing KPI’s must be displayed according to EA components and layers and make sure KPI reporting covers three dimensions: EA’s status and conformance, how well the EA supports the company in meeting business objectives and EA adoption as measures by availability and quality. 3) Getting the most from your EA documentation.
Conclusion
The second paper in this reading spree was the most interesting one. I like the idea to label certain choices. This does not necessarily make some decisions inherently bad, but simply slightly worse than others. This reminds me of the use of language in the agile manifesto. We like the things on the right, but we just link the things on the left slightly better.
Next blog we are going to take a deep dive into Archimate modelling!
#end
01010010 01110101 01100010 01100101 01101110.
References:
Article 2: https://aisel.aisnet.org/icis2019/design_science/design_science/3/
Recent Comments