Add a meeting Rate this page

A

I am.

A

Hi, terry sorry, I'm dealing with my son and niece.

A

You can hear me yeah. I can.

A

Hello hi there welcome.

A

We'll just give it a couple of minutes and see if anyone else is going to join us.

A

Okay, well, uh I guess we should get started. So what I wanted to talk about today really was um getting things moving on the uh reference etc.

A

um So uh let me just give you a a a tour of what we've set up so far and then, hopefully we can. uh Can we move to filling some of that out.

A

So, uh if I switch over to the um the best practices website, you should be able to see that uh I've now added added a new architecture section in in this version of the documentation. So this this is a a draft of punch of the the current document documentation. So uh it's successful, but not published on the on the site.

A

Give younk to this in the chat.

A

So.

A

We've got here is some temple and plus sign that we're going to need to fill out. uh So the the way I think need to work with this is is following sort of the basic structure of the methodology.

A

Which is to prevent architecture vision, and so that means giving an overview view of what the key concepts are and spelling things out, that people understand what we actually mean and we're using the terminology that we're. We.

B

Use.

A

Within continuous delivery, so uh in terms of what that represents from a documentary perspective, uh these are the the first four sort of headline pieces is that we we need to get written up um so so these viewpoints uh is, is going to be the the biggest part of the work to start with, and what I mean by this is that we need to capture the viewpoint.

A

Sorry.

B

Seriously.

A

Sorry to cut you off there, um I think we're having an issue with your audio, your your voice, keeps kind of in and out okay. Well, let me see if it works to a different microphone, hang on a sec.

B

Right does that sound any better.

A

Yes, that's much better! Okay, right, all right.

B

So yeah so these and viewpoints. um Basically, what we're looking at here is uh for for any organization that wants to implement uh continuous delivery.

B

We are going to be encountering a large number of stakeholders who each have different concerns in that space, and so.

A

They're.

B

All going to have a a partial view of the problem, and that means that, from their perspective, they will have uh an individual view of what they need to do with continuous delivery, so that it's relevant for their goals and their concerns in within the organization.

B

Now, the challenge is that um very few people will have a complete view from the organization's perspective. So what tends to happen is that people grasp onto a partial set of goals and uh try and implement? You know one part of the methodology without being aware of how that will impact on.

A

Other.

B

Stakeholders and the the overarching process within the organization, so what we need to do in in that space is capture all of those viewpoints and document the view as held by each of those stakeholders. So.

B

Within this section, I've expanded that this out to give an early list of the individual stakeholders who are likely to be impacted, and this is not a complete list. So one of the things that we need to do is um make sure that we we've got a a full set of viewpoints here from any. You know relevant perspectives within a given organization.

B

But this is our starting point and then for uh for each viewpoint, we need to actually capture what that viewpoint is and then spell out the view of the stakeholder who's holding that viewpoint and then address what the what the value is um from the perspective of implementing continuous delivery uh and potentially also address any uh challenges or potential issues that might exist for that particular stakeholder viewpoint.

A

Now.

B

What I've done here is give a a a very basic example, and we probably want to expand on this, um but this is from the perspective of the end customer. So by end customer I mean the person who is consuming the product that someone is using continuous delivery to create in the first place.

B

So this is trying to show that we've got a we've got a chain here and there are multiple stakeholders.

B

Not just within the organization but also focusing on what the organization is actually doing,.

B

So uh so what I would ideally like is to get some contributors working on this section of the documentation so that we can. We can start fill out these these views and and get a good picture of all of this section of the dock.

B

Then.

B

Going back to the overview, uh we then need to look at the drivers and constraints that will be behind any organization, actually doing a roll out of continuous delivery.

B

So these are the fundamental justifications for why you're trying to adopt continuous deliveries of methodology and any key constraints that might prevent you from implementing. You know some part or might stop you from being able to do certain features of the process.

B

uh Then the the the next two pieces are um capabilities and then the assessment of readiness, so the capabilities is really looking at uh what what skills the organization already has in this space. So what learnings are already relevant and then the assessment readiness is really a gap analysis to say: okay, these are the parts we've got. These are the things that we don't have and therefore we need to uh understand which pieces of work we're going to do in order to implement this methodology.

B

