A couple of weeks ago, Jeff Schneider wrote a post entitled Why Enterprise Architecture is a Joke. Jeff’s point wasn’t to ‘pick a fight’ but rather to point out some troubling issues associated with the practice of enterprise architecture:
1. Zachman pioneered, than stagnated. I believe that the single largest reason that EA is a joke can be linked back to the pioneer. This pains me to say, but many in our industry were patiently waiting for better stuff to come from Zachman and it just didn’t happen.
2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn’t a universal truth, I’ve witnessed my fair share of it. Those who can’t architect do PowerPoint.
3. Silo Organizations promote Silo Funding. Many EA’s never had a chance. They live in organizations that fund everything according to business silo’s. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight.
4. The Tooling Sucks. Modern EA tooling is complete pile of crap. It is designed and written by a generation who is out of touch with the needs of modern I.T. groups.
5. Unconnected Models. Expanding on #4, our models (and tools) do not sufficiently flow from one model to the next. Software development is often explained as a series of model transformations from concept to design to construction, where each stage adds additional fidelity. We currently have a huge hole between EA and the downstream constituents.
In the intended (non-combative) spirit of Jeff’s post, I’m going to add my 2 cents.
EA Frameworks
Similar to James’ response, I don’t often run into enterprise architects in commercial organizations that use Zachman. Certainly, almost all EAs are aware of Zachman, and appreciate his foundational work. But, many have come to the conclusion that Jeff has, the Zachman framework isn’t enough. It does provide a good frame to orient thinking, but producing and classifying documents does not make for an enterprise architecture.
Of course, this isn’t just an issue with Zachman, most enterprise architecture frameworks are artifact centric. As if producing the right documents and policies alone will result in a high performing, low technical debt, business aligned IT organization.
If you want an actionable enterprise architecture, you must go beyond artifacts. You need to create the environment (business capability to architecture strategy matches, architecture platform, portfolio planning & management, governance, talent development, etc) and relationships (business, IT leadership, delivery teams, operations teams) that directly contribute to the delivery of business capability. As I’ve said before, a sure way to failure is to view your architecture as an end, rather than a means.
Conflicting Measurement
Another I problem I see, that relates to Jeff’s “cops with no gun, just a good flashlight” metaphor is the disconnect between EA Governance and IT Leadership. EA teams are charged with policing delivery projects for compliance to the architecture. Among other things, compliance to the architecture should result in risk mitigation, investment productivity over time, business flexibility, reduced technical debt and skills optimization. However, many IT organizations (and their leaders) are measured on shorter term, operational aspects, such as on-time, on-budget, up-time, risk mitigation, etc. Given that people perform in accordance to how they are measured, regardless of the bigger implications, IT Management often trumps EA Governance to ‘get the thing in’.
These, seemingly arbitrary, bypasses of the enterprise architecture contribute to the ‘EA has no teeth/backing’ (is a joke) perception. While there are valid business reasons to give some projects a pass, it needs to be handled in a structured manner, as a waiver, accompanied by a plan to bring the assets into compliance, limit their proliferation and/or schedule their disposal.
While the waiver provides a formal acknowledgement that the project is out-of-compliance, enterprise architects can’t stop there. EAs need to educate IT management, delivery and operations teams on the value of enterprise architecture. And, during those conversations, EAs must listen to the needs of their constituents, in order to create a relevant, actionable enterprise architecture.
