Thursday, October 27, 2005
Implications of the Word "Enterprise"
Anyone following EA for any length of time knows that there are many definitions of the term 'Enterprise Architect." Some are very well-thought out, others are too skewed toward IT and in particular, IT developers. In the worst case, it is mangled by various software vendors to fit their wares into some marketing space to sell product, process and other EA functions be damned.
After reviewing and thinking about all of these definitions and explanations over the years, I have come to the following conclusion: when using the word "enterprise" with respect to any business or IT-related entity or issue, the usage must coincide with the business issues under discussion, not the underlying technology or any other systems-oriented focus. That would also mean that the word "system" would be appropriate when referencing technical and other IT-specific issues.
I favor an approach where the enterprise architect is tasked with developing and managing the business process-to-technology interface space, with substantial input into certain IT-centric issues such as infrastructure, data, IT project ROI/costs, and overall general architectures. On the IT side, a subclassification of an enterprise architect emerges: the system architect or system designer; who takes the broader view from EA and concentrates more on the technical mechanics of functional design, implementation, and production.
The hue and cry from certain technical camps demands that enterprise architects focus more on developer-centric activities. The fact of the matter is one cannot have it both ways: an EA cannot be all things to all parties, and I know of very few people who can assimilate and deal effectively with complex business issues and requirements along with learning and practicing the flavor-of-the-year programming environment or 'kewl' new development framework and databases. There's just too much there for one (or even 2 or 3) people to successfully handle in a medium-to-large environment.
So, just as there is an admittedly fuzzy demarcation line between an EA, the business, and IT, there also exists one between the EA and the next technical level within IT: the systems architects and technical project leads. The EA is tasked with successfully transmitting the overall IT architecture vision to the systems architects (and getting an understanding from them of the tradeoffs and issues/problems that they face without huge amounts of time spent in immersion of technical arcana. The system architects and technical project leads must work with the EA to get an understanding of the EA's broader architecture, what those implications mean to their projects, and deal with them effectively from development and implementation standpoints.
I know, easier said than done. It works best as a collaboration with the EA's vision treated as customer requirements would be. The EA must endeavor to rationalize the overall vision in terms of what is, and what realistically can be from a technical perspective. The two sides must rely on each other for overall success, not dictate terms to each other.
After reviewing and thinking about all of these definitions and explanations over the years, I have come to the following conclusion: when using the word "enterprise" with respect to any business or IT-related entity or issue, the usage must coincide with the business issues under discussion, not the underlying technology or any other systems-oriented focus. That would also mean that the word "system" would be appropriate when referencing technical and other IT-specific issues.
I favor an approach where the enterprise architect is tasked with developing and managing the business process-to-technology interface space, with substantial input into certain IT-centric issues such as infrastructure, data, IT project ROI/costs, and overall general architectures. On the IT side, a subclassification of an enterprise architect emerges: the system architect or system designer; who takes the broader view from EA and concentrates more on the technical mechanics of functional design, implementation, and production.
The hue and cry from certain technical camps demands that enterprise architects focus more on developer-centric activities. The fact of the matter is one cannot have it both ways: an EA cannot be all things to all parties, and I know of very few people who can assimilate and deal effectively with complex business issues and requirements along with learning and practicing the flavor-of-the-year programming environment or 'kewl' new development framework and databases. There's just too much there for one (or even 2 or 3) people to successfully handle in a medium-to-large environment.
So, just as there is an admittedly fuzzy demarcation line between an EA, the business, and IT, there also exists one between the EA and the next technical level within IT: the systems architects and technical project leads. The EA is tasked with successfully transmitting the overall IT architecture vision to the systems architects (and getting an understanding from them of the tradeoffs and issues/problems that they face without huge amounts of time spent in immersion of technical arcana. The system architects and technical project leads must work with the EA to get an understanding of the EA's broader architecture, what those implications mean to their projects, and deal with them effectively from development and implementation standpoints.
I know, easier said than done. It works best as a collaboration with the EA's vision treated as customer requirements would be. The EA must endeavor to rationalize the overall vision in terms of what is, and what realistically can be from a technical perspective. The two sides must rely on each other for overall success, not dictate terms to each other.
