Many enterprises experience a more intense form of competition and for that matter a more intense form of pressure from the outside the enterprise e.g. through financial institutions, government agencies and customers that demand more and better products for less money.

In such situations there are several perspectives that the enterprise’s decision makers would have to take into consideration when it comes to how the enterprise should develop in order to achieve the goals and objectives that have been defined by the various groups of stakeholders within the enterprise.

In regard to this I have to confess, that I work in a Scandinavian environment where other stakeholders than the executives can have a significant influence on where the enterprise is heading and with what measures it have to be done with, and that has an impact on my view on how to deal with the process of defining capabilities and how to execute strategies.

When I speak of capability then I am defining it as how the enterprise is able to execute activities or processes that are related to realistic strategic initiatives.

Activities and resources can be defined as those who deals with something in a specific way in order to complete a particular task or for that matter reach a particular objective. Activities can to some extend be defined as processes if they are grouped as such by the enterprise that is investigated.

Resources deals with the people, machinery, structures and systems there are at hand. When mentioning structures and systems then it is possible to deal with how people interact with one another in order to handle the activities or processes. Structures are in this regard how various hierarchies work and how the distribution of people within departments do things in various ways. Systems can in this case be a bit bogus. The first way I have chosen to understand and later on defining a system is through a hypothesis that it can be a social system where people interact in a formal and for that matter an informal way, and the concept of a system can be a set of coupled information systems transforms data (input) into information. Information systems are combined with structures in order to develop the information needed for the decision makers. As earlier mentioned there can be several layers in the decision-making platform in Scandinavian companies, and as a result there are several different needs in order to deal with the information available.

An Enterprise Architecture program is about taking charge of the people, the activities, the structures, the systems and synergies that exists in the enterprise and transform relatively complex information into useable information for the decision-makers.

The question is to find information that has been validated and that can be trusted. The information should provide the decision-makers with a set of scenarios and opportunities that summaries the capabilities of the enterprise.

The Maps

So how do you map the capabilities of the enterprise?

First and foremost you will never be able to map all the capabilities or for that matter simulate all the scenarios. First of all why would you? The enterprise you work for has limited resources available for the doing so in the first place and secondly you would probably have a lot of other things to do as Enterprise Architect in your enterprise e.g. continuing to convince stakeholders to commit their support for the Enterprise Architecture program.

So the question becomes, how do you transform the information you got organized in your Enterprise Architecture repository into capabilities?

The first and foremost action to take is to consult the various specialists, middle managers and people who have the first hand experience with working with the activities and processes in order to gain an insight in how the enterprise is working and how the various parties perceives the problems at hand and what barriers and obstacles that the enterprise would have to cope with in order to achieve an objective.

The second action to take would be dealing with organizing the impressions and validate each one of the impressions in order to identify ways to do things in a smarter way and identify issues that could be dealt with in easy ways and issues that seems systemic of nature. This process is a rather subjective one and it is very likely that a great deal of the stakeholders will disapprove of the particular prioritization of the issues, barriers and capabilities. The reason for this might that they assume that their problems or issues with the current architecture are way more important than those of the rest of the enterprise.

In other words don’t expect to become popular with all people in the enterprise while you prioritize and develop the capability map, but you can do a lot of things in order to convince the various stakeholders the necessity to deal with the problems at hand.

The third action to take would be dealing with organizing the feedback and validating the first set of impressions from the various forms of the issues dealing with capabilities, barriers and problems.

The fourth action to take would be to create the map presented to the decision-makers in the enterprise. The capabilities map should in turn be combined with scenarios due to the problems the enterprise will face with the increasing competition and availability of resources.

The Capability Map

The way I see it, the capability map shares a lot of features with the rich picture (as described by Checkland and Mathiassen, in each of the two separate books on information systems development), the user can apply a lot of different notation forms in order to illustrate the situation the enterprise would be dealing with if a particular scenario would be realized. Though I have found that some icons or pictograms to be more useful than others e.g.:

Icons for the Capability Map

And for that matter can a grid be applied in order to give the decision-makers a good insight to when it could be a necessity to deal with the capabilities in the enterprise. I make use of a 3 x 3 grid where the vertical axis is strategic importance and the horizontal axis is time.

3 x 3 Grid

So what is the capability map good for?

It is good for illustrating how the enterprise can achieve its objectives by (re)organizing and execute strategies through informed governance. One way of achieving informed governance is through an Enterprise Architecture program.

Furthermore, the capabilities map is good for dealing with communication with stakeholders within the enterprise and convincing decision-makers to initiate specific strategic plans.

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.

In most enterprises that applies Enterprise Architecture will there be a need to measure how the enterprise is progressing from adapting the Enterprise Architecture Program and there will be some stakeholders who would like to know what value or benefits they gain by investing (and keep financing) the Enterprise Architecture Program.

Enterprise Architecture Processes

Implementing Enterprise Architecture principles, standards, systems and strategies would need some changes, processes and scoping. In this particular paper the idea of Enterprise Architecture processes deals with the concept that a chief architect sets a set of tasks in motion in order to uncover systems, social networks and business processes. The Enterprise Architecture processes differs from business processes by the architectural processes changes systems, business processes, information systems, IT, technology and social systems. Business processes deals only with optimizing the flow of production and goods.

The Enterprise Architecture Processes deals with implementing the structured approach to Enterprise Architecture and to keep maintaining and maturing it. It is quite right that the Enterprise Architecture program would have to be maintained in order to ensure its functional in the long run.

If you can’t measure it, you can’t manage it
– W. Edwards Deming.

Measuring

The chief architect would have to develop some KPIs in order to measure the processes that are a part of the Enterprise Architecture Program. In order to gain an overview of the processes it becomes a necessity to measure the processes before the initiatives have been initiated in the Enterprise Architecture Program. In the ideal situation the chief architect would have to investigate how the business performed before the Enterprise Architecture Program was initiated. The measurement should be used in order to improve the decision makers abilities to make the right decisions. In order to investigate if the proposed changes that have been implemented with the Enterprise Architecture Program have improved the situation for the enterprise, the chief architect would have to measure the “as-is” situation for the processes and “to-be” would have to be like. After the processes have been implemented the ideas would have to give the decision-makers an idea of or if the enterprise has moved closer to a desired state. For this key performance indicators can be a rather good tool for measuring.
The next section of the paper deals with the concept of key performance indicators.

Key Performance Indicators

In this paper a key performance indicator is defined as a number (simple indicator) indicating how a process or segment of an enterprise works. Key performance indicator is a simple tool that gives the various stakeholders data for interpretation and as such the KPI can’t stand alone it has to be accompanied with in-depth analysis documents.

Key performance indicators (KPIs) are suitable situations when the decision-makers would have to a quick overview of how the enterprise works (processes, segments and systems).

The KPIs would have enable the chief architect and the various other profiles that are a part of the Enterprise Architecture group with the appropriate data from the various systems.

KPIs have a significant factor within the concept of the Enterprise Architecture Program due to the various elements of the enterprise’s architecture works.

The KPI is needed is used as by the decision-makers in order to find out if there are any particular problems in the day to day management. Each of the KPIs can guide the decision-makers and it would be able to misguide the decision-makers. In order to find out if the KPI is adding the right value to the the overview that the decision-makers understand the KPI and how it should be used. Likewise does it become a necessity to deal with the KPI in order to understand if the KPI can be used in order to gain the overview in the in the enterprise. KPIs are by all means simplified and it becomes a necessity for the chief architect and for that matter the enterprise architects investigates if the KPI is too simplified and if the KPI can be implemented in the enterprise at hand.

Validating the KPIs

In order to validate the KPIs the chief architect would have to go into the situation of the various groups in the enterprise e.g. do the various actors understand what is to be measured and how they are measured. It is a necessity to challenge each of the KPIs and their stakeholders in order to find the best possible way to ensure that the KPIs measures contributes with value.

Five Things to do in KPI – EA Development

As promised I will hereby present five things that the chief architect could do in order to develop usable KPIs:

1) Identify what KPIs are relevant for the enterprise from a business point of view. Associate other KPIs when the business KPIs have been identified.

2) Probe the views of the enterprise’s decision-makers and those who would make use of the KPIs. Ensure that the business-stakeholders understands why the KPIs have been chosen and what they represent.

3) Articulate a draft for the KPIs and simulate how they impact the decision-makers and if they give the right kind of indication to the decision-makers. Ensure that you incorporate business-politics in your plan for implementing the KPIs.

4) Refine the KPIs and educate the various stakeholders and decision-makers in how the make use of the KPIs and when not to make use of them.

5) Build in the KPIs for the Enterprise Architecture program and ensure that the KPIs are visible in all the various forms of governance structure that are directly related to the Enterprise Architecture program.

]]> http://coherencyarchitect.com/2011/09/26/five-things-to-do-in-order-to-deal-with-kpis-for-enterprise-architecture-approaches-to-measuring-enterprise-architecture-processes/feed/ 0 coherencyarchitect http://coherencyarchitect.com/2011/08/26/perspectives-of-enterprising-architecture-systems/ http://coherencyarchitect.com/2011/08/26/perspectives-of-enterprising-architecture-systems/#comments Fri, 26 Aug 2011 19:54:03 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=528 Continue reading →]]> Enterprising

This blog post deals with the summer school of week 31. The summer school dealt with the theme of “enterprising” which literally means anything from Enterprise Architecture, Viable Systems Models and technologies related to the systems development.

Sally Bean introduced concepts of Enterprise Architecture and systems thinking, and likewise did Patrick Hoverstadt introduced us to his particular perspective on systems thinking and Enterprise Architecture.

After the introduction of various participants in the summer school it could be concluded that a lot of different profiles attended the summer school. E.g. some had a background theological sciences, some had a background in childcare, some had a background in communication and some had a background in informatics and business administration.

Sally Bean started her presented with data on what her views of Enterprise Architecture is all about. From her presentation I noted a quotation about her views on The Open Group’s idea on what Enterprise Architecture is all about.

Sally Bean: “TOGAF is a body of knowledge but also a framework”.

During the first two hours we discussed the concept of Enterprise Architecture, the problems with Enterprise Architecture and the barriers facing the concept of Enterprise Architecture.

During the first session of the summer school the participants defined the following words (keywords) that would be dealt with during the Enterprise Architecture Summer Camp:

1. Selling.
2. Defining.
3. Doing.
4. Understanding.
5. Pragmatic.

Patrick Hoverstadt made some interesting comments on what Enterprise Architecture should be all about, and how systems works in their own ways. One of these remarks have been quoted below.

Hoverstadt: “People think and says a lot about systems but they rarely practice them. You can make the hole system more viable by “enabling” the individual VSM segments of the enterprise one by one to become sustainable and thereby ultra stabile”.

Perspectives on EA – A Conversation

A keynote by Sally Bean.

Context is really important to EA. Sally Bean is of the opinion that the various practitioners in the U.S. and G.B. have an IT background. Sally Bean has a background in IT. She has a background with working for the ministry of Defense and changed to working for British Airways’ department for operational research, and after she had joined the IT department, she joined the Enterprise Architecture group.

For about 10 years she worked with synthesizing a framework. In this regard Sally Bean stated “that you would need a mixture of theory and practice”.

From 2002 she dropped B.A. and went on consulting and as a result of this she was one of the founders of Enterprise Architects Anonymous.

She went on studying systems thinking and the Viable Systems Model, and as such she later experienced at a conference while speaking on other things than IT-oriented Enterprise Architecture that persons started to say it was wonderful to hear about EA in a non-IT related issue.

She went on presenting the fundamental model that Doucet et al (2009) presented. According to Sally Bean and John Gotze the focus was that quite a few do the embedded architecture but more and more practitioners and organizations works with the extended approach to Enterprise Architecture.

Sally Bean confirmed the assumption that all enterprises have an architecture even in conditions and contexts where electricity is a limited commodity.

