 Well, John, welcome to the overgroup. It's great to have you here. It's been a while since we've been on the same bill I saw you speaking New York 15 years ago. It was very entertaining How, when did you start? Well, I probably drew the original Graphics around 1980. It was published internally. I've worked for IBM for a lot of years, but it was internally about 1984 in the system journal in 1987, but I probably sketched it out in 1981 And it's sustained all this time? Well, actually, my framework hasn't changed, you know, it's deriving from classification and structures that humanity had used for thousands of years You know, it comes back to the linguistics structure. You want a complete description of something? You have to answer six questions and that hasn't changed for seven thousand years The other dimension, I didn't realize the theoretical base for it. I saw kind of empirically what it was about It comes from reification from one of the philosophy domain where an idea you have is one thing, but the instantiation of that idea is a completely different thing So you have to take the idea and transform it into a series of well-known transformations into the instantiation The classification, the schema has been there forever. My framework has been there forever I just happen to see the pattern. I appreciate people put my name on it The structural pattern for descriptive representations has been the same for a thousand years Well, I can remember when we started looking at architecture, enterprise architecture It was our customers, people like the CCTA, Central Communications, Cellular Communications Agency in the UK The NHS, the Lloyds Bank, those were the organizations that came along and demanded We need standards for how to do architecture In our industry, in our standards industry, people couldn't understand how you could have standards for architecture Because they were non-normative, you know, it was guidance So we've come a long way because the standards industry now recognizes that those types of standards are critical Really critical So you're teaching TOGAP and is that in front of you? Right, I own FIAC now, which I'm sure many of you might be from nearest We teach the federal standards, which is the Federal Enterprise Architecture Framework Also, DODAF, the Department of Defense, and also TOGAP as well Plus, the folks who started FIAC wanted to retire I taught there since the beginning, so they made it easy for me to acquire So we still teach those things, plus we teach the ZAC and the framework Now it becomes really much more practical to us to be more definitive about the integration of those concepts So that's why we're here talking I don't even know who precipitated our meeting here, Alan, whether it was you or me or both of us or whatever But this really is a profoundly significant thing And I think this may be a milestone from an industry standpoint Because I remember one time you introduced me to a TOGAP conference in Johannesburg And without any discussion or prompting from me, you basically made the observation For a lot of years you thought it was either TOGAP or ZAC And in introduction you said it's not TOGAP or ZAC, it's TOGAP and ZAC And that's the point I've always seen them as complementing each other I like the six headings across the top And I like that way of thinking But obviously populating that is a challenge Yeah, Alan, that's right So when I saw you 15 years ago in New York you said that some organizations could fill in the top bit And as it got further down it got tough Have you seen organizations fill in the complete framework? Well, one thing is you don't necessarily populate the complete framework This is my framework, I use the metaphor, a lot of times a periodic table You don't have to have all the elements actually to create what other compounds you need So you may or may not populate the entire framework I would argue in enterprises you probably do want to populate the entire framework at some point Because you have to, you know, the enterprises of the future Today and beyond, I make the case that the game was changed here We're moving farther into the information age And the characteristics we know about is extreme complexity, extreme change So if you want to deal with complexity and change You'll have some classification for complexity and change You have to retain the descriptive representations based on your chain So someday every enterprise probably got to wish they had all the descriptive representations You don't necessarily need it initially So the other thing is, those of us who come from the information community We tend to operate at the bottom actually We have a lot of formalism set where some of the lower rows of my structure And we're beginning to get more sensitive I think that was a pretty innovative thing that Tokyo dealt with to begin with To raise the level of visibility for the enterprise I thought that was really significant And how do you react to the sort of growth of agile DevOps? Well, one thing is, I normally, when people ask me about this There's something good about everything But no, one thing does everything, okay So you have to know what's good and what's not so good So agile is a programming process It's a project management kind of a device But in order to build and run things You need to decompose them down into smaller pieces Because the smaller the piece, the faster and cheaper it is to manufacture But at the same time, if you decompose things You basically, it's a function of analysis that decompose it But all those things have to fit together So you have to deal with this issue of synthesis as well Because if the pieces don't fit together, all you have is a lot of pieces So for agile, it's really good if you're trying to get the code to run If you're breaking down smaller pieces of code to run Which is really good, it's running On the other hand, if you don't have some kind of architectural construct Which defines how the pieces integrate You're going to end up with a lot of code Which is not too different from what we have today We have lots of code, it's not integrated, not flexible, not interoperable Not reusable, not aligned and so on So those are engineering characteristics So somebody has to do some engineering first And then you reuse the primitive components In the agile implementations And in that fashion, what would happen is you would get the implementation You'd get the thing running, but they would be architected as well as running You don't have any architecture, it's running But it's not architected So you need to have both So it's not either or to add issues Yeah, I'd certainly subscribe to that as you know Every now and again you come across people that say Oh, we don't need enterprise architecture, we're doing agile And you say, you know, there's going to be a trainer example Yeah, right, exactly So you're going to move along that But what I've been trying to get, certainly with our internal development And activity, is that the enterprise architecture is More visible on a two week cycle So you can produce things on a two week cycle That show what's happening with the enterprise architecture So it's not one of these things that's going on under the surface And then when you're doing rapid development and deployment It's actually in lock state with the architecture Yeah, this is a really important point, I think One thing is I'm not, you know, the time frame Once we begin to build some inventory of the architectural constructs That I think we can reduce the time to market for implementation Down the very short periods of time In fact, this idea has been around the IT community since the very beginning I don't hear people talk about it But it's late binding, you want to keep everything separate Until the point of time you click the mouse That's when you hard bind things together That's the implementation And if you want to reduce the time to market That presumes that you have something in inventory What you have in inventory has to be engineered to be assembled Into more than one thing With a manufacturer called mass customization So you're absolutely right Now here's my little twist on that issue In the short term I am changing my perception here And I had some experiences here lately And I don't know that this is going to take time to work through this In any detail But I think what we have to do is We have to change the whole process of enterprise architecture It's not one of IT building models It's one of solving general management problems If you can solve the general management problem There's no shortage of problems If you can solve the general management problem In some period of time A month or two months or a week or two weeks Whatever the time period is If you can solve that problem The resource and the cost and time issue Tends to go away Because if you can solve the general management problem Say hey that was really good I got another problem by the way So if we can just do this We can get to build the architectural constructs Internally and permanently Little by little by little Problem by problem by problem In some period of time We're building up the inventory Of what I call primitive components Problem solutions So that's my affirmation And I feel pretty strongly about this Those of us who care about the subject And there's not I don't know whether I should say this or not I'm probably going to regret this But there's not too many people Who are thinking about this There's a handful of us who care Those of us who care Really need to change the perception We're going to start solving General management problems That will bias the time and resource To build up the architectural constructs There was nothing ever about Exactly from the autograph That said that it wasn't going to do General management problems I think the top row Is identifying those people And so we've never had that But all of a sudden We're seeing a lot of people That are very keen on These things coming out around And it's not anything new As far as I can see It's the things we've been doing for a while But it's just been given The sort of feeling That it's all about IT We're going to have two factors About the enterprise architecture That's really a good observation I've been with A lot of the business Architectural folks And a lot of them Come from the IT domain And it's interesting They change their attitude They get disdainful about IT It's about a work business When I hear a work business in your IT Or IT in your business That is not a good idea That is divisive That's exactly what you don't want to have happen When I talk to the business architecture folks They tend to be having Very passionate discussions But they don't define business architecture The same way Because of my framework I can identify 176 plausible definitions For business architecture And I basically say Until you can get definitive About which one you're talking about You may be talking about One of those definitions Whoever's listening to you Can be hearing any other of the 175 So this is another one Of those subjects That is like a silver bullet Wait a minute There's nothing magic going on here I would just send a presentation A few minutes ago When they were talking about Cable Miller What does that mean How many different definitions are there If you don't define it precisely Then you can be talking about One thing And anybody who's listening Can be hearing some But that's the idea And there is a community of folks Who are talking about business Architecture these days But once again They're not being very precise About the discussion But there's definitely a need Yeah, I know These are really critical The problem is I argue the case You've got to start working On these kinds of things But you don't learn how to do this In a day Like golf The first time you go out and play You've got to play for a lifetime Before you get good at it But when the enterprise wakes up Someday And they're in extremists Because they can't accommodate The demands from external environment The game is over Unless they have been Working on this So they have some understanding What it is And probably have some A lot of enterprises Forgive me For elaborating this But a lot of enterprises Have been going out of business For the last few years Small ones go out The big ones go out And it's not only the private sector The public sector So nobody is exempt from this And I'm going to say If you don't forget to deal With these architectural issues That's a high-risk position Yeah So coming back to Togaf Where do you see the synergies Well, one thing is My framework I define a single variable What I call primitive components Actually Togaf Defines some artifacts That are created for practical use I would call it composite structure In some cases Maybe primitive Or Implementation composite in nature And this is to be expected Because the reality The world is full of compounds Composites We don't see the elements In the tangible things We don't see the elements We see the compounds So my framework is just Classifying the elements If you use the chemistry metaphor You're using the elements To create the compounds That's what you want to do So that's where the integration point takes place So I would just say Whenever I'm talking with anyone I'd say on the next iteration There's going to be another iteration So I would just say The next iteration You need to start searching For the primitive components And I pretty well Based upon the classification structure That humanity has used for thousands of years I think we know precisely The primitive has become the reusable building blocks And I know that's a term It's used in TOGA The primitive has become the building blocks And that's where you want to create The composite implementations From the primitive components That's the way I have a friend that will be with me this week And he talks about using My framework is kind of a rosetta stone If you have to translate Between TOGAF and XYZF You know the primitive Turns out to be the common Common point So that's probably Some people Because of I mean when you look at the history We've got about 70 years or so In the information domain We haven't Recognized the practicality Of the elementary or primitive components That have been perceived to be A theoretical structure And actually My argument is This is not theoretical It's very practical So I think that's where we need to move There's a lot of room for creativity A lot of room for innovation A lot of room for specialization As well for that matter So I think that I'm excited about These are good times Those primitives Those headings Are used for all sorts of things Like marketing and so on It's not really an enterprise issue It is The classifications of Humanity is exercised For thousands of years So when you come across someone That's about to embark on enterprise architecture How would you advise them? Well One thing is Well My perception these days I would start with the general manager's problem But that resumes If you have some understanding Of what the architectural constructs are I would parse out of that problem Some of the primitive components That begin to populate The inventory But you need a methodology To do that So then I would embrace A tool gap The primitive components And then use that Use the primitives To create the composite Of the compound implementations That's what I would advise them Well I'd like to see the two Pieces of work Be closer together Yeah I think that would benefit The community I think it would I don't see any reason Why that can't happen I'm just going to take some work And we have a lot of inertia From where we've come So we've got to get inside Some of the capability Or business architecture Get inside to find out What the composition of those things are So we get down to populating The elemental or primitive Inventories from which we Create the composite One of the other things I'm Very passionate about Is the profession From enterprise architects And the uptake of the A.E.A 44,000 of growing Has been really quite good But we need a way of You know we've got togath And exactly the framework For guidance for people We have open certified architect As well as measuring that people Can do the job Or just learn these things But there's not really a long ramp For architects In any of the things we do To teach them how to do that I think FIAC does some of that Doesn't it? Yeah, a little bit of that You know, Al is really Another good question Roger Greer Who was the dean Of the school library information Managed to USC years ago Just passed away within the last I found some notes I made at an old guide conference In 1991 I think it was He was differentiating A profession From Craig And He identified the Profession cycle You start First one, you diagnose the problem Then you prescribe a solution And then you apply the prescription And then you evaluate the results And then you're into the cycle The professional starts With the diagnosis The trade starts With the application implementation So what differentiates The professional from a trade Is they start with the diagnosis And then prescribe So I say To enterprise architecture first We need to diagnose We need to be the doctor The diagnosis, the enterprise problem We're going in at the stage three With the solution We're going for the solution So we need to be a profession We need to start with the diagnosis And the prescription Okay, chief Here's four or five things We can do to address this issue And they're complicated issues So it's not one thing Here, four or five things Which one we want to pick And do and evaluate I think that's what differentiates it That comes from Roger From years and years ago I just recently Stumbled across my notes And I was writing some things about this But boy, I think that is the key To this whole thing If you can prescribe the enterprise solution I'll tell you what You're prescribed the problem And if you can diagnose the problem And prescribe the solution Our credibility We won't have a credibility problem We won't have a problem getting resource And time to do the architecture That's kind of where I'm going Boy, I'm really glad you raised that issue Yeah, I think it's really important And I think that Like any other profession There are a lot of disciplines within it So with accounting Which is my profession originally You've got financial accountants Production accountants Management accountants Factory accountants And so on And with healthcare workers The doctors have all got different specializations With lawyers And there's no reason why we shouldn't Have different specializations I agree I mean, we start thinking There's one enterprise architect I'll tell you what There's not one airplane architect Or one building architect And we don't We start to think that You know, one person does everything To forget that I mean, I usually say Nobody can Nobody knows everything Life is too short You know, these days when I wake up I look in the mirror in the morning I say, that man is running out of time We just don't have time You can't know everything You have to have people who have some Competence, experience And a variety of subjects And I really like that idea too Yeah, we've got to move from that Anyway, I'm great Really pleased that you're here with us You know, every time I'm with you Alan, I always feel better So I find somebody who really Is kind of into the same conclusions I can say Maybe from a different perspective I think we're coming to Some kind of conclusions And I always appreciate it I appreciate being here I'm doing a talk tomorrow On the subject of What I don't need for business architecture Oh, that's great I'm glad I'm anxious to hear that It could be fun It could be controversial I'm sure Thanks, it's been great talking to you Thank you