A picture is worth a thousand words - and it’s a valuable tool for Enterprise Architecture (EA). With the pictures generated in Scenarios, you can document planned changes to your architecture and explore potential future states. The diagrams generated in Ardoq Scenarios also help you communicate your plans to your team and stakeholders.

To explain how it works, we’ll use a hypothetical example. In it, we'll show you how an Ardoq change project works. We’ve kept everything simple, so you can clearly see the process and not get lost in details. Naturally, a real-world scenario would typically have much more complexity.

In the last few years, the Acme organization has grown significantly. From the outset, they’ve used WordPress as their CMS. Up to now, they’ve hosted their WordPress instance on a single server that also supports all their other applications. However, due to their increasing traffic and customer base, they need to find a more viable solution.

Acme’s EA team wants to improve the WordPress installation to increase their scaling and security. With more customers across all time zones, there’s little room for downtime. In addition, the WordPress installation requires continuous attention to keep it safe. Since it’s installed in the same environment as their main webshop, this poses a serious security risk.

All the internal applications are hosted on the same server.

The website has custom WordPress code to dynamically embed promotional content snippets from their webshop. The content is embedded server-side. This is an important part of their customer funnel, so the functionality must be preserved.

The EA team decides to explore a few alternatives on how to best make improvements. With Ardoq they create two separate scenarios, where they model their two possible changes. With the Scenarios, they can visualize how the approaches differ.

Pro tip: To create the scenarios, open the relevant workspaces (application and infrastructure workspaces) and get all components relevant to the WordPress changes. When all the components are in the visual, you click “create a scenario from view”.

As their first alternative, they have chosen to continue with their own hosted solution, and improve the security by adding more servers and separating the applications. While this doesn’t reduce the risk of the WordPress installation, it does make the consequence of a breach less critical.

As you can see, this approach doesn’t resolve the high risk involved with self-hosting a WordPress instance. Although it isolates the problem, which may make the consequences smaller, the main problem remains. A breach in one area of their infrastructure will typically be a stepping stone to compromise the entirety of their systems.

The EA’s second alternative involves moving the WordPress hosting to an externally managed service. While it resolves the challenges of internal hosting, it also requires altering the custom changes that were possible with the internally managed WordPress instance. The integrations with internal services must be changed to work from the outside. To support this, the promotion service must be prepared for internet exposure, and standard WordPress functionality should be used to embed content from the service.

Alternative one only encapsulates the problem without truly solving it, so the EA team decides to move forward with alternative two. Alternative two requires more changes, but it solves the root problem. While it has more initial work, it solves the challenge of a high-risk WordPress installation that is hard to maintain.

Now that they have agreed upon the final solution design, the project is split into smaller, more manageable phases. The EA team uses Ardoq scenarios to document and communicate as they work through these phases.

Pro-tip:

You can model each milestone or phase in a separate Ardoq scenario. When the first phase is modeled, it’s convenient to copy the scenario, give the copy the name of the next phase, and continue modeling there.

In the first preparatory phase, we set up all integrations for the subsequent phases. At this point, no applications have moved, but the integrations are set to support both the current deployment and the future external consumption of the services.

When the new system is operational, we can start throttling traffic towards it. We’ll start with a small portion, sending only a small fraction of our user traffic. The traffic will hit either the hosted External WordPress instance or the internal backup instance. Both instances will consume the same services, either directly or through the firewall.

When we’re confident that the new environment is working as intended, we can stop routing traffic to the old system, and remove the A/B testing configuration. But, for now, we will keep the old system operational just in case.

After a couple of weeks of a fully and successfully operating new system, we’ll decommission the old system.

We will use the same setup as the one agreed upon in the planning phase.

Scenarios help you explore potential future states when you need to document planned changes to your architecture. Take a look at this scenario presentation slide to see the power of Scenarios in action.

To learn more about Scenarios, check the "Getting Started with Scenarios" KB article.