There is some form of hierarchy among strategies that relates to the enterprise information technology strategy (IT strategy) and there might be some need to divide the strategies in order to specialize them e.g. through different persons who have the responsibility for the strategies or ensuring that the relevant information is screened to the relevant stakeholders. I hereby assume that the chief executive officer wouldn’t be that interested in particular technological products e.g. which edition of JAVA should the company’s IT-department be using or which particular server platform would be preferable in order to keep track of smartphones and tablets?

The technology strategy deals with the “hard side” of the technology. Which products, programming languages, databases, hardware, operating systems, back end platforms, ERP systems should the organization make use of.

What is the Technology Strategy?

The technology strategy deals with articulation of plans, roadmaps and principles for which information technologies that the enterprise should make use of.

The technology strategy is all about giving the decision makers some guidance on how to ensure to get rid of systems that only adds risks to how the organization does its business.

Systems that potentially will not add any kind of value to the business and instead seems like a liability own and be a part of the application portfolio.

Relations to IT-strategy

The technology strategy is delimited to deal with information technology (abbreviated IT) and as such the technology strategy can be related to the usage of IT strategy.

The difference between the technology strategy and the IT strategy; is that the IT strategy usually makes use of a long term description of goals that ensures that the IT department will enable the “business” with achieving its goals and adding bits to the a platform that could be turned into competitive advantage if used correctly.

Who formulates the Technology Strategy?

In many medium and large sized organizations have usually two types of technically related chief executives. The first one is the Chief Information Officer. The second one is the Chief Technology Officer (abbreviated CTO) who is more focused on the application portfolio, platforms and hardware.

The two of them are responsible for different perspectives of the enterprise’s usage of information technology; however it is more likely that the CTO reports to the CIO than the other way around.

The two would have to collaborate on delivering plans that can improve the organization and its usage of information technology.

How do You Formulate a Technology Strategy?

There are many ways to formulate a technology strategy and the way I see it the most important thing is to deliver results through changes investments behavior.  In this regard I assume that a technology strategy would have to be dealt with through the articulation of principles.

Greefhorst & Proper (2011) have written a rather interesting book named “Architecture Principles” and as such their approach to formulating principles can be made use of in order to formulate proper principles that can be incorporated in the technology strategy.

Conclusions

A technology strategy is usually used for ensuring the organization’s ability to gain a return of value of the investments it has committed to the applications, systems, platforms and development can be gained and turned into an advantage.

In order to do so the CTO has to collaborate with other profiles like the CIO in order to develop coherent strategies for the organization’s it-architecture. In order to make a sustainable and resilient strategy it has to be build upon principles.

The next blog post that I plan to publish will deal with principles and how a good principle is formulated.

I am aware of that Tom Graves has done something similar, though he has made a completely different model, and as such his model is fine, but the audience that I intend to communicate with would be more likely that they will understand the value proposition of enterprise architecture through a model designed upon the business model canvas compared to a model based upon Graves’ model.

As you might have guessed then I had to adjust the business model canvas in order to expose the data on how the enterprise architecture program delivers value in the best way possible.

The first seven phases have been renamed in order to adapt the model for how a department or function within an IT department delivers values.

The first phase is about key partners needed in order to produce any form of value by the enterprise architecture program.

The second phase is about how the key activities that are needed in order to produce value. The needed activities would have to be organized around on handling the resources.

The third phase is about the key resources needed to produce the services or products needed by the segments of the it department.

The fourth phase is about the value proposition. In other words its about the initiatives at hand.

The fifth phase is about team relations and they are usually essential for both implementing and producing the services. Especially if we assume that enterprise architecture is about creating value through others.

The sixth phase is about channels. How does the enterprise architecture program deliver resources

The seventh phase is about the segments of the IT department that receives the services from the Enterprise Architecture program.

The eight phase is about the Enterprise IT Investment structure. This particular section of the business model deals with the identification of how the current situation of the IT Architecture the IT organization processes.

The ninth phase is about scenario planning, that deals with planning for a better IT Investments for the IT department.

The tenth phase is about the Improved Enterprise IT Investment Structure that deals with multiple actionable plans for changing and optimizing the total architecture.

All together these phases can present the necessary data to the decision-makers in order to give them an insight on how enterprise architecture delivers value to them. Value is key in situations where organization have limited access to resources.

The Architecture Business Model.

The foundation architecture is as earlier mentioned scoped on delivering value to the IT department and through to the IT department to the rest of the enterprise. The model is published under the Creative Commons license (share alike).

As a result I have made some thoughts of my own, and my thoughts have been delimited to what could happen in Scandinavia. There are reasons for when or where the organization should develop.

Most of the articles that I have read in order to identify the potential development of Enterprise Architecture in 2012 were developed by American organizations and my assumption is that American organizations usually apply an American approach to dealing with problems at hand, and as a result my view might differ quite a bit from the trend analysis that organizations like IBM, Gartner Incorporated, The Open Group, Microsoft or other organizations might have articulated.

Below I have defined four areas that organizations will invest their resources into.

Frameworks and Models

• CIOs, it-management and the chief architect have discovered that it is unlikely that they will gain a total overview of all systems available in the enterprise and they will focus on developing a few key models.

• The chief architects will continue investing time and effort into deployment of frameworks, but the chief architects would still have to mix “best of breed” from the frameworks in order to implement the enterprise architecture program.

Investments Planning and Governance

• Medium and major organizations will begin to add their IT investments to their Enterprise Architecture models, since it is presumable that this would add value to the decision platforms.

• The investment planning will still be focused on the IT-spending and only to some degree on how information technology takes part of add value to the business.

Technology Foresight

• The Enterprise Architecture programs will still be IT-centric; however the structured methodology for collecting data about the enterprise architecture will provide the chief architects with the opportunity to impact the IT – strategy, and as such they could have a chance to evolve the enterprise architecture program.

• The Enterprise Architecture programs will be used in order to define strategic approaches to what sort of technologies that make sense to invest in. As such the chief architect can gain a leading role in articulating the it-strategy. In order to do so the chief architect would enable a platform where realistic scenarios for implementing technology in order to give the decision-makers a realistic insight on what they would have to deal with.

• The debt and credit crisis will in 2012 impact the organizations in a way that increases the demand for a smarter usage of the information systems and technology platforms available. The smarter usage of information systems demands an approach to information governance and reliable information.

Principles, Standards and Methodology

• Organizations will find out that without principles for how to deal with different perspectives of developing their IT architecture, they will not be able to enforce the desired behavior. As a result organizations will invest more time in articulating principles.

• EA assurance for the IT architecture will be a hot topic during 2012, and the organizations will eventually initiate projects that will focus on the articulation of principles based upon criteria like when does the principle apply, when can the developers differ from the principles, when should the principle be updated and who is responsible for updating the standard?

• Standardization will likewise become a dominant topic, and many organizations will initiate projects that supports the development of it-projects enhances customer experience (platform independent and mobile). Management of standards are vital in order to ensure the development of these projects since it it is vital to ensure the data export of data.

Conclusion

Due to the crisis most organizations tries to reduce costs and deliver a better value proposition to its customers. Most organizations can save money through standardization of the their IT-architecture; however the decision-makers would have to know how to deal with gaining information of how the IT-architecture works, how it can be simplified (enhancing speed of development) and how it can be closer aligned with the business processes.

For this, enterprise architecture is essential and that is how I see the usage of enterprise architecture in Scandinavia in year 2012.

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.