 I would like to invite Will Estham, who will be presenting on the topic Enhancing Enterprise Agility using the TOGAP and IDCROID standards. Welcome Will. Will Estham is the President of Metaplexity Associates. He is actively involved in the development of TOGAP and our idea and has extensive training and consulting experience in enterprise architecture and TOGAP. He is the past chair of the Open Group Architecture Forum and is the chairman of modeling and terminology committee in the fall. He has also served a two-year term on the Open Groups governing board. Over to you Will. Thank you. I'll speak to you back. Yeah, I came here actually to Hyderabad a year ago and did a presentation that was very similar to this one. But at that time it was kind of a prototype. Since then I've been joined by three other people. So myself, but also Michael Fulton, Michael Fulton, some of you may know him. He has just previously been working with CCNC Solutions and just last week he started a new job in enterprise architect over at Nationwide Insurance, which has come back in his home town in Cincinnati, Ohio. And then also Sylvain Marie from Paris Floor from Paris Friends and Lucas Rizinski from the Architecture Center Limited which is located in England but they're actually a group of people that came from Poland originally. So right now we are all working together on a white paper that really talks about this subject in more detail. So I'm going to be giving you pretty much just some of the highlights of the things that we've been doing from the past a year as we work on this white paper. So before I got started with this project I was the chairman of another project of the open group that's called Project Harmony and we just finished a presentation talking about Archimade. So when Archimade came out it really was developed by a group of architects in the Netherlands and Archimade was not designed to be like totally compatible with Toga it was a separate product that's had its own development stream it's own intellectual property. So on the two standards down into the market to the other people were trying to use them and they were finding that there were some places where there was disconnects and so we said we need to figure out a way to harmonize Toga and Archimade. And so myself, I remember three or four other people we basically worked for about almost two years and came up with some very detailed analyses of the differences between Archimade and Toga and then recommendations for how you can overcome some of those challenges. So that's Project Harmony and so this week we're going to be talking here about kind of the differences between and the similarities between Toga and IT for IT. So let me go ahead and start here. So this page has a lot of text here you don't have to read it. It's just talking about the white paper that they're working on. So I just basically told you what I didn't even know. So we're going to start by just reviewing Toga. I've seen the elements of Toga up on the screen several times today so I'll be brief. And then I'm going to introduce IT for IT and that is probably something that's a little bit less well known to you so I'll dig in there. But then I'm going to look at the touch points between the two. So what are the similarities, what are the differences that we see between Toga and IT for IT. And then how can we use them together to transform an enterprise's business capabilities, improve agility and we'll talk about the kind of how can we get architecture to work better with communities that are practicing agile methods and DevOps and continuous development. Some of these kind of modern day development methodologies. You know I mean this has always been going on. I remember about ten years ago everybody was head over heels about extreme programming. So we do have some fads that we go through. I'm a strong believer in the gardener hype curve and so not everything is going to survive on the market extreme programming didn't. Although there might still be some people that are doing it for special projects where they need a user interface design or something like that. But that's great. But for most people other methods are okay. You know today it seems to be invoked to criticize waterfall models. And well I think when you're developing large scale systems waterfalls are actually what you really need. Some of the stuff you're trying to do as scrums are more like user focused kind of thing. How do we build applications for people? But when you're building back end systems sometimes you really need to be very methodological about your approach. So these are all trends and things that are going on inside of our industry and they affect how we go about delivering value to the enterprise. So let's just go ahead and take a quick look at TOGAF. So again the open group architecture framework was the original meaning today it's just TOGAF. Today it's just a brand name. It's trademarked by the open group. And it's a framework for doing architecture especially enterprise architecture and really helps us to focus on developing architectures that are based on standards as much as possible. You know some companies care about standards. Other companies are less concerned about standards. And I think even they should be thinking about consequences of not really watching out for standards and the impact they have for you. So I'm hoping to get you to be able to build architectures that are more interoperable so your systems can talk to each other. And today with a lot of computing and things like that portability is becoming more and more of a customer issue. So this is my adaptation of figure number one from TOGAF. I just took out a lot of text that was too small for you to read. But what it's really showing on the left hand side of the screen you see business, vision, drivers, basically strategic intent. And on the right hand side you see something called business capabilities. So TOGAF 9, one of its hallmarks is this introduction to this idea of capability-based planning especially focused on business capabilities. So basically the idea is that as we go through the TOGAF method we're going to basically identify strategic needs and then try and figure out capabilities that will address those needs. And as we address those capabilities that will expose new opportunities for new strategic capabilities. So it's kind of a positive feedback move. And the colored boxes you see in the middle are the major elements. There's six major parts of TOGAF. So you've got the architecture capability. This is where we manage and govern it. We've got the ADM, the crop circle diagram that everybody talks about, the development method. And then we've got the architecture content framework and the enterprise architecture repository and the enterprise continuum. And then finally we have a set of reference models which are there for you to use if you wish. And then as you go through the TOGAF framework up at the very top there you see this one third that is the capability framework. And the middle tier is essentially the ADM and the content framework. And then the bottom is the repository and the enterprise continuum. So that's actually figure number one in TOGAF in the conceptual model. So what we're trying to do here with TOGAF is figure out how can we build capabilities that meet needs and there were several speakers today that talked about this. So a capability could be something like delivering products to customers on time or making sure that you can track shipments and things like that. In order to achieve that kind of capability you might have to take an incremental approach so we talk about capability increments. A little bit like transition architectures. And then we also talk about capability dimensions. So we can talk about the people, the process, the technology dimensions. And so what we have to do to get our people ready to perform how we design a business process that works and finally what are the technology capabilities that we need to provide. So basically this is my illustration. This isn't in TOGAF. This is kind of like my TOGAF game board at TML. So the game of TOGAF is played by looking at all four of the domains of the top there, business, information, actually data, applications and technology. The middle two, the data and applications are actually clustered together into what's called the information systems architecture. So we look at each of those domains. We basically perform this middle level thing here. We look at, for each of the domains we look at the current state, the target state, and then the gap that exists between them. So what have I got to do to close that gap? Usually the gap in the enterprise architecture is significant enough that you're not going to be able to close it in one jump. So we build in these transition architectures that incrementally help us move towards the target state. The blue arrows that you see around the target state represent the impact of the targets. If we actually build this thing, what is the impact going to be? And finally down at the very bottom, everything in TOGAF framework in the ADM is driven by requirements and constraints. So there's our beloved crop circle diagram. And you'll see me going through the ADM so if you're not familiar with it already, as I get further into this discussion, you'll see me breaking the ADM down and explaining different parts and how they work with IT for IT. So basically the top circle is where we start up an enterprise architecture practice. It's the preliminary phase. And then once we complete that activity, then we can begin actually doing ADM cycles as projects, if you will. And those projects basically create a vision. They then flesh that vision out into an architecture description. And then they basically derive a solution architecture. And then they build a solution. And so that's the basic process. And you notice in the very middle there you've got requirements management, which is driving the whole process. So then we talk about this architecture capability. And it's a little bit hard to read, but on the left-hand side, we've got the architecture staff. In the middle, we've got the project management and the implementation teams who are working on architecture contracts to develop something for us. And on the right-hand side, you've got basically your operations people. And so this is kind of a flow of things, although we'd like to see this actually recirculating so that the operations people can talk to the architects. And then you'll notice at the very top there, the whole thing is governed by a network of governance structures like IT governance, architecture governance, in some cases even corporate governance. So then we have the enterprise repository. Again, you may not have a repository like this. I heard somebody asking a question earlier today about where we store all of our Archimage files. Well, in TOGAP, we have this thing that was recommended to basically provide a container where you can store and organize your content. I'm not going to go into a big, long explanation of this, but it basically has a place called Landscape. And in Landscape, it contains your architecture building blocks that they use, and they're stored at different levels of detail, starting at a strategic level, going down to segment levels, and then finally getting to basically capability architectures. So, and then there's also in the outer part of the gray box, you'll see a requirements repository and something that they call the solutions repository, which actually can be open to a variety of different things like maybe a CMDB configuration management database or something like that. We're actually storing operational system descriptions and things like that. And then there's this strange thing called the enterprise continuum, which befodils a lot of people that don't really understand what exactly this enterprise continuum is. Prior to TOGAP 9, the enterprise continuum was actually the recommendation for the architecture repository. So it was the place where we stored our content. And the reason they call it continuum is you kind of view the building blocks that you put into that continuum on this kind of a number line that goes from the left-hand side, which is where you have very generic building blocks towards the right-hand side where you get increasingly more specific. So you finally get to the point when you get all the way to the right-hand side there where you have a specific architecture and then you get down to the green box there and the solutions continue. You pretty much do the same thing. You might start out with a generic piece of software, for example, SAP or something like that, but then you tailor it and configure it until you finally get to the exact solution that the customer wants. So that's basically the flow. And then we have something called deployed solutions about the bottom. And that would be the stuff that's actually operational on the enterprise right now. So that's the enterprise continuum. So that's a review of the FOGAP standard. Let's go ahead now and take a look at this IT for IT. It's kind of the new kid on the block. It's a very exciting framework. And how many people have seen this picture? How many people have not seen this picture? Let me see that. So there's a few people out there. So some of you may remember Michael Porter's famous book about competition. And he talked in that book about value chains. So this is not exactly Michael Porter's version of a value chain. He had something quite different. This is an IT value chain. But it's kind of showing you the same things. The goal here is to provide IT services to meet the needs of the business. And so we talk about having efficiency and agility as kind of the goals here. And along the way, on the top of this model you see the four blue herringbone wedges there. Those are basically the value streams and you have plan, bill, deliver, run, roughly. So that's sort of like the Deming Cycle. And then underneath that you see some supporting resources. And these are still being defined as they go through the next version of IT for IT. But the top part is pretty well fleshed out right now and that's what we're going to focus on today. But I'm kind of excited to see what happens in the next version when they start fleshing out some of the stuff that's in the lower part as well. These things are not just built all at once. So as we go through, we basically have a service life cycle. So we're trying to provide services to the enterprise. So we start out with strategy to portfolio. That's the plan thing that we were looking at just a minute ago. And so strategy to portfolio is really where we start looking at what is it we're trying to do, that strategic intent that I talked about. And we start figuring out how to map that into an architecture. And so then as we do that, we basically come up with what is it we're going to do, strategy. Then we start moving into requirement to deploy. And this is where we start to think about well if I'm going to build this thing for the strategy, what have I got to do to fulfill that? So what's the requirement to deploy? And then once we get the system up and running, it moves into request to fulfill. And that's where the system is actually operating. And so the customer says I need 10,000 light bulb or something like that. And we fulfill their order and ship it to them. And that's how it goes. And finally, excuse me, I skipped one there. At the very end, we have a thing called the tactic correct. So that's where we look for problems that might be happening and try and put it into an adaptive feedback loop so we can correct the issues, things like that. And so as we move along this process for successively refining it, I don't like the enterprise to continue kind of doing that same thing, except this is more about operational system. This is not about architecture. So now this one I don't expect you to be able to read. It's a very detailed model and it basically is what we call a level one reference architecture. And it's got the misspelling in there. It says ITI or IT. You've got to get that out there. But if you look carefully, let me see here if I can point to things. The left-hand side, the first problem is essentially strategy portfolio. So that's all the strategic planning stuff. The next two columns are requirements to deploy. And pretty much the next three columns are requested to fulfill. And then finally the last two columns are detected correctly. So that's level one. The IT for IT standard right now defines a total of five different levels and they get more detail as you go down. But they only publicly show you the top three levels. The bottom two levels are reserved for particular vendors to do like for example maybe BMC might do the way that they do service management differently from Hewlett-Acker or something like that. So each vendor can kind of define the internals of their solutions using levels four and five. So they don't talk about that specifically in the standard. Here's another way of looking at things. This is the service model. And basically as we basically provide services to the customer to address issues, we can start out looking at kind of the conceptual level where we can look at continuous assessments or kind of constantly looking for things to be fixed. And then continuous integration for the logical level and continuous delivery for the actual solution that you're actually building. So that's just kind of talking about how we can go about delivering services to customers. So the question becomes can and should IT for IT be used together? And I think there's a bunch of different attitudes and beliefs about that. I think some people in the IT for IT community are operation managers people and they don't understand why the architects would want to have anything to do with this. And there's architects out there that say, well, I don't want to give my hands to an operation manager. So I think we've got some polarization along the way. But I think a lot of people realize that these two things actually can work together very well. And that's what we'll spend the rest of the presentation here. So when we try to do harmonization activities, the goal is not to join IT for IT and TOGAF together so that they're inseparable. We want to keep those independent standards, but we want to try and identify what are the ways that we can use them together. What are the exceptions? There might be some areas where you really shouldn't try and mix them together. So that's what this white paper working on is going to be producing. So we'll just give you a few ideas here. They are very complementary in many respects. There are areas where there are differences, and we'll talk about that. But there are significant benefits that could accrue from getting them to work together. So let's just take a look at this. So what are the touch points? So, you know, when we did the project harmony stuff with Archimage, I remember one of my colleagues, Sonia Gonzalez, who's now the chairman of the director of the architecture forum, she kept saying, Bill, TOGAF is a framework, and Archimage is a modeling language. So there are differences there. She repeatedly brought that up, which is pretty obvious. But TOGAF is an architecture framework. IT for IT is best referred to as a reference architecture for the IT function. Okay? So where TOGAF is very general, IT for IT is more specifically focused on a particular thing. The scope of IT for IT is the business of IT. And it's basically providing you an operating model based on those value streams that I just talked about. And then defining information systems architectures that enable the interoperability across the business. So, you know, just imagine if you could get detected correct to be able to, you know, communicate back to the people that are working in the requirements area, things like that. So, basically, communication picks up sooner. TOGAF, on the other hand, is an architecture framework. The scope of TOGAF is really enterprise-wide and in some cases beyond. And it looks at those four domains, business, information, applications, technology, and trying to define the business capabilities. So basically, conceptual models, they do have different conceptual models that show that about it. There are definitely some differences you know, TOGAF talks about, for example, actors, organizations, services, talks about functions and processes, it talks about data objects, it talks about application objects and platform services, and things like that. So those are the kind of entities that TOGAF is accustomed to modeling, whereas IT for IT is a much more specific set of entities that we'll look at later on through here. So this is a thing that is called the MetaModel. This is a subject of great debate and discussion within the architecture forum. We are trying to re-engineer this from the next bird to the TOGAF and we have really been coming up with a lot of different permutations to the model. But this one's a nice, great starting point and it just shows you the entities and relationships to each other. For example, actors are allowed to be part of an organization and organizations are allowed to have functions and processes. So as long as there's a line that connects these different entities together then that's a legal relationship that can exist. So I don't want to get lost in the MetaModel right now I could do a whole hour on the MetaModel and that's not what we're here to talk about today. Let me hear we see the reference models for IT for IT and again like I mentioned Level 1, 2 and 3 the standard explicitly talks about what's in each of those levels but once you get below Level 3 it's reserved for the vendors to do their humanities. So how do we use TOGAF and IT to transform business capabilities? So here's the crop circle diagram preliminary phase of the very top layer that's just setting up the architecture we get to that next level down at the top circle in the crop circle diagram it says A, architecture vision that's the normal starting point for an architecture project and the goal there is to come up with a high level architecture vision for something we're trying to do maybe we're trying to build an ERP system that can basically manufacture widgets and keep track of hours for workers in a factory so we might start out with that vision of Level 1 and then we can go into phases B, C and D and we can define the architectures, the actual high level architectures for that so we might say that we need some more ERP system and we might say that we need a module that can keep track of time or we need another module that can do economic order quantity calculations and things like that so we can build the different elements that need to be put in notice here I'm not really talking about a product like SAP or Oracle or something like that I'm just talking about the functional needs that we have so typically phases B, C and D we try and operate at a logical level stay away from vendor products nothing wrong with vendor products it's just that at this point in the game we're trying to strip away that marketing and focus on what we actually need what are the requirements that we have and then we get down to the very bottom and we get to phases E and F and that's where we bring the vendors in and say ok here's what we've identified as our needs and then what is the what is the products that we need the vendor products that will fulfill or what are the stuff that we might build we might actually develop our own solutions or integrate existing solutions so those are all things that we can do and and then as we move up there by the time we get to phase G we take the architecture the solution architecture that we've identified and we basically give it to the implementation organization, the development team and they go off and develop it on their own and this could be where the agile work begins although the agile people would say hey we want to be more involved in the very front of this activity and I don't blame them but let's just say that the agile people would take over and finish whatever was started early and but then they will go ahead and actually build something that will solve the architecture and then it rolls through the QA and test and rolls into production and that's when it enters phase H when the architecture actually rolls into production we put it under change control on phase H and observe the architecture as it operates to make sure that it's fit for purpose and if it is, we say that's great, we're done if it isn't and then it needs to be adjusted we can do various things to adjust the architecture so those are all the kind of things that we do in TOGAP and if you look at the balloons that are on the outside there you can see how they've labeled those things using IT for IT terminology and so we're going to see more slides like this so I'm not going to dwell on this one here's another picture of the same thing we see the ADM and as we go through the first three phases we're basically dealing with the business services and then as we get into the third phase, information systems architecture, we're dealing with IT services that need to be provided and then phase D kind of focuses on infrastructure services then we get into phases E and F we're doing the solution roadmap and the implementation migration strategy and then by the time we get into phase F we're starting to package things up into projects that can be implemented using work packages and delivery vehicles and then basically phase G when you turn it over to the development organization so that's one possible way of doing this the other thing that's important to realize is this is showing TOGAP is kind of a deterministic waterfall and it's really not you can certainly do it as a deterministic waterfall if that's appropriate but you can also especially in TOGAP 9 you have the ability to iterate and do things in different sequences there's no problem with that so you can do for example phase B and phase C simultaneously if you wanted to things like that with all kinds of tricks that you can use to speed up development to get to the answers better and here they're looking at the value screen so again on the left or the right hand side you see strategy to portfolio and that definitely is a place where the right hand side of the crop circle diagram fits and then you look at requirements to deploy that's your solution architecture request to fulfill where you're actually building it and operating it and then you put another change in control for detector app so it's not a perfect mapping there but it's not bad and here you see some more of the stuff over there the very top there you see that red box that's highlighted in strategy to portfolio the very top box there is called the enterprise architecture component and so the IT for IT group when they were developing standard they really thought that enterprise architecture should be prominently featured and so it's right there at the very top of strategy to portfolio but I hope you've seen as I've gone through this today that there's other touch points to the ADM and to TOGA so it's not only that architecture component yeah so here's the IT for IT perspective when you talk to some of the people in that group this is kind of their major thing that they want to see TOGA helping with that enterprise architecture component but I think we've seen that there certainly are some other things that we need to be we need to get some things from the IT for IT people to see the stuff that we're trying to do as well so this is kind of a concept that I'd like to leave you with last year I had a word up on here an indie that said Armini and that seemed to get a lot of cheers from the audience what I'm proposing here I mean everybody today is talking about DevOps DevOps and continuous delivery continuous integration and hedge off but I think you have to really have somebody who's watching the bigger picture and so I think this is where the enterprise architects can really earn their feet and so I'd like to see a way to make architecture and the development people and the operation people work together that's really the big idea here and yeah there it is okay so Armini I think we can make that happen so there was somebody who showed this slide earlier today it's a little different configuration but I really like this slide and this is out of Toga I've kind of embellished it a little bit so on the left hand side there you see strategic planning and there we have so this might be executives of the company other strategic planning people and they might be the ones that actually identify the capabilities and they might be the ones that break down the increments and things like that and the architects will take over and they might do more of that capability planning more of the building block design and things like that and then it gets handed and this is all very sequential doesn't have to be that way the development team gets involved and then ultimately the operations people so I came from manufacturing and you know back in the old days in the 1970s when they designed automobiles it would take them seven years to work an automobile from the walk and then I'm rolling out the door and they did a thing called concurrent engineering where they started having the manufacturing the design engineers and the service engineers working together throughout the whole process and they've driven the cycle time down to a year or two now for developing a new automobile so I think we have the same kind of opportunity here if we can get the planners and the developers and the operations people to talk to each other in a similar way so that's it that's toy out an IT to transform the IT capability and after there's illustrating some other things here from that figure number one toy out I really already said that here's the enterprise continuum again as we move from left to right at the top there you see what we call building blocks the architecture building blocks starting out a very high level reference model working all the way down to specific architectures but again these are vendor neutral logical building blocks and then the lower level is the solutions continuum where we start out with maybe generic product descriptions or things that we need to build and then we work that through the process until we wind up with a specific architecture that can be built and then here we're just showing you some of the some of the goodies in the repository and how they could be used by the IT for IT community and again here they're using the ADM to implement IT for IT and again we've already really covered a lot of this stuff already so I'm not going to go through it again so that's it I guess I kind of messed up there can you bring up my summary yeah so just to sum up here the toy out is a standard for doing architecture IT for IT is a reference architecture that really helps us to design the business of IT so how do we properly execute IT that supports the business needs so the two standards have many of the same goals but different ways of doing things and I believe and we'll be working hard to finish up this white paper that the two can be used together and if they do then I think it will be a beneficial thing to the enterprise so ensuring that the toy out for IT IT for IT standard are properly harmonized will make each of them more valuable to the organization's employment that's why I'm talking and I'm glad to take questions