Master the Secrets of VMware Licensing to Maximize Your Investment

Learn the essential steps to avoid overspending and to maximize negotiation leverage with VMware.

EXECUTIVE BRIEF

Analyst Perspective

Master the Secrets of VMware Licensing to Maximize Your Investment.

The mechanics of negotiating a deal with VMware may seem simple at first as the vendor is willing to provide a heavy discount on an enterprise license agreement (ELA). However, come renewal time, when a reduction in spend or shelfware is needed, or to exit the ELA altogether, the process can be exceedingly frustrating as VMware holds the balance of power in the negotiation. Negotiating a complete agreement with VMware from the start can save you from an immense headache and unforeseen expenditures. Many VMware customers do not realize that the terms and conditions in the Volume Purchasing Program (VPP) and Enterprise Purchasing Program (EPP) agreements limit how and where they are able to use their licenses. Furthermore, after the renewal is complete, organizations must still worry about the management of various license types, accurate discovery of what has been deployed, visibility into license key assignments, and over and under use of licenses. Preventive and proactive measures enclosed within this blueprint will help VMware clients mitigate this minefield of challenges.

Scott Bickley Practice Lead, Vendor Management Info-Tech Research Group

Executive Summary

Info-Tech Insight

VMware customers almost always have incomplete price information from which to effectively negotiate a “best in class” ELA.

Your challenge

VMware's dominant position in the virtualization space can create uncertainty to your options in the long term driven by:

• VMware’s dominant market position and ownership of the virtualization market, which is forcing customers to focus on managing capacity demand to ensure a positive ROI on every license.
• The trend toward a hybrid cloud for many organizations, especially those considering using VMware in public clouds, resulting in confusion regarding licensing and compliance scenarios.

ELAs and EPPs are generally the only way to get a deep discount from VMware.

Common obstacles

There are several hurdles that are presented when considering a VMware ELA.

• A lack of understanding around VMware’s licensing models, bundles, and negotiation tactics makes it difficult to negotiate from a position of strength.
• Unfriendly commercial practices combined with hyperlink-ridden agreements have left organizations vulnerable to audits and large shortfall payments.
• ELAs come in several purchasing models and do not contain the EULA or various VMware product guide documentation that govern license usage rules and can change monthly.

Competition is a key driver of price

Source: Datanyze

Master the Secrets of VMware Licensing to Maximize your Investment

Info-Tech’s methodology for Master the Secrets of VMware Licensing to Maximize Your Investment

Insight summary

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

VMware ELA Analysis Tool	VMware ELA RFQ Template Tool	VPP Transaction Purchase Tool
VMware ELA Analysis Tool	Use this tool as a template for an RFQ with VMware ELA contracts.	Use this tool to analyze cost breakdown and discount based on your volume purchasing program (VPP) level.

Key deliverable:

VMware Business as Usual SnS Renewal Only Tool

Use this tool to analyze discounts from a multi-year agreement vs. prepay. See how you can get the best discount.

Blueprint Objectives

The aim of this blueprint is to provide a foundational understanding of VMware’s licensing agreement and best practices to manage them.

Examining VMware’s vendor profile

Turbonomics conducted a vendor profile on major vendors, focusing on licensing and compliance. It illustrated the following results:

Source: Turbonomics

N-sample size

Case Study

INDUSTRY: Finance

SOURCE: VMware.com

“We’ll have network engineers, storage engineers, computer engineers, database engineers, and systems engineers all working together as one intact team developing and delivering goals on specific outcomes.” – Vipul Nagrath, CIO, ADP

Improving developer capital management

Constant innovation helped ADP keep ahead of customer needs in the human resources space, but it also brought constant changes to the IT environment. Internally, the company found it was spending too long working on delivering the required infrastructure and system updates. IT staff wanted to improve velocity for refreshes to better match the needs of ADP developers and encourage continued development innovation.

Business needs

• Improve turnaround time on infrastructure refreshes to better meet developer roadmaps.
• Establish an IT culture that works at the global scale of ADP and empowers individual team members.
• Streamline approach toward infrastructure resource delivery to reduce need for manual management.

Impact

• Infrastructure resource delivery reduced from 100+ days to minutes, improving ADP developer efficiency.
• VMware Cloud™ on AWS establishes seamless private and public cloud workflows, fostering agility and innovation.
• Automating IT management redirects resources to R&D, boosting time to market for new services.

Info-Tech offers various levels of support to best suit your needs

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 2 to 6 calls over the course of 1 to 2 months.

Phase # 1

Manage Your VMware Agreements

This phase will walk you through the following activities:

• Understanding the VMware licensing model
• Understanding the license agreement options
• Understanding the VMware sales approach

This phase will take you thorough:

• The new VMware subscription movement to the cloud
• How to prepare and migrate
• Manage your subscriptions efficiently

1.1 Establish licensing requirements

VMware has greatly improved the features of vSphere over time.

vSphere Main Editions Overview

• vSphere Standard – Provides the basic features for server consolidation. A support and subscription contract (SnS) is mandatory when purchasing the vSphere Standard.
• vSphere Enterprise Plus – Provides the full range of vSphere features. A support and subscription contract (SnS) is mandatory when purchasing the Enterprise Plus editions.
• vSphere Essentials kit – The Essentials kit is an all-in-one solution for small environments with up to three hosts (2 CPUs on each host). Support is optional when purchasing the Essentials kit and is available on a per-incident basis.
• vSphere Essentials Plus kit – This is similar to the Essentials kit and provides additional features such as vSphere vMotion, vSphere HA, and vSphere replication. A support and subscription contract (SnS) is sold separately, and a minimum of one year of SnS is required.

Review vSphere Edition Features

Download the vSphere Edition 7 Features List

1.2 Evaluate licensing options

VMware agreement types

Review purchase options to align with your requirements.

1.2.1 The Volume Purchasing Program (VPP)

This is the entry-level purchasing program aimed at small/mid-sized organizations.

How the program works

• The threshold to be able to purchase from the VPP program is 250 points minimum, equivalent to $25,000.
• Discounts attained can only be applied to license purchases. They do not apply to service and support/renewals. Discounts range from 4% to 12%.
• For the large majority of products 1 VPP point = ~$100.
  • Point values will be the same globally.
  • Point ratios may vary over time as SKUs are changed.
  • Points are valid for two years.

Benefits

• Budget predictability for two years.
• Simple license purchase process.
• Receive points on qualifying purchases that accumulate over a rolling eight-quarter period.
• Online portal for tracking purchases and eligible discounts.
• Global program where affiliates can purchase from existing contract.

VPP Point & Discount Table

Source: VMware Volume Purchasing Program

1.2.2 Activity VPP Transactional Purchase Tool

1-3 hours

Instructions:

1. Use the tool to analyze the cost breakdown and discount based on your Volume Purchasing Program level.
2. On tab 1, Enter SnS install base renewal units and or new license details.
3. Review tab 2 for Purchase summary.

Download the VPP Transactional Purchase Tool

1.3 Evaluate agreement options

Introduction to EPP and ELA

What to know when using a token/credit-based agreement.

Token/credit-based agreements carry high risk as customers are purchasing a set number of tokens/credits to be redeemed during the ELA term for licenses.

• Tokens/credits that are not used during the ELA term expire and become worthless.
• By default in most agreements (negotiation dependent), tokens/credits are tied to pricing maintained by VMware on its website that is subject to change (increase usually), resulting in a reduced value for the tokens/credits.
  • Therefore, it is necessary to negotiate to have current list prices for all products/versions included in the ELA to prevent price increases while in the current ELA term.
• Token-based agreements may come with a lower overall discount level as VMware is granting more flexibility in terms of the wider product selection offered, vendor cost of overhead to manage the redemption program, currency exchange risks, and more complex revenue recognition headaches.

1.3.1 The Enterprise Purchasing Program (EPP)

This is aimed at mid-tier customers looking for flexibility with deeper discounting.

How the program works

• Token-based program in which tokens are redeemed for licenses and/or SnS.
  • Tokens can be added at any time to active fund.
  • Token usage is automatically tracked and reported.
• Minimum order of 2,500 tokens, equivalent to $250,000 (1 token=$100).
  • Exceptions have been made, allowing for lower minimum spends.
• Restricted to specific regions, not a global agreement.
• Self-service portal for access to license keys and support entitlements.
• Deeper discounting than the VMware Volume Purchase Program.
• EPP initial purchase gets VPP L4 for four years.

Benefits

• Able to mix and match VMware products, manage licenses, and adjust deployment strategy.
• Prices are protected for term of the EPP agreement.
• Number of tokens needed to obtain a product or SnS are negotiated at the start of the contract and fixed for the term.
• SnS is co-termed to the EPP term.
• Ability to purchase new products that become available at a future date and are listed on the EPP Eligibility Matrix.

EPP Level & Point Table

Source: VMware Volume Purchasing Program

1.3.2 The ELA is aimed at large global organizations, offering the deepest discounts with operational benefits and flexibility

What is an ELA?

• The ELA agreement provides the best vehicle for global enterprises to obtain maximum discounts and price-hold protection for a set period of time. Discounts and price holds are removed once an ELA has expired.
• The ELA minimum spend previously was $500,000. Purchase volume now generally starts at $250K total spend with exceptions and, depending on VMware, it may be possible to attain for $150K in net-new license spend.

Key things to know

• Customers pay up front for license and SnS rights, but depending on the deployment plans, the value of the licenses is not realized and/or recognized for up to two years after point of purchase.
• License and SnS is paid up front for a three-year period in most ELAs, although a one- or two-year term can be negotiated.
• Licenses not deployed in year one should be discounted in value and drive a re-evaluation of the ELA ROI, as even heavily discounted licenses that are not used until year three may not be such a great deal in retrospect.
  • Use a time value of money calculation to arrive at a realistic ROI.
  • Partner with Finance and Accounting to ensure the ROI also clears any Internal Hurdle Rate (IHR).
  • Share and strategically position your IHR with VMware and resellers to ensure they understand the minimum value an ELA deal must bring to the table.
• Organizational changes, such as merger, acquisition, and divestiture (MAD) activities, may result in the customer paying for license rights that can no longer be used and/or require a renegotiated ELA.

Info-Tech Insight

If a legacy ELA exists that has “deploy or lose” language, engage VMware to recapture any lost license rights as VMware has changed this language effective with 2016 agreements and there is an “appeals” process for affected customers.

1.3.3 Select the best ELA variant to match your specific demand profile and financial needs

The advantages of an ELA are:

• Maximum discount level + price protection
• SnS discounted at % of net license fee
• Sole option for global use territory rights

General disadvantages are:

• Term lock-in with SnS for three years
• Pay up front and if defer usage, ROI drops
• Territory rights priced at a premium versus domestic use rights

Type of ELAs

1.4 Purchase and manage licenses

Negotiating ELA terms and conditions

Editable copies of VMware’s license and governance documentation are a requirement to initiate the dialogue and negotiation process over T&Cs.

VMware’s licensing is complex and although documentation is publicly available, it is often hidden on VMware’s website.

Many VMware customers often overlook reviewing the license T&Cs, leaving them open to compliance risks.

It is imperative for customers to understand:

• Product definition for licensing of each acquired product
• Products included by bundle
• Use restrictions:
  • The VMware Product Guide, which includes information about:
    • ELA Order Forms, Amendments, Exhibits, EULA, Support T&Cs, and other policies that add dozens of pages to a contractual agreement.
    • All of these documents are web based and can change monthly; URL links in the contract do not take the user to the actual document but a landing page from which customers must find the applicable documents.
  • Obtain copies of ALL current documents at the time of your order and keep as a reference in the CLM and SAM systems.

Build in time to obtain, review, and negotiate these documents (easily weeks to months).

1.4.1 Negotiating ELA terms and conditions specifics

License and Deployment

• Review perpetual use rights for all licenses purchased under the ELA (exception being subscription services).
• Carefully scrutinize contract language for clearly defined deployment rights.
  • Some agreements contain language that terminates the use rights for licenses not deployed by the end of the ELA term.
• While older contracts would frequently contain clearly defined token values and product prices for the ELA term, VMware has moved away from this process and now refers to URL links for current MSRP pricing.

Use Rights

• The customer’s legal entities and territories listed in the contract are hard limits on the license usage via the VMware Product Guide definitions. Global use rights are not a standard license grant with VMware license agreement by default. Global rights are usually tied to an ELA.
• VMware audits most aggressively against violations of territory use rights and will use the non-compliance events to resolve the issue via a commercial transaction.
  • Negotiate for assignment rights with no strings attached in terms of fees or multi-party consent by future affiliates or successors to a surviving entity.
• Extraordinary Corporate Transaction clause: VMware’s standard language prevents customers from using licenses within the ELA for any third party that becomes part of customer’s business by way of acquisition, merger, consolidation, change of control, reorganization, or other similar transaction.
  • Request VMware to drop this language.
• Include any required language pertaining to MAD events as default language will not allow for transfer or assignment of license rights.

Checklist of necessary information to negotiate the best deal

1.4.2 Activity VMware ELA Analysis Tool

2-4 hours

Instructions:

1. As a group, review the various RFQ responses. Identify top three proposals and start to enter proposal details into the VPP Prepay or ELA tabs of the analysis tool.
2. Review savings in the ELA Offer Analysis tab.

Download the VMware ELA Analysis Tool

1.4.3 Negotiating ELA terms and conditions specifics: pricing, renewal, and exit

VMware does not offer price protection on future license consumption by default.

1.4.4 Find the best reseller partner

Seek out a qualified VMware partner that will work with you and with your interest as a priority:

1. Resellers, at minimum, should have achieved an enterprise-level rating, as these partners can offer the deepest discounts and have more clout with VMware.
2. Select your reseller prior to engaging in any RFX acquisition steps. Verify they are enterprise level or higher AND secure their written commitment to maximum pass-through of the discounting provided to them by VMware.
3. Document and prioritize key T&Cs for your ELA and submit to your sales team along with a requirement and timeline for their formal response. Essentially, this escalates outside of the VMware process and disrupts the status quo. Ideally this will occur in advance of being presented a contract by VMware and be pre-emptive in nature.
4. If applicable and of benefit or a high priority, seek out a reseller that is willing to finance the VMware upfront payment cost at a low or no interest rate.
5. It will be important to have ELA-level deals escalated to higher levels of authority to obtain “best in class” discount levels, above and beyond those prescribed in the VMware sales playbook.
6. VMware’s standard process is to “route” customers through a pre-defined channel and “deal desk” process. Preferred pricing of up to an additional 10% discount is reserved for the first reseller that registers the deal with VMware, with larger discounts reserved for the Enterprise and Premium partners. Additional discounts can be earned if the deal closes within specified time periods (First Deal Registration).