Challenges that the Enterprise Architecture Community Faces

Sally Bean mentioned and ranked the challenges that faces the Enterprise Architecture community about it.

• Diversity, but the concept is to improve coherence, but the concept of Enterprise Architecture is rather diverse.
• Language and metaphor deals with that the Enterprise Architects and “ordinary” architects don’t do the same job the same way. They don’t architect the same way.
• Enterprises are more complex and embody a much stronger human dimension. Sally Bean was of the opinion that buildings aren’t a good metaphor for organizations.

According to Sally Bean then Enterprise Architects works with:

1. Map out change programmes.
2. Designing frameworks and meta models.
3. Business process management and re-designing.

From this part of the presentation Hoverstadt and Gotze had some rather interesting comments. Both of their comments (not directly quoted) have been included in the paragraph below.

According to Patrick Hoverstadt it appears that John Zachman has created a taxonomy for the enterprise. John Gotze talked about a conversation he and others had with John Zachman where Zachman had exclaimed: It is a framework, what you chose to do with it is up to you.

Architecture was defined by Sally Bean as:

1. “A non-linear process of enquiry, exploration and design.
2. Clear understanding of context.
3. Key principles required to achieve and maintain coherency, guiding design decision with an eye on the future.
4. A set of models that enable visualization and exploration of different perspectives on the situation.
5. The ability to identify common patterns and ways of reproducing or avoiding them.
6. An ultimate result that is pleasing and inspiring to the user and is capable of evolving gracefully over time.”

Sally Bean: “You don’t do bricolage on your chassis. Needless to say I believe this happens quite a few times in the lifespan of an organization in order to cope with the challenges and crisis that occurs in the environment of the organization.”

According to Sally Bean Enterprise Architecture is a bled of different types of activities e.g. prescriptive activities (which is named city planning), descriptive activities (e.g. blueprinting) and programmatic (that is named RoadMaps).

Descriptive activities are providing information, ensuring ownership, audience, and adds value to be understood.

Prescriptive that provides direction and guidance to be widely communicated and supported by governance procedures.

Programmatic activities coordinate architecture dependencies.

Sally Bean argued that the construction of a business map might improve the Enterprise Architecture governance. Map the important parts and challenge your views on the matter. Sally Bean defined herself as a corporate architect (not as an enterprise architect). This might be a question of terminology but in the end it has a significant impact on how to define roles for any Enterprise Architecture group. Sally Bean argued that the top segments on the model were the most important segments to deal with. E.g. the most important persons are in top of the diagram.

It depends on where from you interpreter it, and there are no right or wrong answers. According to Sally Bean there is no wrong in having the principles in the prescriptive.

Likewise are standards closer to the standards than to any of the other parts of the three major categories.

Target architecture is some sort of a future state of where “we” are heading like the to-be architecture is to what Bernard (2005) says. From this point of view it can be concluded that the statements presented by Sally Bean are supported by other theorists that have worked with the concept of Enterprise Architecture.

Where the artifacts go depends on what the analyst (or in this case the enterprise architect) thinks it is for. This is the views that Sally Bean promotes in her keynote at the first day. According to Sally Bean “the Enterprise Architecture team does not maintain all the content, but provides the framework, structure and governance to ensure that it’s self-consistent and accurate” – slide 23.

Sally Bean presented four different approaches to Enterprise Architecture e.g. horizontal EA, vertical EA, multi-enterprise EA and ‘Whole-enterprise’ EA.

• Horizontal EA that promotes enterprise-wide coherence in a particular domain (process, information and technology). The domain can consist of many other forms of components.
• Vertical EA that deals with approach to large programmes or thematic challenges. In this particular view the business changes and IT systems are vertically coherent across the scope of the programme.
• Multi-enterprise EA deals with organizations try to organize into collaborative clusters e.g. forming common standards for interoperability. Sally Bean did also indicate that the clusters might collaborate in order to achieve common services.
• ‘Whole-enterprise’ EA deals with organizations establish governance policies, and it works as a framework and it deals with artifacts to promote a sort of incremental achievement of horizontal and vertical coherence.

Sally Bean pointed out three forms of complexity e.g. structural complexity, dynamic complexity and human complexity. All of the three forms of complexities that are available in an enterprise will impact the one another.

The living company that is a book dealing with the Shell Oil company. The book deals with the characteristics of long lasting companies. We where encouraged to acquire this book in order to understand how the long lasting enterprises could deal with the problems over time.

Patrick Hoverstadt pointed out that the concept of modeling is rather “freaky” compared to other forms of corporate discipline. Since the financial department, the human resource department or other departments clearly don’t know what or how the model impacts them or what models they make use of in order to do their job.

Sally Bean made use of a quotation that stated “all models are wrong, but some are useful” (Box). I assume that the quotation originates from a book, article or blog post by a person named Box (surname).

From an ontological point of view models aim to represent things in the real world, and from an epistemological models are mental learning devices to explore ideas about the real world. These two claims originates from Checkland.

Sally Bean have met various different stakeholders in various enterprises that in one way or the other thinks that Enterprise Architecture is a project which in many cases could turn out to become a rather dangerous view on how the enterprise can be governed.

Sally Bean: “You really got to fall back on your theory”.

There have been many different perspectives of what Enterprise Architecture is about, as such I feel that Enterprise Architecture is about facilitating the enterprise-wide ontological model.

Cynefin Sense-Making Framework

Deals with how the analyst can deal with the concept of complex systems and find information.
The problem with the simplistic view of the world sees the world as a group of IT and business process management. They usually sees the world as rather simple and they can through their simple models turn the world into something rather chaotic.

You can’t apply a simple process to something that is rather complex, and if there is no process what so ever then it is quite clear that the problem can’t be dealt with in that way. Sally Bean claims that in a complex world it is better to tell people what not to do instead of telling them what to do.

If it becomes too complex (also with IT e.g. with amount of data, features or processes) the system flips over and the systems become too complex to deal with.

Day Two

This is the second day of the summer school on Enterprise Architecture. There where two topics the day. The first one was dealing with the Viable Systems Model (management cybernetics) and the second one was about Enterprise Architecture repositories.

The Viable Systems Model a Keynote by Patrick Hoverstadt

The system is partially based upon a workshop where the different participants works with different approach to organization design. Thereto did Patrick Hoverstadt talk about the “Mosaic” change method.

Patrick Hoverstadt: “Enterprise Architecture is a fairly new discipline and I fairly don’t see any science in it, it is rather pragmatic. It is like IT specification on steroids”.

From a systems point of view Patrick Hoverstadt claims one of the differences between Enterprise Architecture and Systems (in particular the Viable Systems Model) works is that EA focus on “Architecture” of the enterprise where the VSM is about identifying the architecture of the organization.

Enterprise Architecture is a kind of taxonomy framework but it isn’t a good framework in order to deal with complexity.

Gotze had an interesting insight into the particular issue that was discussed. His view on the matter dealt with how the data (artifacts) are usually dealt with in the Enterprise Architecture Program.

John Gotze: “I think it is about being complicated instead of complex”.

Patrick Hoverstadt: “Systems thinking has a long history and a very strong theoretical base, perhaps too strong, we got stuck with academics who controls the theory but can’t practice it. One of the big differences is that it is a relatively simple model for handling complex systems. The models are specifically designed in order to handle complexity. Things that ‘we’ have in common is modeling, and we have the issue of why we have to model organizations”.

Patrick Hoverstadt claims that the ability to manage an organization is about how well we are able to plan it.

With this in mind the idea of systems thinking and cybernetics where discussed. From the discussion the history of cybernetics where discussed, or rather it was discussed in briefly.

Systems thinking has always been a multidisciplinary system and as such it has always tried to embrace different perspectives. One of the things that came out of the “Macey Conferences” lead to the establishment of the concept and paradigm of Cybernetics. The entire foundation for Cybernetics comes from the design principles of anti-aircraft missile guidance systems that introduced the concept of circular feedback systems. It was for the first time that circular logics where introduced.

The introduction of Cybernetics changed the entire world of science due to the feedback and the concept of how feedback is dealt with in the long run.

Pragmatism

The relation to VSM and Enterprise Architecture has to be based on pragmatism. From the pragmatic point of view VSM can enable Enterprise Architects to modeling large complex enterprises quickly.

The integration of information structures to business structures. One of the major issues for IT is that you can take information and separated from what the information was all about. E.g. separated the risk from the asset, and as such people lost sense of what it was. The overall claim of this was stated by Patrick Hoverstadt.

Information should not lose the meaning. Information is about the activities. It is so important and it is a necessity to make track of.

John Gotze pointed out that TOGAF (as in the The Open Group’s Framework for Enterprise Architecture) discusses the issues of capability.

One of the main arguments for this was about Enterprise Architecture is a “meta-strategic” discipline and that information (in theory) design drives decision and as such should architecture drive corporate strategy.

The Conant Law was based on that teams that builds IT systems builds the systems as reflections of themselves so people should be build IT systems that reflects the IT systems.

Patrick Hoverstadt: “It is at least as true that the information system will detect strategy as strategies will detect information systems and as such this should lead to that Enterprise Architecture is a meta-strategic discipline”.

Kune Brodersen: “I hope that isn’t the case due to that would lead to that if we don’t have a strategy then let’s go and look at IT systems in order to understand what we lacks”.

Patrick Hoverstadt: “Unless we design our information systems for the executives to make decisions, they will make short-term decisions, and they will make decisions based on feelings, and in short it will be bad decisions. [….] I would say there is at least a credible argument for that EA is more than just a servant of strategy”.

From there Patrick Hoverstadt went on to discuss five case studies that he has been involved with in order to create sense through the Viable Systems Model. The first case study he talked about he mapped an information system (or systems for the IS-department) to the Viable Systems Model and a result of that was that the IS-department could be consolidated from being a lot of different Information Systems Architecture.

The second case study that Patrick Hoverstadt presented was Stafford Beer’s socio – economic project in Chili (during the Allende period) where he tried to implement the Viable Systems Model on a national scale. Stafford Beer went to Chili to map the socio-economic structure onto a Viable Systems Model and he was able to design a centralized function to cope with data. The project was introduced and implemented in months and it covered most of the big industries of Chili. According to Patrick Hoverstadt the scale was dramatic and it was way too fast.
Patrick Hoverstadt: “It went too fast, I don’t think it would be able to be implemented on that scale with that speed today due to technology has become way too complicated”. As such the technology used in the experiment was rather simply and rather stabile.

From the VSM point of view you would have to find out what is the gap between the need and the current state.

There will be problems if people don’t have access to the right information in order to take decisions on an informed platform. From this particular insight a kind of discussion between Hoverstadt and Gotze took place. Parts of this discussion is presented below.

Patrick Hoverstadt: “If you can rewire a country in six months, you should be able to do things quickly in organizations”.

Another example made that Patrick Hoverstadt presented was that a person in a large British Telecom operator had developed an IT model based upon the VSM model and as such he was able to understand the shape of the enterprise in a matter minutes through life feeds connected directly to the model.

John Gotze: “We have a case in Denmark, the Danish Tax-administration’s first approach to EA developed a hugh repository, but he was really bad communicating, so the decision takers were unaware of it. When they got a new management the architecture team changed they sort of forgot about it”.

Patrick Hoverstadt: “Half the time people don’t know what is happening. Scary isn’t it”.

Questions for the Workshop

1. It is a problem that the decision makers don’t have a suitable overview of the enterprise when they are about to make decisions?
2. If that is a part of the role that EA is playing, where does that leave us all? Is it an advantage? How do you go to the strategists to sell EA?

For the first question: In most enterprises strategy isn’t done well and as such this can lead be optimized. I can only speak on behalf on my own points of view and as such I think it really depends on where you are located in the organization, your personal aura and reputation. Likewise does it depend on the organization and its decision makers. From my point of view the wish for EA has to come from the inside of the enterprise.
Nonetheless the best answer I have for this particular situation would be to do EA instead of selling it. Develop products and show the success-rate of them to the board of directors, and through that show that the success can be coupled directly to the successful project.

