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