1.4.5 Activity VMware ELA RFQ Template

1-3 hours

Use this tool for as a template for an RFQ with VMware ELA contracts.

1. For SnS renewals that contain no new licenses, state that the requirement for award consideration is the provisioning of all details for each itemized SnS renewal product code corresponding to all the licenses of your installed base. The details for the renewals are to be placed in Section 1 of the template.
2. SnS Renewal Options: Info-Tech recommends that you ask for one- and three-year SnS renewal proposals, assuming these terms are realistic for your business requirements. Then compare your SnS BAU costs for these two options against ELA offers to determine the best choice for your renewal.

Download the VMware ELA RFQ Template

1.4.6 Consider your path forward

Consider your route forward as contract commitments, license compliance, and terms and conditions differ in structure to perpetual models previously used.

• Are you able to accurately discover VMware licensing within your environment?
• Is licensing managed for compliance? Are internal audits conducted so you have accurate results?
• Have the product use rights been examined for terms and conditions such as geographic rights? Some T&Cs may change over time due to hyperlinked references within commercial documents.
• How are Oracle and SQL being used within your VMware environment? This may affect license compliance with Oracle and Microsoft in virtualized environments.
• Prepare for the Subscription model; it’s here now and will be the lead discussion with all VMware reps going forward.

Shift to Subscription

1. With the $64bn takeover by Broadcom, there will be a significant shift and pressure to the subscription model.
2. Broadcom has significant growth targets for its VMware acquisition that can only be achieved through a strong press to a SaaS model.

Info-Tech Insight

VMware has a license cost calculator and additional licensing documents that can be used to help determine what spend should be.

Phase # 2

Transition to the VMware Cloud

This phase will walk you through the following activities:

• Understand the VMware licensing model
• Understand the license agreement options
• Understand the VMware sales approach

This phase will take you thorough:

• The new VMware subscription movement to the cloud
• How to prepare and migrate
• Manage your subscriptions efficiently

2.1 Understand the VMware subscription model

VMware Cloud Universal

• VMware Cloud Universal unifies compute, network, and storage capabilities across infrastructures, management, and applications.
• Take advantage of financial and cloud management flexibility by combining on-premises and SaaS capabilities for automation, operations, log analytics, and network visibility across your infrastructure.
• Capitalize on VMware knowledge by integrating proven migration methods and plans across your transformation journey such as consumption strategies, business outcome workshops, and more.
• Determine your eligibility to earn a one-time discount with this exclusive benefit designed to offset the value of your current unamortized VMware on-premises license investments and then reallocate toward your multi-cloud initiatives.

2.2 Migrate workloads and licenses to the cloud

There are several cloud migration options and solutions to consider.

• VMware Cloud offers solutions that can provide a low-cost path to the cloud that will help accelerate modernization.
• There are also many third-party solution providers who can be engaged to migrate workloads and other infrastructure to VMware Cloud and into other public cloud providers.
• VMware Cloud can be deployed on many IaaS providers such as AWS, Azure, Google, Dell, and IBM.

VMware Cloud Assist

1. Leverage all available transition funding opportunities and any IaaS migration incentives from VMware.
2. Learn and understand the value and capabilities of VMware vRealize Cloud Universal to help you transition and manage hybrid infrastructure.

2.2.1 Manage your VMware cloud subscriptions

Use VMware vRealize to manage private, public, and local environments.

Combine SaaS and on-premises capabilities for automation, operations, log analytics, network visibility, security, and compliance into one license.

2.3 The VMware sales approach

Understand the pitch before entering the discussion

1. VMware will present a PowerPoint presentation proposal comparing a Business-as-Usual (BAU) scenario versus the ELA model.
2. Critical factors to consider if considering the proposed ELA are growth rate projections, deployment schedule, cost of non-ELA products/options, shelf-ware, and non-ELA discounts (e.g. VPP, multi-year, or pre-paid).
3. Involving VMware’s direct account team along with your reseller in the negotiations can be beneficial. Keep in mind that VMware ultimately decides on the final price in terms of the discount that is passed through. Ensure you have a clear line of sight into how pricing is determined.
4. Explore reseller incentives and promotional programs that may provide for deeper than normal discount opportunities.

INFO-TECH TIP: Create your own assumptions as inputs into the BAU model and then evaluate the ELA value proposition instead of depending on VMware’s model.

2.4 Manage SnS and cloud subscriptions

The new subscription model is making SnS renewal more complex.

• Start renewal planning four to six months prior to anniversary.
• Work closely with your reseller on your SnS renewal options.
• Request “as is” versus subscription renewal proposal from reseller or VMware with a “savings” component.
• Consider and review multi-year versus annual renewal; savings will differ.
• For the Subscription transition renewal model, ensure that credits for legacy licensing is provided.
• Negotiate cloud transition investments and incentives from VMware.

What information to collect and how to analyze it

• Negotiating toward preferred terms on SnS is critical, more so than when new license purchases are made, as approximately 75-80% of server virtualization are at x86 workloads, where maintenance revenue is a larger source of revenue for VMware than new license sales.
• All relevant license and SnS details must be obtained from VMware to include Product Family, Part Description, Product Code (SKU), Regional/Global List Price, SnS Term Dates, and Discount Price for all new licenses.
• VMware has all costs tied to the US dollar; you must calculate currency conversion into ROI models as VMware does not adjust token values of products across geographies or currency of purchase. The token to dollar value by product SKU is locked for the three-year term. This translates into a variable cost model depending on how local currency fluctuates against the US dollar; time the initial purchase to take this into consideration, if applicable.
• Products purchased based on MSRP price with each token contains a value of US$100. Under the Hybrid Purchasing Program (HPP) credit values and associated buying power will fluctuate over the term as VMware reserves the right to adjust current list prices. Consider locking in a set product list and pricing versus HPP.
• Take a structured approach to discover true discounts via the use of a tailored RFQ template and options model to compare and contrast VMware ELA proposals.

Use Info-Tech Research Group’s customized RFQ template to discover true discount levels and model various purchase options for VMware ELA proposals.

Summary of accomplishment

Knowledge Gained

• The key pieces of licensing information that should be gathered about the current state of your own organization.
• An in-depth understanding of the required licenses across all of your products.
• Clear methodology for selecting the most effective contract type.
• Development of measurable, relevant metrics to help track future project success and identify areas of strength and weakness within your licensing program.

Processes Optimized

• Senior leaders in IT now have a clear understanding of the importance of licensing in relation to business objectives.
• Understanding of the various licensing considerations that need to be made.
• Contract negotiation.

Related Info-Tech Research

Prepare for Negotiations More Effectively

• IT budgets are increasing, but many CIOs feel their budgets are inadequate to accomplish what is being asked of them.
• Eighty percent of organizations don’t have a mature, repeatable, scalable negotiation process.
• Training dollars on negotiations are often wasted or ineffective.

Price Benchmarking & Negotiation

You need to achieve an objective assessment of vendor pricing in your IT contracts, but you have limited knowledge about:

• Current price benchmarking on the vendor.
• Pricing and negotiation intelligence.
• How to secure a market-competitive price.
• Vendor pricing tiers, models, and negotiation tactics.

VMware vRealize Cloud Management

VMware vCloud Suite is an integrated offering that brings together VMware’s industry-leading vSphere hypervisor and VMware vRealize Suite multi-vendor hybrid cloud management platform. VMware’s new portable licensing units allow vCloud Suite to build and manage both vSphere-based private clouds and multi-vendor hybrid clouds.

Bibliography

Barrett, Alex. “vSphere and vCenter licensing and pricing explained -- a VMware license guide.” TechTarget, July 2010. Accessed 7 May 2018.
Bateman, Kayleigh. “VMware licensing, pricing and features mini guide.” Computer Weekly, May 2011. Accessed 7 May 2018.
Blaisdell, Rick. “What Are The Common Business Challenges The VMware Sector Faces At This Point In Time?” CIO Review, n.d. Accessed 7 May 2018.
COMPAREX. “VMware Licensing Program.” COMPAREX, n.d. Accessed 7 May 2018.
Couesbot, Erwann. “Using VMware? Oracle customers hate this licensing pitfall.” UpperEdge, 17 October 2016. Accessed 7 May 2018.
Crayon. “VMware Licensing Programs.” Crayon, n.d. Accessed 7 May 2018.
Datanyze." Virtualization Software Market Share.” Datanyze, n.d. Web.
Demers, Tom. “Top 18 Tips & Quotes on the Challenges & Future of VMware Licensing.” ProfitBricks, 1 September 2015. Accessed 7 May 2018.
Fenech, J. “A quick look at VMware vSphere Editions and Licensing.” VMware Hub by Altaro, 17 May 2017. Accessed 7 May 2018.
Flexera. “Challenges of VMware Licensing.” Flexera, n.d. Accessed 5 February 2018.
Fraser, Paris. “A Guide for VMware Licensing.” Sovereign, 11 October 2016. Accessed 7 May 2018.
Haag, Michael. “IDC Data Shows vSAN is the Largest Share of Total HCI Spending.” VMware Blogs, 1 December 2017. Accessed 7 May 2018.
Kealy, Victoria. “VMware Licensing Quick Guide 2015.” The ITAM Review, 17 December 2015. Accessed 7 May 2018.
Kirsch, Brian. “A VMware licensing guide to expanding your environment.” TechTarget, August 2017. Accessed 7 May 2018.
Kirupananthan, Arun. “5 reasons to get VMware licensing right.” Softchoice, 16 April 2018. Accessed 7 May 2018.
Knorr, Eric. “VMware on AWS: A one-way ticket to the cloud.” InfoWorld, 17 October 2016. Accessed 7 May 2018
Leipzig. “Help, an audit! License audits by VMware. Are you ready?” COMPAREX Group, 2 May 2016. Accessed 7 May 2018.
Mackie, Kurt. “VMware Rips Microsoft for Azure “Bare Metal” Migration Solution.” Redmond Magazine, 27 November 2017. Accessed 7 May 2018.
Micromail. “VMware vSphere Software Licensing.” Micromail, n.d. Accessed 7 May 2018.
Microsoft Corportation. “Migrating VMware to Microsoft Azure” Microsoft Azure, November 2017. Accessed 7 May 2018.
Peter. “Server Virtualization and OS Trends.” Spiceworks, 30 August 2016. Accessed 7 May 2018.
Rich. “VMware running on Azure.” The ITAM Review, 28 November 2017. Accessed 7 May 2018.
Robb, Drew. “Everything you need to know about VMware’s licensing shake up.” Softchoice, 4 March 2016. Accessed 7 May 2018.
Rose, Brendan. “How to determine which VMware licensing option is best.” Softchoice, 28 July 2015. Accessed 7 May 2018.
Scholten, Eric. “New VMware licensing explained.” VMGuru, 12 July 2011. Accessed 7 May 2018.
Sharwood, Simon. “Microsoft to run VMware on Azure, on bare metal. Repeat. Microsoft to run VMware on Azure.” The Register, 22 November 2017. Accessed 7 May 2018.
Siebert, Eric. “Top 7 VMware Management Challenges.” Veeam, n.d. Web.
Smith, Greg. “Will The Real HCI Market Leader Please Stand Up?” Nutanix, 29 September 2017. Accessed 7 May 2018.
Spithoven, Richard. “Licensing Oracle software in VMware vCenter 6.0.” LinkedIn, 2 May 2016. Accessed 7 May 2018.
VMTurbo, Inc. “Licensing, Compliance & Audits in the Cloud Era.” Turbonomics, November 2015. Web.
VMware. “Aug 1st – Dec 31st 2016 Solution Provider Program Requirements & Incentives & Rewards.” VMware, n.d. Web.
VMware. “Global Support and Subscription Services “SnS” Renewals Policy.” VMware, n.d. Web.
VMware. “Support Policies.” VMware, n.d. Accessed 7 May 2018.
VMware. “VMware Cloud Community.” VMware Cloud, n.d. Accessed 7 May 2018.
VMware. “VMware Cloud on AWS” VMware Cloud, n.d. Accessed 7 May 2018.
VMware. “VMware Enterprise Purchasing Program.” VMware, 2013. Web.
VMware. “VMware Product Guide.” VMware, May 2018. Web.
VMware. “VMware Volume Purchasing Program.” VMware, April 2019. Web.
VMware. "VMware Case Studies." VMware, n.d. Web.
Wiens, Rob. “VMware Enterprise Licensing – What You Need To Know. House of Brick, 14 April 2017. Accessed 7 May 2018

Enhance Your Solution Architecture Practice

Ensure your software systems solution is architected to reflect stakeholders’ short- and long-term needs.

Analyst Perspective

Application architecture is a critical foundation for supporting the growth and evolution of application systems. However, the business is willing to exchange the extension of the architecture’s life with quality best practices for the quick delivery of new or enhanced application functionalities. This trade-off may generate immediate benefits to stakeholders, but it will come with high maintenance and upgrade costs in the future, rendering your system legacy early.

Technical teams know the importance of implementing quality attributes into architecture but are unable to gain approval for the investments. Overcoming this challenge requires a focus of architectural enhancements on specific problem areas with significant business visibility. Then, demonstrate how quality solutions are vital enablers for supporting valuable application functionalities by tracing these solutions to stakeholder objectives and conducting business and technical risk and impact assessments through multiple business and technical perspectives.

Andrew Kum-Seun
Research Manager, Applications
Info-Tech Research Group

Enhance Your Solution Architecture

Ensure your software systems solution is architected to reflect stakeholders’ short- and long-term needs.

EXECUTIVE BRIEF

Executive Summary

Your Challenge

• Most organizations have some form of solution architecture; however, it may not accurately and sufficiently support the current and rapidly changing business and technical environments.
• To enable quick delivery, applications are built and integrated haphazardly, typically omitting architecture quality practices.

Common Obstacles

• Failing to involve development and stakeholder perspectives in design can lead to short-lived architecture and critical development, testing, and deployment constraints and risks being omitted.
• Architects are experiencing little traction implementing solutions to improve architecture quality due to the challenge of tracing these solutions back to the right stakeholder objectives.

Info-Tech's Approach

• Translate stakeholder objectives into architecture requirements, solutions, and changes. Incorporate architecture quality attributes in decisions to increase your architecture’s life.
• Evaluate your solution architecture from multiple views to obtain a holistic perspective of the range of issues, risks, and opportunities.
• Regularly review and recalibrate your solution architecture so that it accurately reflects and supports current stakeholder needs and technical environments.

Info-Tech Insight

Well-received applications can have poor architectural qualities. Functional needs often take precedence over quality architecture. Quality must be baked into design, execution, and decision-making practices to ensure the right tradeoffs are made.