For the second question: As I have mentioned earlier. It make no sense to sell Enterprise Architecture, it literally makes no sense since the concept is “intangible”, and the concept is to diversified for any one (even practitioners) to know what is really about. Instead sell the concept as a platform for executing strategic it-based business projects.

“Qualiware” by Kuno Brodersen

Kuno Brodersen is the chief executive officer (CEO) of Qualiware. His contribution to the summer school was how the repositories could be made use of in order to achieve a greater insight of what happens in the enterprise.

Kuno started out with his hypothesis that the Enterprise Architecture Program to some degree can help shape the enterprise’s ontology. The concept of ontology would have to be dealt with through a series of attempts to document the enterprise’s architecture.

Kuno Brodersen: “You as an Enterprise Architect would have to tell the company how to do enterprise ontology”.

Kuno later presented us for the ATP’s approach to an Enterprise Architecture Program that dealt with handling more than a 170 repositories for their entire enterprise.

Kuno Brodersen: “ATP that is located about three miles down the road (pointing in a certain direction) has about 170 repositories for their enterprise architecture e.g. for legacy systems, systems etc.”

Later in the presentation Kuno begain talking about what Gartner Group would recommend in the future, and from that perspective Kuno started to talk about Cloud computing and Enterprise Architecture repositories.

Kuno Brodersen: “Gartner predicts that the top-10 strategic technology areas for 2011 will be 1) cloud computing […...]”.

With this in mind Kuno started to talk about how the customers would like to publish their Enterprise Architecture repositories online e.g. through the cloud in order to share their knowledge with the rest of the enterprise. Furthermore did Kuno identify the problem with searching in large amount of information that for example appears in an Enterprise Architecture related repository.

Kuno Brodersen: “What we see at our customers is that when they wanted to publish their models on enterprise architecture they have found out that text-string search isn’t a good way to identify artifacts. We simply don’t think in text-strings. Instead you can point on e.g. sales assistants as a role or profile you can get the information that you need. If you as an enterprise architect will be able to communicate it way better to the stakeholders in the enterprise by applying a hierarchical model (based on organizational hierarchy) and through the tag structure is in the architecture. You would already have considered that while you designed your Enterprise Architecture model”.

Furthermore did Kuno Brodersen emphasize how important it is to ensure a good user experience, and through that enable the user to find the information that he or she needs in order to find the information that is of importance. Kuno told us that Qualiware has written their own framework that he thinks is more sophisticated than Zachman’s approach to frameworks. He states this in the quotation below.

Kuno Brodersen: “Here we got the Qualiware enterprise architecture framework, well we also have one, we found out that anyone out there had one so we developed one ourself. See the fantastic icons? Why don’t any one apply the Zachman framework? Because it is so ugly! If you present this to c-level executives you will get a different answer each and every time. There are entirely different perspective you will have depending on who you ask. Do we want to have a high level business process in your company? Why is the process there and what do you need to execute this process? Do we want to know who is responsible for this process then you would have to capture that relationship, and when you do so, you would have to adapt your mental model. It might differ overtime.”

Later Kuno presented his ideas on “gamification” of the Enterprise Architecture repository in order to analyze who in the enterprise, or might not make use of the EA repository and to engage the various stakeholders. As such it seems like an interesting idea, but it would have to be implemented in an enterprise with the right culture, where the various stakeholders thinks that they have the surplus of time to “play the game” in order to gain a better understanding of how the enterprise works.

Kuno Brodersen: “It makes the managers able to set up a treasure hunt in order to make the various stakeholders smarter on what is going on in the enterprise”.

Furthermore did Kuno point of which particular approach to documentation of the enterprise’s architecture, that he felt would accelerate the Enterprise Architecture Program.

Kuno Brodersen:” Start the process will identifying key meta-model components. [….] then you should develop a little EA framework for each of the different stakeholders. Then find out the cost drivers for each of the changes identified and then be aware of your sources and check your data. Then you have to figure out how to present/communicate your findings to the management”.

Day Three

Today we celebrate the garden of pure ideology, or rather that Chris Potts presented his views on the market driven approach to Enterprise Architecture. The concept of working with several different approaches to enterprise architecture and its access to the market.

Enterprise Architecture and Business Ecology by Chris D. Potts

Some of the content that has been presented before at other keynotes, but this time it is in another context. Chris started the keynote by presenting himself as a corporate strategist that has adapted some of the concepts of Enterprise Architecture in order to develop better plans and change the organizations according to the plans.

Chris D. Potts: “I am a corporate strategist, and not truly an Enterprise Architect. [….] and the subtitle was how IT consumerise everything. [...] Enterprise Architecture is about 25 years old next year due to the first time John Zachman thought of it. In other words the concept of Enterprise Architecture is a rather young discipline”.

During the presentation Chris presented some interesting views on how the enterprise’s architecture is connected to many different sub systems and how these systems should be focused on what happens outside the enterprise in order to create value. From this perspective he started to talk about ecosystems, which is a classical discipline within the school of management cybernetics.

Chris D. Potts: “Ecosystems are about organisms and how they interact with the world. In a sense the markets are also ecosystems where we, the organisms, interact with one another. Many people want to create an abstract thing instead of saying what it is about (the ecosystem)”.

Furthermore did Chris talk about how businesses that deal with their ecosystems would be able to compete on better terms (by creating some sort of advantages) than businesses that didn’t. The ecosystems are according to Chris the Alpha and Omega.

Chris D. Potts: “Businesses that looks on what happens in the ecosystems will do better every time, compared to the businesses that neglects their ecosystems”.

One of the major changes in the ecosystems of which enterprises operate is that the consumers have taken the lead on using information technology. Back in the day where Chris D. Potts worked with hospital services (around 1987) the focus was on big Enterprise IT-oriented Systems where the consumers perhaps had a personal computer that was able to deal with word-processing and spreadsheets.

Chris D. Potts introduced four different concepts based on individual words e.g. Business, Ecology, Enterprise and Architecture each of the words have different meanings and can be dealt with in order to gain an understanding of how the various elements of Enterprise Architecture and business ecology is all about.

Thereto did Chris Potts introduce ideas on how to deal with the concept of the enterprise. The concept of the enterprise is up for evaluation and all of a sudden Mr. Potts brought up the Sydney Opera House into consideration.

Business ecosystems or what Chris D. Potts argues is the market ecosystems should be considered an overall framework for which the enterprise and its architecture system.

From this perspective the “market architecture” as Chris D. Potts named it deals with the concept by approaching the concept of customer experience.

Likewise are there three minor architectures that Chris D. Potts believe have to be addressed e.g. the technologies architecture, the knowledge architecture and the processes architecture that all have to be connected to the business architecture.

The development of the technologies and the economics by outsourcing the processes to other countries have triggered the development of the virtual enterprise. The virtual enterprise ensures that the boundaries of the enterprise goes beyond the the “old” conceptual model of the enterprise into the value chain and supply chain of the enterprise. In this particular case I consider the concept of value chain as a concept dealing with how the enterprise value where the concept of the supply chain management is build upon the concept of get resources to produce a particular product (physical) or service. Due to the virtual enterprise the concept of Enterprise Architecture would eventually evolve into the extended Enterprise Architecture (which might be in a conflict with EA) or Enterprise Chain Architecture.

Chris D. Potts: “Nonetheless buildings can’t be changed but buildings are not enterprises”.

The above mentioned quote can act as an indicator for that Chris D. Potts has reached a level of understanding of Enterprise Architecture that is equal to the ideas that Herzum presented in his paper for about eight years ago. From this point of view the enterprise can’t be changed in the instant of a second or for that matter a week or a month. The idea on how to deal with rewiring the organization.

This pretty much concluded the keynote for today and we went on with a presentation by Patrick Hoverstadt.

Some Core Systems Ideas by Patrick Hoverstadt

Systems Methodology is one of the origins of the stuff that was presented during this presentation. The relevance to Enterprise Architecture is on some points a bit blurred but it should according to Patrick Hoverstadt this presentation organization design might benefit from it.

Patrick Hoverstadt: “I believe that there is a future for tactical Enterprise Architecture”.

Patrick Hoverstadt: “Yes, you can design a system for a sound purpose.[...] if you have different identity from being inside the organization compared to you being outside the organization. It is true that there is a linear purpose from designing to executing, but there is a part of it that is also non-linear.”

Patrick Hoverstadt concluded that the models that we apply have to be lesser detailed (simpler) than those things the models are supposed to model. In our terminology when you are building model you are modeling a system that you have studied a particular behavior of human beings.

What Patrick Hoverstadt concluded was that systems have:

• It is separated from its environment by a boundary.
• Studying particular behavior implies a boundary.
• Choosing a boundary implies studying particular behavior.

A model that is not valid is an illusion (based on the assumptions that Patrick Hoverstadt brought with his presentation).

When choosing (assuming that the person are aware of other models) a mental model the person isn’t able to alter his or her behavior except choosing another model and as such the focus would be (in many cases) changing their simplified way to view the world.

From this view a kind of debate between Patrick Hoverstadt and John Gotze erupted.

John Gotze: “It is not the model, it is the learning, the understanding and perhaps even the systems to get some points at the course”.

Patrick Hoverstadt: “From the modeling point of view it is great? Through the process of modeling you discovered where you are with EA? There is no feedback without learning and no learning with out feedback”. – Enterprise Architecture Summer School (Week 31 in Hilsinge 2011).

Assumptions are limiting your thinking and as such these assumptions would have to be dealt with in order to understand the world you are observing. Meta-models would have to deal with the assumptions you make and how to break them down. In other words you would have to challenge your assumptions.

Patrick Hoverstadt: “Xerox where about to go bankrupt, so they hired a management consultancy to come with some ideas on what to do, and they came up with producing photocopiers, since if it failed they (Xerox) would be out of business anyway”.

In management terms, information is the way to challenge management models. You would have to test your theory through challenging your views. You would have to design feedback loops in order to ensure data on how to improve your models.

Patrick Hoverstadt: “Measures usually becomes substitute for realities”.

While developing models you should try to filter out the noise in order to get a better model for the particular situation. Noise is an accuracy killer.

You have to start an entirely new procedure based on incidents, but you would have to ensure that you got the proper data to ensure you can add value to changing your models.

Make decisions based on information, don’t collect information based on decisions. What I mean is that you shouldn’t conclude what should be done except if you got the information to justify your decision to begin with.

Understanding diversity is driven by understanding the boundaries of the system. The creativity comes from diversity. There are evolutionary advantages to diversity according to Patrick Hoverstadt.

John Gotze: “The more successful companies have a diversity strategy, diversity on gender, ethnicity, education etc”.

Patrick Hoverstadt: “A hundred years ago this year, Taylor published Scientific Management, and we still live with that, so there is a whole lot of management theory, and budgets was introduced with McKinsey & Co in the 1920s. Linear determinism is rarely happening in a management cybernetics context, you rarely steer a ship in a linear (direct) approach. No one thinks that their behavior is being controlled by the system and yet it is. In the VSM the circles are production or activities and boxes are management”.

From this the idea was identified with the concept of Ashby’s Law was introduced.

Ashby’s Law

Deals with the law of requisite variety. Variety is used as a method fore measure complexity since it deals with the number of possible states of a system. Only variety can absorb variety.

The VSM Model and Designing Systems

The VSM is an exceptional design tool. But the tooling around the real stuff is rather “alternative”. I don’t have a real tool to model how the complexities. It is a tool problem but also a conceptualization problem.

Structural coupling is the core of evolution. Competition isn’t the driver, the process but the acting.

VSM is exactly a system that can be used in order to gain an understanding of that environment. According to Hoverstadt that the VSM is a model of a system capable of structural coupling.

