Architecture approaches

While architecting a system can take many paths and involve different approaches and methods, a few key principles are common across successful, modern ArcGIS architecture efforts. This section of the Well-Architected Framework includes several more traditional architecture topics related to the separation of software and hardware, cloud considerations or approaches to integration. However, the breadth of additional topics illustrates how the role of an enterprise or system architect has shifted, and the outputs of architecture activities have changed as well, to expect new knowledge, topics and considerations. These recommendations aim to provide a good baseline of approach, not a specific set of steps and outputs.

First, it is critical to take a business-first approach. What does this mean in practice? At its core, this means that architecture should primarily be designed to support specific workflows, business capabilities, or outcomes that the organization needs completed. Rather than focusing on areas like performance, availability, deployment technology, or product extensions individually, these decisions should all be rooted in what the business demand is for that capability or feature. This demand-driven approach leads to systems that support the primary capabilities first and then grow effectively to increase impact and adoption across an organization.

Second, it is important to follow an architecture development methodology (ADM). Many different ADMs exist, and there is no single best option, but where possible you should align architecture projects to the commonly used method within your organization.  Using approaches that align to how other systems are architected will make it easier to communicate the system requirements, integrate other architectural guidance, and eventually win the approval or support of other parts of the organization. This extends to involving IT and business architects from other parts of the organization where possible.

Third, focus on designing for flexibility rather than emphasizing a perfect hardware size or physical definition. While the capital expenditure of hardware acquisition drove project cost for many years (and still does in some organizations), broad access to virtualization and cloud computing has reduced the importance of precise hardware commitments during the architecture phase. Changing the compute, memory or storage of a system is now usually more straightforward, and significantly more cost-effective, than in more traditional architectures, which suggests that flexible, loosely defined hardware profiles are sufficient for most architectures. Many organizations will still seek a strong recommendation on initial sizing of a system, and these systems or applications are still responsible for the ongoing costs of these systems. In summary, carefully balancing a reasonable initial estimate with the potential changes brought by growth in usage, new features, or new user communities is an important task for an architect to consider.

New areas of requirements have added to the importance of a structured architectural approach, such as security, enterprise integrations, data sovereignty or other topics that may not have been salient in more traditional cases. These requirements can have impacts on the solution design, hardware choices and overall management philosophy of a project or system and are equally important to the functional or performance-based requirements that would traditionally drive architecture choices.

Additional best practices for architecting ArcGIS systems include:

• Be agile - with changing dynamics, changes in requirements during and after the design phase, and shifts in the direction of your organization’s IT strategy.
• Be responsive – review the successes (and challenges) of an architecture regularly with stakeholders, and suggest changes that respond to their requests, either for new and improved functionality or changes to undesired functionality.
• Be intentional – when changes are required, be clear on the impact, timing, and effects on users. Carefully coordinating architectural changes reduces confusion, improves user confidence in the system, and increases the odds of successful outcomes.

The architecture process

In designing systems with ArcGIS, many organizations go through similar steps in a structured process, usually dependent on the Architectural Development Methodology (ADM) that is in use. To provide some additional context, these are examples of phases of architecture with some ArcGIS-specific details.

1. Establishing a framework and principles is a phase where identifying an ADM is important, as well as the core architectural principles that will guide the design, such as a focus on Service Level Agreements (SLA), an expectation of agile or waterfall project approaches, etc.
2. Defining an architecture vision identifies key themes that will guide the architecture development, such as an organizational “cloud first” initiative, a move to shift towards a different database provider or operating system, or a desire to implement new capabilities quickly in the resulting system. This vision begins to set the stage for decisions and recommendations that are made later in the process.
3. The Business architecture phase focuses on “the business” – a subjective term that generally means the day-to-day operations, and operators, of an organization, whether they are a public or private sector institution. This phase focuses on existing and desired workflows and capabilities – what are the ArcGIS-based components that will help get things done? This phase also includes non-functional requirements that are important to the business, such as usability, security, or performance. Separating the the functional requirements of the business architecture (the desired workflows and capabilities) from the non-functional requirements and solution architecture (the logical solution or software and solution components) is key to identifying gaps and areas of potential ares where these requirements may be in conflict with each other.
4. Once these workflows are defined, a Data and information systems architecture phase focuses on the structures that will support the workflows, both the application interfaces (such as mobile, web or desktop apps) and the data structures (schema, data model, storage) that will support the persistence of business data. During this phase, specific recommendations around which apps, client capabilities or storage patterns to use may be created.
5. As there are many ways to deploy ArcGIS, a Technology architecture phase focuses on the decisions and distinctions that lead to an actual software specification or procurement. In this phase, decisions about the role of ArcGIS Online and ArcGIS Enterprise may be made, or specific choices will be made related to database provider, cloud provider or the operating system which will host the software.
6. Once this target picture is more clear, an organization can begin to Plan for deployment, opportunities, and solutions while focusing on the steps and changes that need to be made to make the new system available to users. This may involve significant organizational change, procurements or increases in technical staff support, or assessments of technologies that allow a decision to be made.
7. When an existing system is already used for some business processes, which is often the case, Migration planning will assist with ensuring that users quickly and efficiently move to the new architecture. This can involve people and process-focused change management planning, but also technology planning so that integrations, workflows, and even public-facing content are shifted smoothly to access and interface with the new architecture.
8. With all of this planning complete, additional considerations for Governance are often discussed. These might influence how the new system is used, how changes to data or applications are reviewed and controlled, and how the process of review, revision and implementation proceeds forward, so that the architecture can stay relevant, adapt to new requirements, and stay responsive to user expectations.

With a structure and well-planned architecture process, systems both large and small can be carefully designed, effectively implemented, and efficiently maintained over many years and changes to users and audiences.