The Coherency Architect » Knowledge Management

Developing Frameworks: Five Things To Do and Five Things To Avoid.

CoherencyArchitect — Mon, 04 Jul 2011 08:00:36 +0000

The Essentials

While working with the concept of Enterprise Architecture it usually becomes a necessity to chose and implement a framework. As such the chief architect can either implement a standard framework, and as such commence the project of documenting the AS – IS situation¹. It is an option to adapt the standard framework in order to make it suitable for the enterprise as such make it work better in the implementation process. An alternative to deal with a standard framework the chief architect could develop his or her own framework that from the start has been developed in mind to the specific enterprise. This specific paper is dealing with some pitfalls that I have identified while I have been working with developing a framework by myself.

I will first and foremost outline my definition of what a framework is, then I will deal with which five problems I have encountered and how these problems can be avoided. As such this will become a list of dos and don’ts. Finally I will summarize my findings in a conclusion.

What is a Framework

There are several reasons to apply a framework e.g. the potential of increasing the success rate of the implementation of the Enterprise Architecture program, and as such I have chosen to go in depth with a definition of what I think a framework is about.
I have defined the concept of the Enterprise Architecture framework as essentially a document that outlines which artifacts the chief architect and the Enterprise Architecture group should be identifying, describing and organizing into a repository. Thereto does the framework defines which roles that are supposed to be in the Enterprise Architecture group and how the AS-IS state should be documented. Likewise does the framework details how the scenarios deals with the process of change from the AS – IS situation to a desired TO-BE situation. In between these two it usually a good idea to have a transition plan (Bernard 2005, p. 33).

I have now defined how I understand the concept of the framework. The framework is a key element in order to implement an organized documented overview of the AS – IS situation of the enterprise.

Problems and Solutions

The chief architect should include stakeholders for its internal environment in order to gain an understanding of how they understand the enterprise’s social systems, business systems and information systems. As such the chief architect would have to gain an understanding of how each of the parts of the enterprise works and how these systems interact with one another.

The framework should reflect the organization since it would have to reflect the current conditions yet the framework would have to be used as common reference model for the Enterprise Architecture group. Eventually should the framework be adaptable to filters in order to give the various stakeholders the information that they would need in order to ensure buy-in and support for the changes needed in order to transform the enterprise to the desired state.

While developing the framework the chief architect shouldn’t make the framework too complex in order to the level of details and the language used. Likewise should the chief architect be aware of that the repositories that he choses should be dynamic due to the possible rapid changes in the architecture of the enterprise while the organizational changes are occurring. I am of the opinion that organizations changes more rapidly than the decision makers realizes since people changes habits and their ways to deal with certain tasks due to the changes in their (and thereby the enterprise’s environment). I have come this particular opinion due to an article I have read by Orton and Weick (1990) where Orton & Weick argues that there are several voices of loosely coupling, and one of these voices (the voice of typology) deals with the fragmented environment impacts the possibility to enforce change onto the social systems (Orton & Weick 1990, pp. 207-210) due to connections and impacts of the internal and external environments will in some points stop a centrally planned change.
It is a necessity to avoid rigidity and too much bureaucracy so to say the chief architect would have to avoid creating a paper tiger. It is one of the major problems with Enterprise Architecture , and Wagter et al. (2005, p. 178) discusses in their book titled “Dynamic Enterprise Architecture”. Likewise does Wagter et al. discusses the concept of implementing Enterprise Architecture in small steps and small sections due to the unnecessary usage of the enterprise’s resources in implementing a system in a world where all resources should be contributing to the enterprise’s competitive advantage.

Dos and Don’ts

In order to give the various chief architects or other individuals in the Enterprise Architecture groups in the enterprises out in the industries, I have articulated five things to do order to develop a good framework. Likewise have I articulated a list of five pitfalls that the chief architect or others in the Enterprise Architecture group should avoid in order to implement a successful framework.

