Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today, Bob will be discussing a complete set of data governance roles and responsibilities. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. And as always, we will send a follow-up email within two business days containing links to the slides and the recording of the session and additional information requested throughout the webinar. Now, let me introduce to you our speaker for the series, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and the publisher of the data administration newsletter, TDAN.com. Bob has been a recipient of the DAMA Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Hi, Shannon. Hi, everybody. Thanks very much for taking time out of your schedules to attend the webinar today. Hope you're having a good day wherever you are. This is a fantastic subject that I feel is really the backbone to successful data governance programs everywhere. It's very important that we start with a very solid definition of what the roles and responsibilities are associated with data governance. So I'm going to share with you a lot of information today and so let's kind of get started. We'll jump right into it in a second here. As I get started, I always like to start by sharing with you some of the ways that I'm going to be involved in the data governance industry for the short term and the long term. As always, the monthly webinar series, the real world data governance series, next month we'll be talking about building an effective data governance framework. And I'm going to allude to that during the session today. Of course, there's always the non-invasive data governance book. I'll be speaking at a couple of data diversity events coming up soon. The first one is in early June, the data governance information quality conference and I'm also going to be speaking at the data architecture summit in October. I really want to let you know about two online learning plans that are available through data diversity. The first one focuses on non-invasive data governance. And the second one, which was just introduced at the beginning of the year focuses on non-invasive metadata governance. And then there's always the publication that Shannon mentioned, the data administration newsletter and KIK consulting, which I consider to be the home of non-invasive data governance. So let's get started. What am I going to talk about today? Like I said, I'm going to share with you an end-to-end complete set of roles and responsibilities associated with your data governance program. So I'm going to talk about a whole bunch of different levels and why we need to have different levels of participation within the program, everything from the executive down to the operational and support levels. We'll talk about how to customize a model that I'm going to share with you. The operating model roles and responsibilities will go through the detailed responsibilities and who needs to participate at each level. And then last but not least, I'm going to talk about something that I'm finding to be really effective in a lot of organizations right now. It's the use of working teams. And I'll share with you who goes into the working teams and what exactly do we ask the working teams to do. So let's get started. The first thing I said I wanted to talk about was the different levels of roles and responsibilities that are associated with a data governance program. If you've attended my webinars in the past, you've seen what I refer to as the pyramid diagram or it can be referred to as the operating model, the steward diagram, or just a set of roles and responsibilities. It goes by a lot of different names and the fact is that typically the set of roles and responsibilities is going to be very different from one organization to the next, but they have some core components that are pretty consistent, at least from what I'm seeing being very consistent within organizations that are implementing successful governance programs. So I'm going to walk through each of the different levels and each of the different roles that are associated with each of the levels. The pyramid diagram that I mentioned I have it on the screen now in front of you. And as I said it looks kind of complex. It looks like it's got a lot of moving parts and the fact is that when I get to the part of the webinar that talks about how you customize this specifically for your need, you're going to want to highlight the things in the model that already exist within your organization and what are the things that we can leverage and also let people know which parts of the model are new and it's going to require some additional resources potentially within your organization as you're getting started with rolling out your programs. And like I said, the roles and responsibilities sit at that backbone core of successful programs because if we're developing communications, we need to know who we're going to communicate with. If we're putting together some formalized processes and who's accountable for the different steps of the processes that also refers back to the operating model. So this is really a core component of a successful program and we're going to go through each of these different levels in detail moving forward. But before we do that, let's talk about each of the specific levels and why they're important. Well, typically I use this setup. I typically define executive roles and obviously they're not going to play a large role in the active day-to-day operationalizing of your governance program. The strategic level which oftentimes is referred to as the Data Governance Council. The tactical level which are typically the subject matter experts of people in your organization. Who do we go to when we have a question about a specific type of data? The operational people are the people that are day-to-day defining, producing and using data as part of their job. And then I'm going to go through the support functions. IT could be considered a support function, audit, legal, all of those different entities that have a vested interest in your being successful with your program. They all fall in at the support level. And the truth is that not all organizations define their levels in the same way. I had a client not too long ago that wanted to swap the operational and the tactical. They said that the tactical was really what I considered to be operational and vice versa. But the fact is that this really needs to be customized per your specific situation. And I've had organizations that have said, you know what, we need to get rid of some of those levels. We need to simplify, simplify, simplify. And the idea is that you're going to need to have these different roles no matter how you set up your program. Whether or not you classify them by the different levels of the organization, it really depends on your organization and what you call the individuals and the groups at the different levels of your organization. So let's start at the very top of the operating model. And that was the executive level. That's typically the tower that sticks out of the top of the pyramid diagram that I shared with you earlier. And you may ask why is it just a tower and why doesn't have any space in it? And the truth is that the amount of space that's identified in each of the different levels of that pyramid diagram, they mean something. Typically it represents at least approximately the percentage of decisions that we take to the different levels. And oftentimes we don't take this data decisions to our executive level. So that's typically why there would not be a space within the executive level of the operating model, because it is really the highest part of the organization. And what I suggest is rather than giving them a new name like calling them the data governance steering committee, there have been some organizations that have done that. But I'd go with whatever they're already called. So when we ask the question of what should we call these people, the first thing that we should do is take a look at what are we already calling these folks? And can we leverage them the way that they exist? So potentially you can call it a steering committee or senior leadership or risk management committee or whatever name you use to talk about the executives that get together from time to time and set the direction of the organization and can also be the ones that set the direction for data governance within your organization. At the strategic level, now that was the top part of the pyramid actually, not the tower that was sticking out of it, that's called the data governance council or an information governance program team or a practice council. Again, look to see if you have representation like the ones I'm going to talk about as we move forward in this webinar as to who the people are that are representing this group or this portion of the model and let's see if there's something that we can leverage and then call them what they're already called rather than creating a new group. But oftentimes that strategic level, that data governance council becomes the ultimate decision maker and actually the ultimate direction giver to the data governance team or whoever has the responsibility for moving your program forward. At the tactical level, I usually talk about the tactical level as being the most difficult to fill but actually in reality in a lot of organizations we can already identify who the people are in the organization that are decision makers or are the authorities in certain subject matters of data. I always refer to them as data domain stewards but I have a client recently that said well what you're really talking about here is the subject matter experts, the enterprise data subject matter experts. I said yeah in reality that's what they truly are and we'll talk about what they do in a minute but the person from this organization said well that's what we're going to call them. So don't feel like you have to go with any of the names that I'm sharing with you but the idea is that at the tactical level we need to have people that represent the ideas in that subject area of data across the organization rather than specifically within one specific business unit. You can call them data domain stewards, enterprise data stewards, enterprise data subject matter experts. Again, look to see what do we typically call somebody in that role within our organization and use that name before we start introducing new language to the organization because you don't want people to spend most of their time asking well what does this role do? Well if you say that enterprise data subject matter experts then it pretty much defines what we're going to ask from these people. So again think about what we're going to call the people at each of the different levels of the pyramid diagram. At the operational level the bottom part of the pyramid diagram and I will show the pyramid diagram some more in a little bit as I go through the specific roles and responsibilities but at the operational level that's where the data stewards reside or you could call them the operational data stewards if you want to differentiate them from the data domain stewards who are your subject matter experts. And for some organizations they'll actually define formal accountability based on people's relationship to the data. So if somebody defines data let's define what their responsibilities are that are associated with defining the data. If they produce data the same thing. If they use data we need to make certain that every single person in the organization that uses data that needs to be protected is aware of the rules associated with handling that data. We don't want to go to our management and say well we've got these people over here and they had to understand how to use the data but everybody else you know it's the Wild West. No the fact is that anybody who uses data that needs to be protected needs to understand what the rules are associated with handling that data and then potentially anybody that defines produces and uses data could be a steward and if you've seen my webinars before you know that I've said that everybody in the organization could be a data steward. I typically say everybody is a data steward over it. Well anybody that has a relationship to the data as a definer producer or user of that data if you're going to hold them formally accountable for how they define produce and use data they potentially can be a data steward using the non-invasive approach. Again we're not looking to go to them and give them more than what they already have we're going to focus on formalizing their level of accountability based on their relationship to the data that they're defining, producing and using. So what are we going to call these people? Do we have to call all these people data stewards? Do we have to let them know that they're data stewards? Well the fact is you really don't. I mean you can let them know that they're stewards and then the level of accountability comes along with the actions that they're taking but these are people in the organization that day to day are defining, producing and using data. We don't need to change their titles we definitely don't want to change all of their titles because it relates to how they get engaged in the data governance program they may be considered to be data stewards or operational data stewards. So figure out what's the best name to call them or do we just use the titles they already have when we start to roll out the program. The support level is kind of interesting. There's a lot of different components that can make up that support level and that the support level was actually what was on the diagram on the left hand side of the diagram kind of the two diagonal bars going up the side of the pyramid and that first of all it needs to consist of at least the person or the people that have responsibility for your program. So whether that's an administrator as it's one person or part of one person's job to a data governance office to a program team whatever you are labeling the people that have responsibility for moving governance forward that is one of the most necessary support levels that we've talked about in the past as a best practice. If you don't have anybody that formally has responsibility for your program your program is going to be at risk immediately. So those first three bullets under support are that function or kind of the administrator, the office, the planning and program team which a lot of organizations need to focus on making certain that they have resources at least to administer the program. The other support levels the IT systems, the IT security, risk management project management all of those listed could be partners of the data governance program if we need to get them involved. So for example let's pick the last one communications. Let's say that the people on the data governance team are not skilled in marketing and communications and that's often the way that it is. So it makes sense to bring in somebody from the communications part of the organization that can help you to refine your message so that your message is resonating in the best possible way with the people that you're sharing your message with. You can look at data governance as almost being a campaign where you need to campaign to the organization and let them know what is going on with data governance, what their role is and somebody needs to do that and you've got a lot of governance already taking place in your organization. Risk management, project management these things are all a level of governance certainly IT security so we want to recognize our partners for what they're presently doing within the organization. All right now let's shift gears a little bit because I kind of walked through the different levels of the organization but I want to talk about some best practices that would be associated with taking this model and applying it to your organization. So the first best practice that I want to talk about is that instead of trying to take your organization and plugging into this model my suggestion is in fact exactly the opposite. Take the model and overlay it over what already exists within your organization. If you've already got a steering committee then let's recognize them as the potential steering committee for data governance. If you've already got stewards or people that are defining producing and using data as part of their job then they already exist but we need to recognize who they are and start to engage with them as being true stewards of the data. So my suggestion is don't try to plug into this model. Use this model and overlay what already exists within your organization and it's going to become a lot less invasive to your organization because you're not going to be creating as many new groups or new roles and new names and such for different people that are playing different roles within your program. As I mentioned before that these two parts of the pyramid diagram start thinking about using names that already exist within your organization. I went through a couple slides of what should we call these people. Let's look for what they're already being called now, what their role is presently and let's use those as the names of the roles at least to get started. If it makes sense at some point to change your risk management council to data governance council because they're focusing more on data governance but we're starting with the risk management council because it is very similar to the makeup of the other council then you want to make certain that you're recognizing the names that you're presently using and change them when necessary but at least to start use names that are already familiar to you and already familiar to your organization. I mentioned this before as you look at the model for the first time as you look at the pyramid for the first time the first response might be wow there's a lot of different levels and this is a lot of new stuff that we need to create for our organization but if we add to our diagram what already exists and what's new and what we can leverage it should decrease some of that fear of people within the organization. So they look and say okay well the data governance administrator in the upper left hand side that's new that's a role we know that we need to play or have somebody play but the data governance partners they're already existing in the organization. We'll talk about the working teams in a little bit but also going down the right hand side that already may already exist but the council might be new. You might leverage your subject matter experts. Again the verbs that I'm using here or the pronouns that I'm using here actually reflect your organization so don't use what I'm providing use the things that make sense to your organization and if it's new call it out as being new. You might do presentations that just focus on the new pieces to help people to understand what all the different moving parts are within the data governance model for your organization and the last thing is really the last best practice or one of the last best practices is you know adjust this is necessary. I had a client that took it and turned it into nine layers and they had a lot of time describing the difference between layer six and layer seven. So what I suggest again look at the levels that I just defined the executive strategic tactical operational and support because they may potentially be being used already within your organization but once you've identified what are the different roles we need to say who are the people in the organization who are going to participate in those roles how much of their time and what exactly is it that we're going to ask them to do as we get them engaged in the data governance program within the organization. And actually I think there's one more best practice I want to share with you and I'm not going to spend a whole lot of time talking about this in the webinar today the common data matrix. If you've read the book non-invasive data governance or you've read the or you've listened to webinars in the past or seen me speak at diversity events I spend a lot of time talking about the common data matrix and what it basically does is it helps you to inventory who's doing what with the data across the organization. If somebody asked a question that needs to be answered with data and they ask it to two different people in two different parts of the organization this diagram can help you to understand why you're getting different answers because people are using different data or their understanding of the data is a little bit different. So the common data matrix is something that we usually share with everybody who attends the webinar. It is a very valuable tool but what I'm suggesting here is the best practice is that we can work in reverse. We can work from the common data matrix and start recording what areas of the organization are using what type of data and who has responsibility and who's the subject matter expert. We can start from that end and work our way backwards to define what are the different roles and responsibilities that are necessary for our program. So we talk about each of the different levels just briefly. What I do want to do is I want to share with you since we're giving you a complete set of data governance roles and responsibilities what some of the responsibilities are that are typically associated with the different levels of the pyramid and for that I'm going to have the diagram pointing to which level of the pyramid it is that I'm talking about. The truth is it looks like there's a lot here for the executive level, the enterprise leadership but the truth is this is not a list of responsibilities. Typically this level of the governance model is made up of people at the C level of the organization and like I said before there might be a committee that already exists. We're not going to give these people specific day-to-day or monthly data governance activities except they are going to be reported to. What is the status of the program? How is the program working? Is it doing what it's supposed to if we have people that are not willing to participate then we need to report that to them potentially as well. But these folks again aren't engaged day-to-day. They're reported to and it's really good if they support sponsor and understand data governance. In fact I typically share that as the very first best practice is that without senior leadership support, sponsorship and understanding your data governance program is going to be at risk immediately. So what we're going to try to do is we're going to try to get on the agenda of those meetings and if data governance or representation from the council becomes part of the agenda item on those meetings it becomes very helpful. That way we can continually keep the people at the executive level up to date on what's happening within our data governance program. Alright so we're going to spend a little bit more time than we did on the executive level. We're going to talk about the strategic level and oftentimes that strategic level is thought of as being the data governance council or something similarly named. And oftentimes the executive level that we just spoke about identify or recognize people that they want to reside at the strategic level. We'll talk about some of their specific responsibilities here in a minute but these are folks that have a vested interest in seeing governance be successful. Like I said before they're aligned with the executive members they typically have direct accountability to those executive levels and what I suggest is that if you're going to have data governance council meetings then every part of the organization would be asked to attend every meeting. And if that means that we need to have an alternate or somebody to stand in for somebody who's on the council if they're not in attendance you know typically in the organizations that I work with I suggest that everybody is represented on the data governance council. So oftentimes we need to have that stand in and now let's talk a little bit about what we're going to ask those people to do. So typically the way I describe it is that the data governance council consists of strategic representation of both the business and IT. We need them because we need to pull together the silos of the organization. And I'd love to hear how many of your organizations have silos. I tend to hear that from pretty much everybody and if we're going to govern data as an enterprise asset we want to look at you know being able to have cooperation across the activities across the divisions or business units of the company. We need to have cooperation and communications and comprehensive risk management. All these things with the data governance council they're at that strategic level to make certain that the people within their parts of the organization are doing what they're supposed to. So let's talk about a little bit about what a data governance council does. And the first thing that they need to do is become educated in data governance which means that we need to have some meetings early on to help them to understand what role they play but also to understand the approach that we're taking to governance within our organization. So we need first and foremost to get them educated on what it means to have data governance in place, how it can and will work within the organization so that they can help people within their parts of the organization to stand behind and activate as it comes to as it comes to that part of the organization. The data governance council also approves things that get they get escalated to their level and they're also responsible for pushing data governance into their areas and so the fact is it sounds like we're going to be asking them a lot of things to do but the fact is that I get asked the question a lot how much time should we expect people with the council to participate and I'll share that with you in a minute. I know you don't want to estimate too high because they don't these people they have much more to do than just worry about the data governance council. It really needs to be directed to communication when you're working with them and get it to them quickly so that they understand what is needed from them. So what else does the council do? They make decisions at a strategic level. They meet regularly. They identify and approve the direction for the organization. They advise the council owner or a person who's directing the council as to what's of interest to them. Maybe we need to focus on a new aspect of data governance and that's protecting sensitive data or maybe we need to improve the understanding or the quality of the data. They're the ones that might be in position to be able to advise you as to what the most important things are for your data governance program to be doing. So now comes the question of how much of a time commitment is there for people with the data governance council level and the fact is if you ask for too much they're going to laugh at you because this is not their first and foremost activity. I had somebody come up to me at a conference recently and say that somebody had instructed them that data governance council members should spend 25% of their time on data governance and the fact is that's ridiculous. I mean I told them when they go back to their organizations and say that you need 25% of these people time for data governance for the data governance council when they're done laughing at you you could share with them what you really mean and I'm going to share that with you right now. So if you're going to have once a month meetings or once every month other month meetings they number one need to be able to allocate the time to attend those meetings. So right off the bat we were expecting that maybe 60 to 90 minutes a month could be asked of the council members at least as a start just to get them educated and knowledgeable in what's going on and what their role is going to be in successful governance within the organization. They also need to have time to review and read and comment recommend and approve different things that you're sending to them. So whether it's your data governance policy and your mandates or even your operating model of roles and responsibilities they need to have time if you're going to take a new data governance information governance records management policy to that level to be approved they need to make certain that they know that they have time to be able to be allocated to focus on these things. So so far we're talking 60 to 90 minutes for a meeting we're talking 60 to 90 minutes to review things and this is on a monthly basis we're not asking for them to do things daily but there is a potential that they could be asked to do things that are outside of attending meetings or just approving things that we're sending to them and that is that they're the ultimate decision makers when it comes to issues that are escalated from the operational to the tactical and then to the strategic level again we're talking about the strategic level of the organization they need to have a bit availability to resolve the data issues that are escalated to their level whether that's five and typically I suggest that that's five to 10% of the issues that get escalated to that level. If all of your issues need to be resolved by your data governance council I typically say that there's a deficiency in the tactical level of your program and I'd love to talk to you about it if you wanted more information about what that means it just means that you're taking every decision to your strategic level it shouldn't be necessary you should have some level of authority within the tactical level of your organization as well. So typically when they hold the meetings we're not solving data governance issues at the council meetings this is time beyond the meeting time to become educated and the approval of things that we're sending to them so this could be and this is really going to depend on the number of issues that you're escalating up to your data governance council level. Alright so let's talk about the tactical level for a little bit so the data governance council plays a key role but again they're not necessarily engaged day to day the people that they could be engaged day to day are at the tactical and the operational level so let's talk about them for a couple minutes here. The data domain stewards are the subject matter experts or the custodians or whatever you want to call them within your organization that's one of the key roles that take place or participate at the tactical level. I also talk about data steward coordinators who would be people within certain parts of the organization that coordinate the activities or coordinate communications with the stakeholders and I'll spend a second talking about them after I get through the subject matter experts or the data domain stewards. So let's talk about what are some of the specific responsibilities for the data domain stewards and so typically they are not responsible for looking at data from just the viewpoint of one specific business unit they are more responsible for looking at the data as an enterprise asset and making decisions that potentially affect multiple people across the organization. Now the fact is that there could be multiple subject matter experts who you need to get together and have conversations to resolve issues that are pertaining to data that's being used by everybody in the organization. So typically these people are identified by position so for example within a university it could be the registrar that's responsible for student data or the bursar that's responsible for financial data that might have policy within your organization that states who the domain stewards are, who the subject matter experts are. So certainly look to see if you have that. And the fact is when they're acting in the role as the subject matter expert their affiliation to their business unit should really become secondary because again they're looking at the data from a cross business unit perspective rather than by a business unit by business unit specific level. They've evolved their facilitator and bringing the resolution to issues pertaining to the definition production and usage of data. And as I mentioned before they could or they could not be the authority or the decision makers. If they are the decision makers and we're escalating an issue up to them then we don't need to take those issues to the data governance council. We might need to educate the council on the fact that these issues existed and that they took place but the data domain stewards play a critical role because again they're the ones that are looking to break down the silos and try to get data to be consistent across the organization. So some more responsibilities for the domain stewards are that they're responsible for escalating those issues to the strategic level if they need to, if they can't make the decision themselves. They may have some level of responsibility for documenting classification rules compliance rules, business rules or they might delegate that to somebody in their part of the organization to document those things. They can be responsible for making certain the rules are communicated, rules RULES are communicated and oftentimes the data domain steward or the enterprise subject matter expert is engaged in the working teams that I'm going to talk about when we get to the end of the presentation here. So what are some of the typical traits of people that make up good data stewards? And I just wanted to share a couple of them with you here. First of all they have a vision of what data, the future of data looks like. They're looking to improve the way things always have been within the organization. They have the ability to motivate and they're setting good example of data related behavior. Definitely the most important perhaps is that last bullet which says that they have the personal interest, the intuitive ability and the communication skill to facilitate conversations with people from across the organization to the best ability to achieve a win-win within their organization. And so let's talk about the steward coordinators which sit at the top of the columns in the common data matrix that I shared earlier and as I mentioned before they can act as a point communication person with the data steward. So instead of the domain stewards communicating to all the different people in the organization that are data stewards we would want to go potentially to the steward coordinators from each function and share with them the information that has to be shared with the stewards within that part of the organization. They typically get involved in identifying the operational stewards working with the domain stewards to make certain that a project is being completed on time and on budget. A steward coordinator typically doesn't have decision making authority but they play that pivotal role in making certain that people are communicating effectively with the data stewards of the organization. And last but not least there's the operational level and actually we'll talk about the support level here in a minute but the operational level as I talked about before anybody who defines or produces or uses or defines and produces and defines and uses any one, two, or three of those three actions if they're being held formally accountable for what they do with the data potentially they could be data stewards. So it could potentially be everybody in the organization let's talk about what these folks do. Actually before I get started I wanted to share with you a real quick list of what I call signers rules for becoming a data steward. Everybody has to have something named after them. So this is signers rules for becoming a data steward. The first one is that a steward can be absolutely anybody in the organization and that really being a steward is describing what people do with the data. It's not a position. You don't have to hire people in to be data stewards. A data steward doesn't need to be called a data steward. It can be called whatever they're already called within the organization. Oftentimes stewards don't need to be told how to do their job except for where there's deficiencies where they're not doing things that are in the best interest of the organization. I don't like the idea of public certification of data stewards because it really the stewards do what they're hired to do by the organization. They're not hired to be data stewards. They're hired to perform a function and that function defines, produces, or uses data as part of that function. Also instead of saying there's only one data steward for each type of data, the fact is that there's as many data stewards as there are people that have relationships to the data. You might have multiple people defining the same data in different parts of the organization. People that have the responsibility for producing the data and using the data is the no brainer. We're going to know that we're going to have a lot of different data stewards and we need to set up our program in such a way that it counts for the complexity of just not having a handful of data stewards. It deals with the complexity that potentially everybody in the organization is a data steward. I just want to go back to that one slide for a second. The number eight bullet point in these rules is extremely important as well. If we're going to talk about how we're going to train the stewards within our organization, if we focus on formalizing accountability for things that they're already doing rather than coming to them as something that's brand new to them, that's how I suggest being as non-invasive as possible. Let's look to what they do. Let's help them to do it in a better way or in a way that's going to be better for the organization before we start handing them additional things to do. We're going to formalize accountability that perhaps should already be formalized, but we're going to do that in a very non-invasive way in the organization. One of these operational data stewards do, we've got people that are defining, producing, and using data. We need to make certain that they understand what are the best ways to define and to produce and to use data. As people who have that relationship to the data, if we can now help to educate them on what that means and where it's really beneficial to the organization, that becomes extremely important. Some other things that the operational stewards do, they participate in definitions, they participate in producing the data, all of these things. I don't want to read through them but I'm glad to say that you will get copies of the, or you'll get a link to the slide so you can see them later, but there's a lot of different things that stewards are already doing with data and if we can help to formalize their accountability for what they're doing and not come at them with a club and say okay, you've got all these additional things you need to do, they may be much more willing to listen to you and participate in governance and stewarding activities. If you say you know what, you're already doing this, we can help you to do it better. So now let's talk about the left side of the pyramid diagram and that's the data governance planning or program team, the data governance administrator, and then the data governance partners, which oftentimes IT is one of the biggest partners that data governance has. If you think about it from the diagram perspective, everything that's in the pyramid, the triangle part of it, including the tower sticking out of it, oftentimes those are business roles but we need to get the technology folks involved and they have a lot of knowledge of the data and a lot of knowledge of the systems and in fact I've been told by a lot of organizations that the stewards of the data are in IT and I know that that's trying to change in most organizations. So if we think of the fact that the two stewards are people within the business units that are defining, producing and using data, then IT plays a different role. They could be data subject matter experts pertaining to specific data within a specific system or they could be system subject matter experts but IT is typically one of the first partners that works with the data governance planning or program team as you're moving forward. Other potential partners include risk management or project management. If you think about it, IT security and all of those things, that these are organizations that could potentially be called governance organizations already as you're getting started because my suggestion is to tell your management that data governance already exists or we're already governing data, we're just doing it very informally, inefficiently and effectively and things like that. So what we want to do is recognize people for what they do and give them a role to play within our governance program instead of again piling on to them and giving them a lot more work to do. So let's talk about what's the responsibility of the administrator or the office or the planning team of that group. So typically, what I found with organizations is that they have a data governance planning team that evolves into a program team. So if you think about it during the planning phase, we're going to engage people at tactical and strategic level more than once we get to the point when we roll out the program, we're going to switch our focus mostly to the operational stewards. So we're going to get these folks involved in the development of the program and architecting the solution and assisting and administering the program and certainly facilitating the data governance council meetings. Somebody has to have the responsibility and typically that's the administrator or the person that has responsibility for data governance within the organization. They participate in the development and delivery of educational materials, they report results to the council. All of these things are the responsibility of that administrator or that group of people that have the responsibility for data governance. So I'm often asked how many people should we have in our data governance office or our data governance team and the best consulting answer that I can give is it depends. It really depends on your organizations. I hear all the time that we need to right size the solution to the organization. My suggestion is don't start out with a team of numerous people on your data governance program team or your data governance office because you're going to constantly be asked what are these people doing. Don't add to your team until you get to a point where there's things that you're going to have these people do. So you can start out small. It can be one person's responsibility and then they can have partners in crime, people that are part of their environment or other people that want to get engaged and start to build out governance that way. But don't start with overkill as far as the number of people that you have on your team. So the data governance administrators play a key role within the program and if you don't have somebody who plays this role, who's doing these things, your program will be at risk immediately. So we need to keep that in mind. What are some of the responsibilities of the partners, the other partners that we're talking about? Well, typically their responsibilities fall under the things that they already do. If IT security is a partner, if risk management is a partner, if project management is a partner, they already have marching orders as to what they need to do and they can help you to make certain that your program moves forward effectively. But they're already doing forms of governance that need to be recognized. So we want to make sure that they're going to be responsible for technical data handling, for securing the infrastructure, all of those types of things. But they're also the subject matter experts when it comes to the technical aspects of the data and the technical aspects of the systems that are using the data. So what are some of the additional responsibilities of the partners? It is to ensure that the policies procedures are in place, ensure that the strategic data is modeled if need be, provide technical support if that's what their role is. You know, the partners do what they do and we should learn to find ways of leveraging what they're doing and we could even use the term governance to describe how what they're presently doing is already related to governing the data within the organization. So one of the last two things that I want to talk about and then we're going to turn it over to Shannon for some questions is who are the people that participate at each level? And it becomes very important for you as you're documenting your roles and responsibilities to provide these three things. So the first part is in the black, that's actually I have the similar role here, data governance council for both, you know, that's the name and that's the level, you know, who is it made up of and how much of their time is going to be expected. So we get expected to be needed when it comes to governing the data. So if we need to suggest, you know, at least recommend all three of these things, same thing holds true for the subject matter experts at the tactical level and the data stewards. Again, these are just examples of what organizations have used to say who makes up the people that are going to be participating at that level and how much of their time is going to be necessary moving forward. So the operational data stewards, they're the folks day to day defining, producing and using data that we're helping to understand what governance is what the role of the steward means and what types of tools and artifacts and things are available to them at the operational level to help them to manage the data better at the operational level. So we know as part of our roles and responsibilities document that we need to not only define, you know, the name of the role with a level of the role, who's going to participate, how much of their time is going to be necessary. And then of course the last thing will be, you know, what are the specific responsibilities that we're going to give to people at this role, specific role within the organization. So here again now shows the data governance working team, which is going to be the last subject I'm going to talk about and putting together these teams that are made up of tactical and operational folks that are focused on solving a problem or at least being engaged to move some aspect of your program forward. And then there's the data governance administrator. Again, we want to say who's it made up of and how much of their time is going to be required moving forward with the program. So ultimately, well before I show you what a page basically looks like from a roles and responsibilities document, let's talk about the responsibilities of the data governance working team and how do we use these working teams to be successful within our organization. So oftentimes these working teams are made up of people at the tactical level or at the strategic level or actually most often at the tactical level on the operational level to solve specific problems. And oftentimes these working teams are convened by the data governance council with assistance from the people that are administering the program. So what do we use working teams to do? Well it really depends on what you're trying to accomplish with your data governance program. Are you looking to improve data definitions and standards, creating a glossary dictionary catalog, are we looking to improve understanding of the data that we're going to create working groups that are focused on specific critical data elements that are shared across the organization. What we're going to call these things, how they're going to be used, how they're defined, what their values are across the organization. You may use the working groups to improve production and collection of data, improve usage and understanding of the data quality. I'm working with the client right now that is creating these business unit working teams to go division by division and educate them on what protecting sensitive information looks like and to understand what level of knowledge do they have about the handling rules associated with how the data is being classified. So we're doing one business unit working team per business unit and this doesn't have too much cross representation of the organization. This is specifically solving a tactical problem within one part of the organization. So this was the page I was alluding to. What you see on the screen now is typically kind of an excerpt of one page from the operating model document. It has the name of the group, the level that the group resides at, who it's made up of, how much of their time is going to be necessary, and then the specific things that are the responsibilities that go along with that specific role. So if we have a page for each of the different roles within our organization, it's going to be very helpful to be able to give people the knowledge as to what is expected of them and how much of their time is going to be necessary as we roll out our program. And the most important aspect of this page basically is who's going to be making up the working team? How much of their time is going to be necessary? We want to make certain that we clarify that and that we give a good estimate as to how much time is going to be necessary so that people have the right expectations going into the development of their program. And this is a diagram that I know is difficult to read, but basically it's a racy diagram. And so whatever the pilot activities or the value add activities are that you have the working team working on, you might define them in a racy matrix where down the left-hand side you have specific steps that are being taken by this working team, and then across the top you have the different roles and responsibilities that we've talked about during the webinar. But then we want to make certain that we articulate what are the specific activities of the working team? When do they get involved? How much of their time is going to be necessary? And what we can ask of them moving forward. So the working teams are starting to play a critical piece because that's really where the rubber hits the road and we start to execute and operationalize data governance within the organization. So I know I've shared a lot of information with you in a very short period of time, but these are the things that I discussed today. I went through the different levels. I talked about some of the things that might be necessary to customize your model to fit your organization. We talked about some detailed responsibilities and who participates at each level. And then last but not least we talked about the working teams and using the working teams to implement the tactical solutions within your organization. So with that, before I turn it back over to Shannon for the Q&A, I just wanted to make you aware of the webinar next month, I'll be talking about building an effective data governance framework. And we'll talk about roles and responsibilities as being one of those core components to a successful data governance framework. And with that, I'm going to turn it over to Shannon to see if we have any questions today. Hi Bob, thank you for another fantastic presentation. And just to answer the most commonly asked questions, just a reminder, I will send a follow-up email by end of day Monday for this webinar with links to the slides and the recording. There was also a request for the matracy, which is also going to be included, so we'll be sure to get that to you. So diving in here, Bob, what is the most basic model or at least amount of roles that can exist to support a data governance system? That's a great question. I don't know if I've ever been asked that before, what kind of is the bare minimum? Well, certainly you're going to have operational data stores, but you're not going to engage them too much. So you might not necessarily need to. I mean, you might actually engage them in teaching them the things that they need to do in order to formalize what they're doing in their job, but we're not going to be asking a whole lot of different things from them. So you might consider very much minimizing the need or what you share around the operational level. I've seen the executive level taken off of the diagram before, too. So seriously, the strategic and the tactical level seem to be the most important. I've seen organizations, again, trying to simplify the model and just using the strategic, the tactical and operational, and not having anything on the support side as well. So at least at a bare minimum, you'd want to have the three levels. And again, identify what already exists within your organization. I hope that answers the question of what can we do to minimize it, but the fact is if a lot of these things already exist in the organization, there might be less of a need to minimize it significantly. So, Bob, we don't distinguish between operational and tactical in our data governance structure. Anyone else in a similar position with regard to data stewards? I have not found it to be successful if you don't have people that are looking at the data across the silos, and that is the tactical level. So you're going to have operational stewards. You already have them. By all means, everybody is a data steward, right? But at the tactical level, where you have people who have responsibility for data across the organization, that's the only way that I've seen organizations able to cut down some of the silos that they have in the organization. If nobody's looking at that data across the organization, then there's a mistake, and that is the tactical level. So I'd say I wouldn't blend the operational and tactical. I'd keep them as they are. Could there be a possibility of conflict of interest between tactical and operational levels with individuals playing in both layers? And how do you address that? There's always going to be conflict, right? That's the reason why we need to be able to escalate issues from the operational level to the tactical and then to the strategic if necessary. There's always going to be issues. If everybody already agreed on the names of what we call things and how they're defined, wouldn't the world be a much merrier place? There's always going to be conflict, and that's why you need to define the operating model in such a way that you can escalate issues up to get them resolved. So that just seems to be a given within most organizations. My organization just launched working groups. The structure of the groups are unclear. So how do you set a structure for the different working groups that have different focuses? Well, typically what you're going to do is you're going to give you as an example the protecting sensitive information example. You know, we have people from risk management and IT security that are just part of the team of working with the business unit working team. So those are partners that are getting involved. The administrator of the program has to be involved. Then we want to make sure that we engage the appropriate tactical level people that have knowledge about or maybe even the authority to make decisions about data in a specific subject area. And then you might want to involve the people at the operational level as well. So there's not one clear structure for how the working teams are made up, but typically you're going to have the administrator. You're going to have some domain stewards. You may engage some operational stewards and potentially some of those other partners that I mentioned. So again, the working teams are the critical component of making this work. So my suggestion is that you include anybody that's going to add value to what it is that you're trying to do with that working team. And what's the typical size of the data governance council? Absolutely. These are great questions. Everybody wants to know about how big some of these things are. Well, the council typically has representation of each of the different business units and IT within the organization. And so if you've got a lot of business units that kind of roll up into a specific functional area or maybe the reverse, maybe just that functional area needs to be represented. I typically find that if you have meetings of more than 10 people, it's a little difficult to manage those meetings. So I guess if you were going to ask for a ballpark figure, I'd say try not to go above 10 or at least make certain that you're engaging only the members of the council that need to be engaged when you're engaging them. If you bring people to the meetings and the things that are being discussed have nothing to do with them, they're going to be, excuse me, less likely to appear at the next meeting because you didn't really need them at the first meeting. So my suggestion is make certain that you have representation across the organization and don't make it too big. I think we have some time for additional questions coming in just a couple more. But if you have questions, Bob will always keep them coming in whether we have a chance to get to them today in this webinar or not. Bob will write up answers and we'll also include that in the follow-up email. So Bob, do you think it is a bad practice for an organization to set a policy that only managers or above can service data stewards? Only managers and above? Well, if the managers and above are the only people in the organization that are using data, by all means go ahead and do that. The fact is that it's not just the managers, it's the people that are day to day performing the business functions that are the actual stewards of the data. And so if you have an organization that's so large that you're going to actually refer to the operational data stewards as being managers, at some point you're going to need to then have a more operational level that would be people that are not managers, because you want to impact the behavior of everybody in the organization, not just the handful of people that you're going to engage. I don't like the idea of the operational level consisting of managers unless they also then have the responsibility for all the people that work for them to make certain that they understand their responsibilities as well. So I would vote no for the data stewards only being managers and above, but it really depends on how your organization is structured. I can't give you a blanket no to that, but I would say I most likely not to have managers as your operational data stewards. So categorize as data governance as part of IT governance. What are your thoughts on how the two work together? Well, I haven't really seen data governance as part of IT governance. I guess it could be. IT governance often has to do with more of the infrastructure and the project planning and the system development and those types of things. I typically don't see data governance falling under IT governance. However, I do see it's not really even emerging anymore. It seems to already be here, the whole concept of information governance that could take into consideration structure, unstructured data. I don't think the data governance and IT governance are really the same thing, but I think that the IT governance is a real thing that needs to be implemented. It's just, I guess they could learn from some of the things we're doing with data governance, but some of the activities of IT are different than the activities of the data governance group. And I think we can slip in maybe just one more quick question. We have a little less than a minute. Any experience or reference of applying design thinking and value proposition design to the process of creation and maturity of a data governance government and its processes? Seriously, I get less than a minute to answer that question of all the questions. It can't be. So the value proposition is really important. And I'm going to share this with you because again there's a recent TDAN article that I wrote about this, but the idea is that we really need to get our senior leadership to stop asking data governance necessary. And why do we need data governance? We really need to get them engaged in asking the question, how is it going to get done? And if we can do that, if we can move them from understanding that it's necessary to, what's the best tactical way to implement it? That's when you're able to bring into them what the value is that comes to the organization, but they're more interested in how are we going to engage people day to day so that we can be successful in formalizing how we're managing and governing the data across the organization. Great question. I'll try to pick it up in the written answers as well. Alrighty, well that does bring us to the top of the hour. Thank you Bob for another great presentation and thanks to our attendees for being so engaged in everything that we do. You know we do have, if I didn't get a chance to get to your question, please just keep submitting them. We will have Bob write up the answers which will be included in the follow-up email that I will send out to all registrants by end of day with links to the slides, the recording, the matrices, and again answers to the questions we didn't have a chance to get to today. So thank you everybody and hope to see you in the next webinar. Thanks Bob. Thanks everybody, have a great day.


