Category Archives: Business Architecture

Architecture Capabilities through Business Models

Posted on by
Reply

For some time I have been working with adapting the business model canvas for explaining how an enterprise architecture program delivers value to the it-department. The scope of the model has been on the foundation architecture where the outcome of the enterprise architecture program is mainly used by the IT department.

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

Developing Frameworks: Five Things To Do and Five Things To Avoid.

Posted on by
Reply

The Essentials

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

1The situation as it is in the current moment.

Innovation in an Enterprise Architecture Context: Innovating the Business Processes, Technological Services and Corporate Strategies.

Posted on by
Reply

Innovation

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.

Holistic Management in a Context of Enterprise IT Management and Organizational Leadership

Posted on by
Reply

An Approach to Sense Making and Intelligent Business

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

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

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

Scanning for Data

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

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

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

Interpretation

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

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

Learning

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

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

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

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

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

The Cycle

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

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

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

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

Assessing the Business Processes

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

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

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

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

Connect the Business Processes and the Information Systems

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

The author’s definition of Enterprise Architecture is:

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

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

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

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

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

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

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

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

Group the Business Processes and the Information Systems

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

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

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

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

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

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

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

Step

Description

Impact

1

Establishment of the an active network within the executive group.

The executive group and middle managers (who aspire to become executives).

2

Identification of change agents in the enterprise that would stay among middle managers and employees.

The entire enterprise and on all levels of the enterprise. There should be found agents as many places as possible.

3

Establishment of an office or department for internal communication in the enterprise. This office has to be located close to the change leader and his position so it is clear that what is sent to the employees in the organization is the words and intentions of the leading coalition.

The upper end of the middle management. Eventually it will impact the rest of the enterprise since the communication from this office should be directed to all parts of the enterprise.

4

Establishment of scope, goals and mission clearance. Stakeholder alignment is a necessity to create the proper dynamics.

The change coalition (all agents on all levels of the enterprise should be involved in this).

5

The change leader should make sure to attend meetings and conferences with the other managers on how the change effort is planned to impact the enterprise.

Executive group and middle management.

6

Plan workshops with employees that focus on identifying issues that needs to be dealt with in the particular devisions, departments, processes and projects.

All members of the enterprise.

7

Enable feedback channels where the executives, managers, and employees can report if departments or processes don’t work as intended. In this case IT / IS is a part of the concept of processes.

It will impact all levels of the enterprise in order to achieve that all members of the enterprise are able to add information to what needs to be re-configured.

9

Initiate the implementation process.

All members of the enterprise will be impacted as a result of the change program.

10

Keep on changing the architecture in order to achieve agility and adaption the changing environment of the enterprise.

In the long run it will impact all members of the enterprise on all levels. In the short run small sections of the enterprise will be changed.

Table 1: The suggested approach to change management.

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

Create Value Through Grouping of IS and Business Processes

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

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

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

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

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

Change the Enterprise

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

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

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

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

Conclusions

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

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

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

Bibliography

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The paper can be downloaded here or read at ISSUU.

The Fractal Organization: From an Enterprise Architecture Point of View.

Posted on by
3

Enterprise Architecture

Patrick Hoverstadt started the lecture by saying that he had never heard of Enterprise Architecture before he ran into John Gotze but of what he has learned it is about making sense of the organization and creating a conceptual model for the enterprise.

Build Models

In Enterprise Architecture modeling is a corner stone and the models serve to create an idea on what we are trying to manage and how well to understand the model. The model has to be based on real life data and it has to represent reality in the best way possible. The models provide both a simplified version of reality but it does also provide a usable representation of reality. This representation gives the members of the enterprise an ability make decisions on how to design the various business processes.

“our ability to manage an organization is based on how well we understand it, and our understanding depends on how useful & appropriate are the models we use” - Patrick Hoverstadt (2010)

When working with this approach it becomes clear that the Viable Systems Model in some form can be identified as a part of the school of enterprise engineering. The school of enterprise engineering is characterized by the idea that enterprises can be defined and designed by models and meta-models.

The Viable Systems Model

Usually the organization diagram has been the model that most enterprises relate two when they delegate blame and responsibility. However the viable systems model is slightly more complicated.

