2007

{{post_terms.hashtags}}

Service Oriented Enterprise Architecture: An Opportunity of Evolution

As Service Oriented Architecture (SOA) has evolved an opportunity to close the gap between the Business Architecture and Technical Architecture. This is however not realizable by just “adding” SOA to an existing EA program. SOA will change EA, and if not aware of this challenge introducing SOA into an organization is sure to fail. SOA has gone through an exceptional evolution during the last couple of years, not only in terms of the hype that often follows new paradigms, more importantly the very conception of SOA has evolved. This evolution has changed the level of abstraction on which SOA operates; it has evolved from a technical discipline to encompass some of the aspects normally seen as key elements of the discipline of Enterprise Architecture (EA). The reason for SOA transition into the discipline of EA lies in the goals of EA and SOA, which are fundamentally identical. The goal of EA within an organization has been described through the use of different maturity models, these maturity models are essentially “the normal path” of EA. Maturity models for SOA are also starting to emerge, but as augmented in this article, the goals of EA and SOA are the same. It is necessary to align the paths of EA and SOA on a common path. To do this it is necessary to identify where EA and SOA correlate so that redundant work is eliminated. One of the main challenges here is to acknowledge that SOA will create artifacts similar to EA. Who owns these artifacts? Are they a part of EA or SOA? The discussion of whether SOA is part of EA, or EA is part of SOA is probably a matter or perspective – they change each other. A change of such proportions that it must be taken into consideration if this change is in fact not a new discipline. This article advocates for the correlation of EA and SOA is resulting in a special type of EA and SOA called Service Oriented Enterprise Architecture.

Creating a Line of Sight in Enterprise Architecture

Performance is a key driver of Enterprise Architecture efforts within organizations of varying sizes. In order to use this driver, it is important to determine quantifiable, outcome-based metrics that can be used to measure and track progress towards a “target” vision. These metrics must be aligned throughout all layers of the EA, thereby creating a “Line of Sight” from business goals to related services and enabling technology. Performance measurements must be aligned to strategic goals and mission needs, and must work seamlessly to drive technical solutions – from inputs to outputs to outcomes.

Analysis and Application Scenarios of Enterprise Architecture: An Exploratory Study

Enterprise Architecture (EA) gained growing importance as a key issue of information management in recent years. This article is aimed at contributing to EA methodology b a systemization of EA analysis techniques and EA application scenarios. These findings are compared with current EA practice collected by means of an exploratory study.

Bridging the Technomic Divide: Using Kiosks and Enterprise Architecture to Deliver Services and Expand Citizen Payment Options in the City of Denton, Texas

Much has been written about the “Digital Divide” where less affluent citizens are (or will be) left out of current or new technologies due to availability factors and the increasing cost of participation. Relatively little has been written about one important aspect of the Digital Divide that relates to the transformation of the electronic payment receipt process, and how participation in many online e-payment processes requires the use of a credit card or debit card. The nature of these transactions has the effect of excluding citizens who primarily use cash and/or personal bank checks from participation. This directly impacts not only the digital divide but also the return on investment of these e-payment solutions to the government entity providing them. The City of Denton, Texas has worked to address this “technomic” divide by developing equitability in payment options by replacing package enabled re-engineering with enterprise architecture as the planning approach for service delivery.

Essential Layers, Artifacts, and Dependencies of Enterprise Architecture

After a period where implementation speed was more important than integration, consistency and reduction of complexity, architectural considerations have become a key issue of information management in recent years again. Enterprise architecture is widely accepted as an essential mechanism for ensuring agility and consistency, compliance and efficiency. Although standards like TOGAF and FEAF have developed, however, there is no common agreement on which architecture layers, which artifact types and which dependencies constitute the essence of enterprise architecture. This paper contributes to the identification of essential elements of enterprise architecture by (1) specifying enterprise architecture as a hierarchical, multilevel system comprising aggregation hierarchies, architecture layers and views, (2) discussing enterprise architecture frameworks with regard to essential elements, (3) proposing interfacing requirements of enterprise architecture with other architecture models and (4) matching these findings with current enterprise architecture practice in several large companies.