EA - Enabler of Organizational Change and Agility

This being the last week of blogging for the EA 872 course, I would like to reflect on a topic that goes back to the basics of why should organizations adopt EA. Out of the manifold benefits offered by EA, organizational agility has been one of them, perceived either as a direct or indirect benefit. The development and use of EA helps to achieve business-IT alignment which in turns contributes to organizational agility.

Achieving organizational agility and business-IT alignment remain the top management concerns. An agile organization is the one that has the ability to quickly and effectively respond to the demands of change while continually delivering high performance. One of the blogs of the Open Group, the writer says that - "Enterprise Architecture is good, but when we make it agile to embrace change, it is great". This is analogous to the ideas in the book 'Good to Great' by Jim Collins. Being nimble or agile to the adoption of organizational changes is a factor that distinguishes an organization and provides a competitive edge in the industry. The figure below depicts an Agile Enterprise Architecture.

It begins with analyzing the organization based on its current and future states and developing a rough initial architectural plan. Then it proceeds to communicating with the stakeholders, discussing the plan to achieve the future state and based on the feedback received from the stakeholders, updating the architectural model and then going back to the project teams to develop the solutions. We can see that the processes of stakeholder communication, updating the architecture and developing solutions are done repeatedly until the final state is achieved. Thus, in order to be agile, the tasks need to be broken down and executed in an incremental and iterative fashion. Also, a conscious efforts needs to be made to achieve the architectural state, hence it is intentional and emergent. A few points from Open Group's blog to achieve an agile EA are:

1. Build a strong foundation (to avoid going back and changing the basic model every time)

2. Establish an implementation strategy

3. Adopt a layered approach

4. Practice Change continually.

Now that we are talking about effectively handling change in an organization, the leaders and C-suite members are the ones leading the change. Bringing about change in an organization is definitely not an easy task, be it in the area of EA, business processes or the people. So, it is important for the organizational leaders to deeply understand the change and their effects on the overall organizational culture. Here are six points that stand for 'The Six secrets of Change' by Michael Fullan. 

1. Love your employees

2. Connect peers with a purpose

3. Capacity building prevails

4. learning is the work

5. Transparency rules

6. Systems Learn

The author states that "The theory of the six secrets can be used to create action plans to stimulate appropriate and effective organizational change." So, while trying to adopt agility, organizations primarily must embrace change and knowing the implied meanings of these six secrets will help make the transformation smoother.

References:

Agile Enterprise Architecture - A Good to Great Evolution. Retrieved from https://blog.opengroup.org/2015/04/27/agile-enterprise-architecture-a-good-to-great-evolution/

Fullan, M. (2011). The six secrets of change: What the best leaders do to help their organizations survive and thrive. John Wiley & Sons

Information Technology (IT) Planning & Strategy

This week's readings were on Information Technology (IT) Strategy. The Gartner glossary defines IT strategy as “the discipline that defines how IT will be used to help businesses win in their chosen business context.” It deals with effective planning and deployment of IT resources in alignment with the business strategy of the organization. IT is about empowering business and getting the organizational activities done quickly and with ease. Hence effective IT planning is necessary for improved agility and efficiency in an enterprise.

Technology innovation these days has become the distinguishing factor that provides the edge among competing organizations. The faster an organization adopts technology best practices and latest innovations, the further ahead is the organization. This makes it important to plan IT implementation and develop an effective IT strategy. Technology is the enabler to achieve the vision and goals of an organization. So, not only is necessary to have an IT strategy, but also it is equally important to develop a strong one.

The figure above shows Gartner's model on IT strategy planning. Three main aspects must be defined:

1. Demand

2. Control

3. Supply
'Demand' refers to the underlying business motive and needs to which IT resources must be aligned to such as the business context, defining capabilities etc.

'Control' defines the decision making to satisfy the demands. Hence, it includes the IT principles, governance and metrics

'Supply' involves efficiently managing and reusing IT services to achieve the goals. It also includes human resources management, deciding on IT sourcing and enabling EA to support capabilities.

