Tag Archives: Enterprise Architecture

Enterprise Architecture is more than IT

Posted on by
Reply

This blog post is based on the guest lecture that Chris Potts performed at the course B30 Enterprise Strategy, Business and Technology at the IT University of Copenhagen the 25th of October 2010.
It is growing sense around the world that Enterprise Architecture is dealing with more than IT; however since the concept’s origin from the world of IT has often been portrayed as an IT concept, and implemented as a rather IT centric tool.
Chris Potts asked the class at the lecture: “Can you recognize this architecture (this building – showing a picture of the insides of the Sydney opera house). This is a picture from the inside of the architecture. It proved to be the Sydney opera house but it is often hard to identify buildings (architectures) from the inside but it is rather easy to identify it from the outside”.
According to Potts is the biggest difference between an Enterprise Architect and a building’s architect, and that is “a building cannot change its own architecture” but an enterprise can, and Potts views on the definition of architects in enterprises deals mainly with that all the members in the enterprise in some way are architects. When it came to the role of Enterprise Architect is to change the world. Potts made use of the quotation below.
“According to Potts then Enterprise Architecture is about changing the world into something it probably wouldn’t otherwise have been.” – Chris Potts (2010b).
The question then becomes how to challenge the status quo, and the approach doesn’t always tells people what to do. So you may have an architecture but it doesn’t tell people what it is. According to Potts then sometimes the Enterprise Architect need to risk a lot as strategist and you would need to be ruthless.
Potts is of the opinion (an opinion he shares with Mintzberg and Ross & Weill) that strategy has to be embedded into the behavior of the actors within the enterprise. When it comes to behavior then there are two different forms that needs to be dealt with. The de facto behavior and the formalized behavior. The formalized approach to behavior deals with articulating the desired behavior in work structures through formalized descriptions of what is desired into the various artifacts.
When working with Enterprise Architecture then it might be a focus to use an argument as “Enhancing Enterprise Performance With Structural Innovations”. The hard part of this is the structural innovations part. The Enterprise Architect has to force himself to become innovative in using Enterprise Architecture and innovative in ways to improve the enterprise, and to create value for the enterprise as a whole.
“The whole is greater than the sum of its parts” – Aristole
Structural performance of the enterprise architecture is a principle that needs to be dealt with. Chris Potts mentioned that many investors work with analyzing the profits and costs of the enterprise but they usually fail with understanding or investigating if the enterprise is about to collapse from within due to bad architectural design.
There are many fundamental truths according to Potts. The first one is that the structural performance of an enterprise depends on its architecture, and the second one deals with an enterprise has an architecture regardless it is formalized or not.
The third truth that any enterprise architect should adapt is that the actual shape and structure of an enterprise’s architecture is the aggregated output of all its invests in change.
The fourth principle deals with the value of the structural innovation depends on the wider architectural context and last the enterprise architecture is about scenarios not certainties.
In this context the work with the core tactics is that the chief architect should bring both the explicit and implicit enterprise architects and make them work together.
Chris Potts introduced a new framework for change called the double e, double a journey.
Establish and explorer. These two steps are private to the chief architect and the activate and apply are public to the chief architect. It simply deals with taken over the enterprise through a guiding coalition which in principle can be related to the change framework that John P. Kotter who made the famous eight steps for change program (dating back to 1995).

The Scope of Enterprise Architecture was discussed and the class reached the following conclusions:
1. Activities and Processes.
2. Boundaries.
3. People.
4. Capabilities.
5. Resources.
6. Data.
7. Information.
8. Government and governance.
9. Environment.
10. Technology.
According to Potts markets do also have architectures and this approach leads to a fundamental focus on business architecture since the business architecture can’t stand alone to the market architecture. The market architecture contains the customer experience and from this perspective the architectures needs to be aligned to the market architecture to provide what the customers want. The business architecture in the other hand deals with the virtual organization (or more or less the virtual organization) and it is directly connected to the partners and suppliers that delivers materials and services to the enterprise.
According to Potts then structural performance is the key for measuring how well the enterprise is doing Enterprise Architecture. For this a cash-flow analysis based on the annual reports from the enterprise can be applied; however it is greatly encouraged to make use of other forms of analysis to come to this particular approach e.g., activity based costing. This approach might not give a correct view of status quo of the various lines of business and therefore other key performance indicators and methods needs to be applied.
Therefore should an Enterprise Architect make use of context specific strategies for each line of business. The example that Chris Potts made use of was a bit simplified in relation to measuring the different initiatives the enterprise works with; however it is a needed technology.
Chris Potts emphasize that the politics of management and the politics of organization is of great importance when it comes to Enterprise Architecture, and if the chief architect doesn’t understand the dialectic struggle within the enterprise then it certainly will become a problem for implementing Enterprise Architecture, and according to Potts the political aspect of governance is rather often worse in the public sector than it the private sector.
The interesting part about the approach that Potts makes use of is that he actively tries to describe how a chief enterprise architect has to be able to play many roles and he has to be able to facilitate innovation and development issues within both the lines of business and enable the top management of the enterprise to govern the various lines of business. In other words he has to be able to facilitate innovation while tightening control which usually is a contradiction.