In the viable systems model operations and environment is linked. The first part that needs to be done is separating the primary activities. Through this process then the focus should be what activities provides value to the customers. The reason for this is that it is the customers who finance the activities of the enterprise (at least from cash flow perspective. For the public sector it is the tax payers who pay for the particular services through the tax bill).

 

When the first two processes have been taken into consideration then you would have to go up through the model. The primary assumption is that the various primary activities can be broken down into smaller steps in the process. This means that the enterprise works with an assumption that the sup processes can be reconstructed and create synergy.

 

The same approach can be used for the enterprise e.g., the operations that are organized around the concept of the co-ordination and the lines of co-ordination. However it is clear that most enterprises are products of randomly available components that likewise have been deployed randomly and one of these components is the management component. The management component is according to Patrick Hoverstadt that component that undermines the core of the enterprise, and that in some way undermines the enterprise’s ability to adapt, adopt and act according to the changes in its envirornment.

 

“Most organizations are rubbish since most managers are promoted by putting fires out” – Patrick Hoverstadt (2010).

 

Management and especially delivery is an important task for the executives and the middle management to deal with. They work in particular to ensure that operations delivers what the management has specified what they should have done.

 

Likewise does it include decisions of what the management has been located in the delivery service. “This is the spine of the hierarchical organization” – Patrick Hoverstadt (2010).

 

The spine is building the conversational loops. The conversational loops deals with creating this focus on working with building the conversations on what we need to produce and when we should deliver it.

According to Hoverstadt this deals with specific (specifying), agreeing on performance, measuring performance, resource bargaining and fragmentation. In other words should the managers (including the executives) work with understanding on how the employees and the managers under them interact with the everyday demands and processes. In most cases will the various levels in the enterprise contribute to both a positive development and the negative cycle.

If management is aware of the problems in the hierarchy it can be assumed at least some of them will do something about it in order to optimize the enterprise or at least do an attempt to enable that the enterprise will survive both in the long and the short run. The usual problems with management and the subunits they manage are conflicts over resources, turf wars, conflicting orders and conflicting messages from the customers (internally and externally) of the enterprise and weak planning for the operational core of the enterprise.

A classic situation is that something changes in the operations section and that impacts the rest of the organization and in response to that is that the senior management demands more and more control over the operation. This is done through reporting (setting up a bureaucracy).

 

“… they try to micro manage the local managers, and that turns into a vicious cycle” – Patrick Hoverstadt (2010).

 

When the vicious cycle has started then it becomes a problem dealing with problem solving, and instead it becomes a show for managers to exercise control. This will eventually turn into a disastrous path.

The turf wars for managerial control leads to sub-optimization and it becomes an anti-thesis to efficiency and it will eventually lead to trouble and act as resilient barrier for accomplishing the goals of the enterprise.

 

Another factor that is of great importance for any enterprise is that its executives (executives, managers etc.) are well informed on the environment (customers, competitors and government), and the organization. If it happens that the executives aren’t informed about the environment, or for that matter they don’t understand the activities or the structure of the organization then the executives will start to develop an assumption of how the enterprise and the environment works. This assumption can very well be very far from what really happens in the enterprise and therefore it becomes dangerous develop this form of groupthink (a state of which the executives continuously will put pressure on one another in order to take more extreme) in the top of the enterprise.

The enterprise’s decision makers needs the right information at the right time and at the right place; however it doesn’t enforce sanity and a sense of reality.

To make some sense of reality basic systems of allocation of resources and responsibility e.g., a basic but functioning management accounting system that is build upon activity based costing.

The Monitoring Loop

In management situations proof and trust are the two most important factors. Can the manager trust the information, and can use the information to guide any form of guiding principle?

If the information isn’t valid then it is very likely that the decisions made will not be in alignment with the continuous change in the environment that the enterprise works in.

 

“The loop needs to bypass at least one level of management. It has to ensure performance reports are accurate and the monitoring loop should ensure the manager’s understanding of operations.” – Patrick Hoverstadt (2010)

 

The monitoring loops should be generating qualitative data that the managers (delivery) can trust. According to Hoverstadt the only way to measure the conflicts among the managers and the various units dealing with operations have to be qualitative due to you can’t measure the conflicts in a management group through quantitative data.

