I enjoyed Nick Malik's response, to my last post, stating that SOA needs to be combined with EA. (I recommend that you put Nick's blog in your RSS readers, I did.) Also, enjoyed Joe McKendrick's follow up post right here on eBizq.net.
"Enterprise Architecture exists to do two things:
1. to Envision an organization that includes the strategic and operational changes that leaders require and demand, and
2. to Guide changes to the structure of the organization, and the actions of the business units themselves, so that the vision becomes reality."
The issue here is around the ability to create and drive change, not the desire to do so. In the 90s and earlier this decade I spent a lot of time at EA conferences talking about everything that Nick states in his post. You can't disagree with any of it, really. However, the enterprise architects typically don't have the ability to control budgets or to fire people required to actually drive such changes. Thus, they are relegated to creating "recommendations" and "position papers" rather than actually driving "changes to the structure of the organization," or any of the other changes required.
Thus, the larger issue here is that when you're in a hole, stop digging. SOA in the world of EA was and is considered a tactic, as Nick points out. "Look carefully. Do you see anything about SOA in that mission... or even information technology?" So, perhaps we need to redefine the mission to include these more productive concepts systemically, which is core to my point.
The trouble is not with the concepts of EA. It's the visibility of EA within most organizations, and the ability to actually get things done. By the way, you can show my dozens of enterprises and government agencies that have made great strides, but that still does not mean that I'm wrong here. Generally speaking EA has become the "designated buzz kill" in most IT meetings, and the rank-and-file in IT, as well as the business, delight in wiring around them these days. I see this all of the time in the world of cloud computing, where speed to meet a business requirement trumps the need for strategic enterprise planning.
So, can SOA fix all this? Nope. To Nick's point, which I agree with, SOA is an architectural pattern where EA is more management-oriented. However, the focus needs to be on getting things done, and addressing the existing architecture with more meaningful approaches, say SOA. Not just SOA in terms of addressing anything and everything as services, but SOA in terms of breaking the existing architecture down to its functional primitive and building it up as something that's, dare I say it, more service-oriented. Thus, you're able to address your architecture in much more meaningful and agile ways. I have all of the details in my last book.
Understandably, SOA replacing EA, or more likely EA better leveraging SOA, requires organizational education and change, which is what I'm suggesting traditional EA has had a hard time accomplishing. The best path here is to demand that you drive real change through real power. If the business is not willing to support that, than the deal is off. In other words, everyone in the hole is digging around you, and you have no way of getting them to stop.
So, here are my suggestions:
· First, accept that the ways of the past have not worked, thus we need some new directions. We drive the tactics of SOA to a more strategic level, which is my overall point here.
· Second, define the business value, and be able to sell it in the board room. ROI should be within 2 to 3 years, but most times I can do it in 1.
· Third, demand that the new process be sanctioned from above, meaning control of both budgets and careers. If not, move on to another enterprise that needs you, you wont' be successful driving any significant amount of change there, trust me.
· Finally, get dirty quickly. Focus on doing, changing, pushing, typically to some very aggressive timelines. Planning is fine, but planning should lead quickly to accomplishments.