Category Archives: Roles of Enterprise Architects

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.

The Enterprise Architect: The Abilities of the Enterprise Architect, and what Should be Expected of Him.

The Enterprise Architect

There is no real definition of what an enterprise architect is or what he or she does. There is no exact definition of what the enterprise architect does and where he can be found in the enterprise. There are many different disciplines within the sphere for the enterprise that has something to do with Enterprise Architecture.

According to Doucet et al (2009) there are both explicits and implicit roles dealing with enterprise architecture, especially if the architecture is mature. The roles all have something to do with being enterprise architects, and there are different ways how they interact with the architecture.

The Chief Architect is according to Bernard (2005) the person who is in charge of establishing an Enterprise Architecture group in the enterprise, and likewise is it the Chief Architect who choses or creates a synthesis for a framework that can be made use of in the particular enterprise. It is Chief Architect who selects who are to take part of the particular enterprise architecture group and what each individual is supposed to do.

The definition that Bernard proposes is that the enterprise architect is a kind of liaison among other forms of architects like solution architects, technology architects, business architects. The enterprise architect the person who works as liaison but also the person who translate, codify and organize the various artifacts.

At the conference on Enterprise Architecture in Copenhagen 2010 the representative for The Open Group said “that The Open Group Architecture Framework has to be adapted to the individual enterprise otherwise wouldn’t give the enterprise any value to make use of it” this particular statement from the largest provider of frameworks illustrates the importance of the Chief Architect and the synthesis process. It does also stress the importance of the highly adaptable enterprise architect who can see possibilities and act upon them.

Op’t Land et al (2009) presented in the book “Enterprise Architecture: Creating Value by Informed Governance” different roles that characterize the enterprise architect. They define the roles as follows:

  1. The Change Agent. The change agent has to encourage both the management and the employees to change their views on what Enterprise Architecture is, and adapt the policies and programs that the Enterprise Architecture can generate for them.

  2. The Leader as having a vision for the Enterprise Architecture program. This includes a visionary focus on the various strategies and how they influence the Enterprise Architecture program.

  3. The Manager has to make sure that the Enterprise Architecture Program is dealt with and updated so it entails the proper way to do practices, projects and principles are kept alive and these are meaningful for “the business” of the enterprise.

  4. The Communicator is one of the roles that the chief architect and the team of enterprise architects have to master to achieve that the various stakeholders collaborate.

  5. The Modeler is a role that is necessary to master for any given enterprise architect, otherwise wouldn’t he or she not be able to create the META-models needed to show how the enterprise works and should be working.

Furthermore did Op’t Land et al (2009. p 119) argue that the Enterprise Architect has five different ways of thinking within the perspective of working and changing the enterprise. These ways of thinking are dealt with below.

  1. Yellowprint – thinking that deals with brings interests together, the approach includes stimulating stakeholders, formulating opinions, creating a “win – win” situation and forming coalitions.

  2. Blueprint – thinking that deals with formulation of unambiguous objectives, development of an action plan, that includes monitoring and adjusting the change process accordingly.

  3. Redprint – thinking deals with ensuring people are aware of new perspectives, ensuring that they (people) are aware of their personal shortcomings. Last but not least does it deal with motivation of the people to see, learn and do things. The focus is the learning process.

  4. Whiteprint – thinking deals with articulation of plans that includes people’s processes, interests and energies. The focus deals with the removal of blockades and barriers.

All of the above mentioned ways of thinking are necessary for the enterprise architects to be able to operate with the Enterprise Architecture approach. It depends on the situation and the the maturity of the enterprise’s architecture.

In conclusion it is important that the enterprise architect can see possibilities and he or she is able to act upon his justified instinct and deal with various people who work and thinks in silos or sees the world very differently from the Enterprise Architects. The Enterprise Architects would have to be able to sell the idea of Enterprise Architecture to people who resent holistic approaches and systems thinking and in the same way be able to be diplomatic.

