Design and Build a User-Facing Service Catalog

Improve user satisfaction with IT with a convenient menu-like catalog.

Our understanding of the problem

This Research Is Designed For:

• CIOs
• Directors and senior managers within IT and the business

This Research Will Help You:

• Articulate all of the services IT provides to the business in a language the business users understand.
• Improve IT and business alignment through a common understanding of service features and IT support.

This Research Will Help Them

• Standardize and communicate how users request access to services.
• Standardize and communicate how users obtain support for services.
• Clearly understand IT’s role in providing each service.

What is a service catalog?

The user-facing service catalog is the go-to place for IT service-related information.

The catalog defines, documents, and organizes the services that IT delivers to the organization. The catalog also describes the features of the services and how the services are intended to be used.

The user-facing service catalog creates benefits for both the business and IT.

For business users, the service catalog:

1. Documents how to request access to the service, hours of availability, delivery timeframes, and customer responsibilities.
2. Specifies how to obtain support for the services, support hours, and documentation.

For IT, the service catalog:

1. Identifies who owns the services and who is authorized to use the services.
2. Specifies IT support requirements for the services, including support hours and documentation.

What is the difference between a user-facing service catalog and a technical service catalog?

This blueprint is about creating a user-facing service catalog written and organized in a way that focuses on the services from the business’ view.

User facing

User-friendly, intuitive, and simple overview of the services that IT provides to the business.

The items you would see on the menu at a restaurant are an example of User Facing. The content is relatable and easy to understand.

Technical

Series of technical workflows, supporting services, and the technical components that are required to deliver a service.

The recipe book with cooking instructions is an example of Technical Facing. This catalog is intended for the IT teams and is “behind the scene.”

What is a service and what does it mean to be service oriented?

The sum of the people, processes, and technologies required to enable users to achieve a business outcome is a Service.

A service is used directly by the end users and is perceived as a coherent whole.

Business Users →Service = Application & Systems + People & Processes

Service Orientation is…

• A focus on business requirements and business value, rather than IT driven motives.
• Services are designed to enable required business activities.
• Services are defined from the business perspective using business language.

In other words, put on your user hat and leave behind the technical jargons!

A lack of a published user-facing service catalog could be the source of many pains throughout your organization

IT Pains

• IT doesn’t understand all the services they provide.
• Business users would go outside of IT for solutions, proliferating shadow IT.
• Business users have a negative yet unrealistic perception of what IT is capable of.
• IT has no way of managing expectations for their users, which tend to inflate.
• There is often no defined agreement on services; the business assumes everything is available.

Business Pains

• Business users don’t know what services are available to them.
• It is difficult to obtain useful information regarding a service because IT always talks in technical language.
• Without a standard process in place, business users don’t know how to request access to a service with multiple sources of information available.
• Receiving IT support is a painful, long process and IT doesn’t understand what type of support the business requires.

An overwhelming majority of IT organizations still need to improve how they demonstrate their value to the business

23% of IT is still viewed as a cost center.	47% of business executives believe that business goals are going unsupported by IT.	92% of IT leaders see the need to prove the business value of IT’s contribution.
How a Service Catalog can help:
Use the catalog to demonstrate how IT is an integral part of the organization and IT services are essential to achieve business objectives. Source: IT Communication in Crisis Report	Transform the perception of IT by articulating all the services that are provided through the service catalog in a user-friendly language. Source: Info-Tech Benchmarking and Diagnostic Programs	Increase IT-business communication and collaboration through the service catalog initiative. Move from technology focused to service-oriented. Source: IT Communication in Crisis Report

Project Steps

Phase 1 – Project Launch

1.2 Project Team

The team must be balanced between representatives from the business and IT.

1.2 Communication Plan

Communication plan to facilitate input from both sides and gain adoption.

1.3 Identify Metrics

Metrics should reflect the catalog benefits. Look to reduced number of service desk inquiries.

1.4 Project Charter

Project charter helps walk you through project preparation.

This blueprint separates enterprise service from line of business service.

Project steps

Phase 2 – Identify and Define Enterprise Services

2.1 Identify the services that are used across the entire organization.

2.2 Users must be able to identify with the service categories.

2.3 Create basic definitions for enterprise services.

Phase 3 – Identify and Define Line of Business Services

3.1 Identify the different lines of business (LOBs) in the organization.

3.2 Understand the differences between our two methodologies for identifying LOB services.

3.3 Use methodology 1 if you have thorough knowledge of the business.

3.4 Use methodology 2 if you only have an IT view of the LOB.

Phase 4 – Complete Service Definitions

4.1 Understand the different components to each service definition, or the fields in the service record.

4.2 Identify which information to include for each service definition.

4.3 Define each enterprise service according to the information and field properties.

4.3 Define each LOB service according to the information and field properties.

Define your service catalog in bundles to achieve better catalog design in the long run

Trying to implement too many services at once can be overwhelming for both IT and the users. You don’t have to define and implement all of your services in one release of the catalog.

Info-Tech recommends implementing services themselves in batches, starting with enterprise, and then grouping LOB services into separate releases. Why? It benefits both IT and business users:

• It enables a better learning experience for IT – get to test the first release before going full-scale. In other words, IT gets a better understanding of all components of their deliverable before full adoption.
• It is easier to meet customer agreements on what is to be delivered early, and easier to be able to meet those deadlines.

After implementing a service catalog, your IT will be able to:

Use the service catalog to communicate all the services that IT provides to the business.

Improve IT’s visibility within the organization by creating a single source of information for all the value creating services IT has to offer. The service catalog helps the business understand the value IT brings to each service, each line of business, and the overall organization.

Concentrate more on high-value IT services.

The service catalog contains information which empowers business users to access IT services and information without the help of IT support staff. The reduction in routine inquiries decreases workload and increases morale within the IT support team, and allows IT to concentrate on providing higher value services.

Reduce shadow IT and gain control of services.

Service catalog brings more control to your IT environment by reducing shadow IT activities. The service catalog communicates business requests responsively in a language the business users understand, thus eliminating the need for users to seek outside help.

After implementing a service catalog, your business will be able to:

Access IT services with ease.

The language of IT is often confusing for the business and the users don’t know what to do when they have a concern. With a user-facing service catalog, business users can access information through a single source of information, and better understand how to request access or receive support for a service through clear, consistent, and business-relevant language.

Empower users to self-serve.

The service catalog enables users to “self-serve” IT services. Instead of calling the service desk every time an issue occurs, the users can rely on the service catalog for information. This simplified process not only reduces routine service requests, but also provides information in a faster, more efficient manner that increases productivity for both IT and the business.

Gain transparency on the IT services provided.

With every service clearly defined, business users can better understand the current support level, communicate their expectation for IT accountability, and help IT align services with critical business strategies.

Leverage the different Info-Tech deliverable tools to help you along the way

1. Project Charter

A project charter template with a few samples completed. The project charter helps you govern the project progress and responsibilities.

2. Enterprise Service Definitions

A full list of enterprise definitions with features and descriptions pre-populated. These are meant to get you on your feet defining your own enterprise services, or editing the ones already there.

3. Basic Line of Business Service Definitions

Similar to the enterprise services deliverable, but with two separate deliverables focusing on different perspectives – functional groups services (e.g. HR and finance) and industry-specific services (e.g. education and government).

Service Definitions & Service Record Design

Get a taste of a completed service catalog with full service definitions and service record design. This is the final product of the service catalog design once all the steps and activities have been completed.

The service catalog can be the foundation of your future IT service management endeavors

After establishing a catalog of all IT services, the following projects are often pursued for other objectives. Service catalog is a precursor for all three.

1. Technical Service Catalog

Need an IT-friendly breakdown of each service?
Keep better record of what technical components are required to deliver a service. The technical service catalog is the IT version of a user-facing catalog.

2. Service-Based Costing

Want to know how much each IT service is costing you?
Get a better grip on the true cost of IT. Using service-based costing can help justify IT expenses and increase budgetary allotment.

3. Chargeback

Want to hold each business unit accountable for the IT services they use?
Some business units abuse their IT services because they are thought to be free. Keep them accountable and charge them for what they use.

The service catalog need not be expensive – organizations of all sizes (small, medium, large) can benefit from a service catalog

No matter what size organization you may be, every organization can create a service catalog. Small businesses can benefit from the catalog the same way a large organization can. We have an easy step-by-step methodology to help introduce a catalog to your business.

It is common that users do not know where to go to obtain services from IT… We always end up with a serious time-crunch at the beginning of a new school year. With automated on- and off-boarding services, this could change for the better. – Dean Obermeyer, Technology Coordinator, Los Alamos Public Schools

CIO Call to Action

As the CIO and the project sponsor, you need to spearhead the development of the service catalog and communicate support to drive engagement and adoption.

Start

1. Select an experienced project leader
2. Identify stakeholders and select project team members with the project leader

Throughout the project

3. Attend or lead the project kick-off meeting
4. Create checkpoints to regularly touch base with the project team

Service catalog launch

5. Communicate the change message from beginning to implementation

Identify a project leader who will drive measurable results with this initiative

The project leader acts on behalf of the CIO and must be a senior level staff member who has extensive knowledge of the organization and experiences marshalling resources.

Influential & Impactful

Developing a service catalog requires dedication from many groups within IT and outside of IT.
The project leader must hold a visible, senior position and can marshal all the necessary resources to ensure the success of the project. Ability to exert impact and influence around both IT and the business is a must.

Relationship with the Business

The user-facing service catalog cannot be successful if business input is not received.
The project leader must leverage his/her existing relationship with the business to test out the service definitions and the service record design.

Results Driven

Creating a service catalog is not an easy job and the project leader must continuously engage the team members to drive results and efficiency.
The highly visible nature of the service catalog means the project leader must produce a high-quality outcome that satisfies the business users.

Info-Tech’s methodology helps organization to standardize how to define services

CASE STUDY A
Industry Municipal Government
Source Onsite engagement

Municipal Government
The IT department of a large municipal government in the United States provides services to a large number of customers in various government agencies.
Service Catalog Initiative
The municipal government allocated a significant amount of resources to answer routine inquiries that could have been avoided through user self-service. The government also found that they do not organize all the services IT provides, and they could not document and publish them to the customer. The government has already begun the service catalog initiative, but was struggling with how to identify services. Progress was slow because people were arguing amongst themselves – the project team became demoralized and the initiative was on the brink of failure.
Results
With Info-Tech’s onsite support, the government was able to follow a standardized methodology to identify and define services from the user perspective. The government was able to successfully communicate the initiative to the business before the full adoption of the service catalog.

We’re in demos with vendors right now to purchase an ITSM tool, and when the first vendor looked at our finished catalog, they were completely impressed.- Client Feedback

[We feel] very confident. The group as a whole is pumped up and empowered – they're ready to pounce on it. We plan to stick to the schedule for the next three months, and then review progress/priorities. - Client Feedback

CASE STUDY B
Industry Healthcare
Source Onsite engagement

Healthcare Provider
The organization is a healthcare provider in Canada. It treats patients with medical emergencies, standard operations, and manages a faculty of staff ranging from nurses and clerks, to senior doctors. This organization is run across several hospitals, various local clinics, and research centers.
Service Catalog Initiative
Because the organization is publicly funded, it is subject to regular audit requirements – one of which is to have a service catalog in place.
The organization also would like to charge back its clients for IT-related costs. In order to do this, the organization must be able to trace it back to each service. Therefore, the first step would be to create a user-facing service catalog, followed by the technical service catalog, which then allows the organization to do service-based costing and chargeback.
Results
By leveraging Info-Tech’s expertise on the subject, the healthcare provider was able to fast-track its service catalog development and establish the groundwork for chargeback abilities.

"There is always some reticence going in, but none of that was apparent coming out. The group dynamic was very good. [Info-Tech] was able to get that response, and no one around the table was silent.
The [expectation] of the participants was that there was a purpose in doing the workshop. Everybody knew it was for multiple reasons, and everyone had their own accountability/stakes in the development of it. Highly engaged." - Client Feedback

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

Workshop overview

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

PHASE 1

Launch the Project

Design & Build a User-Facing Service Catalog

Step 1 – Create a project charter to launch the initiative

1. Complete the Project Charter
2. Create Enterprise Services Definitions
3. Create Line of Business Services Definitions
4. Complete Service Definitions

This step will walk you through the following activities:

• Develop a mission statement to obtain buy-ins from both IT and business stakeholders.
• Assemble a well-rounded project team to increase the success of the project.
• Identify and obtain support from stakeholders.
• Create an impactful change message to the organization to promote the service catalog.
• Determine project metrics to measure the effectiveness and value of the initiative.

Step Insights

• The project leader must have a strong relationship with the business, the ability to garner user input, and the authority to lead the team in creating a user-facing catalog that is accessible and understandable to the user.
• Having two separate change messages prepared for IT and the business is a must. The business change message advocates how the catalog will make IT more accessible to users, and the IT message centers around how the catalog will make IT’s life easier through a standardized request process.

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.

Use Info-Tech’s Service Catalog Project Charter to begin your initiative

1.1 Project Charter

The following section of slides outline how to effectively use Info-Tech’s sample project charter.

The Project Charter is used to govern the initiative throughout the project. IT should provide the foundation for project communication and monitoring.

It has been pre-populated with information appropriate for Service Catalog projects. Please review this sample text and change, add, or delete information as required.

Building the charter as a group will help you to clarify your key messages and help secure buy-in from critical stakeholders upfront.

You may feel like a full charter isn’t necessary, and depending on your organizational size, it might not be. However, the exercise of building the charter is important none-the-less. No matter your current climate, some elements of communicating the value and plans for implementing the catalog will be necessary.

The Charter includes the following sections:

• Mission Statement
• Project team members
• Project stakeholders
• Change message
• Communication and organizational plan
• Metrics

Use Info-Tech’s Service Catalog Project Charter.

Create a mission statement to articulate the purpose of this project

The mission statement must be compelling because embarking on creating a service catalog is no easy task. It requires significant commitment from different people in different areas of the business.

Good mission statements are directive, easy to understand, narrow in focus, and favor substance over vagueness.