Dos	Don’ts
1) Do include stakeholders in the development of the framework.	1) Don’t focus too much on the technical architecture while you develop your framework.
2) Do work with both social systems, business processes and IT.	2) Don’t assume that the framework can be used for a total codification of knowledge in the enterprise.
3) Do work with the business architecture. After all it is the enterprise’s business systems that generates value.	3) Don’t assume that the framework is perfect after you have designed it at the desk. The framework has to be improved during the implementation and after the implementation since new stuff and perspectives will occur.
4) Do work with an approach to keep the framework simple.	4) Don’t assume that people align themselves with a centrally planned strategy. Assume that the organization consists of many different entities that can be impacted by elements outside the organization’s boundary.
5) Do work with the stakeholders understanding of what the framework is and why it is important.	5) Don’t develop a “paper tiger” it makes no sense to develop at lot documents that nobody reads or acts according to.

Which leads to the conclusion of this paper.

Conclusions

A framework is a fundamental element that the chief architect and the decision makers of the enterprise have to be involved with in order to ensure that the Enterprise Architecture program can be implemented in the enterprise. As such there are five things that the chief architect should take into consideration while developing his action plan e.g. Include the stakeholders in the development of the framework, the inclusion of business and IT, the business architecture is the primary architecture, keep the framework simple and ensure that the stakeholders understand what the framework is about and why it is important. Likewise are there five pitfalls that the chief architect has to take into consideration while he develops on the framework e.g. avoid to focus too much on the technical architecture, he shouldn’t assume that the framework is a Swiss army knife in regards to knowledge sharing, he shouldn’t think that the framework is perfect, especially pre-implementation, he shouldn’t believe that people just align themselves with planes developed by a central administration and last but certainly not least. The chief architect shouldn’t develop a paper tiger.

The keyword to framework development is simplicity, prototyping and iterative change.

Bibliography

Bernard, S., A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.
J. D Orton and K. E Weick, “Loosely coupled systems: A reconceptualization,” The Academy of Management Review 15, no. 2 (1990): 203–223.

Roel Wagter et al., Dynamic Enterprise Architecture: How to Make It Work, 1st ed. (Wiley, 2005).

1The situation as it is in the current moment.

A Coherent Architecture as a Strategy

CoherencyArchitect — Sun, 22 Nov 2009 20:37:04 +0000

There are several issues that influence the competitiveness of any organization. These factors are to be found in any domain (and are almost generic). This means that the organization will lead to the innovation, growth and decline of organizations.
Some organizations are privileged by owning a monopoly either backed by a government or by the fact that their products or services are superior to any of the competitors on the market. This makes the organization rather good to earn money since they often can set the price for the products and services as they want to; however this also leads to lack of agility since the pressure of the free market isn’t influencing the decision making of the management or the employees.
When organizations growth then they have a tendency to become more bureaucratic since there is a greater need for coordinating among the members of the organization, departments and management. This leads to a great degree of standardization but it also leads to a decline in agility compared to changes in the domain of the organization.
Therefore it becomes a question on how to cope with the need for coordination (bureaucracy) and the need for agility.
This can become an influence that impacts the organization and if it is used correctly then the organization can gain a competitive advantage.
Likewise can the way the organization make use of a technology become a competitive advantage for the organization. An example of this is that the organization might be superior to any competitors to utilize their information technology like software and hardware to support and develop their processes. These processes might in return prove to become easier to handle and create more value than the processes the competitors of the organization have.
Organization culture might also prove to become a competitive advantage since it indoctrinates the employees to act in a specific way. If the organization culture makes the members of the organization find and discover errors and eliminate the errors then the cost of repair and service fall and re-enforce the brand of the organization and re-enforce the good will the customers of the organization has to the organization.
Thereto will coherency management assist the host organization with creating a competitive advantage since it will assist the management and the various other stakeholders in the organization developing the necessary overview and consistent information that can be used to make the proper decisions.
Thereto if IT, business processes, organization culture, corporate strategy aren’t aligned then the organization will experience that the system is not able to fulfill the its potential and will therefore the organization will experience opportunity costs.
It is therefore in the interest of the management to work with the organization to achieve its goals and it is in the interest of the employees to assist making their work place better for them. It is the interest of them to feel productive and feel that their work matters for the organization. It is therefore a paradigm to involve them in the decision making but they too should be kept informed on how the organization develops.
Coherency Management is building on the principles on identifying the underlying architecture in the organization and enhancing the development of the architecture and by that the organization.
This is done by applying the tools from Enterprise Architecture to identify and evaluate the various processes and adding the technology needed to enhance the processes or re-think the processes to generate more organizational value.
It is therefore a strategical tool to evaluate and rebuild the architecture of the organization to match those tasks and challenges the organization will face in the future competition. A solid architecture which can be extended and reused will be a necessity in the future so the organization can grow and develop an architecture that can be used to connect the processes, people, departments and organizations to develop the right products and services to the right price.

