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.

Is Enterprise Architecture sociotechnical systems (STS) design ?

Sociotechnical systems (STS) theory warns about optimizing the technical dimension of systems without considering the social dimension. Moreover, optimizing both dimensions of a system independently of each other often causes the system to be sub-optimal as a whole. Personally, I see the traditional approach to enterprise architecture as only addressing the technical (technical in this context must be understood from the perspective of STS and not IT) dimension of systems (organizations). I believe that enterprise architecture should be considered equivalent to STS design, hence we must incorporate the human dimension if we want enterprise architecture to be effective.

If my reasoning is correct, the next questions I would ask are :

• Could STS theory be a good framework for evaluating the potential effectiveness of EA frameworks/methodologies?
• How effective would current EA frameworks/methodologies be with regards to an STS perspective?

I find that many enterprise architecture groups base their visions and roadmaps on “technical” best practices without taking into account the human dimension impact of their choices. For me, this is an example of "optimizing the technical dimension of systems without considering the social dimension".

I think that many people underestimate the impact that an organization’s culture will have on the implementation of “technical” best practices. I believe that this is symptomatic of that fact that many IT people use an empirical-rational strategy when managing the impact that enterprise architecture has on organizations. This strategy is based on the assumptions that : people are rational beings and will follow their self-interest – once it is revealed to them – and that successful change is based on the communication of information and the proffering of incentives. Often, these assumptions are not totally accurate; hence compromising the “technical” dimension of a vision (not using best practices) in favor of the “social” dimension could lead to a better overall solution.

My feelings on Business Enterprise Architecture Modeling (BEAM)

As I have mentioned in earlier posts, I have become increasingly interested in organizational development as a tool for addressing the human dimension of enterprise architecture and its challenges. My readings on OD have brought me to believe that:

• the empirical-rational strategies to change/learning that most EA groups use which are based on the assumptions that “people are rational” and “will follow what is in their self-interest if it is revealed to them” are not necessarily effective strategies.
• an EA group that functions in a elitist and “top-down” manner will create more resistance then is necessary and will also have a lot of difficulty in getting people “engaged” in realizing the proposed visions.
• most IT organizations under-estimate and under-invest in on-going learning and the strategic management of skills.

My mid-term objective is to define an EA framework which incorporates values and techniques from the discipline of organizational development in order to achieve the following:

• an EA approach which truly recognized the human component of an organization as the most important one and fosters the definition of visions and solutions which take into account the organization’s culture as well as the learning needs of people required by these visions and solutions;
• an EA approach which is inclusive (cross-department and cross-level), based on teamwork, fosters double-loop learning and system thinking;
• an EA approach which privileges the definition of visions which are “bottom-up” and based on shared visioning;

I believe that tools such as appreciative inquiry, shared visioning, open system thinking, group process facilitation and culture transformation will be key elements of a “human-oriented" framework for EA.

I have discovered a Enterprise Architecture approach called Business Enterprise Architecture Modeling (BEAM) promoted by Ken Orr. My interest in BEAM is that I feel that the RAD sessions and the alternative scenarios which the approach includes incorporates, at a certain level, elements of the values and techniques I mentioned above. For example, I perceive the RAD sessions as fostering an approach which is inclusive, teamwork-oriented and based on shared-visioning. I perceive the alternative scenarios elements as similar to the scenario planning work done at Dutch/Shell which is base on system thinking and shared visioning.

Challenges when combining SOA and Agile

For me, both SOA and Agile require deep cultural changes in organizations in order to be effectively implemented.

Usually, many assumptions about using Agile rest on having self-organizing, self-managing and cross-functional teams. This is typically a step away from traditional “top-down” monitor and control approaches to management and “over the fence” requirement/delivery management. Organizations are open systems that require a holistic approach when changing; hence trying to implement Agile locally without taking into account the non-local forces that will impact the agile delivery group could result in frustrations and poor performance. To illustrate this, one only has to think about the manager that wishes to foster agile delivery but must supply the “traditional” project management indicators/elements to a VP (long term estimates/planning, weekly progression, change requests, etc.) for a dashboard.