Usually do middle managers co-ordinate with one another in secrecy to avoid the micro-management-syndrome.

It becomes a necessity to link operations to decisions and agreeing and measuring performance, and agreeing to the resource allocation.

Intelligence

The intelligence section in the management framework is doing surveys for technical, competitive and market developments that occurs in the environment of which the organization (enterprise) operates. The intelligence section is one of the most important sections in the enterprise, if the enterprise hasn’t access to accurate and sufficient information then the enterprise will experience problems with qualified decision making. Nonetheless most enterprises are not particular good in dealing with this important segment of the enterprise.

“Usually organizations are catastrophically bad at this” – Patrick Hoverstadt (2010).

Thereto does the intelligence deals with identifying the R&D potentially and planning how the enterprise should overcome the obstacles in its way.

Governance

This is the section of the Viable Systems Model that handles the governance and makes the balance between the external and internal social systems in the enterprise and likewise does it handles the AS – IS and the TO – BE state of the enterprise.

According to Hoverstadt then the performance measures have to be designed as inputs to strategy not seen as outputs.

Likewise does the governance and decision making have to be articulated throughout the organization.

Decision making can’t really be set into a particular process and can’t be organized around a linear path since there would be a need to be able to adjust to changes over time.

Enterprise Architecture and VSM

Doucet et al (2009) argues that all enterprises have an enterprise architecture regardless of how the enterprise approach it. Enterprise Architecture has in reality three levels that depends on how the enterprise acts according to Enterprise Architecture and what it can gain from Enterprise Architecture. According to Bernard (2005) Enterprise Architecture deals with both the documentation of the enterprise but it also works as a form of management (what is later defined as integrated governance which Enterprise Architecture is an important part of).

Enterprise Architecture with bringing the information to the decision makers at the right time and the right place. Op’t Land et al (2009) argues that Enterprise Architecture is giving the decision makers the proper information to executive and adopt to the changes in the environment in the enterprise.

There are many different views on what Enterprise Architecture is and the various views have been crystallized into various different frameworks that tries to catch the complexity of the enterprise into a so called meta model that can be communicated to the individuals of the enterprise.

There are many communities that practice Enterprise Architecture sees the foundation for enterprise architecture differently e.g., is Enterprise Architecture as a process (or set of processes) or is it enterprise engineering or something in between. If Enterprise Architecture is seen as a set of processes then the viable systems model can be applied in order to achieve an understanding of how each of the teams, groups and devisions of the enterprise architecture works. If the chief architect sees the concept of enterprise architecture as enterprise engineering then it is likely that the viable systems model can be used as a blue print that the organization can be designed upon.

The ideals of the VSM is to create a resilient organization, and it can be enabled through the implementation of Enterprise Architecture since it enables the executives to audit how the enterprise operates. The Viable Systems model and the concept of Enterprise Architecture has something in common in addressing the problems that the enterprise faces and attempting to establish a resilient organization that should enable the enterprise with achieving competitive advantages. From this point of view should the chief architect at least think on applying the Viable Systems Model when he or she designs the Enterprise Architecture approach.

 

Bibliography

Bernard 2005, An Introduction To Enterprise Architecture, AuthorHouse

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

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

Martin Op’t Land et al., Enterprise Architecture: Creating Value by Informed Governance (Springer, 2008).

The Foundation for Coherency Management: A Framework for Change.

Posted on by
Reply

A Framework for Organization to Embrace Coherency Management

When an organization choses to pursuit the implementation of Coherency Management then it the organization have to focus on organizational change. The idea of the organizational change is when the managers, middle managers and the employees will have to work in a different way and humans and organization culture have a tendency to be conservative and react hostile against change.

For this the Coherency Architect should focus on how create the proper form of change within the organization.

A Quick Summary of Coherency Management

Coherency Management deals with how to achieve alignment, agility and assurance through maturing the enterprise’s Enterprise Architecture. According to Doucet et al (2009) then there are three stages for an Enterprise Architecture. The first one is the form that is called the Foundation Architecture which is typically led by the IT department and sponsored through the CIO. The second stage is the so called extended enterprise architecture where both the business side and the IT-organization have adopted and applied Enterprise Architecture to expose the current situation (AS IS architecture) and is used to manage the enterprise’s strategic, business and technology elements.

