Blog

Building A Software/ Application Strategy: Part 1

  • 27 March 2019
  • 0 replies
  • 1770 views
Building A Software/ Application Strategy: Part 1
Userlevel 7
Badge +34
This post was authored by Sachin Chheda Senior Director of Solutions Marketing

In a previous blog, I touched on the topic of making infrastructure invisible allowing IT and organizations to focus on applications and initiatives — leverage constructs common in the cloud.

In the next two blogs, we discuss a general level framework for applications and business services, covering the following areas — cataloging applications, tools, and building a roadmap for modernization.

Building a Catalog

It may seem daunting to catalogue the different applications and workloads but done correctly well orchestrated auditing and subsequent cataloging of workloads make decisions on future strategy quick and simple. There are quite a few documented models for creating an application catalog. In conversations with Nutanix experts and our customers, I was captured a few key areas to consider, listed below:

Function: Honest description and classification of the app/workload functionality including history (age, rationale) and business criticality (core to business i.e revenue generating/impacting or equivalent for the organization or playing a supporting function). Some recommended best practices include:
  • Pay attention to [the] origins of workloads, including those inherited through mergers and acquisitions, and identify overlapping or similar ones by business and IT function.
  • Setup simple scoring mechanism based on factors like application criticality, immediate and future revenue and growth impact, user/personnel productivity, brand/external perception etc.
Organization: Identify application/workload owners (owns the budgets—SW, infrastructure, operations, etc), operators (day-to-day responsibility including escalations, updates, etc), users (all users touching the application/workload including other dependent apps and workloads), consultants/external vendors like system integrators, and other vested parties (security and compliance teams, etc). Recommended best practices include:
  • Build out and share the RACI model for the application/service.
  • Capture meetings and processes related to the workload (ex: planning meetings, scrum cycles, business reviews, etc)
Requirements: Capture the application’s infrastructure or cloud services requirements including underlying components, current deployment model (ex: virtualized or bare metal or cloud service), performance, storage and connectivity needs (ex: throughput/connectivity), service levels (ex: uptime, data protection), and security/compliance requirements. Also capture the utilization of the application by time and capacity, by whom and where (location). Some recommended best practices include:
  • Leverage audit/assessment tools that can capture relevant metrics over a period of time. Also, capture seasonality (ex: some workloads may need to scale over periods while others).
  • Capture underlying SW components including functions like databases or app servers (with specific versions). This may include cloud services like object storage or application functions.
  • Capture budget and other resources needed to maintain and refresh/add new functionality.
  • Identify constraints and challenges from both business and IT associated with the applications like uptime or availability, scaling, time to deploy, troubleshooting, and more.
Cloud readiness: Understand the application’s affinity to cloud technologies including use of cloud native technologies and services (ex: packaged in containers/VMs, leveraging RDS/DBaaS or what is now called serverless computing functions), application and data portability, automation, catalogs and self service, measuring usage and chargeback, location of the workload or use of cloud services/hosting, and more. Some recommended best practices include:
  • Understand other tools in IT touching the workload like identify management, self service portals, performance or network performance monitoring, and app/data migration tools. These may be outside of the application/workload — involving the operation teams.
  • Understand the different infrastructure, cloud and application providers involved. As with the tools this may be outside the application/workload.
As mentioned earlier, there are other approaches to creating IT catalogs including the IT service catalog, part of the ITIL(R) best practices for service management. Structured approaches like IT Service Catalog (linked below) may work better for certain organizations vs. others. The key point is the act of cataloging. The next blog in this series concludes the discussion on the framework with a discussion on building a roadmap for application and exploring options from continual investment vs. outsourcing.

Nutanix services has a complementary workshop for qualified customers where they walk through the process. Send us a note at services@nutanix.com to if you are interested in pursuing it with Nutanix. Also, discuss this topic on next.nutanix.com and share your thoughts note on our NEXT community including any resources you and your organization use. We’d love to hear from you!

Additional resources/reading on the topic:
© 2019 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

This topic has been closed for comments