Organizations will in the future be able to align them self to one or more syndicates to create products which are cheap enough to sell to the people in the third world. The organizations in these syndicates have to know their architecture to understand and connect to these shifting syndicates and if these organizations either don’t know or understand their architecture then they will not be able to join the syndicates and gain the benefits from it.

Therefore is it of strategic importance that all organization work with and articulate their architecture to enable abilities of agility, knowledge and innovation and to that all the support functions and processes to enable interactions with so called networked organizations and syndicates.

To give the analyst some insight into how IT influences the an Architecture then it is advised that the analyst reads about critical issues in IT management.

How Coherency Management Impacts Knowledge Management

CoherencyArchitect — Thu, 01 Oct 2009 21:43:57 +0000

The Coherency Architect has to take knowledge into account when the architecture of the organization is to be upgraded. The reason for this is that the key to develop the architecture of any organization is the members (Managers and Employees) of the organization. Most knowledge is implicit meaning that the knowledge is embedded in the brains of the members of the organization. This means that if the members choose to leave the organization then the knowledge will follow them. Knowledge can be diffused from individual to individual, from written sources to an individual and by members who modify and enrich the written sources to others who enrich them.
To represent this point of view then it is feasible to make use of Nonaka’s framework (see illustration 1).

Nonaka's Framework

The SECI model deals with that all knowledge is made by individuals, the individual share his or her knowledge with other individuals (first quadrant) in order to diffuse knowledge then it has to be articulated e.g., in papers, reports, books, blogs, videos or podcasts or other media (second quadrant). When knowledge is diffused then there are individuals who can enrich it by adding to the articulated knowledge (third quadrant). Individuals then read the papers, reports, books, blogs or watch the videos or listen to the audio and then by that learns how to make use of the knowledge and by that makes the knowledge implicit (fourth quadrant).

As before mentioned then the members of the organization are key in relation to the development of the organization architecture. Which means that the members of the organization have to be enabled to share their knowledge with one another and they would need some incentives to do so.
It is notable that economic incentives for sharing knowledge almost certainly will lead to that the cost for knowledge will increase and yet it will lead to that at some point then the members will stop sharing their knowledge and eventually when they have received all the incentives the organization can provide them with then will stop sharing knowledge.
E.g., who might want four company cellphones that are exactly a like or two company cars or multiple company paid DSL connections etc.?
To avoid this situation then the Coherency Architect has to understand the organization culture and thereto the Coherency Architect has to influence the organization culture so it becomes a necessity to motivate the members of the organization to make use of the IT tools (web 2.0) and to share their knowledge with the rest of the organization.
To enable the members of the organization to share their knowledge then the Coherency Architect has to empower the members and by that focus on moving the organization typology towards the adhocracy (Primary coordination is mutual adjustment) or towards the professional bureaucracy (primary coordination form is the skills the individual member has). Thereto should the organization should give the employees the resources to form communities of practice where they can go and communicate, work with and share the knowledge. It is notable that Coherency Architect or for that matter the organization can’t go in and interfere in the process which will lead to the members of the communities will lose their interest in working in the communities.
To make knowledge management coherent with other processes in the organization then the Coherency Architect should work with how the business processes can be supported by 1) decentralization and empowerment, 2) how IT can enable the members to break down the barriers in the organization (so the knowledge can flow freely), 3) how a functional compensation system should be designed (cultural based) so it enforces the urge to share knowledge and 4) deployment of communities of practice (winning trust among the members of the organization and providing the necessary support) and continuously align the primary business processes to the knowledge sharing processes.
The Coherency Architect has to think in new terms to ensure that the organization achives its goal in a smarter way which means that the work processes have to be obliterated and designed to interact with the technology new and smarter processes; however it is notable that the Coherency Architect has to understand that if the members of the organization finds the changes undesirable then they will reject the processes and work against them and key employees will eventually grow discontent and leave the organization taking the knowledge with them.