What really makes you Enterprise Architect
You just entered the meeting room for another meeting. Each one of the people around the table has certain specialization，which everyone recognize.
The DBA has unique knowledge, the security specialist has unique
knowledge, the software architect has unique knowledge and the
network architect has unique knowledge. This unique knowledge makes
them expert in a certain domain and that makes management to take in
account what they have to say. But, what about you (the enterprise
architect), what is the unique knowledge that you're bringing to the
table? Well,
that's one of the common problems that I saw at enterprise architecture
teams, they simply doesn't have any unique knowledge. Most of those
teams are collections of people from different domain of expertise that
was gathered together as a team. Don't take me wrong, those people has
unique knowledge. But not as enterprise architects, their knowledge is
based on their previous work experience. As enterprise architects that
don't have any unique knowledge that they can bring to the table. Most of
the EA teams will argue that the fact that they formed from different
experts from different domains, that's their uniqueness. That's true
but, still this is not a unique tangible assets that you can bring to
the table and share it with the others. What I
learned from my experience is that some effort need to be invested in
order to build EA unique tangible assets. The effort is all about
modeling all the four enterprise domains (business, information,
application and technology) and their cross domain relationships. Such
knowledge doesn't exist in any other head at the enterprise. Based on
this knowledge you can start to advocate new architecture, principles,
blue prints and any other EA related work outcomes. Having this unique
knowledge will also give you the justification for decisions and
activities that you're running in the enterprise. As
powerful as this asset is for enterprise architecture the wisdom here
is to know what to collect and model and how to do it. Too much
information to collect and model will end up with very long work that
will prevent you from seeing any EA outcomes.
Even if you manage to keep your management pleased for the duration of
collecting and modeling data, you'll find yourself wasting a lot of
time (and loosing management support) on maintenance. On the other
hand, collecting too less information will prevent you from reaching
all the objectives that have been assigned to you.