This ended the keynote on Viable Systems Models and Kristian Hjort-Madsen took over with his presentation on the usage of frameworks and their usefulness for dealing with enterprises.

Frameworks Versus Institution by Kristian Hjort-Madsen

Due to the demand for development and evolution Accenture is heavily involved in Enterprise IT Architectures. Accenture engaging the various clients on Enterprise Architecture. Throughout his Ph.D. Dr. Kristian Hjort-Madsen, Ph.D. criticized the various frameworks available on the market. Through his career as a Ph.D. And in the public sector like the ministry of Finance he has had a rather linear approach to strategy development and strategy execution.

A lot of the work that Dr. Kristian Hjort-Madsen, Ph.D. is working with seems to deal with IT strategy tasks but in reality it is the work with Enterprise Architecture, at least that is what I assumed he really worked with while he explained what he does as senior consultant in Accenture.

Accenture operates with reference models that are compatible with many, if not most, of the industries that the consultancy operates in. In this particular light it seems like Accenture is rather content with applying generic frameworks (at first) and adapting them to the particular enterprise’s situation. Dr. Hjort-Madsen was of the opinion that this particular approach to deal with things were rather useful in order to “sell” the projects to the decision-makers in the enterprise.

While working with various different problems that enterprises out in the industry that Accenture sells their services to, they develops differebt industry reference frameworks. They will through these frameworks, they accelerate the development of solutions for the particular enterprises that they assists with solving particular tasks.

We went into the enterprise to the enterprise and worked out an ideal model for how Enterprise Architecture governance for the organization. From this particular view there where parts that was handled by

Dr. Kristian Hjort-Madsen, Ph.D.: “After I worked with this client, I ended up with questioning my conclusions in my Ph.D. where I used a lot of effort for concluding that frameworks don’t work. [….] but I think that a lot of people who applies a framework off-the-shelves will fail in the implementation phase.”

Dr. Kristian Hjort-Madsen, Ph.D.: “The understanding of systems-thinking is really important, and then I think, I don’t know how much you have been talking about power, but there is power all over the place and you really have to understanding. You don’t have to read all the works by Foucault.”

Dr. Kristian Hjort-Madsen, Ph.D.: “We focus on speed, ROI, decreased risks, proof of concept and acceleration of projects”.

I tend to agree with Dr. Hjort-Madsen, it makes no sense to develop frameworks for the sake of developing them, but they tend to be able to dictate which direction seems to be the most relevant in the beginning of the Enterprise Architecture Program’s lifetime.

Day Four

This day had a rather commercial approach to Enterprise Architecture. The PFA, DHL Express and Dong Energy did presentations on how to deal with their Enterprise Architectures.

PFA

Is about to mature through its foundation architecture. Due to the nature of the presentation I was rather involved in the generation of questions, and I therefore invested my attention in this particular aspect of the session. It is in its foundation phase due to it seems like the architecture program is still rather IT-centric. The IT-centric approach to Enterprise Architecture is rather useful in enterprises that are rather IT-dependent.

The PFA had an interesting approach to Enterprise Architecture. The person in charge of the department for Architecture and Method is named Soeren Staun Biangslev (SSB) who happens to be both the CTO and the chief architect. The PFA makes use of the MOOD modeling application in order to document the higher prioritized artifacts of their approach to Enterprise Architecture Framework.

The framework was (as I can recall) based on elements of TOGAF and as such the focus had been on proving to be valuable, and ensuring that projects have been implemented on time and in the best way possible. This was according to SSB some of the primary drivers of the Enterprise Architecture Program that the PFA had initiated. It was on the other hand rather important to point out how value could be created for the various stakeholders of the enterprise.

It seemed like the PFA had its grabs on Enterprise Architecture, but the enterprise would have to deal with many different perspectives on how to evolve the program to go beyond the enterprise’s social systems.

Keywords from the presentation

• Value.
• Speed.
• Overview.
• Adaption.
• Information Technology.

My Observations Based on the Enterprise Architecture

In my humble opinion the PFA could benefit from using their Enterprise Architecture Program as a way to challenge the mental models of the various decision-makers and the ordinary employee who would have to deal with the problems at hand in the operations of the enterprise. This could enable unseen synergies.

After this particular presentation the representative from DHL Express began with his approach to Enterprise Architecture.

DHL Express

Adrian Apthorp did a presentation on how DHL Express handles its Enterprise Architecture. Express is the original organization back in the 1950s.

The enterprise has about 100.000 employees and as such 250 dedicated aircrafts. The enterprise has three international hubs for cargo. Leipzig is the biggest of the three, secondly is the Hong Kong and Cincinnati.

The enterprise has two IT centers one in Malaysia and one in the Czech Republic.

What the DHL Express is focusing on is to deal with the focus of capabilities that can be build upon the Enterprise Architecture Program. Somehow I got the feeling that the DHL Express has an architecture that is

Adrian Apthorp has been focusing on adopting Enterprise Architecture as a management discipline e.g. what is the role of the Enterprise Architect. Likewise did he commit some attention to what essential “building blocks” of EA is to the enterprise.

AA: “Ivory towers gives architecture a bad name.”

AA: “The role of policeman doesn’t go well. […] You will not become a popular man.”

The DHL has been able to apply its Enterprise Architecture Program in e.g. moving its European headquarters from Belgium to Germany (Bonn).

AA compared enterprise architecture to city-planning. John Gotze introduced the Pat Helland and the blog post / paper “Metropolis”. In his opinion the blog could be used for generating interesting ideas.

After this particular presentation the focus changed to a crash-course-kind-of-presentation by Jan Staack who is the chief architect for Enterprise Architecture from Dong Energy.

Dong Energy’s Approach to Enterprise Architecture by Jan Staack

Enterprise Architecture is shaping capability through architecture planning program, strategy and planning, enterprise architecture and programme management. Besides that Mr. Staack introduced a reference model from TOGAF on what skills Enterprise Architects and other architects profile can be classified as.

The presentation concluded the ending of the summer school at the hotel located at the Northern part of the larger Copenhagen district. The last day (day five) took place at the IT University of Copenhagen.

Day Five

This day was build upon a workshop the IT University of Copenhagen. It was designed as a workshop where the representative from the DHL Express was the facilitator.

Discussion

The workshop was rather discussion based and as such the focus of what was to be included in the Enterprise Architecture Program. What is “in the EA program” is about what could clearly be included in the program.

In the EA Program

1. The enterprise architecture program should include standards, processes and facilitating knowledge sharing in the organization in order to ensure the integration of the verified data.
2. Legal council e.g. enforcing (convincing) other parts of the enterprise architecture program to adapt to the commonly agreed standards.
3. Planning input – department. Which is according to AA where the dynamic role of the enterprise comes in. The architect would hopefully say or think about adding value through knowing how the various processes, technologies etc. that should be put into play.
4. Owning the reference architecture.

Out of the EA Program

1. Project Manager role shouldn’t be a part of the Enterprise Architecture Program.
2. Not the implementor.
3. IT support.
4. Taking in too much, too many tasks, and too many tasks that have been IT-related.
5. IT-operations.

The Building Blocks of the Enterprise Architecture

The focus of the Enterprise Architecture Program was some of the building blocks dealing with the concept of enterprise’s architecture. Likewise are there two different perspectives on EA.

In the EA Program

1. Patterns.
2. “Networks” that means value through networks.
3. You would have to understand the business operating model.
4. Supporting, helping and finding strategic dynamics. At times this would lead to some degree of policing.
5. The information used in the business is naturally a part of the Enterprise Architecture Program.

Out of the EA Program

1. Defining business objectives.

2. Not-detailed designing.

3. Not all change management.

The Role in Enterprise Management

There are several different forms of management disciplines and tools that should be connected and dealt with in the Enterprise Architecture Program.

Steer

1. Balanced Scorecard, there has to be a connection, e.g. through resources.
2. Governance structure.
3. Standards, plans and principles are a part of the steering approach to Enterprise Architecture.

Operate

1. Chart of accountants.
2. ABC (Activity Based Costing) models are located located.
3. Indoctrination and training to the organization’s structure.

The meta-model is combination of steering and operations, and the meta-model is according to AA an enabler of change. AA named this change models.

Change Through Enterprise Architecture

AA had a small presentation on how to deal with change management and Enterprise Architecture.

1. Identify the business objectives and ensure the dependencies and break them down into projects e.g. through a GANTT-chart.
2. Map business capabilities and organize them within the GANTT-chart.
3. This is the dependencies, capabilities and the business objectives have been assigned and allocated to specific projects and through that layout the strategy.

Conclusion

Through this particular summer school it became rather clear that the situation for dealing with the enterprise has to be build upon an idea that the architects would have to be pragmatic. On the other hand it seems that there is no reason for not going beyond the classical assumptions of what is realistic, and it seems like a lot of the potential of Enterprise Architecture is really about challenging the mental models (or models in general) that the enterprise’s decision-makers believe in.

The question of fait is really a necessity to deal with in the long run since it seems like a lot of different people (regardless of their profiles and personas) seems like they talk of applying systems, but they tend not to act upon the systems.

Systems are on the other hand dictating behavior of the various profiles in the enterprise, if the systems are implemented correctly. Furthermore does it seem like Enterprise Architecture deals with cultivating complex systems in order to re-enforce the enterprises ability to operationalize their capabilities. One of the major trends among the commercial actors at the summer school was that they had worked a lot on capability maps. My hypothesis on the matter is that the various Enterprise Architects makes use of the capability maps to inform the decision-makers on what they “realistically” can do with the enterprise.

The last day at the summer school convinced me that one of the punch lines I learned at the Copenhagen Business School appears to represent the truth. The punchline goes: “without accountability it is doomed to fail”. If the enterprise architects don’t have control over the design of incentives and organizational change, and they aren’t held accountable for the changes it would seem like organizational design is not part of the Enterprise Architecture Program.

Enterprise Architecture is about exploring, probing, and challenging the models the various decision-makers and other personas have and it is about developing realistic plans and change approaches. Enterprise Architecture as a concept has a great potential for change the enterprise for the better, but it has to go beyond the classical boundaries of what is considered the norm of an Enterprise Architecture Program.

Download the paper here.

The Model

The model is segmented into three different levels and three different categories. The first (vertical) category deals with information and how information is used. The second (vertical) category deals with strategy (you shouldn’t articulate a strategy that isn’t based on information). The third category (vertical) is about innovation since strategy is often about doing new things and do them well in order to move the enterprise.

The categories that are horizontal deals with different perspectives and as such as economy, organization and technology. There are some “blank” spaces in between the three horizontal categories and as such these should be seen as in the spectra of the three perspectives.

The various authors that I have organized in the model have been mentioned under the Harvard source notation standard e.g. Beer (1994).

The model is essentially constructed upon the same principles as Leavitt’s model for organizational and technological alignment which means that I can only recommend the reader to read books with-in all of the perspectives in order to gain a holistic understanding of what Enterprise Architecture is all about. The model is of course a simplification of the reality.

Feel free to contact me if you feel that other books should be added to the model. You can contact me by comment this blog post or using the contact form.

Bibliography

Anderson, R.J., 2008. Security Engineering: A Guide to Building Dependable Distributed Systems 2nd ed., Wiley.

Andrew, J.P. & Sirkin, H.L., 2007. Payback: Reaping the Rewards of Innovation 1st ed., Harvard Business School Press.

Atkinson, A.A. et al., 2007. Management Accounting 5th (2007) ed., Upper Saddle River: Pearson Education.

Baldwin, E.C., M, 2007. Managing IT Innovation for Business Value: Practical Strategies for IT & Business Managers: Practical Strategies for IT and Business Managers, INTEL PRESS.

Beer, S., 1994a. Brain of the Firm 2nd ed., John Wiley & Sons.

Beer, S., 1994b. The Heart of Enterprise New edition., John Wiley & Sons.

Bernard, S., A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.