While building your mission statement, think about what it is intended to do, i.e. keep the project team engaged and engage others to adopt the service catalog. Included in the project charter’s mission statement section is a brief description of the goals and objectives of the service catalog.

Ask yourself the following questions:

1. What frustrations does your business face regarding IT services?
2. f our company continues growing at this rate, will IT be able to manage service levels?
3. How has IT benefited from consolidating IT services into a user perspective?

Project Charter

Info-Tech’s project charter contains two sample mission statements, along with additional tips to help you create yours.

Tackle the project with a properly assembled team to increase the speed and quality in which the catalog will be created

Construct a well-balanced project team to increase your chances of success.

Project Leader

Project leader will be the main catalyst for the creation of the catalog. This person is responsible for driving the whole initiative.

Project Participants

IT project participants’ input and business input will be pivotal to the creation of the catalog.

Project Stakeholders

The project stakeholders are the senior executives who have a vested interest in the service catalog. IT must produce periodic and targeted communication to these stakeholders.

Increase your chances of success by creating a dynamic group of project participants

Your project team will be a major success factor for your service catalog. Involvement from IT management and the business is a must.

IT Team Member

IT Service Desk Manager

• The Service Desk team will be an integral part of the service catalog creation. Because of their client-facing work, service desk technicians can provide real feedback about how users view and request services.

Senior Manager/Director of Application

• The Application representative provides input on how applications are used by the business and supported by IT.

Senior Manager/Director of Infrastructure

• The infrastructure representative provides input on services regarding data storage, device management, security, etc.

Business Team Member

Business IT Liaison

• This role is responsible for bridging the communication between IT and the business. This role could be fulfilled by the business relationship manager, service delivery manager, or business analyst. It doesn’t have to be a dedicated role; it could be part of an existing role.

Business representatives from different LOBs

• Business users need to validate the service catalog design and ensure the service definitions are user facing and relevant.

Project Charter

Input your project team, their roles, and relevant contact information into your project charter, Section 2.

Identify the senior managers who are the stakeholders for the service catalog

Obtain explicit buy-in from both IT and business stakeholders.

The stakeholders could be your biggest champions for the service catalog initiative, or they could pull you back significantly. Engage the stakeholders at the start of the project and communicate the benefits of the service catalog to them to gain their approval.

Project Charter

Document a list of stakeholders, their involvement in the process (why they are stakeholders), and their contact information in Section 3.

Articulate the creation of the service catalog to the organization

Spread the word of service catalog implementation. Bring attention to your change message through effective mediums and organizational changes.

Key aspects of a communication plan

The methods of communication (e.g. newsletters, email broadcast, news of the day, automated messages) notify users of implementation.

In addition, it is important to know who will deliver the message (delivery strategy). Talking to the business leaders is very important, and you need IT executives to deliver the message. Work hard on obtaining their support as they are the ones communicating to their staff and could be your project champions.

Recommended organizational changes

The communication plan should consist of changes that will affect the way users interact with the catalog. Users should know of any meetings pertinent to the maintenance and improvement of the catalog, and ways to access the catalog (e.g. link on desktop/start menu).

The Qualities of Leadership: Leading Change

Project Charter

Your communication plan should serve as a rough guide. Communication happens in several unpredictable happenstances, but the overall message should be contained within.

Ensure you get the whole company on board for the service catalog with a well practiced change message

The success of your catalog implementation hinges on the business’ readiness.

One of the top challenges for organizations that are implementing a service catalog is the acceptance and adoption of the change. Effective planning for implementation and communication is pivotal. Ensure you create tailored plans for communication and understand how the change will impact staff.

1. Draft your change message

“Better Service, Better Value.” It is important to have two change messages prepared: one for the IT department and one for business users.
Outline a few of the key benefits each user group will gain from adopting the service catalog (e.g. Faster, ease of use, convenient, consistent…)

2. Address feedback

Anticipate some resistances of service catalog adoption and prepare responses. These may be the other benefits which were not included in the change message (e.g. IT may be reluctant to think in business language.)

3. Conduct training sessions

Host lunch & learns to demonstrate the value of the service catalog to both business and IT user groups.
These training sessions also serve as a great way to gather feedback from users regarding style and usability.

Project Charter

Pick your communication medium, and then identify your target audience. You should have a change message for each: the IT department and the business users. Pay careful consideration to wording and phrasing with regard for each.

Track metrics throughout the project to keep stakeholders informed

In order to measure the success of your service catalog, you must establish baseline metrics to determine how much value the catalog is creating for your business.

1. Number of service requests via the service catalog

The number of service catalog requests should be carefully monitored so that it does not fluctuate too greatly. In general, the number of requests via the service catalog should increase, which indicates a higher level of self-serve.

2. Number of inquiry calls to the service desk

The number of inquiry calls should decrease because customers are able to self-serve routine IT inquiries that would otherwise have gone through the service desk.

3. Customer satisfaction – specific questions

The organization could adopt the following sample survey questions:
From 0-5: How satisfied are you with the functionality of the service catalog? How often do you turn to the service catalog first to solve IT problems?

4. Number of non-standard requests

The number of non-standard requests should decrease because a majority of services should eventually be covered in the service catalog. Users should be able to solve nearly any IT related problem through navigating the service catalog.

Use metrics to monitor the monetary improvements the service catalog creates for the business

When measuring against your baseline, you should expect to see the following two monetary improvements:

1. Improved service desk efficiency