In addition, the IT strategy includes identification of the risks and threats and ways to mitigate them. It also involves discussion on the current state and the ways to achieve the future state. A detailed migration plan is also included. A good way to represent these aspects is use a matrix representation. The enterprise business Strategies, the Change Requirements, IT Strategies and Initiatives must be decided. They can be shown in the matrix form:

- Business Strategies to Change Requirements and IT Strategies Matrix 

- Business Strategies to Change Requirements and Initiatives Matrix

This gives a clear view of the important factors involved in planning. These diagrams are useful because they help model the contribution of IT towards achieving the business goals.

References:

Bank XYZ IT Strategy Document. Gartner. Retrieved from http://online.ist.psu.edu/sites/ea872fusco/files/eaimprovesitsynergy.pdf

Schulte, A. (2014, March 28). IT Strategic Planning Key Initiative Overview (ID: G00262933). Retrieved from Gartner database.

EA Measurement

The topic assigned for this week is EA measurement. This involves trying to find out the effective of the EA implementation and the value that it has brought to the organization. It is not an easy task to demonstrate the value of EA in terms of accurate numerical metrics. One of the reasons being that a lot of factors (benefits, costs, risks) in the overall EA implementation program need to be considered while measuring the benefits offered by EA. Gathering all of such information in a timely manner is very tedious. At the same time, without proper means of measurement, it is not possible to assess the value of EA. So, it is of utmost importance to chalk out a good measurement program that addresses all possibles areas of EA adoption and projects the best possible outcome of EA.

As per Gartner, the EA Measurement program consists of the following stages:

1. Planning — mapping measurements to strategies

2. Assessing the organization — comparing capabilities with goals

3. Designing and identifying effective measures

4. Building the measurement process

5. Implementing and measure

6. Communicating appropriate results to appropriate stakeholders

7. Reviewing, changing and improving performance

The first two stages fall under scoping of the measurement program. It is about pre-planning and setting the stage for a good measurement program. It involves understanding and analysis of the various factors involved and collecting information about them. It might also involve going through historical data to get a better hold of the progress made by EA. The next stage is a thorough assessment of the organization based on the information gathered in the planning stage. It involves understanding the current state of the organization.

The third and fourth stages involve defining what and how to measure. It is the designing phase of the measurement program. The measurement matrix is used to test the quality of the EA program by defining the assessment areas (EA value areas) and different measurement categories (like balanced scorecard). Once all possible measures have been drawn out, the next task is to select the measures based on the strategy of the organization and deliver them.

The last three stages are the actual implementation part. The measures shortlisted in the preceding stages need to be finally implemented and also communicated to all the stakeholders. This needs to be done in a coordinated way. And then comes repeating these steps in an iterative fashion - review, change, improve. This helps to further refine the measures and align them with organizational goals. This requires strong support from the leadership team as well as the EA team.

So, we can very clearly that EA measurement is no doubt a complex process and involves a lot of planning and designing for it to be successful. It needs to be dynamic and resilient, and change as the needs and goals of the organization change. This is very important for the continuous growth and improvement of the organization.

References:

Weiss, D. (2006, September 13). Enterprise Architecture Measurement Program, Part 1: Scoping (ID: G00142314). Retrieved from Gartner database.

Weiss, D. (2006, September 13). Enterprise Architecture Measurement Program, Part 2: Defining What and How to Measure (ID: G00142387). Retrieved from Gartner database.

Weiss, D. (2006, September 13). Enterprise Architecture Measurement Program, Part 3: Implementing (ID: G00142355). Retrieved from Gartner database.

Leveraging Governance to sustain EA efforts

For this week's blog post, I will be reflecting on a white paper of Oracle Consulting on the topic of leveraging the governance methodology to support and improve EA efforts, especially in the area of technology innovation. A very important point is stated in the words - "Neither the importance nor the tedium of EA governance can be overstated". EA governance is considered to be a double edged sword offering the advantage of standardization of business processes but at the same time posing the disadvantage of being an overhead to the functioning of an organization.