The third and last stage is called the Embedded Architecture. This particular form of architecture is defined by the most employees in some way or the other work with the Enterprise Architecture. However there are two forms of Enterprise Architects. The first form is the explicit of architect of which there can be defined to dominant forms. The mature and advanced form of Enterprise Architects that are working with an established architecture office that handles the various forms of strategies to create a so called coherent overview. The other form of explicit architect are working with various sub architectures such as the business architecture, technology architecture or the solution architecture.

It is worth to mention that these three stages of architectures are supported by Herzum in his 2003 paper on the topic.

The Framework

When dealing with organizational change then the Coherency Architect needs to work with developing and internal pressure for enabling change. The question can be if the organization is loosely coupled or not. In this particular framework the assumption is that the organization (enterprise) isn’t loosely coupled.

When the organization (enterprise) isn’t a public given monopoly such as the Danish postal services then it will face competition. The competition deals with that the competitors will work for gaining market share this is done through various strategies and those enterprises that sees that they can’t make money in a particular market focuses on differentiating their products or services.

The various moments the competing enterprises makes are in a way a path to more innovation (since it emphasis the development of new products or differentiating the products e.g., make products of a better quality), and this can be defined as a part of the external pressure. It is worth mentionable that not only does the competitors add to the external pressure e.g., the government, press or other external entity. The external pressure can be an enabler for an internal pressure of which is needed to create the urge for change. Change or initiatives for change can be limited through the persistence of organizational culture (as before mentioned organizational culture tends to be rather conservative) and urge is a feeling among the actors within the organization to approve the change initiatives.

It is a preferable situation for the enterprise and the Coherency Architect would be if there can be created a synergy between the external pressure and the internal pressure. This particular synergy would be the burning platform.

When the external pressure e.g., competition, law (regulation) or other element changes in the enterprise’s domino then the Coherency Architect should work with influencing the various groups within the organization that holds some form of power. For this the Coherency Architect needs to produce valid arguments for the need for change and arguments on what to do. For this an elevator pitch can be necessary. According to Bernard (Bernard 2005) then the concept of Enterprise Architecture embraces strategy, business and technology so all of them can be aligned.

The elevator pitch could therefore be something like this “Enterprise Architecture assists in creating a coherent overview of business, strategy and technology”. The elevator pitch has to be supported through an economic and strategical estimation of the benefits that Enterprise Architecture and Coherency Management can add to the enterprise.

When done so then the Coherency Architect should establish an Enterprise Architecture group where he or another person should be appointed the Chief Architect and this person should be granted the resources, responsibilities and power needed to implement an Enterprise Architecture program. Before Coherency Management can be implemented then the organization needs to implement an Enterprise Architecture program and through the principles of Coherency Management evolve the Enterprise Architecture to more than just the “Foundation Architecture”. When establishing the Enterprise Architecture program a suitable Enterprise Architecture framework should be applied e.g., Bernard’s EA 3 Cube framework. The framework should as a documentation form and as a management form ensure that the enterprise’s current projects are investigated and if possible aligned with the strategy, business and technology goals for the Enterprise.

While the Enterprise Architecture program is established then the Coherency Architect should communicate with the sponsors

When the alignment has been established then the Coherency Management framework CoMOF framework should be adapted to the needs of the organization e.g., should issues like repositories be dealt with which leads to the example of the Modular (modular repositories) Coherency Management Framework (needless to say that the framework is based on Doucet et al. basic suggestions for a framework). When the maturing process for the Enterprise Architecture has been matured then it is important for the Coherency Management to verify and moderate the feedback channels that is the foundation of the renewing the Coherency Management and Enterprise Architecture programs and eventually the need for changes have to be implemented along side a new burning platform.

Key Issues

An Enterprise Architecture program should be enterprise – wide and therefore the Coherency Architect will have to deal with resistance to change and for that communication is vital for all the necessary stakeholders. Therefore a communication plan is needed and it has to focus on three particular issues. 1) The stakeholders don’t think like the Coherency Architect. 2) The various stakeholders needs different kinds of information. 3) The need for urgency needs to be enabled through communication and therefore should the Coherency Architect communicate the victories and the victories needs to be sequenced over the period of time one iteration takes and the communication needs to be done in a way that appeal to the feelings of the stakeholders.