A badly designed solution architecture is the root of all technical evils

A well-thought-through and strategically designed solution architecture is essential for the long-term success of any software system, and by extension, the organization because:

1. It will help achieve quality attribute requirements (security, scalability, performance, usability, resiliency, etc.) for a software system.
2. It can define and refine architectural guiding principles. A solution architecture is not only important for today but also a vision for the future of the system’s ability to react positively to changing business needs.
3. It can help build usable (and reusable) services. In a fast-moving environment, the convenience of having pre-made plug-and-play architectural objects reduces the risk incurred from knee-jerk reactions in response to unexpected demands.
4. It can be used to create a roadmap to an IT future state. Architectural concerns support transition planning activities that can lead to the successful implementation of a strategic IT plan.

Demand for quick delivery makes teams omit architectural best practices, increasing downstream risks

In its need for speed, a business often doesn’t see the value in making sure architecture is maintainable, reusable, and scalable. This demand leads to an organizational desire for development practices and the procurement of vendors that favor time-to-market over long-term maintainability. Unfortunately, technical teams are pushed to omit design quality and validation best practices.

What are the business impacts of omitting architecture design practices?

Poor quality application architecture impedes business growth opportunities, exposes enterprise systems to risks, and consumes precious IT budgets in maintenance that could otherwise be used for innovation and new projects.

Previous estimations indicate that roughly 50% of security problems are the result of software design. […] Flaws in the architecture of a software system can have a greater impact on various security concerns in the system, and as a result, give more space and flexibility for malicious users.(Source: IEEE Software)

Errors in software requirements and software design documents are more frequent than errors in the source code itself according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also more severe and more difficult to remove. (Source: iSixSigma)

Design a solution architecture that can be successful within the constraints and complexities set before you

APPLICATION ARCHITECTURE…

… describes the dependencies, structures, constraints, standards, and development guidelines to successfully deliver functional and long-living applications. This artifact lays the foundation to discuss the enhancement of the use and operations of your systems considering existing complexities.

Good architecture design practices can give you a number of benefits:

Lowers maintenance costs by revealing key issues and risks early. The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was 4 to 5 times as much as one uncovered during design.(iSixSigma)

Supports the design and implementation activities by providing key insights for project scheduling, work allocation, cost analysis, risk management, and skills development.(IBM: developerWorks)

Eliminates unnecessary creativity and activities on the part of designers and implementers, which is achieved by imposing the necessary constraints on what they can do and making it clear that deviation from constraints can break the architecture.(IBM: developerWorks)

Use Info-Tech’s Continuous Solution Architecture (CSA) Framework for designing adaptable systems

Solution architecture is not a one-size-fits-all conversation. There are many design considerations and trade-offs to keep in mind as a product or services solution is conceptualized, evaluated, tested, and confirmed. The following is a list of good practices that should inform most architecture design decisions.

Principle 1: Design your solution to have at least two of everything.

Principle 2: Include a “kill switch” in your fault-isolation design. You should be able to turn off everything you release.

Principle 3: If it can be monitored, it should be. Use server and audit logs where possible.

Principle 4: Asynchronous is better than synchronous. Asynchronous design is more complex but worth the processing efficiency it introduces.

Principle 5: Stateless over stateful: State data should only be used if necessary.

Principle 6: Go horizonal (scale out) over vertical (scale up).

Principle 7: Good architecture comes in small packages.

Principle 8: Practice just-in-time architecture. Delay finalizing an approach for as long as you can.

Principle 9: X-ilities over features. Quality of an architecture is the foundation over which features exist. A weak foundation can never be obfuscated through shiny features.

Principle 10: Architect for products not projects. A product is an ongoing concern, while a project is short lived and therefore only focused on what is. A product mindset forces architects to think about what can or should be.

Principle 11: Design for rollback: When all else fails, you should be able to stand up the previous best state of the system.

Principle 12: Test the solution architecture like you test your solution’s features.

CSA should be used for every step in designing a solution’s architecture

Solution architecture is a technical response to a business need, and like all complex evolutionary systems, must adapt its design for changing circumstances.

The triggers for changes to existing solution architectures can come from, at least, three sources:

1. Changing business goals
2. Existing backlog of technical debt
3. Solution architecture roadmap

A solution’s architecture is cross-cutting and multi-dimensional and at the minimum includes:

• Product Portfolio Strategy
• Application Architecture
• Data Architecture
• Information Architecture
• Operational Architecture

along with several qualitative attributes (also called non-functional requirements).

Related Research: Product Portfolio Strategy

Integrate Portfolios to Create Exceptional Customer Value

• Define an organizing principle that will structure your projects and applications in a way that matters to your stakeholders.
• Bridge application and project portfolio data using the organizing principle that matters to communicate with stakeholders across the organization.
• Create a dashboard that brings together the benefits of both project and application portfolio management to improve visibility and decision making.

Deliver on Your Digital Portfolio Vision

• Recognize that a vision is only as good as the data that backs it up. Lay out a comprehensive backlog with quality built in that can be effectively communicated and understood through roadmaps.
• Your intent is only a dream if it cannot be implemented ; define what goes into a release plan via the release canvas.
• Define a communication approach that lets everyone know where you are heading.

Related Research: Data, Information & Integration Architecture

Build a Data Architecture Roadmap

• Have a framework in place to identify the appropriate solution for the challenge at hand. Our three-phase practical approach will help you build a custom and modernized data architecture.
• Identify and prioritize the business drivers in which data architecture changes would create the largest overall benefit and determine the corresponding data architecture tiers that need to be addressed.
• Discover the best-practice trends, measure your current state, and define the targets for your data architecture tactics.
• Build a cohesive and personalized roadmap for restructuring your data architecture. Manage your decisions and resulting changes.

Build a Data Pipeline for Reporting and Analytics

• Understand your high-level business capabilities and interactions across them – your data repositories and flows should be just a digital reflection thereof.
• Divide your data world in logical verticals overlaid with various speed data progression lanes, i.e. build your data pipeline – and conquer it one segment at a time.
• Use the most appropriate database design pattern for a given phase/component in your data pipeline progression.

Related Research:Operational Architecture

Optimize Application Release Management

• Acquire release management ownership. Ensure there is appropriate accountability for the speed and quality of the releases passing through the entire pipeline.
• A release manager has oversight over the entire release process and facilitates the necessary communication between business stakeholders and various IT roles.
• Instill holistic thinking. Release management includes all steps required to push release and change requests to production along with the hand-off to Operations and Support. Increase the transparency and visibility of the entire pipeline to ensure local optimizations do not generate bottlenecks in other areas.
• Standardize and lay a strong release management foundation. Optimize the key areas where you are experiencing the most pain and continually improve.

Build Your Infrastructure Roadmap

• Increased communication. More information being shared to more people who need it.
• Better planning. More accurate information being shared.
• Reduced lead times. Less due diligence or discovery work required as part of project implementations.
• Faster delivery times. Less low-value work, freeing up more time for project work.

Related Research:Security Architecture

Identify Opportunities to Mature the Security Architecture

• A right-sized security architecture can be created by assessing the complexity of the IT department, the operations currently underway for security, and the perceived value of a security architecture within the organization. This will bring about a deeper understanding of the organizational infrastructure.
• Developing a security architecture should also result in a list of opportunities (i.e. initiatives) that an organization can integrate into a roadmap. These initiatives will seek to improve security operations and strengthen the IT department’s understanding of security’s role within the organization.
• A better understanding of the infrastructure will help to save time on determining the correct technologies required from vendors, and therefore, cut down on the amount of vendor noise.
• Creating a defensible roadmap will assist with justifying future security spend.

Key deliverable:

Solution Architecture Template
Record the results from the exercises to help you define, detail, and make real your digital product vision.

Blueprint Deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.

Guided Implementation

Our team knows that we need to fix a process, but we need assistance to determine where to focus. some check-ins along the way would help keep us on track

Workshop

We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place

Consulting

Our team does not have the time or the knowledge to take this project on. we need assistance through the entirety of this project.

Diagnostics and consistent frameworks are used throughout all four options

Workshop Overview

Contact your account representative for more information. workshops@infotech.com 1-888-670-8889

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is series of calls with an Info-Tech analyst to help implement our best practices in your organization.
This GI is between 8 to 10 calls over the course of approximately four to six months.

Phase 1: Visions and Value Maps

Phase 1

1.1 Articulate an Architectural Vision
1.2 Develop Dynamic Value Stream Maps
1.3 Map Value Streams, Use Cases, and Required Architectural Attributes
1.4 Create a Prioritized List of Architectural Attributes

Phase 2

2.1 Develop a Data Architecture That Supports Transactional and Analytical Needs
2.2 Document Security Architecture Risks and Mitigations

Phase 3

3.1 Document Scalability Architecture
3.2 Document Performance Enhancing Architecture
3.3 Combine the Different Architecture Design Decisions Into a Unified Solution Architecture

This phase will walk you through the following activities:

• Determine a vision for architecture outcomes
• Draw dynamic value stream maps
• Derive architectural design decisions
• Prioritize design decisions

This phase involves the following participants:

• Business Architect
• Product Owner
• Application Architect
• Integration Architect
• Database Architect
• Enterprise Architect

Enhance Your Solution Architecture Practice

Let’s get this straight: You need an architectural vision

If you start off by saying I want to architect a system, you’ve already lost. Remember what a vision is for!

An architectural vision...

… is your North Star

Your product vision serves as the single fixed point for product development and delivery.

… aligns stakeholders

It gets everyone on the same page.

… helps focus on meaningful work

There is no pride in being a rudderless ship. It can also be very expensive.

And eventually...

… kick-starts your strategy

We know where to go, we know who to bring along, and we know the steps to get there. Let’s plan this out.

An architectural vision is multi-dimensional

Who is the target customer (or customers)?

What is the key benefit a customer can get from using our service or product?

Why should they be engaged with you?

What makes our service or product better than our competitors?

(Adapted from Crossing the Chasm)

Info-Tech Insight

It doesn’t matter if you are delivering value to internal or external stakeholders, you need a product vision to ensure everyone understands the “why.”

Use a canvas as the dashboard for your architecture

The solution architecture canvas provides a single dashboard to quickly define and communicate the most important information about the vision. A canvas is an effective tool for aligning teams and providing an executive summary view.

Leverage the solution architecture canvas to state and inform your architecture vision

1.1 Craft a vision statement for your solution’s architecture

1. Use the product canvas template provided for articulating your solution’s architecture.

There are different statement templates available to help form your product vision statements. Some include:

• For [our target customer], who [customer’s need], the [product] is a [product category or description] that [unique benefits and selling points]. Unlike [competitors or current methods], our product [main differentiators].
• We believe (in) a [noun: world, time, state, etc.] where [persona] can [verb: do, make, offer, etc.], for/by/with [benefit/goal].
• To [verb: empower, unlock, enable, create, etc.] [persona] to [benefit, goal, future state].
• Our vision is to [verb: build, design, provide] the [goal, future state] to [verb: help, enable, make it easier to...] [persona].

(Adapted from Crossing the Chasm)

Download the Solution Architecture Template and document your vision statement.

Input

• Business Goals
• Product Portfolio Vision

Output

• Solution Architecture Vision

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Product Owner
• IT Leadership
• Business Leadership

Solution Architecture Canvas: Refine your vision statement

Understand your value streams before determining your solution’s architecture

Business Strategy

Sets and communicates the direction of the entire organization.

Value Stream

Segments, groups, and creates a coherent narrative as to how an organization creates value.

Business Capability Map

Decomposes an organization into its component parts to establish a common language across the organization.

Execution

Implements the business strategy through capability building or improvement projects.

Identify your organization’s goals and define the value streams that support them

Goal

Revenue Growth

Value Streams

Stream 1- Product Purchase
Stream 2- Customer Acquisition
stream 3- Product Financing

There are many techniques that help with constructing value streams and their capabilities.

Domain-driven design is a technique that can be used for hypothesizing the value maps, their capabilities, and associated solution architecture.

Read more about domain-driven design here.

Value streams can be external (deliver value to customers) or internal (support operations)

External Perspective

1. Core value streams are mostly externally facing: they deliver value to either an external/internal customer and they tie to the customer perspective of the strategy map.

• E.g. customer acquisition, product purchase, product delivery

Internal Perspective

• E.g. employee recruitment to retirement

Key Questions to Ask While Evaluating Value Streams

• Who are your customers?
• What benefits do we deliver to them?
• How do we deliver those benefits?
• How does the customer receive the benefits?

Value streams highlight the what, not the how

Value chains set a high-level context, but architectural decisions still need to be made to deal with the dynamism of user interaction and their subsequent expectations. User stories (and/or use cases) and themes are great tools for developing such decisions.

Product Delivery

1. Order Confirmation
2. Order Dispatching
3. Warehouse Management
4. Fill Order
5. Ship Order
6. Deliver Order

Use Case and User Story Theme: Confirm Order

The use case Confirming Customer’s Online Order has four actors:

1. An Online Buyer who should be provided with a catalog of products to purchase from.
2. An Online Catalog that is invoked to display its contents on demand.
3. An Integrated Payment system for accepting an online form of payment (credit card, Bitcoins, etc.) in a secure transaction.
4. An Inventory Lookup module that confirms there is stock available to satisfy the Online Buyer’s order.

Info-Tech Insight

Each use case theme links back to a feature(s) in the product backlog.

Related Research

Deliver on Your Digital Portfolio Vision

• Recognize that a vision is only as good as the data that backs it up. Lay out a comprehensive backlog with quality built in that can be effectively communicated and understood through roadmaps.
• Your intent is only a dream if it cannot be implemented – define what goes into a release plan via the release canvas.
• Define a communication approach that lets everyone know where you are heading.

Document Your Business Architecture

• Recognize the opportunity for architecture work, analyze the current and target states of your business strategy, and identify and engage the right stakeholders.
• Model the business in the form of architectural blueprints.
• Apply business architecture techniques such as strategy maps, value streams, and business capability maps to design usable and accurate blueprints of the business.
• Drive business architecture forward to promote real value to the organization.
• Assess your current projects to determine if you are investing in the right capabilities. Conduct business capability assessments to identify opportunities and to prioritize projects.

Example: Dynamic value stream map

Loan Provision*

*Value Stream Name: Usually has the same name as the capability it illustrates.

Loan Application**; Disbursement of Fund**; Risk Management**; Service Accounts**

**Value Stream Components: Specific functions that support the successful delivery of a value stream.

Disbursement of Funds

Style #1:

The use case Disbursement of Funds has three actors:

1. A Loan Applicant who applied for a loan and got approved for one.
2. A Loan Supplier who is the source for the funds.
3. The Applicant’s Bank that has an account into which the funds are deposited.