This article is focused on the importance of governance in the context of new technology adoption and innovation in organizations. It discusses five major advances in technology:
1. Service-Oriented Architecture (SOA)
2. Mobile Computing and Bring Your Own Device (BYOD)
3. Cloud Computing
4. Big Data
5. Consumerization of IT (CoIT)
The article highlights the governance areas that each of these technologies must focus on. Moving further, it suggests the characteristics that an effective governance methodology should have in order to meet new and dynamic IT/Business models.

Regarding SOA adoption, the articles stresses on having a separate SOA governance to get the expected ROI from SOA. The governance must include defining where in the SDLC would service development and reuse come into picture, effective internal communication channels, approval processes etc. Without a good SOA governance, it is hard to receive the full benefit of SOA implementation.
For Mobile Computing and BYOD, the main idea of governance would be around data ownership. With the use of smartphones and other personal devices to work on organizational data, ownership of data is a big issue to be concerned about. It is also important to think about data security and data access in this case.
With more and more organization making the move to the cloud, governance plays a big role here. Governance needs to be addressed based on six major factors - Standardization, Data ownership, Data Location, Availability, Service Request Handling and Procurement Authority.
With the big data explosion and big data technology adoption, the need here is to have a solid architectural plan along with a master data management plan. It is an extension of data governance. Data stewardship and data ownership are important factors to be considered.
The consumerization of IT also has governance needs similar to BYOD in terms of device management and maintaining security.

With the overview of the need for efficient governance, the article highlights the various characteristics of governance - the importance of EA governance, organization-specific governance, Just enough, Just in time, Socialization and Communication and Process Integration. The article provided a good overview of the importance of governance in an organization adopting EA. The organization must maintain a good balance of governance required and agility needed to keep up with the competition.

References:
Oracle Consulting.(2012). Leveraging Governance to Sustain Enterprise Architecture Efforts. (White Paper) Retrieved from http://www.oracle.com/technetwork/issue-archive/2013/13-jan/1697085

Effective EA Governance

In general, governance is necessary anywhere there is a team setting, wherein a group of people interact and work with each other to accomplish tasks. Be it an informal setting of a household or a formal setting of corporate organizations or government bodies, governance has a major role in the smooth functioning of the processes. The Business Dictionary defines governance as - "Establishment of policies, and continuous monitoring of their proper implementation, by the members of the governing body of an organization." This definition in the context of EA is that, "A governance body must be established to make final decisions regarding the approval of new or modified EA content. Gartner refers to this entity as the architecture review board (ARB).”

In the assigned readings for this week, the Gartner toolkit that defines the five steps to effective EA governance is of specific interest to me. It states that EA governance is different from corporate and IT governance because of the strategic nature of EA. EA governance contributes to both corporate and IT governance to help the organization align to and meet the strategic goals. IT governance, on the other hand is more operational. It cannot understand the business needs unless EA governance comes into picture and monitors that IT governance works on supporting the business strategy.

The five steps outlined by Gartner for effective EA governance are as below:
Step 1: Incorporate IT and Corporate Governance Principles
Both IT and Corportate Governance principles need to be assessed for a good EA governance. It helps to guage how much of support from the EA end is required for IT and Corporate governance. Some organizations are focussed more on the IT and have a much stronger IT governance. It is necessary to strike a balance between the two, so as to enable an effective EA governance.
Step 2: Identify your EA Archetype to Guide EA Governance
The EA archetype can be identified with the help of the following figure. It is based on the scope and focus of the organization.

