I recently attended The Open Group Architecture Practitioner’s conference in Seattle. During the event, I was given the opportunity to present a Keynote on the Language of Business Architecture, which I thoroughly enjoyed. A couple of my peers, Mike Rollings of Burton and Henry Peyret of Forrester, were present and gave interesting presentations, as well as participated in a panel discussion, with Business Architecture themes. There were several questions posed during the panel and Q&A sessions following their presentations upon which, surprisingly, I also had an opinion. With apologies to Mike and Henry, I thought I would share some of them with our readers. And George has an opinion or two, as well.
Q1: If Enterprise Architecture as practiced by most is really IT Architecture and Enterprise Architecture is not a term that will be embraced outside the IT organization, what should we call it?
Tim’s Answer: Although it is not as catchy, my first thought was Enterprise Planning & Optimization. Until something sexier or more appealing comes along, this is my suggestion.
George’s Answer: I can live with that and have never found anything better. Several years ago, at successive Enterprise Architectures Conferences (EACs) I ran working group sessions to “rename” EA. Each time, the group concluded that “even with all the undesirable connotations of the name ‘EA’, we can’t come up with a better name”.
Q2: Have you ever seen EA report outside of IT?
Tim’s Answer: To this point, I have not worked with a company that has the EA function reporting outside of EA permanently; however, I have worked with companies where the head of EA has had occasional assignments working for a corporate executive (not line-of-business) on strategic initiatives.
George’s Answer: I have seen a few forward-looking organizations exhibit EA-like behaviors with notions like future state, enterprise principles, enterprise operating models (a la “EA as Strategy” – Ross, Weill, Robertson) as context, etc., usually within the enterprise strategic planning function. They never call it EA, though.
Q3: Do you see many EA groups with defined qualitative metrics? What are they?
Tim’s Answer: Most EA groups need to have some kind of metrics or KPIs in place, and as most of the benefits of EA are indirectly realized through the efforts of others (project teams, operations, procurement, etc.), they tend to be qualitative. I have seen clients measure reductions in complexity and asset portfolio mix that have both qualitative and quantitative elements to them. Perhaps the most common qualitative metric I see is a periodic assessment of EA maturity/effectiveness. Organizations compare the ratings in different categories from one year to the next to see where they are improving and where they are lagging.
George’s Answer: I agree with Tim and would add that, occasionally, I see many organizations implement specific quantitative measurements because their HR systems require them to have something designed to evaluate individual and/or group performance. These tend to be behavioral measures, not value measures. Examples include completion of specific EA deliverables, or reducing the number of EA exceptions requested by projects. The latter is achieved by creating appropriate reuseable patterns that have high utility across the enterprise, solving specific implementation scenarios in a repeatable way, through education and project coaching, etc. The leadership team must believe that these behaviors will eventually drive desired outcomes in the company if the architect is to have any chance of representing these as legitimate metrics.
Q4: In large organizations, line-of-business (LOB) architectures abound. Is this an inhibitor or opportunity?
Tim’s Answer: I think that it can be both. If you do not create a unified, but federated, EA practice across the organization, then you run the risk that the LOB architectures are inconsistent, increasing cost and complexity overall. Also, the LOB EA groups will tend to be more customer-focused, giving the LOB what they want, which makes it more difficult for Enterprise-level architecture decisions that are optimal company-wide, to be embraced at the LOB level. This federated approach is what we see at most large complex organizations, so it must be turned into an opportunity to be successful. Without leveraging the extended architecture community, the EA will probably be largely unsuccessful in large organizations.
George’s Answer: It could be both, but being a cup half-full person, I usually see it as an opportunity. If even a small part of a large organization can do EA successfully, that’s good for them. With luck, it will spread and grow to others. If there are multiple LOB EA’ish functions, perhaps they will be able to identify opportunities for commonality and leverage, but only if that really makes sense for that particular company. If critical mass or commonality never materializes at the big-“E” enterprise level then at least part of the company has embraced EA concepts.
Q5: How do you define a business capability?
Tim’s Answer: To me, business capabilities are the next layer of abstraction below business strategies and objectives, defined as the capabilities that the business operations must deliver to achieve those strategies and objectives. Since capabilities are usually defined at a higher level than requirements, there is more opportunity to find capabilities that cross organizational and functional boundaries. This approach helps identify the areas to which we can architect, rather than getting right to the solution.
George’s Answer: This is a tough one because everyone has their own interpretation. The simplest one I have seen defines a capability as “the ability for an organization to perform a particular piece of work”. I like it BECAUSE of its simplicity. Of course, then one must be able to define “work”. One example capability might be, in a product company, packaging and communicating product features to potential customers. That capability manifests in the marketing function.
Q6: Do you think the long-term future of EA is to merge or disappear?
Tim’s answer: I think for the vast majority, the answer is neither. Ultimately, EA is all about leadership – providing it and being recognized by it. It seems to me that the leadership of most organizations is interested in surviving, keeping the status quo, and being tremendously risk averse. In those kinds of circumstances, I see EA following the enterprise leadership and basically staying the same. Those organizations that truly embrace EA’s transformational capabilities and allow it to reach its potential may end up creating a hybrid version of EA – one part that continues the traditional IT architecture leadership under the CIO called EA, and one part that merges into the executive offices to provide leadership in planning and strategy, called something other that EA, perhaps Business Architecture (but I kind of doubt it). In these cases, there will be a strong relationship and integration between EA and BA.
George’s answer: I have long maintained and continue to be of the opinion that a well-run EA program “melds into” and becomes part of the management and decision-making fabric of the enterprise. It isn’t EA itself that we ultimately care about – it is just the name we are stuck with to represent a future-oriented, holistic, business driven, enterprise-wide context that informs decision-making. What we really care about is the installation of those EA-like concepts, behaviors and an enterprise context into how the enterprise works – whether it is called EA or not. By the way, I think we are a long way from this happening for anything more than a relatively small fraction of organizations.
Let us know what you think.
Hi Tim, we discussed question #1 after my keynote “Enterprise Architecture – Disappearing into the Business”. While I am flattered that you were inspired by my definition of EA, I don’t want people to call EA “Enterprise Planning & Optimization” unless they are actually doing it inside their organization. We do not need another term to become meaningless like enterprise architecture.
If an organization looks at EA as a techno-focused activity, then it is not because of the name they have given the function. Most likely EA is perceived as techno-focused because the members of the EA team are acting this way!
If you focus on the right things NOBODY WILL CARE WHAT YOU CALL IT. For more read my post in our Executive Advisory blog –> http://tinyurl.com/yj2fr6n
Mike Rollings
Research Director Enterprise Architecture
Burton Group
Hey Mike! I agree that what people say and how they act are definitely part of the issue, but I am not convinced that speaking/being more business-like will get rid of 30 years worth of a technical connotation associated with Enterprise Architecture – the term, the function, or the people. I am not suggesting that we call it Enterprise Planning & Optimization either. But if pressed for a name, that is what, IMHO, best describes the scope (Enterprise), the activity (Planning) and the goal (Optimization). It is not catchy and I doubt it would catch on globally, but if someone is searching for a name for their business-sponsored EA activity and they don’t want to call it EA, then I am completely open to a better suggestion. Anyone?
However, I do completely agree with the gist of your comment – do the right thing and the name shouldn’t matter. Which is why we generally tell folks not to use the word EA (why cloud the discussion if indeed there is an IT connotation) when in discussions with business executives and focus on the outcomes.