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.