Step 3: Identify your organizational culture
Gartner defines the culture of an organization as "a collection of attitudes, experiences, beliefs and values that is shared by people or groups, and that influences the way they behave with each other and with stakeholders outside the organization." It is a tough task for the enterprise architects to identify the culture because of its evolving and changing nature.
Step 4: Identify your Governance Style
Governance style refers to the way in which decisions are made in an organization. The well-known governance styles can be categorized as:
- Business Monarchy
- IT Monarchy
- Feudal
- Federal
- Duopoly
- Anarchy
- Blended
Step 5: Match your Governance Style with your EA Approach
The EA approach - traditional, federated, middle out, managed diversity or blended needs to be in sync with the governance style. The decisions to be made are identified and then mapped to the governance style in order to develop an EA Governance framework. This is a very time consuming task as it involves communicating with people from different teams before arriving at a consensus.

These five steps take into account a number of considerations identified by Gartner towards designing an efficient EA Governance framework. This will definitely help organizations get started with EA governance.



References:
Toolkit: Five Steps For Defining Effective EA Governance, Gartner. Retrieved from http://online.ist.psu.edu/sites/ea872fusco/files/5stepsforgovernance.ppt

Fusco, D. (2016). EA Governance. Retrieved from https://psu.instructure.com/courses/1772174/assignments/8524422?module_item_id=20641324

EA Roadmaps - Way to the future-state architecture

The readings for this week are based on three topics - Gap Analysis, Migration plans and EA roadmaps. These topics are closely related to each other. The gap analysis involves finding out gaps or differences between the current and future state of EA implementation. Once the gaps are identified, the next step is the migration plan that addresses the initiatives that will be undertaken to close the gaps and move from the as-is to the to-be EA states. And, all of these activities are charted out in a document called as an EA roadmap.

As per Gartner, "An enterprise architecture (EA) road map is a planning document that lays out activities or changes over time, and often highlights the inter-dependencies between these streams of activity that convey an organization from a current state to a desired future state." This is a very important document to improve communication with the stakeholders. The EA roadmap is focused on just the 'what' part and not the 'why' part i.e. it just outlines the activities that lead an organization from its current to its future architecture state and does not document the reasons for incorporating the specific activities.

Gartner defines two kinds of roadmaps:
1. Conceptual, asset-change-focused road maps
2. Conceptual, project-timing-focused road maps
Both these roadmaps are conceptual but address different aspects of EA implementation.

The asset-change-focused roadmaps outline the list of infrastructure and solution changes in an organization from its current to its future state journey. The assets could be in any of the EA viewpoints business, technology, information or solutions architecture. It outlines what changes will take place in the future.
The project-timing-focused roadmaps are also typically the same as the asset-change roadmaps. Just that the assets/infrastructure is replaced by the projects. The progress of projects is shown over a period of time.
Both these views of roadmaps - asset and project are extremely important to the stakeholders.
There are implementation roadmaps as well which are much more detailed than the conceptual ones and which also incorporate the 'why' i.e. reasons for the various activities enlisted in the change from current to the future state.

In nut shell, roadmaps are concise documents that include graphical representations to enable an easier understanding. They basically contain the steps needed to close the gap between the current and future states. They also aid in describing the EA vision.

References:

Weiss, D., Robertson, B. (2006, September 25). Enterprise Architecture Road Maps: Closing the Gap to the Future State (ID: G00140082). Retrieved from Gartner database.

Weiss, D., Robertson, B. (2007, February 26). Use Road Maps to Chart a Course to the Future-State Architecture (ID: G00146266). Retrieved from Gartner database.

Current State documentation - Identify redundant applications

I would like to reflect on one of the Gartner articles that I read this week - 'Use Enterprise Architecture to Control Overlapping Applications'. This article provides six iterative steps (shown in the figure below) that can help reduce redundancy among applications.

The process begins with identifying the various high-level business processes in the organization. High-level in the sense, the important functions performed in the organization that summarize the overall functioning of the enterprise. These business processes are further broken down into smaller or granular business functions in order to fine tune the usage of applications in each area. Next step is to select one business function and deeply analyze the applications that are used and the data handled under it. This is nothing but mapping of applications to the low level business functions. Once, the applications are found, it is easier to identify redundancies in their use. Next, the application that is useful is identified for reuse and the ones that are not required are identified and their future use/scope is limited. This process is repeated in an iterative fashion for the various selected business functions for the short-listed business processes. These processes span through the different EA viewpoints - business architecture, information architecture and solutions architecture.

