We have a simplified way to set up your Okta service and we're sharing tips to help! But what does this mean for Compass?

Starting with HCL Compass 2.0.1, we now ship a new schema and package called EssentialSAFe. You can use this schema to help your team follow Essential SAFe ® practices. More information about SAFe can be found on the Scaled Agile Framework® website. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. In our last blog, Introducing an Essential SAFe® Schema and Package for HCL Compass 2.0.1, we introduced the release train and its supporting records, such as the Solution, Team, ProgramIncrement and Iteration records. In this blog we will introduce  you to the SAFe work items available in the EssentialSAFe schema. Introduction In the EssentialSAFe schema, there are three work items available to scope, plan and implement wonderful experiences in your solutions. They are the Feature, Story, and Task. These make up part of the SAFe Requirements Model, which is shown below: Among the work items shown here, only the Feature and Story are available in Essential SAFe. In addition, the Task work item (optional in SAFe) can be used. Below we describe each of these, including how they get created. Features Feature work items are completed within a Program Increment (PI), which generally lasts 8-12 weeks. There are two types of features, a business feature and an enabler feature. Business features are created by Product Managers with assistance from Product Owners. Enabler features are created by System Architects and System Engineers and provide an Architectural Runway. To create a feature, use the New… menu in the upper left. Note – the menu will say New Query if you are using the sample EssentialSAFe database, because no default record type has been specified yet. Work items in HCL Compass EssentialSAFe are stateful records. That means they follow a state model. The following diagram shows the states and...

Starting with HCL Compass 2.0.1, we now ship a new schema and package called EssentialSAFe. You can use this to help your team follow Essential SAFe® practices. More information about SAFe can be found on the Scaled Agile Framework® website. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc. With the HCL Compass Essential SAFe schema, you can create and track an Agile Release Train, and then use it deliver highly desirable solutions to your customers. You can define teams, solutions, program increments and iterations. You can submit, analyze, size, plan and implement features, stories and tasks. The schema is also customizable, so you can fine tune the workflow for your organization. This blog will introduce you the schema and show you how you might set up a release train for your organization. Getting Started To get started using the EssentialSAFe schema, you need to first install and configure HCL Compass 2.0.1, including the Compass Web Server. After installing HCL Compass 2.0.1, create a new schema repository using the maintenance tool. For this introduction, let’s create a sample database too. Now head over to Compass Web. If you installed with the defaults, it would be: http://[servername]/cqweb where [servername] is the hostname or IP address of the Compass web server. At this point, “localhost” would also work if you are using a web browser locally. Log in to the repository and sample database you just created. The default password for “admin” user is blank (no password) - you should change it when you have a chance with the User Administration tool. Now let us look at the sample data, which will give you some ideas on how to set up your own release train. Find the example release train by running the All Release Trains query. This is...

Tired of entering your password? I know I am. If I didn’t have to type in my password 20 times every day, I would have finished fixing all the defects in Compass. Ok, that’s hyperbole, but it really is a pain, isn’t it? Wouldn’t it be great if you could log in once to access all your applications? The good old people writing security standards have been nice enough to give us a solution. It is called “single sign on”. With more and more DevOps products integrating with each other it is becoming even more important to have a centralized identity management solution where you can sign in once, and access multiple applications.  Single sign-on (SSO) prevents the need to sign on to multiple applications separately. Rather than having to sign on for each application, the user signs in once at an identity provider (IP) and this provides tokens to provide to other web applications and services. A token is like an ID card. You show it wherever you go, and it is trusted in many places. If the ID card is trusted, you can do things such as rent a car, walk into a secure building, fly on a plane, and so forth. The same goes for SSO tokens. For any application that is set up to trust the token, it will allow you to log in to that application as the authenticated user. SSO makes it easier and more secure to use different applications, because you only need to log in once and you only do so on the trusted login site.  Authentication and authorization are separate in SSO. The first time a user connects to one of the applications, the user must authenticate by logging in. While the token is valid (usually in 24 to 48 hours), the user does not need...