Article

{{post_terms.hashtags}}

Characteristics, Roles and Responsibilities of the Modern Day Systems Architect: Lessons from the Field

The roles, responsibilities and titles of Architects often vary in relation to the domain or environment in which they operate. Throughout our work with a wide variety of clients, we have discovered that there is a „misconception‟ with regards to both the function and deliverable of the architects. This misconception often means that inappropriate resources are allocated or targeted to tasks; this can result in either delay or in appropriate solutions being delivered. In this article we discuss the roles of Enterprise, Solution and Technical Architects and highlight some key products which are produced, together with the inter dependencies between these individuals and products.

An Enterprise Abstraction Approach: Viewing Enterprise Architecture Through Natural Language Constructs

This article introduces an approach to define an Enterprise Architecture (EA) that aims to get closer to the abstraction level of the business side of an organization. Named as Enterprise Abstraction Aproach (EAA), the approach stems its roots from ontology engineering, business rules approach and business process engineering and aims to define business view of EA through natural language contructs. The approach also suggests to define domain ontology of the information view of an EA. By extending the business ontology definition towards information and technology views of EA, the approach aims to define a semantic mapping accross self-contained domain ontologies that pertain to different views of an enterprise, achieving a 360-degree view of the enterprise through a unified language.

Enterprise Data Architecture Trade-Off Analyses

Enterprise Data Architecture Trade-Off Analyses lie in making the right choice of building block components, patterns of organizing these blocks, choosing the way they communicate, the timing of these messages, and the constraints and service levels that they can provide, for the given business problem and with the available resources and budget. It always involves a cost-benefit analysis comparison between the alternate candidate solutions. This article lists the Enterprise Data Architecture building blocks with available options for implementing these components with their relative merits, and help enterprise architects in making those choices. These patterns can also be re-used in other contexts, when similar problems are encountered.

Service-Oriented Enterprise Architecture (SOEA): A Conceptual Design Through Data Architecture

This article provides a basic foundation for developing a Service-Oriented Enterprise Architecture (SOEA) through a conceptual data architecture design. SOEA uses services (i.e. business, software and technology) and data to describe the composition of strategy, business, data and information technology. SOEA has to identify the business services and data needed to support the strategy and business processes of the enterprise, and map the business services and data to software and technology services (i.e. IT infrastructure services). This type of architectural framework supports heterogeneity, interoperability, and extensibility which serve as the basics for continued enterprise growth and effectiveness. The article also addresses the architectural constructs required to support the business goals and informational needs across an enterprise by principally addressing the service and data architecture layers providing the blueprint for the architectural design.

The Service Oriented Architecture Method for Federated Enterprise Architectures

The Services Oriented Architecture (SOA) Method for Federated Enterprise Architectures (EA) comprises an integrated set of techniques for enterprise analysis, contextual visualization, decision support, and portfolio management. The method utilizes state-of- the-art SOA concepts and artifacts to produce federated community architecture designs supporting mission and business transformations. The resulting architectures are not exclusive to the SOA paradigm and can be engineered and implemented using a variety of techniques such as functional decomposition, component oriented, SOA, or COTS- centric methods. The SOA EA method produces and applies advanced artifacts and tools including Enterprise Component Maps (ECM), heat maps, business intelligence dashboards, and EA line-of-sight models for decision support and portfolio management. The authors tailored the method from a precursor SOA method that was heavily exercised in practice. Tailoring extended and applied the EA metamodel to support decisions such as IT consolidation, information sharing, programmatics, and portfolio management. The method integrates with federated system lifecycles in consideration of downstream uses of the artifacts produced. Intended for application to community-level architectures, the method is lightweight, extensible, agile, and can produce actionable architectures. We also present some sample artifacts from a security EA case study.

Metaphor as an Inference from Sign

Metaphor “sign inferences establish that there is a relationship between two factors, so that one can be predicted from knowledge of the other. This relationship is called correlation”. While metaphor states one is the other, has characteristics of the other and informs one of the other their likeness is not apparent, is seemingly unrelated and yet has an essence common to both. The parallels between effective and literary reasoning reveal the technical and conceptual metaphor’s science. Using both literary and architectural cases the metaphor explains the two realities they diversely express and therefore we learn how the metaphor works when it is a sign which correlates and not a form which causes. This article cites only one of the nineteen scientists from A. Ortony’s, Metaphor and thought honing in on the work of George Lakoff, an American cognitive linguist and professor of linguistics at the University of California, Berkeley.