In this session, Aaron will provide an update on the open group preliminary standard for open business architecture that I mentioned earlier on, OBA. So you hear a bit more about it now from Aaron. So please give Aaron Rostrom a big, big warm open group. Welcome. Welcome. I really appreciate what Jeff was talking about and can relate. I've been doing architecture, I call myself architecture practitioner for 25 years, let's say, eight years before that. I was an organizational change agent for one of the congressional agencies and designing and developing and implementing human system changes, mainly around agency or department level transformations. And it's true that at the end of the day it's all about culture. And when I teach architects, new architects and experienced architects about enterprise architecture, I always tell them that you spend 60% of your time being a communicator, 20% of your time actually doing your analysis, and 20% of putting models together and stuff like that. And so I can really relate to what Jeff says. And I always tell architects, don't forget to look left and right, peripherally, because that's the stuff culture that's not being said, that's as important as what's being said. And so for me, I can really relate to what Jeff is saying. And as an enterprise architect, as a practitioner, I'm always going back to my roots those first eight to ten years of my career, going back to looking at organizational change and culture change or organizational analysis types of stuff and applying that in a technology-oriented capacity. So I can really appreciate that. And Steve said at the beginning, you know, I'm really excited about the renewed or sort of the forward movement we're making around business architecture within the open group. I think, like Jeff has said, like Steve said, it is, and others are saying, it is an area of opportunity for architects. I spend a lot of time training our senior business analysts to think about things in an architecture way to give them a new way of looking at problem solving for their clients. And so with that, the open business architecture initiative at the open group is really about providing some guidance to companies for establishing business architecture practice. And so what I'd like to do is to kind of review, give you sort of an update on that status. So first of all, we'll update regarding the recent activities and work pertaining to the emerging, and I'll be better if I'm out here, emerging work around business architecture. So review the structure of the OBA emerging standards. So OBA stands for Open Business Architecture Standard. And then provide an update regarding one of the OBA preliminary standards, i.e. Part One of the standard. So organizations today are really, you know, this whole digital transformation thing, and now the internet of things, and there are a number of pressures from the outside and internal pressures to perform better and to behave differently and to engage with the clients better and to engage with the customers better. There are internal pressures and external pressures. So this is the contemporary organization. So the reaction is to mitigate the situation. And many organizations are embarking or intend to embark on a strategic transformation, organizational transformation effort, because they know that they need to do something different. So companies that are looking at doing digital transformation, for example, they know that in me, almost all of them have to do things dramatically different if they want to be successful in that area. Coming back to what I said before, for me, digital transformation is a human endeavor. It's not a technology endeavor. And when I work with our management consulting group within Capgemini, I'm always reminding them, don't look at this from a technology perspective, look at this from a human perspective and then technology perspective. So as an architect, how can I help? So what's needed is an approach to describe and then derive understanding of the required transformation. So organizations decide that they want to go through an enterprise organizational transformation or business unit transformation. I need to make sure that everyone understands up and down and sideways, left to right, what that actually translates to. So the Open Business Architecture Initiative is trying to provide just that guidance. So we're developing a new standard to provide the guidance for new and existing business architecture practices. So companies are, as Jeff was saying, initiating these business architecture efforts to try to bring some progress, some additional movement forward in this area. So the standard is intended to give some guidance around the business architecture practice. And the current standard focuses on transformations at the enterprise or organizational level. So what does a business architect need to do to help make sure that these enterprise organizational transformations are successful? And it defines an approach to ensure a clear understanding of the vision across all stakeholders. Just as Jeff was saying as a practitioner, I can tell you it's really true. The strategy diffusion sort of path that line he gave, that is really true. That definitely happens. So the idea is to come up with a set of mechanisms that will ensure and assure that as a stakeholder reads about the strategy and what that means that everyone hears it the same way, at least they see and hear the same words. So the emerging standard has three parts. Part one is really focused on let's make sure that people understand the strategy, what the transformation is intended to do. Part two will then describe the context which the business architecture practice is applied. And the part three will include specific techniques and guidelines that will enable the practice. So part one is the only piece that's a preliminary standard today and it's really around making sure that the business architect can articulate what the enterprise organization transformation is about to make sure that all stakeholders get it and think about it in a very common way. Not that they'll think about it exactly the same way because they'll have their own organizational personal biases, but at least they have a chance to hear it the same way. And our focus today is on part one. So part one is the first of three parts. It has a table contents that looks like this. It's going to go through a typical type of things around the standard around business architecture, present a paradigm for looking at what business architecture is and to propose a way of actually pulling off a business architecture practice. Through a particular business architecture framework idea. And so the standard is really trying to address three prevailing transformation challenges. One is consistent communication, which is really important if you're trying to fulfill a transformation initiative and the goals and objectives of that and the impact of that. Alignment and governance. Let's make sure that we have alignment across all stakeholders and that there's a governance process to make sure that everyone has a chance to iterate and influence the transformation and then to address systemic nature. And so there are mechanisms that the standard is articulating to help us with all of this. So first of all, it's a common language. It gives the business architects a way to speak amongst themselves as well as with the business folks on how to represent what the business architecture needs are. There's vertical and horizontal or cross domain traceability. So whether I'm talking to a stakeholder that is in different departments or at different levels of the organization that there's traceability in terms of the value or the impact that that can have or the implication that this new transformation will have upon them. So holistic view. So looking at things broadly and comprehensively so that whatever stakeholder I happen to be, I can see where my piece is going to be impacted and where the opportunities lie. And kind of integration of the kind of modeling and narrative around the transformation itself. And then a transformation process or method integration. So the business architecture practice needs to get integrated into the transformation planning and management exercise so they can influence what is actually going to take place and monitor and influence what is taking place. And then the last piece, the business architecture practice features. So this is another sort of piece of the standard where we make recommendations around what we think the business architecture practice should look like or feel like. So it captures and interprets the business strategy. It integrates and aligns strategy and structure and operations, assess implications and sets directions. So as a practice, those are the types of things that at the moment we believe are things that that practice should consider doing. The other parts of the standard will deal with design, develop and implementation perspectives of the business architecture practice. So the standard provides guidance for business architecture as I've been saying. And mainly to facilitate cross stakeholder and stakeholder group understanding of the vision for the transformation. The strategy, the approach, the mechanisms to actually help us realize the transformation. And then what are the implications from operations perspective or from a structure perspective as a result of the transformation? And this is all aimed at making sure all the stakeholders, regardless of where they sit in the organization, understand the description of the transformation and the potential implications. And the standard aims to do this through and provides a mechanism for a holistic view to make sure that companies and that their organizations can do that. So let's look at this holistic view. The holistic view is comprised of three domains, strategy, structure and operational. The strategy piece is really intended to make sure that we articulate all the elements that are a part of the strategy together, you know, the insights and the priorities and the value mechanisms that we want to have impact around the strategy. Structure says, you know, it refers to those elements that describe how the strategy is going to actually be pulled off. What's required from a structure perspective to actually pull this off, you know, organizationally, process-wise, operational, you know, structurally, what needs to be changed and what are the implications or the focus of the operational sort of domain. So ways that the business architect can articulate and to describe and visualize what those implications are and how to mitigate those or how to address those. So that's the holistic view at a high level. There are a set of artifacts that are, you know, deliverables, output that are proposed or recommended as part of the standard to a potential, new or existing business architecture practice. And they're aligned to the different three domains. So let's look at the strategy. So one is around strategic intent. So give the business architect a set of tools that they can use, selectively use. So this isn't a prescription. Think of this as a lot like TOGAP for those of you who know TOGAP. It's a framework in which I cherry-pick the things I need to use for what I'm trying to do. It's the same idea here. There's a set of artifacts that we think are important and that they're recommended. But as a business architect, I may choose to only do just a few of them or the ones that are really impactful. So strategic intent is one of those. Let's make sure that people clearly understand and I can describe what the strategic intent is. External vision. So what are the impacts and what's the vision from an external perspective? What are the priorities? What are the objectives from an external perspective? And then strategic priorities. So these are the three areas of artifacts that support the strategy or domain or allow the business architect to bring to fruition the strategy aspect of the transformation. And in structured domain, it's a business structure. So what are the structural elements from a capabilities perspective, for example? What are the things that are going to allow the strategy to come to be realized? And operational, there are operational contacts. I mean, operational is really about implications. Implications from an organizational perspective, from a process perspective, from a variety of perspectives. So there is a specific set of artifacts that are recommended for the business architecture practice to leverage while they're trying to address the operational aspects of the transformation. And so the idea is that with those artifacts being created and being proposed, we believe that there's a business architecture practice that would be the mechanism to create and maintain those through the lifecycle of the transformation. So whether it's an enterprise transformation or a process or department transformation, the idea is that this business architecture practice would be the team that would be on the hook to pull this off. So let's look at the business architecture practice. So within the standard, we actually recommend a specific set of requirements for the business architecture practice. So if I'm an executive or if I'm an enterprise architect and I think that the business architect thing is important, then what are the requirements that I need to think about? So that's the intent of this portion of the standard, to articulate for the person who's looking or investigating or thinking about putting together a business architecture practice or has one that they might want to improve. So one requirement is apply a common language. So this is really to drive consistent communication across all the stakeholders, with other architects, with business stakeholders, with IT stakeholders, et cetera. Another one is make sure you have mechanisms to give you the ability to articulate vertically traceability. So traceability from a strategy piece all the way down to the operations piece. So these might be things like vision or strategic intent or competence or capability or resources. So there is a specific point in time that I think about those things and I actually articulate and describe them as they relate to the transformation. Especially as they are related to the, as a result of the implications of the strategy of the transformation. Also I'll have mechanisms that you can articulate horizontally speaking traceability. So this is make sure that stakeholders that work might typically be working in silos in the functions or operational areas, but because this transformation, it spans those different departments that they might be in. Let's make sure that they understand the relationship across those different departments and organizations. So really from a cross business domain perspective. And I spend a lot of time when I teach folks about whether it's Togaf or other enterprise architecture frameworks. I spend a lot of time talking about these things called views. And a holistic view is, for the standard, this thing that provides a view broadly makes sure that everything is covered. In a few seconds I'll talk about what those three specific view areas are. But I teach architects, you may, especially when you're doing the logical design of the business, you might actually create 30, 40 different views and use about 12 or 15 because those are the ones that end up being impactful. So what we're doing here is we're recommending a specific set of views that the business architect can pull from to communicate what he or she thinks that they need to communicate to their stakeholders. So again, we think that this holistic view is an important piece to this. And then lastly, as a requirement, the department's implement transformation process integration with the approach to ensure right artifacts applied at the right time. So if the company has a defined transformation process, a typical set sequence of things that the transformations go through, let's make sure that the business architecture pieces are integrated into that. Or if the company doesn't have, which often can be the case, they don't have a formal transformation method or framework in place, that we influence what gets a part of that and recommend that the company does that. So that's the idea behind these requirements. So this set of requirements is intended to give guidance to organizations that are investigating, putting in place a business architecture practice. So think of them like that. And as is typical with standards, these will evolve over time, but this is the current set with their preliminary standard. So one of the things that the standard recommends is, let's approach things in a very systematic way through a structured process. And the recommendation is to have a three-step structured process to fulfill what we think are the requirements of the business architecture practice. And this is really to make sure that the transformation, the value to the business resulting from the transformation comes to fruition like it happens. And that the business and even the IT sides of the house each has some value opportunity coming from the enterprise or organization transformation, for example. So the first one is capturing insights. So this step is really about let's look at the market, let's see what's going on the market, let's look at what's happening across the different marketing departments and the product and services that the company sells. Let's analyze the market, let's understand implications. So what are the implications that are there as part of these transformation and vision transformation? The second piece is the alignment and governance. So this is about stakeholder alignment, alignment, and then having a formal way that the described transformation bits from a business architecture perspective can be iterated to address the needs of the stakeholder and stakeholder groups. So the holistic view of alignment, so the holistic view mechanism is just a piece to that and the common language for governance. So if I'm going to come and propose a change to a transformation or to evolve a particular part of the transformation, let's make sure we have a consistent way that the stakeholders know how to present that. And the third piece is communication, direction and enabling means. So this is once we have, once we understand what the transformation is about and once we have stakeholder alignment and governance, now we want to go out and actually communicate this broadly and actually implement it as part of the transformation. So let's apply the business strategy to, it might be to an organization, it might be to the enterprise. Let's communicate before we actually pull the trigger what's actually going to happen and why that's happening. And then let's choose some enabling means. So enabling means could be a wide variety of things. There might be some specific artifacts that we're proposing. It might be something specific. There might be mechanisms going on in the organization that might be a meaningful way to share and communicate what's actually coming. And this process is intended to generate a variety of views or output. So the idea is we have a systematic kind of a rigor to the process that we recommend as part of the standard. And coming out of each one of these pieces will be kind of a wide variety or I'd say a variety of artifacts or views. And the views are all about, let's make sure that our description, people can understand it. So you have a variety of views around that. So we can communicate it so we can share it and then that we can actually track the progress to the strategic goals. The structured process should have certain properties. So as part of the standard, we recommend that there is a structured process. Well, that process should have some specific properties or characteristics or attributes. And one is the holistic view, which we've talked about already, but it's the complete set of descriptions of business strategy, structure and implications. So it's a holistic view from that perspective. Way of fields. So the way of fields describe the different aspect areas of the business architecture practice. And I'll say a little bit more about the way of, but think of the way of doing something, way of, is a specific application of how to describe how the business architecture practice would work. And then common language, sort of a set of defined concepts that are essential to the business architecture practice. So standard set of process, you know, standard structured process that has these particular properties. So our recommendation is, as the structured process is going through, it's doing its thing, that there are things falling out of it that satisfy these properties is just a way to think about this. Now Togaf is another one of the critical open group standards. And we know that, we believe that the business architecture standard, the OBA standard, can work in conjunction with the Togaf standard, especially in three phases. And so the preliminary phase, phase A, the architecture visioning, and phase B, which is the business architecture. And so there are many reasons why we think that this sort of collaboration, so to speak, or this sort of integrativeness is as good. So one is the enterprise continuum provides a view of how an industry architecture needs to evolve. And so we need to make sure that the business architecture evolves in alignment with that. The output of the OBA basically builds on, enhances the preliminary phase. So preliminary phase is all about why are we doing this architecture project, what are we trying to accomplish, any assumptions that might be related to that, what are some constraints. So the good piece of information that's going to drive that understanding would come from the structure process for the open business architecture group. And then the OBA standard provides a more explicit and structured way to align and integrate strategy, structure, and operations. And then lastly is that the standard, so the OBA standard applies from a content perspective, extensions to the Togaf 9 content metamodel. And so through the business architecture extensions idea mechanism that's where these additional common language and artifacts would get represented. So the business architect role engaged in all phases of transformation, ensures consistent communication. So just as Jeff was saying and as a practitioner I see all the time as being important, communication is really a key part of the enterprise architect, especially for the business architect. So by having the business architect involved with the entire transformation cycle or life cycle, we can make sure that all the stakeholders and impacted roles will understand what's coming and what the impact of that's going to be. So there are a number of trends happening in the organizations these days. There are internal, external pressures around you, all over the place. And oftentimes companies are looking at, okay maybe we need to think about doing our business, the last example I think that Jeff gave, we need to think about doing our business a little differently. Maybe take the same things we do today but maybe we need to do things differently. So i.e. this idea of a new business model. There isn't any better opportunity to leverage a business architecture practice or business architect than in this situation for which the structured approach will help describe the business architecture elements that's required for the new business model. So and with that in mind the challenge today is to capture and communicate a holistic view again from a strategy and structure and operations perspective so that that holistic view across all stakeholder groups that shows where the boundaries of the transformation lie is easy to communicate. So the mechanisms that we are proposing have that as a characteristic that should be easier to apply and that it conveys a transformation vision to make sure that what gets implemented will satisfy the enterprise organizational transformation and increasingly companies are turning to the business architecture practice to help them to systematically deal with the disruptive change and so hence the need for the the timely need of the standard to provide some guidance to companies that are doing that. And so we believe that the business architecture practice isn't just one thing it's not one size fits all sort of thing the project might vary widely so the project that or the initiative of business architecture practice might be involved and could be something like it might be a whole business strategy transformation so it might move from understanding the business and business strategy to the implications for operations it might be one or either those or both of them. It might be for a large business transformation or it might be for a small change initiative or it might be kind of an initiative idea so this kind of funky idea for a business initiative it might be helped to try to bring that to fruition or it might be deploying a target structure in operations. So from a practice perspective the message is the projects won't all look alike the initiatives you get involved in the work that you do won't all be the same type of work you need to make sure you have some flexibility in how you operate and how you assign and delegate roles to that and the OBA standard is intended to help business architects deal continuously with change and the implications, cross domain and structures and operations. So the OBA describes ways to model vertical and horizontal traceability so traceability has been an ongoing concern in the architecture community for a long time and in TOGAF and other enterprise architecture frameworks we give simple mechanisms typically matrices how to do that. So for the OBA standard provides some enhanced ways of doing vertical and horizontal traceability and why this is important is that the vertical traceability ensures transparency, enables alignment and governance so looking top to bottom wherever I sit in the organization as a stakeholder I have visibility to what the transformation is being described to do and I can feel or it can be described to what the implications might be. Horizontal traceability is critical for understanding the sort of cross domain dependencies and investments. So an enterprise transformation often has different types of implications depending on which business area I'm in and so the idea of the business architect is to be able to describe those impacts or implications across the board horizontally. So now we have understanding across the board across the departments or organizations of the impact of enterprise transformation. So the key elements of the OBA standard to assist this architect to bring value to transformations is what this is another part of the standard. And so within the standard we identify what these key elements are. So one is a holistic view of all aspects as strategic needs for transformation what is the strategic need for the transformation? What's the business structure across domain? So the transformation, what's the impact and what does the structure across from a business perspective across domain? So integrated operations so what is the integrated impact of the transformation across operations and all levels of operations? And hence horizontal and hence their vertical traceability and then the technology strategy. And that last piece is important because today business transformation or business change whatever whenever one of my clients talks to me as a business executive they want to make some change 99% of the time it's being driven or facilitated by technology. So if I have a business architecture sort of defined from a for the transformation chances are there will be a technology strategy that needs to be articulated as well which requires some collaboration across different architecture communities so that at least initially there's an initial view what these technology strategy impact and implications are. So the five ways framework is used to is to help to describe the standardized practice. So part of the standard is to describe that what a business architecture practice would be and to propose a specific way of actually pulling that off and so the five ways framework is the mechanism that's included in the standard. So the five ways include way of thinking, way of modeling, way of organizing, way of supporting, way of working and so this specific technique allows, it provides sort of as I'm trying to build the practice these five areas give me inform me how to think about the practice itself. So way of thinking is all about the mindset and how we're going to approach this and it resolves challenges of continuous change. So for these, today these transformation initiatives are becoming less and less long lived. They're short cycle transformations that we will need to do routinely. So we need to think about these from business architecture perspective and to embed flexibility within the defined structure. A way of modeling so it assures alignment and integration of strategy structure and operations. So a specific way of modeling what's required and what the implications are what the impacts are. So a specific set of artifacts that we're recommending for the business architecture practice. Way of organizing so assures the business architecture acts at the right time. So from an engagement management perspective or from a consultative perspective the business architect engaging with the business leader or the IT leader. So a specific way of organizing our thoughts and a way of supporting basically gives us a way of supporting the practice. So these might be a common language or techniques or artifacts that we might that we're proposing to support the business and enable the business architecture practice and lastly is the way of working which assures leadership and stakeholder communication. So as I'm building or as I'm describing the required transformation I'm doing that in a way that I can address each of the stakeholders wherever they sit left to right or sit top to bottom in the organization. And then lastly is three recommended views. So in the OBA standard we articulate three particular views which we think are important. Think of these views not as a single illustration but as a collection of words and illustrations let's say. So one is the strategy view the second one is the structure view and the last one is the operational context view. So the idea is that these are three recommended views that have a different context so they're actually representing the transformation from a different perspective and that they are doing they're implementing the recommendations that we talked about before so they give us a way to do vertical traces to represent and to model and to describe vertical traceability. They're actually giving us the mechanism to horizontal traceability. The dependency network diagram is one of the specific things that's recommended so now we have the understanding the dependencies across the life cycle of the transformation that we specifically articulate that. And then the common language is another piece to that where we provide a proposed set of mechanisms that are part of each one of the views and that those things are what we think the business architect should mentally consider doing. This architect may choose to add additional things to what they are articulating but from a standards perspective there's a specific set that we're recommending. So in summary the open business architecture standard is intended to describe an approach for a business architecture practice and to drive enterprise and organization transformation. Secondly part one of the standard has reached the preliminary standard stage of the open group governance standards governance cycle and parts two and three still to come will address the design, development, implementation phases of the business architecture practice. There's a particular figure in the standard where that is described along with details around the artifacts so what mechanisms and some examples of what those mechanisms would look like or should look like from a standards perspective. As with any open group standard initiative it's not any one person it's a variety of people that contribute to the variety of companies that contribute to the evolution of this standard and the business architecture standard is no different and this is representative of the different individuals and companies that are contributing greatly to this and with that I say thank you. Thank you Aaron. We'll have a few quick questions because we are running into the break but it's generated quite a few questions so maybe the ones we don't get to maybe we can cover some other way maybe afterwards but one that I thought would come up what's how is OBA positioned relative to the bizbok, the business architecture book of knowledge from the business architecture guild and how would that be communicated the second part is probably not a question for you it's more one for us but how does it relate to the bizbok? I know the bizbok standard or stuff fairly well and there isn't any specific you know integrated sort of perspective at this point however business capabilities analysis is we believe a key part of the structure aspects of the standard so the bizbok mechanisms might be a useful tool to consider using for that so I might have we might have defined in the standard a recommended business capability analysis piece but as a practitioner I may choose to use the bizbok because that aligns to either the organization but the organization has already decided or I may choose to use that for other reasons okay thank you question on analyzing markets it says the time required and the specialization for for this industry and disruptions can be daunting for an architect what is the document the OBA does it separate the process and framework from guidance and the second part is the guidance and what is the guidance and level of detail that the standard recommends for this portion of work yeah so I was so the first of all we do separate content from formats so to speak so that type of idea and at the moment the artifacts are still evolving so you'll see as a preliminary standard there's a set of artifacts which have been identified and there are examples of some of them and this area in particular I think there isn't a lot of specific or specificity right now okay so that probably not the answer you're hoping for but that's the current state design thinking is also a popular way to drive business change how do you see the relationship between design thinking and OBA or their approaches really good question and there are other like mechanisms, collaborative mechanisms out there today so as a practitioner I may choose to use a variety of ways to collaborate and engage with the business with business and IT around a particular business topic design thinking is certainly one of the popular ways to do that today so I would might engage the design thinking as a mechanism and trying to weed out from that process the things that I need as a business architect to create or to maintain the artifacts that I decided I need to create so it's a complimentary thing and I may choose to rely on that technique to get to an understanding of what the business is needing to do another question I predicted might come up but how does OBA see business architects as part of the EA group or as a separate discipline we've never talked about that before that topic comes up all the time and at the moment I don't think we have any specific guidance around that we talk about the ways that we see it happening across the organizations across the open group member organizations as well as many of us that have clients and there isn't any single trend as Jeff described earlier typically they might be reporting up to a CIO organization but more and more they're reporting to the business side the one example Jeff gave to the CFO which I think is unusual but that's very interesting but I think I'll just leave it at that I think on that point I'll say a bit more later on but we have a Togaf user group on Wednesday morning and the debate there is where does business architecture fit inside an organization very nice looking forward to that one actually slide 14 which I'm guessing from the rest of the question is the one that showed the Togaf ADM and how this relates it suggests a change to the preliminary phase A and phase B does it replace B or enhance B? yes so the current thing is it's an enhancement of phase A and phase B it's also an enhancement of the preliminary preliminary work today I'm bringing to the situation my own set of tools and mechanism a way of thinking about it as enterprise architect now I'll have a standard that I can call upon and if I engage other people in that process whether on the client side or another consulting company whatever that standard is just like Togaf has will evolve and will have consistency across what's being around the thinking and the way of articulating and describing we'll leave it there and let people go get coffee but thank you very much thank you everybody


