Tag Archives: Architectures

The Architecture Crystal Ball: Predictions for 2012

I have had the opportunity to read several documents containing estimations on what the chief architects and CIOs should expect of the concept of Enterprise Architecture in 2012.

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

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

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

Frameworks and Models

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

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

Investments Planning and Governance

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

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

Technology Foresight

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

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

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

Principles, Standards and Methodology

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

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

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

Conclusion

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

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

The IGIA-Framework

During the summer of 2010 I worked with a literature review that basically dealt with how Enterprise Architecture (through Coherency Management) could be addressing the issue of rewiring the form of leadership which exists in the enterprise.

The IGIA-Framework is a form of synthesis of various theories within the field of corporate governance, IT strategy, IT governance, Workforce planning, Enterprise Architecture and Coherency Management.

The edition of the framework that is released with this blog post is advocating a big bang change approach which demands a lot of resources and a long term commitment. This will be altered with the next edition of the framework which I plan to release during 2011.

The IGIA-Framework needs to address the short turn achievements while using Enterprise Architecture and Coherency Management, and for that reason should the IGIA-Framework be evaluated and developed into a framework that can enable enterprises with gaining a better form of leadership, structure, architecture and not to forget a chance to achieve a sustainable competitive advantage.

With these words I publish “Integrated Governance: A Way to Achieve Competitive Advantage” the certified edition.

Download the literature review / IGIA – Framework here

The Foundation for Coherency Management: A Framework for Change.

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.

Artifacts: The Items the Enterprise Architect has to Identify.

Enterprise Architecture Artifact

First of all we need a definition of what an EA artifacts is. Scott A. Bernard defines “an EA artifact as a documentation product, such as a text document, diagram, spreadsheet, briefing slides, or video clip” (Bernard 2004, p. 111).

Please note that the EA artifact documents the EA component. An EA component is in the Enterprise Architecture components are those elements that are owned by Lines of Business. The components can be shared (cross cuts) or the component can be shared a cross various levels (this is with in the EA3 Framework).

Various Forms of Artifacts

There are various forms of artifacts in the EA 3 framework. Combined with the Cube to illustrate what kind of artifacts than can be identified at the five levels of the cube.

The first (and highest level) is the layer titled “Goals and Initiatives” deals with documents and diagrams dealing with mission statement, overall strategy (corporate and IT strategy), purpose of the organization. E.g., SWOT analysis, Porter’s Five Forces analysis, competitive strategy, Concept of Operations.

The second (and second highest level) is the layer titled “Products and Services” deals with the business plans, swim lane diagrams, business cases (for investment in new business and IT projects), use case diagrams and node connectivity diagrams among other stuff.

The third (and third highest level) is the layer titled “Data and Information” deals with identifying the knowledge management plan, the information exchange matrix, objects state – transition diagram, logical data model, data dictionary / object library.

The fourth (and fourth highest level) is the layer titled “Systems and Applications”that deals with identifying systems interface diagram, systems communication diagram, systems interface matrix, system data flow diagram, system or operations matrix, systems data exchange matrix, systems evolution diagram and web application diagram.

The fifth (and fifth highest level) is the layer titled “Network and Infrastructure” deals with identifying artifacts like network connectivity diagram, network inventory, capital equipment inventory, building blueprints, network center diagram, cable plant diagram and the rack elevation diagram.

The EA3 Cube.
The EA3 Cube.

Acquiring the Artifacts

When the Enterprise Architect or for that matter the Coherency Architect have to acquire information on the various layers in the EA3 Cube.

The Enterprise Architect has to go to the CIO or other members of the executive group who the Enterprise Architect assumes have access to the corporate strategy and the IT strategy. However many organizations there aren’t isn’t an IT strategy or for that matter an explicit up to date the corporate strategy. Most of that information that all in all can be combined into a functional strategy.

In such cases the Enterprise Architect has to go an interview the stakeholders. However the Enterprise Architect should expect that he or she hasn’t unlimited resources to investigate and uncover the strategies (level 1). He or she should therefore try to focus on the stakeholders that can give them the greatest amount of value through the uncovering process.

The persons or stakeholders should be set into a matrix where the axis should be aligned around importance and impact on the uncovering process.

Importance - Contribution Matrix.
Importance - Contribution Matrix.

When the various stakeholders have been identified then those actors and stakeholders who are in the upper right quadrant should be interviewed. If it is possible then those persons who are in the lower right quadrant should be engaged as well however only as second or third priority.

When interviewing the executive group the Enterprise Architect should focus on applying techniques that enables the interview victims on expressing what they mean by illustrating the strategy e.g., rich pictures, flow charts, concept of operations diagrams etc.

