Joanne M. Johnson

21-Apr-01

Case Study for INFS 413-- Enterprise Architecture

META Group defines an Enterprise Architecture Strategy (EAS) Process Model illustrated in Figure 1. The first core phase establishes a Common Requirements Vision. The next phase defines the Conceptual Architecture. The third core phase and subject of this case study is a definition of the Domain Architectures.

The domain architectures are situated beneath the conceptual architectural principles (CAPs) that are defined in the Conceptual Architecture phase. While CAPs can often be defined for an organization by adopting industry best practices, domain architectures are more specific to the organization. Each domain architecture is described in terms of design principles, technology classifications, and standards. The domain architecture guides the selection and usage of technology and products for that domain. Domain architectures are of two types: basic and applied. Basic domain architectures cover the commonly used technologies that almost every information system depends on such as network, computer hardware, operating systems. Applied domain architectures refer to a specific application of technology to support the business. Applied domains will address specialized software, hardware and configurations of basic technologies for the applied domain.

A network domain architecture is a common type of and an example of a basic domain. The network domain architecture commonly addresses the communication infrastructure for the distributed computing environment. Thus, it would provide design principles, technologies and standards for network topology, bandwidth, network management, wiring specifications, carrier services and protocols (for example).

Internet/e-commerce architecture domain is a type of an applied domain, and the subject of the Analysis section. In this domain the technologies of the Web are applied to support the organization. This architecture addresses issues of security, development tools, search engines, browsers (for example).

The design principles for a domain architecture are derived by the application of each of the CAPs to the domain architecture technologies and usage. Best practices are also inputs for design principles. The design principles are intended to guide the evaluation, selection, design, construction, and implementation of the technologies and products of the domain.

Each domain architecture will span a number of technology categories whose usage will be governed by the design principles. These technologies are identified specifically for the domain definition.

The third element of the architecture definition is the identification and application of standards. In addition to standards addressing overall technologies, standards will also address products and product configurations in the domain.

Domain architecture definitions are very dependent on the organization. For example, a financial services organization may define an entire applied domain architecture to address security, while a manufacturing company might include security as a technology category addressed within a basic domain architecture.

The focus company for this paper is a US based manufacturing company that META refers to as Eco-Cleaners. Eco-Cleaners is global manufacturer of cleaning products for over 30 years. It is headquartered and has manufacturing plants in the US, but also recently added manufacturing plants in Singapore and Australia. Eco-Cleaners has adopted a "grow through acquisitions" strategy. There are autonomous country offices globally who are responsible for their own marketing, selling, and technology infrastructure.

Previously, (also the topic of my first two case studies), the EAS Process Model was applied to the Common Requirements Vision phase and the Conceptual Architecture phase. This case study defines Eco Cleaners’ E-Commerce Domain by following a defined process for domain architecture development.

A domain architecture is defined by an evolutionary process comprised of four major steps depicted in Figure 5. The four steps are briefly described as follows:

Step 1: Decompose Domain Design Principles

This step applies each of the CAPs to the domain. The result is a set of domain-specific design principles that are consistent with other domains because of their roots in the CAPs. Note that not all CAPs will be decomposed into every domain. The linkage between CAPs and domain design principles is typically illustrated by using a matrix.

Step 2: Identify and Categorize Technologies

The technology categories are created as they relate to the domain. It is important not to spend a lot of time debating whether a particular technology belongs to a domain or not. All required technologies must be represented in at least one domain. Where technologies exist in multiple domains, the overlap is reconciled.

Step 3: Perform Current State Assessment

The current technology products identified in step 2 are assessed against the design principles in step 1. Inconsistencies and gaps are identified.

Step 4: Redefine the Domain Architecture

The domain architecture is redefined as a result of the first 3 steps and the processes repeated to ensure an effective domain architecture exists to support the organization’s business goals.

The Architects for Eco-Cleaners defined a domain architecture for E-Commerce as follows:

The technologies, standards, and guidelines for seamless, platform-independent business communications, electronic commerce, and controlled, secure universal access to business information using IP technologies.

Next, they decomposed the CAPs previously established to the E-commerce domain. The first CAP applied was "All products, solutions, tools, designs, applications, and methods used within the architecture shall be selected with the purpose of reducing complexity of the technology architecture" As a result, two design principles emerged:

Another CAP applied was "The imperative of all major change (automation) efforts should be driven by the business process and environment". The following design principle resulted:

3. The e-commerce environment will be designed to enable business to re-engineer the business environment so that it can handle fast change.

In this manner 12 design principles were defined by the application of 6 CAPs. In addition, 6 design principles already in existence were validated and remained part of the architecture definition. Therefore, 18 design principles were established. The full set can be reviewed in Reference 1.

Next the architects performed the other steps of the process and established a table showing the technologies identified for the E-commerce architecture, and they included the current state assessment and anticipate future state of the products related to each technology. Figure 2 shows the final results.

Consistent with the previous case studies that have applied different phases of the META EAS process, the case did not provide much detailed information regarding the activities, resources, timelines and metrics associated with the establishment of the e-commerce domain architecture. The biggest focus was on the outcome of the phase process. For this reason, it is difficult to envision applying this phase in an organization at large.

