Enterprise Architecture vs. SOA: Pick the Winner

What do you do when the organizing strategy for IT you’ve been selling for years–enterprise architecture–is threatened by a new order–SOA? Do you invoke revisionist history and erase all references to enterprise architecture? Or do you risk eye-rolling the business by telling them you have to do both at once now?

The research I did for a recent story on enterprise architecture told me that EA is not very popular among business people because it promises only better efficiency in IT. The real value of the exercise seems to be the creation of an enterprise architecture competency center, with people who know how to build IT solutions with relevance across the company using standards that save money. If governed well and staffed with good people, the group becomes a positive influence; if not, it becomes a Draconian center of doom and denial.

So how does this group deal with SOA? How do its duties change? In this report that focuses on how the two concepts will affect each other, the author says EA and SOA will coexist. I agree, but the lack of success of EA over the years means that while it may be present in an SOA era, it will become less and less visible. You can’t do SOA without the kind of cross-enterprise view and standards espoused in EA. But SOA offers a compelling product that is lacking in EA: services. At the risk of trivializing 20 years of glacial progress in EA, SOA seems to be the part of EA that really matters to anyone outside of IT.

But neither concept will go anywhere without a good architecture competency. In this funny blog entry, a software architect offers his tips for surviving the perilous assignment of being the human embodiment of a concept. The architecture group–practicing SOA–is going to make or break IT’s standing with the business over the next few years. What do you think?