uh But this is also the place where you you confirm that senior stakeholders are committed to this and uh and and get a go ahead for what is effectively business change.

B

So I think this is um really the starting point of this reference architecture work and once we've got this piece in place, we we can do um a sort of first round of publishing. So we can. um We can put this out there on on the production site uh and then move on to the the next stages of you know: further documentation.

B

So does anyone have any questions about this part.

A

So um a question from my side, terry! So do we have a plan to reach out to the different.

A

Interested parties to get the viewpoints or what do you have any idea how you can get the right viewpoints and the different individuals that you had listed in there.

B

So probably the easiest thing to do is for us to uh encourage some contributors uh who have um some commercial experience working within product delivery, businesses so, uh for example, people with product management, experience uh or people operating at a cto level or an architecture, governance level.

A

Because.

B

This is all stuff that'd be very familiar to anyone. Who's had to take that bigger picture, strategic view of.

A

How.

B

To do technology change with within a medium to larger organization.

B

So hopefully we should have um plenty of people involved with the cdf already who have some experience in this space, and then we can also reach out to them the members to ask them to see if they can nominate or volunteer people from within their organizations to come and contribute.

A

Okay um and that, but we should stick with the with the members right.

B

There's two bits of this, um and, and so we'll we'll probably be able to access a fairly wide audience because of that, so the the views and viewpoints piece is uh it's sort of continuous delivery. Agnostic uh in the everyone who has worked with a stakeholder or has been a stakeholder in one of these roles will be able to spell out the the viewpoint and and the view from that perspective, because you know they'll have been very very familiar with what that looks like within any software delivery organization.

B

And you know, in many cases we we've got people who are currently in those roles who are contributing within the cdf. So we shouldn't have a problem in getting access to plenty of people who have those perspectives uh where it then becomes more specialized, is uh in the piece around spelling out the implications, and- and so that's where we'll have to then add to the the basic information to say. Okay, here are the parts that are relevant from a continuous delivery perspective, and this is how this is likely to impact you now.

B

Some um some members will already be on that journey and will be able to feed back some of the learning experiences that they've already had and for everyone else. This will be a useful resource to help them set their expectations for what they're likely to encounter in in various areas.

A

Okay, thank you derek, so I mean.

B

Most of these roles are sort of classic stakeholder roles within your typical uh software delivery organization, uh and I'm I'm sure, we've got a whole bunch of people already uh in involved. Who've have worn one or more of these hats and and can help out uh where we might need to explicitly reach out and ask for additional help is from say the legal or brand management perspective uh where we might have less experience within the foundation today.

B

So how do we actually update this? Well, um this.

B

The site itself is uh within the cd foundation, github repository, so uh we can basically treat this as a set of pull requests against a branch on that repository.

B

So you'll you'll find that uh there's a reference architecture branch already set up and there is a um a pull request for that branch against the main uh release.

B

uh But what we need to do is get people contributing against the branch initially to fill this out uh and then once we're happy with the state of the content against that branch, then I'll I'll merge that back into the main site and we'll uh we'll do a release of that level.

B

So hopefully that gives you a picture of some of the work that we need to do at the moment.

B

So this is the bit where I ask the volunteers.

B

I'm not going to make you uh stand up and say yes in the session, but if you want to reach out to me and express an interest in any part of this, that you'd like to add some content to, then that would be very helpful.

A

But I think what we probably need.

B

To do is put together some messaging that we can then communicate to the rest of the organization and the membership uh to try and encourage some contributors to come and get involved in this piece of work.

A

um Now.

B

I don't know if anyone's got any suggestions as to the best way to go about that, but uh that would certainly be useful.

A

About finding people to contribute to this, like, uh I can try to help with that, because when I reached out to people and invited them for the strategy meeting governing port strategy meeting, I heard many positive comments from the people who joined the meeting. So I can go back to them and say this is now happening. Could you please come and contribute these?

A

You know perspectives or pass this to one of your colleagues from within your organization and get their input made part of this, and that could also help us to reach out to additional people saying that these people are contributing. These organizations are contributing.

A

Maybe we should take a look at this and make sure to get your perspectives in this, so that is something at least for the ones I talked about reference architecture. I can do that four or five people from different organizations.

B

Yeah, so you can, for example, link directly into that preview documentation.

