#begin

 

So for the Enterprise Architecture (EA) course I’m doing now we need to read a lot of scientific literature. This first learning unit (LU) is all about what EA actually means and why it is necessary for organizations to do EA. There are many different opinions about what EA is depending on industry and time-frame. From the literature, it is clear to me that EA is still an evolving field of research. There is still a lot to learn and this field is ever changing due to advances in technology and the way businesses are driven. Think about what has changed in the past year or two for example; work-from-home is here to stay which definitely has a big impact on EA.

In this short blog I want to write down some of the most important things I read in the literature. This LU required us to study four articles. So without further ado, let’s take a look

 

Enterprise Architecture and enterprise architecture artifacts: Questioning the old concept in light of new findings.

The first paper we needed to read was all about which artifacts are associated with EA. I think this is a great way to start of the course since you immediately get an idea of what is involved with EA. Also, what I think is kind of funny, this study is done in 2019. So, knowing that EA started in the late 1980s (1987) I think it was about time someone investigated this. Yeah, I know this probably is not the first paper that dives into this, but still I think it is kind of funny.

Still I think this is a nice paper to start the course off with since it gives me some context about EA and how organizations see EA. This research involves an analysis of EA artifacts in 27 different organizations. An artifact is defined in this study as a “descriptive representation of an enterprise”. So they are most often documents or models (UML for example).

This study identified a number of interesting artifacts that where used in most of the organizations like; Solution designs which are architectural models of the IT infrastructure. I think, we as developers, know all about these diagrams. These designs were found in 96.3% of the analyzed organizations. I’m not really surprised by this fact since I think (as a techie) that architectural designs are crucial for proper software development. Without these diagrams you will probably not be able to communicate very will among stakeholders in and outside the company.

Another interesting finding was the use of roadmaps (92.6%) which seems very logical to me as well. I think setting up some form of future or planned features and business developments is a very smart thing to do. If you don’t you are just a rudderless ship on the ocean, just not going anywhere. You need to set goals in order to end up where-ever you want to go (some decent life-advise here haha). But let’s be real, I can’t remember working anywhere without some form of a roadmap. Yet, they might often not be feasible but still offer some overall guidance and direction.

The last interesting artifact I want to talk about that was found in most organizations (88.9%) are technology reference models, aka technology standards. These are graphical representations of all technology used in an organization. These models can be used and selected when new IT initiatives are kicked off. To be honest, I don’t think I have ever seen any model of this kind, yet I know for a fact that we used them informally. When we are starting some new IT initiative you will try to reuse what you already have and maybe try to innovate with some brand new technology.

Another thing I found interesting to see is that “Direction statements” where only found in 14.8% of the organizations. These statements are conceptual messages commuting major organization-wide decisions. It is surprising to me that large companies, who have embraced EA, have not defined such statements.

 

Observations regarding EA artifacts

Some observations about EA artifacts that resulted from this study were the following; Different sets of EA artifacts are used in different organizations. Different organizations have similar artifacts with different titles, while EA artifacts with similar titles can have different meanings. This means that depending on the organization and/or industry the titles of documents can means entirely different things. I think this is fascinating and very confusing at the same time and really underlines the fact that the definition of EA is still considered fuzzy.

Another observation is that many of these artifacts are created for a specific purpose rather than describing certain aspects of an organization. In none of the analyzed companies, EA artifacts were created merely for the sake of have descriptions.

EA artifacts are industry-independent. This is rather expected I guess. Although industries define EA differently, the documents they require is consistent. So this observation suggests that at least the fundamental aspects of EA are independent of industry.

Company size determines the quantity, yet not the types of artifacts. This is a nice observation as well since it really shows what artifacts are considered important for EA.

EA artifacts do not depend on the declared use of EA frameworks. This is something I found rather interesting since, when you decide to follow some specific framework it makes sense you create the artifacts described by the framework. Yet, this research suggests it does not. So which ever framework you choose, you will most likely create the same types of artifacts.

 

Conclusions

This particular study invalidates conceptualization of EA as a set of business, information, applications and technology architectures as well as the conceptualization of EA as a set of the current state, future state and transition roadmap since these conceptualizations contradict empirical evidence from numerous established EA practices. This research suggests that currently EA lacks theoretical models that are able to describe the concept of EA in a consistent way.

 

