Thinking a move to cloud might be the way to go for your company, but you're not exactly sure if such a move is right for you? There are a few questions you should ask yourself about your organization to understand the context of what a migration to cloud would mean for you.  As you're navigating the pros and cons associated with migrating from on-prem solution to cloud, you have to understand that how these factors are weighed largely depend on the context of your organization. Asking the following questions will help you establish that context:

Why move to cloud?

For context, the term 'Cloud' can be somewhat ambiguous, so if not otherwise stated I'm referring to cloud in the SaaS sense (Software as a Service), that is, maintained by a 3rd party and available in a cloud setting, such as the Atlassian product suite. There are other flavors of cloud out there, but the SaaS model is where we'll maintain our focus. The first question you want to answer is why? Why are you considering moving to cloud in the first place? Are there any specific pain points you are feeling in your current setup that you think might be alleviated by moving to cloud? Understanding what your potential need is for a cloud migration will help you to develop a business justification for the endeavor, as well as allow you to start to build the context of your specific situation. If the reason is "We're spending too much time on maintaining infrastructure for our on-prem solutions" then something like having no maintenance in a cloud environment would be weighed very heavily in your case.

What are you moving?

What are you going to be moving?  What does your current on-prem setup look like? How big is your userbase? What 3rd party add ons or apps are you using? Are you using a single instance and are wanting to consolidate in addition to migrating to cloud?  How much historical data do you have? These questions can help to establish the potential complexity of the migration you're looking to perform.  One of the major considerations that has to be factored into a cloud migration is the cost of entry. This extends from just the literal monetary cost to include time and human resources as well. If your company can't afford to divert labor to perform a migration, is it worth it for you to contract the project out to a 3rd party? Having an idea of what you are migrating will help you weigh the various options and give you perspective to consider the impact.

Pros

Now that you've established the context for you migration, let's take a moment to talk about the potential pros around migrating to cloud.  When comparing cloud to an on-prem solution, you can really break down the pros into four main points:

• Accessibility
• Scalability
• Maintenance
• Cost

Let's take a look at the first point, Accessibility. One of the great things about cloud is that it's accessible from almost anywhere in the world right out of the box. You don't have to configure any VPNs or allow lists, no special permissions groups to modify, all the data replication and content delivery is managed for you, and has a low cost to entry.

Scalability is another major pro in favor of a move to cloud and falls along similar lines as Accessibility, and typically goes hand in hand with Maintenance. The infrastructure behind the application or service is purpose-built on a platform intended to be scalable in order to support multiple customers.

Add to this the fact that you no longer have to be responsible for maintaining that infrastructure, you can focus efforts and resources elsewhere in your organization. If maintaining infrastructure is something in particular your business struggles with, making a shift to cloud can have a huge positive impact.

This leads us nicely into the topic of cost.  Depending on the specific context, cost can sometimes go either way: I'm including it in the pros section because I think in most cases, especially if you factor in for the long term, your costs overall will be lower with a move to cloud. Figuring costs in a cloud move takes some doing because there can be differences in the types of costs you'll encounter in a cloud setting vs. an on-prem. Again, because this can be pretty heavily dependent on the context of the specific situation being analyzed, I'll throw out a few common factors but I don't want to give any potentially wrong impressions. 

Cons

There are of some potential tradeoffs and downsides to consider as part of a move to the cloud. The biggest areas that might cause you or your organization trouble include Control, Security, and Flexibility.

When you break it down, the concepts of control and security almost go hand-in-hand.  Control is probably the hardest thing to overcome when talking about moving your data to the cloud and understandably so. The bottom line of operating in cloud environment is your data lives somewhere outside of your organization and the infrastructure is managed by another entity. You're putting your data and your trust into someone else's hands. While this is not necessarily a bad thing, it can take some getting used to, and some adjusting of your internal methods or practices. Being familiar with the support process can help with this as know what information you can request and how to get it will help to alleviate some of the disjointed feeling when attempting to manage your application.

On the security front, if your company has very specific security requirements or has specific regulatory bodies you have to comply with, there is an extra layer of consideration when weighing the prospect of moving to cloud. It's important to first identify what those needs are and reach out to the cloud provider ahead of time to find out if those requirements can be accommodated.

Lastly it's important to consider that moving to a cloud application means you will not have access to anything beyond the application layer. This can mean workarounds previously in use with the on-prem solution may need to be re-considered or re-engineered, and there are potentially additional restrictions around API calls and traffic to/from the application. Spending some time discovering what your needs are vs what is available to you in a cloud setting will be key to realizing these potential pitfalls.

We are getting to a point where we're moving from "Is cloud the right choice?" to "Which form of cloud is the right choice?" Not all situations involving cloud are the same, and careful consideration and weighing of options is important for any potential move.  Having the right tools to plan and execute the transition as well as an understanding of the context of your environment can make all the difference when deciding how to move forward.

If you have any questions on migrating to cloud, have run into trouble implementing a migration, or simply want to see if your organization is making the most of its digital infrastructure and operations, contact us and one of our experts will reach out to you.

When we initially set out to write a piece about how to implement an IT Modernization Strategy, we quickly realized there is not only a lot to consider when weighing the possibilities, but also a lot of context required to lay a meaningful foundation. We want to discuss what IT Modernization is and what it means for your individual business, as well as other terms and ideas to help define the overall picture.

What is IT Modernization

We'll begin by exploring the motive behind IT Modernization, and identifying the traits that make up the profile of an entity that is looking to implement IT Modernization in their enterprise.  Overarching themes include Digital Transformation, Capital Expenses vs Operational Expenses, Legacy Systems, how Cloud fits into the picture (because it's no longer a question of "if" cloud fits into the picture), as well as others.

There are several questions to ask when trying to nail down the motive- we'll be working through these questions in our series:

• Why would you be interested in IT Modernization in the first place?
• What are some of the apparent benefits of IT Modernization? 
• What would IT Modernization look like in your organization and how?
• What would a rollout plan look like?
• When do you tackle certain things over others?