Integrated Governance

Posted on by
Reply

Is an approach to make your organization work better by creating a form of management that supports the various forms of governance and forms of planning. The literature review that you will be able to read by downloading the document from the provided link, deals with how Enterprise Architecture can enable an enterprise to achieve the vision of holistic management. Enterprise Architecture is therefore one of the major components of the paper and likewise is Coherency Management. The initial assumption is that by using Enterprise Architecture and Coherency Management that the enterprise is able to achieve competitive advantage since the executives, middle managers and employees will be able to get a better understanding of how the organization works and what it can do to align processes, resources and intelligence to achieve a sustainable competitive advantage.

The paper defines integrated governance, and introduces a framework that most enterprises will be able to make use of to implement integrated governance. It is obvious that more forms of governance can be incorporated into the framework; however since it has been an academic study, I had to delimitate what forms of governance I had to deal with (otherwise it could be a rather long paper on various forms of governance that would be more or less relevant to include).

It is notable that the enterprise needs to adapt the framework for its specific context; otherwise it is very likely that the enterprise will not be able to gain any of the benefits that integrated governance as a concept can provide the enterprise with.

One of the most important aspects of the framework is the quality assurance feedback channels that needs to be established, since this is the only official approach to collecting the data needed to understand how the changes influences the enterprise.

The findings of the paper and the paper itself is published under Creative Commons version 3 SA BY U.S. Edition. This means that you are able to make use of the paper in a commercial context and you are welcome to make derivatives as long you stay loyal to the license and you credit me (Peter Flemming Teunissen Sjoelin) as the author of the original paper.

Download the paper here

A Compendium for Understanding Enterprise Architecture.

Posted on by
Reply

I hereby publish the notes I have taken during the course in Enterprise Architecture that I have attended at the IT University of Copenhagen in the spring of 2010. The compendium is published under creative commons SA, BY, NC which means that it can be used for most purposes; however the purposes have to be non-commercial.

The notes are centered on Bernard’s EA Cube and the statement “EA = Business + Strategy+ Technology” and that has been the key organizer for how the notes are presented in the compendium.

You can download the compendium here.

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.

Bushido of the Coherency Architect: The Ways of the Coherency Architect to Efficiently Apply Suitable Solutions!

Posted on by
Reply

The Path to Improvement

The focus is to combine lean, Toyota Production System, Enterprise Architect and Coherency Management into a guide line like the Bushido: The ways of the warrior.

The main principle of Coherency Management is to implement a holistic management approach that enables the management to achieve alignment, assurance and agility.

Enterprise Architecture is the foundation of achieving Coherency Management and it is possible to combine that with efficiency to achieve an enterprise that have a lesser amount of slack and adds more value to its share holders and customers.

First of all an Enterprise Architecture program has to be established.

Second of all an economic analysis of the activities that the organization performs to get income.

Third of all communication of change needs to be performed. That means that the Chief Enterprise Architecture needs to communicate to various stakeholders. The various forms of stakeholders needs to be dealt with in different ways. The various stakeholders needs different kind of information.

Third of all the Enterprise Architect has to work with various applying a framework e.g., the EA3 Framework, TOGAF, OIO or other framework.

Forth of all the Chief Architect needs to demonstrate the value of the Enterprise Architecture. The Enterprise Architect should apply the evaluation models that give the information that the stakeholders needs to make their mind (approve or disapprove) the Enterprise Architecture program. It is necessary to apply the evaluation model for the business processes and IT processes before the EA program has been established. This is needed to compare the before and after approach.