By performing these steps, the future state architecture of the enterprise is designed by considering the current state and documenting the same. Identifying reusable applications based on the business functions selected is a part of the current state documentation. Limiting the future use of the redundant applications is a part of the future-state planning. Thus, the article stresses on the fact that although it is not possible to eliminate overlap of functionalities due to the existence of legacy applications, the adherence to these six iterative steps will lead to reduction in functionality overlap and help to plan the future state effectively. 

References:

James, G. A. (2005, October 25). Use Enterprise Architecture to Control Overlapping Applications (ID: G00131279). Retrieved from Gartner database.

Data Stewardship

This week we worked on our second group assignment. It was based on the future state architecture of one of the leading financial corporations which is still in the nascent stage of EA adoption. Based on our discussion, we decided on the topic of the move of the company to Big data and cloud platforms as the focus of the future state architecture and developed the relevant documents based on out of this.

I decided to work on the data stewardship requirements document. As I went deeper into knowing more about this topic, I realized how important it is for all organizations to manage their data efficiently. It is for this purpose, that data stewards are appointed. The definition of data stewardship as in TechTarget is that “Data stewardship is the management and oversight of an organization's data assets to help provide business users with high-quality data that is easily accessible in a consistent manner”. Data is considered as an asset to the organization which when analyzed can produce meaningful results leading to the overall growth and achievement of competitive edge in the industry. Also, with the adoption of of big data and cloud technologies, data is more distributed in nature. Hence, having a centralized control/rules over data use and distribution becomes vital for improving and maintaining the quality of data.

Data stewardship is about the accountability, responsibility and ownership of data. It does not deal much with the data protection aspect. It is very similar to the RACI matrix for data but rather provides more details on understanding how to deal with data for each application and line of business. To record all these details, every organization must have the data stewardship requirements document. This document mainly consists of the following:
1. Purpose
2. Authority
3. Definitions
4. Requirements of a System of Record

Organizations much think through these points and lay down strong policies and guidelines that need to be followed when dealing with data.

One of the Gartner articles states that, data stewards are critical components of an organization to improve and maintain data quality. Hence, it is very important to select the right individuals for this role. This role demands collaboration and clear understanding of the data flows before deciding on the data rules and regulations.

References:
Friedman, T. (2007, December 3). Best Practices for Data Stewardship (ID: G00153470). Retrieved from https://www.gartner.com/doc/554646/best-practices-data-stewardship

Fusco, D. (2016). Data Stewardship Requirements. Retrieved from https://psu.instructure.com/courses/1772174/pages/l04-future-state-architecture-implementation-level?module_item_id=20641314

Schlier, F. W. (2007, April 30). Toolkit: Bank XYZ Data Stewardship (ID: G00146507). Retrieved from Gartner database

TechTarget. (2013, June). Retrieved from data stewardship: http://searchdatamanagement.techtarget.com/definition/data-stewardship

ETA - Enterprise Technology Architecture

In the readings for this week on Future State Architecture - Implementation and Logical levels, a lot of attention is being given to the Enterprise Technology Architecture (ETA) viewpoint of EA. So, I thought of trying to dig deeper into this topic.

As defined in the Gartner IT glossary, "The enterprise technology architecture (ETA) viewpoint defines reusable standards, guidelines, individual parts and configurations that are technology-related (technical domains). ETA defines how these should be reused to provide infrastructure services via technical domains."
This definition stresses on identifying reusable technical components so as to use them to optimize the individual business solutions and overall whole of an organizations. The main goal of ETA is to provide a structure and set of models for all technology that supports various business applications and solutions. In order to explain this in a better way, Gartner has developed a sample ETA template for Bank XYZ. It consists of five major dimensions:
1. Pattern
2. Domains
3. Services
4. Components
5. Products
These components are related to each other and together make up the technology viewpoint of EA.
The audience for this document includes the chief architect, the EA core team, IT infrastructure director, IT system security director and application development director.