By the end of this series our goal is that you will have the foundational understanding of IT Modernization that will help you answer these questions.

The Basics

If you've worked with Praecipio before, you know we like to start simple - so let's begin with the basic question "What is IT Modernization?"  To oversimplify the concept, IT Modernization is a process of assessing an individual system or group of systems in your organization with the intent of establishing the best possible balance of cost and efficiency. One of the challenges we often call out is that this can look vastly different depending on the context of what it is being applied to.

As part of an IT Modernization strategy there can be some aspects of your business where it makes sense to move in a more digital direction, for example migrating on-prem resources to virtualization or the cloud. While the overarching goal may be to get to the cloud, there are different paths that you organization may take based on your specific context. In the case of moving  an application to the cloud, there are the branches hosting the application on a digital platform like AWS or moving completely to a more SaaS model and allow it to be maintained by a third party.  And of course, for some other aspects of your business it could make more sense to maintain an on-prem solution but update the infrastructure. The key thing to consider here is how you can balance the cost of maintaining whatever aspect of your business you're assessing with the amount of performance proficiency it is providing.

Another term you'll often hear mentioned in the same breath as IT Modernization is Digital Transformation.  It's true that these often go hand-in-hand, but the main difference to consider is that Digital Transformation gets into the explicit changes you have to make in order to keep pace with the digitization of aspects of your business, like products, assets, and processes. IT Modernization is more of a strategy for improving your business through cost savings, efficiency or improving on how agile your business can be. More often than not, Digital Transformation will be a key part of your IT Modernization plan, but they are not necessarily mutually exclusive.

The Breakdown

With that in mind, let's start to identify the motive a business might have for exploring IT Modernization and what attributes make up its profile. The first question you have to ask is "Why would you even be interested in IT Modernization?" The short answer is every business should be thinking about IT Modernization on some level. We exist in a world where the only true constant is change, and as time progresses the main thing that we're betting on is that our technology and business landscapes will continue to shift. The most successful businesses will adjust business practices to match - if you're not willing to embrace the change and make it work for you, your competitor will, and they'll be happy to take your market share off your hands. Additionally, IT Modernization benefits the business, either by lowering your operating costs, or empowering you to be more efficient managing resources and development. Thinking about ways you can Modernize aspects of your business is just good business.

So how do you this? What does it look like?  Well, we've touched on the two key factors associated with Modernization: Cost and Efficiency.  There are a couple schools of thought when it comes to the approach and how you can execute modernization, outlined below.

The first approach would be considered a more traditional approach. This approach involves making incremental changes made over time targeting the most costly or bottlenecked aspects of the business. From this you can attempt to figure out how you can make them more efficient or cost less, or maybe a combination of both. The main benefit of an approach like this pertains to risk: changing pieces incrementally allows you to carefully consider those changes and their impact on the business as a whole. Incremental changes can also be very good for the bottom line since it allows you to budget changes over time.  One of the potential downsides to an incremental approach is it can be limiting. Taking the time to make incremental changes can take.. well... time.

On the other end of the spectrum there's the end-to-end or holistic approach.  This is about what you'd expect: instead of incrementally making changes you're making a plan to implement broad changes across your organization as a whole. This requires careful planning and consideration of what elements need to change in what sequence, to truly understand the potential impact across the organization. One of the benefits of this approach is it keeps the organization from advancing in a siloed manner, which can lead to less efficiency as a whole. In one instance, that might mean two different business groups moving their application to two different cloud solutions that offer the same functionality. Whether your approach is more incremental or end-to-end, it's important to try to take into account the potential impact across the business and ensure groups coordinate the efforts.

Modernization  Mechanisms

When it comes to implementing IT Modernization, it's important to understand that it is much more than a simple update to your technologies. Rather, the approach should be thoughtful and well planned, with an eye to the future and a willingness to embrace the new and sunset the old. At a high level it is important for your teams to identify out of its legacy software or assets what can can be invested in - whether through legacy software modernization or replatforming- and what should be divested from. Reaching a decision on the best path forward for each application will take time - legacy modernization is not an all or nothing endeavor. We'll spend dedicated time in future posts discussing how you can best approach application modernization. 

It's Just the Beginning

As you consider what IT Modernization means for your organization, keep in mind that there is not a one size fits all solution. Our goal is to provide helpful context to help you define what an IT Modernization approach could look like and what success would mean to your organization.

At Praecipio, we enjoy helping our clients reach their IT Modernization goals and bringing teams up to speed with digital demand. If you'd like to learn more about how we can help, please reach out to us!

2020 – What a change!

By now, every technology leader has torn up their plans and strategies as they began a ten-month tactical, fire-fighting effort to move their organization to virtual. In some cases, they were able to assist with changing how people performed their jobs, not just their staff but everyone, in which case they now joined the Digital Age.

CIOs further realized that moving to digital required a move to the cloud, and with it completely new ways of working that took advantage of the internet capabilities and bandwidth. Transferring your data center to a cloud service provider is no more going to cloud than moving your teams to Zoom makes you digital. Cloud requires a different mindset, skillset, and culture on how technology will enable your organization.

2021 is the year CIOs can own the Digital watercooler and change their role to being a Business Technology Officer, integrating software into every aspect of how their company performs tasks and services customers. But first, CIOs must address new ways of hiring, financing, and benefitting from technology, their people, their processes, and their IT. Accelerating the path to digital and cloud is the only way to remain sustainable, competitive, and compliant going forward.

The path has two main steps: funding and the creation of a new operating model

1. The innovation funding model – iterative investments using VOI as the guide to obtain technology value sustainably

Before you decide on your cloud service provider (CSP) partner and how to migrate your applications, you will need to determine how you fund the migration to enable your organization to do work better, sooner, and safer. You need to separate the process of budgeting – a plan on what resources will be required – and funding, which is the action of providing those resources.

Current budgeting practices limit moving to the cloud and digital by:

• Asking individuals to annually decide what they will need – and how would you know in this VUCA world?
• Constricting work to be feature-focused but with no indication of what it will add to customer satisfaction or help staff perform better
• Adding to technical and cultural debt with no strategy as to paying it off

