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.
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 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.
Geographic information systems (GIS) are widespread at the federal, state and local levels. Data sharing is important because the ultimate power of a GIS is its ability to graphically present layers of data from multiple unrelated disciplines to create new information that allows people to answer questions. GIS have traditionally been built on standalone, stove-piped systems that present considerable difficulties to enterprise architects for several reasons. Although there are standard exchange formats for individual data types, there is a lack of federally-mandated standards for overall GIS data sets. This paper will discuss the efforts and associated challenges at federal, state and local levels to develop and implement GIS enterprise architecture frameworks, standards and enterprise architectures in order to better manage geospatial data. It presents the U.S. Census Bureau as an example of how the federal government is pursuing data sharing efforts with local government agencies, and provides examples of state and local government organizations that are implementing GIS into their enterprise architectures. It also discusses the impact of web technologies on the GIS industry and the differing opinions of the GIS industry on these technologies.