Skip navigation
All Places > Implementing ArcGIS > Blog > Author: SScher-esristaff

Implementing ArcGIS

4 Posts authored by: SScher-esristaff Employee

In my previous article, Architecture is a Funny Word, I introduced Esri’s Global Architecture Team. I talked a bit about the work we do (and don’t do) and how we can support you in your efforts to design, build, and implement a GIS that makes a real difference at your organization. You might want to check that blog out first, since it sets up some of the context for this one. However, if you think context is dull and overrated, then by all means carry on, dear reader.

While everyone uses both sides of their brain, it is said that ‘right-brained’ people tend to be creative, imaginative and innovative thinkers. They like to employ creative concepts to understand complex ideas, are often focused more on the ‘big picture’ rather than specific details. ‘Left-brained’ people are said to be detail-oriented, analytical, and logical thinkers. They like to approach problems methodically and with concrete evidence and facts, and know that people don’t trip over mountains, but over molehills.

 

It seems to me that GIS practitioners are a diverse mix of right and left-brainers. Which makes sense, since GIS is as much about analyzing data and identifying patterns as it is about communicating concepts and ideas with beautiful, compelling visuals. So, I figured it could be valuable (and fun) to try and explain architecture in a way that would appeal to a larger group of thinkers.

The Right Brain
For my right-brained readers, I offer you an architecture analogy: Architecture is often compared to the architecture of the physical world of buildings, bridges, or even city planning. This analogy illustrates some key facets of the discipline- describing ‘what should be’ in terms of design, and how it should be adjusted going forward. However, this analogy only describes some of what architects do, and sometimes the ‘how’ and ‘why’ are more interesting, especially to you right-brainers, than the ‘what’. So why don’t we take a new analogy for a spin?

 

The fundamental idea of “yin-yang” is that seemingly opposite or contrary forces are actually complementary and interrelated. If you’ve ever sat in a room with technologists and business people trying to solve a problem together, you might see how those 'seemingly opposite forces' could represent business and technology. Technologists often feel separated from the business objectives of their organization, and business people sometimes see technology as a frustrating, separate field from their work. Of course, these two practices are completely interrelated and dependent on each other: the business dictates the use of technology, and technology guides and enables what’s possible for the business to achieve.

 

One of the key tenets of an architect’s duty is to make this relationship strong and clear by aligning the capabilities of technology to the needs of the business. In other words, we strive to highlight and strengthen the interconnectedness of these sometimes seemingly opposing forces. We do this by starting with a vision everyone can agree on and collectively work toward. Almost as importantly, we also need to make that alignment easier to see and understand, especially for leadership and other key stakeholders. This means communicating creatively, often with visuals, to explain complex ideas. Anyone who has had to act as the bridge between business and technology knows that bridge’s foundation relies more heavily on the art of building relationships than the science of technicalities.

The Left Brain

Alright, left-brained readers, it’s your time to shine. Let’s get serious about the methodical, concrete work architects on the Global Architecture team can do with you. Our work revolves around three key questions:

  1. Where is your organization today?
  2. Where do you need to be tomorrow?
  3. What’s the best path to get there?

Notice how I didn’t say:

  1. What does your GIS do today?
  2. What do you want to do with GIS tomorrow?
  3. Here’s what you need to buy or install to do it

Rather, we take a business-first approach to ensure that your investment in GIS is directly impacting outcomes for your organization and its stakeholders. We start by understanding the business challenges impeding your organization’s goals, and design new or augmented business workflows that resolve those challenges. Then, we identify what technology components, information, data, and skills are needed to enable those workflows. This process draws clear connections between technology solutions and business outcomes for your executive sponsors (or potential executive sponsors).

 

This work can’t be done in isolation. An architect documents perspectives from both the business and technology side before defining how to meet their needs in an efficient, sustainable and adaptable way. This means that architects speak the languages of both technologists and business managers. One way we do this is with diagrams. Kind of how GIS practitioners communicate with maps.

 

While technical architects communicate with system diagrams, my team and I communicate with conceptual and logical architecture diagrams. These might take the shape of a matrix illustrating where technology is not being effectively leveraged in your organization, a flow diagram outlining a new or augmented business workflow, or a roadmap that details how to get from where you are now to a place where you can overcome the challenges impeding your goals.

 

Let’s Connect

As Esri’s User Conference is just around the corner, I suspect many of you are getting excited to talk about the future for GIS at your organization. The Global Architecture Team is excited to work with you. Come chat with us. If you have any questions or would like to talk about any of these ideas further, email me at sscher@esri.com. You can also reach my team at global_archiecture@esri.com.

 

“Nothing is as dangerous in architecture as dealing with separated problems” – Alvar Aalto

Like many of my colleagues on the Global Architecture Team at Esri, I spend a lot of time explaining who we are and what we do, and I think I know why. architecture is a funny word. It means a lot of different things to a lot of different people, which makes sense because depending on your domain, your experience with architects will differ greatly.

You might think of data architects, who design how data is collected, stored and arranged. Perhaps you’re more familiar with application architects, who are concerned with how applications are used and how they work together. Many people think of system architecture, and quickly find themselves in a cold sweat after picturing a horrifyingly complex system diagram. All this preamble to say: The Global Architecture Team doesn’t really do any of that.

What We Do

