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
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
Swathika,
ReplyDeleteThanks for mentioning the Gartner article that states EA should focus on the future state. Prior to reading that article, if you were to deploy an EA, would you have documented the current state? I would have prior to the article because of the thought "you don't know where to go unless you know where you are". I think having a future based outlook in business is sometimes frowned upon, but the article makes a great point about staying focused on the future. If you're at an organization that does not have a well documented current state already, documenting it for an EA implementation will do little good for you and your organization.
-Larry