Component Level View with Overall System Score

[regicsolutions]

Feature Suggestion

Love the idea of this plugin, and how everything is pure json 😀

Haven’t had a chance to play with it but looking at the screen prints I am not seeing a component view where I can see the scorecard at the component level when I open a component entity or more importantly when I bring up a system scorecard it would be nice to get a component level view where I have one system with 50 microservices / components I can see the score of each service together with an Overall System Score.

Possible Implementation

Context

[jvilimek]

Thanks for the idea!
As I understand you have a multiple systems in your organization, each consists from many microservice (components) in a different maturity level and you want to see some aggregated score per system, maybe also with some list of components and their scores?

I can imagine making configurable at which level you want to have the entities to be scored... system (as is) or component (a new way). Or maybe have this somehow to be specified on the entity level, as some systems might be small, some large... also what kind of components would you like to score...only services? Or also web components (FE)? Should they have the same set of requirements? ....maybe entity might have own template/own set of requirements... and if its a composable entity (it has children) we might introduce some overview for this purpose...

WDYT? Any thoughts?

[regicsolutions]

That’s correct, having visibility at the component and system level would be ideal, you bring up some great points, i wouldn’t personally restrict it down to the component type, but would consider making the EntityScoreCardContent more of a EntityHasScoreCardContent where it’s only displayed if there is content similar to how other plugins are doing it i.e EntitySwitch.Case if={isScoreCardAvailable}>

Regarding requirements by entity kind/type. I would suggest having something like a entityScoreCardPolicy where all rules can be re-usable across any entity kind/type maybe follow a similar permission rules/policy scheme like the permissions framework?

anyOf: [
  scoreCardConditions.isEntityKind({
    kinds: [
      'Component',
      'System'
  ],
}),
allOf:[
  scoreCardRules({
    jiraIssues < 15
)}

Thinking it may make sense to have an overall “average” score as shown below where you bring up a parent entity such as a system entity where the average score is calculated based on all component scores for that system, that can be 1 or hundreds this can continue down the parent/child catalog hierarchy where you can possibly get down to the domain level, that’s when the executives start to drool 🤤

https://www.cortex.io/products/scorecard

[jvilimek]

@regicsolutions I am sorry I didn't have time to get back to this. But it makes sense to me to make this plugin more extendable. Is this something you want to contribute with?

[T0RAT0RA]

Hi,

I also have the need to score other kind of entities.
Current implementation already allow that, even though there are some assumptions to be a system .
For instance, scoring an API:

const apiPage = (
  <EntityLayout>
    <EntityLayout.Route path="/" title="Overview">
      <Grid container spacing={3}>
        <Grid item md={6}>
          <EntityAboutCard />
        </Grid>
      </Grid>
    </EntityLayout.Route>
+   <EntityLayout.Route path="/score" title="Score">
+     <Grid container spacing={3} alignItems="stretch">
+       <Grid item xs={12}>
+         <EntityScoreCardContent />
+       </Grid>
+     </Grid>
+   </EntityLayout.Route>
  </EntityLayout>
);

It will try to find ${jsonDataUrl}/<api-name>.json.

Now what @jvilimek proposed here #123 (comment), to have the namespace and kind as part of the scorecard path, would make it easier for a backend to identify the entity, and build logic to retrieve its scorecard.

While at it, I would replace the references to systemEntityName by entity, and support Entity References, like:

{
  "entity": "api/foo"
}

{
  "entity": "default/api/foo"
}

{
  "entity": {
    "kind": "component"
    "name": "abc"
  }
}

(with namespace being optional)

I would also add a Kind (or Type) column on the ScoreCardTable, for sorting and filter.
It would also be nice to be a property so we kind build different scorecard pages, per entity kind.

If the property Kind is set, it would also be used to fetch the all.json file: ${jsonDataUrl}/api/all.sjon, ${jsonDataUrl}/system/all.json, falling back to the default ${jsonDataUrl}/all.json when not set.

I can help with the implementation.

[regicsolutions]

Hi,

I also have the need to score other kind of entities.

Current implementation already allow that, even though there are some assumptions to be a system .

For instance, scoring an API:

const apiPage = (

  <EntityLayout>

    <EntityLayout.Route path="/" title="Overview">

      <Grid container spacing={3}>

        <Grid item md={6}>

          <EntityAboutCard />

        </Grid>

      </Grid>

    </EntityLayout.Route>

+   <EntityLayout.Route path="/score" title="Score">

+     <Grid container spacing={3} alignItems="stretch">

+       <Grid item xs={12}>

+         <EntityScoreCardContent />

+       </Grid>

+     </Grid>

+   </EntityLayout.Route>

  </EntityLayout>

);

It will try to find ${jsonDataUrl}/<api-name>.json.

Now what @jvilimek proposed here #123 (comment), to have the namespace and kind as part of the scorecard path, would make it easier for a backend to identify the entity, and build logic to retrieve its scorecard.

While at it, I would replace the references to systemEntityName by entity, and support Entity References, like:

{

  "entity": "api/foo"

}

{

  "entity": "default/api/foo"

}

{

  "entity": {

    "kind": "component"

    "name": "abc"

  }

}

(with namespace being optional)

I would also add a Kind (or Type) column on the ScoreCardTable, for sorting and filter.

It would also be nice to be a property so we kind build different scorecard pages, per entity kind.

If the property Kind is set, it would also be used to fetch the all.json file: ${jsonDataUrl}/api/all.sjon, ${jsonDataUrl}/system/all.json, falling back to the default ${jsonDataUrl}/all.json when not set.

I can help with the implementation.

That's great, @jvilimek i am a bit tied up with other initiatives at the moment maybe we can assign this one to @T0RAT0RA for an initial MVP?

[jvilimek]

Thanks! Adding a couple of thoughts

If the property Kind is set, it would also be used to fetch the all.json file: ${jsonDataUrl}/api/all.sjon, ${jsonDataUrl}/system/all.json, falling back to the default ${jsonDataUrl}/all.json when not set.

Nice, @T0RAT0RA you read my mind :)

That's great, @jvilimek i am a bit tied up with other initiatives at the moment maybe we can assign this one to @T0RAT0RA for an initial MVP?

@regicsolutions Well, it's up to @T0RAT0RA if he has time to hack something together? I will be more than happy to review/help in any way but coding as at the time we do not have any use case for it in Oriflame.

[jvilimek]

Also, it will be probably a breaking change in terms of storing/providing the data. It would mean a couple of things on our side as well, like adjusting the paths for uploading the scoring results... but not a big deal.

[T0RAT0RA]

Ok I'll propose somehting in the next few days.
I'll make it backward compatible with a new configuration key, useEntityRef or somehting.

[jvilimek]

Thanks a lot!

Thinking of backward compatibility...maybe more calls, but it could be done also like fetching ${jsonDataUrl}/{namespace}/{kind}/{name}.json, falling to ${jsonDataUrl}/{kind}/{name}.json, falling back to the old-style ${jsonDataUrl}/{name}.json .. similar way, how you have proposed the "all.json" fetching...

[regicsolutions]

Good to close Thanks @T0RAT0RA