3 Schools of Thought on Enterprise Architecture

Here is an article that I wrote about various perspectives on Enterprise Architecture. The objective of the article is to surface key systems of beliefs that are presented in the enterprise architecture community. These systems of beliefs are represented by the Enterprise IT Architecture School, the Enterprise Integration School and the Enterprise Ecological Adaptation School.

The softer side of EA

Here are some reflections on the inclusion of soft elements in the pactice of EA. My reflections are constructured around a 3 level model : Self, Others and System. These levels help to guide my reflection about the implications of the human dimension of EA at various conceptual levels.

Self. Embracing human-centric elements in Self is about understanding how our way of seeing is also our way of not seeing. It's about understanding how our view of the world, our values and beliefs affect our perceptions and decisions. Hence, it’s about walking away from the belief that perceptions and decision may be disconnected from emotions. There is not "rational" way "a la Descarte". As a side note, the work of Damasio (a neurologist) supports this view.

Others. Embracing human-centric elements in Others is about understanding how to take into consideration the needs of others, especially with regards to motivation, self-fulfilment, learning and engagement. Consequently, this is about understanding how our way of working with others impacts directly the outcome of the work... there are no multiple ways to get to the same end, each way will impact the outcome especially from a human perspective. Other is about change management and transformation.

System. Embracing human-centric elements in System is similar to Others but it is not about the interpersonal dynamics, it's about how the global human dynamics of a organisation impact the other systems of the organisation (and vice versa) such as the political system, the technological system and the socio-economical system. System is about having a "systems thinking" approach to the organization and understanding global optimization with regards to multiple dimensions (technology, human, financial, etc.).

Self is about rethinking how our views of the world impact the way we do and thinking about EA. My topic on Post-Modernist is an example of this. Through self, the process of achieving EA and the expectations on the outcome of EA will change.

Others is about viewing EA through a social psychological lens. It’s about viewing EA as a sense-making process. Consequently it’s about rethinking how we engage people is EA work and how EA work will change the way people work and think. Through Others, the process of achieving EA will change in order to achieve differences in the way people will relate to the outcome.

System is about view EA through different systems theories. It’s about using a holistic (Gestalt) approach in helping organisations. Through System, the dimensions (systems) considered when doing EA as well as the interactions between these dimensions are considered (the whole is greater than the pieces) will change.

As can we seen in my model, considering the human dimension will always change how EA is achieved as well as the outcomes.

Is EA a solution or a cover-up ?

Recently, I have come to believe that EA doesn’t introduce anything new to “modern business management”. However, such an approach to management seems to be rare compared to "classic business management". Consequenetly, I feel that EA is a bad solution to a deeper problem : "classic business management". Classic management is based on a tacit assumption that organizations can be compared to machines. Consequently, divide-and-conquer strategies are promoted both in organizational design as well as task responsibility/accountability distribution. This is to be expected because most “classic” management principles date from the industrial revolution. The consequence of all of this is that “classic” management doesn’t take a systemic approach to management (I’m using the term systemic from the perspective of Senge, Demings, etc.). In addition, as stated by Peter Drucker, classic management is about doing things right, it isn’t about doing the right things… that’s leadership.

If I go off into fantasy land for a moment :o) If organizations were managed using a systemic approach, there probably won’t be a need for an EA team. The EA team would be replaced by a strategic leadership/management committee with representatives from across all units (IT would be one). These representatives would work in collaboration in order to insure systemic optimisation and organizational learning.

Now back to reality… because of classic management, these units often do not work in collaboration because, driven by a culture of silos, they fight for limited resource in order to do what they believe is “locally” right instead of working together in order to do what is “globally right”. This is also sustained by a tacit assumption that accountability cannot be giving to a group but only to a single person.

Now if a talk about IT and EA. EA is probably often in IT because IT is always “stuck” in the middle of all the other units fighting for limited resources. Consequently, for IT to function efficiently, it has to compensate for the silo culture… hence the need for an EA team. Often, business management doesn’t understand EA because understanding it would put into question there ways on managing/thinking.

Software - A social construct or a technological one ?