The value of and myths about enterprise architecture

This paper is all about the value and myths of EA. They conclude, from empirical research and review of literature that only half of the papers provide evidence that support the EA value claims. They define myths as:

“Practices and procedures defined by prevailing rationalized concepts to legitimate their actions are resources, but which are not supported by evidence.”

The reason to do this research and dive into the value of EA are the following; 1) to access the ROI of EA initiatives and understand their risks and 2) alight various stakeholders with different value expectations; clear understanding is needed to find out if EA will result in its intended value. Interestingly, they found that about half of the organizations they analyzed find it difficult to justify investments in EA. I can understand this since this is in line with my experience people have with software architecture as well. These subjects can be very abstract and thus (upper) management might not see the point in doing any of it. The conclusion of this finding is that many organizations do not or poorly understand the value of EA.

 

The myths

The first myth the researchers debunked is one that states that “EA creates value”. EA is seen a one way of creating value but the practice itself only supports finding opportunities for value creating or the ability to realize them. Meaning that only by creating, and using the artifacts can value be created. While EA is necessary, just having EA is not sufficient to create value. EA requires planning and action. EA is aimed at delivering transformational projects that will create value for the organization.

The second myth states that “EA reduces complexity”. This study finds that EA is just a means to manage complexity but does not directly reduce it. As a matter of fact, in some cases it even increased complexity since new organizational complexities are introduced. This is a paradox in EA. They also refer to the TOGAF and Zachman frameworks. TOGAF is version 9.1 is 629 pages long, yet Zachman’s framework is described in one page. The researchers make the case that complex approaches wont find a foothold in the current market. ( Not that TOGAF is not used, it is just rather complex)

Myth three debunks that statement of “EA evaluates all aspects of an enterprise”. There are articles in the analyzed set that suggest that EA can be used to evaluate the entire enterprise but this does not mean that all elements that are taken into account are analyzed in detail. Some parts may contain more detail, while other are shallow. Sometimes it is needed to have very detailed information to create value, yet in other cases an abstract description may suffice. The ambiguous claim of this is that practitioners of EA must always collect as much information as they can. They even quote Zachman himself with his statement: “One day you, or your enterprise, will regret not having completed the schema”. By completed he refers to his framework where you need to fill every cell for a complete EA practice.

The fourth myth is about a claim that “EA should only capture the situation envisioned”. EA has been described to have two major functions, 1) to provide decision makers with a clear and comprehensive descriptive overview of the IT landscape and 2) to provide a prescriptive framework to guide and constrain the subsequent development of business and IT solutions. From the analysis of the researchers it appears that 78% of the articles presenter prescriptive models. Some of which even states that it should only be prescriptive and you should not have to include the current situation. However, from the research they conclude that in order to reach a destination you need to have a good overview of your position and thus you need to document the current situation as well. If you don’t know where you stand, you don’t know where to go. The foundation of any EA initiative must be an adequate documentation of the as-is EA.

The fifth myth debunks the statement that says the following: “EA is a one-time effort”. When I first read this I thought it was ridiculous. I can’t think of a single practice in software development or managing a company that involves  many IT that is a one-time thing. Just because software, and a company, is ever changing. It’s like a living organism which is not simply a “complicated system” but a “complex system”. You cannot expect inputs to result in the same outputs every time. EA requires a continuous effort to reap the value and should incrementally be extended to add even more. EA evolves over time and this complicates the identification of value by EA, as the type of value changes over time as well. Also, some practices may not seem valuable at the moment, but will result in value later in time.

 

The Benefits of Enterprise Architecture in Organizational Transformation

This next paper is about how Enterprise Architecture can benefit organizational transformation. It starts of with a very nice description of EA: “EA has been widely adopted as a planning and governance approach to manage the complexity and constant change, and to align the organization towards a common goal.” The findings of this particular research is that EA is a long-term and intertwined chain of activities. The researchers make the case that some EA benefits may only surface years later from their initiation. This is why EA implementation is often difficult to explain and questioned as the benefits might show up later.

Some other interesting things I found in this research is that they define EA in terms of processes and products since EA is both a process and a product. “EA management operations, i.e. processes provide direction and support in the design and management of the EA to support organization transformation”. EA products are output that come from the processes such as documentation, models, standards and other knowledge items describing the organization. The products are primarily used for guiding the EA’s realization in individual development initiatives.

