 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining this DataVercity webinar today balancing data and processes to achieve organizational maturity sponsored today by IDERA. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by 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 DataVercity. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and any additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Ron Husenga. Ron has over 30 years of business and IT experience across many different industries, including manufacturing, retail, healthcare, and transportation. His hands-on consulting experience with large-scale data development engagement provides practical real-world insights to enterprise data architecture, business architecture, and governance initiatives. And with that, I'll turn the floor over to Ron to get us started. Hello and welcome. Thank you, Shannon, and welcome, everybody. Hopefully you'll find today's topic interesting and compelling and be able to take a look at your own organizations and really start thinking about how would I assess my own organization in terms of both data and process maturity and how we achieve a higher level of capability within our organization. That's really what we're driving at, is looking at some of the fundamental underpinnings to allow us to do that. So some of the things we'll be covering today is, first I'll just talk very briefly about organizational effectiveness and a little bit of my background on that as well. Then we'll merge into some of the standards and bodies of knowledge that come into play that you're probably using one or more of these as a reference or either directly or indirectly in your organization as well. So just paying a little bit of attention to that. And then we'll talk about indicators of maturity in your organization. And from that, I'll talk about it both from a data maturity perspective and a process maturity perspective in the organization. And then we'll expand that out and look at some supporting perspectives on that in terms of what does this mean in terms of governance, enterprise architecture or the complexity of the architectures that we have in our organizations to really enable the organizations to move forward considering all of these different topics that we're talking about. Now what we won't be doing today is it's not going to be a cookbook in terms of how do I walk through and conduct a detailed assessment or audit of my data and process maturity. But what I do have is I have some charts and discussion points that really allow you to take more of a qualitative look and understand different things that may be going on in your organization so you can get a good feel about where you might actually lie in terms of both data and process maturity and then be able to take that and move forward and explore different areas. Now just a little bit of my background as well as Shannon did indicate that I have worked in a number of industries over the years. I actually started my career in manufacturing and that's actually very key to this particular presentation because in my days back in manufacturing was also when the quality movement and everything like that was really starting to take hold in the industry where U.S. or North American industry was really starting to look at things that the Japanese and German manufacturing and those manufacturers were doing and looking at how we build quality into our processes throughout the organization. And coming up with things you might remember things like the Malcolm Baldrige and even quality awards that came into play and then later quality standards such as the ISO standards that came into play for quality standardization and everything like that. So it's against that framework that we're really looking at how do we actually start to have more of a, I guess, standardized or fundamental approach to our quality and our maturity in our organizations to make sure that we're doing that. So if we look at this, one of the things we see is a lot of what I'm going to talk about today in terms of the quality side of things is based on the capability maturity model. Some of you may have heard of it. A lot of the other things that you see in terms of independent data maturity standards, process maturity standards and evaluations all typically come back to the capability maturity model. That model has actually been in existence for many years. It was actually created by a gentleman called Watts Humphrey and that was when he was with IBM and he had a 27-year career with IBM. But where it really started to take off was when the U.S. Department of Defense Software Engineering Institute started utilizing it in 1986 when he joined the Software Engineering Institute at Carnegie Mellon University. So most people, when they think about the capability maturity model, they do attribute it back to the Carnegie Mellon institution itself. Now, what really happened though is the work at Carnegie Mellon really started formalizing it and it was, again, for military use the U.S. Air Force was really a key driver of this and he started driving out his process maturity framework for the Department of Defense specifically. But there are a lot of fundamental underpinnings to this that apply to any business throughout and any industry. So that, you know, it's very important. Other things that was also happening, as I mentioned with my manufacturing background around the same time is the whole total quality management of the product quality standards and those types of things. And again, it started in manufacturing and process types of industries, but then found its way out into a number of different industries across the board, including software development and other aspects of that. So when we look at this, there are a number of different standards that can be based on it. The data maturity model, the business process maturity model, which is actually set by the object management group. Other things that you may be using in your organization, COVID, control objects for information and technology from 2000. ITIL, again, really detailing standardized processes more based on technology and infrastructure that came out in 2002, the total quality management movement that I mentioned, and statistical process control. What all of these have in common is really trying to develop standardized, formalized metrics, measurement standards, and basically providing a framework so that you can improve your processes in your organization as a whole. Then on top of that, we see a number of things that come into play for us as organizations. So those of us that have been dealing in data management for quite some time, there's the data management body of knowledge. Version two of that was just published earlier this year. There's also for those of us that are involved in business process or business analysis, the business analysis body of knowledge. And of course, most are also familiar with the project management body of knowledge. So again, standardized processes, procedures, and ways to evaluate your organizational success comes through a combination of all of these. So let's take a step backwards and say, what is maturity? Maturity isn't necessarily related to age or how long an organization has been around, but it can play a factor. When we think of maturity, what we're really looking at is reaching an advanced stage of development in terms of whatever factor we're looking at. So from data, we're looking at, do we have an advanced stage of data maturity? If it's process, do we have an advanced stage of process maturity and how we're managing and organizing processes in our organization, and also designing from a data and process perspective in our organizations? Interestingly enough, it needs to be a balanced scale to achieve overall organizational maturity. You cannot achieve overall organizational maturity by not having both data and process maturity working in concert with one another. And there are several reasons for that, but when you really think about it, and I'll use the manufacturing analogy again, we can't manufacture a high-quality, reliable end product without high-quality inputs and well-defined, controlled manufacturing processes. Well, the same is true of our organizations. When you think about it, our organizations as a by-product are also information factories. Every business process that we have in place uses inputs and outputs that mirror the tangible inputs and outputs that we use, whether it's manufacturing, process control, retail, health care, all of those things are in play, and all of those inputs and outputs and the results are represented by data that we utilize in our organizational processes. So we need to have a good handle on the data, as well as how we utilize and leverage that data throughout our business processes in the organization itself. Again, on top of this, what we need to know is that data maturity and process maturity are also fundamental aspects of getting the most out of enterprise architecture initiatives that we put into play, and again, all of them are fundamental to data governance, and I'll talk about that a little bit later on a slide that's coming up shortly. Now let's look at data maturity, and what I've done here is I've, rather than actually lay things out in terms of a detailed assessment or that type of thing, what I've done is I've taken the scales of a data maturity. I've actually put in a level zero. The true capability management model is a scale from one to five, but I've actually put in a zero on this particular data maturity scale to represent organizations that may not have any data maturity or they're just starting up as well. And a good way to look at this is just along qualitative factors, really starting from the none and right through where you have initial knowledge, standardized, advanced data maturity, and then optimized data maturity. And as you can see at the top level, what we're really talking about, it really is a life cycle or a progression through the levels. You can't start an organization today and be at a data maturity level of five. There is a process that's in place and it takes a lot of effort to get there. But what you'll find is as you go through, begin from an introductory perspective through expanding your data capabilities and then get to transformational maturity, what you're really doing is you're moving along that scale from initial or low maturity, right up through an optimized organization that's using the data and leveraging it properly. When we look at the different aspects, I've put a few different things here to think of. So when we think about data governance, when you're at an immature level, you probably have very low level or no data governance in place at all. Or you might just be introducing it at a project level if you're in the maturity curve and you start to basically put that in beyond projects to a more of a program level. Then you get to divisional, cross-divisional and enterprise-wide data governance initiatives. As part of that, when we look at master data management as one of the criteria, again, you may start with no formal master data classification at all. Then you start getting to a point where you're classifying it, but it's still not an integrated master data management solution or hub. Aspects or systems in your organization to a point where you then start building out data management services and as you're starting to establish data stewards, data governance councils and data stewardship councils and that type of thing, that's when you're really getting up to more of the advanced and optimized levels of data maturity. This also ties in to how your systems interact and particularly from a data integration point of view. So again, at an immature level, you may have ad hoc or a lot of point-to-point interfaces where you're moving data around your organization. You'll evolve that typically and some people call that like spaghetti code or spaghetti text of interfaces. Then you'll start to introduce some common protocols, kind of chaining out some of those point-to-point interfaces, putting in some standards. Then you start to realize that you really need to handle it and get a common integration platform, start establishing design patterns to be able to work with that data and as you get to more standardized, you're going to start to use things like middleware. So if you're using service buses or canonical models and really using the business rules repository and those types of things and canonical messages and standardized messages between your applications, that's when you're really starting to move up the curve towards standardized and then when you get to an advanced stage, you really have things like a data center of excellence, training throughout your organization in terms of how the information is used and you really start to see that embedded part and parcel of this as well is hand in hand with data maturity, data quality is another important aspect. So again, when you start to look at it, in initial stages you may have data silos and those occur naturally quite often in organizations because a lot of our companies today are built up through mergers and acquisitions. So as a natural byproduct of that, we always start with silos when one of those acquisitions occurs and then we have to start to break that down and integrate that data across our organization. But what that also leads to is inconsistency in information and quite often a problem with information quality as well. So what we really try to do is we try to get out of that stage where we accept these inconsistencies to really have more of a continuous improvement mentality where you're trying to knock down those inconsistencies. You know, first part of that is recognition and then you need to put a plan in place to start to address them and one of the things that I bring or that I keep thinking of from my manufacturing days again is we nearly need to start thinking about data cleansing at the point of consumption where we initially create the information or where we're consuming in a process rather than trying to do it at the end. We spend millions upon millions of dollars in the industry today where we're starting to build out things like data warehouses, data lakes and that type of thing, trying to consume the information in there and applying a lot of data cleansing to make that purpose for the processes or the decisions that we're trying to make. What we need to do is go back and start to build that quality into the processes that utilize that data from initial capture to how it makes its journey throughout the organization. From a manufacturing perspective, I like to liken this to the assembly line approach. When we looked at products many years ago and one of the reasons that the quality movement began to begin with is we have products that would come off an assembly line and then we would inspect them and we'd say, oh, we had some defects here so there might be rework or that type of thing. Nobody has ever improved the quality of a product by inspecting it at the end or at least that particular product or instance of that product that they've inspected at the end. What we need to do is we need to go back and build that into the process. That's why when we saw the quality movement and started adapting the principles of Japanese manufacturing and that type of thing, we started to build it at every step along the process on the assembly line and also empowered the workers that were on those assembly lines to shut down the entire line if a problem was detected, fix it and then move on. We need to have that same type of culture and mentality in our business to make sure that we're understanding and utilizing information and making sure that we have that quality information throughout all of our business processes that we're using. There are other factors that come into play in terms of how you can kind of assess your organization overall. Just from a global perspective if we look at your primary IT focus in your organization, if you find that you're still primarily focused on technology and infrastructure, you're probably down towards the more immature side of the data maturity curve but when you're really starting to look at information as a strategic business enabler you're probably finding yourself moving up that curve and more to the mature stage of that. There's also a very important thing that we need to look at and these are flip sides of the same coin so if we look at risk and value generation, those with a high level of or basically those at an immature level have a high level of risk, those at a mature level have a low level of risk and the flip side of that is from value generation. If you have a low level of maturity you're going to have a low value generation and if you're a high level of data maturity you're going to have a much higher level of value generation in your organization as well. Let's take this one step further in terms of how data modeling factors into data architecture and this overall maturity as well and when we look at the evolution of data modeling and aspects of data modeling in our organization these different dots or these different points here are represented by those same five points of the data maturity scale. So again when we look down at the lower levels of maturity what we find is if data models are being used they're quite often being used for things like documentation of what's there or maybe you're doing some project based work where you're designing just a physical database generating the DDL to really utilize that database for a particular application that you're building. As you start to move up the maturity curve you really start to understand the difference in important separation between conceptual, logical and physical modeling and what the information means to your organization as a whole. So you then start really using it more from a design perspective rather than a documentation perspective and as you move up you're really doing a model first type of approach as well. You're not documenting after the fact you're actually utilizing your data models at the conceptual level driving it through your logical for elaboration and then generating your data constructs in your relational databases or even your big data stores or no SQL stores from the data modeling itself. Then as we move up even more we start to realize that there's a lot more than just PR diagrams and the actual data and the relationships between the data itself. That's when we start to bring into play things like canonical models as an overall reference or enterprise data model. What's the lineage of the data in our organization in terms of how that data is making its journey and what the transformations are that are happening to the data throughout the organization and also making sure that we're leveraging that with traditional metadata that really helps us in terms of data governance initiatives like master procedures and then we move our way up to full governance metadata where we have integration of business glossaries and business meaning integration. We're really looking at the overall data life cycle documenting and modeling that life cycle and looking at the value chain of that data throughout the organization as it ties in and drives the business processes to a point where when we get fully mature that's when we have a fully integrated modeling approach again tied into the glossaries. We can utilize the data and the metadata and those glossaries to really drive self-service analytics and those types of things. So again it's an evolution up that life cycle to achieve that fuller level of data maturity. Now when we look at a data life cycle as well what we're really talking about in terms of data life cycle is how a data element is created, read, updated and deleted and where it's ultimately used in our organization and of course those of us that have been around for quite a while do recognize the CRUD acronym that we use for that. There are many factors that come into play from a data life cycle though. There are business rules, there are business processes that act upon that data and which applications actually implement those business processes that act upon the data as well. Something as well is I've seen tremendous debates in some organizations when people start talking about the gold standard or gold copy of information and trying to rationalize down to what is the gold copy or that one source of the information. Unfortunately that's not always the case. There may actually be multiple ways that a particular data element is created in your organization. As an example if somebody is hired you may actually have employee data that's captured as part of your HR system but there may also have been other types of recruiting process that were in play where maybe there was basically a recruitment system or something like that that not all employees went to but some of that information may originated in those systems before they made their way into the HR systems as well. Again really understanding what the different creation points of the information is in the organization and then how it evolves on its journey throughout the organization as a whole. Now to do this and what I've depicted on the right side is the overall life cycle is we need to be able to model several things to understand the overall life cycle. Again we're going from creation and collection of the data classification of the data how do we store that data and utilize it in the organization and how is it used how is it modified by those business processes through the organization how are we sharing or disseminating that information and something that people often forget and these are very important points is to model and understand the overall data life cycle we need to understand what are the retention policies that come into play what are we doing from archival and purge and ultimately destruction of data and this is also extremely important from a data quality perspective and also from an overall governance perspective. If you're a hoarder and you're keeping all the information in your organization that may actually be a bad thing. What you want to do is make sure that you're keeping the information that is relevant and purging that that is no longer relevant in a timely fashion. Now let's flip over to the other side now and start looking at business process and again we're looking at the process maturity scale and again we're dealing with scale here from one to five and we see the same type of thing in terms of introduction to the organization through expansion and transformation and the same categorized descriptions of these so from initial through managed, standardized advanced and optimized. Now again what I've done here is I've actually given several different types of things that you can look at in your organization to get a feel for where you might exist along this particular scale. So if we look at our overall focus and I'm going to start from the left and work my way to the right as I work down these bars and I'm not going to read these out in detail but just pick and choose some of these to talk about. In terms of work focus, if you're at a low level of process maturity, quite often you're really relying on people to you know set up their own personal methods to accomplish their work and there's not much standardization. And then also often there may not be a lot of preparation or there may be inconsistencies that you see from person to person, department to department and that type of thing. And generally speaking that breeds a very low level efficiency in the organization as well. So you end up with very few measures of standardization which means that you have very few measures of analyzing which are true effectiveness as well. In some organizations this might tie right into the corporate culture where the corporate culture itself may be somewhat stagnant so there's no real identifiable foundation or commitment for improvement. If you see that you're probably down at the low level of process maturity, you also may find that there are few activities that are explicitly defined. You may not even have current state documentation and if you don't have that, how can you actually, if you can't understand and document the current processes, it's very difficult to approve those processes to arrive at a higher level of maturity. What it also means is a lot of the decision making in the organization may be based on gut feel, tribal knowledge or those types of things and you may also find that underpinning all of this from an architectural perspective in your organization you may see a number of disparate IT systems that aren't really tied together around the business processes and organizing in terms of which system you use for which process and also the flow of information between those systems to enable those processes. As you start to move up the curve then you start to see more of a managed approach where you start to see things like more management responsibility for standardizing the work unit operations and performance. Then you start to standardize processes and then really instrumenting those processes. So how do you reuse those processes? More mentoring amongst workers and that type of thing and ultimately optimizing it as we go across. From a work management perspective that means you're expanding it again from more balancing commitments with resources. In other words, do we have the very often project based, do we assigning resources to projects, making sure that you meet the timelines and that type of thing, but not necessarily when you're in a managed approach. Then you start to move up to standardize where you really become adaptable because you're standardizing your processes, you're tailorizing and optimizing them for use in the different circumstances. And again, just like that assembly line thing that I talked about where people feel empowered so they have the authority to evaluate the data, improve the processes and share that information to drive the entire organization forward. That efficiency, it's very important. Again, we move when we move up the process maturity scale from generally inefficient organizations to much higher levels of efficiency where we have repeatable processes to then leveraging common measures and processes across the organization rather than just compartmentalized in different areas to the point where we get to multifunctional processes across the organization. Sorry about that series charming and as well on me here. Also from a cultural perspective, we really want to move to the point where you're moving to a preventative system where you have metrics in your processes. So as part of your business processes, you not only have the data inputs and outputs for the process itself but you're collecting metrics around those processes to measure the efficiency and by doing that you can then improve those processes going forward and you can do it in a quantitative fashion. From an overall decision making point of view, what we really want to get to is more from that gut feel type of decisions that we see all too often in organizations to really having more again moving to a functional process orientation to the point where we have integrative processes, performance metrics against those processes and data driven decisions based on those performance metrics as well. That ties right into our data perspective as well because what we're also seeing as a byproduct of that is that's when we can really start to drive forward things like self service dashboards, analytics in terms of because the analytics against the data is how we're actually evaluating our organizational performance and that we really want to get to is trying to establish competitive advantage through really establishing best practices across your organization which you also find in terms of the underlying architecture that occurs in your organization is we start to move away from those disparate IT systems to more of a services adoption and then through things like service oriented architecture. I'll talk about that a little bit more in a later slide to what would I call the full process driven enterprise where you're pulling these things together. It should come as no secret that we see the same type of thing occurring from a process maturity perspective as we did on that slide where we saw the data maturity. So again when we look at productivity and quality as measures in the low maturity you're going to have low productivity and low quality generally and when you get to a higher level of process maturity you're generally going to see a much higher level of productivity and quality and I'm not talking about just the processes as well but also the goods and services that you're producing as an organization. Again when we talk about risk and waste at a low level of process maturity you typically have a high level of risk and a high level of waste and when you optimize those processes you're significantly reducing the risk and also have a low level of waste in the organization. When we think about it how can we think about in terms of what the overall management philosophy is in terms of what maybe some of our cues is to what we see. So if you see an organization or you're part of an organization where chaos reigns or your primary focus is on cost cutting you're probably again at the lower level of the process maturity scale. As you move up and establish yourself along higher level of process maturity you're going to see more of an efficiency, more focused management of all these processes and then what you're really trying to see is you're going to see things like management philosophy in your organization really evolve more through a leadership and leading by example philosophy and you're also going to see a focus away from primary cost cutting mentality to a real value generation mentality in the organization as well. Now just like we did before we'll take that same level of scale and we'll say how do the process models in particular tie into these things and it's the same types of things that we saw from the data modeling perspective. At a low level maturity if organizations are doing it all, they're typically using process modeling very much as a documentation form for current state not even necessarily designing out what future state processes are or even looking at business process optimization. Then what you really start to do is you move up the maturity curve you're really starting looking at design and utilizing process modeling to drive out business process management moving again up the curve to process improvement. You have to have that baseline to understand current state that you start to design future state problems you start looking at gap analysis and that starts to help you drive out process improvement and then you really started to use process modeling as you move further up to design the processes in the first place and you might even find yourself getting into things like process simulation and those types of activities to prove those processes before you implement them and then when you get to the fully mature level that's where you start to see things like really a lean type of focus you may see things like full process improvement, business transformation like Six Sigma and a number of other things come into play as well when you get up to that top level of the curve. This particular one I'm not going to talk about in a lot of detail but what I've done is I've just taken a number of the different things that I had scattered on the data process maturity grid and also the process maturity grid and I've just categorized them for them so it just kind of is a quick qualitative lookup table if you will but if you start to see some of these different types of things manifesting themselves in your organization you can see them as saying okay this helps me assess to where I might actually fit along the scale in our particular organization so as an example of that things I talked about previously if you find that the preliminary mode of operation is get field types of decisions again you're probably very much at the initial low level of process maturity whereas if you start to look at things like data driven decisions or really focusing on using data to drive competitive advantage you're going to find yourself up to the higher level of the scale if you're optimized if you're really driving out competitive advantage. Again when you start to look at things like disparate systems you know again down the lower level of the scale as you start moving into more architectures like service-oriented architecture, data services business process monitoring and those types of things you're probably going to find that you're moved up to the more advanced levels of the scale as well and again I'm not going to go through all of these but I just wanted to include this in the slide deck to really give you some points to think about in terms of if you see this this is likely where you're going to fit now something that's important to talk about as well when we look at those both the process scale and the data scales. It's also very rare that for instance that in one broad one of the broader categories that you would be a 5 and in another one you'd be a 1 you'll typically find that you move up the scale within data maturity or move up the scale within process maturity by having all those factors in balance it's very hard to move up the maturity level without keeping those different aspects in balance which is a segue into the next slide as well because what we also find is that from an overall organizational maturity point of view it's virtually impossible to achieve overall organizational maturity unless you're achieving process and data maturity in tandem with one another you may be a little more process centric in your organization or you may be a little more data centric in terms of which will kind of lead up the maturity scale but the other one will be following very closely behind so what you're really looking at is the optimum is kind of that red line to keeping him in perfect balance as you move forward but if you're slightly process centric you might find yourself sliding a little bit more under the blue part of that scale and if you're data centric you might slide to more of data as a leading indicator as you move up the scale as well but ultimately you want to reach that journey when you move up and this can be a very long multi-year process. You cannot go out and you cannot buy a tool that will automatically do it for you it really is roll up the sleeves assess your data in your organization how you're going to improve it assess your business processes and work harder to improving them so unfortunately Santa's not going to bring you either data or process maturity and put it under the Christmas tree this year but hopefully you'll have some of the tools or some of the indicators that you can look at to help you move forward on that journey. Now the other thing to think about here is when we look at it I want to talk about models in particular what I've reproduced here is the latest version of the data management body of Knowledge Wheel and I'm really talking about data governance here but we can also talk about process governance because data is such an integral part of the processes as well and what we want to talk about is the fact that when we drive this data maturity and process maturity forward through our models the models themselves are integral to all these different things and one of the things I'll call out is something that's changed from the DIMBOK 1 to the DIMBOK 2 is this has been recognized so data modeling and design in particular has actually been called out as a separate aspect that you see now on the DIMBOK wheel but as you see a lot of these other things are extremely important when we start talking about data quality, data architecture as a whole, data modeling our data storage and operations, data security, data integration and interoperability. Again we're talking a lot about data here including things like reference and master data management and data warehousing and business intelligence but around all of these and the metadata that drives them which is also called here there's process intertwined with all of this and these are all necessary to drive not only data governance but also process governance in our organization as well so let's take another look at this quite often in our organizations we start talking about enterprise architecture and there are a number of different enterprise architectures that are prevalent in any use across organizations what I'm showing here first is just a high level view of TOGAP which is very common and again it really starts to talk about things like requirements management at the center and understanding the business but it really drives out from things like an overall architecture vision to your business architecture, to your information systems, your technology architectures defining your opportunities and solutions migration planning governance comes into play here in architecture change management so when we look at this intertwined again into all of these is that business centric philosophy but also as part of that to enable all of these we need that sound business processes and data architecture so we again under all of this we need that to drive forward that level of maturity on both business process and data architecture as well I'm going to go into a different one because I actually for a conversation like this I actually prefer to utilize another one which is the Zachman framework because it helps to compartmentalize some of these things it just helps people to understand them a little bit better particularly if you're not an architect and you're a business person it's somewhat a little easier to relate to so when we look at the Zachman framework which was created by John Zachman many many years ago we're looking at the what, the how the where, who, when and why so these are things that are describing our organization and as we move down into the chart we're moving from a very high contextual level down to conceptual, logical, physical and detailed it's by no fluke that our data modeling architecture has followed this significantly and in fact the Zachman framework was first started for data architecture and then it evolved out to expand to cover other aspects of enterprise architecture in particular but when we look at the what what we're really talking about there is primarily data when we start to think about overall it's called a materialist but overall business concepts are a materialist and then we start to drive out things like entity relationship conceptual models down to logical, physical models and then our detailed implementation detail our how quite often ties into our business processes and our business architecture so not only in terms of what are our list of processes then we start to model and how they interact with one each other, diagram those processes out we get to more detailed functional specifications and then the underlying implementation details of those processes as well something that we need several things to provide context to all of this in our organization is now that we have the data, the what and the how and of course the interaction of the what and the how then we also bring in other factors like where is this happening not only within our organization but in the organizational environment so our customers our vendors and everything else so we start to talk about geographical locations or physical locations within our organization we also start to talk about who and responsibilities from an organizational perspective from who is responsible to who actually implements or participates in all of these different things throughout the processes and also things that are very important is events events are critical what happens what triggers different processes to happen what's the data that we utilize or need for those events how do we detect the event so again tying the events that occur that drive the processes and again the data acting against those processes and as we get into more of the enterprise architecture as well the applications that implement those processes are all extremely important and of course extremely important and last and definitely not least is the why of all this the goals list the relationships of the goals in the organization what are the business rules that we are going to play how are we specified those business rules in our organization and what are the underlying details of those rules if you look at this as well a good way to think about this when we look at these different levels is really talking about at the top level or conceptual what's the overall definition of scope then we drive it down through business models system models then we start to drive down into the underlying technology and implementation models and a detailed representation of what we're actually implementing so the Zachman model I think actually does a pretty good job of tying it all together now a couple more things that I want to talk to very briefly here is taking this back a step and talking about enterprise architecture as a whole quite often people talk about the four pillars of enterprise architecture being data application business and technical architectures our perspective is a little bit different on that again when we look at things in terms of how the enterprise architecture evolved initially it evolved out of data architecture and moved into the other different areas but something that we've been talking about all through is that even when we're talking about business process data is an integral to those business processes so we need to sound data architecture to ensure that the data that we're collecting and consuming in those processes is correct and keeping us aligned what we also need though is when we start talking about all the different aspects of enterprise architecture is we have all the metadata around the data constructs themselves or the data architecture the metadata around all of our processes including our goals our philosophies, our business rules and everything else and the metadata for all of the different aspects of the application and technical architectures as well so that's why we need that sound data architecture underpinning to manage all of this when we have that solid foundation comprised of that married with the central pillar of business architecture and augmented by our application and technical architectures that's what really drives out full enterprise enablement and again you need to have all of these working in concert to really give you the ability to establish solid and organizational wide governance both from a data governance perspective and a process governance perspective as well in terms of the ER studio perspective and I'm not going to go through this in much detail at all but from our perspective what we're really talking about is again these aren't silos we need to make sure that our data architecture is integrated to our business architecture and that we also are able to collaborate and communicate the message out and work along with our business stakeholders so what you see on this diagram and it will be in your deck so I'm not going to go through it in a lot of detail but everything from business architecture where your business analysts working with your business units and documenting and capturing information on your business processes and some of the data artifacts that they're producing or capturing in the form of conceptual models move into a data modeling perspective where there's more elaboration through your logical and physical models but they can be refreshed back into those business models as well but more importantly than that is as we elaborate out the data models and we also elaborate our business process models all of the data constructs can be utilized back in the business process model so you can get very detailed about detailing out what your business processes are what are the data elements that you're using in those business processes to the area where you're actually specifying your crud of which data is created red updated and deleted within those lower level business processes as well and then of course communicating that out and augmenting it with things like business glossaries and collaboration with your business takeovers is extremely important. From a data model in context in particular what I want to talk about is again bringing the data models into play is why do we need them? Well we have several levels of modeling that occur as part of our data architecture typically what we want is an overall enterprise or canonical model that ties things together we have enterprise data dictionaries that contain a lot of the different metadata and I'm talking about more than just domains and data types and that type of thing I'm talking about things like data governance attributes or master data management characteristics that can all be part and parcel of those enterprise data dictionaries that are shared across models and systems and then what we do is we utilize that to tie together all of our implementation models whether they be for our transactional systems such as the implementation models that have kind of got a few samples up here and also how we're doing decision support and I've put data warehouse here but of course that also translates into the other decision support types of things that we're doing as well is we need an integrated picture of this data and we need to have it implemented and driven through models. Again a picture is worth a thousand words doing this just on metadata catalogs and descriptions without models to really show us how these things relate together is extremely difficult and without this it's extremely difficult to reach a high level of data maturity in the organization. Again on the flip side of things we always need to have that overall business perspective in mind. What are your business capabilities? Look at your organization as a whole and just interesting things that we come back and ask to as part of the overall business architecture. What's your organization's reasons for existence? Do you have a mission statement? Do you have strategic goals and objectives defined? How are you optimizing your business processes to achieve those objectives? When you're doing that in terms of your process design are you remaining flexible and adaptable to change that's imposed from within and also from your organizational management that you're conducting business in? How are you instrumenting your processes to measure performance? Do you have targets? Do you have targets for improvement? How are you measuring your progression along those lines of improvement? In addition to the capabilities what we also want to look at is what's the context in which you conduct your business in the organization so who are your trading partners, your customers, your vendors, your competitors as well in terms of other parties that come into play? Again, tying into those capabilities. What's the vision, the strategy and tactics that you're using in the organization? How are you driving those through projects and initiatives? What are the decisions and events that are important to you? Again, metrics and measures. How are you measuring those metrics and how are you utilizing them in your business processes? And I'm not just talking about processes in terms of implementation of our systems. I'm really talking about metrics and measures on things like even on your assembly lines and everything else if you're a manufacturer or metrics and measures in terms of supply chain efficiency if you're supply chain and those types of things. And of course the external factors like the policies, rules and regulations that come into play that you have to comply to and of course that's a big factor in governance as well. Again, putting a little more verbiage around this, we'll look at some of these things that the customers and trading partners are the who and the where. We're tying into why with our vision strategy and tactics. How are we implementing things? Well, what is the information? The projects and initiatives really help drive us out the how. So as you look, work around the circle, you can see that we're defining who we are, what we're doing, why we're doing it and our measurements of effective throughout the process and business architecture. Now, how does this play into more advanced technical architecture? So this is one reference to several versions of this that have been floating around for years in the industry, but this is just one version of how we might represent a concept like service-oriented architecture in an organization. So when I look at this, we have it broken down into multiple types of layers. But we see things that we've been talking about today come into play, particularly on the data maturity and data architecture side of things. That's where we really start to see things in terms of the data services when we look towards the bottom right there and not only just the data itself, but the integration of that data, extra transform and load to our BI, data replication, movement of the data throughout our applications. We look at things like the quality and the messaging of the services as well and enablement of all of our services through contracts, different standards and those types of things. In terms of managed service connectivity, what we're really talking about there is several things. How do we connect the different applications in the business to the backend databases and we may find ourselves using things like enterprise service buses, data services and a number of things there. We also need to think about mediation, change control and to be able to do all of these, this doesn't happen just by putting things together. This really involves sound design from both a data architecture and a business architecture or business process modeling perspective to pull all this together. Because when we start to talk about things about our business processes and together, we're talking about things like process orchestration in terms of coordinating processes across the different areas of our business and we can't orchestrate those processes until we've actually fully understand and design those processes and how they work together. I talked earlier about event detection. Quite often a particular event will occur or will be detected and that's going to be the trigger that drives some of these business processes to occur. So making sure that we model and understand those and implement those is extremely important and also monitoring of business activities to make sure to tie all this together. Rules management and a number of other things come into play and the secret is to tie those data and business architectures together to really be able to enable these types of architectures in our organization. We've covered a lot but in summary I want to talk about a few things. Overall organizational maturity requires both data and process maturity. You cannot have one without the other. They're fundamental to be able to move forward with promoting enterprise architecture perspective which in turns enables our organization and enterprise architecture perspective which in turns enables our government's initiatives. Enterprise architecture is the solution but it needs that solid data architecture foundation and integrated process modeling to provide that business context and that overall business architecture and maturity. And I would say organizations that what I've seen is some organizations are actually moving away or not paying as much attention to modeling as we once did. I think that modeling is now more important than it ever was before. We live in extremely complex organizational environments. The only way to truly understand it is to model it to understand it because you need that visual representation to help you understand it and improve upon it and that means data modeling, process modeling, data lineage, all that metadata that you're capturing is part of that modeling effort and you need to have that business meaning tidying with business glossaries not only from a data perspective but from your process perspective because that allows you to also achieve process governance in addition to data governance as well. And again, what we really want to do is we want to get to a point where we're really focusing on enabling business capabilities in our organizations. We want to make sure that we're aligned and driven by the business goals and strategies and to be able to do that from a technology perspective we really need advanced architectures in today's marketplace to be able to achieve that. That's it in terms of the presentation itself and we'll now open it up for questions. Ron, thank you so much for another great presentation. What a hot topic, I just love it. We've had a lot of good chat going on from the attendees as well and to answer the most commonly asked questions we will be sending a follow-up email by end of the day Thursday with links to the slides and links to the recording this session. So, just diving right in here to the questions that are coming in already. Ron, so, you know, just a very simple question. How does that fit in? Are you familiar with that? Yeah, in fact, the CMMI that's factored, in fact, the capability management model is actually the underpinning of where these data maturity and process maturity standards evolved from. I love it. So the high-point scale that we're using actually came from the capability management model and CMMI is the capability management institute. Yes, indeed. So, what model was used to later compare maturity models? Was that the CMMI or was it something different? Well, what I did is I actually took the capability maturity model in the five-point scale across these and I looked at several different models that were out in industry that different organizations and different bodies were using and what I did is I pulled together like a lot of those descriptors that I pulled out were from those different standards that were used across multiple bodies that were kind of a common or industry-wide type of perspective rather than just slanting it towards one or the other. How about business process modeling? Are tools important? Or would you store all processes in one big repository or have a repository per division unit service? Again, it depends on your organizational maturity level in terms of what you might be doing for process modeling. Are you doing process like simple swim lane diagrams using a drawing tool or that type of thing? You're actually missing out on a lot because what you're doing there is you're basically drawing a static image of what your current state or maybe even a perceived future state process is but what you really want to be able to drive it forward is you need to have it repository driven because what you need and again, I didn't go through a lot of detail in that one slide about ER Studio is you need to have that repository that ties both of your processes and your data together so that you can actually drive a collaborative effort across teams of data architects on the data side, teams of business architects and business analysts on the process side to develop an integrated viewpoint of what that is and that's really of course getting into the enterprise architecture side of things because we're taking things like our data models, our lineage models or business process models that are common repository and then being able to integrate the constructs and leveraging the constructs from one to another. Does that make sense? It does to me but certainly if the questioner has additional inquiries into that, certainly submit it in the Q&A section there. You know, we get this next question a lot Ron in terms of through many of our webinars so can you suggest any metrics that I can use to check my data quality level? Very interesting question and there are a lot of things that you could do and if you haven't done much so far I would start to do things like look at things like data skew a number of distinct values and those types of things looking at any so again first of all look for consistency in your data break it up between master reference and transactional data so master data management comes into play then what you really want to do because it factors into a lot of the things that you're working on is focus on your reference data and your master data first from a data quality perspective because those are participants in all the transactions in your business so getting those right is important to making sure that the overall transactions are correct so again depending on your industry first I'd start like say if you're going to have key areas that really drive your business and that's why I talked about business strategy and value generation and that type of thing if you're a retailer you're going to want to focus on your product assortment you're going to want to sort on your locations and your customers and making sure that type of information is clean first if you're something like a natural resources or mining firm you're going to start to focus on things like on your equipment how you grade your product quality your overall performance metrics because basically overall performance and throughput is critical just improving those metrics slightly can mean millions of dollars in those types of businesses so hone on those critical data elements as it were and then start looking for inconsistencies look for missing data look for duplicate data and look for data skew to see what I mean by data skew is if you see a lot of values at one end of the range and you're not seeing a lot of values in terms of another range of values it could be normal but it could also be some types of data problems as well so again I was kind of a broad answer but there are a lot of different things that you want to look at and it's often driven by which aspects of the business and the data that represent that you're looking at first. So why does processes income post BPM? Basically I think what they're talking about is that one maturity scale and basically it's just an indicator that you may find people that are basically when they really start using as a design first is typically when most organizations have hit that higher level of maturity. It doesn't mean that there's a sequential nature that you have to do that one before the other but it's really an indicator of characteristics that we're seeing along that maturity curve of what the primary factors are that businesses are using those process models for. So it's really moving from a monitoring to a more proactive design if that makes sense. I don't know if you can answer this Ron in just a few minutes that we have left here but because I know they answered already any case history saw this really good stuff that you got going on. Any case histories? I've seen several I get a lot of consulting for many years in the industry before it came onto the project management side of things and I've seen things like I'll give you an example of when I was in the manufacturing industry that I keep coming back for. We became extremely focused on business process and data quality in our organization. We got to the point where what we were doing and I'll kind of backtrack a little bit. When I first joined that organization inventory control was a word process list of parts that were counted every month and to determine our inventory levels. We knew that we were in a highly competitive environment. We had another number of regulatory things that were going on as well and we really needed to optimize and make the business much more efficient. So when I joined the organization what we did is we focused on data and that meant everything from painstaking detail to accuracy in bills of material, accuracy in manufacturing processes and the process around those processes and that type of thing. So we took our business in a period of a few years to where we were stocking many different finished goods. We manufactured explosion proof heaters and we built them on spec stock finished goods so that we could deliver them in a relative period of time. What we did is we transformed our business from a stocking business to a built-to-order business where we were custom building in two to three days our nearest competition was two weeks and while we did that we increased our sales levels five-fold and we decreased our inventory by two-thirds all simultaneously. So there was a lot going on there so tons of optimization that were going on and it was driven by a focus on data and process. Well I think we have time to fit in maybe one more question. So some tools in the marketplace are using machine learning to automate and retrofit some of what's used to be manual modeling efforts. How are you seeing these being integrated? It's interesting. I guess I could say I'm a bit of a pessimist in terms of I think machine learning goes so far and I think machine learning is fantastic for discovery but you still need to have that human being to perform the rationalization and help you optimize the process and data. You need that decision point. That does bring us right to the top of the hour. Ron, thank you so much for taking the time for another fantastic presentation. It's a great topic so important obviously by the amount of chatter we've got going on from the attendees and thanks for our attendees for attending and being engaged in so much that we do. We really appreciate it and we just wish a happy holidays and a happy new year to everybody and I hope everyone see you on the flip slide in the new year. Ron, thank you. Thank you and thank you everyone. Have a wonderful Christmas and happy new year. Cheers. Enjoy.