Fifth of all the Enterprise Architect has to make use of his or her talent to deal with the persons who have to change their way of working after the Enterprise Architecture program has been established. According to Doucet et al. (Doucet et al 2009) then the organization then there are three forms of applied Enterprise Architecture. The first form is known as Foundation Architecture. The Foundation Architecture is when the organization has applied Enterprise Architecture in the IT department. The IT department has been the driver of the Enterprise Architecture and made use of it to uncover the the operational model of the Enterprise Architecture. When the organization mature the Enterprise Architecture then it should over time come to the Extended Enterprise Architecture where both the business side of the enterprise and the IT side. The IT side and the business side works uncovering the business and its processes. There are several forms of architects who have various functions and responsibilities. There will be a centralized office for Enterprise Architecture and there will be a commitment from the Executive Group1 to enhance and use Enterprise Architecture to govern the enterprise. There are business architects, process architects, technology architects information architects and the Enterprise Architects. The Enterprise Architects will be dealing with handling the overall aspects of Enterprise Architecture. The Enterprise Architects will be dealing with keeping the other architects in line with the Enterprise Architecture program.

After the Extended Enterprise Architecture level then the organization will be moving toward the Embedded Enterprise Architecture. The form of architecture is so far a kind of utopia where every employee in some way acts as an architect which leads to that there are explicit and implicit architects. Theres is a focus on a central EA department that consist of the best Enterprise Architects who works with the overall Enterprise Architecture framework and enabling the other architects with their work through empowering the framework and governance of the Enterprise Architecture.

Sixth of all the Chief Architect has to implement a Coherency Management framework so far there is only one kind of a kind. That means the CoMOF framework has to be adapted. As it is with all other frameworks then the CoMOF framework is a generic framework and it has to be modified for the particular organization. While applying the modified CoMOF framework in the organization then Coherency Architect (or Chief Architect) has to make use of the efficiency theories such as LEAN, Six Sigma or Toyota Production System. This is a necessity to improve the organization’s enterprise.

Seventh of all the Coherency Architect has to ensure that executive group continues supporting the Enterprise Architecture program and Coherency Management program. This have to be done through emphasizing the support for Enterprise Architecture by using external pressure to enable the internal pressure(groups with power) to invest resources into renewing the program. If the Enterprise Architecture program isn’t renewed then the value of the Enterprise Architecture program will lose value. The same is the case for the Coherency Management program.

Eight of all the Chief Enterprise Architect should be working for improving the channels of how the Enterprise Architecture is transforming.

The Code

The Coherency Architect should be therefore be working with being efficient, effective and use his or her experience to develop develop efficient enterprises through Enterprise Architecture.

  1. Focus has to be on efficiency and effectiveness. The ideal is that the Coherency Architect should be thinking in systems where to much slack is minimized; however enough slack to harvest the benefits of innovation.

  2. The vision of Enterprise Architecture has to be communicated to the stakeholders . The people skills and abilities to communicate fluently with people are virtues.

  3. Improving the Enterprises and their Enterprise Architectures then the Coherency Architect have to focus on influencing the organization cultures to institutionalize improvement through Enterprise Architecture.

Applying the Code

The Bushido Framework

The Bushido Framework.

The code can be applied through the model dealt with above . The path to improvement is designed around the stones n the circle. The circle represents continuity. Bernard’s EA 3 framework is located in the bottom is matured a long side the principles of the CoMOF-framework. The lines with arrows are symbolizing the maturing process and a part of the continues process.

1Top managers including CEO, CIO, CFO and COO etc.

Download the paper here.

The Enterprise Architecture Framework

Posted on by
2

The Steps of the EA approach

There are defined 20 steps to establish the EA program according to the EA 3 Cube framework (Bernard 2005). The 20 steps have different importance in the four different phases which needs to be taken into consideration.

The first and thereby primary step is the establishment of the EA program. If the EA program isn’t established the organization will experience difficulties with improving its Enterprise Architecture.

The second phase deals with how the organization should define an methodology and the tools that are compatible with the EA approach (framework). If that is not in order then the EA program will not aggregate a proper view “AS IS” perspective.

The third phase deals with how the execution of the EA documentation program.

The fourth phase deals with how the EA program should be linked to the management and other kinds of management processes so the organization can generate the full advantage of the investment in the program.