(# of routine inquiry calls reduced) x (average time for a call) x (average service desk wage)

Routine inquiries often take up a significant portion of the service desk’s effort, and the majority of them can be answered via the service catalog, thus reducing the amount of time required for a service desk employee to engage in routine solutions. The reduction in routine inquiries allows IT to allocate resources to high-value services and provide higher quality of support.

Example

Originally, the service desk of an organization answers 850 inquiries per month, and around 540 of them are routine inquiries requesting information on when a service is available, who they can contact if they want to receive a service, and what they need to do if they want access to a service, etc.

IT successfully communicated the introduction of the service catalog to the business and 3 months after the service catalog was implemented, the number of routine inquiries dropped to 60 per month. Given that the average time for IT to answer the inquiry is 10 minutes (0.167 hour) and the hourly wage of a service desk technician is $25, the monthly monetary cost saving of the service catalog is:

(540 – 60) x 0.167 x 25 = $2004.00

• Reduced expense by eliminating non-standard requests

(Average additional cost of non-standard request) x (Reduction of non-standard request)
+
(Extra time IT spends on non-standard request fulfilment) x (Average wage)

Non-standard requests require a lot of time, and often a lot of money. IT frequently incurs additional cost because the business is not aware of how to properly request service or support. Not only can the service catalog standardize and streamline the service request process, it can also help IT define its job boundary and say no to the business if needed.

Example

The IT department of an organization often finds itself dealing with last-minute, frustrating service requests from the business. For example, although equipment requests should be placed a week in advance, the business often requests equipment to be delivered the next day, leaving IT to pay for additional expedited shipping costs and/or working fanatically to allocate the equipment. Typically, these requests happen 4 times a month, with an additional cost of $200.00. IT staff work an extra 6 hours per each non-standard request at an hourly wage of $30.00.

With the service catalog, the users are now aware of the rules that are in place and can submit their request with more ease. IT can also refer the users to the service catalog when a non-standard request occurs, which helps IT to charge the cost to the department or not meet the terms of the business.

The monthly cost saving in this case is:

$200.00 x 4 + 6 hours x 30 = $980.00

Create your project charter for the service catalog initiative to get key stakeholders to buy in

1.1 2-3 hours

The project charter is an important document to govern your project process. Support from the project sponsors is important and must be documented. Complete the following steps working with Info-Tech’s sample Project Charter.

1. The project leader and the core project team must identify key reasons for creating a service catalog. Document the project objectives and benefits in the mission statement section.
2. Identify and document your project team. The team must include representatives from the Infrastructure, Applications, Service desk, and a Business-IT Liaison.
3. Identify and document your project stakeholders. The stakeholders are those who have interest in seeing the service catalog completed. Stakeholders for IT are the CIO and management of different IT practices. Stakeholders for the business are executives of different LOBs.
4. Identify your target audience and choose the communication medium most effective to reach them. Draft a communication message hitting all key elements.
   Info-Tech’s project charter contains sample change messages for the business and IT.
5. Develop a strategy as to how the change message will be distributed, i.e. the communication and organizational change plan.
6. Use the metrics identified as a base to measure your service catalog’s implementation. If you have identified any other objectives, add new metrics to monitor your progress from the baseline to reaching those objectives.
7. Sign and date the project charter to officiate commitment to completing the project and reaching your objectives. Have the signed and dated charter available to members of the project team.

INPUT

• A collaborative discussion between team members

OUTPUT

• Thorough briefing for project launch
• A committed team

Materials

• Communication message and plan
• Metric tracking

Participants

• Project leader
• Core project team

Obtain buy-in from business users at the beginning of the service catalog initiative

CASE STUDY A
Industry Government
Source Onsite engagement

Challenge

The nature of government IT is quite complex: there are several different agencies located in a number of different areas. It is extremely important to communicate the idea of the service catalog to all the users, no matter the agency or location.

The IT department had yet to let business leaders of the various agencies know about the initiative and garner their support for the project. This has proven to be prohibitive for gaining adoption from all users.

Solution

The IT leaders met and identified all the opportunities to communicate the service catalog to the business leaders and end users.

To meet with the business leaders, IT leaders hosted a service level meeting with the business directors and managers. They adopted a steering committee for the continuation of the project.

To communicate with business users, IT leaders published announcements on the intranet website before releasing the catalog there as well.

Results

Because IT communicated the initiative, support from business stakeholders was obtained early and business leaders were on board shortly after.

IT also managed to convince key business stakeholders to become project champions, and leveraged their network to communicate the initiative to their employees.

With this level of adoption, it meant that it was easier for IT to garner business participation in the project and to obtain feedback throughout.

Info-Tech assists project leader to garner support from the project team

CASE STUDY A
Industry Government
Source Onsite engagement

Challenge

The project received buy-in from the CIO and director of infrastructure. Together they assembled a team and project leader.

The two struggled to get buy-in from the rest of the team, however. They didn’t understand the catalog or its benefits and objectives. They were reluctant to change their old ways. They didn’t know how much work was required from them to accomplish the project.

Solution

With the Info-Tech analyst on site, the client was able to discuss the benefits within their team as well as the project team responsibilities.

The Info-Tech analyst convinced the group to move towards focusing on a business- and service-oriented mindset.

The workshop discussion was intended to get the entire team on board and engaged with meeting project objectives.

Results

The project team had experienced full buy-in after the workshop. The CIO and director relived their struggles of getting project members on-board through proper communication and engagement.

Engaging the members of the project team with the discussion was key to having them take ownership in accomplishing the project.

The business users understood that the service catalog was to benefit their long-term IT service development.

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:
1.1		Begin your project with a mission statement A strong mission statement that outlines the benefits of the project is needed to communicate the purpose of the project. The onsite Info-Tech analysts will help you customize the message and establish the foundation of the project charter.
1.2		Identify project team members Our onsite analysts will help you identify high-value team members to contribute to this project.
1.3		Identify important business and IT stakeholders Buy-in from senior IT and business management is a must. Info-Tech will help you identify the stakeholders and determine their level of influence and impact.
1.4		Create a change message for the business and IT It is important to communicate changes early and the message must be tailored for each target audience. Our analysts will help you create an effective message by articulating the benefits of the service catalog to the business and to IT.
1.5		Determine service project metrics To demonstrate the value of the service catalog, IT must come up with tangible metrics. Info-Tech’s analysts will provide some sample metrics as well as facilitate a discussion around which metrics should be tracked and monitored.

PHASE 2

Identify and Define Enterprise Services

Design & Build a User-Facing Service Catalog

Step 2 – Create Enterprise Services Definitions

1. Complete the Project Charter
2. Create Enterprise Services Definitions
3. Create Line of Business Services Definitions
4. Complete Service Definitions

This step will walk you through the following activities:

• Identify and define enterprise services that are commonly used across the organization.
• Create service descriptions and features to accurately sum up the functionality of each service.
• Create service categories and assign each service to a category.

Step Insights

• When defining services, be sure to carefully distinguish between what is a feature and what is a service. Often, separate services are defined in situations when they would be better off as features of existing services, and vice versa.
• When coming up with enterprise services categories, ensure the categories group the services in a way that is intuitive. The users should be able to find a service easily based on the names of the categories.

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.

Identify enterprise services in the organization apart from the services available to lines of business

Separating enterprise services from line of business services helps keep things simple to organize the service catalog. -

Documentation of all business-facing IT services is an intimidating task, and a lack of parameters around this process often leads to longer project times and unsatisfactory outcomes.

To streamline this process, separating enterprise services from line of business services allows IT to effectively and efficiently organize these services. This method increases the visibility of the service catalog through user-oriented communication plans.

Enterprise Services are common services that are used across the organization.

1. Common Services for all users within the organization (e.g. Email, Video Conferencing, Remote Access, Guest Wireless)
2. Service Requests organized into Service Offerings (e.g. Hardware Provisioning, Software Deployment, Hardware Repair, Equipment Loans)
3. Consulting Services (e.g. Project Management, Business Analysis, RFP Preparation, Contract Negotiation)

All user groups access Enterprise Services

Enterprise Services

• Finance
• IT
• Sales
• HR

Ensure your enterprise services are defined from the user perspective and are commonly used

If you are unsure whether a service is enterprise wide, ask yourself these two questions:

Leverage Info-Tech’s Sample Enterprise Services definition

2.1 Info-Tech’s Sample Enterprise Services definitions

Included with this blueprint is Info-Tech’s Sample Enterprise Services definitions.

The sample contains dozens of services common across most organizations; however, as a whole, they are not complete for every organization. They must be modified according to the business’ needs. Phase two will serve as a guide to identifying an enterprise service as well as how to fill out the necessary fields.

Info-Tech Insight

Keep track of which services you either modify or delete. You will have to change the same services in the final Info-Tech deliverable.

The next slide will introduce you to the information for each service record that can be edited.

Info-Tech’s Sample Enterprise Services definitions is designed to be easily customized

2.1 Info-Tech’s Sample Enterprise Services definitions

Below is an example of a service record and its necessary fields of information. This is information that can be kept, deleted, or expanded upon.

Distinguish between a feature and a unique service

It can be difficult to determine what is considered a service itself, and what is a feature of another service. Use these tips and examples below to help you standardize this judgement.

Example 1

Web Conferencing has already been defined as a service. Is Audio Conferencing its own service or a feature of Web Conferencing?

Info-Tech Tip: Is Audio Conferencing run by the same application as the Web Conferencing? Does it use the same equipment? If not, Audio Conferencing is probably its own service.

Example 2

Web Conferencing has already been defined as a service. Is “Screen Sharing” its own service or a feature of Web Conferencing?

Info-Tech Tip: It depends on how the user interacts with Screen Sharing. Do they only screen share when engaged in a Web Conference? If so, Screen Sharing is a feature and not a service itself.

Example 3

VoIP is a popular alternative to landline telephone nowadays, but should it be part of the telephony service or a separate service?

Info-Tech Tip: It depends on how the VoIP phone is set up.

If the user uses the VoIP phone the same way they would use a landline phone – because the catalog is user facing – consider the VoIP as part of the telephone service.

If the user uses their computer application to call and receive calls, consider this a separate service on its own.

Info-Tech Insight

While there are some best practices for coming up with service definitions, it is not an exact science and you cannot accommodate everyone. When in doubt, think how most users would perceive the service.

Change or delete Info-Tech’s enterprise services definitions to make them your own

2.1 3 hours

You need to be as comprehensive as possible and try to capture the entire breadth of services IT provides to the business.

To achieve this, a three-step process is recommended.

1. First, assemble your project team. It is imperative to have representatives from the service desk. Host two separate workshops, one with the business and one with IT. These workshops should take the form of focus groups and should take no more than 1-2 hours.
2. Business Focus Group:

• In an open-forum setting, discuss what the business needs from IT to carry out their day-to-day activities.
• Engage user-group representatives and business relationship managers.

IT Focus Group:

• In a similar open-forum setting, determine what IT delivers to the business. Don’t think about it from a support perspective, but from an “ask” perspective – e.g. “Service Requests.”
• Engage the following individuals: team leads, managers, directors.

INPUT

• Modify Info-Tech’s sample services

OUTPUT

• A list of some of your business’ enterprise services

Materials

• Whiteboard/marker
• Info-Tech sample enterprise services

Participants

• Key members of the project team
• Service desk rep
• Business rep

Using Info-Tech’s Sample Enterprise Services, expand upon the services to add those that we did not include

2.2 1-3 hours (depending on size and complexity of the IT department)

Have your user hat on when documenting service features and descriptions. Try to imagine how the users interact with each service.

1. Once you have your service name, start with the service feature. This field lists all the functionality the service provides. Think from the user’s perspective and document the IT-related activities they need to complete.
2. Review the service feature fields with internal IT first to make sure there isn’t any information that IT doesn’t want to publish. Afterwards, review with business users to ensure the language is easy to understand and the features are relatable.
3. Lastly, create a high-level service description that defines the nature of the service in one or two sentences.

INPUT

• Collaborate and discuss to expand on Info-Tech’s example

OUTPUT

• A complete list of your business’ enterprise services

Materials

• Whiteboard/marker
• Info-Tech sample enterprise services

Participants

• Key members of the project team
• Service desk rep
• Business rep

Follow Info-Tech’s guidelines to establish categories for the enterprise services that IT provides to the business

Similar to the services and their features, there is no right or wrong way to categorize. The best approach is to do what makes sense for your organization and understand what your users think.

What are Service Categories?

Categories organize services into logical groups that the users can identify with. Services with similar functions are grouped together in a common category.

When deciding your categories, think about:

• What is best for the users?
• Look at the workflows from the user perspective: how and why do they use the service?
• Will the user connect with the category name?
• Will they think about the services within the category?

Sample categories

Categorize the services from the list below; how would you think to group them?

There is no right or wrong way to categorize services; it is subjective to how they are provided by IT and how they are used by the business. Use the aforementioned categories to group the following services. Sample solutions are provided on the following slide.

Tips and tricks:

1. Think about the technology behind the service. Is it the same application that provides the services? For example: is instant messaging run by the same application as email?
2. Consider how the service is used by the business. Are two services always used together? If instant messaging is always used during video conferencing, then they belong in the same category.
3. Consider the purpose of the services. Do they achieve the same outcomes? For example, document sharing is different from video conferencing, though they both support a collaborative working environment.

This is a sample of different categorizations – use these examples to think about which would better suit your business

Info-Tech Insight

Services can have multiple categories only if it means the users will be better off. Try to limit this as much as possible.

Neither of these two examples are the correct answer, and no such thing exists. The answers you came up with may well be better suited for the users in your business.

With key members of your project team, categorize the list of enterprise services you have created

2.3 1 hour

Before you start, you must have a modified list of all defined enterprise services and a modified list of categories.

1. Write down the service names on sticky notes and write down the categories either on the whiteboard or on the flipchart.
2. Assign the service to a category one at a time. For each service, obtain consensus on how the users would view the service and which category would be the most logical choice. In some cases, discuss whether a service should be included in two categories to create better searchability for the users.
3. If a consensus could not be reached on how to categorize a service, review the service features and category name. In some cases, you may go back and change the features or modify or create new categories if needed.

INPUT

• Collaborate and discuss to expand on Info-Tech’s example

OUTPUT

• A complete list of your business’ enterprise services

Materials

• Whiteboard/marker
• Info-Tech sample enterprise services

Participants

• Key members of the project team
• Service desk rep
• Business rep

Accounts & Access Services

• User ID & Access
• Remote Access
• Business Applications Access

Communication Services

• Telephone
• Email
• Mobile devices

Files & Documents

• Shared Folders
• File Storage
• File Restoration
• File Archiving

Collaboration

• Web Conferencing
• Audio Conferencing
• Video Conferencing
• Chat
• Document Sharing

Employee Services

• Onboarding & Off Boarding
• Benefits Self Service
• Time and Attendance
• Employee Records Management

Help & Support

• Service Desk
• Desk Side Support
• After Hours Support

Desktop, Equipment, & Software

• Printing
• Hardware Provisioning
• Software Provisioning
• Software Support
• Device Move
• Equipment Loaner

Education & Training Services

• Desktop Application Training
• Corporate Application Training
• Clinical Application Training
• IT Training Consultation

Connectivity

• BYOD (wireless access)
• Internet
• Guest Wi-Fi

IT Consulting Services

• Project Management
• Analysis
• RFP Reviews
• Solution Development
• Business Analysis/Requirements Gathering
• RFI/RFP Evaluation
• Security Consulting & Assessment
• Contract Management
• Contract Negotiation

IT department identifies a comprehensive list of enterprise services

CASE STUDY A
Industry Government
Source Onsite engagement

Challenge

Because of the breadth of services IT provides across several agencies, it was challenging to identify what was considered enterprise beyond just the basic ones (email, internet, etc.)

IT recognized that although the specific tasks of service could be different, there are many services that are offered universally across the organization and streamlining the service request and delivery process would reduce the burden on IT.

Solution

The client began with services that users interact with on a daily basis; this includes email, wireless, telephone, internet, printing, etc.

Then, they focused on common service requests from the users, such as software and hardware provisioning, as well as remote access.

Lastly, they began to think of other IT services that are provided across the organization, such as RFP/RFI support, project management analysis, employee onboarding/off-boarding, etc.

Results

By going through the lists and enterprise categories, the government was able to come up with a comprehensive list of all services IT provides to the business.

Classifying services such as onboarding meant that IT could now standardize IT services for new recruits and employee termination.

By capturing all enterprise services offered to the organization, IT centralized its management of services instead of having scattered request processes.

Organization distinguishes features from services using Info-Tech’s tips and techniques

CASE STUDY B
Industry Government
Source Onsite engagement

Challenge

For some services, the project team had difficulty deciding on what was a service and what was a feature. They found it hard to distinguish between a service with features or multiple services.

For example, the client struggled to define the Wi-Fi services because they had many different user groups and different processes to obtain the service. Patients, visitors, doctors, researchers, and corporate employees all use Wi-Fi, but the service features for each user group were different.

Solution

The Info-Tech analyst came on-site and engaged the project team in a discussion around how the users would view the services.

The analyst also provided tips and techniques on identifying services and their features.

Because patients and visitors do not access Wi-Fi or receive support for the service in the same way as clinical or corporate employees, Wi-Fi was separated into two services (one for each user group).

Results

Using the tips and techniques that were provided during the onsite engagement, the project team was able to have a high degree of clarity on how to define the services by articulating who the authorized users are, and how to access the process.

This allowed the group to focus on the users’ perspective and create clear, unambiguous service features so that users could clearly understand eligibility requirements for the service and how to request them.

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:
2.1		Understand what enterprise services are The project team must have a clear understanding of what qualifies as an enterprise service. The onsite analysts will also promote a user-oriented mindset so the catalog focuses on business needs.
2.2		Identify enterprise services The Info-Tech analysts will provide a list of ready-to-use services and will work with the project team to change, add, and delete service definitions and to customize the service features.
2.3		Identify categories for enterprise services The Info-Tech analyst will again emphasize the importance of being service-oriented rather than IT-oriented. This will allow the group to come up with categories that are intuitive to the users.

PHASE 3

Identify and Define Line of Business Services

Design & Build a User-Facing Service Catalog

Step 3 – Create Line of Business Services Definitions

1. Complete the Project Charter
2. Create Enterprise Services Definitions
3. Create Line of Business Services Definitions
4. Complete Service Definitions

This step will walk you through the following activities:

• Identify lines of business (LOB) within the organization as well as the user groups within the different LOBs.
• Determine which one of Info-Tech’s two approaches is more suitable for your IT organization.
• Define and document LOB services using the appropriate approach.
• Categorize the LOB services based on the organization’s functional structure.

Step Insights

• Collaboration with the business significantly strengthens the quality of line of business service definitions. A significant amount of user input is crucial to create impactful and effective service definitions.
• If a strong relationship with the business is not in place, IT can look at business applications and the business activities they support in order to understand how to define line of business services.

Phase 3 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.

Communicate with your business users to get a clear picture of each line of business

Within a business unit, there are user groups that use unique applications and IT services to perform business activities. IT must understand which group is consuming each service to document to their needs and requirements. Only then is it logical to group services into lines of business.

Covering every LOB service is a difficult task. Info-Tech offers two approaches to identifying LOB services, though we recommend working alongside business user groups to have input on how each service is used directly from the users. Doing so makes the job of completing the service catalog easier, and the product more detailed and user friendly.

Some helpful questions to keep in mind when characterizing user groups:

• Where do they fall on the organizational chart?
• What kind of work do they do?
• What is included in their job description?
• What are tasks that they do in addition to their formal responsibilities?
• What do they need from IT to do their day-to-day tasks?
• What does their work day look like?
• When, why, and how do they use IT services?

Info-Tech Insight

With business user input, you can answer questions as specific as “What requirements are necessary for IT to deliver value to each line of business?” and “What does each LOB need in order to run their operation?”

Understand when it is best to use one of Info-Tech’s two approaches to defining LOB services

1. Business View

Business View is the preferred method for IT departments with a better understanding of business operations. This is because they can begin with input from the user, enabling them to more successfully define every service for each user group and LOB.

In addition, IT will also have a chance to work together with the business and this will improve the level of collaboration and communication. However, in order to follow this methodology, IT needs to have a pre-established relationship with the business and can demonstrate their knowledge of business applications.

2. IT View

The IT view begins with considering each business application used within the organization’s lines of business. Start with a broad view, following with a process of narrowing down, and then iterate for each business application.

This process leads to each unique service performed by every application within the business’ LOBs.

The IT view does not necessarily require a substantial amount of information about the business procedures. IT staff are capable of deducing what business users often require to maintain their applications’ functionality.

Use one of Info-Tech’s two methodologies to help you identify each LOB service

Choose the methodology that fits your IT organization’s knowledge of the business.

1. Business View

If you do have knowledge of business operations, using the business view is the better option and the service definition will be more relatable to the users.

2. IT View

For organizations that don’t have established relationships with the business or detailed knowledge of business activities, IT can decompose the application into services. They have more familiarity and comfort with the business applications than with business activities.

It is important to continue after the service is identified because it helps confirm and solidify the names and features. Determining the business activity and the user groups can help you become more user-oriented.

Identifying LOB services using Info-Tech’s Business View method

We will illustrate the two methodologies with the same example.

If you have established an ongoing relationship with the business and you are familiar with their business operations, starting with the LOB and user groups will ensure you cover all the services IT provides to the business and create more relatable service names.

Identifying LOB services using Info-Tech’s IT View method

If you want to understand what services IT provides to the Sales functional group, and you don’t have comprehensive knowledge of the department, you need to start with the IT perspective.

Info-Tech Insight

If you are concerned about the fact that people always associate a service with an application, you can include the application in the service name or description so users can find the service through a search function.

Group LOB services into functional groups as you did enterprise services into categories

3.1 Sample Line of Business Services Definitions – Functional Groups & Industry Examples

Like categories for enterprise services in Phase Two, LOB services are grouped into functional groups. Functional groups are the components of an organizational chart (HR, Finance, etc.) that are found in a company’s structure.

Functional Groups

Functional groups enable a clear view for business users of what services they need, while omitting services that do not apply to them. This does not overwhelm them, and provides them with only relevant information.

Industry Services

To be clear, industry services can be put into functional groups.

Info-Tech provides a few sample industry services (without their functional group) to give an idea of what LOB service is specific to these industries. Try to extrapolate from these examples to create LOB services for your business.

Use Info-Tech’s Sample LOB Services – Functional Group and Sample LOB Services – Industry Specific documents.

Info-Tech Insight

Keep track of which services you either modify or delete. You will have to change the same services in the final Info-Tech deliverable.

Identify the user group and business activity within each line of business – Business view

3.1 30-45 minutes per line of business

Only perform this activity if you have a relationship with the business that can enable you to generate business input on service identifications and definitions.

In a group of your project participants, repeat the sequence for each LOB.

1. Brainstorm each user group within the LOB that is creating value for the business by performing functional activities.
2. Think of what each individual end user must do to create their value. Think of the bigger picture rather than specifics at this point. For example, sales representatives must communicate with clients to create value.
3. Now that you have each user group and the activities they perform, consider the specifics of how they go about doing that activity. Consider each application they use and how much they use that application. Think of any and all IT services that could occur as a result of that application usage.

INPUT

• A collaborative discussion (with a business relationship)

OUTPUT

• LOB services defined from the business perspective

Materials

• Sticky notes
• Whiteboard/marker

Participants

• Members of the project team
• Representatives from the LOBs

Identify the user group and business activity within each line of business – IT view

3.1 30-45 minutes per application

Only perform this activity if you cannot generate business input through your relationships, and must begin service definitions with business applications.

In a group of your project participants, repeat the sequence for each application.

1. Brainstorm all applications that the business provides through IT. Cross out the ones that provide enterprise services.
2. In broad terms, think about what the application is accomplishing to create value for the business from IT’s perspective. What are the modules? Is it recording interactions with the clients? Each software can have multiple functionalities.
3. Narrow down each functionality performed by the application and think about how IT helps deliver that value. Create a name for the service that the users can relate to and understand.

→ Optional

4. Now go beyond the service and think about the business activities. They are always similar to IT’s application functionality, but from the user perspective. How would the user think about what the application’s functionality to accomplish that particular service is? At this point, focus on the service, not the application.
5. Determine the user groups for each service. This step will help you complete the service record design in phase 4. Keep in mind that multiple user groups may access one service.

INPUT

• A collaborative discussion (without a business relationship)

OUTPUT

• LOB services defined from the IT perspective

Materials

• Sticky notes
• Whiteboard/marker

Participants

• Members of the project team

You must review your LOB service definitions with the business before deployment

Coming up with LOB service definitions is challenging for IT because it requires comprehension of all lines of business within the organization as well as direct interaction with the business users.

After completing the LOB service definitions, IT must talk to the business to ensure all the user groups and business activities are covered and all the features are accurate.

Here are some tips to reviewing your LOB Service Catalog generated content:

• If you plan to talk to a business SME, plan ahead to help complete the project in time for rollout.
• Include a business relationship manager on the project team to facilitate discussion if you do not have an established relationship with the business.

Sample Meeting Agenda

Go through the service in batches. Present 5-10 related services to the business first. Start with the service name and then focus on the features.

In the meeting, discuss whether the service features accurately sum up the business activities, or if there are missing key activities. Also discuss whether certain services should be split up into multiple services or combined into one.

Organization identifies LOB services using Info-Tech’s methodologies

CASE STUDY A
Industry Government
Source Onsite engagement

Challenge

There were many users from different LOBs, and IT provided multiple services to all of them. Tracking them and who had access to what was difficult.

IT didn’t understand who provided the services (service owner) and who the customers were (business owner) for some of the services.

Solution

After identifying the different Lines of Business, they followed the first approach (Business View) for those that IT had sufficient knowledge of in terms of business operations:

1. Identified lines of business
2. Identified user groups
3. Identified business activities

For the LOBs they weren’t familiar with, they used the IT view method, beginning with the application:

1. Identified business apps
2. Deduced the functionalities of each application
3. Traced the application back to the service and identified the service owner and business owner

Results

Through these two methodologies, IT was able to define services according to how the users both perceive and utilize them.

IT was able to capture all the services it provides to each line of business effectively without too much help from the business representatives.

By capturing all enterprise services offered to the organization, IT centralized its management of services instead of having scattered request processes.

Info-Tech helps organization to identify LOB services using the IT View

CASE STUDY B
Industry Healthcare
Source Onsite engagement

Challenge
The organization uses a major application containing several modules used by different users for various business activities.

The challenge was to break down the application into multiple services in a way that makes sense to the business users. Users should be able to find services specific to them easily.

Therefore, the project team must understand how to map the modules to different services and user groups.

Solution
The project team identified the major lines of business and took various user groups such as nurses and doctors, figured out their daily tasks that require IT services, and mapped each user-facing service to the functionality of the application.

The project team then went back to the application to ensure all the modules and functionalities within the application were accounted for. This helped to ensure that services for all user groups were covered and prepared to be released in the catalog.

Results
Once the project team had come up with a comprehensive list of services for each line of business, they were able to sit with the business and review the services.

IT was also able to use this opportunity to demonstrate all the services it provides. Having all the LOB services demonstrates IT has done its preparation and can show the value they help create for the business in a language the users can understand. The end result was a strengthened relationship between the business and the IT department.

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:
3.1		Understand what Line of Business services are The onsite analysts will provide a clear distinction between enterprise services and LOB services. The analysts will also articulate the importance of validating LOB services with the business.
3.2		Identify LOB services using the business’ view There are two methods for coming up with LOB services. If IT has comprehensive knowledge of the business, they can identify the services by outlining the user groups and their business activities.
3.3		Identify LOB services using IT’s view If IT does not understand the business and cannot obtain business input, Info-Tech’s analysts will present the second method, which allows IT to identify services with more comfortability through business applications/systems.
3.4		Categorize the LOB services into functional groups The analysts will help the project team categorize the LOB services based on user groups or functional departments.

PHASE 4

Complete Service Definitions

Design & Build a User-Facing Service Catalog

Step 4: Complete service definitions and service record design

1. Complete the Project Charter
2. Create Enterprise Services Definitions
3. Create Line of Business Services Definitions
4. Complete Service Definitions

This step will walk you through the following activities:

• Select which fields of information you would like to include in your service catalog design.
• Determine which fields should be kept internal for IT use only.
• Complete the service record design with business input if possible.

Step Insights

• Don’t overcomplicate the service record design. Only include the pieces of information the users really need to see.
• Don’t publish anything that you don’t want to be held accountable for. If you are not ready, keep the metrics and costs internal.
• It is crucial to designate a facilitator and a decision maker so confusions and disagreements regarding service definitions can be resolved efficiently.

Phase 3 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.

Utilize Info-Tech’s Services Definition Chart to map out your final service catalog design

Info-Tech’s Sample Services Definition Chart

Info-Tech has provided a sample Services Definition Chart with standard service definitions and pre-populated fields. It is up to you throughout this step to decide which fields are necessary to your business users, as well as how much detail you wish to include in each of them.

Info-Tech Insight

Keep track of which services you either modify or delete. You will have to change the same services in the final Info-Tech deliverable.

Tips and techniques for service record design

The majority of the fields in the service catalog are user facing, which means they must be written in business language that the users can understand.

If there is any confusion or disagreement in filling out the fields, a facilitator is required to lead the working groups in coming up with a definitive answer. If a decision is still not reached, it should be escalated to the decision maker (usually the service owner).

IT-Facing Fields

There are IT facing fields that should not be published to the business users – they are for the benefit of IT. For example, you may want to keep Performance Metrics internal to IT until you are ready to discuss it with the business.

If the organization is interested in creating a Technical Service Catalog following this initiative, these fields will provide a helpful starting place for IT to identify the people, process, and technology required to support user-facing services.

Info-Tech Insight

It is important for IT-facing fields to be kept internal. If business users are having trouble with a service and the service owner’s name is available to them, they will phone them for support even if they are not the support owner.

Design your service catalog with business input: have the user in mind

When completing the service record, adopt the principle that “Less is More.” Keep it simple and write the service description from the user’s perspective, without IT language. From the list below, pick which fields of information are important to your business users.

What do the users need to access the service quickly and with minimal assistance?

Identify service overview

“What information must I have in each service record? What are the fundamentals required to define a service?”

Necessary Fields – Service Description:

• Service name → a title for the service that gives a hint of its purpose.
• Service description → what the service does and expected outcomes.
• Service features → describe functionality of the service.
• Service category → an intuitive way to group the service.
• Support services → applications/systems required to support the service.

Description: Delivers electronic messages to and from employees.

Features:

• Desk phone
• Teleconference phones (meeting rooms)
• Voicemail
• Recover deleted voicemails
• Team line: call rings multiple phones/according to call tree
• Employee directory
• Caller ID, Conference calling

Category: Communications

Identify owners

Who is responsible for the delivery of the service and what are their roles?

Service Owner and Business Owner

Service owner → the IT member who is responsible and accountable for the delivery of the service.

Business owner → the business partner of the service owner who ensures the provided service meets business needs.

Example: Time Entry

Service Owner: Manager of Business Solutions

Business Owner: VP of Human Resources

Info-Tech Insight

For enterprise services that are used by almost everyone in the organization, the business owner is the CIO.

Identify access policies and procedures

“Who is authorized to access this service? How do they access it?”

Access Policies & Procedures

Authorized users → who can access the service.

Request process → how to request access to the service.

Approval requirement/process → what the user needs to have in place before accessing the service.

Example: Guest Wi-Fi

Authorized Users: All people on site not working for the company

Request Process: Self-Service through website for external visitors

Approval Requirement/Process: N/A

Info-Tech Insight

Clearly defining how to access a service saves time and money by decreasing calls to the service desk and getting users up and running faster. The result is higher user productivity.

Identify access policies and procedures

“Who is authorized to access this service? How do they access it?”

Access Policies & Procedures

Requirements & pre-requisites → details of what must happen before a service can be provided.

Turnaround time → how much time it will take to grant access to the service.

User responsibility → What the user is expected to do to acquire the service.

Example: Guest Wi-Fi

Requirements & Pre-requisites: Disclaimer of non-liability and acceptance

Turnaround time: Immediate

User Responsibility: Adhering to policies outlined in the disclaimer

Info-Tech Insight

Clearly defining how to access a service saves time and money by decreasing calls to the service desk and getting users up and running faster. The result is higher user productivity.

Identify availability and service levels

“When is this service available to users? What service levels can the user expect?”

Availability & Service Levels

Support hours → what days/times is this service available to users?

Hours of availability/planned downtime → is there scheduled downtime for maintenance?

Performance metrics → what level of performance can the user expect for this service?

Example: Software Provisioning

Support Hours: Standard business hours

Hours of Availability/Planned Downtime: Standard business hours; can be agreed to work beyond operating hours either earlier or later

Performance Metrics: N/A

Info-Tech Insight

Manage user expectations by clearly documenting and communicating service levels.

Identify support policies and procedures

“How do I obtain support for this service?”

Support Policies & Procedures

Support process → what is the process for obtaining support for this service?

Support owner → who can users contact for escalations regarding this service?

Support documentation → where can users find support documentation for this service?

Example: Shared Folders

Support Process: Contact help desk or submit a ticket via portal

Support Owner: Manager, client support

Support Documentation: .pdf of how-to guide

Info-Tech Insight

Clearly documenting support procedures enables users to get the help they need faster and more efficiently.

Identify service costs and approvals

“Is there a cost for this service? If so, how much and who is expensing it?”

Costs

Internal Cost → do we know the total cost of the service?

Customer Cost → a lot of services are provided without charge to the business; however, certain service requests will be charged to a department’s budget.

Example: Hardware Provisioning

Internal Cost: For purposes of audit, new laptops will be expensed to IT.

Customer Cost: Cost to rush order 10 new laptops with retina displays for the graphics team. Charged for extra shipment cost, not for cost of laptop.

Info-Tech Insight

Set user expectations by clearly documenting costs associated with a service and how to obtain approval for these costs if required.

Complete the service record design fields for every service

4.1 3 Hours

This is the final activity to completing the service record design. It has been a long journey to make it here; now, all that is left is completing the fields and transferring information from previous activities.

1. Organize the services however you think is most appropriate. A common method of organization is alphabetically by enterprise category, and then each LOB functional group.
2. Determine which fields you would like to keep or edit to be part of your design. Also add any other fields you can think of which will add value to the user or IT. Remember to keep them IT facing if necessary.
3. Complete the fields for each service one by one. Keep in mind that for some services, a field or two may not apply to the nature of that service and may be left blank or filled with a null value (e.g. N/A).

INPUT

• A collaborative discussion

OUTPUT

• Completed service record design ready for a catalog

Materials

• Info-Tech sample service record design.

Participants

• Project stakeholders, business representatives

Info-Tech Insight

Don’t forget to delete or bring over the edited LOB and Enterprise services from the phase 2 and 3 deliverables.

Complete the service definitions and get them ready for publication

Now that you have completed the first run of service definitions, you can go back and complete the rest of the identified services in batches. You should observe increased efficiency and effectiveness in filling out the service definitions.

This blueprint’s purpose is to help you design a service catalog. There are a number of different platforms to build the catalog offered by application vendors. The sophistication of the catalog depends on the size of your business. It may be as simple as an Excel book, or something as complex as a website integrated with your service desk.

Determine how you want to publish the service catalog

There are various levels of maturity to consider when you are thinking about how to deploy your service catalog.

Organization uses the service catalog to outline IT’s and users’ responsibilities

CASE STUDY A
Industry Government
Source Onsite engagement

Challenge

The client had collected a lot of good information, but they were not sure about what to include to ensure the users could understand the service clearly.

They were also not sure what to keep internal so the service catalog did not increase IT’s workload. They want to help the business, but not appear as if they are capable of solving everything for everyone immediately. There was a fear of over-commitment.

Solution

The government created a Customer Responsibility field for each service, so it was not just IT who was providing solutions. Business users needed to understand what they had to do to receive some services.

The Service Owner and Business Owner fields were also kept internal so users would go through the proper request channel instead of calling Service Owners directly.

Lastly, the Performance Metrics field was kept internal until IT was ready to present service metrics to the business.

Results

The business was provided clarity on their responsibility and what was duly owed to them by IT staff. This established clear boundaries on what was to be expected of IT services projected into the future.

The business users knew what to do and how to obtain the services provided to them. In the meantime, they didn’t feel overwhelmed by the amount of information provided by the service catalog.

Organization leverages the service catalog as a tool to define IT workflows and business processes

CASE STUDY B
Industry Healthcare
Source Onsite engagement

Challenge

There is a lack of clarity and a lack of agreement between the client’s team members regarding the request/approval processes for certain services. This was an indication that there is a level of ambiguity around process. Members were not sure what was the proper way to access a service and could not come up with what to include in the catalog.

Different people from different teams had different ways of accessing services. This could be true for both enterprise and LOB services.

Solution

The Info-Tech analyst facilitated a discussion about workflows and business processes.

In particular, the discussion focused around the approval/authorization process, and IT’s workflows required to deliver the service. The Info-Tech analyst on site walked the client through their different processes to determine which one should be included in the catalog.

Results

The discussion brought clarity to the project team around both IT and business process. Using this new information, IT was able to communicate to the business better, and create consistency for IT and the users of the catalog.

The catalog design was a shared space where IT and business users could confer what the due process and responsibilities were from both sides. This increased accountability for both parties.

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:
4.1		Determine which fields should be included in the record design The analysts will present the sample service definitions record and facilitate a discussion to customize the service record so unique business needs are captured.
4.2		Determine which fields should be kept internal The onsite analysts will explain why certain fields are used but not published. The analysts will help the team determine which fields should be kept internal.
4.3		Complete the service definitions The Info-Tech analysts will help the group complete the full service definitions. This exercise will also provide the organization with a clear understanding of IT workflows and business processes.

Summary of accomplishment

Knowledge Gained

• Understanding why it is important to identify and define services from the user’s perspective.
• Understand the differences between enterprise services and line of business services.
• Distinguish service features from services.
• Involve the business users to define LOB services using either IT’s view or LOB’s view.

Processes Optimized

• Enterprise services identification and documentation.
• Line of business services identification and documentation.

Deliverables Completed

• Service catalog project charter
• Enterprise services definitions
• Line of business service definitions – functional groups
• Line of business service definitions – industry specific
• Service definition chart

Project step summary

Client Project: Design and Build a User-Facing Service Catalog

1. Launch the Project – Maximize project success by assembling a well-rounded team and managing all important stakeholders.
2. Identify Enterprise Services – Identify services that are used commonly across the organization and categorize them in a user-friendly way.
3. Identify Line of Business Services – Identify services that are specific to each line of business using one of two Info-Tech methodologies.
4. Complete the Service Definitions – Determine what should be presented to the users and complete the service definitions for all identified services.

Info-Tech Insight

This project has the ability to fit the following formats:

• Onsite workshop by Info-Tech Research Group consulting analysts.
• Do-it-yourself with your team.
• Remote delivery (Info-Tech Guided Implementation).

Related Info-Tech research

Establish a Service-Based Costing Model

Develop the right level of service-based costing capability by applying our methodology.

Design and Build an Effective Contract Lifecycle Management Process

Mitigate risk and drive value through robust best practices for contract lifecycle management.

Our understanding of the problem

This Research Is Designed For:

• The CIO who depends on numerous key vendors for services
• The CIO or Project Manager who wants to maximize the value delivered by vendors
• The Director or Manager of an existing IT procurement or vendor management team
• The Contracts Manager or Legal Counsel whose IT department holds responsibility for contracts, negotiation, and administration

This Research Will Help You:

• Implement and streamline the contract management process, policies, and procedures
• Baseline and benchmark existing contract processes
• Understand the importance and value of contract lifecycle management (CLM)
• Minimize risk, save time, and maximize savings with vendor contracts

This Research Will Also Assist

• IT Service Managers
• IT Procurement
• Contract teams
• Finance and Legal departments
• Senior IT leadership

This Research Will Help Them

• Understand the required components of a CLM
• Establish the current CLM maturity level
• Implement a new CLM process
• Improve on an existing or disparate process

ANALYST PERSPECTIVE

"Contract lifecycle management (CLM) is a vital process for small and enterprise organizations alike. Research shows that all organizations can benefit from a contract management process, whether they have as few as 25 contracts or especially if they have contracts numbering in the hundreds.

A CLM system will:

• Save valuable time in the entire cycle of contract/agreement processes.
• Save the organization money, both hard and soft dollars.
• Mitigate risk to the organization.
• Avoid loss of revenue.

If you’re not managing your contracts, you aren’t capitalizing on your investment with your vendors and are potentially exposing your organization to contract and monetary risk."

- Ted Walker
Principal Research Advisor, Vendor Management Practice
Info-Tech Research Group

Executive Summary

Situation

• Most organizations have vendor overload and even worse, no defined process to manage the associated contracts and agreements. To manage contracts, some vendor management offices (VMOs) use a shared network drive to store the contracts and a spreadsheet to catalog and manage them. Yet other less-mature VMOs may just rely on a file cabinet in Procurement and a reminder in someone’s calendar about renewals. These disparate processes likely cost your organization time spent finding, managing, and renewing contracts, not to mention potential increases in vendor costs and risk and the inability to track contract obligations.

Complication

• Contract lifecycle management (CLM) is not an IT buzzword, and it’s rarely on the top-ten list of CIO concerns in most annual surveys. Until a VMO gets to a level of maturity that can fully develop a CLM and afford the time and costs of doing so, there can be several challenges to developing even the basic processes required to store, manage, and renew IT vendor contracts. As is always an issue in IT, budget is one of the biggest obstacles in implementing a standard CLM process. Until senior leadership realizes that a CLM process can save time, money, and risk, getting mindshare and funding commitment will remain a challenge.

Resolution

• Understand the immediate benefits of a CLM process – even a basic CLM implementation can provide significant cost savings to the organization; reduce time spent on creating, negotiating, and renewing contracts; and help identify and mitigate risks within your vendor contracts.
• Budgets don’t always need to be a barrier to a standard CLM process. However, a robust CLM system can provide significant savings to the organization.

Info-Tech Insight

• If you aren’t managing your contracts, you aren’t capitalizing on your investments.
• Even a basic CLM process with efficient procedures will provide savings and benefits.
• Not having a CLM process may be costing your organization money, time, and exposure to unmitigated risk.

What you can gain from this blueprint

Why Create a CLM

• Improved contract organization
• Centralized and manageable storage/archives
• Improved vendor compliance
• Risk mitigation
• Reduced potential loss of revenue

Knowledge Gained

• Understanding of the value and importance of a CLM
• How CLM can impact many departments within the organization
• Who should be involved in the CLM steps and processes
• Why a CLM is important to your organization
• How to save time and money by maximizing IT vendor contracts
• How basic CLM policies and procedures can be implemented without costly software expenditure

The Outcome

• A foundation for a CLM with best-practice processes
• Reduced exposure to potential risks within vendor contracts
• Maximized savings with primary vendors
• Vendor compliance and corporate governance
• Collaboration, transparency, and integration with business units

Contract management: A case study

CASE STUDY
Industry Finance and Banking
Source Apttus

FIS Global

The Challenge

FIS’ business groups were isolated across the organization and used different agreements, making contract creation a long, difficult, and manual process.

• Customers frustrated by slow and complicated contracting process
• Manual contract creation and approval processes
• Sensitive contract data that lacked secure storage
• Multiple agreements managed across divisions
• Lack of central repository for past contracts
• Inconsistent and inaccessible

The Solution: Automating and Streamlining the Contract Management Process

A robust CLM system solved FIS’ various contract management needs while also providing a solution that could expand into full quote-to cash in the future.

• Contract lifecycle management (CLM)
• Intelligent workflow approvals (IWA)
• X-Author for Excel

Customer Results

• 75% cycle time reduction
• $1M saved in admin costs per year
• 49% increase in sales proposal volume
• Automation on one standard platform and solution
• 55% stronger compliance management
• Easy maintenance for various templates
• Ability to quickly absorb new contracts and processes via FIS’s ongoing acquisitions

Track the impact of CLM with these metrics

The numbers are compelling

71%

of companies can’t locate up to 10% of their contracts.

Source: TechnologyAdvice, 2019

9.2%

of companies’ annual revenue is lost because of poor contract management practices.

Source: IACCM, 2019

60%

still track contracts in shared drives or email folders.

Source: “State of Contract Management,” SpringCM, 2018

CLM blueprint objectives

• To provide a best-practice process for managing IT vendor contract lifecycles through a framework that organizes from the core, analyzes each step in the cycle, has collaboration and governance attached to each step, and integrates with established vendor management practices within your organization.
• CLM doesn’t have to be an expensive managed database system in the cloud with fancy dashboards. As long as you have a defined process that has the framework steps and is followed by the organization, this will provide basic CLM and save the organization time and money over a short period of time.
• This blueprint will not delve into the many vendors or providers of CLM solutions and their methodologies. However, we will discuss briefly how to use our framework and contract stages in evaluating a potential solution that you may be considering.

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

Design and Build an Effective CLM Process – project overview

Workshop overview

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

PHASE 1

Master the Operational Framework of Contract Lifecycle Management

Design and Build an Effective CLM Process

Phase 1: Master the Operational Framework of Contract Lifecycle Management

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.

What Is Contract Lifecycle Management?

• Every contract has a lifecycle, from creation to time and usage to expiration. Organizations using a legacy or manual contract management process usually ask, “What is contract lifecycle management and how will it benefit my business?”
• Contract lifecycle management (CLM) creates a process that manages each contract or agreement. CLM eases the challenges of managing hundreds or even thousands of important business and IT contracts that affect the day-to-day business and could expose the organization to vendor risk.
• Managing a few contracts is quite easy, but as the number of contracts grows, managing each step for each contract becomes increasingly difficult. Ultimately, it will get to a point where managing contracts properly becomes very difficult or seemingly impossible.

That’s where contract lifecycle management (CLM) comes in.

CLM can save money and improve revenue by:

• Improving accuracy and decreasing errors through standardized contract templates and approved terms and conditions that will reduce repetitive tasks.
• Securing contracts and processes through centralized software storage, minimizing risk of lost or misplaced contracts due to changes in physical assets like hard drives, network shares, and file cabinets.
• Using policies and procedures that standardize, organize, track, and optimize IT contracts, eliminating time spent on creation, approvals, errors, and vendor compliance.
• Reducing the organization’s exposure to risks and liability.
• Having contracts renewed on time without penalties and with the most favorable terms for the business.

The Operational Framework of Contract Lifecycle Management

Four Components of the Operational Framework

1. Organization
2. Analysis
3. Collaboration and Governance
4. Integration/Vendor Management

• By organizing at the core of the process and then analyzing each stage, you will maximize each step of the CLM process and ensure long-term contract management for the organization.
• Collaboration and governance as overarching policies for the system will provide accountability to stakeholders and business units.
• Integration and vendor management are encompassing features in a well-developed CLM that add visibility, additional value, and savings to the entire organization.

Info-Tech Best Practice

Putting a contract manager in place to manage the CLM project will accelerate the improvements and provide faster returns to the organizations. Reference Info-Tech’s Contract Manager Job Description template as needed.

The operational framework is key to the success, return on investment (ROI), cost savings, and customer satisfaction of a CLM process.

1. Organization

• Every enterprise needs to organize its contract documents and data in a central repository so that everyone knows where to find the golden source of contractual truth.
• This includes:
• A repository for storing and organizing contract documents.
• A data dictionary for describing the terms and conditions in a consistent, normalized way.
• A database for persistent data storage.
• An object model that tracks changes to the contract and its prevailing terms over time.

Info-Tech Insight

Paper is still alive and doing very well at slowing down the many stages of the contract process.

2. Analysis

Most organizations analyze their contracts in two ways:

• First, they use reporting, search, and analytics to reveal risky and toxic terms so that appropriate operational strategies can be implemented to eliminate, mitigate, or transfer the risk.
• Second, they use process analytics to reveal bottlenecks and points of friction as contracts are created, approved, and negotiated.

3. Collaboration

• Throughout the contract lifecycle, teams must collaborate on tasks both pre-execution and post-execution.
• This includes document collaboration among several different departments across an enterprise.
• The challenge is to make the collaboration smooth and transparent to avoid costly mistakes.
• For some contracting tasks, especially in regulated industries, a high degree of control is required.
• In these scenarios, the organization must implement controlled systems that restrict access to certain types of data and processes backed up with robust audit trails.

4. Integration

• For complete visibility into operational responsibilities, relationships, and risk, an organization must integrate its golden contract data with other systems of record.
• An enterprise contracts platform must therefore provide a rich set of APIs and connectors so that information can be pushed into or pulled from systems for enterprise resource planning (ERP), customer relationship management (CRM), supplier relationship management (SRM), document management, etc.

This is the ultimate goal of a robust contract management system!

Member Activity: Document Current CLM Processes

1.1 Completion Time: 1-5 days

Goal: Document your existing CLM processes (if any) and who owns them, who manages them, etc.

Instructions

Interview internal business unit decision makers, stakeholders, Finance, Legal, CIO, VMO, Sales, and/or Procurement to understand what’s currently in place.

1. Use the Existing CLM Process Worksheet to capture and document current CLM processes.
2. Establish what processes, procedures, policies, and workflows, if any, are in place for pre-execution (Phase 1) contract stages.
3. Do the same for post-execution (Phase 2) stages.
4. Use this worksheet as reference for assessments and as a benchmark for improvement review six to 12 months later.

INPUT

• Internal information from all CLM stakeholders

OUTPUT

• A summary of processes and owners currently in place

Materials

• Existing CLM processes from interviews

Participants

• Finance, Legal, CIO, VMO, Sales, Procurement

PHASE 2

Understand the Ten Stages of Contract Lifecycle Management

Design and Build an Effective CLM Process

Phase 1: Master the Operational Framework of Contract Lifecycle Management

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.

The Ten Stages of Contract Lifecycle Management

There are ten key stages of contract lifecycle management.

The steps are divided into two phases, pre-execution and post-execution.

Pre-Execution (Phase 1)

1. Request
2. Create
3. Review Risk
4. Approve
5. Negotiate
6. Sign

Post-Execution (Phase 2)

7. Capture
8. Manage
9. Monitor Compliance
10. Optimize

Ten Process Stages Within the CLM Framework

Stage 1: Request or Initiate

Contract lifecycle management begins with the contract requesting process, where one party requests for or initiates the contracting process and subsequently uses that information for drafting or authoring the contract document. This is usually the first step in CLM.

Requests for contracts can come from various sources:

• Business units within the organization
• Vendors presenting their contract, including renewal agreements
• System- or process-generated requests for renewal or extension

At this stage, you need to validate if a non-disclosure agreement (NDA) is currently in place with the other party or is required before moving forward. At times, adequate NDA components could be included within the contract or agreement to satisfy corporate confidentiality requirements.

Stage 1: Request or Initiate

Stage Input

• Information about what the contract needs to contain, such as critical dates, term length, coverage, milestones, etc.
• Some organizations require that justification and budget approval be provided at this stage.
• Request could come from a vendor as a pre-created contract.
• Best practices recommend that a contract request form or template is used to standardize all required information.

Stage Output

• Completed request form, stored or posted with all details required to move forward to risk review and contract creation.
• Possible audit trails.

Stage 2: Create Contract

• At the creation or drafting stage, the document is created, generated, or provided by the vendor. The document will contain all clauses, scope, terms and conditions, and pricing as required.
• In some cases, a vendor-presented contract that is already prepared will go through an internal review or redlining process by the business unit and/or Legal.
• Both internal and external review and redlining are included in this stage.
• Also at this stage, the approvers and signing authorities are identified and added to the contract. In addition, some audit trail features may be added.

Info-Tech Best Practice

For a comprehensive list of terms and conditions, see our Software Terms & Conditions Evaluation Tool within Master Contract Review and Negotiation for Software Agreements.

Stage 2: Create Contract

Stage Input

• Contract request form, risk review/assessment.
• Vendor- or contractor-provided contract/agreement, either soft copy, electronic form, or more frequently, “clickwrap” web-posted document.
• Could also include a renewal notification from a vendor or from the CLM system or admin.

Stage Output

• Completed draft contract or agreement, typically in a Microsoft Word or Adobe PDF format with audit trail or comment tracking.
• Redlined document for additional revision and or acceptance.
• Amendment or addendum to existing contract.

Stage 3: Review Risk 1 of 2

The importance of risk review can not be understated. The contract or agreement must be reviewed by several stakeholders who can identify risks to the organization within the contract.

Three important definitions:

1. Risk is the potential for a negative outcome. A risk is crossing the street while wearing headphones and selecting the next track to play on your smartphone. A negative outcome is getting hit by an oncoming person who, unremarkably, was doing something similar at the same time.
2. Risk mitigation is about taking the steps necessary to minimize both the likelihood of a risk occurring – look around both before and while crossing the street – and its impact if it does occur – fall if you must, but save the smartphone!
3. Contract risk is about any number of situations that can cause a contract to fail, from trivially – the supplier delivers needed goods late – to catastrophically – the supplier goes out of business without having delivered your long-delayed orders.

Stage 3: Review Risk 2 of 2

• Contracts must be reviewed for business terms and conditions, potential risk situations from a financial or legal perspective, business commitments or obligations, and any operational concerns.
• Mitigating contract risk requires a good understanding of what contracts are in place, how important they are to the success of the organization, and what data they contain.

Collectively, this is known as contract visibility.

• Risk avoidance and mitigation are also a key component in the ROI of a CLM system and should be tracked for analysis.
• Risk-identifying forms or templates can be used to maintain consistency with corporate standards.

Stage 3: Review Risk

Stage Input

• All details of the proposed contract so that a proper risk analysis can be done as well as appropriate review with stakeholders, including:
  • Finance
  • Legal
  • Procurement
  • Security
  • Line-of-business owner
  • IT stakeholders

Stage Output

• A list of identified concerns that could expose the business unit or organization.
• Recommendations to minimize or eliminate identified risks.

Stage 4: Approve

The approval stage can be a short process if policies and procedures are already in place. Most organizations will have defined delegation of authority or approval authority depending on risk, value of the contract, and other corporate considerations.

• Defined approval levels should be known within the organization and can be applied to the approval workflow, expediting the approval of drafted terms, conditions, changes, and cost/spend within the contract internally.
• Tracking and flexibility needs to considered in the approval process.
• Gates need to be in place to ensure that a required approver has approved the contract before it moves to the next approver.
• Flexibility is needed in some situations for ad hoc approval tasks and should include audit trail as required.
• Approvers can include business units, Finance, Legal, Security, and C-level leaders

Stage 4: Approve

Stage Input

• Complete draft contract with all terms and conditions (T&Cs) and approval trail.
• Amendment or addendum to existing contract.

Stage Output

• Approved draft contract ready to move to the next step of negotiating with the vendor.
• Approved amendment or addendum to existing or renewal agreement.

Stage 5: Negotiate

• At this stage, there should be an approved draft of the contract that can be presented to the other party or vendor for review.
• Typically organizations will negotiate their larger deals for terms and conditions with the goal of balancing the contractual allocation of risk with the importance of the vendor or agreement and its value to the business.
• Several people on either side are typically involved and will discuss legal and commercial terms of the contract. Throughout the process, negotiators may leverage a variety of tools, including playbooks with preferred and fallback positions, clause libraries, document redlines and comparisons, and issue lists.

• Audit trails or tracking of changes and acceptances is an important part of this stage. Tracking will avoid duplication and lost or missed changes and will speed up the entire process.
• A final, clean document is created at this point and readied for execution.

Stage 5: Negotiate

Stage Input

• Approved draft contract ready to move to the next step of negotiating with the vendor.
• Approved amendment or addendum to existing or renewal agreement.

Stage Output

• A finalized and approved contract or amendment with agreed-upon terms and conditions ready for signatures.

Info-Tech Insight

Saving the different versions of a contract during negotiations will save time, provide reassurance of agreed terms as you move through the process, and provide reference for future negotiations with the vendor.

Stage 6: Sign or Execute

• At this stage in the process, all the heavy lifting in a contract’s creation is complete. Now it’s signature time.
• To finalize the agreement, both parties need to the sign the final document. This can be done by an in-person wet ink signature or by what is becoming more prevalent, digital signature through an e-signature process.
• Once complete, the final executed documents are exchanged or received electronically and then retained by each party.

Stage 6: Sign or Execute

Stage Input

• A finalized and approved contract or amendment with agreed-upon terms and conditions ready for signatures.

Stage Output

• An executed contract or amendment ready to move to the next stage of CLM, capturing in the repository.

Info-Tech Best Practice

Process flow provisions should made for potential rejection of the contract by signatories, looping the contract back to the appropriate stage for rework or revision.

Stage 7: Capture in Database/Repository 1 of 2

• This is one of the most important stages of a CLM process. Executed agreements need to be stored in a single manageable, searchable, reportable, and centralized repository.
• All documents should to be captured electronically, reviewed for accuracy, and then posted to the CLM repository.
• The repository can be in various formats depending on the maturity, robustness, and budget of the CLM program.

Most repositories are some type of database:

• An off-the-shelf product
• A PaaS cloud-based solution
• A homegrown, internally developed database
• An add-on module to your ERP system

Stage 7: Capture in Database/Repository 2 of 2

Several important features of an electronic repository should be considered:

• Consistent metadata tagging of clauses, terms, conditions, dates, etc.
• Centralized summary view of all contracts
• Controlled access for those who need to review and manage the contracts

Establishing an effective repository will be key to providing measurable value to the organization and saving large amounts of time for the business unit.

Info-Tech Insight

Planning for future needs by investing a little more money into a better, more robust repository could pay bigger dividends to the VMO and organization while providing a higher ROI over time as advanced functionality is deployed.

Stage 8: Manage

• Once an agreement is captured in the repository, it needs to be managed from both an operational and a commitment perspective.
• Through a summary view or master list, contracts need to be operationally managed for end dates and renewals, vendor performance, discounts, and rebates.
• Managing contracts for commitment and compliance will ensure all contract requirements, rights, service-level agreements (SLAs), and terms are fulfilled. This will eliminate the high costs of missed SLAs, potential breaches, or missed renewals.
• Managing contracts can be improved by adding metadata to the records that allow for easier search and retrieval of contracts or even proactive notification.

• The repository management features can and should be available to business stakeholders, or reporting from a CLM admin can also alert stakeholders to renewals, pricing, SLAs, etc.
• Also important to this stage is reporting. This can be done by an admin or via a self-serve feature for stakeholders, or it could even be automated.

Stage 9: Monitor Compliance 1 of 2

• At this stage, the contracts or agreements need to be monitored for the polices within them and the purpose for which they were signed.
• This is referred to as obligation management and is a key step to providing savings to the organization and mitigating risk.
• Many contracts contain commitments by each party. These can include but are not limited to SLAs, service uptime targets, user counts, pricing threshold discounts and rebates, renewal notices to vendors, and training requirements.
• All of these obligations within the contracts should be summarized and monitored to ensure that all commitments are delivered on. Managing obligations will mitigate risks, maximize savings and rebates to the organization, and minimize the potential for a breach within the contract.

Stage 9: Monitor Compliance 2 of 2

• Monitoring and measuring vendor commitments and performance will also be a key factor in maximizing the benefits of the contract through vendor accountability.
• Also included in this stage is renewal and/or disposition of the contract. If renewal is due, it should go back to the business unit for submission to the Stage 1: Request process. If the business unit is not going to renew the contract, the contract must be tagged and archived for future reference.

Stage 10: Optimize

• The goal of this stage is to improve the other stages of the process as well as evaluate how each stage is integrating with the core operational framework processes.
• With more data and improved insight into contractual terms and performance, a business can optimize its portfolio for better value, greater savings, and lower-risk outcomes.
• For high-performance contract teams, the goal is a continuous feedback loop between the contract portfolio and business performance. If, for example, the data shows that certain negotiation issues consume a large chunk of time but yield no measurable difference in risk or performance, you may tweak the playbook to remedy those issues quickly.

Additional optimization tactics:

• Streamlining contract renewals with auto-renew
• Predefined risk review process or template, continuous review/improvement of negotiation playbook
• Better automation or flow of approval process
• Better signature delegation process if required
• Improving repository search with metadata tagging
• Automating renewal tracking or notice process
• Tracking the time a contract spends in each stage

Establish Your Current CLM Maturity Position

• Sometimes organizations have a well-defined pre-execution process but have a poor post-signature process.
• Identifying your current processes or lack thereof will provide you with a starting point in developing a plan for your CLM. It’s possible that most of the stages are there and just need some improvements, or maybe some are missing and need to be implemented.
• It’s not unusual for organizations to have a manual pre-execution process and an automated backend repository with compliance and renewal notices features.

Info-Tech Best Practice

Use the CLM Maturity Assessment Tool to outline where your organization is at each stage of the process.

Member Activity: Assess Current CLM Maturity

2.1 Completion Time 1-2 days

Goal: Identify and measure your existing CLM processes, if any, and provide a maturity value to each stage. The resulting scores will provide a maturity assessment of your CLM.

Instructions

1. Use the Existing CLM Process Worksheet to document current CLM processes.
2. Using the CLM worksheet info, answer the questions in the CLM Maturity Assessment Tool.
3. Review the results and scores on Tab 3 to see where you need to focus your initial improvements.
4. Save the initial assessment for future reference and reassess in six to 12 months to measure progress.

INPUT

• Internal information from all CLM stakeholders

OUTPUT

• A summary of processes and owners currently in place in the organization

Materials

• Existing CLM processes from interviews

Participants

• Finance, Legal, CIO, VMO, Sales, Procurement

Member Activity: Complete RASCI Chart

2.2 Completion Time 2-6 hours

Goal: Identify who in your organization is primarily accountable and involved in each stage of the CLM process.

Instructions

Engage internal business unit decision makers, stakeholders, Finance, Legal, CIO, VMO, Sales, and Procurement as required to validate who should be involved in each stage.

1. Using the information collected from internal reviews, assign a level in the CLM RASCI Diagram to each team member.
2. Use the resulting RASCI diagram to guide you through developing or improving your CLM stages.

INPUT

• Internal interview information

OUTPUT

• Understanding of who is involved in each CLM stage

Materials

• Interview data
• RASCI Diagram

Participants

• Finance, Legal, CIO, VMO, Sales, Procurement

Applying CLM Framework and Stages to Your Organization

• Understand what CLM process you currently do or do not have in place.
• Review implementation options: automated, semi-automated, and manual solutions.
• If you are improving an existing process, focus on one phase at a time, perfect it, and then move to the other phase. This can also be driven by budget and time.
• Create a plan to start with and then move to automating or semi-automating the stages.
• Building onto or enhancing an existing system or processes can be a cost-effective method to produce near-term measurable savings
• Focus on one phase at a time, then move on to the other phase.
• While reviewing implementation of or improvements to CLM stages, be sure to track or calculate the potential time and cost savings and risk mitigation. This will help in any required business case for a CLM.

CLM: An ROI Discussion 1 of 2

• ROI can be easier to quantify and measure in larger organizations with larger CLM, but ROI metrics can be obtained regardless of the company or CLM size.
• Organizations recognize their ROI through gains in efficiency across the entire business as well as within individual departments involved in the contracting process. They also do so by reducing the risk associated with decentralized and insecure storage of and access to their contracts, failure to comply with terms of their contracts, and missing deadlines associated with contracts.

Just a few of the factors to consider within your own organization include:

• The number of people inside and outside your company that touch your contracts.
• The number of hours spent weekly, monthly, and annually managing contracts.
• Potential efficiencies gained in better managing those contracts.
• The total number of contracts that exist at any given time.
• The average value and total value of those contract types.
• The potential risk of being in breach of any of those contracts.
• The number of places contracts are stored.
• The level of security that exists to prevent unauthorized access.
• The potential impact of unauthorized access to your sensitive contract data.

CLM: An ROI Discussion 2 of 2

Decision-Maker Apprehensions

Decision-maker concerns arise from a common misunderstanding – that is, a fundamental failure to appreciate the true source of contract management value. This misunderstanding goes back many years to the time when analysts first started to take an interest in contract management and its automation. Their limited experience (primarily in retail and manufacturing sectors) led them to think of contract management as essentially an administrative function, primarily focused on procurement of goods. In such environments, the purpose of automation is focused on internal efficiency, augmented by the possibility of savings from reduced errors (e.g. failing to spot a renewal or expiry date) or compliance (ensuring use of standard terms).

Today’s CLM systems and processes can provide ROI in several areas in the business.

Info-Tech Insight

Research on ROI of CLM software shows significant hard cost savings to an organization. For example, a $10 million company with 300 contracts valued at $3 million could realize savings of $83,400 and avoid up to $460,000 in lost revenues. (Derived from: ACCDocket, 2018)

Additional Considerations 1 of 2

Who should own and/or manage the CLM process within an organization? Legal, VMO, business unit, Sales?

This is an often-discussed question. Research suggests that there is no definitive answer, as there are several variables.

Organizations needs to review what makes the best business sense for them based on several considerations and then decide where CLM belongs.

• Business unit budgets and time management
• Available Administration personnel and time
• IT resources
• Security and access concerns
• Best fit based on organizational structure

35% of law professionals feel contract management is a legal responsibility, while 45% feel it’s a business responsibility and a final 20% are unsure where it belongs. (Source: “10 Eye-Popping Contract Management Statistics,” Apttus, 2018)

Additional Considerations 2 of 2

What type of CLM software or platform should we use?

This too is a difficult question to answer definitively. Again, there are several variables to consider. As well, several solutions are available, and this is not a one-size-fits-all scenario.

As with who should own the CLM process, organizations must review the various CLM software solutions available that will meet their current and future needs and then ask, “What do we need the system to do?”

• Do you build a “homegrown” solution?
• Should it be an add-on module to the current ERP or CRM system?
• Is on-premises more suitable?
• Is an adequate off-the-shelf (OTS) solution available?
• What about the many cloud offerings?
• Is there a basic system to start with that can expand as you grow?

Info-Tech Insight

When considering what type of solution to choose, prioritize what needs to been done or improved. Sometimes solutions can be deployed in phases as an “add-on” type modules.

Summary of Accomplishment

Knowledge Gained

• Documented current CLM process
• Core operational framework to build a CLM process on
• Understanding of best practices required for a sustainable CLM

Processes Optimized

• Internal RASCI process identified
• Existing internal stage improvements
• Internal review process for risk mitigation

Deliverables Completed

• Existing CLM Processes Worksheet
• CLM Maturity Assessment
• CLM RASCI Chart
• CLM improvement plan

Project Step Summary

Client Project: CLM Assessment and Improvement Plan

1. Set your goals – what do you want to achieve in your CLM project?
2. Assess your organization’s current CLM position in relation to CLM best practices and stages.
3. Map your organization’s RASCI structure for CLM.
4. Identify opportunities for stage improvements or target all low stage assessments.
5. Prioritize improvement processes.
6. Track ROI metrics.
7. Develop a CLM implementation or improvement plan.

Info-Tech Insight

This project can fit your organization’s schedule:

• Do-it-yourself with your team.
• Remote delivery (Info-Tech Guided Implementation).

CLM Blueprint Summary and Conclusion

• Contract management is a vital component of a responsible VMO that will benefit all business units in an organization, save time and money, and reduce risk exposure.
• A basic well-deployed and well-managed CLM will provide ROI in the short term.
• Setting an improvement plan with concise improvements and potential cost savings based on process improvements will help your business case for CLM get approval and leadership buy-in.
• Educating and aligning all business units and stakeholders to any changes to CLM processes will ensure that cost savings and ROI are achieved.
• When evaluating a CLM software solution, use the operational framework and the ten process stages in this blueprint as a reference guide for CLM vendor functionality and selection.

Related Info-Tech Research

Master Contract Review and Negotiation

Optimize spend with significant cost savings and negotiate from a position of strength.

Manage Your Vendors Before They Manage You

Maximize the value of vendor relationships.

Bibliography

Burla, Daniel. “The Must Know Of Transition to Dynamics 365 on Premise.” Sherweb, 14 April 2017. Web.

Anand, Vishal, “Strategic Considerations in Implementing an End-to-End Contract Lifecycle Management Solution.” DWF Mindcrest, 20 Aug. 2016. Web.

Alspaugh, Zach. “10 Eye-Popping Contract Management Statistics from the General Counsel’s Technology Report.” Apttus, 23 Nov. 2018. Web.

Bishop, Randy. “Contract Management is not just a cost center.” ContractSafe, 9 Sept. 2019. Web.

Bryce, Ian. “Contract Management KPIs - Measuring What Matters.” Gatekeeper, 2 May 2019. Web.

Busch, Jason. “Contract Lifecycle Management 101.” Determine. 4 Jan. 2018. Web.

“Contract Management Software Buyer's Guide.” TechnologyAdvice, 5 Aug. 2019. Web.

Dunne, Michael. “Analysts Predict that 2019 will be a Big Year for Contract Lifecycle Management.” Apttus, 19 Nov. 2018. Web.

“FIS Case Study.” Apttus, n.d. Web.

Gutwein, Katie. “3 Takeaways from the 2018 State of Contract Management Report.” SpringCM, 2018. Web.

“IACCM 2019 Benchmark Report.” IAACM, 4 Sept. 2019. Web.

Linsley, Rod. “How Proverbial Wisdom Can Help Improve Contract Risk Mitigation.” Gatekeeper, 2 Aug. 2019. Web.

Mars, Scott. “Contract Management Data Extraction.” Exari, 20 June 2017. Web.

Rodriquez, Elizabeth. “Global Contract Life-Cycle Management Market Statistics and Trends 2019.” Business Tech Hub, 17 June 2017. Web.

“State of Contract Management Report.” SpringCM, 2018. Web.

Teninbaum, Gabriel, and Arthur Raguette. “Realizing ROI from Contract Management Technology.” ACCDocket.com, 29 Jan. 2018. Web.

Wagner, Thomas. “Strategic Report on Contract Life cycle Management Software Market with Top Key Players- IBM Emptoris, Icertis, SAP, Apttus, CLM Matrix, Oracle, Infor, Newgen Software, Zycus, Symfact, Contract Logix, Coupa Software.” Market Research, 21 June 2019. Web.

“What is Your Contract Lifecycle Management (CLM) Persona?” Spend Matters, 19 Oct. 2017. Web.

Document Your Cloud Strategy

Get ready for the cloudy future with a consistent, proven strategy.

Analyst perspective

Any approach is better than no approach

Moving to the cloud is a big, scary transition, like moving from gas-powered to electric cars, or from cable to streaming, or even from the office to working from home. There are some undeniable benefits, but we must reorient our lives a bit to accommodate those changes, and the results aren’t always one-for-one. A strategy helps you make decisions about your future direction and how you should respond to changes and challenges. In Document Your Cloud Strategy we hope to help you accomplish just that: clarifying your overall mission and vision (as it relates to the cloud) and helping you develop an approach to changes in technology, people management, and, of course, governance. The cloud is not a panacea. Taken on its own, it will not solve your problems. But it can be an important tool in your IT toolkit, and you should aim to make the best use of it – whatever “best” happens to mean for you.

Jeremy Roberts

Research Director, Infrastructure and Operations

Info-Tech Research Group

Executive Summary

Your Challenge

The cloud is multifaceted. It can be complicated. It can be expensive. Everyone has an opinion on the best way to proceed – and in many cases has already begun the process without bothering to get clearance from IT. The core challenge is creating a coherent strategy to facilitate your overall goals while making the best use of cloud technology, your financial resources, and your people.

Common Obstacles

Despite the universally agreed-upon benefit of formulating a coherent strategy, several obstacles make execution difficult:

• Inconsistent understanding of what the cloud means
• Inability to come to a consensus on key decisions
• Ungoverned decision making
• Unclear understanding of cloud roles and responsibilities

Info-Tech’s Approach

A cloud strategy might seem like a big project, but it’s just a series of smaller conversations. The methodology presented here is designed to facilitate those conversations, using a curated list of topics, prompts, participant lists, and sample outcomes. We have divided the strategy into four key areas:

1. Vision and alignment
2. People
3. Governance
4. Technology

The answers might be different, but the questions are the same

Every organization will approach the cloud differently, but they all need to ask the same questions: When will we use the cloud? What forms will our cloud usage take? How will we manage governance? What will we do about people? How will we incorporate new technology into our environment? The answers to these questions are as numerous as there are people to answer them, but the questions must be asked.

Your challenge

This research is designed to help organizations that are facing these challenges or looking to:

• Ensure that the cloud strategy is complete and accurately reflects organizational goals and priorities.
• Develop a consistent and coherent approach to adopting cloud services.
• Design an approach to mitigate risks and challenges associated with adopting cloud services.
• Create a shared understanding of the expected benefits of cloud services and the steps required to realize those benefits.

Grappling with a cloud strategy is a top initiative: 43% of respondents report progressing on a cloud-first strategy as a top cloud initiative.

Source: Flexera, 2021.

Definition: Cloud strategy

A document providing a systematic overview of cloud services, their appropriate use, and the steps that an organization will take to maximize value and minimize risk.

Common obstacles

These barriers make this challenge difficult to address for many organizations:

• The cloud means different things to different people, and creating a strategy that is comprehensive enough to cover a multitude of use cases while also being written to be consumable by all stakeholders is difficult.
• The incentives to adopt the cloud differ based on the expected benefit for the individual customer. User-led decision making and historically ungoverned deployments can make it difficult to reset expectation and align with a formal strategy.
• Getting all the right people in a room together to agree on the key components of the strategy and the direction undertaken for each one is often difficult.

Info-Tech’s approach

Info-Tech’s approach

Your cloud strategy will comprise the elements listed under “vision and alignment,” “technology,” “governance,” and “people.” The Info-Tech methodology involves breaking the strategy down into subcomponents and going through a three-step process for each one. Start by reviewing a standard set of questions and understanding the goal of the exercise: What do we need to know? What are some common considerations and best practices? Once you’ve had a chance to review, discuss your current state and any gaps: What has been done? What still needs to be done? Finally, outline how you plan to go forward: What are your next steps? Who needs to be involved?

Review

• What questions do we need to answer to complete the discussion of this strategy component? What does the decision look like?
• What are some key terms and best practices we must understand before deciding?

Discuss

• What steps have we already taken to address this component?
• Does anything still need to be done?
• Is there anything we’re not sure about or need further guidance on?

Go forward

• What are the next steps?
• Who needs to be involved?
• What questions still need to be asked/answered?
• What should the document’s wording look like?

Info-Tech’s methodology for documenting your cloud strategy

Insight summary

Separate strategy from tactics

Separate strategy from tactics! A strategy requires building out the framework for ongoing decision making. It is meant to be high level and achieve a large goal. The outcome of a strategy is often a sense of commitment to the goal and better communication on the topic.

The cloud does not exist in a vacuum

Your cloud strategy flows from your cloud vision and should align with the broader IT strategy. It is also part of a pantheon of strategies and should exist harmoniously with other strategies – data, security, etc.

People problems needn’t preponderate

The cloud doesn’t have to be a great disruptor. If you handle the transition well, you can focus your people on doing more valuable work – and this is generally engaging.

Governance is a means to an end

Governing your deployment for its own sake will only frustrate your end users. Articulate the benefits users and the organization can expect to see and you’re more likely to receive the necessary buy-in.

Technology isn’t a panacea

Technology won’t solve all your problems. Technology is a force multiplier, but you will still have to design processes and train your people to fully leverage it.

Key deliverable

Cloud Strategy Document template

Inconsistency and informality are the enemies of efficiency. Capture the results of the cloud strategy generation exercises in the Cloud Strategy Document template.

• Record the results of the exercises undertaken as part of this blueprint in the Cloud Strategy Document template.
• It is important to remember that not every cloud strategy will look exactly the same, but this template represents an amalgamation of best practices and cloud strategy creation honed over several years of advisory service in the space.
• You know your audience better than anyone. If you would prefer a strategy delivered in a different way (e.g. presentation format) feel free to adapt the Cloud Vision Executive Presentation into a longer strategy presentation.
• Emphasis is an area where you should exercise discretion as well. A cost-oriented cloud strategy, or one that prioritizes one type of cloud (e.g. SaaS) at the exclusion of others, may benefit from more focus on some areas than others, or the introduction of relevant subcategories. Include as many of these as you think will be relevant.
• Parsimony is king – if you can distill a concept to its essence, start there. Include additional detail only as needed. You want your cloud strategy document to be read. If it’s too long or overly detailed, you’ll encounter readability issues.

Blueprint benefits

Measure the value of this blueprint

Don’t take our word for it:

• Document Your Cloud Strategy has been available for several years in various forms as both a workshop and as an analyst-led guided implementation.
• After each engagement, we send a survey that asks members how they benefited from the experience. Those who have worked through Info-Tech’s cloud strategy material have given overwhelmingly positive feedback.
• Additionally, members reported saving between 10 and 20 days and an average of $46,499.
• Measure the value by calculating the time saved as a result of using Info-Tech’s framework vs. a home-brewed cloud strategy alternative and by comparing the overall cost of a guided implementation or workshop with the equivalent offering from another firm. We’re confident you’ll come out ahead.

8.8/10 Average reported satisfaction

13 Days Average reported time savings

$46,499 Average cost savings

Executive Brief Case Study

INDUSTRY: Pharmaceuticals

SOURCE: Info-Tech workshop

Pharmaceutical company

The unnamed pharmaceutical company that is the subject of this case study was looking to make the transition to the cloud. In the absence of a coherent strategy, the organization had a few cloud deployments with no easily discernable overall approach. Representatives of several distinct functions (legal, infrastructure, data, etc.) all had opinions on the uses and abuses of cloud services, but it had been difficult to round everyone up and have the necessary conversations. As a result, the strategy exercise had not proceeded in a speedy or well-governed way. This lack of strategic readiness presented a roadblock to moving forward with the cloud strategy and to work with the cloud implementation partner, tasked with execution.

Results

The company engaged Info-Tech for a four-day workshop on cloud strategy documentation. Over the course of four days, participants drawn from across the organization discussed the strategic components and generated consensus statements and next steps. The team was able to formalize the cloud strategy and described the experience as saving 10 days.

Example output: Document your cloud strategy workshop exercise

Anything in green, the team was reasonably sure they had good alignment and next steps. Those yellow flags warranted more discussion and were not ready for documentation.

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.

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 4 to 6 calls over the course of 1 to 3 months

Workshop Overview

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

Phase 1

Document Your Vision and Alignment

This phase will walk you through the following activities:

1. Record your cloud mission and vision
2. Document your cloud strategy’s alignment with other strategic plans
3. Record your cloud guiding principles
4. Define success

This phase has the following outcome:

• Documented strategy: vision and alignment

Record your mission and vision

Build on the work you’ve already done

Before formally documenting your cloud strategy, you should ensure that you have a good understanding of your overall cloud vision. How do you plan to leverage the cloud? What goals are you looking to accomplish? How will you distribute your workloads between different cloud service models (SaaS, PaaS, IaaS)? What will your preferred delivery model be (public, private, hybrid)? Will you support your cloud deployment internally or use the services of various consultants or managed service providers?

The answers to these questions will inform the first section of your cloud strategy. If you haven’t put much thought into this or think you could use a deep dive on the fundamentals of your cloud vision and cloud archetypes, consider reviewing Define Your Cloud Vision, the companion blueprint to this one.

Once you understand your cloud vision and what you’re trying to accomplish with your cloud strategy, this phase will walk you through aligning the strategy with other strategic initiatives. What decisions have others made that will impact the cloud strategy (or that the cloud strategy will impact)? Who must be involved/informed? What callouts must be involved at what point? Do users have access to the appropriate strategic documentation (and would they understand it if they did)?

You must also capture some guiding principles. A strategy by its nature provides direction, helping readers understand the decisions they should make and why those decisions align with organizational interests. Creating some top-level principles is a useful exercise because those principles facilitate comprehension and ensure the strategy’s applicability.

Finally, this phase will walk you through the process of measuring success. Once you know where you’d like to go, the principles that underpin your direction, and how your cloud strategy figures into the broader strategic pantheon, you should record what success actually means. If you’re looking to save money, overall cost should be a metric you track. If the cloud is all about productivity, generate appropriate productivity metrics. If you’re looking to expand into new technology or close a datacenter, you will need to track output specific to those overall goals.

Review: mission and vision

The overall organizational mission is a key foundational element of the cloud strategy. If you don’t understand where you’re going, how can you begin the journey to get there? This section of the strategy has four key parts that you should understand and incorporate into the beginning of the strategy document. If you haven’t already, review Define Your Cloud Vision for instructions on how to generate these elements.

Understand key cloud concepts: Archetype

Once you understand the value of the cloud, your workloads’ general suitability for the cloud, and your proposed risks and mitigations, the next step is to define your cloud archetype. Your organization’s cloud archetype is the strategic posture that IT adopts to best support the organization’s goals. Info-Tech’s model recognizes seven archetypes, divided into three high-level archetypes. After consultation with your stakeholders, and based on the results of the suitability and risk assessment activities, define your archetype. The archetype feeds into the overall cloud vision and provides simple insight into the cloud future state for all stakeholders. The cloud vision itself is captured in a “vision statement,” a short summary of the overall approach that includes the overall cloud archetype.

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.

Prepare for the Upgrade to Windows 11

The upgrade is inevitable, but you have time, and you have options.

Analyst Perspective

Upgrading to Windows 11 is easy, and while it should be properly investigated and planned, it should absolutely be an activity you undertake.

“You hear that Mr. Anderson? That is the sound of inevitability.” ("The Matrix Quotes" )

The fictitious Agent Smith uttered those words to Keanu Reeves’ character, Neo, in The Matrix in 1999, and while Agent Smith was using them in a very sinister and figurative context, the words could just as easily be applied to the concept of upgrading to the Windows 11 operating system from Microsoft in 2022.

There have been two common, recurring themes in the media since late 2019. One is the global pandemic and the other is cyber-related crime. Microsoft is not in a position to make an impact on a novel coronavirus, but it does have the global market reach to influence end-user technology and it appears that it has done just that. Windows 11 is a step forward in endpoint security and functionality. It also solidifies the foundation for future innovations in end-user operating systems and how they are delivered. Windows-as-a-Service (WAAS) is the way forward for Microsoft. Windows 10 is living on borrowed time, with a defined end of support date of October 14, 2025. Upgrading to Windows 11 is easy, and while it should be properly investigated and planned, it should absolutely be an activity you undertake.

It is inevitable!

P.J. Ryan

Research Director, Infrastructure & Operations

Info-Tech Research Group

Executive Summary

Your Challenge

• Windows 10 is going EOL in 2025. That is closer than you think.
• Many of your endpoints are not eligible for the Windows 11 upgrade. You can’t afford to replace all your endpoints this year. How do you manage this Microsoft-initiated catastrophe?
• You want to stay close to the leading edge of technology and services, but how do you do that while keeping your spending in check and within budget?

Common Obstacles

• The difference between Windows 10 and Windows 11 is not clear. Windows 11 looks like Windows 10 with some minor changes, mostly cosmetic. Many online users don’t see the need. Why upgrade? What are the benefits?
• The cost of upgrading devices just to be eligible for Windows 11 is high.
• Your end users don’t like change. This is not going to go over well!

Info-Tech's Approach

• Spend wisely. Space out your endpoint replacements and upgrades over several years. You do not have to upgrade everything right away.
• Be patient. Windows 11 contained some bugs when it was initially released. Microsoft fixed most of the issues through monthly quality updates, but you should ensure that you are comfortable with the current level of functionality before you upgrade.
• Use the upgrade ring approach. Test your applications with a small group first, and then stage the rollout to increasingly larger groups over time.

Info-Tech Insight

There is a lot of talk about Windows 11, but this is only an operating system upgrade, and it is not a major one. Understand what is new, what is added, and what is missing. Check your devices to determine how many are eligible and ineligible. Many organizations will have to spend capital on endpoint upgrades. Solid asset management practices will help.

Insight summary

Windows 11 is a step forward in security, which is one of the primary reasons for the release of the new operating system.

Windows 11 comes with a list of hardware requirements that enable the use of tools and features that, when combined, will reduce malware infections.

The hardware requirements for Windows 11 enable security features such as password-less logon, disk encryption, increased startup protection with secure boot, and virtualization-based security.

Many organizations will have to spend capital on endpoint upgrades.

Microsoft now insists that modern hardware is required for Windows 11 for not only security but also for improved stability. That same hardware requirement will mean that many devices that are only three or four years old (as well as older ones) may not be eligible for Windows 11.

Windows 11 is a virtualization challenge for some providers.

The hardware requirements for physical devices are also required for virtual devices. The TPM module appears to be the biggest challenge. Oracle VirtualBox and Citrix Hypervisor as well as AWS and Google are unable to support Windows 11 virtual devices as of the time of writing.

Windows 10 will be supported by Microsoft until October 2025.

That will remove some of the pressure felt due to the ineligibility of many devices and the need to refresh them. Take your time and plan it out, keeping within budget constraints. Use the upgrade ring approach for systems that are eligible for the Windows 11 upgrade.

New look and feel, and a center screen taskbar.

Corners are rounded, some controls look a little different, but overall Windows 11 is not a dramatic shift from Windows 10. It is easier to navigate and find features. Oh, and yes, the taskbar (and start button) is shifted to the center of the screen, but you can move them back to the left if desired.

The education industry gets extra attention with the release of Windows 11.

Windows 11 comes with multiple subscription-based education offerings, but it also now includes a new lightweight SE edition that is intended for the K-8 age group. Microsoft also released a Windows 11 Education SE specific laptop, at a very attractive price point. Other manufacturers also offer Windows 11 SE focused devices.

Why Windows 11?

Windows 10 was supposed to be the final desktop OS from Microsoft, wasn’t it?

Maybe. It depends who you ask.

Jerry Nixon, a Microsoft developer evangelist, gained notoriety when he uttered these words while at a Microsoft presentation as part of Microsoft Ignite in 2015: “Right now we’re releasing Windows 10, and because Windows 10 is the last version of Windows, we’re all still working on Windows 10,” (Hachman). Microsoft never officially made that statement. Interestingly enough, it never denied the comments made by Jerry Nixon either.

Perhaps Microsoft released a new operating system as a financial grab, a way to make significant revenue?

Nope.

Windows 11 is a free upgrade or is included with any new computer purchase.

Market share challenges?

Doubtful.

It’s true that Microsoft's market share of desktop operating systems is dropping while Apple OS X and Google Chrome OS are rising.

In fact, Microsoft has relinquished over 13% of the market share since 2012 and Apple has almost doubled its market share. BUT:

Microsoft is still holding 75.12% of the market while Apple is in the number 2 spot with 14.93% (gs.statcounter.com).

The market share is worth noting for Microsoft but it hardly warrants a new operating system.

New look and feel?

Unlikely

New start button and taskbar orientation, new search window, rounded corners, new visual look on some controls like the volume bar, new startup sound, new Windows logo, – all minor changes. Updates could achieve the same result.

Security?

Likely the main reason.

Windows 11 comes with a list of hardware requirements that enable the use of tools and features that, when combined, will reduce malware infections.

The hardware requirements for Windows 11 enable security features such as password-less logon, disk encryption, increased startup protection with secure boot, and virtualization-based security.

The features are available on all Windows 11 physical devices, due to the common hardware requirements.

Windows 11 hardware-based security

These hardware options and features were available in Windows 10 but not enforced. With Windows 11, they are no longer optional. Below is a description and explanation of the main features.

How do all the hardware-based security features work?

This scenario explains how a standard boot up and login should happen.

You turn on your computer. Secure Boot authorizes the processes and UEFI hands over control to the operating system. Windows Hello works with TPM and uses a pin to authenticate the user and the operating systems gives you access to the Windows environment.

Now imagine the same process with various compromised scenarios.

You turn on your computer. Secure Boot does not recognize the signature presented to it by the second process in the boot sequence. You will be presented with a “Secure Boot Violation” message and an option to reboot. Your computer remains protected.

You boot up and get past the secure boot process and UEFI passes control over to the Windows 11 operating system. Windows Hello asks for your pin, but you cannot remember the pin and incorrectly enter it three times before admitting temporary defeat. Windows Hello did not find a matching pin on the TPM and will not let you proceed. You cannot log in but in the eyes of the operating system, it has prevented an unauthorized login attempt.

You power up your computer, log in without issue, and go about your morning routine of checking email, etc. You are not aware that malware has infiltrated your system and modified a page in system memory to run code and access the operating system kernel. VBS and HVCI check the integrity of that code and detect that it is malicious. The code remains isolated and prevented from running, protecting your system.

TPM, Hello, UEFI with Secure Boot, VBS and HVCI all work together like a well-oiled machine.

“Microsoft's rationale for Windows 11's strict official support requirements – including Secure Boot, a TPM 2.0 module, and virtualization support – has always been centered on security rather than raw performance.” – Andrew Cunningham, arstechnica.com

“Windows 11 raises the bar for security by requiring hardware that can enable protections like Windows Hello, Device Encryption, virtualization-based security (VBS), hypervisor-protected code integrity (HVCI), and Secure Boot. These features in combination have been shown to reduce malware by 60% on tested devices.” – Steven J. Vaughan-Nichols, Computerworld

Can any device upgrade to Windows 11?

In addition to the security-related hardware requirements listed previously, which may exclude some devices from Windows 11 eligibility, Windows 11 also has a minimum requirement for other hardware components.

Windows 7 and Windows 10 were publicized as being backward compatible and almost any hardware would be able to run those operating systems. That changed with Windows 11. Microsoft now insists that modern hardware is required for Windows 11 for not only security but also improved stability.

Software Requirement

You must be running Windows 10 version 2004 or greater to be eligible for a Windows 11 upgrade (“Windows 11 Requirements”).

Complete hardware requirements for Windows 11

• 1 GHz (or faster) compatible 64-bit processor with two or more cores
  • Not all processors are compatible; compatible processors are listed in this link: “Windows Processor Requirements”
• 4 GB RAM
• 64 GB or more of storage space
• Compatible with DirectX 12 or later with WDDM 2.0 driver
  • DirectX connects the hardware in your computer with Windows. It allows software to display graphics using the video card or play audio, as long as that software is DirectX compatible. Windows 11 requires version 12 (“What are DirectX 12 compatible graphics”).
  • WDDM is an acronym for Windows Display Driver Model. WDDM is the architecture for the graphics driver for Windows (“Windows Display Driver Model”).
  • Version 2.0 of WDDM is required for Windows 11.
• 720p display greater than 9" diagonally with 8 bits per color channel
• UEFI Secure Boot capable
• TPM 2.0 chip

(“Windows 11 Requirements”)

Windows 11 may challenge your virtual environment

When Windows 11 was initially released, some IT administrators experienced issues when trying to install or upgrade to Windows 11 in the virtual world.

The Challenge

The issues appeared to be centered around the Windows 11 hardware requirements, which must be detected by the Windows 11 pre-install check before the operating system will install.

The TPM 2.0 chip requirement was indeed a challenge and not offered as a configuration option with Citrix Hypervisor, the free VMware Workstation Player or Oracle VM VirtualBox when Windows 11 was released in October 2021, although it is on the roadmap for Oracle and Citrix Hypervisor. VMware provides alternative products to the free Workstation Player that do support a virtual TPM. Oracle and Citrix reported that the feature would be available in the future and Windows 11 would work on their platforms.

Short-Term Solutions

VMware and Microsoft users can add a vTPM hardware type when configuring a virtual Windows 11 machine. Microsoft Azure does offer Windows 11 as an option as a virtual desktop. Citrix Desktop-As-A-Service (DAAS) will connect to Azure, AWS, or Google Cloud and is only limited by the features of the hosting cloud service provider.

Additional Insight

According to Microsoft, any VM running Windows 11 must meet the following requirements (“Virtual Machine Support”):

• It must be a generation 2 VM, and upgrading a generation 1 VM to Windows 11 (in-place) is not possible
• 64 GB of storage or greater
• Secure Boot capable with the virtual TPM enabled
• 4 GB of memory or greater
• 2 or more virtual processors
• The CPU of the physical computer that is hosting the VM must meet the Windows 11 (“Windows Processor Requirements”)

What’s new or updated in Windows 11?

The following two slides highlight some of the new and updated features in Windows 11.

Security

The most important change with Windows 11 is what you cannot see – the security. Windows 11 adds requirements and controls to make the user and device more secure, as described in previous slides.