 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