SOA also requires deep culture transformation. For me, SOA is not about technology (Web Services, REST, etc), its about having a clear understanding about operational processes as well as their segmentation, governance and data requirements. In my mind, in order to achieve a truly effective SOA implement most of the values of Quality Management (or Total Quality Management) must be implemented such as “global interests above local interests”. SOA requires a holistic, cross-functional approach to its implementation and management.

An example of a possible challenging situation that an Agile-SOA team could face is one which requires the team to delivery a list of services that surpasses its knowledge base. In this context, chances are that “over the fence” attitudes will show its face; instead of using a self-contained cross-functional delivery team, requirements gathering will probably be thrown over the fence (because it is usually the hardest) and the SOA team will only manage delivery. This situation creates a potential gap between what is required and what is delivered as well as an “us vs them” dynamic which does not follow the values of Agile. Now, we can also imagine that the team must delivery data-oriented services in which the consuming departments and the producing departments of the data are not the same. In this situation, if the organization is not supporting holistically the values of SOA, the team will struggle deeply with the prioritization of the services when “local interests” pressures build around the task without the capability to manage “global interests”. In this context, SOA adds an extra layer of complexity because even if the team manages to holistically prioritize the services to deliver (holistic planning) they must also manage to get people with potentially no interest in certain data to produce it for another group (holistic delivery). The latter combined with the former requirements-delivery gap and an “us vs them” dynamic can make for a very explosive experience and frustrating.

So in a nutshell implementing “SOA-Agile” = implementing “holistic planning and delivery” which requires a deep change in culture in most organizations… its no just about technology.

Are EA Frameworks Dead or Enough ?

An interesting blog entitled “Enterprise architecture frameworks are dead, long live real-life practice !” was posted. The blog discusses how EA frameworks are maybe not all that useful in practice.

I personally find that EA frameworks don't address one key dimension which makes then very hard to use in practice : the human dimension. Yes frameworks such as TOGAF are like recipes which can guide somebody on how to identify EA opportunities and how to manage the overall design. However, they don't speak to what will actually stick in the organization. Moreover, they don't say how to communicate and receive engagement from members of the organization in order for them to endorse EA visions and participate actively in EA initiatives/activities. In short, EA frameworks don't take into account the cultural aspect of organizations when guiding EA.

I think this is the stuff that you learn from experience (or training) which is the missing "magic ingredient" that makes EA frameworks incomplete and useless if used as is...
For me, the following examples illustrate what happens when the human dimension is not taken into account:

• EA visions and orientations are defined but their communication and endorsement are a never ending on-going struggle;
• Technological EA (integration, software, networking) visions/orientations which include technology choices, usage patterns etc. are made but years later people are still questioning them, little money is spent on training and very few have developed the necessary skills to apply them (IT side) or want to pay for them (Business side);
• Quality management is incorporated into the data management vision of the enterprise but again very few people are engage in the on-going process of sustaining quality management and people are sacrificing global operations optimization for local optimization because;
• Agile models are adopted for project delivery but project members don't function as a team (only as a group working of the same task), they only want to execute tasks directly related to their specialty, business users are not part of the team(they are only SMEs and/or supports). etc.

Underlying these examples are human issues such as cultural/vision compatibility, change management and learning management. These key issues are rarely (if not) spoken to in EA frameworks but are so important for the implementation of EA visions and initiatives. In short, EA frameworks don't include the aspect of organizational development which addresses culture management, change management, organizational learning, etc. which makes them mostly useless.

An analogy with cooking would be : you can own the best cooking recipe book, be an amazing cook and be truly creative but if you can't realize that your specialty is vegetarian cooking and that your cooking for meat lovers.. Well good luck.... You better realize that your vision does not fit the culture, you better be capable of fostering organizational learning in order to help people realize that vegetarianism will better align them with their environment and guarantee their survival, and you better be able to help the transition (change management).... if not, your cooking will never be appreciated not matter how good it is and how well it follows long-standing and short-standing best practices.