Hello everybody. Thank you very much for coming. My name is Hasib Akhtar from Ericsson. And I have my colleague, Tuber Keise, also from Ericsson. Okay, and we're going to talk about realization of infrastructure and network APIs at the edge. So we're going to go ahead. Okay, so I will start and get you some context for the following discussion related to the APIs. So what we have here is the 3GPP view of what the disaggregated run and disaggregated core network look like. So if you look in the middle of this picture, you see on the right hand side this disaggregated core that contains a number of different nodes. It's both control node and also the user plane functionality denoted by UPF. So we'll put some more emphasis on the UPF during this presentation. Then on the left hand side we have the disaggregated run and it consists of three major pieces here. One is the CUCP, which is the central unit control plane. And this is the functionality that handles the mobility management in a radio network. We also have the central unit user plane, the CUUP, and that handles the user plane processing, which essentially is packet processing. Processing packet is aimed for the radio network. And then on the leftmost side here, we have the DU together with the RU. So the DU here is the distributed unit and the RU is the radio unit. And primarily if you're familiar with notions like baseband processing, the signaling processing, that goes on in the DU. So in today's deployment, the CUCP, CUCU, and also the DU are usually deployed as one single entity in an embedded system. But now we are taking the steps towards this aggregated run. So a couple of these functionalities could typically be moving higher up in the network like the CU parts. They are typically very well aimed for virtualization. If you look at the CP part, it's a soft real-time problem that we are talking about. And if you talk about the UP part, that is packet processing. So it's throughput and latency that are important for this part of the applications. For the DU parts, it's a bit more complicated because we have a synchronous loop going on in this area. So we are actually on a one millisecond level, always making new decisions on what goes in the air. And if you are looking at 5G, which this is aiming for, then we are going down even further. We are talking about making decisions in a 100 microsecond level. So it's a completely different area. So now what we see when it comes to edge deployments, a typical application here is that we are combining the CU UP part in particular, the user plane processing. Together with the UPF function, which is the user plane function from packet core. And this is also something that has been happening in the packet core. You may be familiar with the notion of CUPS, which is a control user plane separation. So in this setup, we see that we place some of the user plane functionality from packet core in the same location as we have most of the centralized part of the radio. And then we need to have a third party application, otherwise this is kind of pointless. And the reason for this is that we want to move this functionality further out in the network for a couple of reasons. One is obviously we want to have a low latency application placed on the edge. There are other applications that we want to limit the amount of bandwidth that goes through the right-hand side in this picture. In the radio network, we are sort of going to handling tens of gigabytes per second in the air interface, but we usually don't have that kind of aggregated bandwidth when we are moving upwards in the network. Then also on the top here, we have another entity. So in this case, we have been using ONAP as an entity for orchestration and also deployment of the functionality. And also in this picture, the crime of edge tags comes into play in order to deploy this functionality. And if you move to the next one, we have a couple of interfaces that Hasib here will talk more about. So on the left-hand side, we have this API A which goes from the network up to this ONAP entity that actually collects a lot of information for the network. And then we have the purple, the API B which is changing configurations in the radio network but also injecting policies into the network. And then we also have these green interfaces that are more related to the actual deployment of the functionality. And there is where the acreno stack comes into play. So by that time, we will go over to Hasib to continue with the API discussion. Thank you, Tarbian. So what we see here on the API A side, which is basically the all of the network that you have in the form of the core as well as in the RAM, that information that needs to go into the ONAP. So these are the information that relates to the user. So for example, the device and the profile of the users, application and service characteristics, the bandwidth, for example, how much bandwidth the user is using or how much do they need. What are the latency sensitivity to these applications?  Then also the network characteristics, like what are their congested network or if there are any specific latency that are associated with the network that needs to be communicated to. And then you have the key RAM related information. How are the mobility patterns? What are the mobility conditions in different parts of the RAM? As well as some of the RF environment related information where you have what type of frequency you have available, which frequency is congested, whether or not you have small cells around or how does the user could be handed off and so forth. So those are some of the information that requires APIs which could be fit into the own app, for example, as an orchestration and management. And then the next class of API, which we're calling API Setup B, so where you can now inject some of those information that you have collected to basically optimize and manage better of the RAM components. And the things that you could do, for example, you could inject UE specific policy information towards the RAM and tell RAM that, for example, if this is a premium user, you provide higher bandwidth or better quality. If there are some handoffs happening, for example, if the user is moving in high speed and going across multiple small cells, then there is no need to hand off the user to the small cells. You keep him to the regular macro cells and move forward. So a RAM component may not have that information, so you use a management and orchestration aspect, in this case, own app, to inject that information to RAM. There are other policy injections also could be done. For example, what are the neighbor relationship between multiple cells? What frequencies are available and configured? How much bandwidth are available in other areas? The traffic prediction in terms of what are the users that are coming in one cell versus your neighbor cells so that you can do a better frequency and capacity management. Also, you could put some of the data enrichment, for example, across domain information. So one of the things are also, for example, here could be useful is the transport network. And RAM by itself may not have the information related to transport. So own app could then, in this case, send transport-related information to RAM and provide this level of granularity and information so that you could do better optimization again of the user experience. And the next one is related to the edge applications, such as AR-VR, IoT, CDN, and or analytics. And there could be others. So those information could then be fed into the acreno edge stack in this case. And this is related to really the infrastructure of your NFVI. So the network function virtualization infrastructure related. And this could be related to the edge application placement. There could be latency, requirement for that application could be regulatory. Then also, of course, you have the compute, such as what kind of CPUs, what kind of pods you get connected to. And networking related to the OVS DPDK or SRIOV or IPv6, for example. On the storage, whether you need onboard or off-board. So for example, for analytics, you need much more type of storage than an application like IoT. It could be for just onboard storage information is good enough.  So those are some of the things that you could send or you could make use of it using those APIs to onboard those applications. And then finally, the API category D, which is similar to API category C, is in terms of the nature and the characteristics, but it does consist of mainly the RAN and the core network applications. So this would be related to what type of application are you onboarding, whether it's like the CUUP or the user plan function of the core. And then the similar type of compute, networking and storage information and the workload characteristics that are needed for these applications to be onboarded. So those are kind of an overall view of the API set that we feel are needed to kind of enable 5G and the NFVI, in this case, Acrena and the orchestration and management in this example ONAP and some of the 5G applications as well as some of the edge applications that could work together. And finally, I'd like to kind of show how this could fit in with Acrena. So Acrena, as you can see on the top, there is an edge API that is provided from Acrena Stack to the different applications. And in this case, applications include both 3G, sorry, 5G applications, the RAN and core, as well as the edge applications. And then what I'm showing here just as a very high level, that the API set C and D as we specified earlier in terms of the application placement could get the information from the ONAP layer as well as the software components which includes OpenStack, Kubernetes, Calico, SRI, OVS and the operating system such as Ubuntu and so forth. So that's kind of an overall high level view of what we think would be a realization of the APIs for 5G applications at the edge. Thank you. Thank you, Turban. Appreciate it.