Volleyball teams in the area can taste the state tournament, as schools are just two games away from a trip to the excel center. The section 8-8 semifinals were held at Bagley High School tonight, as a pair of 1-2 seeds squared off looking to keep their seasons alive. In the first matchup, it was top seeded Boston taking on Sacred Heart, and Sacred Heart took an early two set to lead, but in the third, the Greyhounds did not go down easy. Emma Drellick was able to spike it off the block, and that pulled Boston within three. The Greyhounds down 21-23, but Taylor Cronin comes up with a diving save, then gets the block later in the point. Boston takes the set 25-23, fourth set, Sacred Heart looking to close it out. Ivy Edwards is not messing around, giving the Eagles the early advantage. Boston trailed early in the set, and they could never recover, as Jessica Remar spike can't be returned, and Sacred Heart is going to go on to win the set 25-18. If you enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland PBS.


能夠介紹一下,歡迎請你加購特別有肯定的飯在整個加購裡面,到底它是如何配備然後接下來的話,就歡迎肯定的飯invade,給大家一個進口然後,我會談談這個零零的過程最後的話,是來自於內亞的食物我認為在肯定的飯裡,在未來的話有哪些發展的需求然後首先的話,是歡迎肯定來加購歡迎加購的話,只要給大家一鍋鍋那邊都已經對,這個加購的話,都已經進去了就是說,它會為Mask的文後的兩部分就對Mask來說除了管理等科的用期的一個控制的一個主謀化包括你所有的程庫對於APL,包括你所有的層面包括APL、Access然後,萬一你的很軟弹的運行的話就在那上面就在那上面,把這個迅音起來所以,那些的話,都在那上面而那上面,就是在那邊的話就是,三個部分,就是Corproxy就在那邊,還有一個CouplatorCouplator的話,就是負責跟API跟Couplator跟這個,在那邊進行交互上完成這個人氣還有印象的這個生命的這個管理然後,再進來的話,就是Couplator在Couplator裡面就在那邊打合所以,現在我們在上面上用的應該打合的就是Docker這個Couplator然後去管理我們的運行的運氣那麼,關於Couplator的話這裡我也能介紹一下關於Couplator的它的架構然後,Couplator的話它是經常以去包括很多的功能比如說,像我跟它說要給容器去配置速度要配置網絡,這些的話都需要配置內部的話那如果結束了模塊的視線而且一定要現在我們都會發現什麼是在視線的比如說,對於Couplator來說我們有自己的插件就現在,對往後來說我們有配合,就網絡的插件而對於Counter-on-contact的話我們這裡有的就是Counter-on-contact interface也就是,這裡有一塊它在Counter-on-contact interface就像的話,在Couplator裡面就有一個比較多的叫Inner-on-contact interface它管理所有的這個容器的一個整個機然後,它所管理的就是基於DI的一個接口去管理而在這次上的話當然還包括很多其他的功能模塊比如說,我必須要EMC最大的問題裡面去提供一些加工序的命令有時候就需要Couplator的它對外提供一個EPI這個EPI的話可以供給EPI社會來去向它進行訪問然後我能夠本身可能會提供一個問題或者說,我的課程它的資源使用比較大的例如說,來了頓高一天一個課程這個時候我就需要Election然後讓高一天你的解錄器的話用一些力量然後還有後面的一些比如說,像Couplator裡面我們也必須要去知道我的Couplator我的Counter-on-contact我的課程它們本身的一些Magic的課程Magic Data然後在下面就在下面的話EPI-Apps是一個Docker的一個容器運使然後在Docker裡面就叫Dockshame在Couplator裡面有Dockshame然後Dockshame它已經包括了去通過CNN去管理這個CNN而其他的容器運使的話實際上可以用過Dockshame的一個容器運使就利用給你這一塊就是一個比較基本的CRI-container容器比如說它通常的話會包括一部板首先是一個GIPC的一個遮耳就是GIPC遮耳就要用這個遮耳然後去玩會有容器和鏡像會有容器、鏡像還有Pod3BOX的一些管理然後鏡像的話就很難說得像NPC這種交互式的命令的話就是選擇遮耳的方式來管理然後在後面還有一塊就是你也可以用有另一個就是你的容器到底是怎麼樣去配置往後所以這個時候我們可以用這個CRI-container來我們的推薦是CNN的CNN的話你可以選擇其他的那些往後插件你也可以選擇往後的藥水然後再去然後再去讓你還需要一個可能的應用然後在這個按鍵你需要按鍵按鍵像CNN的電話或是任何東西你想選擇然後用它去處理這些視鏡以及電話OK接下來所以接下來像我剛才說的我會說CNN的一段時間Couplet所以它是CRI-container通過所以基本上這就是你把所有的模式Couplet然後還有Couplet的時間然後Couplet這是客人的時間然後Continues是所以通過IPC通過交換Continues的時間然後去處理所以我們必須對我們出現Continues的一段時間所以裡面隨便CRI但它只是用來用來如果你它不會用來用來用來用來儲存儲存儲存可以所以最有效的使用CRI是所有的CRIs in the community can be used我又沒有很想So for theWhen we know the container runtimeif we look at the CI and the interfaceit is actually a JVC based interfaceIt includes three partsOne isOne is the coupletthat will use these interfaceto manage the containers, mirrorsand the partisan boxand this is the second partit is JVC as coolSo when you have this databasewhen you have this libraryit manages interactive for directivesso you caninput this libraryinto your container runtimeso it is easily realizedand also CI toolsCRI tools is a supportive toolso when I achieve the CI runtimehow can I know that it can besimilarly connected to coupletso you can use CI toolslike CI testthis test can help youto verifyyour runtimewhether your runtime meetsdemand or notand also because we areGPRC basedinterfaceso it is actually easybecause this interfacecan generatebasic frameworkfor exampleincorporating all the communicationlogics so you just realizethe interfaceso it includes the runtime serviceto manage the runtimeand also the imageserves interfacewhich is to manage containerswhen I developmost of the runtimewill incorporate them in one programbecause for the imagemanagement and container managementthere could be some coupling partso they areincorporate in the same serverto realizein the communityso we can already seethis externalround timeI will introduce more lateron the CRIround timecontainer runtimeso actually we also haveto allocate an optionfor a coupletbecausethis externalcontainer is connectedyou have tointroduce thebut if it is running on thewindows so we support tcpand impact analyticswe support tcpwe only support unisocketand also forthe CRIs detailsso for the CRI interfacesthere are two servicesone is image serviceand runtime serviceyou have to understandit manages the mirrorsand you pull these mirrorsto local homesand make inquiriesand to look at the detailsof these mirroringsand how much, how large is the storageand when I deletethis containerI also haveto clear the mirroringsso this is easily understoodfor runtime serviceactually the CRIyou have more interfacesso you can seethere's four types of interfacesthe first is for pod send boxso for every podthe send boxisto initialize the podto support all thecontiners in the podof a shared send boxand also in campusit is a pod's containerand on top of this containeryou allocate networkand other containerswill besharing, for examplea Linux base with thispodso if you are realizingexternal container runtimeyou need toallocate the plug-inof networkand alsofor the containersmanagementso maybe I've deployed the containerand the podand then through these interfacesI cancreate or generate these containersin the send boxesandwhen you don't need these containersI can delete themof coursethere's may sometimes I have to makeaccess to these containersandwith the matrix dataof my containersthere are also these interfacesavailableand on the rightyou have three which is interactive interfacesandthese APIsareallow interactive operationandfor differentthe container runtimeand it is actually very similarso in kubernetesas you sayyou have streaming service libraryand it is easierto achieve that libraryand from CRS perspectivethis part is quite specialbecause its feedbackis urlso it is feedbackto these three interfacesso it backto the monitoring urlthe kubernetes will accessthisthe kubernetes will code this urlto finish the interactiveto finish interactiveaccessand this is theso thebasic functions like I want to accessthe type of my runtimeetc.whether it is compatiblewith my kubernetesso CRS streaming serverstream serverthe three interfacesexact attach and put forwardbecause they require interactive operationso from this illustrationyou can seewhen the userexecutesinteractiveso I will site an inquiryand this inquiry was sentto the APS serverand then based on the podit is transferred to its nodethen to its componentand this kuberneteswill inquire to your runtimeto see the monitoring addressof your monitoringand they will ask you tofeed feedback and urland thenyou can redirectthis urlto thisinquiryand then finishthe entire inquiryand actually in the newinitso it's for another typebut the downside of this typeis that the monitoringadress of thisserveris at leastit should be directly accessedby apiand for the dummy serverand api serverif you want to do interactthen you need toput some verificationit isyou still have some costto do this verificationand alsothere is also a layer of poxyhereso I do not redirectso the kuberneteswillexchangewith the streaming serverto finish the inquiryand so that meansfor the TSyou need to do by your ownrun timeand the nextis in the kubernetes codewe havewe have a libraryand if you want toyou have to referenceyou have to code this libraryto achieve these threegimi interfacesand when wetalk about thisinvolvementinvolving of containerround timeso actually at the beginningespecially before kubernetes 1.5there is no containerround interfaceor there is no CRRso it isbeautywhen this dog is a junketand these two beautycontainer runtimethey can allbecause more and more container has to customizethey aredemand for examplehaptdand alsovirtualize the container engineand alsodockersfock the issueand also redheadthey also have their container runtimeso everyone wants thatI will replacethe default dogwith my ownso I canrealize my functions fasterso from 1.5to 2.6 versionso we havecontainerwe have CRRso with that you canintroduce theexternal containersround timeinto the copyand for the rock kitfrom its startit is totally out of tradeyou have to have a rocket sheenand then the migrationof the rocketwill be in rocket sheenso there is a migration processso for theoriginal rocketwhen the external rocketsheen is readyand then you migrate directly inand then you can delete the existingin the cabinetandand because of rocketisdeletedso within kubeletyou have only one CRandthat meansCR is only supportingdockerso it turns intosomething like thisand so in the kubeletwe only have CR anddockerand when we look at the kubeletit isand also the network of pluginsit is actually part ofthe plugins and also for theexternal containerthat means you have toachieve your own containerround timeand then to manage the networkof the containerand you have to also relyon kubeletis jmyservice librarytoachieve api enquiriesstreamingand also when you have the CRI in open sourcecommunitiesyou have a lot of these different CRand all of these CRsare to solve different issuesof coursewe don't have to talk too much about the buildingdockerof course you need the containerround timeto guaranteethe function intactfulnessof the containerbut the docker provides a lot offunction which isabslit inthe containersand for example they providesome network cache but these aretotally unusedso in communities we havetwo CR is require all and require alld so these twoare supportthe OKI basedcontainer to be connectedand their parents do notacquireanymoreand it is notpart ofit is part of continuityif you have continuity you can opencontainerround timeit is only available in a new versionand also it is the same with cryoyou have a CR streamand it realizesome interfacesit islike in openshift you can see itand it also have ashining qualityit is early in a virtualized containerit support like hyperhyper and docker來完成so this is the containerround timeto work with each otherand for the containerround timeand for rocketif you have a rocketyou can see it on the outsideit is a kind of rocketwe can migrate the rocketthe battery and it will beindependentprojectand also the alibaba pouchcontainerand we canmigrateinto the alibabathrough the pouch containerby alibabawe can temporarily migratethe original alibabainto the alibabaand then you canmodify使稍微有点特殊的前面这些是像我运行的目标也说我接触了请求是一个w image最后一个的话它也是一个virtualizedvm imageand it also manages the vmit is different from the other CR不关心你的wso for the CRRit doesn'tmatter the formatof the imageor how the containermatter the imageas long as you satisfythe CRR definitionyou can achievea similar connectionwith the Kubernetesand you can use Kubernetesto manage this containerok 然后这个这里的话就有一个东西比较迷惑我们就看到we have the containercontainer runtimethe container runtimethe SCAR issueso what does thismore explainfor the bigger runtimefor example, this is the CNCF containerruntimeit goesin the wrong timeso speakingcontainer runtimewe will saythe CRRwhich means the CRRfor examplean emptyso this two hasthe CRRand they are the CRRcontainer runtimefor the otherswe can call themthe container enginefor CRRfor example, givilercada containerruntimethey all achieve the OCIso in the OCIstandard container runtimewe canuse cryoor CNCFCRR onindirectlywe can use cryoor CNCF containerindirectly they can have their ownCRR interfacein the futurewe can use cryocan use cryocan use cryocan use cryocan use cryocan use cryocan use cryocan use cryocan use cryocan use cryocan andcontainer interfacecan exportcontainer supply controlcontainer supply controlcontainer supply controlcontainer consolecontainer接受用来调弃你的定程的工具也就是说在我的教训的应用程式例如是一个Gamali Line应用程式我这条肯尔然试试的一个方法有让它有了绿色的研发的或者是用在过程的环境里面来这样在调弃的时候就带来一个麻烦临过之后面的这些肯尔然试试它的工具就这些组织,因为有些组织有不同的关系,例如关于一些困难,例如关于CRI的团体,它可以帮助你查复组织,而其他团体是在我实现的时候,我有一个问题,就是说,我没有保证我的组织的时间,它可以下降CRI,所以我们可以利用这个触碟,它的质源就是,可以把它做为一个CRI的一个工具,然后允许它需要允许CRI,而它能去重疊至于你能够进入维度中的等级程度,在未來的話,尋找很多的對肯尼人探訪的時候,還有很多的訓練例如說,在未來的時候,你未必有什麼事要做現在內置在固定,但是大部分的訓練也不一定有問題但當自己出了問題的時候如果有什麼錯的問題,就像大部分的訓練,他可能會有很多的問題所以我們就要把大部分的訓練留下來當他看來之後,這個發布的話就會看到很多這一段,其實在實習裡面,尋找很多的對肯尼人探訪的時候順出的實習的參與才能完成然後還有另外一個就是關於強格烈的容器以前就是剛才提到說,我的外部的容器以前可能除了有像裝飾音響、高科的機器人,還有像卡拉普林的補隔的機掰式然後這些容器的話,全格烈的功能可以把你的容器通過虛擬化的方式使用如果全格烈的容器有錯的話,就帶來一個問題就是說,我的一些化的容器如果這些容器不可以支撐一些容器一個烘焦電腦的容器,這個基本上是我們想要做到的所以就需要在層面燈灯的上面,可能就需要一些烘焦電池它在設計裡面有一個烘焦電池的容器最後的話,就是我們現在雖然說給人家會提供了買烘焦的功能但是我的烘焦電池在實習那時候所以最終你過來的時候,需要你去找或者進行裡面到底有哪些接電的容量是什麼對於烘焦電池的功能還是需要就是需要關於底下的資源需要關於底下的功能所以後面我覺得有一個趣事就是有可能說我們的特別是我們的民族特別是我們提供了這種特別的或者特別的體驗的容量比如說像不少烘焦電池就是這麼一個一個烘焦電池所以你的機器來的時候你就辦的這些服務的話做一個進行的進行就是無限資源的弄的放在你的開發機器裡面來密集現在的話你就不需要去服務了然後以上的話就是我今天要介紹的一些別的那種然後後面還有三張對的你要使用不知道處理的然後後面它需要一個設立的進行牌對,那個進行就是一個進行的進行就是一個無限 node你看到它想說就是叫什麼Node1,Node2Node3,Node5Node will become a virtual nodelike node1,Node2對,但是你看這個Node5的它的資源表明Node5So the CPU or memory of this virtual nodeare much larger than the previous nodes是的然後如果你用Area可能reinvent的話實際上你可以支持運營各種不同的應用比如說你可能藉由Linux的應用藉由Windows的應用So for if you useArea container extensionand you can set updifferent applicationlike Linux or Windows這個實際上是它們連著功能負責的就是說從那個複製的人角度來說它需要去管理每一個parts的資源然後它可以除了管理之外它們可以你需要從那個d.grpnd.grpnd.grpn它們可以讓它們來做d.grpn它們可以來做d.grpn它們可以來做d.grpn它們可以來做d.grpn它們可以加入到d.grpn裡面d.grpn在d.grpn所以 in thisgrpnd.grpn有一個三個叫PythonocentPythonocent就是你把你的化粒裡面多了個代子應該放到哪一個這個熱的下面去然後你的所有管理之外都應該在d.grpn附近的外面那一段就在So during the practical productioncriit cannot satisfy our directory notso when we use thiswe have toinhouse the criwhat kind of enhancement we have down to the crifor examplewe use the newpouch or dockerwe have our ownfeatures recordedfor example resource limitationso we have todo the extensible on this criso I don't knowif there is any better wayto address this kind of issue有一個方式就是一個的話就是如果你有新的features你覺得you have no questionif the existing crican satisfyyour demandyou can raise thatquestions or raiseyour blackproblemsin the communityor in the geek huband then you canplace a common requirementand maybewe will alsohave ourmultipleadjust the situationor if you havea specialspecial demandwe can useyou can defineyour special matrixwith a differentround type of fluxso you need somecustomizedround type of fluxactuallywe mightwe mightwe mightwe mightwe mightwe mightwe mightwe need to modifyyou can raiseyourperimentalin the communitybecause it dependson the specific scenarioswe can havethe discussionin the communityfor some CRIadjudicationthe service fabricMicrosoft,I think it is similar to the K8SAnd also,Microsoft has also done the K8SLokong 9 deploy this K8S on our machineOr I have to use the Azure App for Service FabricIt has a lot of practice inside the MicrosoftBut for the state's role time management is kind of troublesomeSo no matter you use the service fabric or KubernetesIn the future,we will support bothAnd for the container ecosystem,I think Kubernetes maybe has better environment for the server