Gartner has also identified five key best practices for the ETA implementation.
1. Make following technical architecture standards easy.
2. Connect the technical architecture back to the business vision and strategy.
3. Get involved in projects early and often.
4. Provide a road map for progress toward the future-state ETA.
5. Focus on communication and education.

These best practices focus on the very basics and re-iterate the importance of keeping things simple and avoid complicating unnecessarily. One of the most important points mentioned here is the idea of connecting the technical architecture back into the business strategy and goals. This is the purpose that EA strives to achieve - Business alignment with the aid of technology. Another point of having a clear road map is also of great significance. Because, along with defining the standards and principles of future-state architecture, the ETA team also needs to define how to get to this future-state. Lastly, at every point in this process, the most significant aspect is communication! Conveying decisions, processes and educating the team about the value and benefits of the ETA will prove to be extremely beneficial in the long run.
I think these best practices are very well researched  and apt. They provide a good blend of the technicalities as well as the soft skills of communication and education required in an organization. Adhering to them will definitely guarantee good ETA implementation.

References:

Robertson, B. (2009, January 29). Five Best Practices for Enterprise Technology
Architecture (ID: G00164948). Retrieved from Gartner database.

Retrieved from https://psu.instructure.com/courses/1772174/pages/l05-future-state-architecture-implementation-level?module_item_id=20641318

Conceptual level of Future State Architecture

From this week on, our class begins to focus on the Future State Enterprise Architecture. We are going to be looking at this future state from two different angles - the conceptual level and implementation level. This blog is about the conceptual level of defining and understanding future state architecture.

The conceptual picture stresses on identifying the various concepts and constructs that help to better understand the future state or to-be state of EA in an organization. The main components here are:
1. Conceptual Principles
2. Conceptual Process Patterns
3. Conceptual Process Topology
4. Conceptual Information Pattern
5. Conceptual Application Architecture
6. Enterprise Technical Architecture Domain Definitions
7. Data Stewardship Requirements
8. Enterprise Technical Architecture Service Definitions

I would like to stress on the Conceptual Principles topic. The conceptual principles help to break down the high-level details into more finer or granular level details. Gartner has provided a sample Conceptual Principles Worksheet for Bank XYZ. The conceptual principles revolve around the three basic viewpoints of EA - Information, Technology and Business viewpoints and how these viewpoints interact with the Architecture principles. The Architecture principles are laid down by the core EA team which form the crux of the EA implementation. A matrix of these principles is constructed which provides an organized perspective to the EA viewpoints and also help in tracing it back to the business strategy.
The other components mentioned above are also based on the same fact - trying to break down high level ideas into micro level ideas.

Now, that the future state architecture is being discussed, one thing that I would like to bring up is the amount of exposure to the current state architecture. One of Gartner's articles (Enterprise Architecture Program Pitfalls: Don't Start With the Current State) mentions that spending more time on the current state architecture is one of the major pitfalls of EA implementation. The article states that "EA is primarily about what the business needs to change, not about what already exists." Hence, it is better to just analyze the current state architecture and not create an inventory from it. As it is always believed, EA is all about change and focusing on the current-state inventory first gives an impression of being resistant to change rather than being agile.

References:

Burke, B., Papegaaij, B. & Guevara, D. (2011, January 11). Enterprise Architecture Program Pitfalls: Don't Start With the Current State (ID: G00210232). Retrieved from Gartner database.

Retrieved from https://psu.instructure.com/courses/1772174/pages/l04-future-state-architecture-implementation-level

EA and operating models

This week revolves around the topic - Understanding Business Context. In order to set a clear business context it is necessary to understand the core business functions. It is here that the operating model comes into picture. It is vital for every company implementing EA to have an operating model. The author of the book - Enterprise as a Strategy defines an operating model as - "An operating model is the necessary level of business process integration and standardization
for delivering goods and services to customers." Operating models provide a clear vision of the business strategy and lays the path in which the company wants to make progress in. Integration and standardization are the key terms here called as the 'key dimensions' of an operating model. Both of them are defined in the context of business processes in an organization. It is the business processes that constitute the core of an organization.

