Current information technology (IT) trends promote the benefits of integrated, normalized and service-oriented enterprise systems. As a consequence, enterprise GIS design practices have embraced this approach, introducing a new way of delivering what used to be isolated, controlled and stable desktop systems.
Unfortunately, this has an unexpected potential to degrade and limit proposed solutions if their inherent complexities aren’t addressed. These issues are particularly sensitive for enterprise architectures in which GIS is a core piece of the puzzle, such as in the utility industry.
How Did We Get Here?
Through the years, GIS has evolved into an essential resource of any large utility operation. Typically emerging from old AM/FM or drawing systems, and initially deployed at desktop or workgroup levels, GIS has migrated to the IT land of servers and data centers.
During the same period, IT environments also have changed, embracing new values and models. Concepts such as “best practices,” “COTS/bespoke ratios” and “service-level agreements” have become a part of everyday life for IT specialists.
In this context, GIS projects can quickly run into trouble when a company embarks into this new technology landscape without a clear roadmap for the business role that GIS will have in the overall business-systems environment, potentially lessening its fitness to deliver the expected outcomes.
Enterprise GIS in Utilities
GISs in utilities are subject to wider use within organizations, and they’re more integrated with other enterprise systems (ERP, AM, CIS, OMS, etc.). They’re also a key component to business processes (service requests, dispatch, customer requests, etc.), and they need more internal and external information sources (land, imagery, network, weather, etc.). They also have more specialized applications and components (tiers, extensions, clients, etc.).
Enterprise IT also uses more scalable, distributed and virtualized environments. They’re loosely coupled—not hardwired—and ride the enterprise service bus and live in the cloud.
Deploying an enterprise GIS with disregard to the underlying enterprise IT architecture, business logic or processes it will affect likely will set back most of its anticipated benefits.
When integrating/interfacing a GIS to other systems, be mindful of the following:
• Plan for an error-management subsystem.
• Don’t underestimate traffic volumes.
• Implement flow-control mechanisms.
• Minimize hardwired replicas; favor extractions where possible.
• Define tight logic for managing native and foreign keys.
When using a GIS as a network asset management system (or subsystem) or as a building tool or design system, be sure to do the following:
• Expect complexity in resolving geometric network reconciliations (e.g., deciding which GN junction goes with which conflicting line segment).
• Manage user expectations.
• Tackle performance issues quickly and systemically in large replication or synchronization processes.
• Don’t underestimate maintenance and administration requirements.
And if using GIS for map production and viewing, be sure to do the following:
• Don’t underestimate growth of demand in all client types.
• Diversify corporate mapping products, but consolidate management.
• Don’t underestimate maintenance and administration requirements.
And if using GIS for any or all of the above, remember to do the following:
• Model geodatabases as standard and as simple as possible.
• Capture and manage only what’s needed, not what “used to be” or is “nice to have.”
• Take full advantage of industry-specific logic tools, such as auto field calculators, validation tools and customizable behaviors.
• Don’t try to do everything with the GIS; but make sure to exploit what it’s good at.
But how can some of these problems be avoided? How do we plan for the best possible GIS an organization can afford? Here’s where “architecture” comes into play.
Basic Design Guidelines
The term architecture often is used when presented with a set of nice pictures of servers, applications, databases, users and clouds, all tied together with complex lines and connectors. These compositions often are branded as the “architecture of the solution,” without depicting architecture at all.
According to the Institute of Electrical and Electronics Engineers, “architecture” is defined as “the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
What’s often missing in the diagrams is the architecture itself: the principles, fundamental organization, and time and use perspective. Some of these shortcomings are unintentional and often byproducts of the diagramming tools. Describing any architecture with these diagrams equates to describing a building architecture by listing its components and reading the construction plans.
But even with better tools, the underlying problem persists. GIS architecture is seen as variations of how to tie software, data and users through computers and networks. But an adequate enterprise GIS architecture should be organic and sustainable.
Organic Architecture?
According to a classic definition, organic architecture is a design approach that promotes harmony between the built and the natural world through design approaches so sympathetic and well integrated with its site that buildings, furnishings and surroundings become part of a unified, interrelated composition.
In the IT context, organic enterprise architecture should be a design approach that promotes alignment among systems and their environment through solutions so supportive and well integrated with the organizational model that applications, data and processes become part of a unified, interrelated composition.
One has to visualize the “to be” GIS solution in its specific context, for example, next to the legacy billing system, recent financial engine and manual reconciliation processes. The design has to take into consideration these environmental conditions and constraints, as it will accommodate a new set of components that will interact and affect the business.
An organic design should be based on the intrinsic character of the chosen GIS technology and its nurtured role in the organizational context by articulating the structural interactions occurring within business processes conveyed across the system.
The design fitness should be assessed from its internal logic and flows as well as its external interactions and suitability or aggressiveness with regard to the enterprise environment as well as the shaping or reshaping it generates in business processes, data flows and functions.
Sustainable Architecture?
Sustainable architecture describes environmentally conscious design techniques that seek to minimize the negative environmental impact of buildings by enhancing efficiency and moderation in the use of materials, energy and development space.
Sustainable enterprise architecture describes a context- and time-conscious system-design approach that seeks to minimize the negative organizational impact of systems by enhancing efficiency and moderation in the use of resources, effort and components.
A sustainable GIS design should do the following:
• Incorporate flexibility as a key design factor. A sustainable design should adapt, support and enable organizational change, and improve the overall system and business agility.
• Efficiently use all its components as well as take advantage of existing untapped resources.
• Achieve greater effectiveness by means of continual efficiency gains.
• Not generate continuous strains on existing IT and business resources.
Organize and develop the overall architecture in a tangible and communicable manner, and use some of the common architectural frameworks where possible (e.g., Zachman, TOGAF, DOD, etc.).
Building the Big Picture
If an organization engages in these basic guidelines, it becomes apparent that no single implementation or upgrade project will be able to cover all the expected benefits in a brief period of time. Deploying organic and sustainable GIS architecture requires a projection in time of actions, which become de facto work programs. These programs will have at least one of the following characteristics:
• They should be outcome driven, delivering tangible (solutions, tools and data) and intangible products (governance, processes and roadmaps). GIS managers need to stop evangelizing about technology and start speaking about specific benefits.
• They should deliver combined expansions of functionality along with incremental gains in existing ones.
• They should seek continuous optimization of existing resources and services.
• Solution specifications should shift toward performance-based requirements and less-descriptive or component-driven designs.
• Wrap operational and planning activities with proper consolidated governance.
Designing organic and sustainable GISs will likely become a journey rather than a project or a destination. But this change will deliver more positive outcomes and less pain than traditional practices.
By Igor Albornett
Igor Albornett is a GIS professional leading an IS Solutions team in Powerco, New Zealand; e-mail: igor.albornett@gmail.com.
Issue Date: August - 2010, Posted On: 9/27/2010
ไม่มีความคิดเห็น:
แสดงความคิดเห็น