Home > Blogs > VMware Operations Transformation Services > Monthly Archives: February 2016

Monthly Archives: February 2016

Building a Holistic IT Strategy Using a Top-Down, Bottom-Up and Middle-Out Approach

Part 2 of the “Cloud Capable – Now What?” Series

Dion ShingBy Dion Shing

The modern business environment is fast, fluid, complex and ambiguous. Businesses in all markets are embattled and face challenges and threats both internally and externally.

In order to adapt, survive and thrive, business strategies should be fluid, adaptable and innovative. From an implementation perspective, strategy should be well communicated to all levels of the organization.

Challenges in IT Strategy Definition

IT StrategyFor many organizations, IT strategy definition occurs infrequently and is based on protecting current position and revenue streams, not taking into account feedback from middle and front line tiers of the business.  Furthermore that strategy is not clearly communicated to the business, or even within the IT organization.

This broken process for strategy definition results in tactics and plans that are often watered down, inadequate and not geared towards leveraging the unique strengths of the company.  For example, a company may say that their strategy is to “improve operating efficiency and provide excellent customer service.”  This strategy only brings their IT department up to par with everyone else, it does not provide any competitive advantage.

To find unique and creative competitive advantages many enterprises adapt an inclusive approach to strategy and develop frameworks such as Top-Down, Bottom-Up and Middle-Out.  This approach recognizes that IT is not only a support function that underpins business processes, but a source of competitive advantage that can provide innovative services that will help drive the strategy and success of the company as a whole.

Top-Down, Bottom-Up and Middle-Out

On their own Top-Down, Bottom-Up and Middle-Out strategies are only partially effective. What is required for effective strategy selection and for the development of rationalized strategies is coordination between all three approaches.

Top-Down

The strategy is established by senior management, and filters down the ranks. Often implementation is not well supported and results are lacking.

Bottom-Up

Strategies developed here focused on specific improvement initiatives and address specific needs, they are typically managed by a single group and manager and are effective.

The downside is that the improvement may occur only in a single area, may not be institutionalized and can lead to complexity and inconsistency. Shadow IT and unsanctioned IT Services can occur.

Middle-Out

Middle management is where the strategies that enable competitive advantages can be championed and communicated.  The effective Bottom-Up strategies developed at the frontline can be supported, nurtured, advocated for and developed by finding sponsors at the executive level, elevating bottom-up strategies to top-down strategies.  Middle management is also effective at translating Top-Down strategies from High-level language into Operational activities to be executed at the frontline

Combined, these represent a force for developing action out of strategy that ultimately drives innovation and finding the illusive competitive advantages.

=======

Dion Shing is an Operations Architect based in Dubai.

DevOps: The Operations Side

Ahmed_croppedBy Ahmed Al-Buheissi

DevOps is about getting Development and Operations to work together and avoid conflicts in how they operate is to achieve their goals. The most commonly noted objective is shifting to Agile processes where applications are released more often and with better quality. While development and operations are of equal importance to a DevOps methodology, this article focuses on the role of Operations in facilitating an efficient and successful DevOps implementation.

In a DevOps environment, the operations team participates in the following activities:

Automation Tools

DevOps AutomationAutomation is a cornerstone to DevOps, as it facilitates continuous integration and delivery of applications into various environments (dev, test, prod, etc.). An example of such automation tools is VMware’s vRealize CodeStream, which allows the creation of release pipelines (e.g., from dev, to test, to production), with various tasks to retrieve application builds, deploy environments, automation testing, and etc. These tools are typically implemented and maintained by the operations teams.

Blueprints

Infrastructure and application blueprints may consist of a number items, such as VM templates, configuration management code, or workflows. Configuration code, e.g., Puppet manifest or Chef cookbooks, are used to configure deployed VM’s and the applications running thereon. Configuration Workflows may also be developed using tools such as vRealize Orchestrator. Dev and operations teams share responsibility for developing the blueprints to ensure deployed environments are correct and ready for use in the various release stages.

Patching and Upgrading

Historically, operations teams held responsibility for maintaining the various tools used by the development and release teams, such as build tools, source-code management tools, automated testing systems, and etc. However, the lines are blurring here as developers take on more coding responsibility for such management. This means Operations teams are housing development teams capable of developing the management automation.

Monitoring

This is one of the areas that are frequently overlooked, or at least rarely mentioned, in a DevOps environment. Monitoring applications through the various promotion environments is very important to ensure a fail-fast approach: potential issues are reported and investigated in early stages (dev and test), before they become real problems.