B

um So so there's a way to say that here's, a list of things that we need to fill out, um make it clearer to people uh where they can get involved, and you know also it helps to show people the the scale of what needs to be done and right now, where we're talking about sort of a few paragraphs rather than having to write war and peace. So it's a it's, not a huge commitment from any one individual contributor.

B

But if we get half a dozen people, then we'll very quickly uh be able to fill this out and get a good collaborative worldview.

A

Another question about like the pull requests uh flow and so on. Some people may not be familiar with github, or they know they prefer to contribute in different ways. I guess it should be fine to you know, have a google doc or something and ask them to know, give us google that we can fix publishing your contribution ourselves.

B

Yeah we can, we can certainly work around any challenges in in that space.

A

Yeah, okay,.

B

So, um oh welcome to uh melissa and thomas. um Let me just switch back and and show you what we've been discussing here um so.

B

We've got a um a draft overview of uh the the first section of the reference architecture, which has been added to the uh the cf best practices website. Now this is uh on a preview version of the site.

B

Let me put the link in the chat again so that you can see it. I don't think, there's a history in the chat.

B

So what we're trying to do is uh get some contributors to help fill out these perspectives and the primary area being in the viewsmith viewpoint, section where what we want to do is document the sets of concerns relating to each of these classes of stakeholder.

B

And I've got a example here where we need to explain the viewpoint that that stakeholder is is operating from so how they see the world, what their actual view is and then any value add relating to continuous delivery or any issues or concerns that might come from a continuous delivery implementation that are relevant to to that viewpoint, and the purpose of doing this is so that everyone feels that their perspective has been understood and included in the thinking behind a strategic piece of work like this.

B

So from an organizational perspective, this is a sizeable piece of business change. Not everyone will be supportive of that business change and so.

A

An.

B

Architecture like this is about showing that everyone's views have been taken into account and and also demonstrating, basically what's in it for me from an individual stakeholder perspective and what usually happens when you work through problems at this level. Is you find out that the organizational organization actually has conflicting demands on different stakeholders?

B

And so you know one group wants to do it and another group doesn't want to do it because one group is being measured against metrics. That mean it's good to do continuous delivery and another group has a different set of metrics that conflict, and then you need to actually get senior executives to adjust those metrics to align them to the overarching strategy.

B

So I hope that's giving you a bit of a view on what we're trying to achieve here. At the moment, these other sections are all empty. At the moment, we need to fill them out with some content.

A

That is a really good start. I love the different viewpoints approach um and are we and I'm sorry I didn't I missed the beginning, but are we looking to reach out to people in these positions to get review to get their input.

B

So, yes, I ideally what I'd like is to get some contributions from people who are actually in those roles or work closely with those roles in in the recent past, so so that we're we're actually eating our own dog food and getting the customers of this reference architecture product to actually tell us what their problem is rather than us impose our theory about what their problem is.

A

That makes sense.

B

uh So um my expectation is that it should be fairly easy for us to get to talk with people who are in say, product management roles, um our cto roles or architecture roles, um and- and they should all be people who are fairly familiar with this sort of approach anyway.

B

um So it's probably an exercise they've already done within their organization at some point in the past couple of years.

B

So so we should be able to cover off quite a lot of that. From that perspective, and obviously when we get to the technical roles, we we've got lots of people within the foundation who were in those technical roles and be happy to contribute.

B

So that's easy enough where it gets a bit more challenging is where we're looking at things like uh legal roles or brand management stuff like that, where we might not necessarily have active contributors in those spaces at the moment, but where we should have. You know some people in member organizations who may be volunteered to come and help out.

B

And I think the the process of actually going through this will will help to get people to understand why we're doing this and what it means, uh because it's it's all a bit theoretical until you go through one of these exercises for the first time and then it suddenly starts to really make sense when you sit down and and think about. Well, what is the viewpoint from my job position and what what's the perspective? I should be taking what's important to me. What, where are my blind spots.

A

And and I.

B

I hope that you know when we've done this piece, it will suddenly become clearer why it can be hard to implement continuous delivery, even when you've got a whole team of engineers who are jumping at the bit to go and do it.

A

So I have a quick question on this, um so based on the best practices right is there going to be so? This is like a best practices guide. So is there going to be like an implementation of how these practice practices look?