The central dilemma of every executive board is how to plan, fund, and prioritize technology activities. The current best practice is not to use cost savings as a goal and instead let that be an outcome as you do things differently aided by software. You can prioritize by:

• Application review
• Moving from a Project mindset to a Product culture
• Cost of Delay
• Creating platforms for products
• Decide on the WHY of moving to the cloud and digital, on HOW it will help, and WHAT tasks will accomplish your goals
  • Faster time to market
  • Reduction of manual activities
  • Making work more compliant
  • Creating workflows that provide agility and flexibility to meet customer demand, staff requirements, competitive threats, and external issues such as Brexit or COVID19
• Get your entire workforce and significant suppliers to be part of the planning and allow them to focus and contribute to the proposed strategy

Shift-left! Think as your customer or staff and deeply analyze your applications, products, and services. Which ones are unique to you, and which ones could you source from a SaaS provider? Which ones do you no longer need? Now group the applications into product groups and allow your IT teams to create platforms (see next section) to service these groupings from the cloud.

Many organizations follow McKinsey's advice to create a FinOPS team of cross-functional product business leaders or at least a team comprised of IT, Finance, Risk, and HR. FinOPS will frequently negotiate with stakeholders to allocate resources (money, people, etc.) to continue the innovation or improve services. They will base their decisions on the value of investment towards the company. Frequently repeating and communicating this interaction creates the ability to pivot or stop work quickly, creating new behaviors, and embedding new disciplines on technology use.

FinOPS will rely on analytics, reporting dashboards with real-time data, and automated processes to make decisions visible and linked to business activities. Leaders will have to coach a new culture of moving from CAPEX funding to OPEX. This team will also introduce training to upskill the entire organization on how technology is applied and that by making use of cloud and digital, they will not lose their roles.

Where needed, a partner such as Atlassian and Praecipio Consulting can help you begin this journey of becoming a sustainable business, maximizing resources while reducing costs and making the entire process transparent.

 2. You have the funding model, and now you need the digital cloud operating attitudes, behaviors, and culture to achieve scalability, agility, and continuity

Can you answer these questions?

• Which business workloads are most important to your company?
• What are your goals by business line for the next quarter and year?
• What are your obstacles to these goals?
• What are your strengths for achieving these goals?

Taking the answers to these questions, review what activities you have planned in your IT department. If a user story or request is not helping solve a problem or achieve a goal, stop it. The FinOps should ask these questions monthly, which will influence resource allocation decisions for technology tasks. Visualizing findings to the company will illustrate the importance of product stories while embedding the capability of pivoting or stopping work, as necessary.

Your operating model will require:

• A compensation model mapped to the technical activities that are not divisive
• A full review of your applications mapped to the business lines
• A map of the way data flows throughout your organization
  • What it entails
  • How it is used
  • Storage, archival, and continuity requirements
  • Security and access obligations
  • Tools that maintain the applications
  • A full list of proposed enhancements
  • Server, network, storage, and operating system supporting them
  • If provided to a specific location, why and how

Using this list, technology leadership needs to help the company move from a project model to a product model. Services must be led by an owner fully accountable for the resources and associated workload, including packaging software into chunks (platforms) that can be used interchangeably throughout the company.

FinOPS and the Product Owners can collaborate on which business domains would benefit most from enhancing the applications used to provide their services. Management can utilize the model to ensure that the right CSP is chosen for each platform. As you mature, you can empower your development teams to decide the best CSP for designing and deploying platforms, be they SaaS or containers. At the beginning of your journey, the strategy should be to communicate the intent and collaborate on the outcomes.

FinOPS also needs to be cloud-savvy. The pricing and SLA options are numerous and complicated. You need to ensure that what you choose is the right decision. You also need to affirm the best path for migrating your application and data to the CSP. Should you port it as it is (provides little benefit), rewrite the application, switch the workload to a SaaS provider? Remember that the avoidance of technical debt, adding to cloud migration's complexity, must be avoided.

There is no shortcut or other option to having Product Owners. You cannot interject a translator or business analyst between what people call the business and your IT. You are all part of the same company, and technology needs to be owned by the business area that provides that service. Further, the people that support these services need to feel that they also own and contribute to these services. This change in attitude and behavior will reduce incidents, increase innovation agility, and enhance your employees' satisfaction, who will feel empowered to see their contribution to the business goals.

The cloud offers the capability of completely altering the way you use technology. Do you need a new instance or environment? Build it, use it, dismantle it, and all within a few minutes at a minimum cost. The software lifecycle of products will be a combination of IaaS, PaaS, and SaaS, depending on the services' platform. Data lakes can share information across the company powered by analytic and reporting tools that would not be accessible to you unless you are quite large.

Security and continuity are other strengths of the cloud as you adopt the framework used by your CSP. Using IAM and Zero-trust security concepts will ensure that you do not become front-page news. Product Owners will have to maintain the governance model required and test it as part of any software change using DevSecOps practices. Scalability, both up and down, is another cloud and digital feature, enabling you to offer new products that can sense and respond to demand.

Are you worried about regulations? Globally FinOPS and Product Owners are finding that regulatory bodies, such as the Bank of England, are moving to the cloud themselves and more than willing to help ensure that their mandates are provisioned accordingly by your CSP. Even if you use a hybrid approach of more than one CSP, which leadership needs to consider, the governance and management models exist via SIAM® to support cloud and digital operating models' best strategies.

The business product operating model is not to become vendor dependent but instead use microservices and containers so that you can migrate your applications as needed to another CSP or a different offering with little effort. This abstraction mode offers the best efficiency in technology enablement. The FinOPS and Product Owners will help to create the loose guardrails to be used by your staff and IT teams as they develop software provisioned products and workloads of your business

In summary