Conclusion

When an Enterprise Architecture program and a Coherency Management program is about to be established then it is vital for the success of the program, that the Coherency Architect deals with the issues of pressure to establish a burning platform and then anchor an EA office or for that matter a coherency management office to the power bases in the organization. When done so communication about victories has to be prioritized and sequenced to so the stakeholders continue with their support for both the Enterprise Architecture and Coherency Management program. Since Coherency Management is based on the foundation of Enterprise Architecture then it is a necessity that the EA program is anchored first and for that the proper approach is to apply an EA framework e.g., Bernard’s Enterprise Architecture 3 Cube Framework and use the EA program to align the business and IT projects of the organization to support new or improved business processes (TO BE architecture) that are dictated by the corporate strategy.

When the EA program has been established then the usage of a Coherency Management framework needs to be implemented and the framework needs to be modified to the needs of the particular enterprise e.g., by adding multiple repositories.

When both the EA program and Coherency Management program has been established then it is vital that the Coherency Architect ensures improvement and that can be done by established and routinized channels for verification and feedback.

The need for adaption to the domain of the organization will lead to a continued demand for the establishment of a burning platform.

Sources

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

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

Herzum, P., 2003. Applying Enterprise Architecture. Cutter Consortium Executive Report, 6(3), 36.

Kotter, J.P., 2008. A Sense of Urgency, Harvard Business School Press.

Download the paper here.

The OIO-Framework: The EA Framework Designed for the Danish Public Sector.

Posted on by
Reply

The Public Sector has to take Charge of its IT Architecture

The public sector has had a sector wide view on IT investments (that includes investments in information systems and architecture) that they should focus on purchasing the cheapest and most relevant solution.

The cheapest solution has often led to that the solution has been developed with in a narrow scope. This has had an impact on the IT architecture since it has been optimized for the local department or unit. The result of this is in general not desirable since the government in 2003 articulated goals for that the architecture should be scalable and reusable.

The suppliers to the IT architecture are still in charge of developing components and implement the business logic. The public sector then have to demand a common set of standards to enhance interoperability.

The reason for the public sector should promote these demands are that the level of competition will become more intense which will be an advantage for the public sector.

The public sector has to realize that if it wants to be ahead of the suppliers and thereby gaining a competitive advantage then it should focus on developing its employees in the skills of Enterprise Architecture or IT Architecture Management.

According to John Goetze the reason for why the public sector (the ministry of Research and Science) chose to name the concept IT Architecture due to the secretary of Research and Science preferred the name “IT architecture” compared to the title “Enterprise Architecture”.

A common IT Architecture Framework

The framework focuses on coordination, a common set of methods, a common choice of methods, systems and principles, and common tools.

The common coordination deals with that the public sector should establish a committee that create the common IT architecture that public sector should mature and develop. The common frame of method is a common standard of processes, concepts and processes. The common choice of systems and principles deals with the public sector should deal with standards and infrastructure that should led to a reference profile and a Service Orientated Architecture.

The common set of tools deals with establishing common databases, libraries, contracts, description of processes, definition of data, software components including descriptions of infrastructure solutions.

Consequences

To promote the usage of IT and the be able to scale the systems across several departments, ministries, counties, communes and other public administrative sectors and institutions can make use of the stored data.

The public sector will experience that the costs for developing the IT architecture and the costs of the processes will also diminish over time.

However when the organizations within the public sector in one way or the other invests in a new information system then the specific organization has to apply specific controls and methods to ensure that the systems are designed and optimized for the specific processes (of course build the reference public reference profile).

The new repository and framework will give the public sector the benefits of organizational change and the understand of systems changes as well since they are build around the same systems and principles of management and Service Orientated Architecture. It is notable that the implementation of the IT architecture will be a hugh investment and the investment can result in big benefits and opportunities as well.

The Background for the OIO-framework

The reason and background for the development of the public IT architecture (and the OIO-framework) is to establish a foundation for Enterprise Architecture to ensure maturity in the common enterprise architecture to enhance and develop public services to citizens and customers.

