THOUGHT LEADERSHIP

2: Know Where You Want to Go

Our firefighting efforts bought us two things: a reasonably resilient and stable minimal viable product, and the time we needed to plan and implement the fully realized vision our founders intended. We hired a product strategist, reviewed all the capabilities and features that our founders wanted to get into the real world, and laid out our product and software roadmaps. Then we compartmentalized features and upgrades into bundles that were easier to digest and pushed them into our systems development life cycle so we could deliver them in a predictable manner.

3: Start from the Top Down

Once you have your roadmaps in place—and they don’t have to be very detailed—you can begin to focus on how to get there. This is where you will start to see the constraint points in your value stream. Constraints can be removed through culture, with processes, with tools, or with a combination of these. But you won’t know until you start experimenting. And you can’t experiment until you ask yourself some questions. You’re still not talking about tools. These should be big architectural questions:

• Based on our product roadmap, how might we need or want to change our technology stack?
• Is our database architecture scalable?
• Where does it make sense to look at our own data center versus a hosted service?
• Should we use a different application framework?

The answers can be found through the lens of your own constraints. For instance, we knew we had an issue integrating with school information systems. One way to solve this issue would be to use application segmentation, by writing a microservice focused on that single task. Moving to a microservices architecture would mean fewer restrictions on where these loosely coupled, containerized apps needed to reside. And that decision would have a direct impact on our platform strategy and the notion of vendor lock-in I mentioned earlier.

Our entire journey is framed around adding automation into the value stream. We had to get to the point where the developers were not waiting on operations to deliver new services. But there was still the issue of security and compliance. Do we allow people to push directly into production, or should there be gates? So we were very interested in infrastructure as code, and in change control with automated assurance.

Automation removes ambiguity from a process. When you spin up an Amazon Elastic Compute Cloud (EC2) server based on a configuration articulated in a job ticket, it may or may not meet the needs of the task. But if you create a cloud formation stack and write a script with a “deploy this when that” trigger, you know what you’re going to get every single time.

You can apply this level of automation to development and integration testing as well. By having trust early in the development cycle, you can increase agility and quality, and the back-end constraints start to fall away.

When you view your existing processes through the lens of your constraints and the ideals of your product roadmap and cultural pillar, ask yourself: Do our processes still make sense? If they don’t, move on. If they do, it’s time to experiment.