Style # 2:

Loan Provision: Disbursement of Funds
Use Case	Actors	Expectation
Deposit Loan Into Applicant’s Bank Account	Loan Applicant Loan Supplier Applicant’s Bank	Should be able to see deposit in bank account Deposit funds into account Accept funds into account

Example for Phase 1.3

Loan Provision

Loan Application → Disbursement of Funds → Risk Management → Service Accounts

1.2 Document dynamic value stream maps

1. Create value stream maps that support your business objectives.

• The value stream maps could belong to existing or new business objectives.

• Determine use case(s), the actors, and their expected activity.

*Refer to the next slide for an example of a dynamic value stream map.

Download the Solution Architecture Template for documentation of dynamic value stream map

Input

• Business Goals
• Some or All Existing Business Processes
• Some or All Proposed New Business Processes

Output

• Dynamic Value Stream Maps for Multiple Use Roles and Use Cases

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Product Owner
• Application Architect
• Integration Architect

Example: Dynamic value stream map

Loan Provision*

*Value Stream Name: Usually has the same name as the capability it illustrates.

Loan Application**; Disbursement of Fund**; Risk Management**; Service Accounts**

**Value Stream Components: Specific functions that support the successful delivery of a value stream.

Disbursement of Funds

Style #1:

The use case Disbursement of Funds has three actors:

1. A Loan Applicant who applied for a loan and got approved for one.
2. A Loan Supplier who is the source for the funds.
3. The Applicant’s Bank that has an account into which the funds are deposited.

Style # 2:

Mid-Phase 1 Checkpoint

By now, the following items are ideally completed:

• Mid-Phase 1 Checkpoint

Start with an investigation of your architecture’s qualitative needs

Quality attributes can be viewed as the -ilities (e.g. scalability, usability, reliability) that a software system needs to provide. A system not meeting any of its quality attribute requirements will likely not function as required. Examples of quality attributes are:

1. Slow system response time
2. Security breaches that result in loss of personal data
3. A product feature upgrade that is not compatible with previous versions

Focus on quality attributes that are architecturally significant.

• Not every system requires every quality attribute.
• Pay attention to those attributes without which the solution will not be able to satisfy a user’s abstract* expectation.
• This set can be considered Architecturally Significant Requirements (ASR). ASR concern scenarios have the most impact on the architecture of the software system.
• ASR are fundamental needs of the system and changing them in the future can be a costly and difficult exercise.

*Abstract since attributes like performance and reliability are not directly measurable by a user.

Stimulus Response Measurement Environmental Context

For applicable use cases: (*Adapted from S Carnegie Mellon University, 2000)

1. Determine the Stimulus (temporal, external, or internal) that puts stress on the system. For example, a VPN-accessed hospital management system is used for nurses to login at 8am every weekday.
2. Describe how the system should Respond to the stimulus. For example, the hospital management system should complete a nurse login under 10ms on initiation of the HTTPS request.
3. Set a Measurement criteria for determining the success of the response to the stimulus. For example, the system should be able to successfully respond to 98% of the HTTPS requests the first time.
4. Note the environmental context under which the stimulus occurs, including any unusual conditions in effect.

• The hospital management system needs to respond in under 10ms under typical load or peak load?
• What is the time variance of peak loads, for example, an e-commerce system during a Black Friday sale?
• How big is the peak load?

Info-Tech Insight

Three out of four is bad. Don’t architect for normal situations because the solution will be fragile and prone to catastrophic failure under unexpected events.
Read article: Retail sites crash under weight of online Black Friday shoppers.

Discover and evaluate the qualitative attributes needed for use cases or user stories

Deposit Loan Into Applicant’s Bank Account

Assume analysis is being done for a to-be developed system.

Use cases developed in Phase 1.2 should be used here. (Adapted from the ATAM Utility Tree Method for Quality Attribute Engineering)

Reduce technical debt while you are at it

Deposit Loan Into Applicant’s Bank Account

Assume analysis is being done for a to-be developed system.

1.3 Create a conceptual map between the value streams, use cases, and required architectural attributes

1. For selected use cases completed in Phase 1.2:

• Map the value stream to its associated use cases.
• For each use case, list the required architectural quality attributes.

Download the Solution Architecture Template for mapping value stream components to their required architectural attribute.

Input

• Use Cases
• User Roles
• Stimulus to System
• Response From System
• Response Measurement

Output

• List of Architectural Quality Attributes

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Application Architect
• Integration Architect
• Database Architect
• Infrastructure Architect

Prioritize architectural quality attributes to ensure a right-engineered solution

Trade-offs are inherent in solution architecture. Scaling systems may impact performance and weaken security, while fault-tolerance and redundancy may improve availability but at higher than desired costs. In the end, the best solution is not always perfect, but balanced and right-engineered (versus over- or under-engineered).

Loan Provision

Loan Application → Disbursement of Funds → Risk Management → Service Accounts

1. Map architecture attributes against the value stream components.

• Use individual use cases to determine which attributes are needed for a value stream component.

In our example, the prioritized list of architectural attributes are:

• Security (4 votes for Very Important)
• Data Reliability (2 votes for Very Important)
• Scalability (1 vote for Very Important and 1 vote for Fairly Important) and finally
• Resilience (1 vote for Very Important, 0 votes for Fairly Important and 1 vote for Mildly Important)
• Performance (0 votes for Very Important, 2 votes for Fairly Important)

1.4 Create a prioritized list of architectural attributes (from 1.3)

1. Using the tabular structure shown on the previous slide:

• Map each value stream component against architectural quality attributes.
• For each mapping, indicate its importance using the green, blue, and yellow color scheme.

Download the Solution Architecture Template and document the list of architectural attributes by priority.

Input

• List of Architectural Attributes From 1.3

Output

• Prioritized List of Architectural Attributes

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Application Architect
• Integration Architect
• Database Architect
• Infrastructure Architect

End of Phase 1

At the end of this Phase, you should have completed the following activities:

• Documented a set of dynamic value stream maps along with selected use cases.
• Using the SRME framework, identified quality attributes for the system under investigation.
• Prioritized quality attributes for system use cases.

Phase 2: Multi-Purpose Data and Security Architecture

Phase 1

1.1 Articulate an Architectural Vision
1.2 Develop Dynamic Value Stream Maps
1.3 Map Value Streams, Use Cases, and Required Architectural Attributes
1.4 Create a Prioritized List of Architectural Attributes

Phase 2

2.1 Develop a Data Architecture That Supports Transactional and Analytical Needs
2.2 Document Security Architecture Risks and Mitigations

Phase 3

3.1 Document Scalability Architecture
3.2 Document Performance Enhancing Architecture
3.3 Combine the Different Architecture Design Decisions Into a Unified Solution Architecture

This phase will walk you through the following activities:

• Understand the scalability, performance, resilience, and security needs of the business.

This phase involves the following participants:

• Business Architect
• Product Owner
• Application Architect
• Integration Architect
• Database Architect
• Enterprise Architect

Enhance Your Solution Architecture Practice

Fragmented data environments need something to sew them together

• A full 93% of enterprises have a multi-cloud strategy, with 87% having a hybrid-cloud environment in place.
• On average, companies have data stored in 2.2 public and 2.2 private clouds as well as in various on-premises data repositories.

Source: Flexera

In addition, companies are faced with:

• Access and integration challenges (Who is sending the data? Who is getting it? Can we trust them?)
• Data format challenges as data may differ for each consumer and sender of data
• Infrastructure challenges as data repositories/processors are spread out over public and private clouds, are on premises, or in multi-cloud and hybrid ecosystems
• Structured vs. unstructured data

A robust and reliable integrated data architecture is essential for any organization that aspires to be relevant and impactful in its industry.

Data’s context and influence on a solution’s architecture cannot be overestimated

Data used to be the new oil. Now it’s the life force of any organization that has serious aspirations of providing profit-generating products and services to customers. Architectural decisions about managing data have a significant impact on the sustainability of a software system as well as on quality attributes such as security, scalability, performance, and availability.

Storage and Processing go hand in hand and are the mainstay of any data architecture. Due to their central position of importance, an architecture decision for storage and processing must be well thought through or they become the bottleneck in an otherwise sound system.

Ingestion refers to a system’s ability to accept data as an input from heterogenous sources, in different formats, and at different intervals.

Dissemination is the set of architectural design decisions that make a system’s data accessible to external consumers. Major concerns involve security for the data in motion, authorization, data format, concurrent requests for data, etc.

Orchestration takes care of ensuring data is current and reliable, especially for systems that are decentralized and distributed.

Data architecture requires alignment with a hybrid data management plan

Most companies have a combination of data. They have data they own using on-premises data sources and on the cloud. Hybrid data management also includes external data, such as social network feeds, financial data, and legal information amongst many others.

Data integration architectures have typically been put in one of two major integration patterns:

Sidebar

Difference between real-time, batch, and streaming data movements

Real-Time

• Reacts to data in seconds or even quicker.
• Real-time systems are hard to implement.

Batch

• Batch processing deals with a large volume of data all at once and data-related jobs are typically completed simultaneously in non-stop, sequential order.
• Batch processing is an efficient and low-cost means of data processing.
• Execution of batch processing jobs can be controlled manually, providing further control over how the system treats its data assets.
• Batch processing is only useful if there are no requirements for data to be fresh and current. Real-time systems are suited to processing data that requires these attributes.

Streaming

• Stream processing allows almost instantaneous analysis of data as it streams from one device to another.
• Since data is analyzed quickly, storage may not be a concern (since only computed data is stored while raw data can be dispersed).
• Streaming requires the flow of data into the system to equal the flow of data computing, otherwise issues of data storage and performance can rise.

Modern data ingestion and dissemination frameworks keep core data assets current and accessible

Data ingestion and dissemination frameworks are critical for keeping enterprise data current and relevant.

Data ingestion/dissemination frameworks capture/share data from/to multiple data sources.

Factors to consider when designing a data ingestion/dissemination architecture

What is the mode for data movement?

• The mode for data movement is directly influenced by the size of data being moved and the downstream requirements for data currency.
• Data can move in real-time, as a batch, or as a stream.

What is the ingestion/dissemination architecture deployment strategy?

• Outside of critical security concerns, hosting on the cloud vs. on premises leads to a lower total cost of ownership (TCO) and a higher return on investment (ROI).

How many different and disparate data sources are sending/receiving data?

• Stability comes if there is a good idea about the data sources/recipient and their requirements.

What are the different formats flowing through?

• Is the data in the form of data blocks? Is it structured, semi-unstructured, or unstructured?

What are expected performance SLAs as data flow rate changes?

• Data change rate is defined as the size of changes occurring every hour. It helps in selecting the appropriate tool for data movement.
• Performance is a derivative of latency and throughput, and therefore, data on a cloud is going to have higher latency and lower throughput then if it is kept on premises.
• What is the transfer data size? Are there any file compression and/or file splits applied on the data? What is the average and maximum size of a block object per ingestion/dissemination operation?

What are the security requirements for the data being stored?

• The ingestion/dissemination framework should be able to work through a secure tunnel to collect/share data if needed.

Sensible storage and processing strategy can improve performance and scalability and be cost-effective

The range of options for data storage is staggering...

… but that’s a good thing because the range of data formats that organizations must deal with is also richer than in the past.

Different strokes for different workloads.

The data processing tool to use may depend upon the workloads the system has to manage.

Expanding upon the Risk Management use case (as part of the Loan Provision Capability), one of the outputs for risk assessment is a report that conducts a statistical analysis of customer profiles and separates those that are possibly risky. The data for this report is spread out across different data systems and will need to be collected in a master data management storage location. The business and data architecture team have discussed three critical system needs, noted below:

Keep every core data source on the same page through orchestration

Data orchestration, at its simplest, is the combination of data integration, data processing, and data concurrency management.

Data pipeline orchestration is a cross-cutting process that manages the dependencies between your data integration tasks and scheduled data jobs.

A task or application may periodically fail, and therefore, as a part of our data architecture strategy, there must be provisions for scheduling, rescheduling, replaying, monitoring, retrying, and debugging the entire data pipeline in a holistic way.

Some of the functionality provided by orchestration frameworks are:

• Job scheduling
• Job parametrization
• SLAs tracking, alerting, and notification
• Dependency management
• Error management and retries
• History and audit
• Data storage for metadata
• Log aggregation

2.1 Discuss and document data architecture decisions

1. Using the value maps and associated use cases from Phase 1, determine the data system quality attributes.
2. Use the sample tabular layout on the next slide or develop one of your own.

Download the Solution Architecture Template for documenting data architecture decisions.

Input

• Value Maps and Use Cases

Output

• Initial Set of Data Design Decisions

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Application Architect
• Integration Architect
• Database Architect
• Infrastructure Architect

Example: Data Architecture

There is no free lunch when making the most sensible security architecture decision; tradeoffs are a necessity

Ensuring that any real system is secure is a complex process involving tradeoffs against other important quality attributes (such as performance and usability). When architecting a system, we must understand:

• Its security needs.
• Its security threat landscape.
• Known mitigations for those threats to ensure that we create a system with sound security fundamentals.

The first thing to do when determining security architecture is to conduct a threat and risk assessment (TRA).

Related Research

Optimize Security Mitigation Effectiveness Using STRIDE

• Have a clear picture of:
• Critical data and data flows
• Organizational threat exposure
• Security countermeasure deployment and coverage
• Understand which threats are appropriately mitigated and which are not.
• Generate a list of initiatives to close security gaps.
• Create a quantified risk and security model to reassess program and track improvement.
• Develop measurable information to present to stakeholders.

The 3A’s of strong security: authentication, authorization, and auditing

Authentication

Authentication mechanisms help systems verify that a user is who they claim to be.

Examples of authentication mechanisms are:

• Two-Factor Authentication
• Single Sign-On
• Multi-Factor Authentication
• JWT Over OAUTH

Authorization

Authorization helps systems limit access to allowed features, once a user has been authenticated.

Examples of authentication mechanisms are:

• RBAC
• Certificate Based
• Token Based

Auditing

Securely recording security events through auditing proves that our security mechanisms are working as intended.

Auditing is a function where security teams must collaborate with software engineers early and often to ensure the right kind of audit logs are being captured and recorded.

Info-Tech Insight

Defects in your application software can compromise privacy and integrity even if cryptographic controls are in place. A security architecture made after thorough TRA does not override security risk introduced due to irresponsible software design.

Examples of threat and risk assessments using STRIDE and attack trees

STRIDE is a threat modeling framework and is composed of:

• Spoofing or impersonation of someone other than oneself
• Tampering with data and destroying its integrity
• Repudiation by bypassing system identity controls
• Information disclosure to unauthorized persons
• Denial of service that prevents system or parts of it from being used
• Elevation of privilege so that attackers get rights they should not have