All of the above mentioned characteristics are to be operationalized in the enterprises regardless of how mature their Enterprise Architecture programs are. Furthermore does the views that Hoogervorst et al (2009) presents and the views that I present in this blog post indicate that the enterprises would have to test the enterprise architects in order to investigate what kind of architects they need and define what roles they would have.

The Chief Architect and the Roles in the Enterprise

Doucet et al (2009) argues that in order to mature the enterprise’s architecture it is a necessity to change a few roles within the management group and for that matter within the IT group. Doucet et al. argues for the changes in the IT – organization is because the concept of Enterprise Architecture originates from the IT department and the world of Information Systems it is a necessity to force the management of the IT department (and this usually includes the management of the Enterprise Architecture group) to think in new ways.

Doucet et al argues that in the perfect world the ownership of the Enterprise Architecture program has to change from the IT department (the CIO) to a leader within the organization who works with the operations or other executive.

In my opinion the change of focus is needed as long it doesn’t mean that IT and the enablement of new and old business processes aren’t neglected. Likewise does Potts (corporate strategist, speaker and author) advocate for a new and slightly different approach to IT management and IT investment. His approach that entails that the CIO role should be abolished and replaced with the role of chief internal investments officer (CIIO).

The CIO or his successor CIIO should deal with corporate transformation through investment planning and corporate program management that would have to entail all strategically important projects. Strategy is according to Potts the implicit and it is defined by the embodiment of actions taken by the executive group. This is in its way a perfect situation for the chief architects and for that matter the enterprise architects since they would be able to identify how the enterprise has invested its resources and how they in the future would be able to invest.

The Elite Architecture

According to Doucet et al (2009) the focus of working with the Enterprise Architecture program is to go beyond the IT – centric approach that usually is applied in the IT department. In this approach it becomes a necessity to work with the maturation of the Enterprise Architecture program and by that establishing a group of elite architects who in term work withs the focus of developing and adapting the Enterprise Architecture approach to solve the problems that the enterprise experience. The focus of the elite architecture is to aid those enterprise architects that are involved in the various business units. In other words the focus is to facilitate a community of practice.

The establishment and later on the facilitation of communities of practice seems to be the greatest difficulty for the enterprise.

In my opinion it isn’t possible to establish communities of practice, they are simply a social phenomena that happens if the right people are present at the right time. However it is a possibility to facilitate the communities of practice after the enterprise has identified what they are and who participate; however this is only possible to a certain degree.

If the management or other element within the enterprise begin to interfere with the community of practice it will eventually become irrelevant and dissolve itself.

Communities of practice are too specialized in their ability to deal with their tasks, and impact of the behavior of the people who participate in them are to random to any kind of generic rule for dealing with facilitation of communities of practice can be established.

Focus has to be on the enterprise allows people from different parts of the enterprise to meet in areas suited for meetings and informal talks.

The community of practice would enable the enterprise with achieving an elite architecture team and as a result an elite architecture program.

The architects would have to interact with one another in different ways and tasks where they can take advantage on the expertise that they posses and the understanding of these expertise and the registration of knowledge abilities they posses.

In order to achieve elite architecture the enterprise would have to establish an incentives program that ensures that the enterprise architects who evolve with the Enterprise Architecture program can handle tasks that are suitable for their personal development and as such could this enable the enterprises to retain knowledge on how to innovate, develop, deploy and mature its enterprise architecture. It is needless to say that the hypothesis of this blog post is that the more mature the enterprise’s architecture is, the better the enterprise would be able to assure alignment, assurance and agility and through that would the enterprise be able to crystallize competitive potential into competitive advantages.


Doucet, G. et al., 2009. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, International Enterprise Architecture Institute.

Land, M.O. et al., 2008. Enterprise Architecture: Creating Value by Informed Governance, Springer.

Potts, C., 2008. fruITion: Creating the Ultimate Corporate Strategy for Information Technology illustrated edition., Technics Publications, LLC.