Reflection 1: On layers in enterprise-architecture
Since the first lesson for EA-874 is an introduction to the enterprise architecture stack, I thought it would be worth taking a closer look at the different stack depictions among EA frameworks. The above article highlights a few of the differences:
- Archimate’s three layers: Business, Application, and Technology
- TOGAF’s four layers: Business, Data, Application, Technology
- Zachman’s five or more layers (depending on interpretation)
In addition to the article, our Lesson 1 reading material falls in line with TOGAF, while the Gartner EA framework (not examined in the article) puts a twist on the stacked layer paradigm, emphasizing the business, data/information, and technology layers. Instead of stacking them, Gartner shows the layers intersecting, and it’s at the intersection of the three layers where solutions (applications) are defined and created.
The article rightly points out that while there are many depictions of the EA stack, two layers are consistent: business and technology. It’s the data/information and application layers that provide the variability.
While the article fairly contends that there is no right or wrong depiction, I will express a bias for having a data/information layer that is separate from the application layer. Information should be treated as something that exists in an enterprise regardless of the existence of applications. It’s for this reason that an information layer is essential to defining an enterprise.
I will further express a bias for the Gartner approach, which shows applications (solutions) not as an EA layer, but rather, as an outcome of the three core layers of business, information, and technology. The business and information layers should define the enterprise without regard for technology. When we add in the technology layer, we now have the ability to create solutions and/or applications. It is the three layers of business, information, and technology that actually define the enterprise. Once they are established the enterprise can go about creating solutions/applications.
That’s just my point of view. Once again, there can be no right or wrong, just varying degrees of acceptance or popularity.
Reflection 2: Introduction to Enterprise Architecture
The previous article explored the long-standing differences in EA stacks and their respective layers. This article goes a bit further and reveals a recent trend for depicting separate security and integration layers, not as part of the stack, but as vertical layers that touch all the horizontal layers of the EA stack.
I have an easy time seeing why security is being treated as an EA layer, albeit vertical, as all EA layers have unique security requirements which are not all technology-driven, and thus, not addressed in the stack’s technology layer. Security strategy should be expressed and executed at an enterprise level to ensure that all layers of the enterprise are addressed in a coherent manner.
The integration layer, however, is something I’m still struggling with. I see integration as part of the technology layer, used to build solutions and enable communication between intra- and inter-enterprise applications. I’m not sure what the purpose is at the business and information levels. Keep in mind, my interpretation of the information layer is as a logical depiction of the enterprise’s information without regard for applications, which is why I struggle with the integration layer having pertinence here.
It will be interesting to further explore vertical EA layers throughout the semester as well as in the following article and reflection, where yet another example of a vertical EA stack layer is presented.
In this last article, the author took four real-world businesses and mapped their actual EA layers to the author’s proposed, or ideal set of EA layers. The four businesses were intentionally selected from different business domains and different countries to ensure diversity.
One discovery, maybe not that surprising, is that each business had implemented their own unique layering, definitions, and core artifacts, which can be seen in the respective diagrams depicting the mapping between the subject’s layers to the author’s proposed layers. The paper is only two and one-half years old (published in February 2014), so it’s interesting to see the custom EA programs at these businesses given the amount of time the more popular EA frameworks have had to take root.
On the surface, these differences don’t seem to mean much as they appear to be mostly superficial preferences in naming and in the grouping artifacts and responsibilities. It is interesting to read the motivating factors each business had for starting their EA program and to contemplate the impact those motivators had on the resulting custom EA layers and programs even though the article avoids direct cause and effect conclusions.
Let’s take a quick look at how these four real-world EA stacks compared to our Lesson 1 reading and the first two articles from above.
- Company A comes close to the common three layer stack, forsaking the data/information layer but adding the strategy layer, which I think most EA programs would lump into the business layer.
- Company B comes very close to the traditional (and Lesson 1 recommended) four layer stack, but surprisingly, separated out the data/information layer into two separate layers, treating the data layer in the traditional sense of logical and physical data models, while defining the information layer in a unique fashion with a focus on metrics.
- Company C really went custom with six layers. What I found interesting here is the integration layer, which is depicted in the stack as a horizontal layer underneath the application layer. Recalling the second article from above, where I was having a hard time with the notion of a vertical integration layer spanning the entire EA stack, this approach by Company C made more sense to me and felt much more intuitive.
- Finally, Company D went with the traditional three layer stack, but also added in two vertical layers, similar to what was depicted in the second article. One of these two vertical layers represents security, matching the reference from the second article and further reinforcing the concept of a vertical security layer as a trend with EA stacks.
My take-away from all this is that businesses will commonly tailor their EA stack, just as the article’s four companies did, even as certain EA frameworks gain wider adoption. This tweaking will sometimes be done in obvious ways, by adding or subtracting layers, and also by more subtle ways, by slightly altering the definition of certain layers and what artifacts and responsibilities get grouped into those layers.
Ultimately, the differences come down to each enterprise simply wanting to emphasize unique EA elements while deemphasizing others based on their unique histories and future strategies.
