1. Purpose of White Paper.doc

Enterprise Architecture White Paper

Achieving

Business-Aligned and Performance-Based

Enterprise Architectures

An ICHnet.org White Paper

On

Enterprise Architecture Assurance

August 1, 2002

ICHnet.orgArchitecture Resource Center

904 Clifton Dr. Alexandria VA, 22308703 768 0400 (pn) 703 765 9295 (fx)

ICH Confidential and Proprietary. All rights reserved. www.ICHnet.org


Preface

The Interoperability ClearingHouse (ICHnet.org)

ICH’s charter is to aid business and government executives in creating effective Enterprise Architectures and Asset Management. It is an industry collaboratory that provides consulting services, architecture research, and education to ensure the success of its clients and members.

ICH value proposition: ICH has a unique architecture alignment and validation process that effectively maps common business needs to interoperable solution architectures. The ICH facilitates architecture communications with principle members of the IT value chain (standards groups, industry associations, CIO communities, solution providers, integrators) which results in highly effective working relationships to better enable stakeholder understanding, interoperability and information sharing. Meaningful work gets done by the IT value chain with ICH behind it.

ICH’s primary focus is to assist value chain members in creating, maintaining, and operating world class Enterprise Architecture with scrupulous objectivity, enabled by re-usable solution frameworks.

ICH is a Non Profit (501 C 6) which provides Enterprise Architecture, IT Capital Planning and Portfolio Management Services to its members and to its public sector constituents. These services include; mentoring, IV&V, measuring performance outcomes, research, and consulting support. ICH focuses on the entire EA lifecycle with specific attention to E-Gov/E-Biz domains, Cyber-Security, Critical Infrastructure Protection, and Detailed Business and Technical Framework alignment to the IT infrastructure services. The ICH architecture alignment offerings are delivered through formal EA templates, reports, training, in-context research, hotline, and on site facilitation. The consortia model enables the ICH to tap into the existing communities of interests and knowledge sources, and to discourage an NIH approach that results in paralysis through analysis. To prevent conflicts of interests, the ICH employs a govt/industry approved architecture alignment process, and does not engage in activities that would compromise its objectivity; implementation, buy/selling of products, nor lobbying.

ICH Architecture Resource Center provides a wide range of architecture remediation and support services through firm fixed price and project engagements.. Services can be accessed through GSA Schedule 70, and FEDSIM, 8A contracting vehicles.


About The Authors

John Weiler is the Co-Founder and Executive Director of the Interoperability ClearingHouse (ICHnet.org). Mr. Weiler has been a leading force in transforming the Architectures from an art into a science (architectonics). He is active participant on many industry standards initiatives and CIO Council working groups including; OMB Solution Architecture Working Group, IAC Enteprise Architecture committee, Open Applications Group, OASIS/ebXML, Federal Enterprise Architecture Working Group, Secure E-Business Program Committee, Financial Services Technology Consortium, DISA.org, and Object Management Group.

Mr. Weiler has 25 years of IT Portfolio Planning, Configuration Management and Enterprise Architecture experience with some of the most progressive IT organizations in government and industry; Boeing Aerospace, May Dept. Stores, Giant Food, Booz Allen Hamilton, Northrop-Grumman/PRC, Object Management Group, NASA Space Station, Patent Trademark Office, Dept. of Navy CIO, DARPA, Office of the Secretary of Defense, and LTV Steel.

Rick Smith is the Chief Operating Officer for the Interoperability ClearingHouse (ICHnet.org). Rick has 35 years of IT industry experience, including 15 years with the Gartner Group in business development and research management. He brings extensive experience in business transformation and architecture assessment.

Mark Nelson is a member of the ICHnet.org Architecture Advisory Board. Mark has defined and implemented architecture and portfolio management programs for: The Ford Motor Company, Sprint PCS, Discovery Channel, NorthEast Utilities, Coca Cola, Signet Bank, and The Wallem Ship Management Company. Mr. Nelson was responsible for architecting enterprise solutions for BAH, Boeing, Oracle Complex Systems and Ernst & Young (where he helped evolve the Fusion Offering).

Special thanks to Kevin B. Kreitman, Ph.D, of The Aerospace Corporation, for her insights, advice and contributions to the white paper.



Table of Contents1. PURPOSE OF WHITE PAPER................................................................................................................1

2. EXECUTIVE SUMMARY AND VALUE PROPOSITION...................................................................1

3. CRITICAL SUCCESS PATTERNS FOR ENTERPRISE ARCHITECTURES.................................2

4. KEY CONCEPTS OF AN ACTIONABLE ENTERPRISE ARCHITECTURES .............................3

4.1 FOCUSING ON ALIGNMENT, VALIDATION AND ABILITY TO IMPLEMENT..............................................54.2 THE BUDGET AND CAPITAL PLANNING PROCESS.................................................................................64.3 USING SOLUTION SETS INSTEAD OF APPLICATIONS AS PART OF THE FRAMEWORK.............................7 ....................................................................................................................................................................84.4 MAPPING SOLUTION SETS AND APPLICATIONS.....................................................................................94.5 ALIGNMENT AND TRACEABILITY...........................................................................................................9

4.5.1 Deconstructing Architecture Framework Components................................................................94.5.2 Value Chain Based Assessment...................................................................................................114.5.3 Measurement and Valuation.......................................................................................................12