Our work is more closely aligned to the discipline of enterprise architecture. The role of the enterprise architect is to align the perspectives of business, applications, data, and technology to the organization’s overall strategy, while making sure the design follows organizational governance policies and standards. Now, we obviously we work at Esri, so we aren’t going to architect your entire business-technology landscape (sorry). Rather, we use enterprise architecture principles and frameworks and apply them specifically to the domain of GIS. One of those principles you’ll hear us talk about a lot is to take a ‘top-down, business first approach’.

This means starting with a vision for how GIS needs to support your business. This isn’t a list of maps or apps, and it definitely isn’t a data catalog. Rather, it’s a statement of what your organization will ‘look’ like when it has implemented and is operationalizing GIS effectively. Then we need to understand what business processes need to be designed or augmented with GIS. More simply, we figure out how the work your staff does needs to change to achieve the vision. Only once we have this level of understanding do we start aligning technology components, information products and data needed to enable those new or enhanced processes. Ultimately, we work with you to design the ‘why’ and then the ‘who’, ‘what’, ‘where’, and ‘how’ of GIS in your organization. My colleagues on the Global Architecture team and I are here to work with you to design the most impactful GIS that’s feasible in terms of sustainability, cost, and potential risk.

 

 

Let’s Connect

As Esri’s (first-ever virtual) Users Conference(esriuc2020) rapidly approaches, we know many of our customers are eager to connect and learn how they can do more. The Global Architecture team has supported organizations large and small, and in nearly every industry in their efforts to transform the way their organization works with geography and GIS. If you found this blog interesting and are looking for more on how our team can help amplify your success, you can reach me at sscher@esri.com or my team at global_architecture@esri.com.


“An idealist believes the short run doesn’t count. A cynic believes the long run doesn’t matter. A realist believes that what is done or left undone in the short run determines the long run.” - Sydney Harris

In your organization there are likely different people, working in a variety of roles, with varying skills and responsibilities. It can be overwhelming to deliver the right content in the right format to these different people in a well-performing, reliable, and secure manner.

 

Your geospatial content publication strategy serves as a guide to help accomplish this. While any two organizations can have vastly different publications strategies, an effective content delivery strategy will always address performance, reliability, and security.

 

Performance

Think of performance as how long it takes an application to load- is it lightning fast, or crawling along. One way to address performance strategically is to consider separating internal and external activities. In practice, this could mean external public applications like StoryMaps live in a scalable environment such as ArcGIS Online, and internal dashboards, analytics, and editing work stays on your own infrastructure in ArcGIS Enterprise. This way, if one of those public-facing apps suddenly becomes popular, your internal resources won’t have to compete for resources.

 

Reliability

Reliability is expressed in a service level agreement (SLA), and is an expectation of when the system will be available- like during work hours, or 99% of the time. There are many ways in which organizations address reliability, such as following other best practices like high availability, load balancing, workload separation, and security. You could also address reliability by leveraging cloud capabilities.

 

Security

Within the context of a publication strategy, security is about exposing the right content and capabilities to the right people. You certainly don’t want non-experts editing your asset information, or your sensitive data to be exposed publicly. This content should be properly maintained in a secure system of record. Security isn’t just about keeping your internal content within your organization; it can also pertain to information or capabilities that is sensitive even between departments or teams within your organization. Depending on the level of risk and sensitivity of this content, it may be appropriate to have a separate, internal publication environment.

 

 

While your organization’s individual content publication strategy will likely encompass many other considerations that are relevant to your work, goals, and mission, it should always address the needs and expectations of the people in your organization and protect your internal system.

 

Download the PPT for this presentation from the 2018 Esri User's Conference: Content Publication Strategy.pdf  

As technologists supporting important business functions, it’s important to do what you can to make sure that your organization’s production environment is protected.

 

What kinds of negative business impacts could you expect if your production environment failed? How much money would it cost your organization? How many mission-critical operations would be halted? How many customers or citizens would be affected?

 

Environment isolation will help protect your production system by creating at least three separate and distinct computing environments for operational, testing, and development activities. Let’s talk about how each of these systems help to protect your production environment.

 

Production Environment

Your production environment is the system that you are most familiar with. It’s your “live” system. It’s where most people in your organization go to do their work, whether it’s to access their mobile application to submit damage assessments around the city, or their desktop application to predict the structural integrity of buildings and bridges, or their dashboards to monitor the progress of their initiatives and projects. Because these people’s work is so important, it’s crucial that changes aren’t made here without first being tested and evaluated in a separate environment.

 

Staging Environment

Your staging environment is a replica of the production environment that isn’t supporting your business operations. This makes it a great, safe place to test an amazing new application your team has developed. This way you can be sure the app will deliver the functionality you promise and that nothing else in the system will be negatively impacted. It’s worth mentioning that many risk-averse organizations will have many kinds of testing environments, including a staging, performance testing, load testing, acceptance testing, and even training environments. The needs of your organization may differ depending on the level of risk you’re willing to assume.

 

Development Environment

Let’s get back to that amazing new application. That app was made in a separate environment: development.

This is a workspace where your developers can innovate. It’s where they can manage content, make changes, construct new business workflows, and create new capabilities. This environment’s size and complexity will largely be determined by how many developers you have working in this space and the level of risk associated with the kinds of changes they work on.

 

Needless to say, delivering a reliable, high-performing system is no easy feat. It takes a lot of diligent work done by smart, dedicated people. Isolating inherently risky activities like development and testing from your production environment will contribute to the stability and performance of that system.

 

Download the PPT for this presentation from the 2018 Esri User's Conference: Environment Isolation 

Filter Blog

By date: By tag: