If you needed to go somewhere and had to build the transportation, which one of the below options work for you? The last picture on the right in each is your final business solution but the paths you go down and the gaps for business value matter. The same scenario pertains to agile software development.
If you are going to automate your environment, you can design your automation processes to be consumable or in bits and pieces along the way. You could attack a use case by automating storage first, than networking, followed by virtualization and so on. The flip side is to not providing any automation for consumption until you have your final product that is ready.
Would you be happy with getting just a tire or two for your car? Could that tire or set of tires really translate into any business value? That tire would be of little direct use or value. There is no business value in the upper half until you get to the end. Your proverbial “9 month” project is over and it is even what you need now?
The flip side is that while the skateboard or scooter might not haul a lot, they still improve your ability to move. The skate board is faster than walking, scooter faster than the skateboard, and so on. With each iteration, you get more value from your prior investment and it is in fact something you can use along the way. Eventually you end up with a car, not the one you originally thought but the one you actually need. You had a choice and at the end you have a convertible, not the hard-top.
How It Relates To the IT Decision Maker
When examining automation efforts, the same kinds of use case inspection are just as important. Productivity can come incrementally or in one big swoosh. Breaking your workflows into chunks might free enough of a particular resource to give you breathing room or prevent a group from getting buried.
The challenge though is having use cases you can split or getting your culture use to a new incremental update process. The process does not mean you do not have deadlines. You certainly still do but that your self-service portal users, administrators or developers could lean more on automation before they could in years past. Some projects might still not lend themselves to this, but that’s where examining your efforts helps plan in aggregate.
Beginning Our Journey
We see it often where a business knows they need to automate. They build a huge requirements list, put out an RFI, get answers back and then have to make sense of a giant matrix. It turns into an incredibly complex cost/comparison discussion. Our argument here is that might not be the best approach.
If the customer chooses to automate, let’s assume for a moment what they really want is their developers to get temporary virtual machines for test/dev. The test/dev environment might include short-term leases of VMs, anti-virus, active-directory enrollment, installation of a few packages and a few firewall openings to facilitate the appropriate access to other resources like a test database. If this is the business priority, the customer might be best served by making a targeted investment to tackle this issue. If there are a few other use cases, then those might play into the purchase decision as well.
The trick will be breaking up the problem into smaller stories that represent what each item is and the business value it offers. If developers are going to be spinning up and tearing down virtual machines, the client might want a self-service portal. The portal helps customers request what they need while keeping the impact of their request off the shoulders of administrators. Even if we just stop right here, we’re looking at something fairly concrete that already gives the customer a lot of choices as to which vendor to look at.
With more to look at, we’re asking the portal system to allow the user to select and manage leases. If done correctly, this ability for selection might be a feature native to the portal and not require additional programming. Hence we now have something we can partially deploy, developer X could request VMs and we’ll time bound their lifetime. This is not trivial as a lot of companies provision machines but are no where near as efficient as reclaiming them.
Antivirus is another are where businesses want software installed for the compliance and protection it provides. Integrations with AV software can be of a few different flavors and automation software typically will not have direct integrations. Some will have silent installs, some will have APIs you can talk to on the AV console servers. In either case, the automation software is spending more time either integrating in the deployment of(silent install) or with console servers via APIs. The step which can be manual or automatic depends more on your choice of AV software. However, the choice of how you implement it is a combination, or as I like to refer to it, a tools confederation. One tool does not do everything hence whatever you select is likely already interacting with multiple systems. This antivirus integration story though represents another clean break where you can take an incremental step to deliver functionality.
Active Directory might be required for the typical reasons AD is required. However, enrollment might include not just joining domains, but putting machine accounts in the right groups and performing other operations in support of following steps. You can have your automation software do these changes directly or include support scripts into your build that your automation tool can leverage.
If you have larger software packages that need to be laid down, you may assess your environment and decide that your existing software management tool does just fine. You are then enabled to make that choice and use it to guide your automation roadmap. If for some reason you do not have any tools to do that, you might find there are specialized tools that do a better job managing software than a general automation package.
Lastly we come to network firewall openings where it’s a combination of process approvals, knowledge transfer like what are the apps for, can we pre-approve anything using standard templates, etc. Here you might find that this is either one bridge too far to look at right now or maybe it’s the perfect bridge to end the use case on. This one step though crosses compliance & security and forces the agility vs security balance discussion. If done correctly, you can start to get your internal processes thinking about how you form a more agile team across the board.
To Iterate or Not
In the story above, you can see how automation could be used to help select a tool or tools to help improve the velocity of your environment. If this case represents your company, you could look at a smaller set of tools, some even with more focus. In the end, regardless of which tool you choose, you are left with something you can break down and decide to deliver to your consumers either in one fell swoop or in iterative releases.
Learn more about the new technologies that are transforming the way enterprise infrastructures are being designed and built.