The government has established a vision for what is known as digital governance & management. The vision is based on four goals (principles) that needs to be taken into consideration:

  1. The digital governance & management has to empower the citizens and corporations to the network society.

  2. The public sector has to work and communicate digitally.

  3. The public sector has to provide coherent services and products to the citizens and the corporations.

  4. The tasks in the public sector has to executed where the tasks can generate the largest benefits.

The above mentioned goals have to be translated into processes and these will be implementing over several years and with different development logic.

  1. Goal two to four deals with that the IT architecture should better public support through higher quality in the IT foundation.

  2. Support the development of innovative cross governance processes through greater coherence in the informations.

  3. Achieve a more effective governance through larger efficiency in IT usage.

  4. Gain access to rapid support of new or changed governance processes and organization changes through tested infrastructure solutions.

  5. Give access to public information through open to citizens, corporations and public institutions and authorities.

  6. Give sufficient protection of public information through secure solutions to manage and communicate data.

  7. To create more successful IT solutions through larger predictability of the results of IT investments.

  8. Give the public sector access to stabile IT systems with sufficient capacity.

Experiences that can be Crystalized from the OIO-framework

There are several other countries that have made an effort to implement IT architecture (Enterprise Architecture) and these countries have gained some experiences.

These experiences are as follows:

  1. Commitment has to be on government level.

  2. A cross government institutions and departments collaboration is needed.

  3. Standardization of data structure and functional data interfaces has to be implemented.

  4. Choice of technical standards are needed.

  5. A common infrastructural platform has to be implemented.

  6. Anchoring the knowledge and change through certifications and common shares of practice have to be implemented.

Guiding principles

The OIO-framework emphasizes 10 principles that the Coherency Architect has to take into consideration when the government of one reason or the other implements a new IT architecture:

  1. The Service Orientated Architecture is a paradigm of which the government has to invest its resources so a coherent digital governance can be applied.

  2. The prospect is that the government will take an active role in the service orientated architecture.

  3. The national common IT architecture has to be the lowest common standard that in the same time enables the ability to add to it (a kind of dogma architecture).

  4. The IT architecture should reflect the vision of the business side and there should be a consensus regarding the choices the business side has committed itself to.

  5. The national IT architecture should be applied in those cases where there is a business needs and business analysis should support the usage of the usage of the IT architecture.

  6. Legacy systems shouldn’t be scraped or for that matter be converted to run on the same platform. In the other hand none of the legacy systems should be spared in advance of the implementation.

  7. The implementation should focus pragmatic assumptions and the implementation should be done in iterations.

  8. The IT Architecture should be based on the lowest possible political foundation to ensure that those persons who know about the situation locally can take the proper responsibility and accountability for the situation and implementation.

  9. Denmark is not the only country on this planet and therefore should the work with the architecture be coordinated with international players.

  10. The work with the IT architecture and the standards should be published on a public website www.oio.dk.

The IT Architecture Process

The white book is based on two cycle processes that enriches each other while they are executing. The two processes are iterative which means that these have to be executed continuously.

Since the public sector is rather decentralized and therefore is the principles and concepts discussed in the white book based on the idea that these can be dragged down onto the various self-governing institutions and their contexts.

Strategy Process.

Strategy Development Process.

It is worth to mention that the upper circle is the strategic process and the lower circle is the implementation process.

  1. Vision and goals describes the strategic business goals and that will be with a special focus on those that are related to Information Technology. It is a necessity to keep a dialog with the top management of the enterprise and the political side of the business is a necessity as well.

  2. The Business Architecture describes those processes the IT system has to support both when it comes to functionality and procurement. This state is a result of an analysis and an optimization of existing work related processes.

  3. The Information Architecture describes the business strategy and its demands to the organization of information. This contains both the high level description and low level technical description.

  4. The Technical Architecture is based a common shared systemic description of the demands which can be categorized with the high level part of the systems and modules and the low level description of each of the modules.

  5. The Conceptual Architecture Principles is a rule set that handles the initiation of the IT solutions so these are within the demands presented in the “Conceptual Architecture Principles and former mentioned architectures”.

Besides the strategical architecture process the practical implementation process will be executed.

  1. Document the existing situation (AS – IS).

  2. The Gap analysis deals with identifying the identifying what legacy systems that fit into the conceptual architecture principles.

  3. Prioritization and planning. This phase deals with the planning the technical change that is needed to bring the “AS IS” to the desired state “TO BE”.

  4. Implementation projects deals with implementing the changes through a series of projects.

