The purpose of undertaking an enterprise architecture assessment is to understand how well the current architecture is aligned with the organizations needs and goals. Here we talk about the value of assessments and outline the steps you need to take.
By: Jane Carbone, in conjunction with Harris Kern's Enterprise Computing Institute
What is it that makes an enterprise architecture assessment a worthwhile undertaking? In our view, the purpose of architecture: is to align the IT infrastructure with the organization in a way that best promotes the organization's goals, while maximizing the benefit of IT dollars spent. This makes it valuable to clearly understand how that purpose is currently being served. In fact, we often begin the entire enterprise architecture "adventure" by conducting an architecture assessment. So the purpose of undertaking an enterprise architecture assessment is to understand how well the current architecture is aligned with the organizations needs and goals.
What is enterprise architecture?
What we mean by enterprise architecture is the set of plans that describes how all parts of the IT infrastructure need to behave or currently behave to support the enterprise needs and goals – this includes all the data, the functions, the technology, and the people that constitute the infrastructure. And then an architecture assessment becomes the process of
- Collecting and analyzing data about the current state of enterprise architecture
- Drawing conclusions about how well it supports the enterprise
- Reporting results.
Where is the value in it?
Undertaking an architecture assessment often proves valuable in other ways too. It allows for a fact-based understanding of the costs and benefits of the current IT infrastructure to the organization. (This is valuable even if you don't need to make changes—you'll have the facts to support your decision.)
It helps to clarify how the current architecture contributes to perceived business problems or positively supports goals. An assessment looks at both what is working and what is not. Because it surfaces problems with the current infrastructure, assessment helps to identify where re-architecting can improve business costs, improve business functionality or process, and improve IT efficiency (e.g., reduce IT costs, eliminate duplication). Assessment often provides the business case data and the impetus to fund re-architecture since an assessment provides a relatively objective look at what needs to be kept or changed and why.
An architecture assessment requires motivation
When we are asked to conduct an assessment, we basically attempt to follow "police procedure" and identify motive, opportunity, method and "evidence." First we look at motive—why should your organization want to do an assessment? What is the trigger for doing an assessment and why now? The most common "good" motives we have seen are:
- A desire to improve a specific business process or support a major business change (e.g., a new market or service)
- An organization change (e.g., job elimination or consolidation, management restructure)
- An existing commitment to revise part of the current architecture for a major project. For example, one client was funded to re-engineer their billing systems—a very large undertaking—so they wanted us to take a look at what they were proposing and help make some decisions. For us, that began by looking at what was currently in place.
Even though it's tempting to jump into creating target architecture, if you're serious about enterprise architecture, assessment is the right place to begin! If you then decide to continue on to re-architecture, your effort will be far more "science" than "art."
An architecture assessment requires opportunity
If you know you have your organization's commitment to re-architecture, it will probably be simpler to gain their agreement for an assessment. If you're not sure, do what is necessary to gain support, for the purpose of assessment is to discover problems. You may need executive support for an assessment to ensure the bearer of bad tidings is welcomed (not shot!) Even if your organization decides not to undertake target architecture development, assessments still provide substantial benefits, so here are some selling points you might use:
The assessment results provide a clear benchmark against which to evaluate proposed IT changes (e.g., if you're considering CRM, a new database, or a new platform component, an assessment identifies how the change will "fit" into the existing infrastructure).
The assessment may highlight or identify major "fix" projects and impacts. Your organization may still decide to fix a "piece" of the infrastructure (e.g., consolidate a couple of databases) even though they don't want to do a wholesale re-architecture.
The team who conducts the assessment becomes a highly trained resource that can make informed decisions or recommendations for management about proposed IT solutions including risks and consequences. This is valuable whether you plan to develop a complete IT architecture or you are trying to determine if or where your CRM/EAI/ERP/Portal/Web Services (you get the idea…) fit—you still want your infrastructure to be aligned with business goals and ensure that IT funds are spent where they are needed.
Because of our "adventures" in architecture, we developed the "Toolkit for Enterprise Information Architecture" (hereafter referred to as "Toolkit") as a practical response to many architecture "lessons." The Toolkit is a set of practices (methodology) for creating the outputs for each of our three enterprise architecture frameworks shown in Figure A. We apply the Toolkit methodology to teach architecture, develop enterprise architectures and conduct architecture assessments for clients.
Figure A--Toolkit Frameworks
We use the Toolkit for architecture assessment because:
- It supports assessing enterprise architecture vs. e.g. technical architecture only.
- It considers the business needs as primary architecture drivers.
- It provides a natural "segue" to target developing architecture.
We use the Toolkit differently for assessment than for architecture development. The high-lighted "cells" in Figure A illustrate where we focus our effort in an assessment.
At a high level, the following steps identify the parts of the Toolkit we use to collect "evidence" and conduct enterprise architecture assessments:
STEP 1: Business framework—Identify the business current and target states
To develop a useful view of the business, we develop current and target state descriptions. In general, our data collection follows this path:
Document collection and analysis: Collection of formal/published, easily available, commonly shared and understood views of executives about the organization (e.g., mission/goal statements, key initiatives).
Interviews: Less formal collection of views from executives and key players in the organization to identify current business process problems, describe current business plans and direction, and clarify how the current IT infrastructure is perceived to contribute to current business problems.
We organize our outputs into lists and/or process flows of current and desired states.
STEP 2: Architecture framework—Identify current state architecture
Our goal in this step is to put together architecture models that illustrate the existing relationships between data, functions and platform components. We also collect or develop inventory for existing data, function/application, and platform components. We strongly recommend the capture of cost data associated with Inventory. When these documents do not exist or are outdated, we develop them by conducting architecture interviews, reviewing existing documents, and preparing drafts for review and update.
STEP 3: Analyze
In this step, we apply analysis techniques to the business current and target state descriptions to identify business problems, gaps and opportunities. We also apply analysis methods to the current state architecture to evaluate where the architecture contributes to business problems and gaps.
STEP 4: Consult the framework for implementation
In this step, armed with our lists and analyses, we examine our outputs for never-to-be-overlooked "political" considerations. That is, we test our outputs against current processes, measurements, and organization "readiness"—is the organization extremely change-averse? This step also provides a "sanity check." For example, if our assessment indicates the need for a complete organization restructure or wholesale business process changes, we may want consider biting off a smaller piece of the pie. When we have a realistic set of problems and gaps (think ten, not hundreds), we assemble the data—first for a "readout" presentation, where we encourage discussion (is this the "right" list of problems?) and finally into a more formal report on the state of the architecture. Very often, a clear set of recommendations has emerged, so include them here; this is a perfect opportunity to propose target architecture work.
I know first hand that what we have described here requires significant knowledge, work, and tenacity, but the results are well worth the effort. I know of no more effective, less haphazard approach to clearly understanding how IT supports the business and where it valuable and cost-effective to pursue change.
The Harris Kern Enterprise Computing Institute (www.harriskern.com) is a consortium of publications – books, reference guides, tools, and articles - developed through a unique conglomerate of leading industry experts. Together with Prentice Hall/PTR, members of the Institute have published several 'how-to' books, including such titles as: IT Services, IT Organization, IT Systems Management, IT Production Services, High Availability, Managing IT as an Investment, and CIO Wisdom to name a few.