A

You know based on you know, just this is my first time attending this meeting, so I apologize if it's a it's been answered before and such but uh like based off this, is there going to be our it's the next step going to be like hey, let's create some kind of important implementation that takes takes all these best practices and kind of shows it in a form that customer or whoever is going to look at this going to can follow.

B

Yeah, so um that's a very good question and and it's it's the sort of medium term goal of this piece of work.

A

um

B

The the way we're trying to tackle this is, if you like, uh an inverted pyramid balanced on a pyramid in that we're, starting at the very top with the methodology itself.

B

So this is continuous delivery as a theoretical methodology for improving your ability to deliver product to market quickly and that's what the best practices site is all about, and then what we're doing with this piece is now saying: okay, well, you've got the theory, but here's the impact when you start to apply that theory to your organization, and this is who it's going to affect, and this is how it's going to change the way they need to work in order for this to pay off for you um and then that, if you like comes down to a a point which is okay.

B

So what what are the specifics and then the the way we're going to approach that is to then uh have um each of the relevant cdf projects provide a perspective, saying: okay, here's how you implement best practice and the reference architecture using this technology.

B

So so that way, we're we're not mandating a single reference implementation, but what we're saying is is the is the theory and and and the concept and then here's how each of the existing implementations takes that and turns it into a tool that you can use to apply that with within your organization.

A

Got it that makes sense, okay, um yeah, so I'm just coming like this is my first time so like I'm coming in from um more of a software supply chain security aspect, so we've been actually using a lot of tecton and tektons techno pipelines, tecton chains, and we kind of built out like a reference architecture through the cncf. Basically, uh you know the the supply chain, security, best practices, white paper that came out and the reference architecture that came up for that.

A

So you know if the if the, if the community's interested, I can kind of show that off also, but basically it's like an implementation of like how supply chain security can be used in this kind of context. You know in a ci cd pipeline with with all the controls in place and all that kind of stuff.

B

Yeah, so that that's exactly the the sort of thing that we're looking for uh to go into the the community side of of this. So um let me switch back over to this. So if you're familiar with the um with the best practices site, there's a community section here which is set up and ready to go, for uh you know, white papers and discussion um about exactly those types of things.

B

So if if you would like to work on something in that area, then feel free to send me a sort of pricey of what you'd like to produce and then, uh if we're uh comfortable with the the the content, you know general framework of that, then you know you're welcome to then create and submit a pr and we'll uh we'll merge it into into this section.

A

Parse, are we missing a security related title or position here? Maybe we should treat that as a whole, separate section.

B

So we we have the uh the cso viewpoint. So, okay.

A

At the moment, and and.

B

We can we can expand these, so if you feel that there are multiple different viewpoints that we need to incorporate, then we can do that. um I suspect what we'll actually probably do with some of these is um have a a headline title, but then expand this out with a set of tags to say you know this applies to the following job descriptions so so that we can make it easier for people to search on what their role is and link into a relevant viewpoint that sits with that.

A

I like that idea, yeah I mean, I think the right. I think security should be on the mind right. I mean everybody in that in terms of the views that we kind of listed out there. um I think it's it's. How much I think in the best practices, I think it should be like you should be paying attention to security right. Security is not something is an afterthought, but that each of these roles are kind of responsible for it and how maybe each one.

A

So maybe there should be a section for like how does this help in terms of security? In my viewpoint also- maybe maybe that's that's worth adding here.

B

Yeah and I think we should explicitly when we get down to the implementation roles, like you know, software engineering roles and things like that.

B

We should also express the security perspective as part of that that viewpoint, um we're also operating within the context of the broader best practices, so um you'll see that we've got software supply chain um as a piece in here um and in fact that spans four major categories of which the supply chain security is is one um so you know we, we tried to capture a high-level view of um best practice in this space. This is a work in progress.

B

So if we find that there are important things that are missing from the overarching methodology docs, then we can update those.

B

But ideally what I like to see is, as we move into the the architecture section, we start to expand on some of this now. This is this piece is phase one of the reference architecture, um and I would expect us to need to expand on uh some of this. Typically, if you were following togaf, you would have a you know, business architecture and a technical architecture, etc, etc.

B