The Three Layer Model

The three layer model can be utilized and linked directly to the architecture model.

  1. The user interface layer (3-layer) that is directly linked to API & Services and Presentation.

  2. Business Logic Layer (3-layer) that is directly linked to application server, integration server and database sever.

  3. Storage Layer (3-layer) that is linked directly to server hardware and operating system, data layer, and network.

When the public sector starts the redefinition of its “Enterprise Architecture” (IT Architecture) then it should focus on to break down the known barriers and not just enabling old government procedures or processes. This means that the old processes should be supported with new technology since they often just led to the same result as the old processes and these rarely enables the true potential of the technology.

Principles

The foundation of work with IT Architecture (Enterprise Architecture) is based on the principles developed by the chief architect and the EA team.

On the lowest level of principles we find the principles that are focused on a specific system where we in the highest level is based on the idea that the entire enterprise should align their decision making with.

The principles should be build upon:

  1. Interoperability is a necessity to enable the usage of and recycle the data. However interoperability can also be viewed as a way to create coherence in new ways.

  2. Security is a paradigm and an imperative. If the system is not based on the

  3. Openness is based on the idea that the interfaces have to be open so the can ensure communication and interoperability among the systems components.

  4. Flexibility is based on the idea that the system has to be build so it would be easy to modify to the system (enterprise architecture will be suited to its surroundings).

  5. Scalability deals with how the system will be working when there is a greater demand for its features and usage.

Sources

Gotze et al, 2003, Hvidbog om IT-arkitektur, Copenhagen.

Download the blog post from here.

Implementing Enterprise Architecture: From a Coherency Architect’s Point of View!

Posted on by
Reply

Organizational Change

In most organization it has been the IT department and the Chief Information Officer (CIO) that has initiated the Enterprise Architecture program with an IT department’s focus. The IT department’s focus is often based on that the IT department wants to clarify how the organization operates (operation model) and makes use of the artifacts that it has collected through the initiating of the Enterprise Architecture program. This often leads to a business to IT alignment process where the

The Change of Focus

The IT focus can in many ways be a good approach to start with; however the IT approach only gives the organization limited possibilities with working with Enterprise Architecture since the rest of the executive team often aren’t responsible or even evaluated on how well the Enterprise Architecture program is performing. This means that they rarely will take the EA program into consideration or assist in making the EA program more successful for the organization. Therefore it can be necessary to force a change of focus.

Replacing the CIO

The necessary change might come through that the organization chooses to replace their current (and often technically minded) CIO with a new CIO that has been engaged with the business side of the organization. This often eases the communication with the executive team and not to mention the Chief Executive Officer. This will eventually bring another perspective to the Enterprise Architecture program. The EA program will go from being IT minded to be organizational minded. This will in time evolve and mature the architecture from being the foundation architecture to become the extended architecture (Doucet et al. 2009).

However then replacement of the CIO is not enough to create the new focus. The focus has to be implemented along side an organizational change program that has to focus on how achieve desired changes in order to gain a competitive advantage or advantages such as agility, assurance and alignment with the goals of the organization. Since there can be a lot of bad will (Bjorn – Andersen & Marcus 1987) towards the IT department within the organization then it is a necessity to alter the organization culture and that can often only be achieved through organizational change programs. To initiate the organizational change program then the EA board, the Coherency Architect and the Chief Architect should address the various stakeholders in the executive group where the primary focus should be to communicate the value (including strategic value) of Enterprise Architecture to them.

The Extended Architecture

