Lately, I was among a group of enterprise architects and IT
professionals who shared their experiences and thoughts on how their
organizations transition from a current state to a desired future state, in
particular we discussed the use of road-maps to help the enterprise visualize
the transition. Although I have blogged twice about EA road-maps, I decided to share this interesting discussion and my thoughts out of it.
It surprised me that many of them felt that the road-maps
developed in their organizations are “too dense with technical information”. Loads
of technical details are included such as Application Middle-ware Services, Data
Services, Network Services, Network-based Services, Platform Services,
Development Services, and Security Services making them rather look as technical
deployment plans. Identified initiatives are not presented in a way that shows
how they are related to strategy and dependent on each other. In other words,
it is very difficult to get the information you need out of them. I can see
that these organization had fallen into one of the worst EA practices
identified by Gartner which is: confusing technology architecture with
enterprise architecture.
Some professionals mentioned that their organizations do not
use road-maps to guide change efforts. In these organizations, changes are
identified in a reactive manner. Changes are either triggered by stakeholders or
internal and external events through emails, process workflows and town hall
meetings. Well, I am confident that
these organizations suffer from poor coordination and a lack of a common ground
on how the enterprise should move towards its future directions. Therefore, It
can be said that they do not really have an EA program in place.
Many professional stated that their organizations use
graphical high level road-maps to illustrate the sequence of capabilities that
need to be obtained to reach the desired future state. Their road-maps are
updated on a periodic basis to reflect the timelines and scope of initiatives
that will affect the organization. According to them, these road-maps were
excellent communication tools that brought the attention of even the
non-executive staff.
One of the enterprise architects explained how their
business outcome based enterprise architecture practice leveraged the use of
road-maps to communicate their transition to the target architecture in the most
effective way, by listing the outcomes and the initiatives along with
disruptors and risks. This has allowed them to show what would be delivered and
how these outcomes would address the disruptors and risks. I believe that
this approach has allowed stakeholders outside of the enterprise architecture
team to easily understand the goals of the enterprise architecture program.
There is no doubt that a simple, clear graphical EA road-maps
can allow the organization to coordinate and communicate change efforts, as
long as this road-map is kept current.
See you in week 15 !
No comments:
Post a Comment