DevOps Automation Service
Domains Involved
- DevOps & Automation
IBM Schematics is an infrastructure-as-code service that takes time and human error out of provisioning cloud resources, allowing DevOps to “templatize” and automate the process.
Solving Long Standing User Pains
Throughout a number of projects on IBM’s Watson & Cloud Platform, my team’s research found that creating resources on the platform was regularly cited as a cumbersome, repetitive, and time consuming process that took developers away from what they wanted to do — build unique value into their applications. This put provisioning squarely on our Top 10 Most Wanted list for user pains.
To address this issue, we performed market and process research to determine that we could use scripting to alleviate this and allow users to automate repeated processes or even schedule or set triggers to allow provisioning behind the scenes without the need for human intervention at all.
Developing and Testing a Hypothesis
Working together, design, development, and product management defined and agreed upon user needs and prioritized them into a roadmap. This roadmap would not be final marching orders for the team. Instead, we distilled the user needs into an MVP with the intent that we release only what we needed to test our hypothesis — Developers had gone to great lengths to create great automated build and versioning processes for their application code. If the application infrastructure could be defined in code rather than manually provisioned piece by piece, those same processes could streamline pipeline development.
Once released, the team used NPS, analytics, and user feedback and testing to validate our plans and respond with change when we gained insights that ran contrary to them.
Once the team aligned on user needs, we weighted them by feasibility and impact and developed a roadmap to act as a living vision for the product — all lead by our definition of a ruthlessly scoped MVP.
Domain Expertise & Complicated Processes
The capturing of application architectures in templates, storing, provisioning, versioning, and hand-off to other automation processes was a complicated process that took the developers who worked with these concepts years to master. The design team worked side by side with development to map out use of infrastructure-as-code technologies and understand how and when developers would use them in their day to day operations.
Such complicated processes meant that the design would need to guide developers through the concepts and steps. To ensure we didn’t “vomit” all of the functionality on the user’s screen at once, we used experience maps to define the UX and information hierarchy.
User flows were mapped to inform the hierarchy of information on each screen and ensure the user saw only what they needed when they needed it.
“If you are not embarrassed…”
Founder of LinkedIn, Reid Hoffman’s famous statement “If you are not embarrassed by the first version of your product, you’ve launched too late,” were words we tried to live by with the initial release of the product. The service lacked support for many of the high-value services we ultimately wanted and was missing much of the functionality defined in our roadmap. However, the team worked continuously to deliver improvements into the service each sprint, and the early release allowed us to prove out our initial hypothesis without heavy investment.
In fact, the early feedback from real world use drew client use cases and insights we had never thought of, which served to continually evolve our roadmap and development backlog to make sure we were building the service our customers actually needed.
I can’t go into further detail about this project publicly, but we can still talk about it.