Example of using STRIDE for a TRA on a solution using a payment system
Spoofing	PayPal	Bad actor can send fraudulent payment request for obtaining funds.
Tampering	PayPal	Bad actor accesses data base and can resend fraudulent payment request for obtaining funds.
Repudiation	PayPal	Customer claims, incorrectly, their account made a payment they did not authorize.
Disclosure	PayPal	Private service database has details leaked and made public.
Denial of Service	PayPal	Service is made to slow down through creating a load on the network, causing massive build up of requests
Elevation of Privilege	PayPal	Bad actor attempts to enter someone else’s account by entering incorrect password a number of times.

2.2 Document security architecture risks and mitigations

1. Using STRIDE, attack tree, or any other framework of choice:

• Conduct a TRA for use cases identified in Phase 1.2

Download the Solution Architecture Template for documenting data architecture decisions.

Input

• Dynamic Value Stream Maps

Output

• Security Architecture Risks and Mitigations

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Product Owner
• Security Team
• Application Architect
• Integration Architect

Examples of threat and risk assessments using STRIDE

Phase 3: Upgrade Your System’s Availability

Phase 1

1.1 Articulate an Architectural Vision
1.2 Develop Dynamic Value Stream Maps
1.3 Map Value Streams, Use Cases, and Required Architectural Attributes
1.4 Create a Prioritized List of Architectural Attributes

Phase 2

2.1 Develop a Data Architecture That Supports Transactional and Analytical Needs
2.2 Document Security Architecture Risks and Mitigations

Phase 3

3.1 Document Scalability Architecture
3.2 Document Performance Enhancing Architecture
3.3 Combine the Different Architecture Design Decisions Into a Unified Solution Architecture

This phase will walk you through the following activities:

• Examine architecture for scalable and performant system designs
• Integrate all design decisions made so far into a solution design decision log

This phase involves the following participants:

• Business Architect
• Product Owner
• Application Architect
• Integration Architect
• Database Architect
• Enterprise Architect

Enhance Your Solution Architecture Practice

In a cloud-inspired system architecture, scalability takes center stage as an architectural concern

Scale and scope of workloads are more important now than they were, perhaps, a decade and half back. Architects realize that scalability is not an afterthought. Not dealing with it at the outset can have serious consequences should an application workload suddenly exceed expectations.

Scalability is …

… the ability of a system to handle varying workloads by either increasing or decreasing the computing resources of the system.

An increased workload could include:

• Higher transaction volumes
• A greater number of users

Architecting for scalability is …

… not easy since organizations may not be able to accurately judge, outside of known circumstances, when and why workloads may unexpectedly increase.

A scalable architecture should be planned at the:

• Application Level
• Infrastructure Level
• Database Level

The right amount and kind of scalability is …

… balancing the demands of the system with the supply of attributes.

If demand from system > supply from system:

• Services and products are not useable and deny value to customers.

If supply from system > demand from system:

• Excess resources have been paid for that are not being used.

When discussing the scalability needs of a system, investigate the following, at a minimum:

• In case workloads increase due to higher transaction volumes, will the system be able to cope with the additional stress?
• In situations where workloads increase, will the system be able to support the additional stress without any major modifications being made to the system?
• Is the cost associated with handling the increased workloads reasonable for the benefit it provides to the business?
• Assuming the system doesn’t scale, is there any mechanism for graceful degradation?

Use evidence-based decision making to ensure a cost-effective yet appropriate scaling strategy

The best input for an effective scaling strategy is previously gathered traffic data mapped to specific circumstances.

In some cases, either due to lack of monitoring or the business not being sure of its needs, scalability requirements are hard to determine. In such cases, use stated tactical business objectives to design for scalability. For example, the business might state its desire to achieve a target revenue goal. To accommodate this, a certain number of transactions would need to be conducted, assuming a particular conversion rate.

Info-Tech Insight

• Scalability is the one attribute that sparks a lot of trade-off discussions. Scalable solutions may have to compromise on performance, cost, and data reliability.
• Horizontal scalability is mostly always preferable over vertical scalability.

Sidebar

The many flavors of horizontal scaling

Traffic Shard-ing

Through this mechanism, incoming traffic is partitioned around a characteristic of the workload flowing in. Examples of partitioning characteristics are user groups, geo-location, and transaction type.

Beware of:

• Lack of data currency across shards.

Copy and Paste

As the name suggests, clone the compute resources along with the underlying databases. The systems will use a load balancer as the first point of contact between itself and the workload flowing in.

Beware of:

• Though this is a highly scalable model, it does introduce risks related to data currency across all databases.
• In case master database writes are frequent, it could become a bottleneck for the entire system.

Productization Through Containers

This involves breaking up the system into specific functions and services and bundling their business rules/databases into deployable containers.

Beware of:

• Too many containers introduce the need to orchestrate the distributed architecture that results from a service-oriented approach.

Start a scalability overview with a look at the database(s)

To know where to go, you must know where you are. Before introducing architectural changes to database designs, use the right metrics to get an insight into the root cause of the problem(s).

In a nutshell, the purpose of scaling solutions is to have the technology stack do less work for the most requested services/features or be able to effectively distribute the additional workload across multiple resources.

For databases, to ensure this happens, consider these techniques:

• Reuse data through caching on the server and/or the client. This eliminates the need for looking up already accessed data. Examples of caching are:
• In-memory caching of data
• Caching database queries
• Implement good data retrieval techniques like indexes.
• Divide labor at the database level.
• Through setting up primary-secondary distribution of data. In such a setup, the primary node is involved in writing data to itself and passes on requests to secondary nodes for fulfillment.
• Through setting up database shards (either horizontally or vertically).
• In a horizontal shard, a data table is broken into smaller pieces with the same data model but unique data in it. The sum total of the shared databases contains all the data in the primary data table.
• In a vertical shard, a data table is broken into smaller pieces, but each piece may have a subset of the data columns. The data’s corresponding columns are put into the table where the column resides.

Info-Tech Insight

A non-scalable architecture has more than just technology-related ramifications. Hoping that load balancers or cloud services will manage scalability-related issues is bound to have economic impacts as well.

Sidebar

Caching Options

CSA PRINCIPLE 5 applies to any decision that supports system scalability.
“X-ilities Over Features”

Database Caching
Fetches and stores result of database queries in memory. Subsequent requests to the database for the same queries will investigate the cache before making a connection with the database.
Tools like Memcached or Redis are used for database caching.

Precompute Database Caching
Unlike database caching, this style of caching precomputes results of queries that are popular and frequently used. For example, a database trigger could execute several predetermined queries and have them ready for consumption. The precomputed results may be stored in a database cache.

Application Object Caching
Stores computed results in a cache for later retrieval. For data sources, which are not changing frequently and are part of a computation output, application caching will remove the need to connect with a database.

Proxy Caching
Caches retrieved web pages on a proxy server and makes them available for the next time the page is requested.

The intra- and inter-process communication of the systems middle tier can become a bottleneck

To synchronize or not to synchronize?

A synchronous request (doing one thing at a time) means that code execution will wait for the request to be responded to before continuing.

• A synchronous request is a blocking event and until it is completed, all following requests will have to wait for getting their responses.
• An increasing workload on a synchronous system may impact performance.
• Synchronous interactions are less costly in terms of design, implementation, and maintenance.
• Scaling options include:

1. Vertical scale up
2. Horizontal scale out of application servers behind a load balancer and a caching technique (to minimize data retrieval roundtrips)
3. Horizonal scale out of database servers with data partitioning and/or data caching technique

Use synchronous requests when…

• Each request to a system sets the necessary precondition for a following request.
• Data reliability is important, especially in real-time systems.
• System flows are simple.
• Tasks that are typically time consuming, such as I/O, data access, pre-loading of assets, are completed quickly.

Asynchronous requests (doing many things at the same time) do not block the system they are targeting.

• It is a “fire and forget” mechanism.
• Execution on a server/processor is triggered by the request, however, additional technical components (callbacks) for checking the state of the execution must be designed and implemented.
• Asynchronous interactions require additional time to be spent on implementation and testing.
• With asynchronous interactions, there is no guarantee the request initiated any processing until the callbacks check the status of the executed thread.

Use asynchronous requests when…

• Tasks are independent in nature and don’t require inter-task communication.
• Systems flows need to be efficient.
• The system is using event-driven techniques for processing.
• Many I/O tasks are involved.
• The tasks are long running.

Sidebar

Other architectural tactics for inter-process communication

A team that does not measure their system’s scalability is a team bound to get a 5xx HTTP response code

A critical aspect of any system is its ability to monitor and report on its operational outcomes.

• Using the principle of continuous testing, every time an architectural change is introduced, a thorough load and stress testing cycle should be executed.
• Effective logging and use of insightful metrics helps system design teams make data-driven decisions.
• Using principle of site reliability engineering and predictive analytics, teams can be prepared for any unplanned exaggerated stimulus on the system and proactively set up remedial steps.

Any system, however well architected, will break one day. Strategically place kill-switches to counter any failures and thoroughly test their functioning before releasing to production.

• Using Principles 2 and 9 of the CSA, (include kill-switches and architect for x-ilities over features), introduce tactics at the code and higher levels that can be used to put a system in its previous best state in case of failure.
• Examples of such tactics are:
• Feature flags for turning on/off code modules that impact x-ilities.
• Implement design patterns like throttling, autoscaling, and circuit breaking.
• Writing extensive log messages that bubble up as exceptions/error handling from the code base. *Logging can be a performance drag. Use with caution as even logging code is still code that needs CPU and data storage.

Performance is a system’s ability to satisfy time-bound expectations

Performance can also be defined as the ability for a system to achieve its timing requirements, using available resources, under expected full-peak load:

(International Organization for Standardization, 2011)

• Performance and scalability are two peas in a pod. They are related to each other but are distinct attributes. Where scalability refers to the ability of a system to initiate multiple simultaneous processes, performance is the system’s ability to complete the processes within a mandated average time period.
• Degrading performance is one of the first red flags about a system’s ability to scale up to workload demands.
• Mitigation tactics for performance are very similar to the tactics for scalability.

System performance needs to be monitored and measured consistently.

Measurement Category 1: System performance in terms of end-user experience during different load scenarios.

• Response time/latency: Length of time it takes for an interaction with the system to complete.
• Turnaround time: Time taken to complete a batch of tasks.
• Throughput: Amount of workload a system is capable of handling in a unit time period.

Measurement Category 2: System performance in terms of load managed by computational resources.

• Resource utilization: The average usage of a resource (like CPU) over a period. Peaks and troughs indicate excess vs. normal load times.
• Number of concurrent connections: Simultaneous user requests that a resource like a server can successfully deal with at once.
• Queue time: The turnaround time for a specific interaction or category of interactions to complete.

Architectural tactics for performance management are the same as those used for system scalability

Application Layer

• Using a balanced approach that combines CSA Principle 7 (Good architecture comes in small packages) and Principle 10 (Architect for products, not projects), a microservices architecture based on domain-driven design helps process performance. Microservices use lightweight HTTP protocols and have loose coupling, adding a degree of resilience to the system as well. *An overly-engineered microservices architecture can become an orchestration challenge.
• The code design must follow standards that support performance. Example of standards is SOLID*.
• Serverless architectures can run application code from anywhere – for example, from edge servers close to an end user – thereby reducing latency.

Database Layer

• Using the right database technologies for persistence. Relational databases have implicit performance bottlenecks (which get exaggerated as data size grows along with indexes), and document store database technologies (key-value or wide-column) can improve performance in high-read environments.
• Data sources, especially those that are frequently accessed, should ideally be located close to the application servers. Hybrid infrastructures (cloud and on premises mixed) can lead to latency when a cloud-application is accessing on-premises data.
• Using a data partitioning strategy, especially in a domain-driven design architecture, can improve the performance of a system.

Performance modeling and continuous testing makes the SRE a happy engineer

Performance modeling and testing helps architecture teams predict performance risks as the solution is being developed.
(CSA Principle 12: Test the solution architecture like you test your solution’s features)

Create a model for your system’s hypothetical performance testing by breaking an end-to-end process or use case into its components. *Use the SIPOC framework for decomposition.

In the hypothetical example of modeled performance above:

• The longest period of latency is 15ms.
• The processing of data takes 30ms, while the baseline was established at 25ms.
• Average latency in sending back user responses is 21ms – 13ms slower than expected.

The model helps architects:

• Get evidence for their assumptions
• Quantitatively isolate bottlenecks at a granular level

Model the performance flow once but test it periodically

Performance testing measures the performance of a software system under normal and abnormal loads.

Performance testing process should be fully integrated with software development activities and as automated as possible. In a fast-moving Agile environment, teams should attempt to:

• Shift-left performance testing activities.
• Use performance testing to pinpoint performance bottlenecks.
• Take corrective action, as quickly as possible.

Performance testing techniques

• Normal load testing: Verifies the system’s behavior under the expected normal load to ensure that its performance requirements are met. Load testing can be used to measure response time, responsiveness, turnaround time, and throughput.
• Expected maximum load testing: Like the normal load testing process, ensures system meets its performance requirements under expected maximum load.
• Stress testing: Evaluates system behavior when processing loads beyond the expected maximum.

*In a real production scenario, a combination of these tests are executed on a regular basis to monitor the performance of the system over a given period.

3.1-3.2 Discuss and document initial decisions made for architecture scalability and performance

1. Use the outcomes from either or both Phases 1.3 and 1.4.

• For each value stream component, list the architecture decisions taken to ensure scalability and performance at client-facing and/or business-rule layers.

Download the Solution Architecture Template for documenting data architecture decisions.

Input

• Output From Phase 1.3 and/or From Phase 1.4

Output

• Initial Set of Design Decisions Made for System Scalability and Performance

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Application Architect
• Integration Architect
• Database Architect
• Infrastructure Architect

Example: Architecture decisions for scalability and performance

3.3 Combine the different architecture design decisions into a unified solution architecture

Download the Solution Architecture Template for documenting data architecture decisions.

Input

• Output From Phase 1.3 and/or From Phase 1.4
• Output From Phase 2.1
• Output From Phase 2.2
• Output From 3.1 and 3.2

Output

• List of Design Decisions for the Solution

Materials

• Whiteboard/Flip Charts

Participants

• Business Architect
• Application Architect
• Integration Architect
• Database Architect
• Infrastructure Architect

Putting it all together is the bow that finally ties this gift

This blueprint covered the domains tagged with the yellow star.

TRADEOFF ALERT

The right design decision is never the same for all perspectives. Along with varying opinions, comes the “at odds with each other set” of needs (scalability vs. performance, or access vs. security).