Now it's it's not a a perfect fit for what we're doing here, because those things immediately get into the weeds of a particular organization's process.

B

But there will be areas where we're likely to want to expand on.

B

You know some of the challenges that are likely to exist at a a higher level, and we can include that in the in the next round of documentation for this architecture, section.

B

So um any other questions on this anything that I've missed.

B

I'm sure there's lots. I've missed.

B

Well, I I think you know we we need to start somewhere, so this is kind of a nice high level perspective.

B

As we go through this process, it will become more obvious where the gaps are, and so um I I suggest that we um we keep a track of any. You know key pieces that we think need to be included in this documentation as issues on the best practices site, repo, so feel free to post stuff in in there and use that as a memory, so that we can, we can come back to those and add them as we as we get further down the chain.

B

So um does anyone have any specific questions about next steps? uh Oh, does anyone want to volunteer anyone from their organization to come and get involved.

A

So I know something I'm going to do is send this recording to some people that I would love to get them involved. So can you explain really quickly just if they want to contribute to one of these? What's their first step, they just go to the github repo and start opening issues or open pr's.

B

Yeah, so the the the repo itself um can can be found within the cd foundation. Github uh and uh you'll find that it it it. It's called best practices site uh and uh the the the main site uh is at uh best practices, cd dot foundation.

B

um But this is the the view that you're seeing here is a is a preview uh which is publicly accessible. So you can actually see what's in here, but it's not the official published version of the site.

B

Now we can, uh we can take contributions as pull requests against the reference architecture, branch and I'm happy for people to just start firing speculative prs in uh more than welcome. uh But if you'd like to start a discussion, first then feel free to raise an issue on on that repo or come and join the conversation in the best practices, slack channel or just out reach out to to me and have a conversation.

B

I think the nice thing about this piece of work is it. It lets a much broader audience get involved with with the work that we're doing within the cd foundation. um This. This is all going to be very non-technical as as a piece of work, it's it's all documentation, um but it relies upon people having you know, good, hands-on experience of actually working within software delivery and uh not just as a technical contributor, but but also.

A

uh

B

As someone who has a perspective on product delivery, rather than just software delivery, so so this is the chance for people to get involved and really have a say from from the perspective of what it actually takes to take a product to market rather than just the engineering part of that.

B

And the reality is within continuous delivery. The hard problems are generally in the non-technical spaces, because you know we've got lots of tools for accelerating our pipelines and you know improving the the way we automate our code delivery.

B

But if you're trying to speed up the legal process or.

A

Your brand.

B

Management or all of those other aspects of product commercialization, then that's actually much more challenging and that's where a lot of the sticking points are to success in this space.

B

Okay, um anyone have anything else, they'd like to add at this point.

A

A huge shout out to terry for diving in and getting that started, and at least you know giving us something to look at to begin with. This is excellent.

B

Well, it's it's one of those things where it's much much easier to understand. If you can see what it is, we're trying to do and where the gaps are so rather than constantly having to explain this stuff and get people to understand it's much easier to just build a framework and then say what we need to do is build fill in all the gout.

B

And there's this there's probably a couple of rounds of this that we can do and once we've filled in this first set and published this, then there's an another level of detail that we could then go into and and expand on that again and- and we can, we can keep doing that until we feel that we've got a really rich resource that um is properly communicating the challenges in the space.

B

But I think this, although it sounds like a big undertaking, um it's actually fairly nicely time boxed. We should be able to pull this together quite quickly um and get it to the point where it's useful information, that's tidy enough, that we can publish it and it stands alone.

B

It might not be all of the answers, but it will certainly be another piece of valuable reference that people can start to study whilst we're working on the next phase.

B

So again, I want us to be doing continuous delivery on our documentation, as well as everything else, so it would be nice to to move fairly quickly through this phase. Get some momentum going and know get something out. You know in weeks to month, rather than months to years, as it was with the original site,.

B

Okay, well, if everybody's happy with that, then I think it's probably a good place to wind up. um You know feel free to uh reach out to me or put people in touch with me and we'll get this started and get moving.

A

Thank you thanks, teddy thanks. Thank you. Everyone bye.

A

You.
youtube image
From YouTube: CDF SIG Best Practices - Aug 8, 2022

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/