Demystifying Enterprise Architecture
You might think that it sounds quite pretentious for someone to call oneself Enterprise Architect (at least if you don't see yourself as one of them). Well, I don't blame you if you do. The term Enterprise Architect easily leads one's thoughts to someone who architects an entire enterprise from scratch or who orchestrates every wink and turn of an enterprise as a sort of puppy master. Such a conception is course wrong. The Enterprise Architects are cogs in the enterprise wheel just as all others - they are only different in the sense that they have been assigned the responsibility to observe the complete machinery and keep track of the different parts and how they relate to each other. But also to envision how new or changing requirements and constraints - big or small, few or many, dramatic or subtle - will need to change the enterprise and its different but yet often very tightly related parts.
The key word here is "related". An enterprise consists of a lot of different parts, ranging from business models, strategies, processes and people to information resources and IT systems (in turn made up by applications and content stores and running on an underlying IT infrastructure).
Today we all know that one cannot change business models, strategies or even small parts of business processes without changing or at least considering how the change will affect other business processes, people, information resources and IT systems. And vice versa.
To avoid that changes have unpredicted and unwanted (side-)effects, this complex environment of interrelated parts must in some way or another be managed, and to be able to manage it, the different parts and how they relate to each other must be known and understood by all who needs to know about it and understand it. That is why there are some people in your organization who officially or unofficially call themselves Enterprise Architecture. They try to build and communicate this knowledge and understanding to others. "Enterprise Architects" who hide in their offices without talking to people - who are more concerned with creating perfect representations of the architecture of the enterprise - should not be taken seriously.
To be able to "eat the elephant", an Enterprise Architect needs to slice it up into a number of more manageable dimensions and look at it at different levels of abstraction. An Enterprise Architect that tries to do that with anything bigger than a very small enterprise soon realizes that he or she cannot do this alone. Specialization and a team that brings the different specialties together are needed. Together, the members of the team might be able to create, maintain and communicate an understandable model (or actually a number of models) of the most important dimensions of the enterprise and how they relate. They can then be advised when there are new or changed requirements or constraints that call for changes somewhere in the enterprise. They can try to envision what consequences the change will have and guide any implementation initiatives along the way of change.
Enterprise Architecture is about caring about the big picture, the sum of all parts, and every little corner of the enterprise at the same time. It is about being able and willing to (fore)see and care about the consequences of a change - regardless of where these occur in the enterprise - and make sure that someone is appointed to manage them.
The key word here is "related". An enterprise consists of a lot of different parts, ranging from business models, strategies, processes and people to information resources and IT systems (in turn made up by applications and content stores and running on an underlying IT infrastructure).
Today we all know that one cannot change business models, strategies or even small parts of business processes without changing or at least considering how the change will affect other business processes, people, information resources and IT systems. And vice versa.
To avoid that changes have unpredicted and unwanted (side-)effects, this complex environment of interrelated parts must in some way or another be managed, and to be able to manage it, the different parts and how they relate to each other must be known and understood by all who needs to know about it and understand it. That is why there are some people in your organization who officially or unofficially call themselves Enterprise Architecture. They try to build and communicate this knowledge and understanding to others. "Enterprise Architects" who hide in their offices without talking to people - who are more concerned with creating perfect representations of the architecture of the enterprise - should not be taken seriously.
To be able to "eat the elephant", an Enterprise Architect needs to slice it up into a number of more manageable dimensions and look at it at different levels of abstraction. An Enterprise Architect that tries to do that with anything bigger than a very small enterprise soon realizes that he or she cannot do this alone. Specialization and a team that brings the different specialties together are needed. Together, the members of the team might be able to create, maintain and communicate an understandable model (or actually a number of models) of the most important dimensions of the enterprise and how they relate. They can then be advised when there are new or changed requirements or constraints that call for changes somewhere in the enterprise. They can try to envision what consequences the change will have and guide any implementation initiatives along the way of change.
Enterprise Architecture is about caring about the big picture, the sum of all parts, and every little corner of the enterprise at the same time. It is about being able and willing to (fore)see and care about the consequences of a change - regardless of where these occur in the enterprise - and make sure that someone is appointed to manage them.