Done correctly, the number of technology instances and applications you currently maintain will decrease but not the requirement of technical skills. Your business flexibility behaviors should be to create agility via innovative use of software, cloud, and digital. Done correctly, the time to market and lower technology costs will be your outcomes. Let all of your organization be involved in the migration strategy as you join the Digital Age, and if you need help, Praecipio Consulting is here for you.

This article is Part 3 of a five-part series on Atlassian Single Sign-On. Click to read Part 1 and Part 2.

Praecipio has partnered with our friends at resolution to bring you a series of blog posts on how to successfully implement Single Sign-On (SSO) with Atlassian tools. Resolution is an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

In Part 1 and Part 2 of this series, we saw the main symptoms of a password disease that can be cured when applications are secured with single sign-on. We also took inventory of the core identity assets involved in an SSO implementation – including web applications, SSO connectivity, user directories, and opportunities to deploy identity providers (IdPs). 

In other words, we’ve looked at where you are. Now, it's time to look at where you want to go.  

Part of that journey involves making a final decision about the home of your user accounts once you move away from Active Directory. Will it be Okta? Azure AD? Some other vendor? 

Another part of that journey relates to extremely specific requirements that you will need to analyze to make sure that the implementation of single sign-on in Atlassian applications makes all stakeholders happy.  

In this article, we'll spell those requirements out. 

Write them down: These are the most important questions that you will need to answer in full detail before evaluating specific SSO solutions for your Atlassian applications. 

Question 1: Do your Atlassian applications support SSO out of the box? 

We saw this already in Part 2, but it’s worth revisiting. 

Your options depend entirely on the type of hosting of your Atlassian products, as you can see in the summary table. If you are on Server, you will plan a migration to either cloud or Data Center in the next couple of years, so that's where you should look. We won't consider SSO solutions for Server applications in this article, although the answer is easy: go to the Atlassian Marketplace. 

If you are on the Atlassian Cloud, your options can also be spelled out with 2 words: Atlassian Access. The good thing is that you need to search no more. The downside is that Access can be quite expensive, and there is no competition. 

In terms of functionality, Access has everything you could ask for. In fact, it does much more than just SSO, making it a high standard against which other solutions can be measured.  

Audit log, directory syncs, and lifecycle management are components that go beyond the basic SAML SSO functionality and towards a comprehensive Identity and Access Management framework on the Atlassian stack. 

If you're already on a Data Center license or planning a migration in the next couple of years and before Server End of Life in 2024, then you do have (or will have) SAML SSO out of the box. But the Data Center SSO offering is far away from Access. Which takes us to the next question.  

Question 2: Will Native Data Center SAML SSO be enough for you? 

Here are some facts:  

• Atlassian started providing native SSO capabilities with the SAML protocol in 2019. Originally as a free app, it’s now a preinstalled app for any Data Center customer. 
• While more functionalities are being added to the SAML-based authentication, the app is still behind. You can check their roadmap here. 

What this means is that if you have a simple need and a simple infrastructure, Data Center SAML SSO may work for you. Otherwise, you should look for a commercial alternative. In this article we will look at how common additional requirements are covered by resolution’s SAML SSO apps, with over 7 million users in 58 countries. 

Let’s have a quick overview of what the Data Center SAML SSO can do before we look at how additional requirements can be solved with resolution’s SAML SSO. 

A quick overview of Data Center SAML SSO: 

First, we'll cover the main functional requirements that Data Center will solve at a high level: 

• Authenticate users into Jira, Confluence, and Bitbucket Data Center on behalf of an Identity Provider. Spoiler alert: you will need exact username matches on both sides (see question 3). 

• Create users into the Atlassian applications during their first login, without the user being prompted to enter their Atlassian password. This is commonly called Just-in-Time provisioning and happens with the information that the Identity Provider sends in the SAML response. 
  
• Update the information stored in the local Atlassian directory. This also happens during login exclusively and applies to the group memberships that define user permissions and access. 

There’s no question that these three functions alone are powerful. However, a more detailed examination is needed to ensure that you can effectively implement Data Center SSO with your current infrastructure. 

The following two questions are aimed at clearing up that part of the dilemma, before we embark on additional functional requirements. 

Question 3: Do you have different naming conventions on the Identity Provider and in the local Atlassian directories? 

If the answer is no, then Data Center SAML SSO will accommodate you right away. You can skip to the next question. 

For example, if you are implementing Azure AD the UserPrincipalName attribute will be populated with user emails. If you also have email addresses in the Atlassian username, the match will be perfect. 

But if the answer is yes, it will not work. When the usernames don’t match immediately on either side, it will be impossible for the Data Center SAML SSO to identify which user in the Atlassian database is trying to log in. 

This will happen, for example, if instead of the example above, there are full names in the Atlassian usernames. 

There are two workarounds: 

• Modifying all the usernames in your Atlassian applications to align them to the naming conventions in the IdP (Identity Provider). 
• Modifying usernames on the IdP side to align them with Atlassian (but potentially disrupting the rest of your connected applications). 

If you want a more elegant solution, you can use the user-mapping and transformation features in resolution’s SAML SSO.  

In our example, there are two different strategies to create a match with resolution's SAML SSO: 

1. The UserPrincipalName is mapped with the e-mail attribute, which can then be selected as the attribute that is looked up in the Atlassian database for authenticating users. 
2. The UserPrincipalName is transformed into the username by simply stripping the email domain.  

Note: No-code transformation options are quite varied. 

Question 4: Do you have to connect Atlassian applications to multiple identity sources? 

Enterprises rarely have a single, monolithic user directory. For historic and legacy reasons, but also because IT governance models give a lot of autonomy to geographic regions, it is most common to have a few user directories, even from different vendors. 

But even in more centralized approaches, large organizations tend to have separate user directories for different types of users, even if those directories are provided by the same cloud vendor. For example, Jira users and Jira Service Management agents could be stored in different instances of Okta. And it's even more common to separate customers and employees. 

If that is your case, then you won’t be able to use the Data Center SAML SSO app. 

On the contrary, in resolution’s apps, you can setup multiple IdPs and decide when each of them is triggered based on multiple methods: 