Broadbent, M. & Kitzis, E., 2004. The New CIO Leader: Setting the Agenda and Delivering Results, Harvard Business School Press.
Brynjolfsson, E. & Saunders, A., 2009. Wired for Innovation: How Information Technology Is Reshaping the Economy, MIT Press.
Ciborra, C., 2004. The Labyrinths of Information: Challenging the Wisdom of Systems, OUP Oxford.
Dietz, J.L.G., 2006. Enterprise Ontology: Theory and Methodology, Springer.
Doucet, G. et al., 2009. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, International Enterprise Architecture Institute.

Finkelstein, S., Harvey, C. & Lawton, T., 2006. Breakout Strategy: Meeting the Challenge of Double-Digit Growth, McGraw-Hill Professional.

Graves, T., 2008. Real Enterprise Architecture: Beyond IT to the Whole Enterprise, Tetradian Books.

Hoogervorst, J.A.P., 2009. Enterprise Governance and Enterprise Engineering, Springer.

Hoverstadt, P., 2008. Fractal Organization: Creating Sustainable Organizations with the Viable System Model, John Wiley & Sons.

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

Kaplan, R.S. & Norton, D.P., 2006. Alignment: How to Apply the Balanced Scorecard to Corporate Strategy illustrated edition., Harvard Business School Press.

Kaplan, R.S. & Norton, D.P., 2008. Execution Premium. Linking Strategy to Operations for Competitive Advantage, Harvard Business School Press.

Kaplan, R. & Atkinson, A.A., 1998. Advanced Management Accounting 3rd ed., Pearson Education.

Krafzig, D., Banke, K. & Slama, D., 2004. Enterprise SOA: Service Oriented Architecture Best Practices 1st ed., Prentice Hall.

Mintzberg, H., Ahlstrand, P.B. & Lampel, J.B., 2008. Strategy Safari: The Complete Guide Through the Wilds of Strategic Management 2nd ed., Financial Times/ Prentice Hall.

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

Potts, C., 2010. RecrEAtion: Realizing the Extraordinary Contribution of Your Enterprise Architects, Technics Publications, LLC.

Prahalad, C.K. & Krishnan, M.S., 2008. The New Age of Innovation: Driving Cocreated Value Through Global Networks, McGraw-Hill Professional.
Rogers, E.M., 2003. Diffusion of Innovations 5th ed., Simon & Schuster International.

Ross, J.W., Weill, P. & Robertson, D.C., 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution illustrated edition., Harvard Business School Press.

Stamp, M., 2005. Information Security: Principles and Practice, WileyBlackwell.

Skarzynski, P. & Gibson, R., 2008. Innovation to the Core: A Blueprint for Transforming the Way Your Company Innovates illustrated edition., Harvard Business School Press.

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

Watkins, M.D., 2003. The First 90 Days: Critical Success Strategies for New Leaders at All Levels First Edition., Harvard Business School Press.

Weill, P. & Ross, J., 2009. IT Savvy: What Top Executives Must Know to Go from Pain to Gain, Harvard Business School Press.

Weill, P. & Ross, J.W., 2004. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press.

Weick, K.E., 2000. Making Sense of the Organization, WileyBlackwell.

Weick, K.E. & Sutcliffe, K.M., 2007. Managing the Unexpected: Resilient Performance in an Age of Uncertainty 2nd ed., Jossey Bass.

Woods, D. & Mattern, T., 2006. Enterprise SOA: Designing IT for Business Innovation 2nd ed., Sebastopol: O’Reilly Media, Inc.

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).

This blog post deals with innovation in regards to the Enterprise Architecture program. I’ve been able to identify two different approaches to innovation. The first approach to innovation is what I define as incremental innovation. The second approach to innovation is radical innovation. In most cases incremental innovation is innovation in social systems where small improvements have been introduced to the social systems.

Likewise is radical innovations forms of innovations that fundamentally changes the social systems e.g. how they work or how they interact with one another.

Likewise is the concept of innovation extremely context dependable. For one social system a particular approach could be considered an innovation where the same concept could be considered old news. Innovation, could as before mentioned, be incremental saying that a new way to deal with the piece of technology or business activity. Likewise could the same situation be radical if the technology never had been used before.

When it comes to innovation and applying it in the context of the enterprise the question of adaption would have to be dealt with.

Adaption

Rogers speaks of how the innovations spreads to the various organizations, parts of the organizations and people. In this process there are five stages before the people of the enterprise would be able to fully apply any given form of innovation.

Innovation defused by that people observer other people who have success by applying the particular innovation in order to solve problems or to certain things in a new way that benefits them and their social structures.

Social systems shares a culture that is shared among the individuals who interact with the social systems. The purpose of the culture is to give the members of the enterprise a sense of security against the ever changing environment that the members of the enterprise is situated in. Culture is usually against changes and thereby against innovations. However there are also cases that suggests that culture can be used to enable the enterprise with innovation if the executives and middle management gives the employes the proper amount of trust.

In other words Enterprise Architecture has to be adapted to the enterprise that is about to invest in the program and as such the Enterprise Architecture program can be seen as an incremental innovation and a radical innovation depending on how the decision makers and the stakeholders sees the implementation process.

Innovation and EA

In regards to enterprise innovation the focus of Enterprise Architecture would be to deal with the processes in the enterprise. For enterprises the idea of incremental innovation would be dealing with the processes in small steps while radical innovations would be innovations that are “game changing” for the enterprise. In this particular light it is a necessity to see Enterprise Architecture as a form of continuous innovation for the enterprise and as such a container for future innovations and as such can the Enterprise Architecture program become a barrier for the innovativeness of the enterprise.

It easily become a fine act of balancing between the rules, standards and principles and the necessity to crystalize solutions for the various unplanned situations that the enterprise experience. Ciborra named this the concept of bricolage (or organizational hacking). In order to facilitate bricolage it is a necessity for the decision takers to empower the employees of the enterprise by allocating power and accountability to the middle managers or the employees. As such this should give the enterprise the necessary platform in order to make bricolage works.

Innovation in this context could be facilitated by the various stakeholders of the enterprise and through the Enterprise Architecture program the concept of innovation could empower the alignment and the agility of the enterprise.

Enterprise Architecture

So what is Enterprise Architecture all about? I’ve chosen to define Enterprise Architecture as a program that deals with the various projects that the enterprise works with in order to change its architecture. However this can not serve as a definition since it doesn’t include some of the most important elements of Enterprise Architecture. Enterprise Architecture as a concept includes an element of documentation of the current architecture of the enterprise (known as the AS – IS situation) and an element that deals with how the future architecture of the enterprise should be like (the To – Be situation). Different communities of practice within the ecosystem of Enterprise Architecture practitioners sees the concept of Enterprise Architecture differently e.g. some sees Enterprise Architecture as a set of processes that constantly ensures some alignment through the implementation of processes and others who sees Enterprise Architecture as a form of blueprinting that ensures that the enterprise develops in to a coherent entity. There are most likely different views of what Enterprise Architecture is all about in the various communities in the ecosystem, and it is almost certain that each book that have been published on Enterprise Architecture works with its own definition of the concept.

My definition of Enterprise Architecture is in this context that Enterprise Architecture (as a concept) consists of a program for documentation of the enterprise’s architecture, a program for identification, specification and development of projects that enable the enterprise to achieve its goals. Likewise does the concept of Enterprise Architecture include the development of standards and principles that are used to govern the enterprise on all levels. When this is said the last component that add to the definition of what Enterprise Architecture is all about is the concept of enterprise governance.

Enterprise governance has to ensure that the enterprise achieves its goals and the goals can only be achieved if there is some kind of innovation in the enterprise. Innovation should in this context be understood as an ability to alter the various parameters of the enterprise.

The Synthesis

I’ve with some inspiration from Leavitt (1965) and his diamond model defined my own model that shows what Enterprise Architecture is all about. Enterprise Architecture is the platform for how the organization executes the business objectives, business processes and technology services. As such the holistic approach to deal with the elements of tasks, business objectives and technology services will have an impact on what kind of employees that would be needed in order to ensure that the enterprise can produce products and services to its customers. Each of the elements impacts the other elements and as such the decision makers (executives, middle managers, team leaders or anarchies) have to deal with the problems through the Enterprise Architecture platform and program.

People are the key when it comes to the breakdown of the classical barriers in the organizational hierarchy and as such it becomes a necessity to deal with people in order to achieve a better and more mature enterprise architecture. It becomes a necessity to deal with the focus of who the enterprise have access to and how the various stakeholders of the enterprise can add to the innovativeness of the enterprise.

While the enterprise adds value through producing products and services to its customers. The various stakeholders in the enterprise do some kind of bricolage or organizational hacking. The concept of organizational hacking can’t be dealt with in any other way and as such most of this “hacking” helps the organization deal with the everyday crisis and as such the Enterprise Architecture program (principles, standards and security) has to take this into consideration and find the balance between hacking and standardization.

While implementing an Enterprise Architecture program the decision makers would have to ensure that incremental innovation isn’t neglected or for that matter locked due to the approach to standards and principles. Likewise should the decision makers work with the concept of bricolage in their assumptions of planning, and as such they should embrace that two, three or five year plans can’t lead to competitive advantages.

The day was characterized as a setup that was dominated by companies and industry professionals who presented topics of a wide variety of topics.

A Next-Generation EA Approach to Modeling the Firm using Capability Sets

John Gotze has in cooperation with Pat Turner written a paper on how to use capability sets in order to make Enterprise Architecture to work, how to sell Enterprise Architecture and what the value of Enterprise Architecture is all about.

The primary problem that the paper is about to answer is what capabilities the enterprise can get and how it can enhance it through shared capabilities.

John Gotze emphasized that one of the problems with the model that Ross and Weill (2006) proposed for Enterprise Architecture is based on that they don’t give a clue on what is their platform for execution and what is a part of the foundation platform.

John Gotze defines a capability as “an Ability or Expertise upon which that the Enterprise relies to fulfill its core functions”. Likewise does Gotze and Turner define an enterprise capability as “A capability that pervades across the whole of the enterprise”.

According to John Gotze, one organization that applies enterprise capabilities, is the U.S. Army. An example could be the tagline “one army”. With this in mind John Gotze made a reference to David A. Clark’s book on world poverty that deals with how to ensure capabilities among other things.

John Gotze later said that a capability set is directly coupled to the execution of the various processes. The second case that John Gotze presented was the Australian Customs and Border Protection Service. The agency should have one of the biggest Enterprise Architecture programs that John Gotze has ever seen and as such they have articulated a five year plan and roadmaps on how to achieve a better architecture.

In order to achieve enterprise capabilities for the enterprise John Gotze and Pat Turner has developed a rather comprehensive framework in order to achieve a better enterprise.

• A big part of the value of enterprise architecture program can be traced to the capabilities that the program can aid the enterprise with.
• The paper investigates case studies on how Enterprise Architecture could generate “enterprise capabilities”.
• An academic investigation of Enterprise Architecture is all about and how “competitive advantages” can be achieved through the implementation of a Enterprise Architecture program.

Vestas Wind Systems – Windy Architectures

The keynote speaker is Troels Fleckenstein who is Vice President at Vestas Wind Systems.

According to the keynote speaker all windmills from Vestas are equipped with technology that enable the windmills to communicate through the Internet with Vestas. Each of the Windmills communicate with Vestas 512 times yearly. This has created a large quantity of data that the corporation has to deal with in order to ensure maintenance of the windmills. Vestas hasn’t an Enterprise Architecture program, or at least that is what the speaker from Vestas said.

The keynote included a video on what Vestas is all about and Ditlev Engel appeared. Apparently Vestas has a slogan that they apply internally that is known as “people before megawatt” that as such means that Vestas doesn’t have HR-department but a department for people and culture (which I presume is pretty much the same). Vestas’ strategy is based upon that they believe they should be number one in wind energy. As such Vestas claims that 1/3 of all windmills sold on a global scale is produced by Vestas.

