 |
 |
       |
 |
Home | Site Map | Blog | Contact |
 |
|
|
Research Content / Cornerstone
Cornerstone - A Holistic & Pragmatic Approach to Rapidly Evolving to an Effective Enterprise Architecture
The purpose of this whitepaper is to describe a holistic and pragmatic approach to enterprise architecture which creates stakeholder value, elicits executive support, and is embraced by its consumers. Our approach is holistic in that we take a broad view of enterprise architecture, its function and breadth of ‘touch points’ in an enterprise. Our approach is pragmatic. We believe in ‘just-enough-architecture’. We also believe that the tactics used to create support for enterprise architecture can vary enormously as each organization’s realities can be very different.
Enterprise Architecture & the Value Imperative
The fundamental objective of a business is to create value for stakeholders.
Executive teams work hard to determine and validate a business’s value drivers and develop a business strategy. They perform SWOT analyses, look for strategic inflection points, examine resource allocation and search for economies of scale while debating the merits of operational excellence versus customer intimacy.
Business Process Owners look for value from large scale BPR efforts, business improvement through eliminating defects by embracing Six Sigma, or a continuous improvement approach such as kaizen.
Staff functions also work hard trying to create value – from improved cash management to talent acquisition.
All of these roles – executive leadership, business process owners and staff functions – are striving to create value.
Enterprise architecture efforts must also strive to create shareholder value if they are to gain the support of executive leadership, and be viewed as effective both inside and outside the IT organization.
Change, Value & Complexity (The Elevator Pitch)
Assume for a moment, that you have just been hired to lead an EA effort and you find yourself in the elevator with the CEO who asks “So, what do you do for us?”
You have 15 to 30 seconds to make your case. What do you say?
Our elevator pitch is something like this:
“We focus on reducing the complexity of IT and business processes across the breadth of the enterprise so our company is much more agile.”
Our logic is simple:
Is our elevator pitch a good definition of enterprise architecture? No. We have not tried to define what enterprise architecture is or what it does. Instead, we have expressed the outcome of enterprise architecture that is most important to executive leadership – creating shareholder value.
How does the discipline of enterprise architecture understand complexity? Through models, frameworks and repositories. How does the discipline of enterprise architecture reduce complexity? Through roadmaps.
We do not believe that the goal of EA is to eliminate complexity. Not all complexity is bad; in fact, some complexity may be required to provide competitive advantage. Our goal as enterprise architects should be to ensure that complexity is an exception and that there is a valid business case for the desired complexity.
Enterprise Architecture Defined
Enterprise Architecture is a strategic management discipline that creates a single, holistic view of the business processes, systems, information and technology of the enterprise designed and optimized to create shareholder value by achieving both the long-term business strategy as well as current business objectives.
The primary output of enterprise architecture is a roadmap that evolves the ‘as-is’ business processes, systems, information and technology of the enterprise from the ‘current state’ to the desired ‘future state’.
The 19 Core Beliefs of EAdirections
1. It is possible to get the support of executive leadership and the business if the value of EA is effectively demonstrated.
2. There is no single approach to establishing an effective Enterprise Architecture (EA) program.
3. When done correctly, Enterprise Architecture is a manifestation of an organization’s mission, and the IT strategy which enables that mission.
4. A 'mediocre' Enterprise Architecture that is broadly understood and consistently implemented has much greater value and ‘hard ROI’ than a 'great' architecture with brilliant engineering which is neither understood nor embraced.
5. Enterprise Architecture can be highly effective despite the lack of a clear business strategy (by ‘teasing out’ business objectives and scenario planning).
6. ‘Business Strategy & Required Capabilities’ must clearly decompose into architecture requirements, which must be clearly supported by architecture principles.
7. The true measure of the effectiveness of an Enterprise Architecture is the extent to which it changes day-to-day behavior and decision making.
8. Many EA programs fail because they confuse 'architecture' with 'standards‘.
9. Picking standards in the absence of a meaningful Enterprise Architecture is 'easy' and 'fun' but it avoids the hard work.
10. Many EA efforts fail because they attempt to be all encompassing and drive for perfection.
11. Effective Enterprise Architecture programs are highly pragmatic and self-evident.
12. Enterprise architecture is a 'process' not a 'project'; it must be on-going and organic, just as a healthy organization is always evaluating its strategies and tactics, measuring its performance and adapting as necessary.
13. An EA framework is less important to success than EA leadership.
14. The development of an Enterprise Architecture should not be outsourced (but outside resources should be leveraged as required).
15. The phrase ‘Enterprise Architecture’ can be misleading to executive leadership and end users. Architects who insist on educating the business on the meaning and nuances of enterprise architecture are missing the point. It is all about the outcomes, not the ‘A’ word.
16. Producing EA artifacts is not enough. Too many EA teams focus on producing frameworks, diagrams, domain architectures, etc. And when they are done they declare victory.
17. There is a consistent set of critical success factors (CSFs) that characterize effective Enterprise Architecture efforts but there are also unique factors that must be identified and considered for each enterprise. (EA-specific CSFs are the subject of a separate whitepaper.)
18. Information technology is a fundamental enabler of innovation, but it requires more than procurement and installation to be an effective innovation vehicle.
19. Most EA programs initially focus on technical architecture, but they must continue to evolve to become a significant, long-lasting business value contributor.
Misplaced Priorities & Misplaced Investments
One of the first things we do when mentoring a new client is to examine their current priorities and the investments they are making in both time and money. Quite simply, EA teams that are struggling to make progress consistently ‘over invest’ in the same activities and ‘under invest’ in others:
Much of our initial effort is spent quickly redirecting the EA team’s activities and targeting ‘quick wins’ in the areas in which the EA team has been under investing.
Most Clients Have A ‘Dirty Whiteboard’ When It Comes To EA
We have found very few clients who have a complete EA green field[1]. Our clients tend to have ‘dirty whiteboards’ (and in many cases the whiteboards are very dirty).
The EA program might be the second or third try. The business strategy may not have been communicated or, as EA teams often suspect, doesn’t really exist. So how do they link EA to it? The appetite within the enterprise (as well as IT) for another round of EA may be nonexistent or even hostile. Some EA artifacts are comprehensive while others are outdated or non existent. The governance process almost always needs significant improvement.
And the EA team often does not have the resources they need nor do they have a clear idea of what they should do first.
Given this situation what are the choices available?
You Have Choices
Door #1: Do it yourself.
Well, if you are confident that you have an effective EA or have the right strategy to deliver one, then you shouldn’t be reading this whitepaper and should be focused on delivering the value your organization expects.
Door #2: Default and hire a consultant to do it.
Almost always this is an expensive and lengthy process. It seldom creates real credibility for the EA team (but it may for the consultants – though probably not). And it too often results in a document that really doesn’t show an in-depth understanding of your business, is at too high a level to be actionable or, worse yet, looks like it has been cut and pasted.
Door #3: Stay in control but get effective coaching.
We find most architecture teams have the talent. They have the passion. They simply lack the necessary experience to effectively navigate the breadth of challenges they are confronted with.
Our approach is to mentor EA teams through a combination of on-site support, on-going reviews, and ad hoc telephone support. If a few days of intense, on-site expert assistance is required, we can provide this. If a specific subject matter expert is required, such as reviewing the first SOA services delivered at a code level, we refer our clients to trusted SMEs.
We help our clients to rapidly identify ‘quick wins’ to gain credibility. We recommend adjustments to their investment in time and resources. We review the current artifacts and make suggestions to rapidly improve their impact and fill in the gaps. We lay out a tactical plan to rapidly improve EA governance and its myriad of touch points.
Directions: Our bias is simple. We believe most EA teams can be much more effective with capable and pragmatic mentoring.
[1] There are exceptions. Typically, these are either startups or spin-offs which had not IT infrastructure transferred to the new entity.
|
 |
|
 |