Integration - Combining or sharing information/data across the various business units in order to create a unified face of the organization.

Standardization - Put down a clear layout of the various business processes in the organization in order to reduce ambiguity.

These two features are very important because they are responsible for improving the overall performance and efficiency of the organization by increasing throughput, improving coordination and imbibing agility.

Based on these two factors, the author has devised four types of models:
1. Diversification (low standardization, low integration)
2. Coordination (low standardization, high integration)
3. Replication (high standardization, low integration)
4. Unification (high standardization, high integration)

Out of the four, I think organizations must aim at having the Unification type of operating model as it emphasizes on having high levels of standardization and integration. The heart of this model is managing all the operations centrally. The operations include IT functions, governance decisions and management processes. By having a central control on the functioning of the organization, the key dimensions can be achieved. However, achieving a centralized control is easier said than done. Integrating and standardizing data from disparate areas of business is a cumbersome task. Also, adoption of an operating model also depends on the nature of the organization. Having a centralized operation may not be beneficial to all organizations. This makes it important for organizations to put in a lot of thought in devising a good operating model. Once established, the operating model is going to show the plan that needs to be adhered to.

References:
Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business Press.

EA Charter - The first step towards EA implementation

In this blog, I would like to discuss about one of the EA deliverables that I worked on for the group assignment. It was the EA Program Charter. The word charter can be defined as a plan or agreement of functions of an institution, could be a school, college or a company. Very similar to this idea is the EA program charter which serves as a document that contains the goals and objectives of the EA implementation of an organization. 

When I started going through the charter template in detail, I realized that it contains the crux of the EA process. This enables to have a holistic view of the direction in which the organization needs to move in to achieve the future-state (i.e. realize the goals). 

The charter outlines the following important aspects of EA implementation:

      1) Preface (Endorsement, Intent, Alignment, Focus)

      2) Scope

      3) Objectives & Metrics

      4) Governance

      5) Roles & Responsibilities

      6) Deliverables

With all these details in one document, the charter enables to have a very concise view of EA and also keeping all the functionalities documented. In case of conflicts, this document can always be referred back to gain clarity. Hence, it is very important to devote good amount of time discussing with the EA committee about the outline of EA design for the organization before documenting the same in the charter. The EA program charter also represents the agreement between the EA team and the stakeholders of the organization. With all such dependencies on the EA program charter, it definitely has a very pivotal role in EA implementation. As a result, it is one of the very first deliverables that need to be prepared as a part of the EA program. All the future deliverables would definitely be based out of the outline or foundation laid in the EA charter. Moreover, it is equally important to keep the charter up to date after every EA iteration. As per Gartner, it needs to be updated annually as soon as the planning for the next EA cycle is completed.

It was a very good learning experience to create a mock EA Program Charter for the group assignment. It made me go through a lot of other EA aspects like the RACI matrix approach to define roles and responsibilities of the EA team, the importance of metrics to an organization going through the EA implementation etc. I think, this is very close to experiencing EA implementation in the real world.

References:

Rollings, M. (2009, August 19). Enterprise Architecture Program Charter Template (ID: G00203755). Retrieved from Gartner database. 

Burke, B. (2006, January 24). Chartering the Enterprise Architecture Program (ID: G00136607). Retrieved from Gartner database.

Bittler, S. R. (2010, October 05). Toolkit: Sample of a Starter Enterprise Architecture Program Charter (ID: G00207188). Retrieved from Gartner database

EA Maturity - Key to EA Success

This week's reading on Maturity of EA was quite detailed and informative. The fact that any concept or thing becomes stronger and well established as it matures is clearly conveyed in the readings on EA Maturity.