For Vestas the People’s Republic of China and the Republic of India represents the key markets due to the development of the various enterprises. Most likely are other countries in the BRIC group also of interest to Vestas Wind Systems.

Vestas has 15 locations around the world that develops on new products. Vestas produce nacelles in 15 locations, blades in 7 locations and towers in 2 locations and as such Vestas is able to deliver “Wind Power Plants” in eight regions of the world, or at least that is what the keynote speaker proclaimed.

Vestas’ current strategy is named the triple 15. The current corporate strategy goes to 2015 and they want to achieve a yearly revenue on 15% (currently it is 8.5%) and an EBIT (Earnings before interest and taxes) on 15%.

The keynote speaker presented the Vestas business model as titled it the strategy for empower the corporate strategy. With this approach in mind I am sure that Vestas applies an idea that is compatible with “Cybernetics paradigm”. Furthermore Vestas applies an approach they have titled “The Vestas’ High Five” that entails that energy should be competitive, predictable, independent, fast and clean. According to the keynote speaker the most important partners for Vestas are their customers. In other words Vestas would like to own the means of production of “wind energy” and thereby be able to set the price(s) for producing Windmills.

Vestas’ enterprise architecture team is located within the department for strategy and innovation and this is located in Vestas’ group IT. Apparently Vestas apply a model that includes four perspectives: 1) Innovation, 2) Roadmap, 3) Projects and last but not least 4) System Portfolio.

The Vestas’ Enterprise Architecture program is about “business and value adding activities”, or that is the opinion of the keynote speaker.

When working with enterprise architecture the keynote speaker presented the Vestas’ value management square, that most of all looks like a strategy map or balanced scorecard as Kaplan and Norton would define it.

“The way I see, we add value to the business is to have insight into what systems that the business would need” – Troels Fleckenstein (Week 22, 2011).

Vestas applies a framework that is known as the BSG-model in architecture. BSG stands for Business Service Group that is a sheet of paper detailing how the enterprise works. The documents details how the processes works in the enterprise. The BSGs are linked to the various enterprises processes in Vestas and as such the enterprise architects are working with modeling the architecture a long side the BSGs.

Besides the enterprise architects Vestas applies the title “domain architects” for individuals who have a specific knowledge on how the enterprise applies.

Vestas have made use of IBM, Accenture and other consultancies in order to develop their framework. In other words Vestas Wind Systems have developed a synthesis that hey apply in order to enable the systems.

According to the keynote speaker there aren’t any off-the-shelves process frameworks that Vestas was able to make use of.

“We are not such a box” – Troels Fleckenstein (Week 22, 2011).

Vestas applies Aris as a tool for modeling, but the keynote speaker has a rather controversial view on how the tool works which is represented in the quotation below:

“When speaking of Aris it is quite clear it has been developed by German engineers. It is not made for white people” – Troels Fleckenstein (Week 22, 2011).

Vestas’ IT fundamentals deals with providing fast prototyping, innovation lab, enabling agility, “show me – do it”, safeguard end-to-end transparency of business processes, partnering with the business and providing enterprise architecture to guarantee reliability.

It seems like the approach to Enterprise Architecture that Vestas makes use of, is dealing with communication on how the enterprise can deal with the problems and how the enterprise is able to deal with the problem.

When it comes to the focus on governance and advice Vestas have applied boards for processes, BPS community, Vestas Government and SteerCo where a representative from Group IT (and thereby a representative for the Enterprise Architecture group) is represented. The boards usually handles investments, strategy and innovation, program and projects. One of the many interesting things that Vestas works with in their Enterprise Architecture program is “the line of sight”.

“I’m not a particular big fan of frameworks since they tend to distract us from the communication side of EA and the value adding part of EA” – Troels Fleckenstein (Week 22, 2011).

While educating the enterprise architects Vestas applies an approach where they send their architects to Gartner summits and certification modules. However they haven’t made use of TOGAF or other approaches to Enterprise Architecture.

When Vestas works with IT forecasts they usually take in consultants from Gartner and other consultancies to give the various stakeholders in Group IT ideas on what kind of IT the enterprise should invest in.

Obviously Vestas experiences situations of when and where to break away from their own Enterprise Architecture standards. The way the keynote speaker presented the issue it seemed like that it is based on “intuition” and what the “business” defines as a necessity to cope with. The keynote speaker used an example from the implementation of the windmills and how the various committees dealt with the particular problem.

• Vestas’ is a rather complex enterprise that have developed its own framework to deal with its architecture.
• The Enterprise Architecture program is owned by the IT department, or at least it appeared that way while the VP presented the situation.
• The IT and EA agents are represented in various investment and governance boards in Vestas Wind Systems.

Qualiware Enabling Positive Change

The CEO of Qualiware, Kuno Brodersen, acted as keynote speaker on knowledge management and modeling.

The keynote speaker was of the opinion that the modeling of the change processes is a vital key to success, since the model can help the decision makers and individuals in the enterprise to focus on particular areas of attention.

The keynote speaker was of the opinion that many modern enterprises shares the same view on how the management model. In Denmark most enterprises agrees upon that the Scandinavian management model is the best way to achieve.

A fundamental part of the Scandinavian management model. According to Kuno Brodersen, social capital is what enterprises gains when the social systems solves problems.

There are several factors that impacts the concept of social capital e.g. the individual factors, job factors, group factors, company factors.

In reality these factors have to be included when you measure enterprises and their ability to deal go beyond the expected approach to achieve their individual goals.

“The point of modeling tools is that knowledge from the individual actors in the enterprise are modeling and archived in the model” – Kuno Brodersen (Week 22, 2011).

While implementing the modeling tools it becomes a necessity to involve all of the employees, understand knowledge sharing, we have to focus to create transparent management systems and the system has to facilitate distribution of decision making.

It seemed like that CEO Kuno Brodersen was a bit skeptical about the Gartner Group and their approach to information technology and Enterprise Architecture, though he chose to apply one of their models in order to define the “new way of thinking” in Enterprise IT and Enterprise Architecture.

In the future it becomes a necessity to know how the social networks and the way people interact in social networks in order to facilitate knowledge sharing.

Technology trends will have an even greater impact on how knowledge sharing can be facilitated. In the future modeling software trends like the “Like” feature or comments on the various artifacts. Likewise will the concept of rating most likely be implemented in modern modeling tools.

Features from the social networks will in time be incorporated in to the modeling tools, or this is perspective that Kuno Brodersen presented. The reason for this is that it can be used as a form for “information filtering” and “quality insurance”.

“One of the best qualities of an Enterprise Architecture program is that the various models can be viewed by various stakeholders in the enterprise, and as such this can be used to define the enterprise ontology” – Kuno Brodersen (Week 22, 2011).

The QualiWare EA Framework is an organization of artifacts, but according to Kuno Brodersen, graduate students who are about to start writing on their master thesis could or should think on how the Enterprise Architecture framework represents the “social capital”, social networks, and social knowledge.

Kuno Brodersen presented the QualiWare analytics approach to artifacts and modeling that was build like a balanced scorecard that could be used in order to define how KPIs are aligned with the various processes. As such the data that should be represented in the QualiWare models should be collected from the data warehouses and business intelligence systems, this should add value to the platform for enterprise ontology. His approach to business intelligence and knowledge sharing, Kuno Brodersen, applied a rather positivistic approach and as such this seemed slightly in contrast to his initial approach on the Scandinavian management school; however he did emphasize that the business intelligence approach should be used with caution.

Gamification is “the new black” and it will become part of the modeling tools, or at least this is the views that Kuno Brodersen presented. E.g. Qualiware as a modeling tool has a “treasure hunt” game embedded in the modeling tool in order to train or motivate people in order to make people learn about the new models, processes and activities.

• New tools are needed to document and deal with knowledge.
• Enterprise ontology is a part of knowledge management.
• In engaging the various stakeholders in learning more about the enterprise’s architecture the concept of gamification should be introduced into new products.

The Proof of the Pudding is in the Eating

Olov Östberg was the keynote speaker. As such his presentation dealt with e-government and changing social and technological systems in Sweden.

In his presentation Olov Östberg showed dias that stated that only 18% of IT projects are delivered on time and that are succesfull and he put this in light of the Swedish approach to e-government.. Through time (about 300 years) the Swedish approach to government has resulted into very independent public agencies.

There have been different approaches in order to deal with the data that the Swedish government has collected over time. In the 90s and the early 2000s the focus was onto developing portals.

From his experience there are three levels of e-government that should be dealt with in the future. Government 1.0 is the classical approach, the second level is dealing with more communication and at some point slightly more openness and the third and last level deals with engaging the citizen as a co-creator.

The Swedish approach to e-government includes a rather liberal approach to how the local agencies handles its processes. As such it can become increasingly difficult to implement one approach to Enterprise Architecture. Likewise did the national authorities (the Swedish government) refused to install a national CIO, national roadmap or for that matter a national portal for data and information sharing.

Olov Östberg presented various initiatives on how the Swedish approach to e-government dealt with common problems like insufficient road maintenance, electricity etc.

“We have to realize that the foundation of Swedish society is changing.” – Olov Östberg.

]]> http://coherencyarchitect.com/2011/06/01/week-22-enterprise-architecture-summer-camp-day-2/feed/ 0 coherencyarchitect http://coherencyarchitect.com/2011/05/31/week-22-enterprise-architecture-summer-camp/ http://coherencyarchitect.com/2011/05/31/week-22-enterprise-architecture-summer-camp/#comments Tue, 31 May 2011 15:00:49 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=480 Continue reading →]]> This blog post deals with first day at the summer camp for Enterprise Architecture in Week 22 that was held in Denmark at the IT University of Copenhagen. The participants were mostly students. The tagline for this event is “Scandinavian Design and Oblique Angles”. The summer school had five keynotes that mainly dealt with how Enterprise Architecture could be applied under various conditions like everything from contract negotiations to Enterprise Architecture in the arctic circle to the concept of developing models for an Enterprise Architecture program.

The Agile Standard Contract

Kasper Hoegsberg, a student at the e-business line at the IT University of Copenhagen, presented his views on how the public standard contract for IT purchases could be updated.

His reasons to start investigating with standard contracts are based on that the new project models are with in the sphere agile development which is a change from the old approach to the contracts that emphasized the old waterfall model. While conducting his project he found out that the current approach for developing a contract was to fill out 10 documents before the contract could be considered value.

According to Kasper Hoegsberg the Danish National IT and Telecom Agency tried to combine the waterfall approach and the agile approach to develop a system that doesn’t seem that particular smart. Hoegsberg referred to the British DSDM – Aterm contract framework and the Norwegian agile standard contract PS-2000 as examples that in his opinion could outmatch the current approach that the Danish National IT and Telecom Agency has applied.

According to Hoegsberg the focus of the Norwegian contract doesn’t include a particular methodology and as such only includes an agile contract.

In his opinion further studies on how to make better contracts for development and delivery can be developed.

Complexity and Enterprise Architecture

Peter Flemming Teunissen Sjoelin presented some of observations he had made during the time he worked with his master thesis. The presentation had the tagline “Complexity in Development of Models for Enterprise Architecture”. In the presentation Peter Flemming Teunissen Sjoelin explained the concept of complexity, Enterprise Architecture, knowledge management and the mad scientist syndrome.

The focus that Peter Flemming Teunissen Sjoelin applied was that repositories, process models and a like are only representations of reality. The ideas presented in the presentation was based on the concept that the students and later on the future Enterprise Architects should thinking that social-constructivist paradigm might aid them with the investigation of how the various stakeholders in the enterprises thinks and acts.

• Probe your view of the things.
• Act upon the stakeholders suggestions.
• Keep your models simple, you shouldn’t assume that your models or repositories can be understood by all of the stakeholders.
• Models can’t contain reality. Models are just simplified representations of how the world works.

