Thought Leaders in the Cloud: Talking with Scott Morehouse, Director of Software Development at Esri

Scott Morehouse was involved in the early development of GIS
(geographic information system) in the Harvard Graphics Lab and is now director
of software development for Esri. He was responsible for the initial design and
architecture of Esri's ARC product.

In this interview, we discuss:

-How the
cloud is enabling more collaboration around GIS data

-The cost
and complexity in setting up on-site GIS solutions, vs. using cloud based or
on-demand solutions

-The
opportunity for "mashups" where users combine their on-site data with
cloud-based data

-Opportunities
created by Azure virtual machines and database instances

Robert Duffner: To
get us started, could you please take a moment to introduce yourself and tell
us about your role at Esri?

Scott Morehouse:
I direct the software and product development activities of Esri. I've been
involved in building information systems for working with maps and geographic
data for 25 or 30 years. We built systems for workstation and client/server
environments, then we built web-based systems, and now we're building systems
that leverage cloud services and infrastructure.

My background is in geography and software engineering. We're
heavily involved in applying the appropriate computing technology and
leveraging general-purpose computing infrastructure to serve our users, who
work with maps and geographic information.

Robert: You've
been involved in GIS for quite some time, going back to the Harvard
Graphics Lab. How have you seen the field change over the decades, and
where do you see it going?

Scott: It's
interesting to see the technological changes, but the fundamentals actually are
quite the same, in terms of bringing geographic information to life in support
of real users, real decision-making processes, and real work flows.

One thing that has especially become easier with modern
technology is building collaborative systems and making information available
to everyone in an organization, rather than having it locked up in departmental
systems or information silos. Using web technologies and mobile device styles
of system building has made it a lot easier to allow people in a given community
to participate in implementation of the information.

Robert: You've
talked about the underpinnings moving from client/server to a web-based modality,
and now leveraging cloud computing. How do you see cloud providing benefits for
GIS?

Scott: There are
a number of different dimensions that make cloud interesting to us and our
users. First is the simple fact that information systems have been moving from
a client/server pattern to a web-centered pattern. By that I mean that even
intranet or internal systems within an organization are being built around a
web programming pattern and around a web style of user interactions.

Building a web-style information system implies an easy-to-use,
browser-based modality that is stateless and uses a certain programming
pattern. It implies making the information available to devices like iPhones
and tablets as well as to work stations. It implies a certain style of
documentation and leveraging a community of people for a more collaborative
environment.

People are very interested in building applications that
work that way, because that's the highest style of technology that they're used
to. Nobody works with command prompts anymore except for system administrators
and developers.

Another trend is the complexity of building and managing a
computing infrastructure for an organization or even for yourself. It's really
a difficult process to create the right infrastructure for hard drives, CPU
cores, network connectivity, security, software patches, and so forth. So the
notion of being able to grant or tie into a hosted infrastructure rather than
having to build and maintain your own is very attractive to our users. They
just want to turn a switch and get a new server that they can deploy a workload
to.

A third thing is the ability to combine and mash up
functionality and information that comes from other places. Users like to be
able to take our case maps and data that others have created, and use them
together in their own applications.

Robert: With SaaS
applications, you want multi-tenancy and for each customer's data set to be
completely isolated. That's sometimes true with GIS, but at other times you want
to share and use community data. How does the cloud facilitate that?

Scott: The cloud
facilitates the sharing of information in a couple of ways. One is that web-style
system architecture makes information accessible through services. The notion
that information is accessible through RESTful services or web-style interfaces
really reduces the problems of getting at information. You're not having to ETL
data from one database to another or these types of things.

In that context, you have to be clear as to what information
is private, what information is semi-private, and what information is public. I
think there's an implication that if information is easily accessible through a
web-style interface, it also has to be public information. That's not necessarily
the case, and we can put security around information in that context.

I think the question of whether a system is based on a
multi-tenant architecture or whether it's based on having actual instances per
user is kind of a fine point of implementation.

SQL Azure is multi-tenant, but there are individual database
instances within that. Some people can own and control their own database
container, but the system is optimized in such a way that it scales and has
other attributes that multi-tenant applications give you. We see a combination
of services that are implemented in a multi-tenant style and applications that
are instance-per-organization style.

In the context of SharePoint, for example, there's a role for
both a multi-tenant approach, for sharing documents and collaborating on them,
as well as for allowing people to rent their own SharePoint instance in a
hosted or cloud environment.

Robert: You've
also talked about the cloud lowering the barriers for people to utilize GIS
because they don't have to stand up servers to have GIS capabilities. Can you
talk a little bit more about that?

Scott: The main barrier for people to get into this web style of
system building with geographic information is setting up and managing servers.
The cloud makes that easier in a couple of ways. First, people can stand up and
manage their traditional enterprise-type servers and services using the cloud
as a hosting environment, or a virtual data center for their servers, if you
will.

It also allows us to create new services that are lighter
weight, leveraging the scalability of frameworks like Azure. So people can
basically get going with information managed and delivered through services
accessible from web clients a lot easier than if they had to buy their own
hardware and connect it to the Internet.

Robert: Esri
itself has a bit of a hybrid model, where you host your own servers but you
also use Amazon and Windows Azure. Can you talk a little bit about your
architecture and how you decide what to keep in house and what to host in the
cloud?