An evidence-based decision-making approach using a domain-driven design strategy is a good mix of techniques for creating the best (right?) solution architecture.

Summary of accomplishment

• Gained understanding and clarification of the stakeholder objectives placed on your application architecture.
• Completed detailed use cases and persona-driven scenario analysis and their architectural needs through SRME.
• Created a set of design decisions for data, security, scalability, and performance.
• Merged the different architecture domains dealt with in this blueprint to create a holistic view.

Bibliography

Ambysoft Inc. “UML 2 Sequence Diagrams: An Agile Introduction.” Agile Modeling, n.d. Web.

Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practices: Third Edition. Pearson Education, Inc. 2003.

Eeles, Peter. “The benefits of software architecting.” IBM: developerWorks, 15 May 2006. Web.

Flexera 2020 State of the Cloud Report. Flexera, 2020. Web. 19 October 2021.

Furdik, Karol, Gabriel Lukac, Tomas Sabol, and Peter Kostelnik. “The Network Architecture Designed for an Adaptable IoT-based Smart Office Solution.” International Journal of Computer Networks and Communications Security, November 2013. Web.

Ganzinger, Matthias, and Petra Knaup. “Requirements for data integration platforms in biomedical research networks: a reference model.” PeerJ, 5 February 2015. (https://peerj.com/articles/755/).

Garlan, David, and Mary Shaw. An Introduction to Software Architecture. CMU-CS-94-166, School of Computer Science Carnegie Mellon University, January 1994.

Gupta, Arun. “Microservice Design Patterns.” Java Code Geeks, 14 April 2015. Web.

How, Matt. The Modern Data Warehouse in Azure. O’Reilly, 2020.

ISO/IEC 17788:2014: Information technology – Cloud computing, International Organization for Standardization, October 2014. Web.

ISO/IEC 18384-1:2016: Information technology – Reference Architecture for Service Oriented Architecture (SOA RA), International Organization for Standardization, June 2016. Web.

ISO/IEC 25010:2011(en) Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. International Organization for Standardization, March 2011. Web.

Kazman, R., M. Klein, and P. Clements. ATAM: Method for Architecture Evaluation. S Carnegie Mellon University, August 2000. Web.

Microsoft Developer Network. “Chapter 16: Quality Attributes.” Microsoft Application Architecture Guide. 2nd Ed., 13 January 2010. Web.

Microsoft Developer Network. “Chapter 2: Key Principles of Software Architecture.” Microsoft Application Architecture Guide. 2nd Ed., 13 January 2010. Web.

Microsoft Developer Network. “Chapter 3: Architectural Patterns and Styles.” Microsoft Application Architecture Guide. 2nd Ed., 14 January 2010. Web.

Microsoft Developer Network. “Chapter 5: Layered Application Guidelines.” Microsoft Application Architecture Guide. 2nd Ed., 13 January 2010. Web.

Mirakhorli, Mehdi. “Common Architecture Weakness Enumeration (CAWE).” IEEE Software, 2016. Web.

Moore, G. A. Crossing the Chasm, 3rd Edition: Marketing and Selling Disruptive Products to Mainstream Customers (Collins Business Essentials) (3rd ed.). Harper Business, 2014.

OASIS. “Oasis SOA Reference Model (SOA RM) TC.” OASIS Open, n.d. Web.

Soni, Mukesh. “Defect Prevention: Reducing Costs and Enhancing Quality.” iSixSigma, n.d. Web.

The Open Group. TOGAF 8.1.1 Online, Part IV: Resource Base, Developing Architecture Views. TOGAF, 2006. Web.

The Open Group. Welcome to the TOGAF® Standard, Version 9.2, a standard of The Open Group. TOGAF, 2018. Web.

Watts, S. “The importance of solid design principles.” BMC Blogs, 15 June 2020. 19 October 2021.

Young, Charles. “Hexagonal Architecture–The Great Reconciler?” Geeks with Blogs, 20 Dec 2014. Web.

APPENDIX A

Techniques to enhance application architecture.

Consider the numerous solutions to address architecture issues or how they will impact your application architecture

Many solutions exist for improving the layers of the application stack that may address architecture issues or impact your current architecture. Solutions range from capability changes to full stack replacement.

Build Your Data Practice and Platform

Construct a scalable data foundation

Analyst Perspective

Build a data practice and platform that delivers value to your organization.

The build or optimization of your data practice and data platform must be predicated on a thorough understanding of the organization’s goals, objectives, and priorities and the business capabilities and process they are meant to support and enable.

Formalizing your practice or constructing your platform just for the sake of doing so often results in an initiative that is lengthy, costly, fizzles out, does not deliver business value, and ends up being considered a failure.

Leverage Info-Tech’s approach and incorporate our pre-built models and patterns to effectively navigate that crucial and often difficult phase upfront of comprehensively defining business data needs so you can ultimately realize faster time-to-delivery of your overall data practice and platform.

	Rajesh Parab Director, Research & Advisory, Data & Analytics Practice Info-Tech Research Group
	Crystal Singh Director, Research & Advisory, Data & Analytics Practice Info-Tech Research Group

Attempting to Solve Data Problems?

Info-Tech Insight

The true value of data comes from defining intentional relationships between the business and the data through a well thought out data platform and practice.

Situation – Perpetual Data Problem

I can’t access the data. I don’t trust the data in the report. It takes too long to get to the data for decision making

Lack of data-centric leadership results in downstream issues: integration, quality, accessibility The organization’s data is too complex to manage without a cohesive plan. The complex nature of the data and a lack of understanding leads to de-scoping delivery of data services that does not meet business needs or add value. Poorly designed practice and siloed platforms result in an initiative that is lengthy, costly, fizzles out, does not deliver business value, and ends up being considered a failure.

Complication – Data Initiative Fizzles Out

Data problem: When the data problem is diagnosed the organization adopts a tactical approach. Confirmation bias: Subject matter experts (SME) are hired to resolve the poorly defined problem, but the success of the SME is impacted by lack of architecture, technology, and organizational alignment. Still no value: the selected tactical approach does not provide a solid foundation or solve your data problem. Strategy for sake of strategy: Implementing a strategic approach for sake of being strategic but this becomes overwhelming. Fall back to tactical and operational: The data services are now potentially exposed and vulnerable, which strains business continuity and increases data debt. Increased complexity and risk: Data silos, poor understanding, and high complexity result in an unmanageable data environment.

Use the road-tested patterns and frameworks in our blueprint to break the perpetual data solution cycle. Focus on the value that a data and analytics platform will bring rather than focusing on the data problems alone.

Phase-by-Phase Approach to Build Your Data Practice and Platform

Phase-by-Phase Approach Phase 1: Step 1 – Define Your Data Requirement Phase 1: Step 2 – Conduct Your Data Discovery Phase 2 – Design Your Data Practice Phase 3 – Architect Your Data Platform

Measure value when building your data practice and platform

Sample Data Management Metrics

• Refine the metrics for the overall Data Management practice and every initiative therein.
• Refine the metrics at each platform and practice component to show business value against implementation effort.

Understand and Build Data Culture

See your Info-Tech Account Representative for more details on our Data Culture Diagnostic

Only 14.29% of Transportation and Logistics respondents agree BI and Analytics Process and Technology are sufficient	What is a diagnostic? Our diagnostics are the simplest way to collect the data you need, turn it into actionable insights, and communicate with stakeholders across the organization.			52.54% of respondents from the healthcare industry are unaware of their organization’s data security policy
	Ask the Right Questions Use our low-effort surveys to get the data you need from stakeholders across the organization.	Use Our Diagnostic Engine Our diagnostic engine does all the heavy lifting and analysis, turning your data into usable information.	Communicate & Take Action Wow your executives with the incredible insights you've uncovered. Then, get to action: make IT better.
On average only 40% agree that they have the reporting when needed (Source: Info-Tech’s Data Culture Diagnostic, 53 Organizations, 3138 Responses)	35% of respondents feel that a governance body is in place looking at strategic data Build a Data-Driven Strategy Using Info-Tech Diagnostic Programs Make informed IT decisions by starting your diagnostic program today. Your account manager is waiting to help you.

Use Our Predefined Data and Analytics Patterns to Build Your DnA Landscape

Walking through a book of architecture building plans with a personal guide is cheaper and faster than employing an architect to build and design your home

Insights

The true value of data comes from defining intentional relationships between the business and the data through a well-thought-out data platform and practice.

• Phase 1
  • Some organizations are low maturity so using the traditional Capability Maturity Model Integration (CMMI) would not make sense. A great alternative is to leverage existing models and methodologies to get going off the bat.
  • The Data Strategy is an input into the platform and practice. This is considered the Why; Data Practice and Platform is the How.
• Phase 2
  • Info-Tech’s approach is business-goal driven and it leverages patterns, which enable the implementation of critical and foundational components and subsequently facilitates the evolution and development of the practice over time.
  • Systems should not be designed in isolation. Cross-functional collaboration throughout the design is critical to ensure all types of issues are revealed early. Otherwise, crucial tests are omitted, deployments fail, and end-users are dissatisfied.
• Phase 3
  • Build your conceptual data architecture based on well-thought-out formulated patterns that align with your organization’s needs and environment.
  • Functional needs often take precedence over quality architecture. Quality must be baked into design, execution, and decision-making practices to ensure the right trade-offs are made.

Info-Tech offers various levels of support to best suit your needs

Info-Tech’s Methodology for Building Your Data Practice and Platform

Data Platform and Practice Implementation Plan

Build Your Data Practice and Platform

Phase 1

Phase 1: Step 1 – Define Your Data Requirements
Phase 1: Step 2 – Conduct Your Data Discovery

Phase 1: Step 1 – Define Your Data Requirements will walk you through the following activities:

• Confirm the organizational strategic goals, business drivers, business capabilities, and processes driving the Data Practice and Platform effort.
• Identify the data related outcomes, goals, and ideal environment needed to fulfill the business goals.

This phase involves the following participants:

A blend of business leaders and business SMEs together with the Data Strategy team.

Phase 1: Step 2 – Conduct Your Data Discovery will walk you through the following activities:

• Identify and highlight the data challenges faced in achieving the desired outcome.
• Map the data challenges to the data capabilities required to realize the desired data outcome.

This phase involves the following participants:

Key personnel from IT/Data team: (Data Architect, Data Engineers, Head of Head of Reporting and Analytics)

Implement a New IT Organizational Structure

Prioritize quick wins and critical services during IT org changes.

This blueprint is part 3/3 in Info-Tech’s organizational design program and focuses on implementing a new structure

Monitor and Sustain Stakeholder Engagement →

The sections highlighted in green are in scope for this blueprint. Click here for more information on designing or on structuring a new organization.

Our understanding of the problem

This Research is Designed For:

• CIOs

This Research Will Help You:

• Effectively implement a new organizational structure.
• Develop effective communications to minimize turnover and lost productivity during transition.
• Identify a detailed transition strategy to move to your new structure with minimal interruptions to service quality.
• Train managers to lead through change and measure ongoing employee engagement.

This Research Will Also Assist:

• IT Leaders

This Research Will Help Them:

• Effectively lead through the organizational change.
• Manage difficult conversations with staff and mitigate staff concerns and turnover.
• Build clear transition plans for their teams.

Executive summary

Situation

• Organizational Design (OD) projects are typically undertaken in order to enable organizational priorities, improve IT performance, or to reduce IT costs. However, due to the highly disruptive nature of the change, only 25% of changes achieve their objectives over the long term. (2013 Towers Watson Change and Communication ROI Survey)

Complication

• OD implementations can be highly disruptive for IT staff and business partners. Without a structured approach, IT leaders may experience high turnover, decreased productivity, and resistance to the change.
• CIOs walk a tightrope as they manage the operational and emotional turbulence while aiming to improve business satisfaction within IT. Failure to achieve balance could result in irreparable failure.

Resolution

• Leverage Info-Tech’s organizational design implementation process and deliverables to build and implement a detailed transition strategy and to prepare managers to lead through change. Follow Info-Tech’s 5-step process to:
  1. Effect change and sustain productivity through real-time employee engagement monitoring.
  2. Kick off the organizational design implementation with effective communication.
  3. Build an integrated departmental transition strategy.
  4. Train managers to effectively lead through change.
  5. Develop personalized transition plans.

Info-Tech Insight

1. Mismanagement will hurt you. The majority of IT organizations do not manage OD implementations effectively, resulting in decreased satisfaction, productivity loss, and increased IT costs.
2. Preventing mismanagement is within your control. 72% of change management issues can be directly improved by managers. (Abilla, 2009) IT leaders have a tendency to focus their efforts on operational changes rather than on people. This is a recipe for failure.

Organizational Design Implementation

Managing organizational design (OD) changes effectively is critical to maintaining IT service levels and retaining top talent throughout a restructure. Nevertheless, many organizations fail to invest appropriate consideration and resources into effective OD change planning and execution.

THREE REASONS WHY CIOS NEED TO EFFECTIVELY MANAGE CHANGE:

1. Failure is the norm; not the exception. According to a study by Towers Watson, only 55% of organizations experience the initial value of a change. Even fewer organizations, a mere 25%, are actually able to sustain change over time to experience the full expected benefits. (2013 Towers Watson Change and Communication ROI Survey)
2. People are the biggest cause of failure. Organizational design changes are one of the most difficult types of changes to manage as staff are often highly resistant. This leads to decreased productivity and poor results. The most significant people challenge is the loss of momentum through the change process which needs to be actively managed.
3. Failure costs money. Poor IT OD implementations can result in increased turnover, lost productivity, and decreased satisfaction from the business. Managing the implementation has a clear ROI as the cost of voluntary turnover is estimated to be 150% of an employee’s annual salary. (Inc)

86% of IT leaders believe organization and leadership processes are critical, yet the majority struggle to be effective

PERCENTAGE OF IT LEADERS WHO BELIEVE THEIR ORGANIZATION AND LEADERSHIP PROCESSES ARE HIGHLY IMPORTANT AND HIGHLY EFFECTIVE

GAP BETWEEN IMPORTANCE AND EFFECTIVENESS

Human Resources Management - 61%

Leadership, Culture, Values - 48%

Organizational Change Management - 55%

Organizational Design - 45%

Note: Importance and effectiveness were determined by identifying the percentage of individuals who responded with 8-10/10 to the questions…

• “How important is this process to the organization’s ability to achieve business and IT goals?” and…
• “How effective is this process at helping the organization to achieve business and IT goals?”

Source: Info-Tech Research Group, Management and Governance Diagnostic. N=22,800 IT Professionals

Follow a structured approach to your OD implementation to improve stakeholder satisfaction with IT and minimize risk

• IT reorganizations are typically undertaken to enable strategic goals, improve efficiency and performance, or because of significant changes to the IT budget. Without a structured approach to manage the organizational change, IT might get the implementation done, but fail to achieve the intended benefits, i.e. the operation succeeds, but the patient has died on the table.
• When implementing your new organizational design, it’s critical to follow a structured approach to ensure that you can maintain IT service levels and performance and achieve the intended benefits.
• The impact of organizational structure changes can be emotional and stressful for staff. As such, in order to limit voluntary turnover, and to maintain productivity and performance, IT leaders need to be strategic about how they communicate and respond to resistance to change.

TOP 3 BENEFITS OF FOLLOWING A STRUCTURED APPROACH TO IMPLEMENTING ORGANIZATIONAL DESIGN

1. Improved stakeholder satisfaction with IT. A detailed change strategy will allow you to successfully transition staff into new roles with limited service interruptions and with improved stakeholder satisfaction.
2. Experience minimal voluntary turnover throughout the change. Know how to actively engage and minimize resistance of stakeholders throughout the change.
3. Execute implementation on time and on budget. Effectively managed implementations are 65–80% more likely to meet initial objectives than those with poor organizational change management. (Boxley Group, LLC)

Optimize your organizational design implementation results by actively preparing managers to lead through change

IT leaders have a tendency to make change even more difficult by focusing on operations rather than on people. This is a recipe for failure. People pose the greatest risk to effective implementation and as such, IT managers need to be prepared and trained on how to lead their staff through the change. This includes knowing how to identify and manage resistance, communicating the change, and maintaining positive momentum with staff.

Staff resistance and momentum are the most challenging part of leading through change (McLean & Company, N=196)

Reasons why change fails: 72% of failures can be directly improved by the manager (shmula)

Leverage organizational change management (OCM) best practices for increased OD implementation success

Effective change management correlates with project success

Source: Prosci. From Prosci’s 2012 Best Practices in Change Management benchmarking report.

95% of projects with excellent change management met or EXCEEDED OBJECTIVES, vs. 15% of those with poor OCM. (Prosci)

143% ROI on projects with excellent OCM. In other words, for every dollar spent on the project, the company GAINS 43 CENTS. This is in contrast to 35% ROI on projects with poor OCM. (McKinsey)

Info-Tech’s approach to OD implementation is a practical and tactical adaptation of several successful OCM models

BUSINESS STRATEGY-ORIENTED OCM MODELS. John Kotter’s 8-Step model, for instance, provides a strong framework for transformational change but doesn’t specifically take into account the unique needs of an IT transformation.

GENERAL-PURPOSE OCM FRAMEWORKS such as ACMP’s Standard for Change Management, CMI’s CMBoK, and Prosci’s ADKAR model are very comprehensive and need to be configured to organizational design implementation-specific initiatives.

COBIT MANAGEMENT PRACTICE BAI05: MANAGE ORGANIZATIONAL CHANGE ENABLEMENT follows a structured process for implementing enterprise change quickly. This framework can be adapted to OD implementation; however, it is most effective when augmented with the people and management training elements present in other frameworks.

References and Further Reading

• ADKAR (Prosci)
• CMBoK (CMI)
• COBIT 5
• Kotter’s 8 Principles
• Managing Transitions
• Kubler-Ross Curve
• The Classic Change Curve Standard for Change Management (ACMP)

Tailoring a comprehensive, general-purpose OCM framework to an OD implementation requires familiarity and experience. Info-Tech’s OD implementation model adapts the best practices from a wide range of proven OCM models and distills it into a step-by-step process that can be applied to an organizational design transformation.

The following OD implementation symptoms can be avoided through structured planning

IN PREVIOUS ORGANIZATIONAL CHANGES, I’VE EXPERIENCED…

“Difficultly motivating my staff to change.”

“Higher than average voluntary turnover during and following the implementation.”

“An overall sense of staff frustration or decreased employee engagement.”

“Decreased staff productivity and an inability to meet SLAs.”

“Increased overtime caused by being asked to do two jobs at once.”

“Confusion about the reporting structure during the change.”

“Difficulty keeping up with the rate of change and change fatigue from staff.”

“Business partner dissatisfaction about the change and complaints about the lack of effort or care put in by IT employees.”

“Business partners not wanting to adjust to the change and continuing to follow outdated processes.”

“Decrease in stakeholder satisfaction with IT.”

“Increased prevalence of shadow IT during or following the change.”

“Staff members vocally complaining about the IT organization and leadership team.”

Follow this blueprint to develop and execute on your OD implementation

IT leaders often lack the experience and time to effectively execute on organizational changes. Info-Tech’s organizational design implementation program will provide you with the needed tools, templates, and deliverables. Use these insights to drive action plans and initiatives for improvement.

How we can help

• Measure the ongoing engagement of your employees using Info-Tech’s MLI diagnostic. The diagnostic comes complete with easily customizable reports to track and act on employee engagement throughout the life of the change.
• Use Info-Tech’s customizable project management tools to identify all of the critical changes, their impact on stakeholders, and mitigate potential implementation risks.
• Develop an in-depth action plan and transition plans for individual stakeholders to ensure that productivity remains high and that service levels and project expectations are met.
• Align communication with real-time staff engagement data to keep stakeholders motivated and focused throughout the change.
• Use Info-Tech’s detailed facilitation guide to train managers on how to effectively communicate the change, manage difficult stakeholders, and help ensure a smooth transition.

Leverage Info-Tech’s customizable deliverables to execute your organizational design implementation

CUSTOMIZABLE PROJECT DELIVERABLES

1. BUILD A CHANGE COMMUNICATION STRATEGY

• McLean Leadership Index: Real-Time Employee Engagement Dashboard
• Organizational Design
• Implementation Kick-Off Presentation
• Organizational Design Implementation FAQ

2. BUILD THE ORGANIZATIONAL TRANSITION PLAN

• Organizational Design Implementation Project Planning Tool

3.1 TRAIN MANAGERS TO LEAD THROUGH CHANGE

3.2 TRANSITION STAFF TO NEW ROLES

• Organizational Design Implementation Manager Training Guide
• Organizational Design Implementation Transition Plan Template

Leverage Info-Tech’s tools and templates to overcome key engagement program implementation challenges

KEY SECTION INSIGHTS:

BUILD A CHANGE COMMUNICATION STRATEGY

Effective organizational design implementations mitigate the risk of turnover and lost productivity through ongoing monitoring and managing of employee engagement levels. Take a data-driven approach to managing engagement with Info-Tech’s real-time MLI engagement dashboard and adjust your communication and implementation strategy before engagement risks become issues.

BUILD THE ORGANIZATIONAL TRANSITION PLAN

Your organizational design implementation is made up of a series of projects and needs to be integrated into your larger project schedule. Too often, organizations attempt to fit the organizational design implementation into their existing schedules which results in poor resource planning, long delays in implementation, and overall poor results.

LEAD STAFF THROUGH THE REORGANIZATION

The majority of IT managers were promoted because they excelled at the technical aspect of their job rather than in people management. Not providing training is setting your organization up for failure. Train managers to effectively lead through change to see a 72% decrease in change management issues. (Abilla, 2009)

METRICS:

1. Voluntary turnover: Conduct an exit interview with all staff members during and after transition. Identify any staff members who cite the change as a reason for departure. For those who do leave, multiply their salary by 1.5% (the cost of a new hire) and track this over time.
2. Business satisfaction trends: Conduct CIO Business Vision one year prior to the change vs. one year after change kick-off. Prior to the reorganization, set metrics for each category for six months after the reorganization, and one year following.
3. Saved development costs: Number of hours to develop internal methodology, tools, templates, and process multiplied by the salary of the individual.

Use this blueprint to save 1–3 months in implementing your new organizational structure

These estimates are based on reviews with Info-Tech clients and our experience creating the blueprint.

Totals:

Workshop: 1 week

GI/DIY: 2-6 weeks

Time and Effort Saved: 8-17 weeks

CIO uses holistic organizational change management strategies to overcome previous reorganization failures

CASE STUDY

Industry: Manufacturing

Source: Client interview

Problem

When the CIO of a large manufacturing company decided to undertake a major reorganization project, he was confronted with the stigma of a previous CIO’s attempt. Senior management at the company were wary of the reorganization since the previous attempt had failed and cost a lot of money. There was major turnover since staff were not happy with their new roles costing $250,000 for new hires. The IT department saw a decline in their satisfaction scores and a 10% increase in help desk tickets. The reorganization also cost the department $400,000 in project rework.

Solution

The new CIO used organizational change management strategies in order to thoroughly plan the implementation of the new organizational structure. The changes were communicated to staff in order to improve adoption, every element of the change was mapped out, and the managers were trained to lead their staff through the change.

Results

The reorganization was successful and eagerly adopted by the staff. There was no turnover after the new organizational structure was implemented and the engagement levels of the staff remained the same.

$250,000 - Cost of new hires and salary changes

10% - Increase in help desk tickets

$400,000 - Cost of project delays due to the poorly effective implementation of changes

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Implement a New Organizational Structure

Workshop overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Phase 1

Build a Change Communication Strategy

Build a change communication strategy

Outcomes of this Section:

• Launch the McLean Leadership Index
• Define your change team
• Build your reorganization kick-off presentation and FAQ for staff and business stakeholders

This section involves the following participants:

• CIO
• IT leadership team
• IT staff

Key Section Insight:

Effective organizational design implementations mitigate the risk of turnover and lost productivity through ongoing monitoring of employee engagement levels. Take a data-driven approach to managing engagement with Info-Tech’s real-time MLI engagement dashboard and adjust your communication and implementation strategy in real-time before engagement risks become issues.

Phase 1 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 1: Build a Change Communication Strategy

Proposed Time to Completion (in weeks): 1-6 weeks

Step 1.1: Launch Your McLean Leadership Index Survey

Start with an analyst kick off call:

• Discuss the benefits and uses of the MLI.
• Go over the required information (demographics, permissions, etc.).
• Set up a live demo of the survey.

Then complete these activities…

• Launch the survey with your staff.
• Have a results call with a member of the Info-Tech staff.

With these tools & templates:

McLean Leadership Index

Step 1.2: Establish Your Implementation Team

Review findings with analyst:

• Review what members of your department should participate.
• Build a RACI to determine the roles of your team members.

Then complete these activities…

• Hold a kick-off meeting with your new implementation team.
• Build the RACI for your new team members and their roles.

Step 1.3: Build Your Change Communication Strategy

Finalize phase deliverable:

• Customize your reorganization kick-off presentation.
• Create your change vision. Review the communication strategy.

Then complete these activities…

• Hold your kick-off presentation with staff members.
• Launch the reorganization communications.

With these tools & templates:

• Organizational Design Implementation Kick-Off Presentation
• Organizational Design Implementation FAQ

Set the stage for the organizational design implementation by effectively introducing and communicating the change to staff

Persuading people to change requires a “soft,” empathetic approach to keep them motivated and engaged. But don’t mistake “soft” for easy. Managing the people and communication aspects around the change are amongst the toughest work there is, and require a comfort and competency with uncertainty, ambiguity, and conflict.

Communication and engagement are the chains linking your design to transition. If the organizational design initiative is going to be successful it is critical that you manage this effectively. The earlier you begin planning the better. The more open and honest you are about the change the easier it will be to maintain engagement levels, business satisfaction, and overall IT productivity.

Kick-Off Presentation Inputs

• LAUNCH THE MCLEAN LEADERSHIP INDEX
• IDENTIFY YOUR CHANGE TEAM
• DETERMINE CHANGE TEAM RESPONSIBILITIES
• DEVELOP THE CHANGE VISION
• DEFINE KEY MESSAGES AND GOALS
• IDENTIFY MAJOR CHANGES
• IDENTIFY KEY MILESTONES
• BUILD AND MAINTAIN A CHANGE FAQ

Use the MLI engagement dashboard to measure your current state and the impact of the change in real-time

The McLean Leadership Index diagnostic is a low-effort, high-impact program that provides real-time metrics on staff engagement levels. Use these insights to understand your employees’ engagement levels throughout the organizational design implementation to measure the impact of the change and to manage turnover and productivity levels throughout the implementation.

WHY CARE ABOUT ENGAGEMENT DURING THE CHANGE? ENGAGED EMPLOYEES REPORT:

39% Higher intention to stay at the organization.

29% Higher performance and increased likelihood to work harder and longer hours. (Source: McLean and Company N=1,308 IT Employees)

Why the McLean Leadership Index?

Based on the Net Promoter Score (NPS), the McLean Leadership Index is one question asked monthly to assess engagement at various points in time.

Individuals responding to the MLI question with a 9 or 10 are your Promoters and are most positive and passionate. Those who answer 7 or 8 are Passives while those who answer 0 to 6 are Detractors.

Track your engagement distribution using our online dashboard to view MLI data at any time and view results based on teams, locations, manager, tenure, age, and gender. Assess the reactions to events and changes in real-time, analyze trends over time, and course-correct.

Dashboard reports: Know your staff’s overall engagement and top priorities

McLean Leadership Index

OVERALL ENGAGEMENT RESULTS

You get:

• A clear breakdown of your detractors, passives, and promotors.
• To view results by team, location, and individual manager.
• To dig deeper into results by reviewing results by age, gender, and tenure at the organization to effectively identify areas where engagement is weak.

TIME SERIES TRENDS

You get:

• View of changes in engagement levels for each team, location, and manager.
• Breakdown of trends weekly, monthly, quarterly, and yearly.
• To encourage leaders to monitor results to analyze root causes for changes and generate improvement initiatives.

QUALITATIVE COMMENTS

You get:

• To view qualitative comments provided by staff on what is impacting their engagement.
• To reply directly to comments without impacting the anonymity of the individuals making the comments.
• To leverage trends in the comments to make changes to communication approaches.

Launch the McLean Leadership Index in under three weeks

Info-Tech’s dedicated team of program managers will facilitate this diagnostic program remotely, providing you with a convenient, low-effort, high-impact experience.

We will guide you through the process with your goals in mind to deliver deep insight into your successes and areas to improve.

What You Need To Do:

1. Contact Info-Tech to launch the program and test the functionality in a live demo.
2. Identify demographics and set access permissions.
3. Complete manager training with assistance from Info-Tech Advisors.
4. Participate in a results call with an Info-Tech Advisor to review results and develop an action plan.

Info-Tech’s Program Manager Will:

1. Collect necessary inputs and generate your custom dashboard.
2. Launch, maintain, and support the online system in the field.
3. Send out a survey to 25% of the staff each week.
4. Provide ongoing support over the phone, and the needed tools and templates to communicate and train staff as well as take action on results.

Explore your initial results in a one-hour call with an Executive Advisor to fully understand the results and draw insights from the data so you can start your action plan.

Start Your Diagnostic Now

We'll help you get set up as soon as you're ready.

Start Now

Communication has a direct impact on employee engagement; measure communication quality using your MLI results

(McLean & Company, 2015 N=17,921)

A clear relationship exists between how effective a manager’s communication is perceived to be and an employee’s level of engagement. If engagement drops, circle back with employees to understand the root causes.

Establish an effective implementation team to drive the organizational change

The implementation team is responsible for developing and disseminating information around the change, developing the transition strategy, and for the ongoing management of the changes.

The members of the implementation team should include:

• CIO
• Current IT leadership team
• Project manager
• Business relationship managers
• Human resources advisor

Don’t be naïve – building and executing the implementation plan will require a significant time commitment from team members. Too often, organizations attempt to “fit it in” to their existing schedules resulting in poor planning, long delays, and overall poor results. Schedule this work like you would a project.

TOP 3 TIPS FOR DEFINING YOUR IMPLEMENTATION TEAM

1. Select a Project Manager. Info-Tech strongly recommends having one individual accountable for key project management activities. They will be responsible for keeping the project on time and maintaining a holistic view of the implementation.
2. Communication with Business Partners is Critical. If you have Business Relationship Managers (BRMs), involve them in the communication planning or assign someone to play this role. You need your business partners to be informed and bought in to the implementation to maintain satisfaction.
3. Enlist Your “Volunteer Army.” (Kotter’s 8 Principles) If you have an open culture, Info-Tech encourages you to have an extended implementation team made up of volunteers interested in supporting the change. Their role will be to support the core group, assist in planning, and communicate progress with peers.

Determine the roles of your implementation team members

1.1 30 Minutes

Input

• Implementation team members

Output

• RACI for key transition elements

Materials

• RACI chart and pen

Participants

• Core implementation committee

1. Each member should be actively engaged in all elements of the organizational design implementation. However, it’s important to have one individual who is accountable for key activities and ensures they are done effectively and measured.
2. Review the chart below and as a group, brainstorm any additional key change components.
3. For each component listed below, identify who is Accountable, Responsible, Consulted, and Informed for each (suggested responsibility below).

Fast-track your communication planning with Info-Tech’s Organizational Design Implementation Kick-Off Presentation

Organizational Design Implementation Kick-Off Presentation

Communicate what’s important to your staff in a simple, digestible way. The communication message should reflect what is important to your stakeholders and what they want to know at the time.

• Why is this change happening?
• What are the goals of the reorganization?
• What specifically is changing?
• How will this impact me?
• When is this changing?
• How and where can I get more information?

It’s important that the tone of the meeting suits the circumstances.

• If the reorganization is going to involve lay-offs: The meeting should maintain a positive feel, but your key messages should stress the services that will be available to staff, when and how people will be communicated with about the change, and who staff can go to with concerns.
• If the reorganization is to enable growth: Focus on celebrating where the organization is going, previous successes, and stress that the staff are critical in enabling team success.

Modify the Organizational Design ImplementationKick-Off Presentation with your key messages and goals

1.2 1 hour

Input

• New organizational structure

Output

• Organizational design goal statements

Materials

• Whiteboard & marker
• ODI Kick-off Presentation

Participants

• OD implementation team

1. Within your change implementation team, hold a meeting to identify and document the change goals and key messages.
2. As a group, discuss what the key drivers were for the organizational redesign by asking yourselves what problem you were trying to solve.
3. Select 3–5 key problem statements and document them on a whiteboard.
4. For each problem statement, identify how the new organizational design will allow you to solve those problems.
5. Document these in your Organizational Design Implementation Kick-Off Presentation.

Modify the presentation with your unique change vision to serve as the center piece of your communication strategy

1.3 1 hour

Input

• Goal statements

Output

• Change vision statement

Materials

• Sticky notes
• Pens
• Voting dots

Participants

• Change team

1. Hold a meeting with the change implementation team to define your change vision. The change vision should provide a picture of what the organization will look like after the organizational design is implemented. It should represent the aspirational goal, and be something that staff can all rally behind.
2. Hand out sticky notes and ask each member to write down on one note what they believe is the #1 desired outcome from the organizational change and one thing that they are hoping to avoid (you may wish to use your goal statements to drive this).
3. As a group, review each of the sticky notes and group similar statements in categories. Provide each individual with 3 voting dots and ask them to select their three favorite statements.
4. Select your winning statements in teams of 2–3. Review each statement and as a team work to strengthen the language to ensure that the statement provides a call to action, that it is short and to the point, and motivational.
5. Present the statements back to the group and select the best option through a consensus vote.
6. Document the change vision in your Organizational Design Implementation Kick-Off Presentation.

Customize the presentation identifying key changes that will be occurring

1.4 2 hours

Input

• Old and new organizational sketch

Output

• Identified key changes that are occurring

Materials

• Whiteboard
• Sticky notes & Pens
• Camera

Participants

• OD implementation team

1. On a whiteboard, draw a high-level picture of your previous organizational sketch and your new organizational sketch.
2. Using sticky notes, ask individuals to highlight key high-level challenges that exist in the current model (consider people, process, and technology).
3. Consider each sticky note, and highlight and document how and where your new sketch will overcome those challenges and the key differences between the old structure and the new.
4. Take a photo of the two sketches and comments, and document these in your Organizational Design Implementation Kick-Off Presentation.

Modify the presentation by identifying and documenting key milestones

1.5 1 hour

Input

• OD implementation team calendars

Output

• OD implementation team timeline

Materials

• OD Implementation Kick-Off Presentation

Participants

• OD implementation team

1. Review the timeline in the Organizational Design Implementation Kick-Off Presentation. As a group, discuss the key milestones identified in the presentation:
   • Kick-off presentation
   • Departmental transition strategy built
   • Organizational transition strategy built
   • Manager training
   • One-on-one meetings with staff to discuss changes to roles
   • Individual transition strategy development begins
2. Review the timeline, and keeping your other commitments in mind, estimate when each of these tasks will be completed and update the timeline.

Build an OD implementation FAQ to proactively address key questions and concerns about the change

Organizational Design Implementation FAQ

Leverage this template as a starting place for building an organizational design implementation FAQ.

This template is prepopulated with example questions and answers which are likely to arise.

Info-Tech encourages you to use the list of questions as a basis for your FAQ and to add additional questions based on the changes occurring at your organization.

It may also be a good idea to store the FAQ on a company intranet portal so that staff has access at all times and to provide users with a unique email address to forward questions to when they have them.

Build your unique organizational design implementation FAQ to keep staff informed throughout the change

1.6 1 hour + ongoing

Input

• OD implementation team calendars

Output

• OD implementation team timeline

Materials

• OD Implementation Kick-Off Presentation

Participants

• OD implementation team

1. Download a copy of the Organizational Design Implementation FAQ and as a group, review each of the key questions.
2. Delete any questions that are not relevant and add any additional questions you either believe you will receive or which you have already been asked.
3. Divide the questions among team members and have each member provide a response to these questions.
4. The CIO and the project manager should review the responses for accuracy and ensure they are ready to be shared with staff.
5. Publish the responses on an IT intranet site and make the location known to your IT staff.

Dispelling rumors by using a large implementation team

CASE STUDY

Industry: Manufacturing

Source: CIO

Challenge

When rumors of the impending reorganization reached staff, there was a lot of confusion and some of the more vocal detractors in the department enforced these rumors.

Staff were worried about changes to their jobs, demotions, and worst of all, losing their jobs. There was no communication from senior management to dispel the gossip and the line managers were also in the dark so they weren’t able to offer support.

Staff did not feel comfortable reaching out to senior management about the rumors and they didn’t know who the change manager was.

Solution

The CIO and change manager put together a large implementation team that included many of the managers in the department. This allowed the managers to handle the gossip through informal conversations with their staff.

The change manager also built a communication strategy to communicate the stages of the reorganization and used FAQs to address the more common questions.

Results

The reorganization was adopted very quickly since there was little confusion surrounding the changes with all staff members. Many of the personnel risks were mitigated by the communication strategy because it dispelled rumors and took some of the power away from the vocal detractors in the department.

An engagement survey was conducted 3 months after the reorganization and the results showed that the engagement of staff had not changed after the reorganization.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

• To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.
• Info-Tech analysts will join you and your team onsite at your location or welcome you to Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.
• Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

1a: Launch the MLI Dashboard (Pre-Work)

Prior to the workshop, Info-Tech’s advisors will work with you to launch the MLI diagnostic to understand the overall engagement levels of your organization.

1b: Review Your MLI Results

The analysts will facilitate several exercises to help you and your team identify your current engagement levels, and the variance across demographics and over time.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

1.1: Define Your Change Team Responsibilities

Review the key responsibilities of the organizational design implementation team and define the RACI for each individual member.

1.3: Define Your Change Vision and Goals

Identify the change vision statement which will serve as the center piece for your change communications as well as the key message you want to deliver to your staff about the change. These messages should be clear, emotionally impactful, and inspirational.

1.4: Identify Key Changes Which Will Impact Staff

Collectively brainstorm all of the key changes that are happening as a result of the change, and prioritize the list based on the impact they will have on staff. Document the top 10 biggest changes – and the opportunities the change creates or problems it solves.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

1.5: Define the High-Level Change Timeline

Identify and document the key milestones within the change as a group, and determine key dates and change owners for each of the key items. Determine the best way to discuss these timelines with staff, and whether there are any which you feel will have higher levels of resistance.

1.5: Build the FAQ and Prepare for Objection Handling

As a group, brainstorm the key questions you believe you will receive about the change and develop a common FAQ to provide to staff members. The advisor will assist you in preparing to manage objections to limit resistance.

Phase 2

Build The Organizational Transition Plan

Build the organizational transition plan

Outcomes of this section:

• A holistic list of projects that will enable the implementation of the organizational structure.
• A schedule to monitor the progress of your change projects.

This section involves the following participants:

• CIO
• Reorganization Implementation Team

Key Section Insight:

Be careful to understand the impacts of the change on all groups and departments. For best results, you will need representation from all departments to limit conflict and ensure a smooth transition. For large IT organizations, you will need to have a plan for each department/work unit and create a larger integration project.

Phase 2 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 2: Build the Organizational Transition Plan

Proposed Time to Completion (in weeks): 2-4 weeks

Step 2.1: Review the Change Dimensions and How They Are Used to Plan Change Projects

Start with an analyst kick off call:

• Review the purpose of the kick-off meeting.
• Review the change project dimensions.
• Review the Organizational Design Implementation Project Planning Tool.

Then complete these activities…

• Conduct your kick-off meeting.
• Brainstorm a list of reorganization projects and their related tasks.

With these tools & templates:

• Organizational Design Implementation Project Planning Tool

Step 2.2: Review the List of Change Projects

Review findings with analyst:

• Revisit the list of projects and tasks developed in the brainstorming session.
• Assess the list and determine resourcing and dependencies for the projects.
• Review the monitoring process.

Then complete these activities…

• Complete the Organizational Design Implementation Project Planning Tool.
• Map out your project dependencies and resourcing.
• Develop a schedule for monitoring projects.

With these tools & templates:

• Organizational Design Implementation Project Planning Tool

Use Info-Tech’s Organizational Design Implementation Project Planning Tool to plan and track your reorganization

• Use Info-Tech’s Organizational Design Implementation Project Planning Tool to document and track all of the changes that are occurring during your reorganization.
• Automatically build Gantt charts for all of the projects that are being undertaken, track problems in the issue log, and monitor the progress of projects in the reporting tab.
• Each department/work group will maintain its own version of this tool throughout the reorganization effort and the project manager will maintain a master copy with all of the projects listed.
• The chart comes pre-populated with example data gathered through the research and interview process to help generate ideas for your own reorganization.
• Review the instructions at the top of each work sheet for entering and modifying the data within each chart.

Have a short kick-off meeting to introduce the project planning process to your implementation team

2.1 30 minutes

Output

• Departmental ownership of planning tool

Materials

• OD Implementation Project Planning Tool

Participants

• Change Project Manager
• Implementation Team
• Senior Management (optional)

1. The purpose of this kick-off meeting is to assign ownership of the project planning process to members of the implementation team and to begin thinking about the portfolio of projects required to successfully complete the reorganization.
2. Use the email template included on this slide to invite your team members to the meeting.
3. The topics that need to be covered in the meeting are:
   • Introducing the materials/templates that will be used throughout the process.
   • Assigning ownership of the Organizational Design Implementation Project Planning Tool to members of your team.
   • Ownership will be at the departmental level where each department or working group will manage their own change projects.
   • Prepare your implementation team for the next meeting where they will be brainstorming the list of projects that will need to be completed throughout the reorganization.
4. Distribute/email the tools and templates to the team so that they may familiarize themselves with the materials before the next meeting.

Hello [participant],

We will be holding our kickoff meeting for our reorganization on [date]. We will be discussing the reorganization process at a high level with special attention being payed to the tools and templates that we will be using throughout the process. By the end of the meeting, we will have assigned ownership of the Project Planning Tool to department representatives and we will have scheduled the next meeting where we’ll brainstorm our list of projects for the reorganization.

Consider Info-Tech’s four organizational change dimensions when identifying change projects

CHANGE DIMENSIONS

• TECHNOLOGY AND LOGISTICS
• COMMUNICATION
• STAFFING
• PROCESS

Technology and Logistics

• These are all the projects that will impact the technology used and physical logistics of your workspace.
• These include new devices, access/permissions, new desks, etc.

Communication

• All of the required changes after the reorganization to ongoing communications within IT and to the rest of the organization.
• Also includes communication projects that are occurring during the reorganization.

Staffing

• These projects address the changes to your staff’s roles.
• Includes role changes, job description building, consulting with HR, etc.

Process

• Projects that address changes to IT processes that will occur after the reorganization.

Use these trigger questions to help identify all aspects of your coming changes

STAFFING

• Do you need to hire short or long-term staff to fill vacancies?
• How long does it typically take to hire a new employee?
• Will there be staff who are new to management positions?
• Is HR on board with the reorganization?
• Have they been consulted?
• Have transition plans been built for all staff members who are transitioning roles/duties?
• Will gaps in the structure need to be addressed with new hires?

COMMUNICATION

• When will the change be communicated to various members of the staff?
• Will there be disruption to services during the reorganization?
• Who, outside of IT, needs to know about the reorganization?
• Do external communications need to be adjusted because of the reorganization? Moving/centralizing service desk, BRMs, etc.?
• Are there plans/is there a desire to change the way IT communicates with the rest of the organization?
• Will the reorganization affect the culture of the department? Is the new structure compatible with the current culture?