Value Estimation of Enterprise Architecture

Mikkel S. Holst and Tue W. Steensen works with their master thesis that deals with the value estimation of Enterprise Architecture. Their hypothesis is “How Enterprise Architecture becomes successful” and as such they base that further three hypothesis on how the Enterprise Architecture program can be aligned with the corporate strategy and corporate process.

Their theoretical approach to their master thesis has been based on Ross & Weill, Hoogervorst, Kaplan and Norton and many others.

Their master thesis includes three cases studies that the two students are conducting. Two of the case studies are within the public sector and one is the private sector.

In their approach to explore the value of Enterprise Architecture the students have made use of an article by Toomas Tamm et al. from 2011.

John Gotze advised the students to investigate how to “show the value” of the Enterprise Architecture program and how this impacts the organization. The two students plan to hand in their master thesis in August 2011.

Systems Thinking for Health – IT

The two students Linda Praestholm and Rasmus Frost have a loosely coupled approach to collaboration on the topic systems thinking in the public sector, or what is to be known as “Health – IT”.

The two students chose to work with the National Electronic Patient Journal systems and how these where implemented in the capital region of Denmark.

According to Linda Praestholm who have worked with Enterprise Architecture from a positivistic approach and she has come to conclusion that EA is a driver for making rational decisions, being more effective and effectiveness. As such these are the goals for the management and governance method for the enterprise.

Their investigation have included the Hilleroed Hospital, The Kingdom Hospital (Rigshospitalet) and Bisbebjerg Hospital. Their approach to Enterprise Architecture has mainly been based on that the various hospitals should have implemented new business processes in order to achieve some synergies with IT.

Soeren Duus advised the students to investigate what particular perspective to put onto their ideas of what Enterprise Architecture is all about and how it has been applied, or how it could be applied in order to achieve some of the goals that the regions have defined for the various hospitals.

Enterprise Architecture on Greenland (Arctic Architecture)

The three students Lars C. Meden, Soeren Tams and Fredrik Krog have visited Greenland in order to collect data on how to deal with the concept of Enterprise Architecture in a country that is significantly different from the industrialized part of the world. The focus of their thesis has been on how to improve the service the public sector provides to the population on Greenland.

The situation on Greenland includes the focus on few resources e.g., few employees and economy, a big diversity between the organizations and a big IT architecture related diversity.

According to the three students the autonomous government of Greenland should have the resources to implement a functional approach to Enterprise Architecture.

One of the challenges in governing Greenland is that it very expensive for the population to travel from one part of Greenland to the other, and likewise does it make communication among the various local authorities rather difficult. As a result of this the autonomous government of Greenland has started a process of implementing video conferencing.

The students focused on how to deal with the municipalities of Greenland and how their particular strategies could be dealt with through applying Enterprise Architecture.

Another barrier for implementation of Enterprise Architecture on Greenland is the lack of a competent local workforce. If the public sector on Greenland has to be able to identify how the various artifacts and as such it doesn’t seem like the local workforce have access to the particular education, or training in the moment. The three students questioned the suitability of implementing an Enterprise Architecture program across the various organizations in the Greenlandic public sector due to the resistance among the local organizations, that might feel that their independence is threatened by a centralized approach to Enterprise Architecture.

There are probably many different ways to gain sense in each of the many different enterprises and organizations across the planet. This particular paper investigates one particular approach question the validity of the data and the selected approaches to articulate strategies and plans. This should give you (the reader) an idea on how to develop better plans that in turn would give the enterprise a better system.

In order to make proper decisions on how to develop the enterprise it becomes a necessity for the enterprise to deal with the question of sense making. How does the specialists and systems that have been applied in order to analyze data from the enterprise’s environment? How does the systems adapt to the trends the data indicates might be developing? How do the specialists question and tests the data they have collected and analyzed?

The three step approach to organizational learning and data collection is in its origin based on Weick’s approach, though I’ve taken some liberty in order to create a synthesis in order to specify the ideas that Weick presented in his book (Making Sense of the Organization, 2000) to an Enterprise Architecture approach in order to enable enterprises with crystallizing competitive advantages. By crystallizing competitive advantages the enterprises could avoid situations that in other cases would have forced out of business. This leads to the first part of the process that Karl Weick introduced in his book.

Scanning for Data

It is of importance of all enterprises to scan its environment in order to gain an understanding of how the stakeholders (competitors, suppliers, government etc.) will be acting in potential future scenario. This is usually a rather good component in articulating a corporate strategy and all of the subsequent strategies like the IT strategy, financial strategy, organization planning etc.

The scanning process includes the situation for the internal environment and for the external environment. The internal environment consists of an other set of stakeholders than with the external environment, but these are just as important. Likewise is the internal environment connected to the the external environment.

The data is usually based on several different sources and as such the data that the specialists and systems collects are of different qualities and as such the data and their sources have to be questioned. The questioning is in a way a process to ensure that the specialists who collects the data should question the ways they identify the data and how to be able to deal with the way the data is analyzed. This is discussed in detail in the interpretation.

Interpretation

While analyzing the data the specialists works with a validation technique that in turn tries to investigate how or if the enterprise can make use of the data. The interpretation is likewise a fundamental element in the way the data is applied in the strategy development process.

The interpretation can be used to ensure that the strategies could be easier to implement, and as such the strategies could lead to the desired state of the enterprise. As such the focus of the planning would have to avoid what Mintzberg (Mintzbegr 2009) defines as the planning school, that is characterized by applying a lot of resources to the articulation of planning but as such it usually emphasize planning too much and implementation too little.

Learning

The specialists and the systems would have to learn from the articulated strategies, otherwise will they fail in adapting to the new situations of the environment that they analyze.

The learning process is likely the most important step of the entire process since the enterprise’s specialists would have to adapt their analytical models to understand how the environment.

The result of the learning phase is in itself a form of knowledge sharing and it impacts the framework of how the enterprise operates.

Learning and knowledge sharing are two sides of the same issue and as such the specialists and decision makers have to think in how to transfer the knowledge to one another. For this a specialized repository can be applied. In order to share knowledge across the enterprise the individuals would have to a common understanding of what knowledge is about and who to interact within in order to gain access to the information and knowledge that they assume they would need in order to make better decisions and better plans for how the enterprise can gain competitive advantages.

In order to gan a further understanding of how the enterprise can create value through planning it becomes a necessity that the cycle is documented and the cycle is transparent for all of the stakeholders that interacts with top level planning.

The Cycle

The process is cyclic and that is essential that it is build upon a cyclic structure in order to the specialists to make their predictions more reliable. More reliable plans can be used by the decision makers to enable the enterprise to achieve its goals.

Furthermore can cycle be enhanced with the enterprise, if an Enterprise Architecture Program is established and that the decision makers makes use of the data that the Enterprise Architecture program has been able to produce.

The illustration below shows how the enterprises can make use of the sense making process to achieve a more coherent, better aligned and more agile enterprise. As it is illustrated the Enterprise Architecture Program is used to enable the decision makers to align the various conceptual sections of the enterprise. In the diagram below there are three conceptual sections of the enterprise. The decision makers articulate a strategy.

The experienced reader would note that the definition of what Enterprise Architecture impacts is derived form the EA3 Cube framework that Bernard (2005) proposed. The approach is based on the concept of Enterprise Engineering (Sjoelin 2011a) and as such it is the opinion of the author that the focus of the .

Assessing the Business Processes

The chief architect should evaluate the business processes, and it is a necessity to evaluate the primary business processes, business model/operating model (Ross & Weil 2009, Ross et al. 2006, Ross & Weill 2004, Finkelstein 2006) and support processes (Porter 1985).

In this particular paper the concept of primary processes is defined on what processes that are essential in order for the enterprise to deliver value to its customers. The chief architect should naturally apply a multi perspective analysis method to understand the underlying principles of the enterprise and its social systems. For this the chief architect and his associates (the enterprise architects, solution architects, business architects) should investigate the operating model and business model of the enterprise in order to gain an understanding of how the enterprise’s internal environment will change in the near future. The scanning of the internal environment should uncover the processes that aren’t fully supported by IT and the processes of which the enterprise would be able to identify a series of projects that could change the enterprise to a desired and more competitive enterprise.

The chief architect or one of his or her associates have identified which of the business processes that do support the business in achieving its goals. He or she would have to go into a process of identifying those processes that would have to be obliterated (Hammer 2000) (re-designed completely). In the process the chief architect and associates would have to re-thing the support processes in order to avoid the pitfalls of an unstructured and incoherent enterprise architecture.

The chief architect and his associates would have investigate how the various processes could be grouped and how the various projects can be implemented in order for the enterprise to harvest synergy. The primary business processes should be organized into “clusters” along side the support processes that clearly can be associated with each of the primary processes and as it has been mentioned earlier in this paper it is a necessity to organize the various business relates activities and processes in order to maximize the potential synergies. However there are some pitfalls that the chief architect and his associates might fall into for example is complexity a factor that can’t be ignored. The more complex a particular segment or domain of the enterprise is the more likely it is that the particular system in the enterprise can’t be generalized into an “Enterprise-Wide” platform, or rather the meaning of doing so is lesser relevant in the sense of information systems design.

Connect the Business Processes and the Information Systems

The chief architect and his associated would have to apply a structured methodology in order to ensure that the enterprise is able to establish and understand how the enterprise and its underlying architecture works. In this paper the author assume that this can be done through the establishment of a formal group that is in charge of investigating and defining the enterprise’s architecture. The method can be based on formal Enterprise Architecture framework and as such be a part of the structured methodology that the decision takers decides to apply.

The author’s definition of Enterprise Architecture is:

“Enterprise Architecture is a set of principles, standards and methods for achieving informed governance. The models derived from the standards and methods have an impact on how the enterprise is able to align each of the elements of the enterprise with one another. The alignment will enable enterprise governance and agility for adaption and assurance.” – Peter F. T. Sjoelin (2011a)

It is the author’s opinion that the framework is the set of standards that dictates how the various artifacts that would be documented and stored in the repository are to be defined. In other words the framework is alpha – omega in order lay the foundation for an enterprise ontology (Dietz 2006, Bernard 2005, Hoogervorst 2009).

The framework could eventually give the chief architect the advantage of winning over stakeholders that are skeptical towards the concept of Enterprise Architecture, and likewise does the author assume that the framework would have a significant impact on the value of the repository that contains the descriptions of the artifacts. The value is derived from how well the various stakeholders in the enterprise are able to connect to the repository and understand the value of these.

As earlier mentioned the author expressed his views on that business processes and IT rarely generates synergies due to the lack of obliteration of processes that were designed for the pre-computer and Internet age. It is necessity for the chief architect and his associates to investigate the enterprise’s current usage of information technology and information systems. The chief architect and his associates should be working with a methodology that documents the various information systems, platforms, applications, devices that the enterprise applies in order to provide the various stakeholders (executives, middle managers and employees) the proper information in order to make them understand how the social system works. The chief architect would have to make sure that the business processes and the information systems are evaluated before and after the change process has been initiated in order to give the decision makers the best possible overview of how the enterprise has changed after the implementation of the new approach to business processes and information systems.

It is the opinion of the author that in order to ensure that the enterprise would be able to gain an advantage in governance by focusing on the enterprise’s approach to investing in its technology, assets, people and systems (Potts 2008). The investment process is essentially the embodiment of both the corporate strategy, the IT strategy, the financial strategy etc. After the chief architect and his associates have worked with their analysis of the enterprise’s corporate strategy it is almost certain that a road map should be articulated so the focus could be shared among the members of the Enterprise Architecture group and later on among the various decision makers in the particular enterprise.

It is the author’s opinion that the investment approach would have to be connected with the the enterprise’s program management. It will become a necessity for the enterprise to deal with its approach to enterprise investments and program management since it is the decision makers who are responsible for the allocation of resources to the projects and systems that the enterprise are able to invest in the projects that will change the enterprise. According to Bernard the the enterprise would have to change by the many different projects alter and mature the architecture of the enterprise.

