 Hello, and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We would like to thank you for joining this month's webinar, Data Architecture, the Foundation for Enterprise Architecture and Governance. It's part of the monthly series brought to you by IDERA. There's 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 via the Q&A in the bottom right-hand corner of your screen. Or if you like to tweet, we encourage you to share our highlights or questions via Twitter using hashtag dataversity. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Ron Huzenga. Ron is the Senior Product Manager of Enterprise Architecture and Modeling at IDERA. Ron has over 30 years of business and IT experience as an executive and consultant, spanning a diverse range of industries. His hands-on experience and large-scale enterprise initiatives include enterprise and data architecture, business transformation, and software development. His background provides practical real-world insights to enterprise data architecture, business architecture, and governance initiatives. And with that, I will give the floor to Ron to get today's webinar started. Hello and welcome. Thank you, Shannon, and hello, everybody. Welcome. I'm coming to you from a nice balmy day in Alberta, Canada, where the wind chills only a minus 32, so we'll warm things up with a good discussion on enterprise architecture and data architecture in particular today. With that, we'll go straight into it. Here's some of the things that we'll be talking about today. It's really essential that we understand what our business challenges are and look at things from a business perspective when we're dealing with enterprise architecture. So what I'm going to walk through at the beginning of this session is something that I call lemonade logistics, which is really a look at what business leaders are typically thinking of versus what we think they might be thinking about. So it really gives us a frame of reference for how we actually interact with our business leaders that we're dealing with in our own organizations. Again, what we want to do then is talk about why do we actually need architecture in the first place? What is enterprise architecture? We'll spend just a couple of minutes talking about the disciplines that comprise enterprise architecture. We'll talk about data in particular as a foundation for it. So we'll talk about things like data value and lifecycle and also how do we put all the disciplines of enterprise architecture together, including integrated modeling and really focusing on data architecture, business architecture, and the technical and application architectures, as well as wrapping that in to really drive collaborative data governance in our organizations as well. And then what we'll do from there is we'll follow it up with the Q&A that Shannon has mentioned. So lemonade logistics. I'm an entrepreneur and I see an opportunity in the lemonade market. So like most entrepreneurs, I start with a small stand, but I really want to sustain and grow this business. So what I really need to do is I really need to start thinking about what do is my business want to be when it grows up? So that means putting together some strategies and detailed plans. So I start thinking about things like what's my strategic vision? What's my mission statement? What are my overall goals? I need to back that up with things like a business plan, concepts and those types of things. And of course, the way I'm going to grow my business is through sales, you know, in my different areas and in my different markets. So I really start looking at how am I going to grow sales, my market segmentation, all these business things that continue to go on. And as I continue to go out in the future, more and more things come into play. I start to think about as I'm growing, what about supply chain management? You know, as I become a larger organization, maybe expanding beyond the region, maybe even multinational, then supply chain problems start entering into the picture. How do I manage all of those? I'm also looking at things like am I doing business to consumer? Am I doing business to business and those types of things? And I may have different strategies for all of those different types of things going on at a business level. As I'm expanding, then I start thinking about the financial aspects even more as like, do I need venture capital to expand? Or are there competitors out there that I want to acquire to grow in the market? So I do do basically a couple of things like the venture capital with targeting different companies or looking at mergers, acquisitions, those types of things. Obviously, with all of this going on, we need a solid basis in finance and accounting and everything for all of our record keeping needs. We need to continue growing our management capabilities within the organization and our leaders within the organization. So we have to keep firing on all cylinders there. And we're continually dealing with our constituents and the public out there. So we start thinking about things like public relations. Basically, this is supply chain and we're producing lemonade. So then we start thinking about how do I actually get my product to be more, my manufacturing process to be more effective? So am I looking at lean? Am I looking at improving manufacturing processes? How am I growing that productivity? How am I competing in the economic segments and taking the growth basically dealing with the growth? With any markets we enter into and any things that we're doing, there's always risk assessment that we have to be thinking about across all areas of the business. As my growth continues, then I start looking at things like how do I improve the automation within my factories and that type of thing. We have to look after our employees. We have to look after the marketplace. We have to be responsible citizens. Then we start looking at everything like equal opportunity. What's the job market like? Fair treatment of all employees, customers, and everybody that we do business with. Driving things out like customer satisfaction. Obviously, there are many things that go on in the organization, so we have a project management discipline for many different things that go on. As the business grows, I want to make sure that we retain the core values that we've instilled in the business and that everybody in the company is aware of them, so that takes a lot of work as well. We want to give back to society, so I may be thinking about things like philanthropy and altruism and those types of things, giving back to the marketplace that we do business in. With anything that we do, we have all kinds of compliance issues that come into play, especially if we're a multinational organization. I'm not just talking about data compliance, I'm talking about compliance with all sorts of regulations right from labor management all the way through to things like the compliance that we typically think about from a data management perspective. Of course, we want to make sure that we have a high level of business ethics as we go forward. This is just a small snapshot of some of the things that your business leaders may be thinking of on a given day. This slide could be infinitely more complicated with a lot more things on it, but I just wanted to give you a bit of a background about all the different types of things that your business leaders are thinking of, because in the end all I wanted was a lemonade stand, and I had to think of all these different things. What's really important is you need to understand this mindset of your business leaders, because as you're dealing with them in your organization, if you come to them with a technology pitch, it's probably going to fail. But if you can come to them with ideas that will instead sell business benefits, then you really have a shot at moving things forward. But more importantly, we need to be aware of all these different things that our business leaders are thinking about, because we need to make sure that our enterprise architecture and our strategy supports everything that the business is trying to do. If we're not aligned with the business visions and goals, then why are we doing the things that we're doing? So that's always a measuring are we aligning with what the business is trying to achieve. Now an interesting aside to this is in a consulting engagement I did many years ago I had a very interesting discussion with one of the technical developers, and as part of the discussion we were just talking about all kinds of different things, but he made that a statement that we're a java shop. And I said, well, you can't look at it that way. I said, we're not a java shop, we're a retail organization. And that's the emphasis is you need to make sure that you're putting the business needs first. The technologies at that level are irrelevant. We need to be able to help the business attain their goals, and we do that through enterprise architecture and a whole combination of technologies, but those aren't the things that are at the forefront. They're an enabler rather than the end goal. So let's talk about architecture in general. I've used this slide in the past and I've dusted it off again because it really is a good example that represents the reality of today's environments. This is the Winchester Mystery House and for those of you that may not be familiar with it, it was actually commissioned by Sarah Winchester many, many years ago and from the outside it looks like a huge posh and interesting mansion and this actually does exist in San Jose, California you can actually tour it and everything else. But let's talk about some of the realities behind this particular mansion. Here's how it evolved. There were eight years of construction, 147 different builders, absolutely no blueprint so it kind of grew organically by adding rooms and layers on here and there as needs dictated or as she wanted. There was no planning involved and here's the result. Up to seven stories in the buildings, 65 doors to blank walls, 13 abandoned staircases, 24 skylights and floors, 160 rooms with 950 doors, 47 fireplaces with 17 chimneys, miles and miles of hallways, secret passages all over the place and 10,000 window panes and every bathroom was fitted with at least one window. This is a real parallel to what we see in our organizations from a technology footprint today because as our businesses grow, they tend to grow organically and unless there's been an architectural plan right from the front, we find ourselves with all that integration spaghetti that's out there by piling systems upon systems and really trying to integrate things together which becomes a very challenging proposition very quickly. Here's what we typically find in our organization, a proliferation of disparate systems. We see one or more ERPs, mismatched departmental solutions that have cropped up. A lot of SAS applications that are externally controlled and managed, obviously cloud is taking a larger and larger footprint all the time. We also see a lot of obsolete legacy systems for decommissioning strategies so a lot of those systems actually should be gone but they still remain in our environments which just complicates things even further. What we often see as a symptom of problems is a lot of point-to-point interfaces without a really good integration strategy. Obviously we see data warehouses, data marks, obviously data lakes, a lot of ETL going on trying to extract out the data and make sense of what's going on in our business. Now if we've gone through mergers and acquisitions, this can be multiplied many times or even exponentially in terms of a level of complexity because you have things that are all over the place that you need to be able to track and you don't necessarily know where they are so you really have to get a handle on it. This is our interpretation of what it takes to look at data governance and enterprise architecture. We look at it as a structure. Everything is rooted in data. Everything that we do in our businesses has some type of representation in data which is a very solid data architecture foundation. On top of that we have a central pillar of business architecture that really gives the context to how and why we use the data in our organizations and then flanking it our application architecture and technical architecture. The applications that we deploy to do this workforce and of course the technical architecture that supports all of this. By building this balanced type of a structure that's how we really enable our enterprises and really start to meet those goals and strategies that we were talking about earlier on. All of that needs to be in place to really have a solid foundation to support governance initiatives and it's not a one-time thing. It's not a project. It's an ongoing journey. If somebody ever asks you how long is it going to take to implement the enterprise architecture in your organization and when it will be done, the answer is we will never be done. We will be done when the business is done because the business is continually adapting so we need to keep adapting our enterprise and our approach as we continue in business. We'll just take a very quick flip side to a few things and just define a few of the terms. Enterprise architecture is a defined practice for conducting enterprise analysis, design, planning and implementation using a comprehensive approach at all times for the successful development and execution of strategy and we're really talking about execution of that business strategy. It applies architecture principles and practices to guide organizations through the business, information, process and technology changes that are necessary to execute those strategies. That's a fairly comprehensive definition. When we look at data architecture, the supporting layer that we have at the bottom there and our foundation for all of it, the data architecture is composed of models, policies, rules or standards that govern which data is collected, how it's stored, arranged, integrated and put to use in data systems and organizations. Again, everything in our business has some type of representation in data so this is extremely important. The business architecture or that central pillar that I talked about is a blueprint of the enterprise that provides a common understanding of the organization and it's used to align strategic objectives and tactical demands. That's from the business architecture body of knowledge. It encompasses things like business process modeling and a number of different things as well that we'll talk about as we move forward here. An application architecture describes the behavior of applications used in the business, focus on how they interact with each other and with the users. It's focused on the data consumed and produced by the applications rather than the internal structure. Applications are mapped to the business functions. We'll talk about that a little bit as well. And of course the other enabler is the technical architecture that supports all of this from a technological point of view from network architecture, distributed systems and everything else. It really is that system architecture layer that defines and specifies all the processes, parameters and protocols used by all the different architectures that we're talking about here. Here's our perspective from an ER studio point of view and I'm not going to dwell on this too much but to be able to drive this we need to be well rooted and have a very strong modeling discipline to really understand our organizations and really drive forth things like enterprise architecture. I'm actually going to start at the bottom left of this particular slide and talk about things like the business architecture and our business architect product. Typically you're going to have business analysts working with your business, identifying goals, strategies and those other types of things as well as really defining what the business processes are in the organization. As part of that you're going to flesh out a lot of data requirements. So you're going to have, you need the ability to create conceptual data models which what you can do then is further elaborate those when you come up to the top of the area which is our data architect where you're really doing things like driving out your logical data models, your enterprise models and in particular physical data modeling as well as logical data modeling and I'm talking about not just transactional models here, I'm talking about dimensional modeling for data warehouses and data lakes and those types of things and also the ability to really import and export metadata from a variety of other sources which we do through our MetaWizard bridges. Something that's also extremely important is the ability to understand how that data is used in our organization and I'm talking about data lineage and data flow modeling as well as a huge part of that. The other important part is as we're continuing to elaborate and understand our business from a process point of view back down at the bottom of the screen again we need to be able to reference all those data structures as needed in our business process models and we'll talk about this in a later slide where we started a high business process level to get down to detailed levels of how we're actually utilizing the data in our business. Very important is of course to round out the technical architecture is we often need some things like UML modeling to drive out other constructs and that type of thing. Obviously things like component diagrams, sequence diagrams and those types of things because those really help to round out things from both application and technical architectures and what we really need to pull it all together is a repository that we can check things into at a collaborative environment where we can share the information and also start to drive governance and enable it with things like tying in with business glossaries and policies and other things like that. This is an overview of what we do in Enterprise Team Edition and this is kind of the overview of some of the things that I'll be talking about in terms of a general approach of how we need to approach this from our business. When we talk about enterprise architecture the models are crucial. There are many architecture frameworks out there such as Togath and this is a representation of the Zachman framework. Both of those are very popular and there are a lot of other ones out there as well. I actually prefer to use Zachman for discussions like this because I find it's very easy for business people to understand just because of the way it's laid out. Again what we think of when we talk about these types of things is we're looking at things like data and process and a number of other things. Just think of data representing the what and process representing the how as we actually talk about through some of these different things. Now the interesting thing about this when we look at the Zachman framework what we're really doing is we have a lot of different considerations. We're talking about what, how, where, who, when and why and as we go down the page we're actually going from a higher level of abstraction if you will down to more detail level so we have the contextual level down to conceptual levels, logical, physical and the detailed levels as we go further and further down to drive this out. For things like the what we're talking about things like our products our customers and those types of things identifying those critical things that are important to our business. Our business processes and how we're actually conducting our business is an example. The where is how, where do we conduct our business in the organization? Is it where are we geographically? What markets are we in those types of things? Who's responsible for the different things? How do we comprise our organization? When are we with things happening? What are the types of events that we actually have occurring in our organization that we need to respond to? And again thinking about that original lemonade logistics what are our goals and strategies and that type of things which is really enabling the why of we're doing all the rest of these things that actually comprise these diagrams. As we go through the layers we see a lot of different types of things that we're producing and it's not a top-down waterfall approach it's generative approaches we keep evolving all these different areas of the architecture framework. Everything from conceptual levels to ER models down to logical models to physical models down to detailed data specifications when we talk about the what. Same thing with elaborating our process models and decompositions out to very detailed process details in our organization. Same with locations who in our terms of our organizational units and of course the events and the rules and everything really tie in what our business processes are doing and why they're doing it and how we're actually implementing them throughout our applications and the rest of our architecture. Look at it differently we can basically say the top level defined scope we work down through a business model level then down to a system model level only down when we get to the bottom the second bottom layers when we actually start talking about specific technologies and then we get down into detailed representations of the actual implementation. So a lot of the work occurs at the top three layers which are technology agnostic and we need to remember that this is really where we focus on that business alignment. Now from a data modeling perspective again I think most of you have seen this so I won't spend much time on this but our data models start at the conceptual level which are technology neutral, high level entities the relationships we're not looking at capturing things like keys or detailed constraints or anything at this level we're just dealing with building blocks of information and how they relate to each other in the organization and it's really to understand a contextual understanding amongst the domain stakeholders or business stakeholders in the organization. The logical models are a further elaboration of that and that means we're adding detail to the conceptual models in a technology neutral setting again and more context on the relationships, building out things like our data dictionaries with terms definitions and those types of things in the data dictionary perspective and then of course the physical is when we actually start looking at how do we tie these things to particular physical database implementations and that includes things like indexing where we're federating the data stores and that type of thing so the physical really gets down to a very detailed specification within the models. The goal here is to be able to generate those data structures and stores from the models rather than thinking of the models as a byproduct or a documentation tool. It should originate from the model and drive out from there. In terms of the data itself we need to understand the data value chain and we need to focus on this throughout our organization. Just raw data is a representation of facts as text numbers, graphics, images, sound, video all those other things that we're accustomed to but on their own they really don't mean much to us. What we really need is we actually need to have context. When we have the definition, the format things like timeframe and relevance of the data that's giving us the context and that really translates data into information. Without context that data is meaningless. We just don't know what it means. We don't know what the number three means unless we know what the number three is talking about as an example. When we take the information we then look at the patterns and trends in that information. We look at the relationships amongst the different types of information in our organization as well as the assumptions that are coupled with that information and we've got that is when we actually can take that and translate it into knowledge that we can use to drive our businesses. This is extremely important because the organizations that do this well have a distinct competitive advantage over the other people in their market segments. The other part that comes in play is to fully understand the data as part of this data architecture is we need to understand the data life cycle. How are the different types of data that we have in our organization created? Where is it read? Where is it updated? Where is it deleted? In other words where is the overall life cycle about this? We need to know we need to create and collect the information. We need to classify it which means we're building metadata around it. We need to understand how we're storing it. How it's being used and modified. How we're actually sharing that across the organization and that may also involve of course things like transforming that data as we're moving it between different applications or across enterprise services services or however we're sharing the information. Extremely important is what's our retention and archival policies around that data. And just as importantly when do we need to destroy that data? We need to know all of this and we need to be able to document all of it and the way to do that is by modeling. Many factors come into play. What are the business rules? What are the business processes that act upon that data? And what are the applications that implement those particular business processes? If we don't understand that we don't really understand the architecture within our organization. Other things to remember is there may be more than one way a particular data element is created. They can originate from different places so as we're looking at this life cycle we also need to know how we can reconcile all of those different points of creation as well as the points at which the data can actually change in our business processes. So that means we need to model many different things. Not just the data models themselves but the business processes, the data lineage which comprises things like data flow, what our integration architecture looks like, and that includes things like the extract transform and load or ETL for data warehouses, data marts, staging areas, data lakes, all those types of things all has to be brought into play here. And the way to understand that is with modeling. Without modeling it's extremely difficult to get a handle on this. With that let's talk about just data models for a moment. Here's a very high level in terms of the types of context or the types of things of how we relate our models together. What we really want to do is we want to have some type of an enterprise model that really tells us about what's the information that's important to us and to this business. Because at the bottom when we look at the implementation models we're going to have information scattered throughout all these different systems that I talked about which means a lot of different data stores which could be relational databases, no SQL databases, flat files, you name it, as well as warehouses and with that I'd also put data lakes, I'll categorize them together. What we really need to do is we need to know what information is important to us. How do we describe that which is where our data dictionaries come into play with definitions and everything else as well as technical specifications and then tying that together with where is that data implemented across our organization and how are these different databases and data stores used in conjunction again with those business processes that we're talking about. But this is the data model that's active. What we also want to do when we talk about that enterprise model and we look at all those different implementation models that are out there is where are the overlaps. So if I look at things like my enterprise model and I have things like supplier, item customer, and state and province which is the terminology I've chosen for my business, I may have all kinds of different databases out there and these may be called different by different names in those different databases. Some of it's because it's an ERP that we've produced from a vendor. We can't change those types of things. It may be changes over time where terminologies change in the business even on internally built systems or changes in naming conventions. What we need though is an ability to actually stitch these different things together because they are really part of the implementation of a larger order concept. So in this example supplier ties together with something like vendor and implementation model one and suppliers and implementation model two and you can see these associations. This is what we call a universal mapping and the universal mapping is really the thing that ties those things together. We can actually do this across models in our repository so that you can stitch together this larger picture of how all these different types of information are tied together in your organization. The byproduct of that is the ability to link those like or related objects. We can do them with the same model. We can do them across models. They can be a lot of people think of it at an entity level or table level depending if you're thinking logical or physical. You can get down to a very granular level even doing it at an attribute level for example and you may want to do that for some very critical data elements. The byproduct of that is when you look at the right hand side is if I do aware used on this enterprise model that I'm talking about that I'm using as my focal point if I do aware used on my customer here I'm seeing all the places that customer is implemented and what it's called. That gives me a lot of power that I can actually go and see all these different artifacts and all these different data stores in these other models but I know what they are just from looking at this as a byproduct of creating it. The data models themselves and here we're talking again about more conventional data modeling. It's not just a picture. It's a full specification. The logical specification, the physical specification in particular what I'm going to talk about here. The larger containers around there that are color coded are the persistence boundaries which we call business data objects. Again this is really good to bridge knowledge between technical stakeholders and business stakeholders. Business people think in terms of an order or a customer or an item. They don't think about the underlying tables that comprise those and the same happens when we're doing with a lot of application developers. So things like the business data objects allow us to encapsulate these things in terms of how would we group these entities or tables together and from a persistence perspective. So when we create them what are the related entities that we need to populate. We can create that. The nice thing is we can actually collapse and expand and collapse them as well and actually hide the underlying details with other stakeholder audiences. Just as importantly all of this is descriptive metadata that we need to define. The names, the definitions in our data dictionary which often tend to be more technical definitions also notes and considerations about that. Implementation characteristics. Everything from data types, keys, indexes. I didn't call it out specifically here but I'm talking about specifications right down to domains and reference values. All that type of information should be specified in the correct level of model. Business rules are represented by the relationships which are implemented as referential constraints in our actual databases. Security classifications and rules are very important. We define those at the modeling level and then we can carry it through everything downstream from that and then in governance metadata. What are our master data management classes? What about data quality classifications? Retention classes that I talked about for the data and in the whole manner of other things we can define all of that in security properties right at the model level and push it all the way through so we're basically everybody's looking at it from the same perspective throughout the organization. The way we do that as an example and this is an example of kind of zooming in on that part of the data model is data models like I say just aren't for the technical specifications. When you look at this particular one for every entity in my models I actually define a number of characteristics and in some it's less and some it's more but things like master data classes, the business value so we know what to focus on when we're doing things like data cleansing and making sure we have data quality is a part of a master hierarchy. What's the volatility of the data? Is it stable or unstable? Unstable data requires a lot more management and care where stable data really because of its stability doesn't require a lot of interaction to make sure that it's clean. What's the data retention policy surrounded? What are the stewards responsible for? And again I've only shown you a couple here but we can have a multitude of privacy levels, security impacts and other things that we can actually tie to our data all driven from the models and flowing downstream. When we talk about data lineage quite often when people talk about data linger, think about it. They think about extract, transform and load in terms of from a BI perspective or data warehousing and that type of thing where they think about what's the source data? Is it going into a staging area? What are the transformations we do on that data and ultimately where does that data end up residing? Which is an example of what we're seeing here where we're seeing a number of staging tables, the transformations that are happening into on the loads and how they actually load into this particular table in this example. However lineage is not just for ETL. There's a lot more to it. If you're not tracking the movement of your data through your different systems that means you have an incomplete understanding of that data. Here's another example of how we can actually use lineage where we're actually advancing through the life cycle and how the data is being used at a high level in the organization. This example is an extract where maybe we start our customer information in something like Salesforce which is a SaaS solution but by the time we actually start using it because they become customers rather than prospects then we need to make sure that we're keeping track of those customers in our accounting system which in this example is PeopleSoft. So what I've got here is I've got my source data. I've got representations of some of the transformations I'm doing against it in terms of the mapping and the things that we're doing to it and how I'm actually landing that into my PeopleSoft system. This is the type of information you need whether you're doing point to point interfaces or preferentially doing something like a publish and subscribe to an enterprise service boss but you want this level of information so you know how that data is moving through your business. Now on top of that let's talk about business architecture for a moment because this now starts to give us the context and provides that flipside in that central pillar that we're talking about. When we're talking about business architecture we're focusing on our organizational capabilities things like our organizational structure, information about our organization as well as the information we use and how we actually build the value streams in our organization. What are we producing? Why are we producing it and what value does it add? As we expand on that further we start talking about different things that tie back to some of those that previous diagram that I was talking about when I was talking about the Zachman framework. We start identifying things like who do we do business with? Who are our customers? Who are our trading partners? Who are our competitors in fact in the marketplace? What are our business visions? What are the strategy and tactics that we're going to have to realize those? What projects and initiatives do we have on the go to support these things? What are the policies, rules and regulations that we have to deal with when we're interacting with our environment? What are the products and services that we offer? And of course what are the metrics and measures that we have in the organization so that we can measure success? And what are the decisions and events that we're making throughout our business as well? Again, we can put a little more context around this as here's come the questions that we ask around like metrics, how well are we doing? Products and services, what are we doing? The organization, who and where? Policies, rules, regulations, why? Capabilities, what are our capabilities? Again customers and partners, who and where? And you get it, the why's, the what's, the house all this tying back to things like that, Zach when framework and answering those types of questions is what the business architecture side of things is about. Now your typical business can be very complex. A tool that has been around for many years or technique I should say is the idea of using a business decomposition and that is identifying the different areas of your business and the different areas that make up those areas of the business. So what you're really doing is you're decomposing it into the building blocks or a functional breakdown of what your business does. I'm going to zoom in on a smaller part of it. So on this particular one and this happens to be from a pipeline business example I'm doing things like scheduling here but I have all kinds of things like schedule planning which is broken down to a number of different activities. I have operations I have all kinds of things around that like managing my schedules and actually managing how I'm executing those schedules with all my terminal operations and moving of oil through the pipelines and that type of thing. Every one of these areas of business process or processes associated with us but this can be our higher level road not to saying this is how our business is put together and now we can go down to the lower levels and actually detail out what those different business processes are and how they actually contribute to the whole of that organization. A good way to represent this as well is to do things like a high level process context. So here's the same type of business. This is in order to cash cycle believe it or not of a pipeline business. I've got some very simple things here in terms of having a very high level business process I've brought in some of the very high level types of data stores that interact with it for the types of information that we need and if you trace this you see different things. The different swim lanes or blocks that you see in this diagram are tied into business different business areas and processes contained within those particular business areas and as you can see we cross over into different business areas as well. The red that I've got here because it's color coded just to make it easier to follow is basically the core of my basic order to cash cycle for and in the pipeline business they're called nominations so it's everything from receiving the nominations, validating them I then have to do some type of a capacity allocation against that to be able to move it. Unfortunately I won't go into the detail but it's really again allocating it based on pipeline capacity and that type of thing. I create things like a baseline capacity plan which then feeds into my schedule building which then goes into my daily oil movements of how I actually start moving my oil through the pipelines. I have monitoring activities I'm executing it then I'm doing things like executing tickets for the transfer of the oil in and out of the pipelines through the terminals. By the time I've done that so I've actually accepted the oil at one end I've delivered it the other end to whoever's supposed to be receiving it then I have all my financial transactions and my reconciliations and calculations, generating invoices and all that ties different areas of the business and things like my shipper portal and other things come into play what you also see is supplemental processes that tie in and a lot of assumptions and just some type of things to really characterize what this overall process context is about. When I go deeper I'm probably going to go into something more like a true BPMN process diagram where I've got the swim lanes that represent my different areas of the business, the different processes tied into it, the business units involved and again I'm tying in higher order types of information and these are some of the data stores that have actually come out of some of my data models even at a high level but I'm actually now showing what the process is, who's involved with it as I evolve through this process, the types of things I'm producing and the data stores that I'm actually using at a high level. Let's talk about that. Let's go back to that business decomposition for a second. What I typically will have when I'm doing my data models is I'll also break down my data models so when I have that business decomposition that we had in that fairly complex slide, I also want to break down my data models into what we call sub models. In other words, what are the entities or tables of interest in that particular business area and we can do that by decomposing our data models into these sub models. This is a snapshot of a small part of the model used in this one particular process we just talked about but now how do I start to map in these particular data stores into those lower level processes that are coming on. I drill down into specific processes and now in here I'm seeing more discrete data stores and what I see here is I've actually just done this to keep it simple for an example but I'm doing things like what's the actual basic nomination process. One, I may have multiple pipelines in my business which line am I actually nominating it for. I'm creating what's called the notice of shipment header and the details of the different types of commodities I'm going to move on to and then I'm also going to verify and submit it. What you see here is the data stores that come into play from that data model but very importantly is what you can see and I've clicked on one of them. I can see all of the attributes of that data store writing context in this diagram as well if I want to but just as importantly also within this within the metadata but on the diagram itself you can see the crud. So am I creating reading updating and deleting for these different processes or operations. I can get that granular in my detail if I wish to and it's very important to do that to really understand the data in your organization. I'm going to round things out just very quickly here before I kind of go into the last part of it and that is of course I've focused primarily on data and business architecture here but we need to remember those upflanking pillars that we talked about in terms of the technical and application architecture. We had some mention of applications in the business process because we can tie any process to the applications that implement them but other things that we need to think of is maybe we have some use cases that we need to communicate. We may have things like sequence diagrams to really help us specify things like the logic and states and that type of thing that go on. State transition diagrams of course of things going on there and of course things like classes communication diagrams as we're getting into applications with the components and the structures those are and deployment diagrams as well. We want to be able to augment all of those things that we talked about from data and business architecture with these other technical considerations as well. Now we're going to that roof of that structure or going higher just like in talking about how we're actually enabling the governance now that we've started looking at this underlying structure all together. This of course is my reproduction of the DIMBOC wheel, the data management body of knowledge and all the different aspects that we talked about in terms of data governance. Everything from data architecture and modeling through data storage, security, operations and this includes documents, reference and master data, data warehousing, metadata and data quality. We've talked about aspects of all that already but what we're going to talk about from a governance perspective is now how do we take this even further and this is where I talk about what's the underlying approach that we're taking. If you're using just a metadata repository and doing a bunch of metadata imports from different things and actually building out things like a metadata catalog and you don't have those visual models to tie it all together that's like having basically buckets of parts without blueprints of showing you how they're assembled and work together. It's very difficult to work with. You can do things like text search and look up but it's very difficult to really understand what your business is doing holistically. Those of you that have heard me before heard me talk about this is kind of the perspective of the Flat Earth Society where you're really denying yourself that holistic viewpoint of your business. What we really want to do is we want to have fully integrated metadata, fully integrated visual modules like we have in the ER studio and that gives us that global perspective. A visual focal point for data models, business process models, tying in things like those visual data lineage models that I gave you just a brief glimpse at and more importantly it's also a building block to tie in other metadata such as business glossaries, policies, reference data and having it all accessible in one place. With that just a very high level business glossaries sometimes people talk about the business glossary. In reality an organization will have multiple types of glossaries and different terminologies that they have to reconcile. Some of it can be based on again the business decomposition in the different business areas but they can also be other things. They can be internally and externally focused nomenclature or a number of other things. So what you want is a glossary structure that is very flexible where you can actually have nested child glossaries and even network glossaries that comprise other glossaries which is what we do. What we also want to do is make sure that it's limitless in terms of how many hierarchical levels do you need to represent and of course that ties in with how many hierarchy levels or how deep is the decomposition in your business. It differs for everybody so you want to make sure that you can mirror that with your glossaries as well. Rather than show you just the standard type of here's a definition in terms of the type of thing that we typically do, what I really want to emphasize here is coming back to the modeling platforms as well. What I've got here is actually a representation in the entity that I'm working with in a particular data model but when you see what's happening in this editor all these underlying words and don't worry if you can't read them in detail are actually words that are actually in a linked business glossary that I've got here. The reason they're underlined is they're hyperlinked. If I mouse over them I can actually see the definition. I can actually click through and look at all the metadata for that term in that particular business glossary and I also have the ability to create terms from my data dictionaries and push them into the business glossaries as well. So it really gives me that holistic view and it gives me the ability to attack it from all sides. Technical users collaborating with business users building up the business glossaries and the meaning around them. I want to talk about governance policies as well. Organizations and we saw this even at one of my earlier slides like regulatory compliance. I'm talking about data management here in particular right now but we have many different policies that we have to comply with depending on which jurisdictions we're doing business in. This ties into everything from GDPR policies, HIPAA policies, it could be payment card industry. Here in Canada we have something called PIPEDA for personal information. Sarbanes, Oxley everyone's familiar with. The real important thing here is we need to identify all those different data governance bodies that we need to comply with and underneath that what we need to be able to do is break them out. So for HIPAA for instance what I need to be able to do is take that and then I actually need to have data policies so what I've done here is I've actually broken out a number of different policy statements that are all taken from HIPAA and by doing that I've now set myself up to actually associate these business policies or regulatory policies with the data elements that they apply to within my metadata repository that's all fed from my models so I've taken all that metadata from my models, I'm now marrying it with these policies and other things from my glossaries. What it also allows me to do is things like security and parameters and that type of thing I can actually even do things like set up alerts so what you see here is that exclamation mark at the top originating in my data models I designated this as sensitive information and that flows right through how it's published even when I'm looking at the metadata around it so as I'm going further I know I'm dealing with sensitive information here and I have to treat it carefully. Also here's another one here's that patient admission now what I've actually done I've flipped to okay here's my other related thing so I've actually tied in here's all my related policies from the different types of regulations that tie into this particular type of information that I just talked about. Another thing that we want to be able to do is under master data management, reference data management we have a lot of reference data sets that we want to be able to keep track of. It could be something as simple as units of measure, provinces, states, maybe we buy things like postal codes and those types of things externally and we load them in that type of thing. We want to be able to keep track of all that information and be able to share it across the organization. So there again if you can hyperlink to it whether it's in master data management repository or link spreadsheets or whatever you could actually do that you can set up a catalog of your reference data sets and you can break that down into further catalogs if you like to and have links out right to the data sets that you want. In this instance what I've done here is I had country codes that I just happened to keep in a google sheet. I can link out to it so I can see all of it maintained here and obviously it's going to be used to load into my reference data stores in my organization as well. At a very high level because we've covered quite a bit here today again what I really want to emphasize is when we look at that foundation of data architecture I'm going to depict it a little bit differently now. At the core of this and enabling your overall enterprise architecture are your data architecture and your business architecture. Everything from your conceptual models your logical and physical models then that includes a dimensional your data lineage about how that information moves through the organization and your business process models about how those pieces of data are used in the actual business processes in your organization all tied together with the enterprise data dictionary that includes a lot of the physical information about your data all the characteristics as well as things like data security policies and your classification schemes for how you actually catalog all this metadata around that other aspects that come in is you're tying it together with business glossaries with your different business concepts policies tying in those reference data sets that I just talked about security of course is paramount so we've got to tie that in. We have alerts and notifications that you have to bring together and you have to understand all your different data sources in the organization and of course some are more important than others and you need to be able to define that. From the business architecture perspective at the bottom to give all this context we're tying it in with goals and strategies business rules implemented in different places for the business processes as well as things like relationships in our data models that are an implementation of business rules the business units that are using this the applications that are implementing the the processes the stewards responsible what we also need to be able to have is things like collaboration and that involves doing things like following things that are important to you in terms of the metadata that's important to your area of the business as well as being able to discuss it with other stakeholders in the organization so being able to support it with a collaboration platform like discussion threads and those types of things. That was a fair bit what I really want to emphasize out of this is businesses are becoming more and more complex they're not getting simpler anytime soon mergers acquisitions all those other things I talked about it's compounding it and we need to be able to deal with it the only way to decipher that complexity is to rely on enterprise architecture and that means we need that foundation of data process and technology all tied together data is the fundamental building block in every organization is rooted in the past it's a key indicator of what's happening in the future and it's also a strategic asset of the future we got to remember that everything we do in the organization has some type of data representation it's the phone data again is the foundation of enterprise architecture and governance we have to leverage data and unlock that value change data on its own doesn't do much for us we need to transform that from the stages through information and ultimately knowledge in our organization and it's that knowledge that provides the competitive advantage to your business the business architecture is coupled right with that that provides the context of how your organization works what allows the organization to adapt to its business environment which means business enablement what are your goals and strategies who what where when and why and of course tying that into the data and how it's used visual modeling is more important than ever before and that means data modeling process modeling data lineage tying all that metadata together and then we have to have that governance structure on top of it that really helps us to comprehend it and manage all of it thank you for your time and we'll now open it up for questions thank you so much for another fantastic presentation everyone's just loving it lots of questions coming in if you do have questions run please submit them in the bottom right hand corner of your screen in the Q&A section and just to answer the most commonly asked questions I will be sending a follow-up email by end of day Thursday with links to the slides and links to the recording and anything else requested throughout so diving in here Ron can you nest multiple business data objects actually the answer to that is no what the business data object is is how should that be persisted as a collection now you can group them by using other constructs in our models but when you think of a business data object you should think of that as a persistable object it shouldn't be confused with the subject area or a submodel where you may want to have more and more layers of breakdown what you should be really at the granular level of what comprises just that persistable business data object or business object so what is the best way to expect models from ER studio to share with non-licensed business stakeholders non-licensed business stakeholders if you're talking about the actual data architect tool itself that's where the collaboration portal comes in called team server comes in because all the models that we have not just the data models but also all those business process models and things that we talked about can all get published out to team server and that means all the metadata as well as all the visual diagrams and layers of those diagrams get published out to a web portal and of course access to that can be controlled by who can see what but then people can actually go through and see the actual diagram representations as well as the metadata involved with it and what were the most difficult challenges you have found in implementing enterprise architecture and organizations lacking such how did you overcome the biggest problems are typically people problems they're not technology problems and the hard part is getting the buy-in and that kind of goes back to some of what I talked about at the beginning if you try to pitch to like even a CIO if you're pitching technology at times versus business benefits or a CDO or a business leader you need to say you really need to be able to look at it from what's the business benefit that it's going to bring so how do you understand your business and what's it going to do what values that going to derive and if you can sell the business benefits which of course we talked about in a previous webcast that's your that's basically your foot in the door to really start to drive this forward but you've really got to be aligned with those business leaders you've got to get your message through to those business leaders and once you do that then the door opens I found that the best way to do that in an organization is find one person that's receptive at a senior business level and they will soon become your advocate once you can actually start demonstrating the benefits can you extract import to other tools to Visio or Excel yes easy that was the shortest question and answer I think we've ever had the answer is why would you want to so again really and I know exchanging information through spreadsheets and for people to update and stuff like that we can do that many different ways and it is actually a good way of collecting information and bringing it back in as well so push it out have people edit it and bring it back in we do that all the time but the other thing you've got to think about is the true benefit is coming from having this integrated repository where you can tie all of these things together organizations that fail and enterprise architecture are those that are built on just diagrams and spreadsheets but they don't have an integrated repository behind it and Howard a person just starting out in this field get a solid foundation to build upon love that question I'm going to do a commercial here a good place is through webinars like this if you're not signed up for enterprise data world go there you're going to get a lot of information on topics like this and other ones and industry trade publications network with your peers in the space that's the best way to build up your build up your knowledge so this idea help with mapping application for example Salesforce data models with existing data models and the organizations to draw lineage well the nice thing is what you can do is you can bring in the metadata from all kinds of different sources like for instance Salesforce and that type of thing we actually have a companion product called Sapphire that will actually extract things from SaaS platforms and ERPs that interrogate those data dictionaries that will bring that metadata into the modeling area that you need once you've got it into your models that's when you can actually start to detail out what your lineage is now other things that we do is if you actually are using specific ETL tools on enterprise team edition what we can actually do is we can interrogate those ETL routines and actually bring them back and generate visual lineage diagrams as well. Can we build MDM and RLS row level security model in a centralized way? Okay in terms of MDM what the modeling tool is not is not an MDM catalog per se that keeps the data itself but what you can do is you can build all your classifications at your modeling level which means that you're basically classifying your data stores out there including what you might have in a third party MDM store or external files you're probably going to have a mix of them actually in your organization and then you can actually link that information together so really the modeling is the metadata about it but you're still going to need some type of a store to actually keep the data content itself if that makes sense. It does and what ETL tools do you support or interface with? Oh there are several everything from SSIS to Informatica things like Oracle Data Integrator, Talent Data Integrator and a number of other ones. I'd have to go through the list so. It's a long one I know. Let me see if I can pull up this question here I'm having trouble seeing it here. Is there a good example of bang for buck in an enterprise that went through a governance process and what did they go from and what was the result? Was it quantifiable? Yeah I actually again I gave an example in a webinar the one that I did back in December where we actually walked through the business benefits of overall architecture and basically business alignment and that type of thing and for example that was a manufacturing organization that I worked with and excuse me if I don't remember all the numbers off the top of my head here but we achieved several different things by being extremely focused on the data, the data claiming list, how we're using it in our business processes and actually implementing business process alignment and changes as well as part of that whole initiative but we did things like took our inventory control from a physical count once a month to full just in time inventory it would take a month to six weeks to actually deliver product to customers and we were storing finished goods we were able to reduce our inventory by two thirds and increase our sales levels dramatically so when you start doing things like looking at the numbers around save carrying costs as well as just meeting the competition to the punch by getting the products out there we literally had business benefits of millions of dollars. I love it I think we've got time for a couple more questions here is this idea of support big data Hive and Impala to reverse engineer and as target? Yes we use basically and that's the thing about the integrated modeling platform is we support SQL platforms as well as no SQL platforms Hive of course and we have meta wizard bridges for those that we don't natively support so we have multiple ways to getting most of these platforms in we've also extended our notation so if you look at something like a document store like MongoDB for example that we support natively in the tool we've actually extended the relational notation to handle non-relational constructs like embedded objects and better to raise and those types of things because you need to be able to look at that data holistically and having it in one platform is extremely important to be able to do that. Final question here I think we have time for is the idea of metadata tool configurable for example can you add new platforms like domain business owner or is the data entirely screen locked down? You can do many different things. Right from the data modeling tool there are different things that you can do there. The data modeling tool itself which is the data architect we have a concept called attachments and those security properties are also a special type of attachment. You can build out as many of those as you want so you can create all the metadata you want around that. Anything back in the tool so if there are metadata constructs that you want based on specific platforms or anything else you can build them in and you can actually define which object types they would apply to in the tool. Now the nice thing we can do as well is I can build a construct maybe it's something I actually want to have that applies to both for instance entities and attributes and something else for an example like maybe my business data objects. I can actually build it once and apply it to all three rather than having to build separate representations for all and as I populated it all that publishes out to my team server models as well. Now on the team server side where my business users are working we can also build out characteristics again driven by that same attachment type of mechanics under the covers is we can call basically build out user find characteristics that can actually be built out into all the business glossaries and that types of things so you can actually build out the different types of data that you contain in your business glossary as well so you can build it. You can have a lot of capability for extension. That was long winded but basically the answer is yes in a lot of different ways. No worries I love it. Well Ron thank you so much for another fantastic presentation. This has been great again I will send a follow up email to all registrants by end of day Thursday with links to the slides and links to the recording. Thanks everybody so much. Thanks all our attendees for being so engaged in everything we do. We just love it and we hope to see you next month. Ron thank you so much. Thank you everybody and have a wonderful day. You too. Thanks all.