The interview technique could be applied on the other levels in the EA 3 Cube. Likewise can the various managers and employees be categorized in the matrix and likewise should the Enterprise Architect focus on maximizing the values of his work through interviewing those persons who have contributes the most and who are most important to the data collection.

Conclusion

The Chief Enterprise Architecture should work with identify the proper stakeholders and make use of interview techniques to collect the necessary artifacts they need to create the “AS IS” view of the Enterprise Architecture. All organizations faces the conflict of resource shortage which means that the executives needs to prioritize their actions to create maximum value and that includes the way the Chief Enterprise Architect and the Enterprise Architects should handle.

Download the paper here.

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

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

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

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.

Coherency Management and Innovation

When it comes to innovation then coherency management is an enabling tool. This means that the organization that is aware of the various processes, the various elements and various technologies enables the  apply radical innovation and evolutionary innovation.
Schumpeter was of the idea that the single most important function of the organization was to crystalize the innovation in to products that could be used on the market and therefore can innovation be viewed as specific competitive advantage.
When it comes to coherency management then innovation can both be radical innovation and it can be process innovation.
The difference between radical innovation and evolutionary innovation is that radical innovation is game changing e.g., by creating new business models or new ways to do business. Process innovation is different in the way that the issues e.g., the processes are improved over multiple steps.
Both forms of innovation have their impact on how the organization performs e.g., organizations that have a well developed culture based upon evolutionary innovation often have the ability to perform well within their industry they operate.
Organizations that are able to enable radical innovation are often good to define new products, business models and markets that all in all give them a competitive advantage and thereby they are often able to be the first movers at many markets.

Innovation and Coherency Management
Innovation

To sparkle innovation there is a need for using the right people for the right positions within the project organization.
Tom Kelley is of the opinion that these profiles should be combined to create HOT teams that truly creates innovations:

  1. The Visionary is the type of person who is able to identify future possibilities (visions) and he is able to recruit the project team.
  2. The Troubleshooter is a person who in way or the other who are able to identify problems internally in the organization and is able to handle all situations that might occur in the project organization while the project is being executed.
  3. The Iconoclast is a person who is able to challenge the current believes of what is right inside the project organization and is able to see possibilities in other paradigms.
  4. The Pulse Taker is a person who is able to work like a hearth does in a human. The person has to be versatile in his or her way of thinking and is able to channelize the “life blood” of the project on to other individuals in the project organization.
  5. The Craftsman is that kind of person who is able to construct prototypes and work around with them to make innovative designs. These competences are vital for any kind of radical innovation.
  6. The Technologist is what many people would call a geek. A person who is dedicated to work with technology and is able to handle complex tasks, uncover and create deeper meaning.
  7. The Entrepreneur is a person who is able to work out with brainstorms, innovation, prototypes and communicate these to other persons.
  8. The Cross-Dresser these kinds of persons who have studied or worked with a totally different form of field then he or she works with today. These individuals make use of their skills to envision new solutions.

This leads to the concept of the maturity of the architectures and thereby the concept of Coherency Management.

The Concept of Coherency Management

Coherency Management deals with the maturing process of the architecture within the organization. The architecture consist of the various layers of the organization which are:

  1. People.
  2. Organization culture.
  3. Organization structure.
  4. Bureaucratic structure.
  5. Process structure.
  6. Information structure.
  7. Technology structure.

The more matured the architecture of the organization is the better the organization will be come to understand the processes, people, information and technology needed to create both evolutionary innovation and radical innovation.
Every organization has an architecture otherwise they wouldn’t be able to operate but there are three forms of architectures. The first architecture is called an architecture before Enterprise Architecture tools were applied and the organization is not aware of how it operates.
The more mature form of the architecture is called the foundation architecture. The foundation architecture is characterized by that the organization has applied Enterprise Architecture tools to the IT side of the organization. The first level of maturity with in this mode of architecture is where the IT structure and information structure is articulated for the enterprise wide perspective.
The second level of the architecture is when the needs of the business is articulated in a methodical way.
The third level of maturity is known by that the business side of the organization makes use of EA tools to identify, analyze and engineer the processes and structures after a methodical approach and after the change process has ended then the CIO takes over and apply the IT perspective.
The fourth and last maturity level for any organization is called the embedded architecture. This form of architecture is characterized by that all processes are aligned and by that there is a great need for design leadership. The design leadership has to create a framework for how the documentation and plans are to be designed. The other elements of the organization such as the Human Resources, annual planning, strategic planning, public reporting makes use of the structured framework and tools of the EA not to mention the that the strategic goal of the business drives the business requirements a and by that  drive the technological solutions.

Sources

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

Tom Kelley and Jonathan Littman, The Art of Innovation: Lessons in Creativity from IDEO, America’s Leading Design Firm, 1st ed. (Broadway Business, 2001).