Chapter 8 of a Brief Grammar of the Portuguese Language, a Brief Grammar of the Portuguese Language by John Castor Brenner, Chapter 8 of the Indequenables, Adverbs, 134, Adverbs may be single words as bem, well, logo, presently, cedo, early, or they may be adverbial phrases such as the following, amiudo, repeatedly, anti-ontem, day before yesterday, assegas, blindly, as escuras, darkly, até aqui, thus far, a toda hora, hourly, a torto e direito, right and left, avista, at sight, com efeito, indeed, daqui a pouco, shortly, daqui em diante, henceforth, de dia, by day, de longe, afar, de noite, by night, de nenhuma sorte, by no means, de perto, nearby, de repente, suddenly, de chofre, suddenly, unexpectedly, de tarde, in the afternoon, de vez em quando, from time to time, enfim, finally, em seguida, one after another, em vão, in vain, hoje em dia, nowadays, popular, para sempre, forever, pelo menos, at least, por baixo, below, por cima, above, por enquanto, meantime, pouco mais ou menos, a little more or less, quando muito, at most. The following are composite forms, depois, de and pois, afterwards, que sa, perhaps, abbreviation of quem sabe, who knows, tambem, tão and bem, also, tampouco, or tampouco, example, ele não quis e eu tampouco, he didn't want it and neither did I. Many adverbs are formed by adding mente to a feminine adjective. The mente is usually to be translated by the English ending li, escuramente, darkly, propriamente, properly. When two or more adjectives ending in mente follow each other, this termination is used with the last and is understood for the others, Justa e propriamente, justly and properly. Some masculine adjectives are used as adverbs, such are alto, baixo, barato, certo, claro, conforme and muito, falar baixo, speak low, comprou barato, he bought cheaply. Que is an adverb when used to modify an adjective and can be substituted by como, quão or quanto. Que bela é a noite? How fine the night is. Eis, best translated, behold, is a demonstrative adverb. Eis lhes boa, behold Lisbon, eis o warming, behold the man. Eishke, eis aki, eis ai, and eis ali are all used in directing attention. With the objective of the personal pronouns it forms in critics. Eilu, eilush, see him, see them. Adverbs are sometimes used after certain verbs where English requires adjectives. These verbs are estar, ficar, permanecer, sair, continuar. The following expressions are good Portuguese. Este negócio parece-me bom, or parece-me bem. This business seems to me to be good. Estou bem, or estou bom, or boa. I am well. Está bem, he is well off, financially. 135, special cases. Aki, here in this place, is associated with the first person. Por aqui, this way. Daqui, hence. Daqui a três dias, three days hence. Daqui em diante, henceforth, from now on. Ca, here, is also associated with the first person. Vem cá, come here. It is also used with the first person for emphasis. Eu cá me entendo. I, here, know what I am about. Ai, is associated with the second person, and refers to a fixed place near the speaker. Bote aí. Put it just there. Ali, is associated with the third person, and refers to a more distant and fixed place. When used in comparisons, may mean either very or too. Muito longe. Maybe either very far or too far, according to the context. Sim. Yes, is used after que, in indirect discourse, to mean so or just so. Creio que sim. I believe so. Acho que sim. I find it so, or I think so. Sim, and não, as replies, are rarely used alone, but in polite conversation are accompanied by senhor, or senhora. Where yes, would be used in English. In Portuguese, the verb used is ordinarily repeated, or é as used. Está pronto? Are you ready? Estou? I am? Viu o vapor? Did you see this steamer? Vi, or viu. I saw it. Nada is sometimes used as an emphatic know, as explained in 136. Mesmo is used for emphasis in connection with the adverbs aí, aqui, etc. Ai mesmo, in that very spot. Daí por diante, or daí em diante. From that time on, line cima, up there, line baixo, down there. Aonde? Where, wither, indicates motion toward, and Donde? When's motion from a place? Onde estou? Donde venho? E aonde vou? Where I am? When's I come and wither I go? Para onde? Wither. Para baixo. Downward. Para trás. Backward. Por onde? Which way? Por baixo. Beneath. Por detrás. Behind. The English a go is expressed by the use of the impersonal verb há, from haver. Há um ano, a year ago. Just and just now are expressed by the use of the verbs acabar and chegar. And by the adverbs ainda agora. As acabou de jantar, he has just dined. And ainda agora jantou. He has just now dined. Aguarinha. A diminutive form of agora. Now is similarly used and shortens the time past. There is expressed by ali, lá, and acolá. Lá and acolá are associated with the third person and refer to places distant, but not precise. Bote lá. Put it there, that is, somewhere there. A outro vem cá e ele vem. I say to one, go there, and he goes. And to another, come here, and he comes. It often happens that a single English word can be rendered in Portuguese only by an adverbial phrase, such are somewhat and somewhere. Um tanto indisposto, somewhat il. In alguma outra parte, somewhere else. Algúris is sometimes, but not often, used for somewhere. Negation. 136. The adverbs of simple negation are não, no, not. I have not studied. Nem, neither, nor, nenhum, nem outro. Neither the one nor the other. Nunca, never, nunca vi, I have never seen. Nunca mais, jamais. Never more. Jamais. Never. Nunca jamais o saberá. You will never know it. Nada. Nothing. Though commonly announced, this word is sometimes used as an adverb of emphatic negation. Vai a cidade? Are you going to the city? Nada. Decidedly not. The expression pois não. Literally, why not, is sometimes an affirmative, equivalent to certainly. But it is sometimes a negative. The meaning in these cases is determined by the intonation. Pois sim is similarly an affirmation or negation according to intonation. 137. Double or emphatic negative. Two negatives are used for the purpose of strengthening the negation and are not, as in English, equivalent to an affirmative. Não sei nada disso. I know nothing about it. Is correct, Portuguese. Likewise are such expressions as não sei não. Não tenho nada. Não há nada. Não conheço ninguém. Não devemos nunca. Interrogation. 138. There is no special arrangement of words for asking a question. That a question is asked is indicated colloquially by the tone of the voice or, when written, it is shown by the use of the interrogation mark. Este livro é meu. May mean, is this book mine? In which case the interrogation mark would be used. Or it may mean, this book is mine. There are certain words, however, which in themselves sometimes, but not always, imply questions, such as quanto or quanta, how much, quantos or quantas, how many, por que, why or because, como, how or as, and qual, which. The expression não é assim, is it not so, and não acha, don't you find it so, refer to a preceding sentence or idea, and are equivalent to the French n'est-ce pas or the German n'est-va? Prepositions. 139. Prepositions are either single as à, to, até, until, or they are prepositional phrases, cerca de, about, antes de, before, in time. The prepositions de and à are used in connection with direct objects, as explained in 122-123. De follows certain adjectives, capais de, capable of, ele é capaz de chegar a qualquer hora. He is liable to arrive at any time. Cego de, blind, cego de um olho, blind in one eye, seco de raiva, blind with rage, dependente de, dependent upon, digno de, worthy of, doente de, ill with or of, distante de, distant from, fácil de, easy to, próprio de, próprio para, proper to or for. Similarly, de follows certain participles used as adjectives, C124, such as pintado de verde, painted green, vestida de seda, dressed in silk. Di is also used idiomatically in such expressions as estar de pé, or em pé, to stand up, ir de chinelas, to go in one's slippers. The preposition de is much used in certain idiomatic phrases and sentences, such as chorar de prazer, to weep for joy, morrer de fome, to die of hunger, fazer de tolu, to act the fool, chamar de ladrão, to call one a thief. The preposition de of often drops the e and takes an apostrophe when followed by a word beginning with a vowel, desci, of this, for gi esci, da que li, of that. They are also written desci and da que li, with e li, it forms deli. When the preposition gi is followed by the definite article, the two words unite and are written and pronounced du, da, du, sh, da, sh, in place of gi, u, etc., C15. 140. The preposition en is similarly combined with the definite article forming nu, na, nu, sh, na, sh, as explained at 15, and with esci, esci, and a que li, forming ne, sh, ne, si, and na que li. 141. The preposition a, tu, has so many and such varied uses that it seems best to give a list of them. a, tu, as used to express, a, the place to or toward which with the idea of returning, to go to the square, b, the place where or near which, to be at the door, situado a beir amar, situated at the seaside, si, distance, measure of place and time, a tiro de bala, a gun shot away, three kilometers away, d, end or purpose, to work for the good of the country. Deu-li o vinho aprovar, he gave him the wine to test, i, material, pintar a óleo, to paint and oil, bordar a ouro, to embroider with gold, f, time in which, partir ao meio-dia, to leave at noon, d, future time near at hand, expressed with the infinitive, está a chegar, he is about to arrive, h, length of time, daqui a dez dias, ten days hence, i, manner, obra feita a pedaços, work done by bits, a pé, a foot, a cavalo, horseback, anado by means of swimming, j, distribution and succession, dois a dois, two by two, gota a gota, drop by drop, k, means instrument, cause, matar a fome, to kill with hunger, with dagger thrusts, cantar a viola, to sing with a viola, calçar aos pés, to wear on the feet, l, measure, price, tax, to measure in meters, comprar as a roubas, to buy by the roba, vender a peso, to sell by weight, juros a cinco por cento, interest at five percent, m, quantity, aos centos, by the hundreds, chover a bom chover, to pour down rain, and, manner of action with infinitives, andar a saltar, to go jumping, to hear the birds a singing, oh, conformity, ao parecer, as it seems, a vontade, as much as one likes, object of reference, pronto a responder, ready to respond, apertar a mão a alguém, to press one's hand, q, hypothesis, a ser assim, in that case, or a, and para, too, besides other relations, both express movement toward, but with this noteworthy difference, a contains the idea of returning, while para, contains the idea of remaining, vou à Europa, and vou para Europa, both mean I am going to Europe, and are both correct Portuguese, but the former means that I go to return, while the latter means I go to remain there, in such expressions as está para chegar, and está a chegar, he is about to arrive, both refer to future action, but para expresses a more remote, and há a more immediate action, 142, inverse and colloquially, com, with, sometimes drops the m, when followed by the definite article, com os teus, or com os teus, with, thy, in place of, com os teus, on the preposition, per, c, 15, 143, pelo que, is an idiomatic expression, pelo que dizem, from what they say, pelo que me toca, and so far as it concerns, touches me. Certain adjectives and participles used as adjectives are followed by por, célebre, distinto, famoso, ilustre, notável, responsável. Examples of participles used as adjectives, and requiring por, banhado, cercado, conhecido, disperso, habitado, perseguido, povoado, footnote. Habitado and povoado also admit of de, as cercado de amigos, surrounded by friends. 144, the following are idiomatic prepositional expressions, abaixo de, beneath, acima de, above, afim de, in order to, além de, beyond, ao redor de, around, a quem de, de, this side of, a roda de, about, cerca de, about, diante de, before, di entre, between, de frente de, in front of, dentro de, inside of, dentro em, inside of, depois de, after, de sob, below, de sobra, super abundantly, de trás de, behind, em roda, around, junto de, near, longe de, far from, para com, toward, pé ante pé, on tipto, perto de, near, por baixo de, below, por cima de, above. Four prepositions required by certain verbs see 122. Conjunctions, 145. Conjunctions are either single as, i, and, porém, but, quí, then, or they are conjunctional phrases. Following are the more idiomatic of the conjunctional phrases. Afim de, quí, for the prepos of, ainda quí, although, in spite of the fact that, unless, antes quí, rather than, before, apesar de, in spite of, apesar de quí, in spite of the fact that, contanto quí, so that, provided, de maneira quí, de modo quí, so that, in such a way that, depois quí, after that, de tal modo quí, de tal sorte quí, in such fashion that, enquanto quí, while, although, entretanto quí, whilst, no caso quí, in case that, para quí, in order that, se bem que, although, sem quí, unless, visto quí, in view of the fact that, a, then, is usually, quí, but it is also expressed by, mais água que café, more water than coffee, mais que vinte, more than twenty, mais do quí é necessário, more than is necessary, mais de uma vez, more than once, either, or, are expressed by, ou, ou, ou pode ou não pode, either you can or you cannot, si, neither, nor, are expressed by, não, nem, or by, nem, nem, não quero, nem posso, I neither wish, nor can I, não tenho nem ouro, nem prata, I have neither gold, nor silver, interjections, 146, interjections are single words as, oh, o chalar, would to God, or they are interjectional phrases as, vale-me Deus, aí de mim, alas-me, quem me dera, would that, tomara que ele venha, I wish he would come, interjectional phrases containing such as, aí de mim, infeliz de ti, pobre dele, are said to be elliptical, the complete expression would be something like, aí, tenho compaixão de mim, infeliz, tenho compaixão de ti, pobre, tenho compaixão dele, coitado, coitadinha, abbreviations used in writing, 147, there are several abbreviations of Latin origin that are the same as those in English such as, a d for anodominy, a t c for etc, p s for post scriptum, and the like. In addition, there are many abbreviations for Portuguese words, the most common of which are given in the following list. These are used extensively in correspondence and in the official documents.  The final a is dropped when the name begins with a vowel as santana, and a footnote, s i o, salvo, erro, omission, vi, você, vi a, vi uva, vi a, vossa autesa, vi a, or, vossa autesa real, vi e x a, vossa excelência, vi m a de i, vossa majestade, vi m i, vossa majestade imperial, vi e n d o r, venerador, vi m, vossa merce, vi m si, vossa merce, vi s or vi a s a, vossa senoria, one o, two o, primeiro, segundo, etc. 7 br, setembro, 8 br, outubro, 9 br, novembro, 10 br, dezembro, similarity of words in the two languages. One of the difficulties sometimes encountered by a beginner of Portuguese comes from a misleading similarity of certain words in the two languages. A few such words are here brought together to illustrate and emphasize this feature of the language, but the list is not complete. It is noticeable that words of this kind are chiefly from the Latin, and that they have descended to the English language with one of their meanings emphasized, and to the Portuguese with another. It should be noted, however, that the meanings given are the common rather than the only ones. List of Portuguese words having a meaning different from similar words in English. Ação, share, in company, acordar, to awaken, atual, present, time, admirar-se, to be surprised, aluno, student, apreciar, enjoy. Ahmá, ready, tie-up, artista, artisan, ascender, to light, fire, assentar, to sit, assistir, to be present, bravo, wild, bruto, rough, campo, open field, colegio, to school, preparatory, combinar, agree, comum, ordinary, competência, jurisdiction, concertar, to mend, constipação, cold in the head, dano, injury, demandar, porto, to head for, denunciar, to announce and denounce, desapontar, to put out, desgraça, misfortune, direito, right, straight, durar, to last, espaço, period, espetáculo, performance, estreito, narrow, esquisito, queer, face, cheek, faltar, to be lacking, fama, rumor, impertinente, exacting, importar, to amount to, idioma, language, idiotismo, idiom, miserável, wretched, miséria, want, nomear, a point, ofendido, hurt, oficio, trade, ordinário, commonplace, worthless, parente, kinsman, particular, private, partir, to start, prejuízo, injury, querer, wish, real, royal, regimento, rule, ruin, bad, segundo, according to, sereno, do, singular, peculiar, sorte, prize, sucesso, accident, vapor, steen, steamer, visio, habit, vulgarizá, to popularize, vulgarmenchi, commonly, end of chapter 8, end of a brief grammar of the Portuguese language by John Casper Brenner.