EA plans are realized when systems and processes are implemented. The EA products can be used in decision-making and communication, strategic management, governance and IT and business planning activities.

The study then presents a very nice table of all the found benefits that have been described in the literature they analyzed. I encourage you to check these out yourself since there is no point in repeating them all :).

They also found that many studies focus on hypothetical or potential benefits but not on concertized benefits. There are some studies that look at concrete benefits but they do not always clarify the realization mechanisms. Yet, the papers show that EA benefit realization resembles a process, i.e. a series of actions or steps that have to be carried out to realize the benefits of EA.

Another interesting bit I read in this study is that the researchers found that social, cultural and organizational issues also have an impact on EA and the process. For example; Top-management commitment to EA and stakeholder awareness and understanding of EA are crucial for bridging EA and quality of EA processes and products.

 

EA Constructs and their attributes in the enterprise architecture benefit-realization process

Now to get to the really interesting part of this study are the actual things they found really contributed to benefit realization.

1. EA Process Quality: which is defined as “Measures of EA processes, methodologies, tools, and organization”. These all contribute to a clear EA scope and purpose, cohesion with other governance and framework for quality and conventions.
2. EA Product Quality: which is defined as “Measures of EA products”. This contributes to availability, clarity, cohesion and uniformity.
3. EA Service Quality: which is defined as “Measures of EA Services”. This contributes to Activeness, availability, competence and usefulness.
4. EA Results Use: which is defined as “Consumption of output of EA processes i.e. EA results by stakeholders”. This contributes to amount of use, EA results used stakeholders and user satisfaction.
5. First-level benefits: which is defined as “Effects of EA that arise directly from the EA processes”.
6. Second-level benefits: which is defined as “Effects of EA that arise (depending on the situation) either directly from the EA processes or as a result of the first-level benefits”.
7. Third-level benefits: which is defined as “Effects of EA that arise as a result of the second-level benefits”.
8. EA social Environment: which is defined as “Organizational factors external to the EA undertaking that have an effect on the  EA benefit-realization process”. Like common approval and understanding of EA, top management commitment and understanding of EA work in other organizations.

In the paper the researchers lay out these eight constructs in a neat little diagram. This diagram models the relationships between them. So most of these benefits are on an individual or project level while others are organizational in nature, also, some are concrete benefits while others are abstract and not easily measurable.

From their analysis, the researchers concluded that EA benefits can arise directly from EA processes, plus the observation that some might arise more indirectly, which is also shared by several other researchers. EA can immediately result in improved understanding because the gathered information can be used directly. For example, architectural models can be shared right away and thus other architects can benefit from them. This leads to better processes and business IT-alignment which lead to measurable cost savings.

Implications

The last thing I want to discuss about this study is the implications the results of the study make. The researchers point out two categories specifically: implications for EA management (EAM) and implications for measuring EA.

As a matter of the first they state that benefits can be directly realized from EA operations. Therefore should be a solid basis for EA work with appropriate resources, organization, tools methods and frameworks. Top management involvement is also to be found crucial to the success of EA. They also point out that nobody likes the “ivory tower syndrome”. EA should be integrated with strategic, business and IT planning processes of an organization. They also found that there is no single way of carrying out EA work, yet different approaches might match different companies. So look for the right ones!

The actual use of EA products is also a key activity of EA benefit-realization. The EA products are useless from the benefits point of view if not used properly. Timing of their use proved crucial as well especially in development initiatives.

On the matter of the second, implications for measuring EA they have the following to say: They say that benefits and cost savings can be expected years from the actual initiation of EA. So, it requires faith to invest in EA but results will come over time. Process and product quality can be used to ensure that the EA processes result in high-quality EA products and services. A component to measure here is user satisfaction since they will probably have a good thing or two to say about the company’s services.

 

Enterprise Architecture Management: Toward a Taxonomy of Applications

The fourth and last paper of this learning unit is about Enterprise Architecture Management (EAM). The researchers make the case that practitioners and even (other) researchers lack a shared understanding of the application of EAM in organizations. Their finding suggest that EA is not only as an IT-centric practice, but also is an approach to support consistent design and evolution of an organization as a whole.

