Nothing speaks to the value of a product quite like the purveyor’s willingness to be their own customer. There’s a common expression in the tech industry about “eating one’s own dog food”. Although some have tried to render that as a more refined phrase (e.g. “We drink our own champagne”), the ultimate message is clear: if you haven’t experienced using your own product the same way that one of your customers would, you’re missing an opportunity to step into your customer’s shoes and see things from their perspective.
At Astadia, we’ve been using agile methodologies for quite a while now. With our DevOps services, we’ve been helping organizations transform the way they manage technology, marrying agile methodologies with IBM Z and Unisys mainframe modernization. Following Astadia’s recent acquisition of Anubex, we saw an opportunity to leverage our deep DevOps expertise to build and deploy instances of the Astadia Mainframe Migration Factory for our own client projects.
For our internal teams, this was a win-win. We could automate the process of provisioning new instances of the Migration Factory, saving a substantial amount of effort and eliminating the potential for unintended variability in that process. At the same time, this gave us an opportunity to be our own customer, – to have internal teams at Astadia experience our DevOps services from a client’s perspective. That, in turn, provides us with valuable feedback that we can use to improve our products and services.
Astadia’s DevOps services start with a body of best practices built on our decades of experience serving a wide array of enterprise clients and government agencies. We combine our expertise in development automation, system automation, and test automation with our READI methodology for agile project management. To that, we add a suite of technology tools for development and testing, – then we top it all off with an organizational change management process to assist clients in successfully adopting DevOps or DevSecOps in their organizations.
Our technology stack, broadly speaking, breaks down into two major components, – the Development Engineering Environment (DEE) and the Test Engineering Environment (TEE). The DEE automates the configuration and deployment of a standardized development environment, which ensures consistency for all members of the development team. This eliminates the “configuration drift” that introduces variability in development environments, which can often contribute to issues further downstream. The DEE allows for the management and deployment of standardized environments in the cloud or on virtual machines, fully automated and designed to fit an organization’s unique mix of tools and processes.
The TEE automates the configuration and deployment of test environments, which can be deployed in the cloud or on a VM with equal ease. Tightly integrated with our development automation tools, the TEE shares a common repository with development and streamlines many of the manual tasks that are prone to introduce errors and unintended variability. The TEE works to allow testers the ability to have all the automation tools necessary to perform high quality testing and solves the issue of configuration drift.
As part of a larger umbrella of DevOps methodologies that also includes project management and change management, this technology stack brings the incredibly valuable element of automation to the table. Automation saves time and eliminates variability, – either of which would be sufficient justification for using the DevOps toolset. In combination, they provide a huge win for IT teams.
Prior to the becoming part of Astadia, the team at Anubex would build and deploy instances of the Migration Factory one at a time, as needed. This could be a tedious process. Moreover, it required that each new instance be individually tested to ensure that all components were present, that the most current version of each one was in place, and that everything was functioning as expected. Given the critical nature of the mainframe migration and mainframe modernization projects for which the Migration Factory is deployed, that testing effort could be considerable.
In the context of a well-defined DevOps framework, much of that repetitive effort can now be rendered unnecessary. Today, our Shared Services team initiates the process of creating a new Migration Factory instance by generating a key and providing a set of parameters to be applied to the new environment. These parameters consist of basic information like the client name and project title, but typically also include other variables required to build out a Migration Factory environment for the specific client in question.
From that point forward, everything is automated. Parameters for the environment are passed along to Astadia’s TEE/DEE technology stack, which automatically builds out a new instance of the Migration Factory on AWS. Our Shared Services team receives a notification when that process is complete, and gives our Migration Factory team the green light to begin using the new Migration Factory environment.
This is effecting a lot of positive change within our organization. The Migration Factory provides a powerful means of automating the migration process. Our DevOps tools and methodologies are creating even more automation around that, for even greater efficiency and predictability.
To learn more about our DevOps andDevSecOps offerings, visit Astadia’s DevOps page, or read more about it on our blog. If you’re interested in understanding Astadia’s Migration Factory, check out this article or download the fact sheet.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.
contact us now