Hello. Hello, is this the tattoo shop? Yeah, it sort of is. We've got no phone at the moment, so it's been Diverted to my phone, which I own the shop. Right, right. Are you able to take bookings and stuff or no? Can you go on our Facebook page? And we can Get your phone number off that. I don't have Facebook. Is there any way I could just maybe call like a tattoo artist or something or book something in it? It's pretty hard because I don't know what you're after it in. If you go to the shop tomorrow We're open from 10 o'clock to at least six. Right. Yeah, right. Just go there and you can talk to somebody All right, I'll do that. Yeah, we're just with that storm the other day.   I don't know what's happened. They're just coming around tomorrow morning.  So anyway, I'll I'll go and have a look at the servers and I'll see if I can get it back up Running. Yeah Okay, I'll I'll give you I'll give you buzzback and we've got a technician coming in tomorrow morning It's gonna be up Oh, I can have a look myself. I'll just go and I'll go around I don't know where they are the service for that area and all Um, I'll go have a look.  So I'll go on that I'll pop over and I'm a look.  We'll see it. We'll see how I go See how I go with this one But yeah, I'll pop around and because I think it's just been one of the The bulbs is probably short circuit or something from the energy energy coursing through it So I'll go and see if I can swap that over and I'll give you a buzz in about half. I'll see if I sorted it Hey, okay. No worries, mate. See you later. See ya Guess we can call back in five and say that yeah, just got here. It's fucked. It's never coming back Like your system is shut down. It's shut down forever Hello. Hey, mate, it's me again.  I just pulled up Cross a road from it and like I could even see just walking over that there's Big problems with it. The receivers are all spread out on the ground And one of them is actually still a lot like a live wire at the bottom there And it's it's just it's just getting a bit out of control I might have to call the the fire department here and get them to come because one of the live wires It's spanked up against the wall pretty hard and Yeah, it's getting close and it's just just down where the transmitters are mate the The transmitter is just near the joint where all the metal that member the telecommunications fell down During this no idea what you're talking about.      Oh my god I heard him say some of that. Oh, you're funny come at the end Dude, I'm happy with that. You don't win them all and that was good I don't know. I do a what are you talking about?  Just do what you can I'm just okay with the screen You're there within less than five minutes That was very good. I liked it. I enjoyed how it how we created it right on the spot during the phone call Yeah, that was very spontaneous