Want Successful Enterprise Architecture? Define “Enterprise” First.
A couple of recent conversations have really caused this theme to spike in my head. In my experience, I’ve seen successful enterprise architecture and I’ve seen unsuccessful enterprise architecture. While many may put the blame on a failure to define what architecture is, I think that’s wrong. I think a recipe of failure is a lack of understanding of what the enterprise is. By that, I mean a lack of understanding of what capabilities should be managed at an enterprise level and what capabilities should not. There’s no uniform right or wrong approach, it is highly dependent on your company’s operating model as articulated in the book “Enterprise Architecture as Strategy.” In that book, the authors even state that at one extreme, a completely diversified company may have no enterprise architecture at all.
Once you understand what “enterprise” is, you have to set up the organization, processes, and governance to support that. To illustrate this point, however, let’s look at the differences today between two commonly “shared” organizations: HR and IT. Most big organizations have a centralized HR department. While I’ve never looked at the funding model for HR, my guess is that there is some overhead tacked onto every employee and every contractor that winds up paying the costs of the HR department. It’s a shared cost. One organization is normally not able to throw extra money in the pot and fund extra recruiters or benefits managers for their organization. Contrast this with IT where that’s exactly what happens. While IT may be centralized, it’s funding model is not. This results in IT organizations whose structure mirrors the business silos, and whose actions are completely controlled by the funding provided from each of those silos. What’s the point in having a central organization? That central organization really can’t dictate priorities or approaches, because someone else controls the purse strings. The right way of handling it is where the IT leader meets with the business leaders, they jointly agree on IT priorities and budget, and then the centralized IT department is funded based on those priorities with the discretion it needs to manage it from within. I’ve been at an organization that made that transition, and it was a definite improvement in the working environment, in my opinion.
Now the really interesting thing is getting that initial definition of the enterprise. The more I think about this, the more I realize that this definition is the job of Enterprise Architecture. We must architect the enterprise, meaning we come up with the proposal for what things should be enterprise and what things are best left to sub-domains. But wait, this sounds like a task, not a team. Initially, it is a task. Ongoing, however, the refinement of that definition and adjustment based on changes in the business and its climate will occur, and that is the job of the team. On top of that, there’s the enforcement aspect of making sure everyone continues to play by the rules. As an example, think about architecting the enterprise of the United States of America. The initial “architecture” creating the federated governing structure, with some capabilities provided at a federal, or enterprise, level (e.g. military forces) and others left to the discretion of the states. Since that time, the government has continued, in part, to tweak and refine what things are handled federally and what things are handled locally. The approach must always be monitored for effectiveness, responsiveness, cost, etc. Imagine, now, a different world where that structure doesn’t exist, and every cross-cutting topic is brought before a collection of state governors. Debate would occur on every single item, decisions would be extremely slow, and people with the power ($) to do so, simply would, even when it may not be in the best interest of the country as a whole. Take another scenario in recent press like immigration and border security. If the federal government says, “we must secure our borders” but doesn’t create a centralized approach for doing it, what happens? States with money may do a good job, states with others will not. One state’s approach may be completely different, making it difficult for legal immigrants to travel from state to state because the rules are so different. In other words, while all agreed that it was an enterprise goal, it was not managed as an enterprise capability. This is what happens in IT departments around the globe every single day.
My advice to my fellow EA practitioners: if you’re struggling, focus on defining the enterprise first getting buy off from senior executives on what items must be managed at an enterprise level, and then guide the transition to that approach.
6 Responses to “Want Successful Enterprise Architecture? Define “Enterprise” First.”
Leave a Reply
Hi Todd,
Great post. I concur completely with the advice you give here, as I understand it, which is: Understanding the appropriate scope of the EA function within any organisaton. and working within that scope, are necessary conditions for the effectiveness of that function.
But I do worry about a pitfull I see in your approach.
To the amusement of many who know me,(and the irritation of others), one of my recurrent concerns is the abandonment of plain English in the practice of EA in favour of practice-specific stipulations. If we provided a discrete function this practice would be unproblematic. But we don’t, and the practice of EA needs, as you indicated, a clear and shared understadning of the terminology we use.
So when we use words like “enterprise” that have wide broad curreny and conventional meanings we should avoid practice-specific stipulations intended to override or replace them. And I don’t think common practice of using compound nouns or noun adjective phrases lacks efficacy. When you use ‘enterprise-level’ in the same passage as ‘department’ I really think the meaning is perfectly clear, and would be to nearly anyone.
I do however think you have identified a really important and very interesting factor for EA effectiveness that would apply in any large organisation. (Or a structurally vague organisation). Lack of clarity and ambiguity in the scope of agency for varying parts of an organisation can create a lot of waste, conflict and innefficiency – both vertically in terms of who can tell who what to do, and horizontally in terms of which responsibilities are global, regional or local.
As a business capability itself enterprise architecture will (should?) be included in its own representation of the business architecture. I should think an important aspect of any business architecture would be a strategic/authority view that indicated the scope of effect and authority of each part of the organisation through the rest of the organisation. Visibility of what each function can and cannot effect, what level of command it has and what kind of decisions for which it is responsible would enhance any architectural activity.
Many voices (and more recently) in the community seems to be saying that the golden rule of EA is do the business architecture first. (I would happily sign the manifesto). If we do the BA first and well, the appropriate scope of effect for every function should be defined, gaps, conflicts and redundancies could be analysed just as they are with processes, applications and technolgy.
You’re singin’ my tune, Todd! 🙂
‘Enterprise architecture’ literally means the architecture of the enterprise – not merely of the enterprise-IT, or even of the organization.
One crucial point is that although we may be concerned only with our own organization (or even only its IT), the enterprise is usually a whole lot larger than just our own organization. (That’s the FEAF definition, anyway, and I’m sticking to it! 🙂 ) For example, although the US Government is a very important organization in the US, and to the US, it’s only a small part of the shared-enterprise that is the US – and if the government ever thinks it _is_ the US, you’re all in deep trouble… 🙂
(More detail on that at http://www.slideshare.net/tetradian/what-is-an-enterprise )
As you say above, a lot of enterprise-architecture depends on getting clear on what that extended-enterprise is, and our organization’s relationship to that extended-enterprise. For example, much of the fraught tension implied in ‘business/IT-alignment’ tends to fade away when we realize that it isn’t that one should align with the other, but that _both_ need to align with the same extended-enterprise.
Would love to talk with you more on this!
Over to you – but thanks, anyway, and hope this helps.
Great post Todd and dead on for the EA challenge that we’re facing. I’ll be sure to engage with you in helping us to get that all important buy off from our senior executives.
Allow me to play the devil’s advocate:
First, if the ‘Enterprise’ in EA refers to ‘The-Enterprise’ and not just ‘Enterprise-IT’, shouldn’t EA report into an organizational planning function like Office of the COO instead of IT? Further, shouldn’t it be staffed with business operations managers instead of IT specialists?
Second, given how EA often struggles in many companies with even Enterprise-IT Architecture, are we helping or hurting by expanding the scope to The-Enterprise?
[…] Blog post: Want Successful Enterprise Architecture? Define “Enterprise” First. http://www.biske.com/blog/?p=785 <recommend […]
[…] The more I think about this, the more I come back to a recent post of mine from earlier this year: “Want Successful Enterprise Architecture? Define ‘Enterprise’ First.” I’m convinced that this is a critical step for any effort that tries to go beyond a […]