Republicans want flat sales tax. Some conservatives advocate for a national sales tax to replace the internal revenue service. Yet, the Brookings Institution has found that the sales tax at the proposed rate will increase the budget deficit. The bill's primary sponsor, Representative Buddy Carter, argued that the United States does not have an income problem, it has a spending problem.


Welcome to All Hands Update, I'm Petty Officer Tony Rosa with your headlines from the fleet. Chief of Naval Operations Admiral Jonathan Greenert released the Navy's new navigation plan for 2014 through 2018. The plan spells out the way forward for organizing training and equipping the fleet for the next five years. The plan also addresses budget issues including continuing resolutions and sequestration. Lastly, the plan focuses on the importance of sailors and civilians being prepared, confident and proficient in meeting the challenges of tomorrow. To read the full navigation plan, go to navy.mil slash cno. Secretary of the Navy Ray Mabus named the Navy's newest littoral combat ship USS Indianapolis August 16th. Designated as LCS-17, it is the fourth ship to be named Indianapolis. Construction is subject to congressional approval of fiscal year 2014 funding. You can read more about these stories at navy.mil. From All Hands Update, thanks for watching.


Welcome to All Hands Update. I'm Petty Officer Andrew Johnson. The Navy's Office of Women's Policy is accepting nominations for the 2015 Captain Joy Bright Hancock and Master Chief Anna Der Vartanian Leadership Awards. As the Navy continues its commitment to diversity, leaders ranging from junior sailors to senior officers are recognized for their talents. These annual awards recognize and honor the inspirational and visionary leadership of those sailors whose dedication reinforce and further the integration of women into the Navy. Nominees should be mature leaders who have demonstrated leadership both on and off duty and have overcome challenges while serving. Applications are available from the Navy Personnel Command website. All applications are due by January 16th.