Nick Malik recently gave the Zachman Framework (ZF) a death sentence because it does not have a row for 'customer' - making the assumption that any and all EA frameworks that do not recognize the customer as some kind of major entity are severely flawed and in his words, 'doomed.'
I agree with most of the issues and quibbles within the EA community about the ZF. It is dated, IT-centric, and not particularly helpful for future-state work. Where I have an issue is the assertion that if a framework doesn't directly contain or support 'this' or 'that,' it is immediately deemed useless and headed for a quick trip to the electric chair.
Not so fast, my friends. Here's a short list of general EA framework and work product issues that should give us pause when evaluating or using EA frameworks to accomplish our work.
EA and its frameworks do not apply only to businesses. EA is also practiced by government agencies, non-profit organizations, and other organizations that do not sell goods and services to other parties. For example, there is no concept of customer in most government organizations, but there are constituents, taxpayers, defendants, plaintiffs, jurors, students, licensed drivers, etc. In large non-profits such as major health care organizations, there are no customers, but plenty of patients. If one argues that a patient is in reality a customer that pays the bill - that can be refuted by the majority of patients who have their health care paid in full or in part by a third-party payer such as a health insurance company or the government. Who then, is the real customer in these instances - the party receiving the services or the party parting with the cash - or neither - or both?
Unless an EA framework is very explicit with respect to the type of organizations it purports to serve (the US government's definitions and use of FEAF and DODAF come to mind here), the generalizations required to support all possible entities make it obvious that specific entities that someone may be passionate about will always be underrepresented, or not directly represented at all. While this can be addressed and successfully dealt with in alternative ways, it does not immediately mean that such entities are required directly in a framework every time this dilemma is discovered and recognized. The level of complexity in escalating such cases would render all general EA frameworks severely flawed.
EA Frameworks and deliverables often suffer from semantic deficiencies. All forms of architecture at various levels suffer from semantic deficiency - which is while frameworks, models, and related artifacts articulate a strategy, direction, roadmap, design, data models, business process definitions, etc. there is always a risk that a substantial percentage of benefactors, reviewers, and overseers of such work (such as executives, development teams, CIOs, etc.) will not understand or will misinterpret the work even if it is technically correct. Inappropriate levels of abstraction within work products also contribute to this dilemma.
Let's return to our favorite entity/role, the customer, for a moment. In very large organizations, it is not uncommon to discover or eventually realize that there are multiple (and often conflicting) definitions of customers - who/what they are, what they buy or have a stake in, how their needs are met, etc. Trying to straighten out such definitions into a singular view is often futile, because people consuming EA work products will rarely change their perspectives, often for rational and good business reasons. While various forms of organizational governance (data governance, for example) will alleviate some of these issues, if your framework/work products are talking about X, and the recipients and benefactors think you mean Y, you have a large problem, even though in the end, X and Y are identical in most, if not all, aspects.
EA Frameworks are mechanisms for organizing and developing EA work products, not holy grails. Over the course of my career, my path has often crossed with individuals that believe that (counter to Nick's thoughts about the ZF) 'Framework X' is the epitome of excellent EA, the only way to 'get EA done,' and nothing else matters. The same can be said about various operating systems, programming languages, and business methodologies developed and posited by numerous 'thought leaders' and gurus over the years. Drinkers of this form of kool-aid are often disappointed or eventually face failure when it turns out that unwavering belief in and stewardship of specific frameworks doesn't work out, or is eventually replaced with something else that isn't part of their specific views. Keep in mind that for better or worse, things like this always change, and its more important to utilize frameworks to organize and produce work products beneficial to the organization than it is to rationalize that our methods are always correct and need not change over time.
The better way to treat frameworks is to view them simply as structures for producing, organizing, and categorizing EA work products and not holding them in awe beyond that. What matters more about EA work products is that they are relevant to the organization and its strategy situation(s) at hand, not deemed 'fatally flawed' because one or two people think that some entity that they're advocating always requires direct representation in a framework.
The problem here is that semantic deficiencies and other misunderstandings can undermine this approach if one isn't careful and explicit. I mention it because: a) it can and does work in enough cases to be useful; b) it can reduce entity complexity (but conversely, often drives up the complexity of interactions and processes between entities); and c) boils down the entity abstraction level to the minimum required to meet the needs of the organization.
EA Frameworks and artifacts assist in validating and executing business strategies, but does not define them. EAs should resist the temptation to use frameworks and the artifacts produced as a method to define organizational strategies. We aren't paid to develop organizational strategies, but we are compensated to validate them and assist in their successful execution. If our analysis reveals flaws in strategy, we are bound to report our findings to management - who then either takes appropriate action or doesn't. I like to think that our work optimizes the execution of strategic intents and operating models in terms of time, money, and future business/organizational leverage, but the intents and overall guidance/direction has to come from senior leadership. It's about influence in our role, and not in making those sorts of decisions directly (as if we could in any event... :))
Finally, this is a very exciting time for enterprise architecture and EAs as the discipline evolves from its IT-centric roots to providing value for entire organizations. And learning from the past is a crucial way to get to this higher ground.
Comments