Over the last 60 years, we have tried to push the development of software from being a craft to an engineering discipline. Today, the expression “software engineering” is use commonly to describe the activities surrounding creating a dependable, functional piece of software. Despite the great advances which the software community has provided with regards to defining better controlled processes and methodologies for developing software, we often here people say that software creation is part art part science.

So… is it that we have not currently reached the holy grail of software development methodologies which will liberate us from the chains of the arts and crafts aspect of developing software, hence propelling us into a new age of software engineering nirvana….. or are we searching for a mythical dragon that doesn't exist ?

When we associate terms such as engineering, process, and methodology to the activity of creating software, we are implicitly casting software as a technological construct. A technological construct is an object which has meaning and existence outside the influence of people. At the opposite, a social construct only has meaning in the context of a society. For example, a bridge is a bridge. One can talk about a bridge without making reference to a given social context. In contrast, one cannot talk about concepts such as “respect”, goodness without making reference to a given societal context. Each social group will define what it means to “respect others” differently. Technological constructs can be define rigorously using symbols such as mathematics and blueprints to define what they are... they can be engineered.

I have been recently pondering the idea that software is mostly a social construct; especially software developed in the context of organizations. In these contexts, software often plays the role of a human being (albeit an automate one) participating in business processes characterised by complex webs of interacting individuals. Moreover, these processes are most often executed in similar ways but never exactly the same because contexts are never the perfectly the same and people never behave the same. In order for complex tasks such those found in organizations to be accomplish by teams of people, it is necessary for the team to develop “shared meaning” about what most be done and how they should work together. This “shared meaning” about the “what” and the “how” is a social construct… it is establish through dialogue and shared experiences amongst the team members. If software must take part in one of these webs of human interactions because it replaces one of the team members, one could probably argue that “what” the software should accomplish and “how” it should to it is also a social construct because different social contexts (organizations) will probably have different “shared meaning” on the matter.

If this is such, software is a social contract. Consequently, one can only define software through a continuous dialogue of “shared meaning” creation. The process of using upfront specification which are than used to “engineer” the final product cannot work… only iterative process which verify often the congruence of the software with the “shared meaning” of role it should play can work…..

Enterprise architecture - A dialogical approach to fostering collaboration

In essence, enterprise architecture is about creating targets for the future state of an enterprise. In other words, enterprise architecture is about creating a vison for an enterprise. Consequently, the process of creating an enterprise vision, doing enterprise architecture, can be viewed as a vision process.

Many authors such as Senge, Emery, Meadows and O'Brian have stressed the importance of shared visions - visions created my many - in order to create shared meaning and foster engagement.

Typically, enterprise architecture targets are created in a top-down manner by a small group of specialists which are often IT people... hence these targets (visions) are not shared. Once these targets are finished, these specialists go out an "sell" the vision to others in order to get buy-in. Because these visions are not shared, this additional "selling" step is required; a step which often fails because engagement in an idea cannot be "bought"... only compliance! Hence all the "policing" done by enterprise architects.

Approaching the process of creating enterprise architectures with the objectif of creating a shared vision has multiple advantages : the fostering of shared meaning and collaboration through dialogue. In order to create a vision which is "truly" shared, it is necessary to use a participative-democratic approach in which the collective participates in the creative process of defining the vision. At multiple levels, this creative process is fostering important exchanges between people througth the means of dialogue. At one level, the process allows particiants at to engage in creating shared understanding and meaning of the past, present and future or the organization. At deeper more personal level, the process fosters the creation pf shared understanding and meaning about the various perspectives and concerns of people across the organization. I believe that it is at this level that organization silos are truly crossed.

In summary, enterprise archecture, viewed as a vision process, is an opportunity to engage in a collective vision process which through dialogue can foster shared meaning and understanding across the organization, hence breaking-down silos.

What Enterprise Architecture is for me (in a nutshell)

Enterprise architecture (EA) is basically what it sounds like. It’s about resting organizations on a solid foundation with the aid of high-level blueprints that depict how the organization should be in order to function at its best. Many make the parallel between enterprise architecture and urban planning; like the latter, enterprise architecture is not about deciding how many nails to use when building a house but rather about organizing land zoning and designing infrastructures in such a way that will help promote city growth and good overall functioning.

Most approaches to enterprise architecture use the following process:

