Speckle + ISO-19650 standard

Features & Ideas
1

Hey all,

I think Speckle has come a long way from just being able to share some information between software, to a full-on GIT approach on geometry and collaboration between models and disciplines focussed on objects and I think this can be the future of changing the way we approach our design processes. As I am working on projects with (Dutch/Belgian) contractors and clients, I am still struggling to propose Speckle as it is (for most our cases) only applicable for work in progress information.

I think Speckle can still grow a lot in functionalities regarding collaboration in large teams/organisations. To match with the change in market, we can look at how to implement the ISO-19650 standards into speckle to make it better usable and adoptable to designers/contractors/clients

  • One good addition to the speckle tool would be revision management on a stream (as proposed in this thread: Idea: Version (/revision) control through Speckle (with metadata, information states and projectroles) )
  • Another much more important addition could be the ability to organize multiple streams to one “organization”. Much like the repository organizer in Github you could then be able to create streams/repo’s inside that organization and define teams to address certain access to these repositories.
  • Add BCF functionalities to Speckle to track issues within the organization/project you create, to make clear communication possible on objects and/or models. Preferably with pinpoints of locations of issues to locate the position of issues as well :slight_smile:
  • A third one important one in effective collaboration is to be able to maintain different states on a stream. With this I mean “WIP”, “Shared”, “Published” and Archived.
    these states should work as “glasses” on which you can access certain states of information. e.g. a user from another team is not allowed to access the WIP info of your team, as it is prone to changes and might be wrongly used to base design decisions on. To saveguard this, there are multiple solutions possible with one my preference
    • The solution would be the ability to let speckle create a Fork of the stream based on the outcome of certain review processes. This means there will be multiple streams which will have the posibility to (right based) Fork from WIP to Shared, Shared to Published and any stream to Archived.
      • This solution allows different owners of different streams: E.G. According to ISO19650, the client is owner of the “Published” state of the info (proposition explained below)

This works on principle: provide and consume. (I will add visualization later)

  • WIP user requests a state of the main stream to be “fork-able” (only objects with S1 or higher). Reviewer will review the information and approves (or denies) the request.
  • On positive result of review, Speckle will fork this state of the main branch to the “Shared” stream of this stream and thus update the information consumable by other teams. In this way a controlled flow can be started in communication to other teams. The key functionality here is the “review” step based on the suitability of the information. Without review, everything and anything can be regarded as WIP.
  • this is Different for Shared to Published. This again will provide only the elements/information with a certain “suitability” (lets say S4) to be reviewed. The review however will be done by the owner of “Published” instead of a reviewer on “Shared”, as the ownership is transfered from contractor to contracting party (Client will accept transfer of information, and make the information “Contractual”)

These functionalities combined will make it better possible to baseline information and do better quality assurance on projects. Else we would still need to create model files and transfer this, which would be a shame as this state of information is not captured on the source anymore.

If you feel that this would be an addition to it, I would love to be incorporated in the overall approach and/or consult on workflows if needed :slight_smile: !

5 Likes
2

Hi @Dickels112! Thanks for this really detailed feedback and the offer to further nail it down!

There are some cross cutting concerns that we’ll need to untangle around the revision management and information states - we’ll definitively poke you on that. It does seem like a new role is needed that will have the responsibility to mark various commits as wip/shared/published, and/or create “releases” etc. We’ll need to wrap our heads more around this before we continue this convo though!

BCF functionality is coming to Speckle in the near future ™️ (it’s on the roadmap!) in the form of issues. We’ll for sure have commit & even object references tied to them, so you can actually directly see what’s up where as you say. One of our challenges here will be to create a system that’s powerful enough but also not daunting to use.

On the provide and consume principle, just today @Kateryna & @cristi start working on what we call “received receipts” - a lower level mechanism to track who received what commit, and, possibly, where (what application). On top of this further specs/auditing/etc. can be scaffolded down the line.

PS: We’re also planning for organisations! One step at a time though - we’re trying to balance dev work between improving immediate use functionality (e.g., interop, the viewer) vs. longer term features (e.g., if we don’t extract all the data you need from revit, having coordination features is less relevant).

7 Likes
3

Hey @dimitrie,

Thanks for the swift response. On my projects I am working on some procedures to better track and manage continuous changes in the design. This is all based on the topic I described above so I would be happy to support! Reach out when you’re up to the discussion :). Later this week I will update my post with some pictures to better picture my description.

Great to hear that IMS is on the road map! (I have not checked the roadmap yet, but I will do that soon!)

2 Likes