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