My comments will be brief, as I am still behind and writing from my wife’s hospital room… but I do want to try and get back to writing something, as so much is going on.
I recently spoke at the IIR EAC conference in Orlando. My topic seem well received, but what I found more interesting was the conversations with others about “What is EA?” Some said it was “technical strategy.” While others said “it was the merging of business and technology.” While there is merit in the first, I believe the second better describes the role of EA.
It seems to me that too many in the EA field acting as EA’s are really Solutions Architects. Not that any role is more or less valuable than any other; but, they are different and the distinctions must be explored and understood. While the Solutions Architect is focused on how to bring about a solution, the Enterprise Architect is concerned with the portfolio of solutions - and defining the portfolio of solutions requires an understanding of all things business and technology. It is the convergence of vision - both what capabilities the organization needs to meet business vision and what functionality and products are needed to deliver those capabilities.
Moreover, what is most important for the EA is to provide consulting to the business on what things might be possible given the broad range of needs, as well as, to break down the business to technology and technology to business communication gap. Not that the SA role is not also using these skills, and providing an important role. But, the EA must loosen the reins on technology and move into more broad technology concepts. For example, the EA must look beyond Oracle or SQL Server, and instead talk in terms of relational data solutions and object oriented data solutions.
Some might consider this nit picking or not even see the distinction. Again, I would go so far as to say those who do not understand the differences are most likely the ones who have less time working with the business and more time working with technology. Or to put it differently, those who have a hard time seeing the difference are probably more comfortable with technology and the more concrete role that goes with it.
Those who do understand the difference, are most likely those who have spent time talking with sales and marketing and have heard them complain about how “IT just doesn’t hear me!” In fact, if you’ve never been close enough to business customers to understand their sometimes subtle vocabulary differences, you’re not really ready to call yourself an Enterprise Architect. And on the other side of the coin, if you are having trouble talking to some of your more technical cohorts in systems or infrastructure engineering, you might well be on the way to a successful career in Enterprise Architecture :-)
At some point, you need to make a decision. We all do. In what way will I grow my skills? We have only limited ability, especially if we desire balance in life, so we must, for example, either decide to go deep into IdM or choose to understand what IdM is and why it is needed. And, if the later is your decision, let someone else do the product selection… with EA guidance based on the overall vision and roadmap for the business.
As always, I look forward to your input!
Patrick