I personally believe that the key experience that most people refer to is learning about this human dimension of EA. I think that it is called organizational development and that by naming it when can start the process of helping people learn about through other mediums then just ad-hoc experience (trial and error).

BTW: I'm not a vegetarian :o)

Group Dynamics and Team Work

I recently participated in a Basic Human Interaction Laboratory (T-Group). It was an amazing experience that opened my eyes to the subtle but profond implications of fundamental group psychodynamics.

In the domain of software engineering, Fred Brooks once presented the concepts of accidental complexity and essential complexity. Put simply, given a problem to be solved, the accidental complexity of solving the problem is a consequence of the choices which are made when approaching the problem. In the context of software engineering, the specific programming language which is used to solve a problem will bring specific challenges which are independant of the problem. However, the challenge of defining an algorithm (recipe) that solves the problem is totally and only dependant of the problem to be solved, it is essential complexity.

These same ideas can be applied to group dynamics. If we remove all the accidental complexity of group dynamics such as past history between members, a task to accomplish, etc. we are left with the essential challenges (complexity) of group dynamics such as the management of power, inclusion, trust, conflict, prejudices, etc. A group must manage these elements in an effective manner in order to be functional and productive. Adding to a group the elements of past history between members and a task to accomplish will serve only as catalysts for the emergence of power and conflict issues, all of which are accidental complexity. The consequence of the latter is that work teams which only focus on the task at hand and give little importance to the quality of the dynamics of the group will most likely be less productive because they are not addressing the essential complexity of working in a group. I find it fascinating to observe work teams which present fundamental interpersonal issues between members that are not addressed and to see how these issues constantly resurface in different forms while trying to accomplish their collective tasks. It is interesting to see how blame is often put on the task or external agents to the team instead of on the team itself when the team becomes dysfunctional or unproductive.

My experience in the lab showed me how very often the team members are to blame when the team becomes dysfuncitonal because of their inability to face openly issues of conflict, power, etc. To openly name an issue and to have the group reflect on it is most of the work in moving towards solving the issue. However, to achieve this, the challenge is often to create a sense of security, trust, care and respect in the gorup which is essential to foster open discussions.

EA and OD : The perfect mix

I believe that the enterprise architecture (EA) function should also include organizational development (OD) as a key discipline in order to be effective. The underlying metaphor which many EA professionals use to view and understand corporations is that of a “machine”. The use of this metaphor brings us to discuss EA in terms of “design”, “structure”, “building”, “repairing”, etc.

Although this metaphor might be appropriate for discussing and managing technological issues, it is far too simplistic to manage the human impacts of EA visions and decisions. Despite this, all too often, we see or hear about situations in which this impact is managed by “planning”, “orchestrating” and “controlling”; all these words relate to the “machine” metaphor and have a connotation of “control” of the situation. Typically, one can only “facilitate”, “support” and “foster” change; all words which do not have a connotation of “control” but rather of “influence” on a situation. Hence, EA initiatives are greatly hindered by the natural resistance to change by all individuals when this change is managed by “control”.

Organizational learning is another important contribution that OD can bring to the EA function. EA roadmaps will most often require the enterprise to develop new knowledge and skills in order to implement them effectively as well as sustain that implementation. Despite this, the management of these learning needs is often second in importance to the implementation. An approach such as this can only eat away at the “value added” of the roadmap.

Process facilitation and human system intervention are other important skills from the OD domain which EA professionals should learn in order to :
-Build helping relationships;
-Facilitate problem solving;
-Give feedback;
-Help project teams become more effective;
-Be aware of group psychodynamics;
-Enable “grassroot” EA roadmaps.

I believe that the contributions of Schein, Lewin, Block and Senge should be part of the book collection of all EA professionals.

Knowledge Management - Some first thoughts

Knowledge management is often perceived as the management of knowledge sharing. However, it is a much broader discipline which encompasses a range of practices used in an organization to identify, create, represent, distribute and enable adoption of insights and experiences. In order to be effective, knowledge management must be based on a robust learning management program.
Learning management addresses the need of organizing in a structured and strategic manner the creation and distribution of knowledge within an organization in order to increase performance and business value creation. As such, one may perceive knowledge management of an extension of the former in which knowledge is create in an ad-hoc fashion by the collective and distributed through collaborative mediums. Many benefits may be achieved by the adoption and implementation of learning and knowledge management:

