BLOG

Secure Cloud Architecture: Planning for Business Outcomes

Tim Wagner Thumbnail
Tim Wagner
Published February 04, 2020
  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share via AddThis

I recently argued that avoiding new technical debt requires a strategic and intentional plan for moving to the cloud. The key word there is plan. One area I find instructive on this front is urban planning. I have a casual interest in the subject, and like a lot of people, love a good best and worst cities list. These lists are often based on a wide variety of factors from accessibility, affordability, and employment to traffic, culture, and restaurants. Here’s the interesting thing: all these factors are heavily influenced—for good and bad—by planning. In the case of something as complex as a major city, this means not just planning for today but planning for tomorrow as well. They need to think holistically about where people live, work, and play, as well as the infrastructure needed to support all of this.

Secure Cloud Architecture is intended to function very much the same way. It’s essentially a “plan” that allows you to choose the tooling to best achieve your outcomes. Let me put that another way: it’s a plan to achieve outcomes, BUSINESS outcomes. As technologists, that’s the thing we must remember. We are here to serve the business, not deploy technology for the sake of technology or get caught up in the latest IT trend. As in urban planning, the difference between success and chaos comes down to smart choices made early based on defined objectives.

Let’s discuss the objectives of Secure Cloud Architecture. As I stated above, IT exists to serve the business, so let’s start with the business outcomes. F5 believes any architecture designed today needs to account for the at least the following:

  1. Ops, governance, and compliance efficiency
  2. Flexibility to adapt with the business
  3. Spend optimization
  4. Enable a platform for innovation

These are fairly self-explanatory, but the point here is that when you design a system you should fully consider the objectives and potential variables from the start. Ask yourself, how does this choice help or hurt operational efficiency? Does a one-off decision today make compliance harder now or in the future? When will I recognize the value of this decision? Am I stuck or can I iterate, evolve, or adapt to changes? Lastly, how many times should I buy, rent or consume something in a design or is a build once and reuse approach the preferred option?

Starting with these questions will inform the design and ensures you are focused on the most important priority: the business outcomes. A well-designed and planned architecture also allows you, the technical experts, to adapt faster to business goals and outcomes. If everyone understands the structure, the desired outcomes and the WHY behind the decisions, you will enable scalable innovation. As the well-known author on personal time management, Alan Lakein said, “Planning is bringing the future into the present so that you can do something about it now.” Time, it turns out, is the one thing we cannot get back, so using it wisely, upfront, just might save you more of it down the road. For those still tempted to skip directly to the technology and not understanding the business outcomes, do so at your own risk, as you may end up on a “worst” list faster than you think.