The goal of a domain architecture is defining the design principles, technologies, industry standards, product standards, and configuration standards of the domain. Figure 2 which summarizes the e-commerce domain architecture technologies and their product standards appears to be weak, and the design principles seem to reside at a very high level. Rosenfeld implies that an e-commerce domain architecture should also define standards or design principles for web site navigation systems, content organization, architecture blueprints and content mapping, style guides, web page inventory and more (3).

Whereas the case study appears to be brief, the EAS process is comprehensive in its approach and description of general activity required for what META defines as the Enterprise Wide Technical Architecture (EWTA) portion of EAS. In review, the META EAS is comprised of the following phases:

• Process set up
• Common Requirements Vision
• Conceptual Architecture
• Domain Architecture
• Document Current Baseline Infrastructure
• Gap Analysis
• Migration Planning
• Implementation Planning

Process Set up establishes key core teams of people throughout the EAS lifecycle who subsequently identify resources, establish governance and communication plans and perform organizational assessments for supporting EAS. There is a distinct set up phase, but as depicted in Figure 1, the process support elements are present throughout the entire EAS cycle.

EWTA is included within EAS and is comprised of the Common Requirements Vision, Conceptual Architecture, and Domain Architecture phases. Documentation of the current environment is a parallel process/phase throughout the EAS lifecycle. Gap Analysis, Migration and Implementation Planning phases comprise activities to migrate the current technical infrastructure to the future state. These transition phases go beyond the EWTA definition but are part of the EAS. They describe an integrated effort for transition that includes interdependencies between application, data, organization and technology migrations.

There does not appear to be subsequent META case studies at this time for an application of EAS beyond the EWTA phases.

An interesting comparison can be made between META’s EAS and Boar’s Index model architecture framework. Figure 3 shows the Index Model Architecture Framework with a cross reference to the focus areas of both META and Boar.

EWTA primarily addresses the infrastructure cells of the Index Model framework. However the Infrastructure Models cell is more appropriately mapped to the EAS outside of the EWTA phases, in the Document Current Environment phase. Whereas Boar presents a comprehensive methodology for infrastructure and application modeling (i.e. blueprints), META only refers to the infrastructure documentation in a generic sense (2). Infrastructure standards are explicitly addressed in the EAS Domain Architecture phase. Infrastructure inventory is addressed at least implicitly in the EWTA phases as well as the Document Current Environment phase.

The Organization row is mapped to both META and Boar. In the META EAS process, the Process Setup phase includes establishment of governance, and addresses organizational elements associated with the EAS. I interpreted the organizational aspects of EAS to reside in the Organization Inventory and Organization Models columns because the EAS process specifically addresses current organizational state (i.e. "organizational inventory"), and provides recommendations for an organizational structure to govern and support Enterprise Architecture (i.e. "organizational model"). Boar does not describe what is meant from his perspective regarding organization inventory, but suggests that the organization row includes IT organizational structure and processes (e.g. "organizational models"?), and more (4).

Both Boar and META provide methodologies that address the Principles column of the framework. Principles define rules and guidelines that are used to guide decision making and motivate collaboration and consistency in the organization. META distinguishes conceptual architecture principles from domain architecture design principles. Boar distinguishes categories of principles as overarching, design, or buy. The comparison of the two methodologies that derive Principles is best illustrated in Figure 4.

Figure 4: Principles Development Methodologies

META states that the EAS Process Model is still in evolution. It’s direction and vision is for the EAS to be applicable to the more holistic realm of enterprise architecture, including incorporation of templates, techniques, models, and approaches for business architecture, information architecture, and application portfolio planning. They do not anticipate that future evolution will dramatically alter the current EAS process model, but rather extend its scope and depth, resulting in the introduction of new phases and activities.

Although Boar does not explicitly map the steps of establishing business drivers and initiatives to the Index framework, (nor does META); these are key elements of the architecture that must be captured somewhere in an architecture framework. In the Index Model framework, perhaps drivers and initiatives are best mapped to the Organization Principles cell. This however is a recommendation for further review. The same discussion hold true regarding business and infrastructure requirements derived from the drivers and initiatives.

The are several additional recommendations for further review as related to the development of an implementable Enterprise Architecture methodology:

• Choose a ‘slice’ of an enterprise architecture, such as an application family and apply the Index Model Framework.
• Develop the framework by encompassing both META Group’s EAS process, and Boar’s focus methodologies.
• Include the current architecture, vision architecture and next state architecture.
• Define at least one transition project from the current to the next state architecture to exercise the Gap Analysis, Migration and Implementation phases of the EAS process model.
• Use the exercise to address the following issues or crisply describe areas of clarification:

• CAPs verses Design Principles
• Categories of CAPs verses categories of Design Principles
• Success factors and measurements for the EA process
• Domain architecture definition versus Conceptual Architecture
• Criteria for applied versus basic domain architecture classification
• Application and cross reference of EA process and measures to an average individual in the organization who is the customer of services such as a new hire desktop setup.
• Application and cross reference of EA process and measures to asset management and TCO

The ultimate goal of the recommended activity is to establish an applicable methodology for the organization that can be repeated for other areas of the architecture, and ultimately present a living approach for the entire enterprise architecture. These recommendations could define a Case Study for a future work.

3. Rosenfeld, Bernard H. and Peter Morville; Information Architecture for the World Wide Web; O’Reilly and Associates; Sebastopol, California; 1998

4. Boar, Bernard H.; Constructing Blueprints for Enterprise IT Architectures; Wiley Computer Publishing; New York, New York; 1998