The Extended Architecture is characterized by being the advanced step of Enterprise Architecture and by maturing the architecture then the organization will be able to achieve results through that through working with Enterprise Architecture in both an IT context and a business context will make the organization able to know more about its architecture (the way the organization is designed and works (operation model), When doing so then the organization will be able to commit to better governance and decision making.

The assurance through knowing the business processes and the technological platform ensures that the organization will have a chance of applying new business processes that will enable the organization to achieve a strategic advantage.

Forms of Architectures

Forms of Architectures.

Conclusion

The Coherency Architect and the EA board should communicate the value of Enterprise Architecture to the executive team. The Executive team should be working with identifying the need for change to achieve to mature the enterprise architecture from the foundation architecture to the extended architecture and communicate the ideas (and benefit of changing) to the executive team. Eventually if the CIO hasn’t been able to communicate and influence the executive team to buy in to the Enterprise Architecture program then the CIO should be replaced. The successor should be a person from the business side so the Enterprise Architecture program is able to change focus.

Sources

Markus, M.L. & Bjørn-Andersen, N., 1987. Power over users: its exercise by system professionals. Commun. ACM, 30(6), 498-504. Available at: http://portal.acm.org.esc-web.lib.cbs.dk/citation.cfm?id=214762.214764&coll=portal&dl=ACM&CFID=22716975&CFTOKEN=73079095 [Accessed February 20, 2010].

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

Download the blog post here.

Tools for Strategic Evaluation: Tools and Methods the Coherency Architect should Apply.

Posted on by
Reply

The SWOT analysis

The Coherency Architect should be making use of a SWOT-analysis to evaluate the organization (enterprise) of which he or she is working with.

The SWOT analysis is a perfect tool to evaluate an organization’s strategical options in the current situation (AS – IS) and what the organization can do to move to a new desired steady state (TO BE). Please note that in some cases technology can also be evaluated through the usage of the SWOT analysis.

It is notable that the Coherency Architect shouldn’t rely solely on the SWOT analysis since it has a tendency to overemphasize the current situation (AS – IS). The Coherency Architect should therefore focus on using other approaches and methods to support the view of the future situation for the organization. However the SWOT analysis can be a good idea to make use of initiate a strategical analysis.

SWOT stands for Strength, Weaknesses, Opportunities and Threats. Where strength and weaknesses are internal factors for the organization. Opportunities and Threats are external factors of the organization.

However in some cases opportunities that haven’t been created or applied for the organization (though the fundament can be found in the organization) can be considered an opportunity.

SWOT - analysis.

SWOT - analysis.

An Example

This organization (enterprise) is in a situation where its products are seen as a commodity by the customers and as such new players in the market has started to produce products that are of similar quality and can do almost exactly as the products as the organization produces; the products the competitors produce are often a bit cheaper do the fact that the competitors are able to gain economies of scale.

The organization (enterprise) has a home – made Enterprise Resource-planning System, a heterogeneous portfolio of 132 computers (both old and new computers of diverse brands and specifications and operating systems) and the organization has access to one server that runs an elderly Microsoft ® Based Operating System where the ERP software is hosted and the user administration is managed. The organization (enterprise) consist of 300 employees and about 25% of these have an education on college level or above. The COO has a PhD in field of process development. The last 75% o the organization consist of people who have been minded on practical educations and are as such not theoretically in their approach to solve the problems the organization faces.

The organization (enterprise) has access to a credit limit of €10 million which their bank has granted them access to if the organization needs access to external funds to finance their investments.

The Business Processes have a lot of tightly coupling and they are working through a so-called J-I-T system (Just in Time) where the organization produces their products just as many units as needed to the various retailers. This is based on an idea that the organization can save money on storage facilities. The organization is almost like a division organization as Mintzberg described it.

The organization (enterprise) has an internal IT department; however the IT department is overworked and they often spend most of their time with user support and maintenance of the elderly systems and the management of the organization do not value the inputs the IT manager gives to the CFO.

SWOT - Analysis Example

SWOT - Analysis Example

The Coherency Architect can then identify the weaknesses of the current strategical situation (AS IS) and then use the SWOT-analysis as a part of the documentation to create the overview which is needed to articulate a transition plan for the Enterprise Architecture.

Conclusion and Discussion

The SWOT-analysis can be made use of to give the Coherency Architect an overview of the enterprise’s situation (AS IS) and it can assist the Coherency Architect with creating an overview of the strategical and the tactical situation; however the SWOT-analysis should be supplemented by other models and approaches such as the Porter’s Five Forces model and Porter’s internal value chain including Robson’s IS value chain.

Both an organization (enterprise) and technology can be analyzed by applying the SWOT-analysis; though the Coherency Architect needs to take it in to consideration that the analysis method often emphasizes on the “AS IS” state and therefore be questionable to be used in relation to articulation of an transition plan.

Download the paper here.