4.6 ADAPTIVE ARCHITECTURES: NORMALIZED COMPONENTS..................................................................124.7 EFFECTIVE DEPLOYMENT....................................................................................................................134.8 NON-PRESCRIPTIVE OBJECTIVITY.......................................................................................................134.9 EXPECTED RESULTS FROM AN ADAPTIVE ENTERPRISE FRAMEWORK-METHODOLOGY......................13

5. CONCLUSION: STATE-OF-THE-PRACTICE..................................................................................16

IMPLEMENTING SUCCESSFUL ADAPTIVE ENTERPRISE ARCHITECTURES........................18

DEFINING CONTEXT, SCOPE AND EXPECTATIONS......................................................................................18EA MISSION STATEMENT AND PROJECT CHARTER...................................................................................19INITIATE EA PROGRAM EFFORT: .............................................................................................................19THE KNOWLEDGE GENERATING PROCESSES..............................................................................................20 FACILITATE EA DISCOVERY:....................................................................................................................20IDENTIFY OPPORTUNITIES AND GAPS.........................................................................................................20IDENTIFY PATTERNS AND DEVELOP CONSENSUS.......................................................................................20 COMPLETE DEFINITION OF ARCHITECTURAL COMPONENTS:.....................................................................20ACTIONABLE ARCHITECTURES: FINAL CONSENSUS...................................................................................21EA IMPLEMENTATION PLANNING..............................................................................................................21



1. Purpose of White Paper

The purpose of this white paper is to provide a framework for assessing what constitutes best practices in the development of Enterprise Architectures, and reviewing the state-of-the-practice. The paper provides clear criteria for assessing enterprise architecture frameworks, methods, and implementations. Its primary source of validation is practitioner experience in providing enterprise architectures to large commercial concerns, either as standalone activity, or as a component of a business process engineering effort.

2. Executive Summary and Value Proposition

“Business productivity soared in the first three months of the year, scoring its biggest gain in nearly two decades…”

The Washington Post: 8 May 2002.

Information technology and better business processes have led to a remarkable growth of productivity in the world wide economy. At the same time, the Internet paradigm has driven refactored redundant “silo” based information technology architectures into high availability n-tier common services and knowledge tools which directly benefit the end users and their organizations in extending the reach of their capabilities.

However, empowering the end user does not come without a cost, and that cost is in the adoption of a common set of standards, and design patterns which facilitate the business model, meet the requirements of the task at hand, while still effectively dealing with the inherent complexity that lies just beneath the surface of Information Technology that must itself adapt to rapid technological change as evidenced by paradigms such as Moore's Law.

The role of the Information Technology architect is to identify the relevant forces and patterns which exist independently of the natural complexity that comes from software, data and hardware architectures, and therefore mitigate the risks of software and project failure, while at the same time allowing for incremental growth which does not produce overly tight “coupling” of data structures, which in turn can lead to extensive change management costs that directly result from brittle architectures.

Thus the architect must be able to translate the executive vision into a repeatable, and common level of services that can be delivered within budget,


be adaptable to the needs of clients and end users, and meet the requirements of the business case in issues such as project management, and delivering value while coping with immense scale. For example, DOD technology which has been applied to cost controls on large scale contracts such as ANSI 748 EVA can be applied in a “lightweight” and more business friendly manner to prevent “runaway” IT projects.

At the same time, the role of the localized “data owner” has come into question. Who owns personal identifiers for example? Is it the end user, the human resources department, the IT department, the Social Security Administration, the state DMV, the DBA, of a particular database, or an administrative cadre within a particular department? And if no-one owns it, who is therefore responsible?

If that ownership is shared, what is the relevant policy which governs the storage and subsequent handling of that data, within the agency, between agency and private enterprise, between agencies, or as part of an international data flow which is governed by agreements such as Safe Harbor as part of an extendedvalue chain.

Data ownership issues can rapidly lead to “fiefdoms” of protective bureaucracies with complex data structures that inhibit the sharing of information, and inhibit an effective policy of privacy protection. Since personal identifiers (naming) are a “common” service item, such as domain name system information (DNS), then it can be rapidly seen that a common data structure for this type of information is relevant, but the normal case is that many different forms of this information are present, and tightly coupled into other data structures. This is one example ofa common service item which can functionally shared between agencies and private enterprise, lowering costs for all concerned, while still allowing for added value and customized approaches for specific requirements.

The advent of the Internet, and it's more powerful collaboration tools such as e-mail and the WWW, are based on both common services, and meta-layer technology which is capable of successfully abstracting these elements into flexible data models which are easily accessed by the end user and related systems, and thus transcend the complexity of data owner specific functional requirements. This comes from correctly recognizing and applying design patterns which are in effect best practices for dealing with common IT problems.

The current problem frame in IT development is paradoxically related to the advancement of large scale enterprise framework approaches where requirements have been pre-determined by vendors who previously were selling products that were unrelated and application specific. Often the CIO is being asked to accept a complete development, and deployment package like an offering from a diamond wholesaler who is backed by a cartel. The offer is made once, and if refused, is put away until the following licensing cycle.


The decision is reduced to take it or leave it, with no real ability to pick and choose what works best, since the complexity, has been successfully abstracted into a facade pattern by the software manufacturer and therefore impossible to effective deconstruct without an independent enterprise architecture.

But even if a best of breed COTS approach is taken, where is the common architecture that will tie it all together? Perhaps a COTS approach is valid, but may not meet Common Criteria security standards endorsed by NSA and NIST?