The start of the introduction by saying that among practitioners of EA there is a lack of understanding EA, it’s scope and applications. EA is traditionally seen as an IT-centric practice, but EA spans both the business and IT realms. Some studies indicate that the role of the IT architect is not just supporting the architecture evolution but also towards facilitating transformations in a company. This turns EAM in an approach for developing an organization as a whole.

With this study the researchers try to answer two questions: 1) what does EA mean? and 2) How do organizations use EAM (i.e. for what objectives)? They try to find answers to these questions through literature review. First the definition of EA is documented, next they describe three archetypes of EA they found in the literature.

Interestingly they present the definition in a nice big table (there are so many definitions that they made a table for it). This again shows the fuzzyness of the meaning of EA. They found three different scopes of EA; scoped to EA elements, business capability and EA elements, or business strategy, business capability, and IT elements. Let’s take a look at what they mean.

So, first there are many definitions for EA. Based in their research, the researchers suggest that EA is defined as follows: “EA is the fundamental conception of an enterprise in its environment embodied in its elements, these elements’ relationships to each other and to the enterprise’s environment, and the principles guiding the enterprise’s relationships to evolution”. EA is not merely a description or management methodology, it’s an enterprise’s inherent structure.

They also describe that EA is scoped differently in different organizations. Therefore they found three archetypes.

The first one is only focused on the IT Elements meaning the goal of EA is to ensure coherent and consistent design of IT systems. They describe this scope as EA facilitating “IT asset portfolio management, consolidation of the IT landscape and controlling the growth of technical diversity”.

The second scope considers EA as “business processes becoming a typical component of the enterprise” which also include business functions and organizational structure. So it covers help in realization of business capabilities in addition to just IT elements.

The third and most comprehensive scope also includes “an organization’s strategic business elements such as business motivation and business goal”.  In this case EAM supports “strategic development of an organization and ensures that an organization designs a coherent and consistent business model in terms of products and services, delivery channels, customers, economic model and relationship with the environment”.

Taxonomy of EAM applications

As a result of their study they created a nice taxonomy to classify EAM goals to their scope. Since this table is rather important I will copy it to the blog, yet for detailed information you should read the paper.

	IT Management	Business capability management	Business strategy management
EA’s scope	IT elements	business capability elements	business strategy elements
EAM’s goal	Coherent and consistent design and evolution of IT elements in mutual alignment with business strategy and capabilities	Coherent and consistent design and evolution of business capabilities’ realization elements in mutual alignment with business strategy	Coherent and consistent design and evolution of business model in mutual alignment with the market environment
EAM’s applications	Complements IT strategy formation, planning, and implementation Influences business strategy formation and planning	Complements business strategy, planning and implementation Influences business strategy formation	Complements business strategy formation

I’m not planning on describing all these concepts since it is really nicely explained in section “5: Taxonomy” of the paper.

Conclusion

Haha, again, I fell into this trap thinking that I was just going to write a short blog, yet here is another long blog. It’s just that, in order to describe these EA concepts a bit you need some context about it.

I think these papers were interesting to read and a good start of the course. I guess that’s why the professors chose them. I have to admit that it took me quite a while to chew through them but in the end I gained a better understanding of the concept that is EA. I think it is rather funny that event the definition of EA is highly debated. But, by reading these papers I get why it is that hard.

Future blogs about my EA course will probably, and hopefully be shorter. I’ll try to refer more to the source material in my next blogs instead of trying to “translate” it into my blog.

Also I want to point out that I can in no way keep up with my blogs since I need to read many papers, do the group assignment and some individual assignment. For example; this blog is about he literature of learning unit 1, but we are in learning unit 3 now according to schedule. I’m up to speed when it comes to reading, but I’m a bit behind when it comes to blogging, but I don’t really care. So, If you are reading this and also started September 2021, I must disappoint you that these blogs will not be in real-time. Haha, sorry!

Nonetheless, I’m planning of doing a full blog about this course, but some are just delayed.

#end

01010010 01110101 01100010 01100101 01101110.

References:

Article 1: https://journals.sagepub.com/doi/abs/10.1177/0268396218816273

Article 2: https://www.sciencedirect.com/science/article/pii/S0268401217305492

Article 3: https://link.springer.com/content/pdf/10.1007%2Fs12599-019-00605-3.pdf

Article 4: https://aisel.aisnet.org/cais/vol40/iss1/7/