Blog Posts Enterprise Architecture (EA) Process Analysis Process Modeling

EA and Business Transformation

Blog: Brian's Blog - Enterprise Strategy, Architecture and Management

A respected colleague of mine posted today a small opinion piece on LinkedIn “Enterprise Architecture (EA) Is Not Business Transformation” His post positions is that Enterprise Architecture is not about Business Transformation. While I respect his opinion, this highlights the division that has yet to be resolved within the community I’ll state as best I can here. There are two schools –well likely a few more– of thought as to what Enterprise Architecture is. This may be because of its origin, coming from the information technology arena.

First opinion: EA is about design of information infrastructure of an Enterprise. This sets the boundaries clearly at only those elements that are directly connected to or implemented in computer technology. As such activities are then focused around selecting, designing technology implementations. While this is the common activity and focus of many EA and EA associations, I would put forward that to call that “Architecting the Enterprise” is a bit of an overstatement. In this role to add another metaphor one is acting more as an Information Systems Design & Manufacturing Engineer or Electrician. The enterprise is already been architected one is just wiring the framed out house (Enterprise). In such case, an EA’s role in transformation is just planning for swapping out of one technology for another: on Mainframe to Client -Server, Premise to Cloud, etc.

Second opinion: EA spans the entire scope of the design and/or remodeling (aka Transformation) of an enterprise. Here several issues rise.

Has an EA been trained on Finance, Organizational Design, Business Models, etc.
Does an EA have the charter in their specific organization to work on such domains
Is the EA reporting to the right governance body to work effectively on designing the enterprise — if you’re an architect who is your client and what is their design brief

Here is where I see many EAs:

Shout they’re not reporting to the right level within the organization
Restate their belief in the first opinion of EA’s design boundaries
Profess that Business Models, Organization Structure, Financial Structure and the like are not part of EA

To the last point I’ll respond continuing Architecture the metaphor. If one is to design a house, you don’t put out a floor plan or electrical plan by itself and call it job done. There are a whole host of other areas to design; Plumbing, Roof , Foundation, etc. In the design of an enterprise these would include Business Models, Organization Structure, Financial Structure, and other domains. Does not mean that EA is domed to failure. Not at all.

Let’s consider the case not of designing a house, but of designing a skyscraper or a city. One architect is not likely to be designing the entire complex. There are other “architects” working on specific domains and at specific levels of granularity. So too is it in Enterprise Architecture.

What this means is acknowledging that other expertise is required to design the enterprise and forming a design team to include these. The implication of such is establishing partnerships within the functional organizations such that the business and operating models created within the executive suite are accessible to you and informed to them, same as organizational models & competency inventories, financial models, etc. When such occurs whether formally or informally EA functions at an Enterprise Design level rather than a subcomponent design level.

Filed under: Enterprise Architecture, General Systems Thinking, Governance