The operation team also builds dashboards for developers and operations so the application and its environment can be monitored throughout the Continuous-Integration/Continuous-Delivery process. This provides developers with feedback on the applications impact on the environment in which it runs, allows operations to become familiar with the same from an environment (VM/vApp) perspective, and provides confidence to the operations team that the Continuous-Integration/Continuous-Delivery process is working and there will be no issues when the application is released into production

It is worth mentioning that collaboration between development and operations should start very early, as developers need to embed operations considerations in their application code (such as adequate logging information), while the operations team need to ensure infrastructure availability for developers to start their work.

=======

Ahmed Al-Buheissi is an operations technical architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.

Cloud Business Strategy

Part Two of the Cloud Business Management Series

Cloud Business Strategy

By Khalid Hakim, Charlie McVeigh and Reg Lo

At VMware we have the good fortune of working with many different customers on driving and implementing a Cloud Business Strategy.  As we have discussed in some of our prior Cloud Business Management blogs, there is a full spectrum of issues to be considered when considering Cloud Business Management.  This spectrum of issues include:

  • Cloud Strategy
  • Cloud Costing
  • Cloud Marketing
  • Service Level Management & Contracts Management
  • Budgeting & Forecasting
  • Services Definition
  • Cloud Pricing
  • Consumption & Charge-back
  • Cost Optimization

Today we are going to look specifically at the role of Cloud Business Strategy and our time tested workshop approach that we use with our customers to derive a road map to success.

CBM_workshop

Our Cloud Business Management (CBM) Workshops always start by asking our customers what their definition of “success” is when looking forward 18-24 months into the future.  While every customer is unique, the common success criteria that we hear from our customers include the following items:

  • Full transparency for IT consumers as to what they consume and what are the costs for what they are consuming, i.e. who consumes what and at what cost
  • Reclamation and recovery of unused or underutilized infrastructure.
  • Establishment of services definitions for “patterns” (repeatable services in the service catalog) and “snowflakes”  (services that are unique and require engineering to stand the service up.)
  • Reduced time of deployment of services especially “patterns”
  • Understanding from an economic and technical perspective of where is the best place to run cloud workloads. Is it private cloud, public cloud or a hybrid cloud environment? Maybe it is more cost efficient to run temporary workloads in the public cloud than the private one.
  • Incentivizing users to “do the right thing” due to understanding of economics and transparency of costs.
  • Incentivizing users to “do the right thing” due to vastly improved day 0, day 1 and day 2 operations automation.

Once we have an understanding of what “success” will look like in the future, we then drive into a deeper discussion of the following items:

  1. We start by asking for current pain points across the CBM spectrum listed after the first paragraph above. For example: Do you have service definitions? Do you know your costs for services?  Do you engage in pricing strategies?  Are you marketing cloud services to incent user behavior?  Do your users know what they are consuming?  What are you doing for cost optimization?, etc.
  2. We then engage our customers in a discussion of what they would like to see in the future across the CBM spectrum and what tangible improvements that they can anticipate as they mature across each of these disciplines.
  3. Discussions then dive into the current level of maturity across the CBM Spectrum. The key here being that more mature organizations provides higher levels of value to the IT organization and the business consumers of IT resources.
  4. Lastly, a deep dive into data sources that can be used for setting up automated cost modeling are investigated. We are looking to understand what are some of the foundational data sources for Cloud Management (such as vRA, vROPs), Foundation sources for costs (G/L, A/P, Organization, Budgets), Operational Data (Labor rates, Headcount, Compute capacity and metering, Storage capacity and metering, Network capacity and metering, Reporting requirements, Financial practices, etc.)

The workshop and the discussions that occur require a significant discovery effort and detailed listening to our customers.   From this effort we are able to derive a detailed deliverable that results in a tangible Cloud Business Strategy deliverable.   The strategy includes a road map with definitive success points at 6 months, 12 months and 18 – 24 months.

Cloud Business StrategyEmbedded within the Cloud Business Strategy document, is an illustration of what will happen to the organizations maturity across the CBM spectrum if the road map is followed.  Maturity gains will be followed and realized by direct and quantifiable improvements in value provided by the Cloud management team to the business that they are supporting.

For more information and to schedule a Cloud Business Management Workshop for your organization, please contact your local VMware representative.

=======

Khalid Hakim is an operations architect with the VMware Operations Transformation global practice. You can follow him on Twitter @KhalidHakim47.

Charlie McVeigh is an IT business management strategic advisor for VMware. You can follow him on Twitter @cbmcveigh.

Reg Lo is the Director of VMware Accelerate Advisory Services and is based in San Diego, CA.  You can connect with him on LinkedIn.