In the book - Enterprise Architecture as Strategy, with the help of a simple example of the 'Big Dig' project at Boston, the authors explain at depth about the various stages of maturity that EA in an organization goes through. The four stages are -

1. Business Silos Architecture
2. Standardized Technology Architecture
3. Optimized Core Architecture
4. Business Modularity Architecture

Organizations are required to move through each of these stages in order to successfully adopt EA and exploit its complete functionality. An organization at stage 4 of EA maturity would be the one that the entire industry would look up to. The stages begin from the companies which have many silos (individual entities/units of business). It is not a good idea to have business silos because integration across the different business areas would be very difficult. Silos are individual entities which do not talk to other entities leading to a decentralized system. Moving on, the next higher stage of maturity is to standardize the technology/applications across the organization. This is one step closer to having a centralized system. Next level is standardizing the data and processes of the organization as they form the core or skeleton of business. The last and highest level of maturity is the stage which has the highest amount of business modularity and which enforces the greatest amount of standardization across processes. All organizations adopting EA must aim to reach at this level of maturity and I believe that it is at this stage where all the EA benefits would become clear.

But I think moving the stages of maturity is easier said than done because it involves one big thing - CHANGE! Change is something that people dislike. Although the technology, data and process can be changed for good, but changing the most important resource of organizations i.e. People is a comparatively tougher task. This, I believe is the biggest challenge to improving EA Maturity in an organization and Enterprise Architects must keep this point in mind before introducing any change.

References:
Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business Press.

The EA team - First who then what!

An important aspect of the EA chartering processing is the EA team planning. Without the right people on the team, EA planning is not bound to be a success. EA being a process and not a framework requires collaboration and communication among its team members for its effective implementation.

The RACI (Responsible, Accountable, Consulted and Informed) approach of planning for the EA team is presented by Gartner as one of the best practices for team selection. The RACI matrix is an efficient way to plan the team members as it clearly lays down the roles & responsibilities. The relevant team members can be contacted based on their involvement in the planning process. The other idea of maintaining the ethic of stewardship while executing EA tasks is also noteworthy.

In the book- 'Good to Great', the author Jim Collins has very well explained the planning for EA team by giving the example of getting into a bus. According to the author, EA is the bus and its important first to get the right people and remove the wrong people from the bus. Only after this is done, the decision of where the bus needs to go should be thought about. Similarly, in the EA context, it is important first to have the right people in the team and then decide on the direction (i.e goals, objectives and strategy).

References:

Robertson, B. (2008, February 11). Toolkit: Best Practices for Planning People and

Responsibilities for EA Project Teams. Gartner (ID:  G00155180). 

Collins, J. (2001). Good to great.

Business Strategy - The foundation for EA

All the readings for this week are based on the requirement and importance of having a well-defined business strategy for the successful launch of EA. A strategy is nothing but a road map of how will the organization progress in achieving its goals. Without a strategy in place, an organization will not know where is it going and what needs to be done to get there. Hence, it is inevitable that laying a sound and clear business strategy forms the foundation of EA. 

In the Chapter 1 of the book - Enterprise Architecture as a Strategy, the author talks about the pre-requisites required before executing the strategy. They are - Creating an operating model, integration of IT with business logic and lastly creating an IT engagement model. This is the foundation on which business strategy is set up. It enables organizations to increase profitability, improve and retain customer base, expand the organizational activities and so on. 

The other readings of Gartner - Activity cycle and EA - Just Enough, Just in time also emphasize enough on strategy being the bedrock of a good EA implementation. The very first and most important components of the activity cycle is to strategize. It helps to realize the current and future states of the organization (as-is and to-be states) and pave a path to align the organizational tasks into achieving organizational goals. Only then, will the organization be able to decide how much of EA is just enough and the point in time when EA is needed. Another concept of developing the 'Enterprise context' is also talked about in the readings. It is the process of translating the business strategy into the change needed in an organization. 

In order to develop the strategy, a detailed discussion among the EA team, business team and IT team is required. Effective communication among all the three teams is required for a well-defined business strategy to be developed.