Point solutions are clearly not the answer. As suchmany organizations have been paralyzed by the complexity of the technology, and organizations that have decided to pursue IT projects still show an unacceptably high failure rate: IT project failures in industry and Government are at 54% and 72% respectively. This can be directly related to a failure to understand the requirements which relate to executive vision and the business case, and pursuing projects which are department specific, (because that's where the funding is taking place) without also working on common services which are based on functional criteria of better serving the citizen and end-user on a higher order of magnitude. The next leap, towards that higher order of magnitude must be in the realization of common web services, while preserving the expertise and knowledge domains of specialists in government who can address specific problem frames, and innovate in those specific locales.

Our great leap forward in IT driven productivity has created a plethora of overlapping products and standards (the standards “swamp”) that both increase the complexity and risks associated with every decision a CIO makes, and well as leveraging the gains that can be achieved. Each “hype cycle” brings on a claim of a new “silver bullet”, but the fundamental problems are still intractably hard, and are as much human and social issues as issues related to technology. IT can and does act as disintermediator in regards to business relationships. Thus the CIO is working on fixing a train which is moving 150 miles per hour, and the technology and tools are changing all the time. To get off this cycle requires a refocus on business processes and relating IT to those business processes instead of looking at IT as a separate entity.

It is extremely difficult to construct a technology based framework that properly relates the vast array of overlapping products and standards, much less an enterprise framework that can be explained to financial decision-makers or the end user community. However, this is the task at hand, and the technology framework must be part of the overall act of creating value for the enduser and customer, not an end in itself.

All this puts IT executives at a crossroads. There are tremendous rewards for organizations that are able to harness the vast array of available options into a comprehensible framework of adaptive components and supportive infrastructure that meet the rapidly evolving needs of their end user communities. Enterprise Architecture process and framework must effectively align IT resources to the


business drivers and processes that they enable. The resulting solution templates, should be maintained within a govt/industry independent clearinghouse that reflects the view points of each of the stakeholder in the IT value chain. The concept of a lexicon, that enables the mapping of common business needs to technical solutions, can help retain these relationships.

Both government and Industry have recognized the role Enterprise Architecture, plays in both operational and IT effectiveness. Unfortunately, while most Enterprise Architecture frameworks and processes that are gaining currency are able to generate good descriptive architecture models, they do not create actionable, adaptive architectures that address today’s rapidly evolving complex environments.

In its role as a “thought leader” and champion of open and adaptive architectures, the Interoperability ClearingHouse has identified what organizations need to do to create Enterprise Architectures that meet the needs of today’s tough, but opportunity rich environment.

3. Critical Success Patterns for Enterprise Architectures

An effective Enterprise Architecture Framework and accompanying methodology produces Enterprise Architectures that provide:

1.Cost efficiencies 2.Improved operational service quality3.Improved operational alignment of value chain resources: people, process, and

technology4.Improved business and customer alignment5.Change-tolerant and “non-brittle” results6.Two-way Validation: (1) Measurable alignment with organization business

drivers; (2) Availability of real-world solutions and products to support the architecture.

To accomplish this, an Enterprise Architecture and Methodology must be:

1. Community Based: The effort must include representatives from all key stakeholders and value chain members into the process: Business Domains, Senior Management, Business Partners, and customers. This is critical to obtaining “buy-in,” ongoing support and business/customer alignment.

1.2. Comprehensive in Scope: It must address all aspects of the bounded Enterprise and “Extended Enterprise Value Chain,” directly associated with information technology enabled: business processes, applications, information, and infrastructure, standards, policies. Most enterprise architecture efforts are too inwardly focused, and do not include the customer and key business stakeholders. This results in mis-aligned

peterb, 01/03/-1,

Jargon is part of the problem. Notthe solution.


architectures, and lost opportunities to gain competitive advantage and government effectiveness. ” This focus directly supports the E-Gov, cross- community and Homeland Defense initiatives critical to government today by development of common services which relate to functional requirements of the stakeholders,

3. Alignment Driven: It must address the need to directly align architectures to organizational drivers in a way that is comprehensible and transparent to all key stakeholders, with continued traceability of architecture initiatives to business drivers.

4. Metrics Driven: It must provide mechanisms that allow for a “drilldown” from the abstract high level vision to the specifics of the WBS in terms of the requirements. At the same time the reporting requirements should not be substituted for, nor take precedence over the achievement of the goals.

5. Able to address the need for Adaptive Environments: It must include analytical methods that support the development of architectures that are adaptive to changing business drivers, new opportunities or roadblocks, and architectures that provide implementation options that mitigate risks and are adaptive to budget and other organizational constraints.

6.Able to Provide Normative Output: The architecture must produce tangible results, and the processes must be relevant to the participants, i.e. “Eat one's own dogfood”.

7.Non-Prescriptive: It must not presume an implementation approach: COTS or Bespoke.

8.Must be repeatable.9.Can be optimized though the collected metrics at a CMM level 5 of

software project maturity.

4. Key Concepts of an Actionable Enterprise Architectures

A comprehensive Enterprise Architecture includes all the components presented in the ICHnet.org Enterprise Architecture Reference Model presented below. While this reference model is important, in that it outlines all the architectural artifacts required, it does not completely address the actionable aspects of an architecture, which deal with alignment, validation and actual integration into the organization. These must be supported with an effective methodology for architecture development.


ICHnet.org Enterprise Architecture Reference Model

Enterprise Architecture Drivers/Inhibitors

Missions, Goals and Objectives

Revenue Enhancement/Cost Reduction

Industry Shifts,Obsolescence, Recent Investments

Organizational ChangeConsiderations

Budget Legislative DirectivesMandates,Regulations

Enterprise Architecture

BusinessProcess Layer:

TechnologyEnablement Layer:(Application)

DomainArchitectures

Component Security Networking Platform Infrast. Mgmt

Data

Business Driver – Process Mapping

Functional Hierarchies,Location Mappings

Process Maps/BSOMExtendedMaps

ProcessDescriptions,PerformanceMetrics

Security and other Policies

Technology Enabler – Process Mapping

Solution Set: 1. Function/Feature,2. Performance Characteristic3. Performance Measure

BusinessProcessPatterns

Solution Set Patterns

Application Standards & Policies

Information

Layer: Data Dictionary

Key Information Classes

Data Standards & Policies

Data Movement Req.

DataPatterns

InfrastructureServiceLayer:

Solution Set & Information - Infrastructure Mapping

Infrastructure Enabler Description

Topology Mappings, High Level Protocol Stacks

IT Mgmt Architecture, Standards & Policies

Infrastructure Patterns

Solution Set – Information & Infrastructure Mapping


4.1 Focusing on Alignment, Validation and Ability to Implement

Developing a complete architectural model of every component in the organizational value chain is a daunting task. If done as part of an Enterprise Architecture effort, it will tend to divert the focus away from alignment and validation. It also has the strong potential for impeding the important cross-domain collaboration process critical to the overall successful definition and implementation of the architecture. This is not to say that a complete architectural description of the various components is not valuable, but rather to say that their comprehensive definition is better done outside the scope of the Enterprise Architecture effort. The level of architectural detail within the Enterprise Architecture should be governed by the overall objectives of achieving collaboration, alignment, validation and transferring those captured values to an implementation and the management of risk:

Business Process Layer Definition: Can be limited to core functionality with ability to drill down to added detail as necessary by mapping of hierarchies, without specifying in advance the level of detail. Business is by nature a consensual and collaborative effort so placeholders must be established, but the level of detail that exists within those placeholders is dependent on the demonstrated need and ability to define common terms and metrics. The exchange of signs can take place at the level of a handshake, or a contract, but the effective level of detail must be capable of successful abstraction to be considered a process.Technology Enabler Layer Definition: Level of detail is derived from the process definition effort, which defines the required Solution Set Functions and Features.

Information Layer Definition: This activity defines key information classes within a domain at a level of detail that can be used to access their affinities and properly align them in the overall architecture, and provide a description of the Data Movement and Security Services required from the infrastructure.

Infrastructure Layer: This layer defines the services provided, not how they are implemented.

The above level of detail is enough to develop a comprehensive Enterprise Architecture that leads to the proper alignment, validation and implementation of processes, information and technology. Additionally, the Enterprise Architecture components can more readily be extended in more detailed domain specific architectures:

Business processes can be further defined during the design phase of a process implementation (Business Engineering Discipline).

Solution Set Functions and Features, and high level information models will provide the basis for COTs selection and further requirements definition, and data design.


Infrastructure Service definitions, developed as part of the Enterprise Architecture, are a natural starting point for defining an infrastructure architecture component.

4.2 The Budget and Capital Planning Process

While every organization’s budgeting and capital planning process is different, and the Enterprise Architecture integration with the process will vary, there are several critical success patterns associated with a successful EA implementation:

1.The EA implementation is funded as a separate program in itself2.There is a process for “baking-in” the EA to other capital programs3.There is a feedback loop with metrics for measuring performance and

compliance.4.The EA has continued executive sponsorship.

The figure below outlines the ICH view on the relationships among Enterprise Architecture, Domain Architectures, and the Budgeting Process integrating Into the Budget/Capital Planning Process.

Stakeholder Views

EA DRIVEN

Programs andInitiatives

Domain Specific Architectures

EA Requirements

OtherPrograms

EA ImplementationPlan

PerformanceMonitoring

EAPrograms

Iteration


4.3 Using Solution Sets instead of Applications as part of the Framework

Most frameworks have applications as a component of the architecture, when in fact an application as an organizational entity typically has more to do with the marketing strategy of a vendor, or the needs of a software development effort, then it has to do with architecture. Using applications as an organizing entity in architecture will most likely lead to mis-alignment:

Application based frameworks lead to mis-alignment

Using applications as constructs in an architectural framework made more sense in the past when there was a closer alignment between applications and processes. However, in the component and package driven environment of


Resulting Model

Process

ArchitecturallyAssociated Application

Process

Solution Requirements (Gaps and Redundancy) Go Undetected

Process Process

ArchitecturallyAssociated Application

Architecture Does Not Reflect the True Process Driven Solution RequirementsReq. Sol. Set

Req. Sol. Set

today, it is dangerous. The misconception of the alignment between applications and processes is a major reason for the high failure rate for CRM implementations. CRM is a thin layer of functions and features that cross a very wide range of processes. “ CRM as a standalone application usually results in mis-alignment.

As illustrated below, a valid architecturalapproach, abstracts from the process design the function and feature requirements for the process into “solution sets”. This approach results in better alignment and reduces inefficiencies from gaps and overlaps result from the more typical application centric approach.

Process – Solution Set Driven Architecture

Marketing Sales Delivery Support

MarketingSolution Set

SalesSolution Set

DeliverySolution Set

SupportSolution Set

CRM Solution

Other Solutions, e.g. Inventory Mgmt

CRM Application Centric Architecture Leads to Mis-Alignment

CRM Centric Processes

Non-CRM Related

Processes Processes

CRM SolutionOther Related Solutions


4.4 Mapping Solution Sets and Applications

A Solution Set contains a description of the required functions and features required by the processes it supports. It a simple matter of mapping those functions and features the functions and features of the existing application support base to determine gaps and overlaps:

The above process works best when you have normalized models that have wide industry acceptance. Fostering the development of commonly accepted, normalized models is a major a focus of the ICH collaboratory and research.

4.5 Alignment and Tracability

A successful Enterprise Architecture provides service layer access points to the other logical layers of the overall model, thus providing critical abstraction on the enterprise view level. Mapping can help focus on the role of a component within the entire IT ecology, and ontology. However, disruptive drivers are a given, and produce imbalances which can lead to economic gain or loss for actors by the mechanism of complex adaptive micro decisions in regard to utility.

Cooperative or non-cooperative behaviors are exhibited in the normal course of doing business as value judgments are formed, and re-formed on a daily basis.

Users can and do introduce technologies into the workplace which are disruptive in both positive and negative fashions in the roles of client, and producers. As mentioned earlier, then, at a certain level of scale, how can the enterprise adapt to these rapid changes, and relevant second order effects, such as security, when new IT enablers are adopted by end users? For example, the abilityto listen to a choice of music, or piped in music, can haveenterprise effects when dealing with Digital Rights Management. Someonebringing up a Wireless Access point might have security considerations.

The alignment also will provide the basic construct for building the business case for the component’s justification. Building the business case for an architectural component suggests that that component can be mapped to a


Solution Set A

FF1FF2FF3

FF4FF5FF6

OverlappingApplication

Support Gap

business or organizational driver, and that its estimated benefits, cost, risks, and interdependencies be modeled and quantified within an acceptable time framework.

Decision makers however, may tend to ignore this framework in terms of more subjective judgments, advertising, business relationships, if the quality of the resultant business case is not validated by subsequent results. Since EVA analysis indicates that only a small percentage of IT projects actually achieve a positive ROI, executive risk must be considered on backing a specific project, thus lowering that risk, is congruent with career advancement and more satisfied customers, so a workable architecture can evolve from the extant resources, as a continuing model of improvement, or can degrade into the “big ball of mud” pattern, characterized by data silos, and expensive change management costs, but an organizational structure that remains secure in their roles, while compromising overall effectiveness in meeting critical needs. Thus the collection of non-actionable data which can not lead to effective decision making, (dead data) that will not be used, but is done pro-forma, should and can be questioned under Clinger-Cohen as to effectiveness.

4.5.1 Deconstructing Architecture Framework Components

An architecture component is a part of the overall framework that is significant enough in itself to be considered from a design, costing or implementation standpoint. : Deconstructing the architecture into components is key to enabling the analysis process. It allows for multidiscipline teams to iteratively work together to create an enterprise view, while at the same time, dispersing into discipline specific teams performing detailed analysis and validation. A simplified view of how a framework would be deconstructed into components is shown in the next figure.



Process Grant Requests

Field Grant Program Inquiries

Qualify Grant Requests

Process Grant Approvals

Deconstructed Process Components:

Grant Processing Solution SetProvide Web

AccessProvide access to

DUN InformationScore RequestsProvide approval

process workflow

Grant Processing Solution Set:

Grant Request Information StoreRequestor ProfileRequest Status

Grant Award Process:

Active Grant Mgmt Information StoreGrantee ProfileActive Status

Information Model for Grant Award and Mgmt Process:

Deconstructing a Framework into ComponentsSimplified Extract from Grant Process

Remote Access Services:Account Set UpSecure Access

Data Movement Services:Batch ProcessingAggregation

Security PoliciesSecure transaction authentication requirements

Note: Matrices are most likely the most practical tool for representing component relationships

InfrastructureServiceComponents

4.5.2 Value Chain Based Assessment

Interrelationship among the components can be maintained using cross-reference tables and matrices. Those matrices must properly allocate the benefit, cost and risk contributions of each architectural component. Misallocation can lead to major disasters, as can be witnessed by the mistake made by a large trucking company. The trucking company embarked on a $150 million effort to completely replace their mainframe and AS400 “stovepipe” infrastructure with a process driven distributed environment. This included enabling the truck drivers with wireless hand held devices, which was the focus of the initial effort. They knew that the technology was risky, but thought the risk worthwhile given the perceived benefit. The fact is that the architecture methodology used mapped wireless directly to business drivers, rather than to the solution sets it supported. The result was that the contribution wireless made to the overall improvement was grossly exaggerated. A post-mortem mapping of the various architectural components using the prescribed structure showed that the real gains were from less risky loading dock automation, not from enabling the truck drivers.

An effort to track WTC scrap removal by globally identifying trucks and truck drivers using wireless tracking allowed for highly effective traffic routing, and prevented diversion of scrap material by organized crime. Thus resulting in a extremely high ROI by an indirect process mapping to a business need, by decoupling the identification process from the complexity of the effort., There was no previous infrastructure, and it had to be built on the fly within a disaster area, and existed as a valid architectural layer without reference to an existing architecture.

The logical way of doing this is to organize the various disciplined architectural components in conformance with their position in their value chain:



Business Needs

Processes

Solution Sets and Information

Infrastructure Services

Standards & Policies

Common Mistake

DriveGovern

Define

Support

Require$$$$

Enable

Service

4.5.3 Measurement and Valuation

Each architectural component must include metrics for evaluating its contribution and cost to the overall enterprise value chain. Both quantitative and qualitative benefits and cost metrics can be captured for each discrete component and their contributions to the value chain allocated. A typical approach would be:

Cost Allocation of Infrastructure to Solution Sets:

In the above example, cost is allocated at both the Solution Set level, and at the Function-Feature level. Cost would be allocated at a Function-Feature level when those Function-Features have serious cost impacts on there own, and need to be evaluated separately.

Cost and risk interdependencies would flow up. Correspondingly, benefits justifying the expenditures would flow down.

4.6 Adaptive Architectures: Normalized Components

An Enterprise Architecture that uses componentization and normalization to analyze business needs and IT opportunities allows the development of a neutral cost/risk analysis. This cost-risk analysis allows you to understand how brittle or adaptive your chosen implementation will be. This enables IT managers to project what if scenarios regarding the benefits and limitations of particular software applications packages and standards choices without resorting to stealth development practices. It should be noted that projects are also budget targets, so normalization should occur in regards to ROI that includes IT as part of the business development model, and not as simply a cost item or necessary evil.

The architecture can help focus on the underlying risks and limitations associated with these choices—how flexible and extensible or how dependent on particular infrastructure or hardware or vendor-specific products an architectural choice makes them. This analysis process:

1.Provides a re-usable mechanism for the standard CIO strategy of determining how adaptive tand resilient the currentarchitecture is: Is there a single point of failure that would compormise functionality? What

InfrastructureService

Total Cost

SS1 SS2 SS3 SS5 SS6

FF1,2,4 FF 2,5

InfrastructureService A

$$$$ % %

% %

%

%InfrastructureService B


are potential contingencies around that dependency? In government, what are the acquisition policy, O&M, or legal implications of the choices?

2.Clearly segments architectural components so that they can be analyzed for cost and risk. The cost and risk analysis can then be traced back to the business drivers for a comparison to benefits.

3.Divides the architecture into manageable chunks facilitating its continued evolution, but without fragmentation.

4.Provides a framework and structure for building a knowledge base of architectural component requirements and characteristics that can be used to evaluate new opportunities in a continuous improvement program.

Additionally, normalization and componentization provides a mechanism for communicating pieces of the architecture to teams doing product selection, detailed process and workflow design, or more detailed architectural descriptions that are beyond the scope of the Enterprise Architecture.

4.7 Effective Deployment A major predictor of the extent to which architecture influences the actual IT asset base is the quality of the implementation plan. The plan factors in the competing forces impacting implementation, which typically include:

1.Potential ROI;2.New opportunities provided by recently developed technology enablers;3.Organizational and budgetary constraints;4.The need to amortize existing and ongoing IT investments; and5.Maturity of technical alternatives and other implementation related risk

factors.

Being able to deconstruct Enterprise Architectures into normative components provides a mechanism for experimenting with various implementation sequences in an effort to reduce risk and adaptability. A typical approach would be to develop a decision model containing varying scenarios, allowing benefit, cost and risks to be analyzed. This requires an adaptive architecture framework. The Federal CIO Council’s: Guide To Preparing Enterprise Architectures, rightly puts emphasis on implementation planning, and incorporation of the EA into the capital planning and budgeting process. The ICH Enterprise Architecture framework provides the adaptability that results in actionable architectures. Deconstruction can also recognize softer values involved in the motivations of enterprise actors who may have invested value in a particular approach due to the complexity of the knowledge base. Recognizing these more subtle biases can be effective in reaching agreement between competing schools of thought as to what is effective in solving a particular problem. How that agreement/disagreement matrix is dealt with is critical to forward movement,


since actors may argue from the POV of a vendor based approach, a non-vendor approach based on theory, or a strictly pragmatic, “I can code that in five minutes” approach to a specific problem. Deconstruction is dependent on discourse and recognition that there will always be differences, and less likely to be large scale agreement on issues regarding software and hardware, since the majority of actors are primarily motivated by economic incentives of a specificapproach and not the overall architecture. The SWG has expressed concern over a deadlock between major software architectures that are vendor based, that canbe resolved, for example, by a neutral approach such as ODP 96. One could also take the approach of the IETF of loose consensus and running code, as well as the heavily process oriented models of most consulting companies. But in any respect, the design patterns which constitute the architecture are persistent, and underlie the approach of any particular architecture, which needs to establish standards, and provide for improvements on those mechanisms to lower riskand provide a greater ROI.

4.8 Non-Prescriptive Objectivity

Many of the Enterprise Architecture Frameworks that are gaining currency today very much resemble the early phases, and, in some cases, the later phases, of an SDLC. This leads to a fair amount of unnecessary work and a loss of focus, as the level of specificity goes way beyond what is required at the Enterprise Architecture level.

4.9 Expected results from an Adaptive Enterprise Framework-Methodology

The ultimate operational goal of any organization is to optimize the alignment of their customer needs, business strategy, organizational culture, people, processes and technology. This optimization, not only provides for efficient and cost effective performance, but also helps ensure proper execution of the defined organizational goals and objectives. However, by itself, Enterprise Architecture taken by itself, is not a panacea for success. It requires that: (1) the organizational goals and objectives are the right ones, and (2) there are no inhibiting organizational, cultural, budgeting process, and people compensation issues. Since 1 and 2are always present, this makes architecture impossible, and thus the architect must also be able to adapt to 1 and 2, while continuing to maintain control over scope. There never has been a major project that will transcend people andshifting goals.

These above items are beyond the scope of typical Enterprise Architecture, but needs to be factored in by those that can be most directly responsible for seeing the value in changing the organizational structure. The nature of information technology changing organizational structure is starting to be understood by


social scientists, especially in regards to information sharing. The Taylor approach to scientific management created fragmentation, specialization, and division that suited the mass production of goods and services based on standards. Mass consumption facilitated this process. The enterprise value chain approach re-integrates value producers into the delivered product or service, and allow a conscious building of infrastructure that was previously mediated by early adopters who could see the interplay of major value chains. Therefore, even a fully enabled adaptive Enterprise Architecture effort may only achieve incremental results, unless the social affects are also addressed, because the architecture’s effectiveness could be limited by the organizational issues presented above. As such the government needs to be careful about pickingwinners and losers, if the marketplace is effective in doing so, but at the same time can promote the idea of standards which are effective both in business and government as part of a partnership.

This is not to say that Enterprise Architecture efforts are not integral in themselves, and don’t bring exceptional value. However, if the hope is for revolutionary change in an organization, a more comprehensive business process engineering approach, that includes an Enterprise Architecture might be required. The table below provides a comparison of the two, and the following diagram illustrates their varying scopes.

Enterprise Architecture Business Process Engineering

Driven by management perception that information needs are not being met, but current business processes are working

Driven by management perception that major changes need to be made to the operation due to ineffective execution, or radical changes to the business environment

Lower risk with reasonably assured payback; providing there are no major process alignment issues

Higher risk with higher reward; requires senior management commitment to major change

Greater emphasis on information and technology

Greater emphasis on organization, culture, people and processes

Less impact on organization structure, people and culture

Considerable impact on organization structure, people and culture

Implementation and execution is as important to success as organizational change management

Organizational change management is the primary driver of success


Enterprise Architecture [EA] is one component of an aligned organization

BPE

Scope

Total Alignment

Business EnvironmentOpportunities and

Limitations

Business Strategy, Mission, Goals, and Objectives

Organizational Design

Process Design

Enterprise Architecture DesignProcess, Information, Technology

Enterprise Arch. Scope


5. Conclusion: State-of-the-Practice

Both industry and government have recognized the special value of Enterprise Architecture. The government’s embrace of Enterprise Architecture, while partly driven by the mandates of the Clinger – Cohen Act, OMB FEAPMO and OMB Circular A130, is also driven by the complexity of their current IT environments, and the movement from platform-based data processing into Web-based services. Industry has been motivated by the simple reality that they need Enterprise Architectures to remain competitive and support business continuity as they consolidate their ten-year long spending spree on disparate IT resources.

While this is a positive move, a fundamental problem remains. In the rush to implement Enterprise Architectures, most current frameworks and methods are in need of updating to address today’s realities. The virtual plethora of options and overlapping products and standards, and the focus on package integration, create a much more complex environment then the environment that most of these frameworks and processes were designed to address. Most frameworks are focused on providing detailed modeling of systems and activities that are only moderately relevant at the enterprise level. Many of these descriptive models and frameworks have their pedigree in the systems engineering arena, and so much of what is prescribed is more suitably addressed in either domain specific architectures or software design efforts. This level of detail in the Enterprise Architecting effort can be a significant impediment to engaging the stakeholders effectively in the architecture team.

Finally, while most Enterprise Architecture frameworks and processes do a fairly good job at providing a means for describing current and future state architectures, and typically prescribe significant participation from key stakeholders in the effort, they do not effectively address the enterprise value chain, alignment, traceability, performance measurement and the need for adaptive architectures that are actionable.

The ICH Architecture Assurance Framework differs from most of the frameworks in use today, in that its focus is on proper identification, alignment and validation of architectural components (outcomes). This enables appropriate engagement of stakeholders, and the ability to make conscious cost-benefit decisions in the context of adaptive architecture concerns. The ICH Framework specifically focuses the architecture validation effort on discovering how technology can efficiently enable business processes by aligning the business needs to the operational environment with measurable performance indicators. It leverages implementation best practices as its litmus test of viability and source of validation data.


Enterprise Architectures: Three Levels of Maturity

IT Centric EA Effort and Framework

Enterprise Inclusive EA Effort and Framework with internal Alignment, Metrics, Componentization, Normalization, and Objectivity

“ Vaue chain aware” Inclusive EA Effort and Framework with Comprehensive Alignment, Metrics, Modularity Normalization, and Objectivity

Cost Savings IncrementalImprovement

Incremental Improvement


OperationalService Quality

Supportive Incremental Improvement


OperationalAlignment

Supportive Incremental Improvement


Business Alignment

Undetermined Incremental Improvement

Substantial Improvement

Validity Undetermined Internal Validity

IncrementalImprovement

Adaptability Undetermined Internal Adaptability

IncrementalImprovement

ICHnet.org Framework-Methodology Results


Appendix

Implementing Successful Adaptive Enterprise Architectures

A successful Enterprise Architecture effort requires an already existing and documented Business Strategy, goals and objectives. The business strategy, goals and objectives must be tied to metrics. For example, a goal to improve market share by 5% can provide a solid basis for justifying expenditures. A carte blanche goal to eliminate poverty can be used to justify anything. If measurable business strategy, goals and objectives do not exist, then they should be developed in the context of a vision statement before proceeding with the Enterprise Architecture effort.

Defining Context, Scope and Expectations

The Enterprise Architecture Methodology should provide for the early identification and documentation of the context, scope and expectations of the effort. The clear documentation and socializing of this information, early on in the project is critical to guiding the effort to an actionable architecture. Items that need to be addressed include:

1.Identification and validation of business drivers (Strategy, goals, objectives, mission, revenue, cost, new paradigm shifts, obsolescence)

2.Identification of the “going in” expectations of key stakeholders3.Identification of organizational capacity for change, reviewing such

factors as:a.Technology risk aversion b.Level of information sharing and cross-department cooperationc.Innovation quotient and sophisticationd.Budgete.Recent investmentsf.“off-limit items and sacred cows”

4.Development of a high-level current state assessment of technology infrastructure (alignment, quality, adaptability, efficiency):

5.Identification of functional and geographic entities to be included in the EA

6.Identification of high level business process areas to be used to organize the EA project.

The early delineation of EA context, scope and expectations will provide the necessary information required to develop a successful EA Project Charter and Plan. It also provides an opportunity to realign unrealistic expectations on the


part of key stakeholders, and to identify any missing key prerequisites for success, e.g., documented and clearly articulated business strategy, goals, and objectives, along with corresponding metrics.

EA Mission Statement and Project Charter

The Project Mission Statement should clearly articulate the importance of the project to the organization. It should come from the highest level of the organization in order to demonstrate senior management commitment vital to success. The Project Charter expands on the Mission Statement to include:

Detailed goals and objectives of the effort,Governance, including the establishment of the EA Executive Steering

Committee, EA Program Management Office, and working groups,Role of the EA vis-à-vis the IT Capital Investment Program and other ongoing

and planned IT related initiatives,Assignment of team members, and descriptions of their roles and

responsibilities,Security policies,Organizational change and communications strategy,QA approach,Description of methodology and approach to be used, and Change management procedures.

The EA Charter lays out the program’s governance and clearly communicates executive management’s commitment to the Program.

Initiate EA Program Effort:

Kicking off the EA Program in an effective manner is critical to the program’s long-term success. The goal of the kick-off is to set expectations, identify required training, and initiate and build effective working relationships between key participants. This includes:

Reviewing and buying into the EA Charter;Introducing the EA Team (team building);Initiating the review of EA frameworks for consideration;Walking through the overall Program Plan/Schedule and

Expectations/Deliverables;Describing clearly roles and responsibilities and expected participation levels;Discussing EA training requirements;In the case of Government: Integrating carefully the GPRA, Clinger-Cohen Act,

OMB requirements, and other critical requirements into ongoing performance management; and

Scheduling and communicating near-term activities.


The Knowledge Generating Processes

The proper approach to developing adaptive and actionable architectures is facilitation. An EA project will include stakeholders from a whole range of discipline. All with their own, and sometimes incompatible agendas. Success will require project leadership with strong facilitation skills. Additionally, the selected methodology must provide for iteration and flexibility. The collaborative nature of any EA effort requires that the process be iterative and flexible.

There are multiple proven methodologies for a facilitated approach to developing enterprise architectures. Typically, they all include some form of the following steps:

Facilitate EA Discovery:

1.Conduct joint process and technology workshops and interviews2.Develop and iterate “not-yet future state models” 3.Perform research and provide for expert input4.Finalize straw man architectural components and alignment matrices:

a.Process maps and descriptionsb.Solution set descriptionsc.Information modeld.Infrastructure enablerse.Policies and procedures

Results: Iterations of a future state design.

Identify opportunities and Gaps

1.Identify opportunities associated with future state and define metrics.2.Identify gaps between desired and current environment, including

metrics.

Results: Iterations of required changes to the current architecture.

Identify Patterns and Develop Consensus

1.Extract from each layer desired patterns that characterize a successful architecture.

2.Gain EA team and senior management initial buy-in.

Result: Cross discipline insight and consensus.

Complete definition of architectural components:


1.Review each component and determine the required level of definition.2.Separate into discipline specific teams and define features, function,

interdependencies, and performance metrics for each component.3.Identify components requiring domain-based architectures.

Results: Iterative comprehensive future state definition.

Actionable Architectures: Final Consensus

1.Normalize architecture components for validation against real-world solutions.

2.Conduct cost-benefit and risk assessment:Review process changes and performance metrics to quantify

benefits (approach is organization specific, depending on policies)Review solution sets, information architecture changes, and

infrastructure enablers for cost and riskPerform cost and risk allocation based on interdependenciesAssign risk factors to architectural components. Perform a risk assessment and determine the adaptability of the

architectureIterate architecture as required.

3.Develop consensus.

Results: iterative alignment of the architecture with the business that is actionable and viable.

EA Implementation Planning

A successful implementation plan requires that various options can be analyzed, and tradeoffs in cost, benefit and risk identified. This requires that the output of the Enterprise Architecture effort provide:

Identification of cost, benefit and risk associated with each architectural component being considered for implementation.

Complete tracability and proper allocation of cost, benefit and risk.The ability to deconstruct the components into normalized templates for

validation and analysis.

Achieving the above will result in an implementation plan that can generate an adaptive and actionable operational environment that is aligned with business needs.

1. Purpose of White Paper.doc

Documents

Transcript of 1. Purpose of White Paper.doc