• The user’s decision on a selection page 
• The user’s email domain 
• Specific information included in the http request headers 
• Priority scores (by weight)
  

Note: Atlassian has put this feature on their short-term roadmap, but it’s unknown what will be possible with it and whether the setup will support dynamic IdP selections. 

Question 5: Do you want to centralize user management from your Identity Provider? 

In an enterprise setting, there is not a right or wrong answer to this question. It can make sense to manage users in every application locally. This usually happens when the IT team has the right expertise, and the company is small enough that change requests don't swamp the workload. 

But on a larger scale, a decentralized user management framework can become a major issue.  

What happens when user management is centralized? As employees are promoted, change departments, or are assigned to a new project, permissions can be changed directly from the Identity Provider alone. Then, they propagate immediately to all connected applications. 

The technology behind this benefit is a one-way synchronization from the IdP to the connected apps via API. Once set up, the sync will update users’ group membership at regular intervals and therefore automatically modify their access rights. 

Data Center SAML doesn’t have the ability to sync with IdPs, which exist both in Atlassian Access for cloud applications and in resolution’s SAML SSO apps. 

As you can see in the image below, resolution’s User Sync functionality provides connectors with most commercial IdPs. Connectors can then be configured so that they align to your group management practices and nomenclature. We will show a practical example of this in the next article. 

Question 6: Do you want to automate user onboarding and offboarding? 

User syncs are vital if you want to automate user management throughout the entire lifecycle.  

Besides the satisfaction of having the power to control every detail, few administrators enjoy onboarding new users into every application. They understand it’s a job that needs to be done. They also grasp the urgency of removing access to applications when an employee leaves the company. But sometimes they might be too busy to put that task at the top of their list or to double check that every access was effectively disconnected. 

User syncs can automate the three key on and offboarding jobs: 

• When a new employee joins the company, they have immediate access to every application without even having to login for the first time. 
• When an account is deactivated on the IdP, all accesses are immediately blocked. 
• Deactivate users temporarily when they don’t access an application like Confluence for a specific time (for example, 3 months)  

For the third job, it’s even possible to create a specific connector that takes care of the automatic deactivations. 

How to evaluate your answers: 

Until now we have looked at the main requirements that you must consider for your SSO implementation. It's vital to have a clear answer to all these questions before making a final decision.  

Now that you have your answers, let’s translate them into realistic options. 

 The table below summarizes your options, mapping combinations of answers with the most suitable SSO solution.  

To find which product we recommend for your use case, simply find the row that contains your answers. 

As you can see, there are three main possibilities: 

• If you don’t have any of the requirements listed in questions 3 thru 6, then Data Center SAML SSO might do the job.  
• If you answered yes to question 3, question 4, or both, then it seems like resolution’s SAML SSO will be your best shot. 
• If you answered no to 3 and 4 and you still want to automate user management, then you have two alternatives:   
  • The simple alternative is to go for a complete product like resolution’s SAML SSO. This will simplify your implementation and the number of touchpoints with support experts. 
  • The cheap alternative is to implement the existing functionality in Data Center for the basic SAML, and resolution's Users and Groups Sync to automate user management. This will give you the advanced features you need to manage users and groups, but at half the cost of the SAML SSO app. 

Now you know what’s your basic fit.  

Make sure to complete your evaluation going over all your additional requirements as instructed in the next paragraph. 

Continuing your evaluation  

We hope that our attempt at boiling down your implementation project to its essentials was successful and your scenario is realistically captured in the options above.  

But beware! These six questions leave out many details. To quickly cross-reference your feature wish list, we have published a full tour of customization options and how they compare to the Data Center defaults.  

Here’s a high-level preview. 

But if you want to learn how it works, have a look at the in-depth comparison resolution has prepared.

What’s Next 

In this article we reviewed the native SSO capabilities of Atlassian products depending on their hosting type and doubled down on what Data Center SAML SSO can do. We then focused on three major requirements that cannot be solved with it: username mapping and transformations, multi-IdP setups, and user management automations. Finally, we took stock of the combined requirements and presented the best solutions for each of them. 

Part 4 of this series will go even deeper into how to address these requirements with resolution’s SAML Single Sign-On. We will go over the implementation project of an imaginary company that has decided to migrate out of their Active Directory into a cloud Identity Provider. We will identify their challenges, understand the value that the implementation will create for the business, and offer reproducible how-to steps to solve their case. 

Read the rest of our Atlassian SSO Series:

