Fine-Tuning the view of the Technology Architecture Stack against Business Architecture

Discussion for EA874 Topic 1 > Stack Overview
Post # 1

While we understand that this course will focus on the Technology stack, Lesson 1's set of overview notes was good to point out the caveat on quickly dismissing Business Architecture as just one quarter of the significance in the context of Enterprise Architecture - i.e. based on the 4 or 5 layers depicted in the diagram for EA elements.  As was noted,  this delineation for practice areas are useful for conducting enterprise analysis,  but reminds us that EA needs to be treated as a business issue, and not a technology issue -- as clarified by Gartner: “the primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself. This includes innovations in the structure of an organization; the centralization or federation of business processes, the quality and timeliness of business information, or ensuring that money spent on information technology (IT) can be justified.”

Clearly, the practice area for Business Architecture is not that simple to begin with, and perhaps should be visualized as the "other half" of the EA equation, with the other half taken up by all other EA practice areas constituting the technology stack.  The diagram below reminds us that the concerns of Business Architecture is equally multi-dimensional and complex.

Image source: https://en.wikipedia.org/wiki/Business_architecture

The article from the BA Institute provides an interesting discussion on the evolution of the BA practice and what it identifies as four dimensions of concerns: 1.) The functional groups and each groups unique processes, 2.) The cross-functional processes which cut across functional lines, 3.) The processes which interact with Customers and Suppliers, and 4.) The dimension of time to market which creates the competitive drive.

Clearly from that discussion, building an architecture of the business is a significant endeavor.  Moreover, it argues in support of understanding business architecture not only using business function process analysis, but also those cross-functional processes with the dimensions of customers, suppliers, and time to market. This is essentially consistent with James Martin's notion of value streams.  It does make sense that the added dimensions of customer and time will provide more insightful analysis of the enterprise blueprint, and identify opportunities for enterprise wide performance improvement towards promoting competitive advantage.

I think if we, as EA practitioners, adopt this extended view of how the business architecture layer is juxtaposed with the other technology layers for EA, the better we can position EA value within the business organization. Enterprise Architects should master how the appropriate application of the technology stack can best serve the business needs and mission of the enterprise.

References:

BA Institute. (n.d.) The Four Dimensions of the Business Architecture. Retrieved from http://www.bainstitute.org/resources/articles/four-dimensions-business-architecture

Wikipedia. (n.d.) Business architecture. Retrieved from https://en.wikipedia.org/wiki/Business_architecture