I find it fascinating (and a bit disappointing) that Gartner and others are just beginning to figure out that an effective Enterprise Architecture practice needs to start with an understanding of business strategy and direction and cannot (successfully) exist as a purely technical concern.
Perhaps this is because the early days of EA was really more of an application or technology architecture focus. The much lauded (and, in my opinion, over-rated) Zachman framework is really nothing more than a taxonomy as much as it wants to be sold as an ‘architecture’. If you can fill out the top row of Zachman, you have probably exhausted its usefulness (and really gained nothing more that the Who? What? so on perspective that you learned in elementary school).
Spewak then came along with another view of EA that was heavily technology oriented. The thrust of this seemed to assert that if you had a complete inventory of your applications and their interactions you were doing EA. No, actually you were on your way to doing portfolio rationalization – a valuable EA service, but not EA in its entirety.
Maybe it was the recent addition of Business dimension to TOGAF in release 9 that caused these ‘pundits’ to finally come to there senses and realize what successful EA practitioners were doing all along.
It would seem that this technology-focused approach has been the seed corn for the old saw ‘IT needs to align with the business’. I always thought it was odd that there was never an exhortation to have Accounting align with the business or Marketing align with the business. I believe that both parties are to blame here — the business needs to articulate a vision and plan that IT can understand and execute against. Without a clear plan from the business, IT more often than not will turn inward and focus on technology in a way that may or may not support business direction.
This disconnect on having business drive EA sort of reminds me of the strange looks that I would get about 10 years ago when I would try to explain that before an enterprise rush into slathering pointy brackets on their data and declaring that they are ‘service oriented’ that they should take the opportunity to make sure that there was a single enterprise definition of enterprise data and use services to expose them in a enterprise uniform way. ‘That has nothing to do with SOA!’ I was told. Tsk, tsk, that is data management, not SOA. Now, this ‘insight’ is all the rage, with every vendor and consulting firm thumping their chests and proclaiming that ‘data comes first’ and ‘the importance of MDM‘ as a pre-cursor to SOA.
Similarly the same pundits thundered on that it was laughable that BPM be tied to SOA. Problem is that BPM has a certain amount of ambiguity around what the M in BPM means for any given speaker. Is it Modeling? Management? Monitoring? Mapping? So, yes, for all of the non-implementation aspects of BPM, the service orientation part is largely irrelevant. But for any business process implementation that has system touch points (nearly all non-trivial processes do), services are (or should) play a role in exposing the business functions in a consistent, re-usable manner within the enterprise.
So, yes, Enterprise Architecture should be business driven, not technology driven. MDM is a critical underpinning for successful SOA. And BPM is probably the most visible part of service orientation and SOA is key to BPM implementation. What next, governance is key to enterprise SOA success?
Technorati Tags:
architecture, consulting, dubious, enterprisearchitecture, ideas, soa, technology