Architecting the Agile Enterprise with the Agile Cloud Manager
Part 7 of 16: The Enterprise Pipeline Builds Up From Simple, Cloud-Agnostic Interfaces
Figure 6, entitled “Enterprise Pipeline Builds Up From Simplified Interfaces”, shows how the Agile Cloud Manager can create appliances by reusing your pre-existing building blocks to compose increasingly higher-level components of your enterprise systems.
Figure 6 refers to the Agile Cloud Manager’s Domain Specific Language DSL that enables you to model the unique characteristics of your business in terms of custom types of systems and appliances which can then be easily manipulated by pipelines using the Agile Cloud Manager’s Command Line Interface CLI.
Your Pre-Existing Basic Building Blocks
At the lowest level, (“1” in the Figure 6) you can see how your systems can become cloud-agnostic because functionally-comparable versions of basic building blocks can be defined for any public or private cloud.
Infrastructure-as-code templates can define things like networking and basic compute images in ways that are functionally-equivalent between clouds, on-prem, and edges.
The configuration-as-code templates can then be selected as parameters to customize the behavior of the infrastructure building blocks in a way that keeps configuration templates separate from infrastructure templates.
Reusable SaaS definitions can also be placed here.
Everything at this basic building block level of the diagram can be completely abstracted away by the Agile Cloud Manager’s cloud-agnostic and vendor-agnostic interface, as you will see in subsequent paragraphs that describe the rest of the diagram.
All your basic building blocks might feed into one single, central repository at the enterprise level via CICD processes for each building block project. Then, for security reasons, each consuming group in your enterprise might only receive access to a specific subset of the building blocks via a subscription to only certain items from the central repository. In this way, you can ensure that each building block is governed, not only from a requirements standpoint, but also from a security standpoint.
System Templates Using Agile Cloud Manager’s Domain Specific Language DSL
Next, the system template level, (“2” in the Figure 6) is where you model your unique business as a collection of basic types of systems, each of which performs specific units of work that have specialized value for your unique business.
Each Agile Cloud Manager system template uses our proprietary Domain Specific Language DSL to define a specialized system such as storage, database, messaging, microservices, front-end apps, or any other type of system in unique terms that meet the unique needs of your business.
All system templates in your enterprise might also feed into one single, central system templates-repository at the enterprise level, following the model described for basic building blocks above. The same system templates might be reused by many groups throughout your enterprise. But each group might only use a small subset of the available system templates that your organization might create. Rules for publication and subscription of system templates can eliminate redundant engineering tasks while also making sure that each consuming group only receives the specific templates they are going to use. System templates are extremely powerful, so that part of security includes ensuring that each group only has access to the system templates that are actually needed in their own workflows.
Appliances Using Agile Cloud Manager’s Domain Specific Language DSL
Third, (“3” in the Figure 6) is where appliances represent your domains as very simple templates which in turn refer to a small number of custom system templates which each compose meaningful components of your business model.
A brief acm.yaml file summarizes each domain in such simple terms that it can seem like an appliance.
Enterprise Value Stream Pipeline
Fourth and finally for the Figure 6, (“4” in Figure 6) your enterprise value stream pipeline is composed of all your appliances, each of which uses its own brief, simple acm.yaml file to represent one of your appliances.
Simple CLI commands enable the pipeline to operate on meaningful aspects of your business because:
- The Agile Cloud Manager’s Domain Specific Language DSL enables you to model your systems into unique types.
- And the CLI commands are then able to operate directly on the unique types, which each represent a meaningful aspect of your business.
Each Appliance Has Its Own Stage In Enterprise Pipeline
Figure 7, entitled “Pipeline Delivers Enterprise As Appliances Built Up From Simple Interfaces” illustrates how all the systems in your entire enterprise can be delivered in one single pipeline if you use the Agile Cloud Manager to streamline all your systems into reusable appliances.
The top of Figure 7 revisits the 8 general types of appliances that might appear in enterprise architecture.
Figure 7 also shows how the 4 layers of each cloud appliance together deliver an appliance in each stage in an enterprise pipeline.
Figure 7 shows the same 4 levels that diagram 6 showed, but in Figure 7 you see how each of the 4 levels can appear in its own stage in a pipeline.
Reusable Basic Building Blocks Curated At Enterprise Level
Level 1 at the bottom of Figure 7 illustrates that you can continue to use all your existing 3rd party templates for infrastructure-as-code, for configuration-as-code, and for SaaS definitions.
Level 1 represents reusable templates which can be curated at the enterprise level, with the same templates available for use in any of the stages, for any appliance, and in any pipeline in your enterprise, subject to rules defined by your enterprise.
Reusable System Templates Curated At Enterprise Level
Level 2 in Figure 7 shows where system templates written in the Agile Cloud Manager’s simple Domain Specific Language DSL organize all your pre-existing lower-level templates into units that have meaningful value to your business.
These custom system templates will make it possible for your higher-level pipelines to operate on units that have business impact on your operations.
In level 2, you can create a separate template in each cloud for each of your systems.
The templates for different clouds will look very similar for the same system because the templates all use the same simple Agile Cloud Manager Domain Specific Language DSL.
The differences between templates in different clouds for the same system will be small things such as slightly different sets of parameters required to interface with different types of lower-level templates for different clouds.
Level 2 also shows re-usable system templates that can be reused in any appliance anywhere in your organization, subject to rules that your enterprise might define.
Cloud-Agnostic Enterprise-Level Interface
Levels 3 and 4 in Figure 7 are agnostic with respect to cloud provider because Levels 3 and 4 involve the connection between the Agile Cloud Manager’s Command Line Interface CLI and Domain Specific Language DSL.
The CLI is focused solely on your business’ unique building blocks which are modeled in the Agile Cloud Manager’s Domain Specific Language DSL. The CLI level is therefore completely agnostic with respect to underlying cloud provider. The CLI manipulates business-level objects. And the locations of those business-level objects are outside the scope of the CLI level.
The acm.yaml file that summarizes each of your appliances might contain only a few lines. And each line in each acm.yaml contains only a few simple words. Therefore, changing acm.yaml to switch to a different cloud provider is literally as simple as changing perhaps a couple words on each of perhaps a few lines.
back to Site Home
back to Architecture section Home
Back to Part 6 of 16