• Enable high performance through workforce transformation;
• Enable individuals to achieve a more holistic view of the organization as well as their role in the creation of business value;
• Facilitate organizational-wide change management;
• Foster a culture of a “collective” and team-driven success.

Accenture Consulting, a world leader in the sector of consulting services, has achieved great competitive advantage from its capacity to manage the knowledge of its workforce. The company is well known for its innovative approach to learning and knowledge management which has enabled it to offer innovative business value creation solutions. Their approach to learning management has become an industry wide benchmark. They have also innovated by their demonstration of the substantial financial benefits (353% return) called “return on learning” that could be achieved by investing in learning. The following important statements may be made about Accenture’s learning management functional:

• The learning function is run like a business;
• A philosophy of “just-in-time learning” is adopted instead of “just-in-case”;
• Learning is focused on achieving business needs;
• A “phenomenal” learning experience is core to the approach;
• The responsibility is shared between business and training groups.

I believe that all IT organizations should (not to say must) implement knowledge management. Moreover, its implementation should differ little from Accenture's. Many perceive ITs as different from consulting services organization because of the latters focus on revenue and the other on cost. Hence, many IT organizations (and corporations) minimize the importance of investing important sums in learning and knowledge management under the pretext that it is not necessary for their economic survival. I beg to differ.

Accenture's goal when investing money in these activites can be applied to all organizations : to maximize productivity and efficiency. The only important different I believe one will see between various organizations is the targeted outcome. By achieving it goal, Accenture benefits from higher profit margins; ITs benefit from the other side of the coin : lower overhead costs. In the end, both outcomes are the same : if an IT has high overhead costs then it will be easily replaced by an outsourcing firm that has low overhead costs allowing it to offer the same service for less will still making a profit.

Wrongful use of organization design

The design of an organization is a key element which can greatly influence interpersonal group dynamics. As such, an organization's design should faciliate group dynamics which foster the espoused values of the organization; at the opposite, the wrong design can greatly hinder cultural goals. For example, an organization which values team work and intergroup collaboration, by using a matrix structure, will promote rich interpersonal group dynamics. At the opposite, using a highly structured functional model would promote little lateral interpersonal exchanges and would foster a culture of "them and us".

Organizational design can and will help forge culture and interpersonal group dynamics, however it is probably not the most effective tool to influence or manage aspects such as knowledge management. To often, manager are too quick at using organisation redesign as a tool to manage problems. They wrongfully use the "divide and conquer" approach to organization design under the assumption that if there are issues to be solve in their group, creating smaller and more focused sub-groups will surely be the solution. If the issue is a gap in the KSA (knowledge, skills and aptitudes) of the group, no matter how a group of people is slided and diced, the issue will no be resolved.

A new view of the world

Over the last couple of months I have become increasingly interested in the topics of organizational culture and change management. The major cause of these newly found interests was the ever growing frustration I was feeling when faced with my inability to understand (what seem to be at the time) the “irrational” behavior of many people I worked with. Mainly, I could not understand why people were so determined to resist change and continue to use “what I\we have always done” ways of doing things.

Reading books from Kotter and Schein has opened my eyes to a whole new world shaped by beliefs, values and deep assumptions. Up to this point, being a technologist, I held the unconscious and deeply rooted assumption that an organization could be rationalized and controlled; none conformance could be managed simply through governance. Hence, changing the organization was merely a question of careful planning and methodic execution.

Today, I realize that my old Tayloristic view of organizations was outdated; it’s underlying “machine” metaphor was to simplistic in that it was incapable of capturing all the subtle but important psychodynamics which exist and drives human actions and interactions.

Exordium (The Beginning)

Through this blog, I wish to share my ideas and interests on various subjects such as information management, organizational learning, change management and semantic technologies just to name a few. I hope to get feedback and I'm always interested in discovering new subjects.