No organization wants its Enterprise architecture practice to be a bunch of heavily detailed artifacts that resides in shelves and servers with no other user but the EA team. Yet, many organizations are guilty of having an enterprise architecture that yields no value to the business. There are several wrong practices of how EA is approached, presented and realized that lead to this non desired outcome.
One of these practices is giving the priority to the creation of a comprehensive current state architecture. While it is great to understand where the organization stands currently, the EA team, who follows this practice, will ultimately miss the intended alignment to business and strategy. The EA team won’t be able to keep pace with the exponentially changing technology. One of way out of this, is to adopt an EA practice that is business outcome driven. Outcome-driven EA, forces you to focus on future/target states in iterative manner. Not only this makes the EA program on top of change but directs it towards specific measurable outcomes which the business values.
Another bad practice of EA is failing to communicate to the business. When it comes the EA, the business needs answers to two main questions. One question is what will the enterprise look and function like in its future state. Another question is, what are the specific business values that the EA delivers? The answer to the first question involves the use of conceptual modeling to simplify the complex nature of the future enterprise. This can be achieved by creating multiple views that address the concerns of stakeholders at the different levels of the enterprise. The answer to the second question requires mapping the architectural principles to a defined set of business values. Whenever possible, measurable business outcomes should be demonstrated.
The last worst practice usually occurs when senior management has no faith on the EA program. In these organization the EA is not perceived as a management program. This probably due to the fact that EA is handled by IT and was not probably launched as a business initiative. An EA program which is not launched with strong ties to the strategy and the business should not be called an enterprise architecture program but rather an IT architecture program.
One of these practices is giving the priority to the creation of a comprehensive current state architecture. While it is great to understand where the organization stands currently, the EA team, who follows this practice, will ultimately miss the intended alignment to business and strategy. The EA team won’t be able to keep pace with the exponentially changing technology. One of way out of this, is to adopt an EA practice that is business outcome driven. Outcome-driven EA, forces you to focus on future/target states in iterative manner. Not only this makes the EA program on top of change but directs it towards specific measurable outcomes which the business values.
Another bad practice of EA is failing to communicate to the business. When it comes the EA, the business needs answers to two main questions. One question is what will the enterprise look and function like in its future state. Another question is, what are the specific business values that the EA delivers? The answer to the first question involves the use of conceptual modeling to simplify the complex nature of the future enterprise. This can be achieved by creating multiple views that address the concerns of stakeholders at the different levels of the enterprise. The answer to the second question requires mapping the architectural principles to a defined set of business values. Whenever possible, measurable business outcomes should be demonstrated.
The last worst practice usually occurs when senior management has no faith on the EA program. In these organization the EA is not perceived as a management program. This probably due to the fact that EA is handled by IT and was not probably launched as a business initiative. An EA program which is not launched with strong ties to the strategy and the business should not be called an enterprise architecture program but rather an IT architecture program.
These might not be the only worst EA practices out there,
but it what came to my mind after this week ‘s readings.
No comments:
Post a Comment