Scott: Our
fundamental architecture is web-centric, meaning that we've been working to
expose maps and geographic information through open, web-accessible interfaces,
primarily REST and JSON, but also SOAP and some other types. We've engineered
our front end as clients to these services, so this web-centric system
architecture can be deployed within an enterprise entirely, but it's also well
suited to running on the Internet. It's also well suited to having elements of
it, namely some of these services, actually hosted in a cloud infrastructure.

Since everything is a service, it really doesn't matter
whether the service is running on physical hardware that's connected to your
LAN or on virtual hardware that's physically located in an Amazon or Azure data
center. We just make practical decisions about which aspects of the system make
sense to run in our customer's data center, which services should run in the
Azure cloud environment, and which ones should run in Amazon's cloud. We look at
requirements such as what functionality is most efficiently implemented in
which infrastructure and which environments meet the security and access
requirements.

Robert: How do
you see other enterprises using hybrid models where they may keep a large number
of servers and applications on site for the foreseeable future, but consume
cloud services like those that Esri provides?

Scott: It's not
necessarily the case that to take advantage of cloud computing, you need to
rewrite or move all of your applications from an enterprise-centric
architecture to a cloud-centric architecture. It's certainly possible to build
on-premises enterprise applications that combine information coming from your
enterprise systems with data feeds, information, and functionality that are
coming through a subscription to a cloud service.

We're seeing lots of mash up patterns where people combine
geographic information from our hosted services with their enterprise
information and even build their enterprise systems using on-premises web sites
or thick-client applications.

Robert: I think a
lot of companies with products they've traditionally sold as on-premises
offerings see the cloud as something of a threat, but Esri
has really embraced the cloud and pivoted to this technology. What advice
do you have for other companies or organizations that have on-premises
solutions about adopting the cloud?

Scott: Every
organization is different, and we've really just focused on recognizing that
this new pattern of building systems that leverage browsers and mobile devices
is a pattern of systems that people expect. They want to get at their corporate
reports or their geographic information from their iPhone as easily as they can
get to their music from their iPhone.

There's an opportunity there to grow and support that style
of solution as well as more traditional desktop computing. Amazon and Microsoft
have both worked hard to make it relatively simple to migrate applications from
a traditional server computing environment to a hosted computing environment.

In particular, the latest release of Azure has virtual
machines and other capabilities that work both on premises in private clouds as
well as off-premises in hosted ones. I don't see cloud-based applications
completely replacing on-premises based ones, but I see the two complementing
one another, and I see a lot of cases where you can design a system that will
work well in both environments.

Robert: Key
software providers like Esri providing services in the cloud definitely
provides an opportunity that wasn't there before, in terms of enabling customers
to co-locate, for lack of a better term, their software with your software in
the same cloud. What are your thoughts on that?

Scott: People can
build systems that take advantage of the cohesion of software components if
they share a common cloud infrastructure and common application fabric. We are certainly
exposing aspects of our system that allow people to take advantage of that, for
example, building web roles that work with our worker roles and our data
services, tying them into a common application fabric.

Another interesting thing about this sort of web-centric
architecture is that, if it's truly service-based, it is to some extent
agnostic as to where the services are coming from, and that's a good thing. We
don't want to have to replicate or copy the same information and functionality
across to six different ways of storing and managing blobs in a web-addressable
way.

We can definitely have applications that mash things up
between Windows enterprise architecture and Azure cloud architecture, as well
as other hosted environments like Rackspace and other virtual environments like
Amazon. You can build in a degree of system cohesion, and it's not necessary to
rewrite everything so that it runs entirely inside of Azure, Amazon, or any of
the others.

Robert: I came
across a paper for the 1997 Esri User Conference titled "Democratizing
GIS: Are We There Yet?" Where do you think we are on the path of
democratizing GIS?

Scott: A lot of
the technical challenges have been overcome. The challenges now are about how to
create a lot of great content and communities that can collaborate around it.

Robert: How would
you characterize the value of platform as a service, as opposed to
infrastructure as a service?

Scott: I think
the whole distinction between platform as a service and infrastructure as a
service is a false one that creates a lot of confusion. I prefer to think in
terms of "system as a service." To build a system, you use the appropriate
technology, whether it's database technology or client technology. When people
have big debates about whether the business logic should live in the database tier
or the middle tier of a three-tier architecture, the real answer is that it should
live where it's best suited, and where you can build and maintain a system most
appropriately.

I really like what's been going on with this latest release
of Azure, because from a practical standpoint, we're actually blurring that
distinction. The religious people that refuse to let Azure be platform as a
service have relented and allowed us to have virtual machines and allowed us to
have database instances with SQL Azure.

That's really opened up a lot of opportunities for moving
more conventionally architected systems to the cloud and then adding
functionality that might leverage the fabric or platform-as-a-service
capabilities. I look at Azure and Amazon not as differences of kind but as differences
of quality. Both allow you to build cloud-based systems or system as a service,
and you can use both to do tier services, build user experiences, or even have
databases.

What's different, really, is the quality of the relational
data store, the quality of the runtime environment for hosted app instances as
Web roles, and how easy it is to build and manage a system as a service in one
or the other.

Robert: Thanks,
Scott. I really appreciate your insights.

Scott: Thank you.

Tweet