Phase 1: Establishment of the EA Program

  1. Establishment of the EA Program and identifying the EA Chief Architect.

  2. Establish of the EA Methodology.

  3. Establish EA Governance and links to other management processes.

  4. Develop an EA communication plan to ensure EA stakeholder buy in.

The EA Program needs a person in charge to apply the right framework and the right tools and the person needs to be hold responsible and accountable. This means that the top management and management of the organization needs to buy in (#4). If they don’t buy in then the EA program will easily be detoured.

The EA program needs to be linked to other management processes so they can be coordinated and when they are coordinated they can become a greater asset for the organization. When the coordination has been established and the coordination has been applied then it might turn into a competitive advantage.

Phase 2: EA Framework and Tool Selection

  1. Select an EA documentation framework.

  2. Identify the EA lines of business (LOB) and cross cuts and the order of the documentation.

  3. Identify the EA components to be documented framework – wide.

  4. Select documentation methods appropriate to the EA framework.

  5. Select the software applications or tools to support the automated Enterprise Architecture documentation.

  6. Select and establish an online EA repository for documentation and analysis.

The documentation framework is frame for how the various elements have to be put into to create a systemic analysis. The analysis have to be focusing on identifying symptoms and finding the cure for the right problems within the organization.

The Enterprise Architecture should be documented so an “AS IS” is produced and used as a blueprint so management and the EA program chief architect can articulate a transition plan that can enable the organization to achieve its goals and thereby create the “TO BE” situation for the enterprise architecture.

Phase 3: Documentation of the Enterprise Architecture

  1. Evaluate existing business and technology documentation for the use in the Enterprise Architecture.

  2. Document the current views (AS IS) of the existing components in all frameworks areas (levels). Organize and store the artifacts in an online repository.

  3. Develop future business / technology operating scenarios.

  4. Identify future planning assumptions for each future scenario.

  5. Use the scenarios and other program / staff input to drive the documentation of future EA components in all EA framework areas. Store artifacts in the online repository.

  6. Develop an EA management plan to sequence the planned changes in the Enterprise Architecture.

The business and technology documentation is needed to create the “AS IS” since the EA consist of Business, strategy and technology and acts as a kind of governance tool for the organization.

The scenarios needs to deal with a positive scenario where everything stays the same and a scenario where things change and a scenario where everything goes down the drain (worst case scenario).

Involve the the staff to assist in making the documentation since many of them probably act as SMEs (Subject Matters Experts).

The EA management program needs to be the blueprint for changes that needs to be implemented in the enterprise architecture. This means that the program will have to be broken down to projects that can change the various components (and other elements of the enterprise architecture).

Phase 4: Use and Maintain the Enterprise Architecture

  1. Use EA – documentation to support planning making.

  2. Regularly updates current and future views of the EA components, and link information in the EA repository to create high – level and detailed perspectives of Enterprise Activities and resources in the current and in the future operating environment.

  3. Maintain EA repository and related EA modeling and analysis capabilities.

  4. Release annual updates to the EA management plan.

When working with the EA framework then it should be used to assist in the planning making (the transition plan) and not to mention that the methodology needs to be in place for the transition plan.

The EA repository needs to be maintained so every stakeholder in the organization can relate to the objects and terminology in the same way.

The EA management plan needs to be updated so it is matches the changes in the domain.

Sources

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

Information Systems and Enterprise Architecture: An insight to Zachman’s Initial Ideas on his Framework.

Posted on by
Reply

Implementation of Information Systems

The development of information systems have become more complex. The development of the systems and the cost of development has to lead to that the systems can minimize the barriers (constraints of the organization system).

The complexity of the systems leads to issues that the system only adds value to the organization when it is implemented. The barriers that have been diminished by the information systems have lead to that many organizations have become more flat in their structure.

The flatness of the structure leads to decentralization. The decentralized organization will end in anarchy if the system is not build upon an architecture. Zachman deduces that the information systems architecture is related to strategy both the corporate strategy and the IT strategy.

Since it becomes of strategic importance then the enterprise has to invest more attention to the concept of the Information Systems Architecture. The meaning of an Information Systems architecture is losing its meaning without the creation of a framework (this was later known as the Enterprise Architecture framework or Zachman’s Framework).

The framework and the paper is not supposed to present a new strategy planning framework though as before mentioned the foundation for IS architecture is closely related to the concepts like IT strategy and business strategy. The Focus on Architecture The framework was in its origin based on ideas that origin from the architecture paradigm. This means that Zachman is of the idea that enterprises (organizations and companies / corporations) can learn from the thousands of years of experience. The Bubble Charts and the Process Along The first step for an architect is to draw a bubble chart. The bubble chart shows the relationships among the various components.

Thereto the bubble char indicates the shapes and the size of the building. The purpose of the bubble chart is to deal with the communication between the architect (later the Enterprise Architect) and the customers. Then the bubble chart is refined to something a bit more “serious”. This is called the “the architect’s plan” of which the contractors and the sub-contracters will draw their plans. It is notable that the plan might change several times since the estimated costs will lead to changes in the design since the cost is a constraint. This means that the chart has to include more information in a more precise sketchup. Which leads us further into the analogy. The contractor then redraws the architects plan so it fits with the perspective of the persons who are building the systems. Zachman summarizes the various design plan purposes in a table similar to this. It is worth mentioning that the “Nature or Purpose”:

Representation Nature or Purpose (architecture) Nature or Purpose (EA)

Bubble charts

Basic concept of building

Basic outline of architecture.

Architect’s drawings.

Final building to be seen by the owner.

“AS IS” or “TO BE” outlined for the decision makers.

Architect’s plans.

Final building to be seen by the designer.

Transformation plan or a more detailed view on “AS IS” and “TO BE”.

Contractor’s plans.

Final building to be seen by the contractor.

This is the IT infrastructure and the various other infrastructures.

Shop plans.

Sub – contractors designs or sub segments.

Various artifacts within the various plans and charts.

Building.

The physical building.

The transformed Enterprise (“TO BE”).

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.

Strategic Management: From the Coherency Architect’s Point of View!

Posted on by
Reply

Enterprise Architecture in Combination with Strategic Management

According to the discipline of Enterprise Architecture and Coherency Management then all organizations have an Enterprise Architecture. If an organization hasn’t an Enterprise Architecture then it isn’t able to deliver any kind of products or services.

The question then is how the organization is able to understand and later adapt the concepts of Enterprise Architecture to achieve better results and gain competitive advantage.

It is essential for the organization to gain the competitive advantage to lea the market and to survive in the long run.

According to Doucet et al. (2009) then Strategic Management and the concept of Coherency Management is from a strategic stand point a combination of Enterprise Architecture and Strategic Management. The combination of the two concepts have to result in better “alignment”, “Assurance” and “Agility”.

Alignment

Alignment is dealing with how various elements of an organization can be configured so they offer the optimal potential so value can be generated for the organization. The concept of alignment can together with the concept assurance and the concept of accuracy deliver “synergy” to the enterprise. The concept of “synergy” will be dealt with later in this blog post.

Alignment can be achieved by applying a framework (EA Approach) to understand the Enterprise Architecture.

Assurance

Assurance is dealing with the issue of control and openness. The control element deals with knowledge of that the amount of resources are committed to execute the processes and the products and services that the enterprise produces

Agility

Deals with the ability to adapt to change in the organization’s domain. E.g., new competitors, new technology, new substituting products and services. That also have implications for the internal situation for the organization e.g., what sort of technology that should be applied .

Synergy

Synergy deals with creating an effect that enables the organization to perform better by using the same amounts of components that are configured in a different way. Mintzberg quotes Ansoff for saying “He referred to it as the ’2 + 2 = 5′ effect to denote the fact the firm seeks as a product – market posture with a combined performance that is greater than the sum of its parts”. (Mintzberg 2000, p. 45).

The overall idea is to use enterprise architecture to create the foundation for synergy. If the enterprise hasn’t an established EA program then it an idea to emphasize organizational change where Kotter’s Eight Phased approach can be applied.

The reason for this is that the members of the organization might be orthodox and therefore return to the original processes and work forms.

Conclusion

Synergy can be created and enhanced by using Enterprise Architecture. The more mature an enterprise architecture becomes the better the organization will be to cope with agility, alignment and assurance. To establish this organizational change management has to be applied to ensure that the change from the old ways of doing things to the new ones for this the Kotter’s approach to organizational change.

Sources

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

Mintzberg, H., 2000. The Rise and Fall of Strategic Planning, Financial Times/ Prentice Hall.

Download the paper here.