Dealing with Systemic Problems Through the Enterprise Architecture Program

There are many problems the chief architect, enterprise architects, CIOs, executives and decision-makers on all levels will be facing while handling the day to day operations. Quite a few problems that they will be dealing with are symptoms of larger more complex problems or what I have chosen to define as “systemic problems”.

Systemic problems are the roots of why processes do not seem to connect resources, parts of the products that are to be delivered to the customers are bulked up or simply not arriving at the right place at the right time, information that isn’t shared across several different parts of the enterprise. Such symptoms can usually be dealt with rather easily e.g. a systems architect would say that an information system can be constructed in order to create an overview of the information and share the information among the stakeholders, and so the stakeholders believe the problem has been solved; however quite often will the problem not be solved e.g. the information that the system has to make use of in order to create forecast and delivery dates can’t produce any useful information if no one provides information to the system and likewise will the system not deliver any kind of value if those who are supposed to react upon the information delivered don’t do so.

So what can the chief architect and the enterprise architects do in order to find out if there is a systemic problem, and how to gain an overview of the problem(s) in order to find out more about the systemic problem and identify solutions for how to deal with the problems.

As I see it most systemic problems share similarities with “wicked problems”. Wicked problems are defined as problems that are defying logic, they includes various perspective, they are connected through different problems that occur and they can’t bet solved the regular linear way. All in all the chief architect would be in a problem where he and the other members of the enterprise architecture team would have to share their knowledge in order to find out how important the problems associated with the symptoms are, and how the enterprise architecture team can contribute to solving the problems.

One of the great problems applying resources to deal with systemic problems is that the problems involve many different segments of the enterprise and as such all the stakeholders that have something to say would have to be involved. The problems could potentially prove to be hard to solve due to the situation where the enterprise would have to allocated resources to deal with the problem, that is hard to define and where it is hard to identify which of the segments that would have to contribute what. Politics can’t be avoided in order to solve the problem and that means that the decision-makers on various levels in the enterprise would have to be involved and the scenarios for solving the systemic problem would have be changed in order to gain the trust of the important decision-makers.

Besides politics and the allocation of resources there several other barriers that the chief architect and the enterprise architecture group will be facing e.g.:

  • Furthermore does time means money.
  • Opportunity cost can be hard to estimate.
  • Mental models that are frozen.
  • Organization cultures that are notorious hard to change.
  • Power issues and accountability for changing the status quo.

Each of the barriers above would be hard to deal with in the short or for that matter in the long run; however the role of the enterprise architecture program would be to identify the capabilities that the enterprise possess and how they can be made use of in order to gain the insight.

The question becomes how can enterprise architecture program assist the enterprise with solving the systemic (wicked problems).

The way I see possibilities of using the enterprise architecture program is through combining the documentation process with the process of questioning the various stakeholders in the various segments and through that feedback the enterprise architects are able to define a view of the situation that can be used to facilitate workshops where the stakeholders can comment and ask for changes. When this process has been taken care of the enterprise architects would bring back the knowledge they have collected and draw a map dealing with the problems they have been able to identify and from that they would prioritize the problems. The map could be build upon the concept of a rich picture with more layers. This model could with some benefit be mapped in the modeling tool. The chief architect could present the findings to the various decision-makers in the enterprise in order to create a pattern for how the enterprise can get over the systemic problem.

The decision-makers can from that information get a significant better overview of the situation (in any case it is better than having no information what so ever) and decide what to do in order to improve the situation. As I have earlier mentioned then there are no quick fixes to wicked problems and likewise are there few, if none, of the solutions that can be proclaimed the right solution for the problems the enterprise faces. The solutions are to be defined only on if the solutions improve or demote the situation for the enterprise.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s