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.