The author is of the opinion that the desired architecture (TO – BE) should be described in a transition plan that should be used as a document to communicate with the stakeholders and the decision makers in order to communicate and evaluate the each of the projects that would have to be allocated resources to and implementation of projects. Likewise is it the author’s opinion that the transition itself has to be guided by the principles that the chief architect and the decision makers have articulated.

As the author has mentioned earlier in this paper the complexity is a barrier that can’t be ignored if the synergies of enterprise architecture and enterprise governance should be harvested.

Group the Business Processes and the Information Systems

The social systems have to be identified and as such it becomes a necessity to group the systems into various domains of specialisms. Each of these domains would have to generate synergy among the social systems and the information systems in order to justify their existence. The domains are a necessity in order to cope with the question of complexity.

Complex organizations can very well own processes and departments that are specialized to the degree that it constitutes a silo. In those cases, the silos can’t be viewed as negative issue, as long as the employees, middle managers and executives in charge of the various processes communicate and interact with one another on regular basis.

In order to ensure that the changes by grouping the various information systems and social systems, the managers would have to allocated resources in order to facilitate communities of practices that would enable the stakeholders in the enterprise with understanding and adapting to the new situation in the enterprise. It is pivotal that the decision makers allows the various members of the enterprise to make use of their time at work and in the change process to form such social networks.

A community of practice is defined by Wenger (1999, p. 47) as “Such a concept of practice includes both the explicit and the tacit. It includes what is said and what is left unsaid; what is represented and what is assumed. It includes the language, tools, documents, images, symbols well-defined roles, specified criteria, codified procedures, regulations, and contracts that various practices make explicit for a variety of purposes”.

It is likewise a necessity to make use of the social networks to create an understanding of how the enterprise works since that would add value to the ontology of the enterprise.

The social networks are likewise pivotal in order to enable the change process that occurs within the enterprise, and as such the chief architect and the decision takers who are in charge of the enterprise have to identify change agents and motivate the various social networks to adapt to the changes and work alongside the goals that the decision takers have articulated for the enterprise. In this light the decision takers would have to trust that the members of the enterprise works for the best of the enterprise and to some extend allow the employees to self-organize and prioritize the various tasks at hand.

I would recommend a form of hybrid of a top down (Kotter 1995) and bottom up approach (Hamel 2007) to solve the problems with anchoring the changes in the enterprise. The approach is dealt with in detail in table 1: The suggested approach to change management.

Step	Description	Impact
1	Establishment of the an active network within the executive group.	The executive group and middle managers (who aspire to become executives).
2	Identification of change agents in the enterprise that would stay among middle managers and employees.	The entire enterprise and on all levels of the enterprise. There should be found agents as many places as possible.
3	Establishment of an office or department for internal communication in the enterprise. This office has to be located close to the change leader and his position so it is clear that what is sent to the employees in the organization is the words and intentions of the leading coalition.	The upper end of the middle management. Eventually it will impact the rest of the enterprise since the communication from this office should be directed to all parts of the enterprise.
4	Establishment of scope, goals and mission clearance. Stakeholder alignment is a necessity to create the proper dynamics.	The change coalition (all agents on all levels of the enterprise should be involved in this).
5	The change leader should make sure to attend meetings and conferences with the other managers on how the change effort is planned to impact the enterprise.	Executive group and middle management.
6	Plan workshops with employees that focus on identifying issues that needs to be dealt with in the particular devisions, departments, processes and projects.	All members of the enterprise.
7	Enable feedback channels where the executives, managers, and employees can report if departments or processes don’t work as intended. In this case IT / IS is a part of the concept of processes.	It will impact all levels of the enterprise in order to achieve that all members of the enterprise are able to add information to what needs to be re-configured.
9	Initiate the implementation process.	All members of the enterprise will be impacted as a result of the change program.
10	Keep on changing the architecture in order to achieve agility and adaption the changing environment of the enterprise.	In the long run it will impact all members of the enterprise on all levels. In the short run small sections of the enterprise will be changed.

Table 1: The suggested approach to change management.

The managers needs the information that they can gain access to in the social networks through their insight to the networks. When it comes to the diffusion of knowledge it is very likely that the segments of the enterprise that are too complex. If the knowledge is too complex it is evident to investigate if the particular domain can be handled by enterprise-wide systems or for that matter enterprise-wide business approaches. Nonetheless the most important thing is that the any new employees, managers or executives can be introduced to the persons who have some idea on how to deal with the problems, tasks, activities and processes in each of the domains that are likely to be too complex. What is important for the enterprise is that the executives, middle managers and not to forget the employees support a culture of knowledge and information sharing. The IT systems should be developed to support their particular processes. These information systems could eventually be connected, but there is as such no need for enterprise-wide information systems that standardize the workflows. Knowledge can be hard to standardize and as such the various stakeholders of the enterprise can’t be expected to know everything about the same topic. In other words it is very likely that the chief architect and the decision takers would have to challenge their assumption on process standardization.

Create Value Through Grouping of IS and Business Processes

The chief architect and his associates would have to investigate how the enterprise can generate value through grouping the social systems and information systems.

The approach that the chief architect and his associates should work with a projects that will enable change for the various projects that would change the enterprise.

The progress for each of the projects will be impacting the enterprise’s architecture and thereby transform the architecture from the AS – IS situation (Bernard 2005)which is the current state for the enterprise’s architecture to the desired state which Bernard names the “TO-BE” state. The transition plan is the document that communicates what kind of projects that would have to be initiated and implemented in order to mature the enterprise’s architecture and through that enable the enterprise to reach its goals. The transition plan also works as a kind of plan that can be communicated to the various stakeholders who would have to back the enterprise in the maturation of the particular situation. The maturation process has to be evaluated before the chief architect and his followers initiates the change program. It is very likely that the stakeholders will be easier won over if they can see a logical plans that includes economical estimation of how the plan impact the enterprise’s economical situation. It is needless to say that the enterprise’s decision makers would have to have an insight on how well the enterprise can process the various resources it has at hand and thereby produce the products and services that its customers want to purchase.

The evaluation process is likewise a part of how the enterprise scans its internal and external environment and as such the Enterprise Architecture program should work as the platform for the construction of a shared ontology across the enterprise. The chief architect should keep in mind that in departments or segments that can be characterized as being characterized as complex it is rather likely that their particular views can’t be generalized into an enterprise ontology if such can be formulated.

In order to get the information that the chief architect and the decision makers need in order to plan and allocate resources to the transformation the enterprise would have to go through. They would have to go into detail with how the various social networks and communities of practices and search for the information and knowledge in order to gain a firm understanding of how the enterprise works and thereby how it can be changed. In this light the chief architect and his associates would have to decide if they should apply a top-down or a bottom-up approach. The approach chosen would eventually become a part of the debate that the members of the enterprise on what has to be done. Will the decision makers tolerate increased autonomy or if they would prefer increased centralization. As earlier mentioned it seems like that the tendencies for the development organizations.

Change the Enterprise

The chief architect and the decision makers would have to go further with the change of the enterprise. The change process would have to be a part of the overall Enterprise Architecture program and it will certainly impact the enterprise and how it works. In order to do so the chief architect would have to influence the stakeholders (decision makers, the middle managers and for that matter the employees). The changes are caused by the the questioning of the how the enterprise is able to collect the data needed in order to take the decisions needed to achieve the goals that was set for the enterprise. The author is of the opinion that the grouping of information systems and social systems in order to harvest the synergies with each one of them and among each of the clusters The clusters can most likely produce synergies for each of the areas that shows the amount of gravity that produce a barrier of complexity.

Before the chief architect and the executives commit themselves to changing the enterprise they would have to understand how the enterprise and its architecture works. In order to achieve this the chief architect would have to choose an Enterprise Architecture framework, adapting the framework to the particular enterprise and implement the framework. Thereafter should the chief architect and the enterprise architects work with identifying the various artifacts, and organizing them in an Enterprise Architecture repository. While working with the identification of artifacts and organization of artifacts in the EA repository it is important that the chief architects understands that there might be barriers to create define an unified ontology and as a result of that there might be a necessity to create several different sub-units of the EA repository. The chief architect work with an assumption that each of the specialized operations of the enterprise should be mapped as a separated entity and as a separate mini architecture of the enterprise.

The author is of the opinion that it is possible to convert extremely specialized knowledge for each of the specialized processes to other parts of the enterprise without a lot of the meaning of each of the artifacts is lost. It is better that there is a platform for informed governance for each of the segments than a system that doesn’t adapt to the entire enterprise. The managers of each of these segments should in the long run participate in the community of practice that shares knowledge and know how with one another. The chief architect can at some extent work as the change manager would would have to convince the various stakeholders in the enterprise to support the changes and in the same time enable them to take the changes even further.

The change manager would have to ensure that the office of internal communication is located and positioned as a part of management and it symbolizes the foundation of management for all other segments of the enterprise. It is pivotal that the change efforts are supported by the middle managers since they act as the approvers of each of the employees time and effort to commit to the particular change system. If the middle managers ignore the call for change and disapprove of the changes that the employees suggests then it is very likely that the changes will come to a still and eventually fail. Likewise would the commitment of the employee be of great importance since it is likely that each of the employees have specialized knowledge of how the work processes interacts.

Conclusions

The author is of the opinion that the organization have to work with several different approaches to challenge their particular views on how the enterprise collects the data that are used by the decision makers. Likewise is it likely that the various decision makers of the enterprise would have to deal with identifying segments of the enterprise that are too complex to be adapted to generalized business processes. The author is of the opinion that the chief architect and his associates would have to deal with the challenges of adding value to the enterprise by applying the standardized business activities and business processes, but in the same time be able to identify where it wouldn’t make sense to apply standardized systems since that wouldn’t provide the enterprise with any kind of advantages.

The focus of the members of the Enterprise Architecture team would have to include the concept of complexity to the concept of enterprise ontology and as such should the repositories that would be able to connect the various sections of the enterprise and communicate the meaning meaning of how the enterprise works to the decision makers and other stakeholders who would have to make use of the knowledge that is represented in the repositories.

Likewise is it a necessity for the decision makers and the chief architect would have to investigate the various elements of the enterprise in order to achieve better insight into how the enterprise works and from that enable better decision making in order to achieve the objectives for the enterprise.

Bibliography

Bernard, S., A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.

Dietz, J.L.G., 2006. Enterprise Ontology: Theory and Methodology, Springer.

Hamel, G., 2007. The Future of Management, Harvard Business School Press.

Hammer, M., 1990. Reengineering Work: Don’t Automate, Obliterate. , Harvard Business Review no. 68.

Hoogervorst, J.A.P., 2009. Enterprise Governance and Enterprise Engineering, Springer.

Kotter, J.P., 1995. Leading Change: Why Transformation Efforts Fail. Harvard Business Review, (March – April 1995), p.9.

Wenger, E., 1999. Communities of Practice: Learning, Meaning, and Identity New Ed., Cambridge University Press.

Mintzberg, H., Ahlstrand, P.B. & Lampel, J.B., 2008. Strategy Safari: The Complete Guide Through the Wilds of Strategic Management 2nd ed., Financial Times/ Prentice Hall.

Porter, M.E., 1985. Competitive Advantage: Creating and Sustaining Superior Performance, New York: Free Press.

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

Ross, J.W., Weill, P. & Robertson, D.C., 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution illustrated edition., Harvard Business School Press.

Weill, P. & Ross, J., 2009. IT Savvy: What Top Executives Must Know to Go from Pain to Gain, Harvard Business School Press.

Weill, P. & Ross, J.W., 2004. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press.

Weick, K.E., 2000. Making Sense of the Organization, WileyBlackwell.

The paper can be downloaded here or read at ISSUU.