1. A target blueprint is created
2. A gap analysis is done between the current state of the enterprise and the blueprint
3. A transition plan (roadmap) is developed to move the organization from its current state to the target state
4. A set of potential projects are designed in order to deliver the transition plan; from this set of projects, those that have a good return on investment are selected to be delivered.
5. Once a project is delivered, the current state blueprint is updated.

Program/project management can be seen has an organized way of governing and achieving point 4.

The above process loops; hence the target blueprint changes at a rate which is directly related to the speed of external and internal changes.

Roughly, enterprise architecture can be broken-up into to sub-domains: business architecture and technology architecture (information, application and infrastructure). Business architecture is about organizing and designing strategies, processes, capabilities, roles/responsibilities, etc. Technology architecture is about choosing, organizing and designing technological solutions which help support business processes and functions as well as supports strategic objectives.

As you can see, there is a lot of resemblance between EA and sociotechnical systems (STS) design. The problem is that most organizations reduce business architecture to business process design which is often done and only understood by IT. Moreover, often, the technological architecture is done in a vacuum without the human dimension. Design choices are made with little regards to culture compatibility; these choices are often made according to industry best practices and are based on the only concern to support effectively the business processes which were designed in the business architecture. When EA is reduced to the latter description, it is clear that the underlying mental model of the organization is one of a “machine”.

So all in all… there is not much to EA that is really different then STS from my undertanding. I guess the truth complexity of EA which does not come through my text is that: in the same way that the business architecture (human dimension or socio aspect) must be designed in a holistic fashion in order for people to work effectively together and feel good about it, the technological architecture must be done in a manner which is reasonable for both the people delivering the technology as well as those supporting it once it is in place. For example, it makes no sense to choose the best and the greatest tool in the world if there are very few resources on the market to implement it and support it.

Enterprise Architecture is failing. Is it because there are too many consultants?

An interesting discussion on Linkedin entitled Enterprise Architecture is failing. Is it because there are too many consultants? was posted. What follows is my take on the subject. One of the interesting posted comments was:

"Successful EA requires a disciplined commitment at all levels of organization. While that is moderately challenging to attain at the upper levels, propagating that discipline through the management ranks, both business and technology, is THE familiar change management challenge. That is trouble for any organization that attempts the "give me a little EA first" approach - and doesn't apply it to a complete division or subsidiary. And since we're so good at financialdiscipline, that is usually the approach that executives gravitate toward." - Aleks Buterman

I would like to add to Alesks’ first. I find that many enterprise architecture groups base their visions and roadmaps on best practices without taking into account the human dimension impact of their choices… without taking in consideration the culture of the organization. For example, if a company has a culture based on competition and silos it will be extremely hard (not to say impossible) to implement an enterprise data quality management vision.

With regards to consultants, it is very difficult for “outsiders” to truly understand the culture of an organization from being immersed in it during a short period. Hence, going back to my first comments, an “outsider” enterprise architect will NOT be able to truly understand the human impact of his recommendations. What follows is that his recommendations are either not followed, not implemented correctly or their implementation is not sustained in the long run because people do not feel it is “their” solution… this is typical resistance to change. A good way to avoid this is for consultants to act as a process consultant instead of a content expect, hence the consultant HELPS/FACILITATES the hiring company to define an enterprise architecture which aligns with it culture or helps the company to discover the discrepancies between what the company wants and what its culture can sustain. For more info on this see Peter Block. Another interesting post was :

"It is a cycle, while I think there are a lot of EA consultants our there that are a problem in their own right I think from the bigger picture point of view they are a symptom. A lot enterprises think that they can buy EA like fruit at the market a good EA program is more about growing the fruit. EA is something that a successful organization struggles over, strives towards, and is commited to. Bringing in a prepackaged EA is like renting a wife and expecting a marrige. It has to be your EA, not 's EA" - Art Freas

So in resume, I don’t think that the number of EA consultants is the true problem. As Art said, I believe that organizations believe that “off-the-shelf” solutions exist for EA hence they believe that a consultant can help them. I believe that this problem is itself a symptom of organizations which do not take into account the human dimension of EA. I personally believe that Organizational Development should be incorporate into the EA function, this would help greatly with this disconnect.