Part 1 | Part 2 | Part 3 (you're here!) | Part 4 | Part 5

What is SaaS (Software as a Service)?

COVID-19 has changed the world in many ways, accelerating the pace in which the digital transformation has upended traditional modes of working and living. Whatever your organization was planning to do in 2020, whatever 5-year plan you had, is no longer valid. No matter what sort of business you are, your dependence on technology has escalated. You have probably built the services in the table below or at least run them on your infrastructure, managed by your IT teams.  COVID-19 has forced you to ask the question: do I still need to run and manage this service internally, or can I save money and time by letting someone else perform this service for me?

Traditionally in-house Managed Services

The definition of SaaS by the East Sussex Council highlights what software is achieving today as businesses move towards a digital future: "SaaS is the focus for innovation and investment for major system providers and is specifically designed to meet the needs of an agile and mobile workforce, enhancing self-service business processes and significantly improving the use of management information. (Cabinet Office report for East Sussex council)".

Another view to help the discussion comes from Albert Barron using pizza as a stand in for software, with this fun visual of how the transition to SaaS changes from "You do IT" to "They do IT for you". 

There are caveats that you need to be aware of such that your experience with a SaaS provide is valuable to your organization and customers: it's vital to go through these with your team before making decisions.  The rest of this article explores these and if you have any questions, please let us know.

1: Security, Risk and Data

Your data is now their responsibility!

• Who in their organization has access to it?
• How is it backed up and does that comply with your regulatory bodies?
• Where is the data stored and does that contravene any local laws?
• If they have an issue, what is their business continuity plan and how does that align to yours?
• If they are compromised, what processes will they enable to let you know, but more importantly, protect your customers?
• Will they agree to participate in your business continuity tests and decide on their role in a business continuity event?
• Will the transference of data from you to them be exchanged safely and securely?
• What will it cost to perform the data transfers and tests?
• What level of access will your staff receive? Even if they assume responsibility for an activity, you are still accountable to require some level of access over time.
• What defense does the vendor offer against hackers, and is this an extra-tiered service or part of the basic package? If extra, you might want to look elsewhere.
• What processes need to change within your organization to enter, use, modify, delete, backup or restore information and have you been trained by the vendor appropriately?
• Your data is now their responsibility. How portable is it if you want to switch?
• Does the vendor support MFA
• Do they allow penetration tests?
• What policies have you introduced to manage your data in the SaaS provider cloud?
• If the SaaS vendor changes the schema or worse-cancels it, what impact will that have and are you contractually protected?
  

2: SaaS Vendor Performance

The perception and experience of your staff and customers are now based on the SaaS provider's performance.

• Did you create a clearly defined view of expectations supported by metrics and examples? Do you know bad from good from great service?
• How did you explain to your customers and staff that you were now going to use a SaaS provider? What was the reaction?
• What happens if your customers complain? What happens if your customers leave you because of a SaaS performance?
• Is it contractually clear under what circumstances a complaint can be made, the timeframe it must be addressed and any penalties that could be applied for non-conformance?
• Who does the customer or staff call if there is an issue? Your teams or the SaaS provider?
• What level of support do they provide and how will you test that the service is delivered as expected?
• What messages do you receive in case of a data entry issue or general performance issue?
• Do you have regular performance and improvement meetings with the vendor?
• If you want a new feature based on customer feedback, is the SaaS provider responsive?
• If the SaaS provider changes their product procedures, what will be the impact on your customers? Can you pilot the changes? If you do not want the new procedures, can you leave the SaaS provider?
  

3: Vendor lock-in

SaaS vendors bet that once you let them perform an activity, that you will remain a customer for several years. In other words, you are locked-in to their practices, processes, support, improvements and remediation and so are your staff and customers.

• How does the SaaS vendor recruit, train and keep their staff? You do not want a constantly changing workforce and there are examples where 30% of a SaaS workforce changes every 90 days.
• You might have saved money by not having to hire or train your staff, but what will you do with the knowledge they possess?
• Contractually obligating certain staff to remain until the transition is complete is best practice.
• Your IT is now their IT. If you want to benefit from the latest technology and they do not support that product then you are stuck. Make sure your contract allows for changes or even cancellation if needed.
• If the vendor changes their price, what protections have you contractually initiated to ensure that you should remain with that vendor? How will you prove value over time?
• COVID-19 has seen a number of vendors have issues causing them to default on a service or even go out of business. How will you protect yourself in case this happens to your provider? 
• SaaS vendors price in three main ways: by user license, by use, by feature. Make sure that you have chosen the model most appropriate for your needs and that if your work model changes, then you can move to another tier without penalty.
  

4: SaaS requires an internet connection and belief the cloud is secure

• What if something terrible happens to your web servers? Do you have backups of your metadata? You might want to consider using third party backup services such as Spanning, Barracuda, and Backupify.
• If you have communication issues from your office, what is your backup to ensure that the SaaS service remains accessible?
• If your staff are working from home and they have issues, then how will they continue to work until normal service is restored?
• Can your staff download data to their home office? If so, this is a security and perhaps even a compliance risk. How will you know?
• If they invoke contingency, does this place your business in a location where you
• What is the web page loading time? How complicated is the page to read or use?
• If data is transferred to other applications to complete the journey, can this be monitored for security and improvement?
• Is the SaaS service usable across a variety of mobile devices or internet browsers?
  

5: Integration into your other software

SaaS implies that all of the technology required to perform a service is now under the control and management of the vendor.

• How easy is it to transfer their data into your systems such as corporate finance?
• What happens if they make a change to a schema that you were unaware of and this damages your data or causes you lost time to introduce new ways of addressing their change?
• Everyone performs regular maintenance activities and how will this be coordinated?
• If you use multiple SaaS vendors (Accounting and Sales for example), how will you keep them in sync with each other and any internal applications you maintain?
• How do you test that interoperability remains as expected?
• What is the impact to your business continuity of multiple SaaS providers?
• If a vendor has an issue, how will that impact other vendors you rely upon?
• Will you require 3^rd party to help you integrate their software with yours? This can be costly.
• Not every vendor follows standard APIs, protocols, and tools, so the impact to your business practices should be piloted prior to accepting the SaaS provider.
  

6: You may have to change your business practices to use the SaaS

• This is a culture change for your staff. How will you prepare them?
• What training and documentation will you receive and is it sufficient?
• If something requires customization, is that even possible or practical? Many SaaS vendors will only allow this if a significant number of customers also request that feature.
• How will you ensure that other business practices can pivot based on competition, compliance or performance needs?
• How will you ensure that the SaaS provider supports all of the ways your customers want to interact with you? Browsers, mobile technology, VPN, etc.?
• What and when is their maintenance window? How does that impact your business customers? What happens if a change goes awry?
• What information do you receive on incidents related to you? Is it in a format that your ITSM tools can read and archive?

SaaS is a brilliant technology capability that can benefit your organization. You must closely manage them if you are to remain in business, service customers safely, and receive the expected cost benefits. Ensuring that you have a way to mitigate this list of caveats will ensure that your experience is as valuable as possible. Letting go of services you have built in-house can be hard, and moving to a SaaS model can be intimidating: have no fear, Praecipio Consulting is here to help. Contact us for any questions you might have of successfully transition to a faster, more efficient way of doing business.

SaaS Providers & Customer Service

The year 2020 has forced organizations to consider how they service customers and enable staff to do their work by having them reconsider the benefits and value of their current technology practices. 

Look at the fun visual below: most businesses use a combination of managing their own data centers and software or by using cloud-based facilities. Software as a Service (SaaS) allows a provider to perform a service on their technology. You pay for the provider's expertise and convenience to maintain the servers, networks, security, software, and the upgrades or changes. No more cooking as you always eat out!

SaaS providers now perform almost any main business functions: HR, Accounting, Sales, Finance, Communication, Coding, Marketing, Websites, and more. The cost benefits dazzle the eyes but consider that when you allow someone else to perform a business function that the customer still sees you.

At a restaurant, if the service is terrible, you never return to that restaurant. In the eyes of your customer – you are the restaurant! Therefore, how you interrogate the provider before deciding to use them and how you monitor and respond afterward is paramount to your business's success.

The rest of this article offers insights and tips to ensure that your relationship with a SaaS provider does not ruin the relationships with your staff and customers.

Training

• Transitioning to SaaS changes your workflow – how will you be trained, and what documentation will you receive?
• Are any other vendors impacted, which will also require training, and who pays for this?
• Your products will require integration with the SaaS provider, so how will you train them?
• How will changes to the SaaS provider service be addressed?
• Do customers require new FAQs?
• If someone has a question, do they go to an internal team, the service desk, or the SaaS provider?

Know Your User

Before you move a service to SaaS, you need to define the user of that service. Deep dive:

• What is the user of this service in terms of ability, technology, the reason to use the service, expected benefits from their view, and dislikes?
• What is the journey of that user as they use the service? Where will there be issues?
• How can the SaaS provider mitigate these issues? How will you know that problems are occurring?
• What messages can you provide the user to help them on their journey or if they get stuck? Can the message be personalized?
• What can you automate for the users, such as renewals, reminders, or upsells, or anything to make the journey more enjoyable?
• Can users form part of your test team to improve the journey's flow or provide feedback on proposed changes before go-live or to develop future releases?

IT Service Management

ITSM is the practice of allowing technology to benefit someone. It is a required business set of processes that engender better, faster, safer technology applications that deliver value. Initially the IT domain, Enterprise Service Management (ESM), is now commonplace as organizations take advantage of the cloud, SaaS, or move to digital products.

Not long ago, more technology services supported a single department, with only Finance reaching out across all areas. Now technology services are so integrated into your work that a change in one place impacts the entire organization and could disrupt your customers. ITSM processes and tools can help by:

• Logging all incidents or requests, no matter who sees them, the SaaS provider or your teams.
• Merging the incident and request data for performance reporting, improvement actions and decision-making. Daily integration is best practice.
• Helping to determine how long it takes for incidents or requests to be resolved or some sort of communication is issued to the customer? Lack of service will increase customer churn, and they might disparage you in social media.
• Creating alerts for monitored services.
• Obtaining historical information to ensure that improvements are of value.
• Enabling user support via live chat, AI chat, easy to find widgets, easy to read FAQs, and reporting on these interfaces' satisfaction.
• Acquiring your customers' level of satisfaction and does this match to the XLAs (Experiences Levels Agreement) with your provider.
• Informing support staff on offers as refunds or incentives during disruptive events or poor service.
• To know when to follow up with customers that require special care.

Metrics of SaaS

At some point, your customers will have issues that highlight your value stream or service pipeline's weaknesses. The tools that you use to monitor, alert, investigate, and respond to these issues can be improved by agreed metrics that make sense, such as the ones below:

• How fast do customers receive a response?
• What do they feel about that response?
• How fast are incidents or requests resolved?
• What is the lifetime value of a customer?
• What is the cost of servicing a customer?
• What is the cost of acquiring a customer?
• What is your customer churn?
• What is the total investment of SaaS over your customer value or cost?
• Is there a group of customers that benefit more from a SaaS provider than others allowing you to decide how best to service those customers?

Final thoughts

The economy of tomorrow will be fully customer (user) centered. SaaS, cloud, digital and ESM will enable your products and services to become more individualized. Your SaaS provider has little value to you if the user journey is full of bad service. Your goal is to leverage the provider to retain and attract customers and staff. Thinking about how this will happen, setting clear expectations, expectations, documenting service examples with metrics in the contract, testing and monitoring service delivery, and having active conversation with your SaaS provider will ensure that the customers' experiences are delightful.

If you are looking for ways to improve your customer experience through technology and digital transformation, let's chat!

SaaS is the future

2020 has caused the world to work from the internet. Whatever you used to do in your own data centers can now be performed by vendors, be they cloud or software service providers, better, faster, more securely, and at less cost than you.

The diagram below indicates the trajectory of change from traditional to SaaS (software as a service). Learning how to manage SaaS providers is the new skill that must be learned and introduced into your strategy.

The hardships of this year have also proven that you need agility in your 5 year plan so that you can change along the way.  The capability to pivot based on circumstances is the other new capability of an organization moving towards a digital and VUCA (Volatility, Uncertainty, Complexity, Ambiguity) future. You have to be agile, not just in IT, but the way you think, act, and react. Leadership has to manage and accelerate this change in culture and behavior, which means scaling new ways of working enabled by technology is the new management paradigm.

Allowing a SaaS provider to manage a core function such as Marketing, HR, or Sales is the norm, freeing you to concentrate on creating unique services that benefit your customers and save time for your staff. 

Scaled Agile Framework SAFe®

No matter what blend of Agile that you are using (Scrum, Kanban, DevOps, AgileITSM, XP, TDD, BDD, etc.), you will need to spread these practices across your business. New ways of working, constant improvement, collaboration, and the elimination of siloes, benefitting from technology, be it your own or others, is the only way to survive. 

Accomplishing this change means a dramatic, and in some cases, drastic, alteration to how things are currently performed:

• You keep your program office but lose your project mentality
• Product and Service Owners are the new organizational role with accountable budgets and teams
• Agile Budgeting replaces annual budgets, and the same occurs to annual reviews as constant and consistent feedback is provided top-down
• Multi-year contracts are swapped for partners that facilitate your agility
• The use of technology to keep you in business enables every aspect of your business
• Staff are not made redundant but instead acquire t-shaped skills
• Customer focus and shifting left from their request or needs drives your product strategy

Organizations need guidance to make these types of change successfully. Enter Scaled Agile Framework (SAFe®).  The diagram on their website visualizes the breadth of their philosophy and impact on an organization. 

SAFe® is a continually changing set of practices that has blended the technology, people, and business practices into a competency-based model: 

• Leadership based on agile and lean: empowerment, self-organization
• Team and Technical Agility: No defects, use of cloud & internet, open-source, SaaS
• Behavior-Driven Development (BDD): products based on the people use them
• Test-Driven Development: code, infrastructure, people feedback in short cycles
• Agile Product Delivery: small changes made often, usually daily
• Lean Portfolio Management: if it is not helping someone, then you don’t do it, constant improvement, reduced technical and cultural debt
• Lean Governance: common or standard data models, budgets are based on the value of outcomes and funded accordingly, guardrails guidelines both corporate and regulatory, business continuity and sustainability is a daily way of acting 
• Organizational Agility: long-term goals but very short-cycle plans capable of pivoting based on breaching a KPI or OKR (Outcome based vital indicators)
• Continuous Learning Culture: effort is rewarded, management changes to a coaching model from a telling model, relentless improvement is mentored, innovation is the goal

SAFe® is the most ambitious version of this framework's scaling technology, leadership, financial, and organizational practices. It supplies examples, training, templates, and a worldwide community of practitioners. It is not for everyone. It is not a program of introducing Safe® that will make it successful for you but instead a multi-year effort of scaling the way your business does things at every level into a new model. 

SAFe® helps you avoid and overcome these engrained practices:

• Budgets by department or project become funding for products and services
• Prioritization of new features or services is based on value of delivery and cost of delay
• Creating your own software is replaced by using open source or SaaS
• Data used and kept by your business is standardized for ease of maintenance and change to new services as needed
• Mapping the way you work end-to-end and ensuring any changes are not localized but instead improve the flow of work and data is the new program office structure.
• Change Approval Boards or freezes are stopped because you trust the testing and release process that has been enhanced and automated. 
• Design thinking is encouraged to solve problems
• Design thinking underpins making things as small and as standard as possible such that any part of your business can use it or improve it
• Everyone is thinking about what can I do to make things better, do things faster and safer, and how can I save effort or time or money

SAFe® Benefits

• Increase the velocity of change: ways people work and the software that supports these changes
• The software lifecycle of Demand-Approve-Develop-Integrate with other code-Unit Test-Performance Test-Submit to Live Approval-Go live is replaced with Experiment-Develop-Test-Go live
• SaaS + Cloud + Digital is the technology trilogy whereby owning your own technology is discouraged (still allowed where regulatory mandates leave no other option)
• Complex projects requiring months or effort are replaced by an understanding of what a new service or feature or technical update will provide a customer or staff member and therefore, this is what is created and deployed
• Technical stability is more critical than new service introductions (think of your customers and how angry they get when things go wrong)
• Feedback, monitoring, alerting are the trilogy of information collaboration and coordination (no silos)
• Legacy infrastructure or technical debt is mitigated by using cloud services aligned with your work and customer practices. Technology underpins the way you do things and not just there because!
• Training on SAFe® culture and practices is top-down and extends to your external suppliers
• Project Management is now Agile Product Management, coordinated across products and services instead of merely helping a department or team
• Prioritization based on what it fixes, how it meets a regulatory demand, what outcomes it being in terms of value and customer satisfaction, or how it helps staff perform a function

Doing SAFe® means:

• You are willing to release small chunks of change daily versus large pieces that might wait months before going live
• You can monitor the impact of that change in terms of issued caused or customer satisfaction
• If an issue ensues or satisfaction is not as expected, then you can easily roll-back the change with minimal effort or impact (go back to the way things were before)
• New skills of negotiating or always thinking of enhancing products via technology are taught in a variety of formats such as hackathons, formal training, a partner working, and management coaching
• Operating and Strategy long-term plans are replaced by short-term vision plans that are customer and market-centric
• Centers of Excellence or Software Factories are created aligning how people working based on data and technology mapping exercises with the approved practices of the organization, which encourages:
• Standard tooling for Enterprise Application/Service Lifecycle Management 
• Standard data and artifact repositories
• Use of SaaS providers for core activities
• Always on testing, monitoring, and alerting across the value chains

A train yard is a frequent analogy to explain software factories and centers of excellence. You need a standard gauge rail for all trains to use, and an aligned place for trains to be monitored and dispatched. This allows trains to move safely across the landscape, delivering people to their locations. Your organization needs to establish the same kind of software delivery practice. This model is what SAFe® uses to foster the fast and safe distribution of technology via an engineered flow of work.

SaaS Safe® tips

• Create a vision of why SaaS and Safe® are being adopted, underpinned by training
• Change the language used top-down from project to product
• Have metrics that make innovation for customers or staff the prime target
• Developers develop and operations keep things up is the most prominent IT silo. Break this by making product teams that own their product or service.
• Technology metrics of Defect Rejected Ratio, Detected Defects, Change Time compared to Market release, Value of Delivery versus Effort are viewed on product boards
• Create fun programs of change such as Kill the CAB, which force the introduction of standard technology components for use by any aspect of the business
• DevSecOps is not an option but a mandatory requirement: you have to test at every opportunity and use security practices and tools to keep your business safe and compliant
• Automate what you can as often as you can, but only if this improves the quality and speed of work

SaaS is the way of allowing someone else to perform a function via the use of their technology. Carefully avoiding vendor lock-in will make SaaS a credible option for your business. The transition to remote working has opened up a world linked by technology, and your organization needs to do the same by scaling the thinking and practices of technology to everything you do. SAFe® is a framework proving your business a set of rules that promotes scaling Agile, Lean, and DevOps across your organization. It is a radical alteration of your culture that will take time and leadership to embed successfully.

Whether implementing SaaS, SAFe® , or just generally digitally transforming your company, Praecipio Consulting can help!

Note: SAFe® is a Registered Trademark via ©Scaled Agile, Inc.