 Okay, well, I think we're right on it, right on two o'clock here, so we're gonna go ahead and get started. My name's Paul Price, I am the CEO and founder of ISA. We are the world's largest technology enterprise architect association. We do one fundamental thing, our mission statement is to, our vision statement is to make architecture the most recognized profession in the world. Our mission, the way we go about doing that is to develop a higher quality architect and make them successful at their job, give them the skills they need, the tools they need to do it, and promote that activity to their employers. So I like to tell my staff that we're the only people in the world that actually work for architects. Generally speaking, architects work for someone else and we work for them. We're much like the PMI or the American Medical Association or any of the other associations that you would be familiar with. But today, we're gonna talk about what it takes to become an architect. What is an architect or what is an architect? What is this word? I was down over at the vendor booths where we have a table and I was looking through some of the documentation because one of the more exciting parts of my job is I get to go meet, you know, and see all the vendors and see all the new technology. And in one of their top level descriptions, they said, you know, architecting big data. And I just then, and I laughed and I talked to the sales first. I said, you know, architecture is not a verb, right? There's no verb form of architecture. The verb form of architecture is to design. It's just kind of an interesting thing that this word gets used so randomly. So, you know, so just so much everywhere. I saw a statement about the architect of Obama's campaign, which I thought was another humorous use of the term. And quite frankly, you know, in the 11 years that ICE has been around, I have wanted to change this term so badly because of this confusion. But we have found a better one. Building architects settled on it, the naval architects settled on it, and now the enterprise and technology architects have settled on it. It is, quite frankly, the only way to describe what we do. Today we're going to talk a little bit about what this means. What is the difference between an architect and other people? Where did that come from? How did we figure that out? And what does that mean to you? Because fundamentally, again, the reason I'm standing here, and I've been standing in similar conferences for the last 10 years, is so that we don't have quite so much confusion around the term. So that if you want to become an architect, you have very clear, very simple steps to do so. Now, think about this. If you wanted to become a doctor, I don't know if you have the capability to be one or not. I certainly didn't. I didn't like blood, quite frankly. So that kind of limited my options in that space. But if you wanted to become a doctor, you would know what to do. Anybody here have any confusion over the steps that it takes to become a doctor? You know, college, med school, internship, residency, specialization, board certifications, fellowship, et cetera, et cetera. So nobody asked that question. Now, anybody in here have any confusion about what it takes to become an architect? I can tell you how to do it. Go get one of those white cards on our table and write your name, not actually your name. You're the one that's on your lanyard, and put architect them underneath of it. And then hand that out to people. If you do that long enough, guess what? And that is exactly the resistance of the entire technology field to professionalization. It's a very succinct way of saying the greatest drag that we have on successful growth of professionalization in IT is, it's just a lot easier the other way. It's also the reason, one of the significant reasons we have huge project failures and huge project failure rates. It's one of the reasons why we have, as an industry, one of the greatest failure rates, its most spectacular failure rates when you compare the number of technology projects that fail to, say, the number of planes that just happen to fall out of the sky. It's one of the reasons why we are the least satisfied in our work. It's one of the reasons why we are the least recognized in our work. And one of the reasons why we are not included in most of the strategic decisions of the organizations that we actually slave for, work for. I've yet to hear a technologist say, man, I just really want to build this thing because it's cool. I really don't care, you know what happened? I'm just getting my employer to pay for it. Nobody has ever said that to me. I don't know if any of you have ever heard anybody say that, that wasn't joking, that you didn't know they were absolutely kidding. But that's our reputation. Our reputation is, hey, let's go do big data, man. That sounds like fun. Cool, I'm down with that. Yeah, no SQL. I want something as completely unreliable that will break on my customers as often as possible because, you know what? I can get a cool job that way. Right? And what do you hear in every IT conference? You hear, all we want to do is good solutions that our business users love that make a difference in our organization. In fact, it's become a mantra. We want to serve the business. In fact, that's probably one of the worst lines we could have ever come up with, by the way. We're like Democrats, we should name things. Serve the business. You know, the reason that I bring this up is because this is fundamentally what being an architect is about. Is how do you create a technology environment that is a strategic advantage to your organization? So, first today, we're going to talk about what is an architecture? Because, guess what? After 11 years of this, after something like 50 documented years of the use of the term, we are still asking the question, what's an architect and what is an architecture? So we're going to talk a little bit about that. Then we're going to mention the fact that, yes, you know, we are business people and we are technical people. And we fit in both as software and information architects. And then we're going to just mention the kind of balance that you need in terms of your career between skill sets, between levels and what you should expect in terms of benefits from that. How you can organize your team, how you can organize your architects and your people doing stakeholders to architects in such a way that they'd be optimized for success. And we're going to do all of that in what is now something like 38 minutes. So, we're going to get started. Just before I start, I did want to mention that ISA is a non-profit professional association. We're run by architects. All of our chapters and all of our infrastructure and all that stuff at the lead has an architect. I was a practicing architect for 15 years. I worked in Japan for Dell. I did their point of sale, or not their point of sale, but their retail systems. I was with Sears. I've done work with IBM. I've done work with digital asset management, Technicolor, many of these kinds of companies. So, we only put architects in charge of their own profession. We are for all IT or technology architects. And yes, we do consider enterprise architects to still maintain their technology skills. We don't say that they're just about technology, but they very much have to maintain their technology skills. We are centrally governed and locally run. That's an economic principle that works everywhere, meaning value is local. If you live here in San Jose, ISA is less valuable to you because we don't have a chapter here. If you live here in San Jose and you'd like to start a chapter, come see me after the talk. Technology is very diagnostic. Well, we've got 60,000 people in our professional network, and so we have every technology involved. In fact, one of our primary motivations in organizing the association was to develop a skills taxonomy that had nothing to do with vendors or technology, had something to do with what does it take to create a great architect. And what we found is quite simple. Architecture is about technology value. You know how the Agile Alliance said that Agile is all about delivering great software, not documentation? We're all about delivering great technology value, not necessarily just great technology systems. What does that mean? It means an architect can be doing just as good an architecture by shutting off systems and not replacing them. Because replacing them costs money, right? And our companies don't want to spend money unless it does what? Provides competitive advantage. So you're going to hear me talk about that a lot. Architecture is a profession and not a job. Was I the only person that heard that? Okay. I have to ask, because you know, I travel a lot. I get in time zones. Architecture is a profession and not a job. Now, what does that mean? It means that your company doesn't define what an architect is. It means that the profession defines what architecture is. I didn't look good in that. We had little hand signals. I think it still needs more yellow. I'm a little, you know, pasty. Good technology strategy is about how architects engage. What is that? Again, we're talking about it doesn't have anything to do with how good the architecture is. It has to do with how well it's delivered, whether you touch your business effectively. How many of you have heard of the architecture teams being fired as a group on mass? I've been here for two hours. I've heard the story three times. We hear this constantly. Architecture teams have to show value the day they start, and they never get fired. If you're going to wait a year to show value, if you're going to wait six months to show value, kind of think about if you went to the doctor and he said, well, I'm going to wait six months to show you. Because who knows, you might get better on your own. I don't know something. If you went to a building architect and he said, all right, I understand what you want. Give me six months to think about it. When you go to a professional, you want value that day. Let's talk a little bit about what is architecture. How many of you are practicing architects in here? All right. That's a pretty good percentage. All right. Nice to hear. Software. Primarily. Okay. Data. Database. Folks. Good. Infrastructure or operations. Oh. Why is my server down? Come on. All right. I myself was a practicing software architect. ISA originally started as the International Association of Software Architects. We are now just ISA. We took away the acronym because we branched out. So just so you know. We get into this question of what is an architecture. And these are the things that I hear the most. Mostly you walk into a new organization and they say, let me show you our architecture. And what they're really showing you is some sort of design, right? Some sort of block diagram, UML, some form of visual design. And in fact, this is primarily, this is easily 90% of the professional body's definition of what is an architecture. And I'm going to kind of astound you a little today. I'm going to confound you with simplicity because we're not going to talk about no SQL. We're not going to talk about technology. We're going to talk about these kind of fundamentals. If you look at something and you say, is that an architecture? This will fundamentally change your practice. Because the answer is actually pretty weird. The thing that actually makes architects successful, I'm going to surprise you with at the end of this portion of the presentation. Because it turns out that most of these don't work all that well. What is a visual design? You know, you've got a UML diagram up in front of you. Okay, is it a designer or is it an architecture? Can it be both? Is there any reason to use one over the other in that context? Okay, the other concept is an architecture is a document. It's a deliverable. I'm going to hand you the architecture of our system. If you're a consulting organization, you probably get paid to create architectures. And what do the architectures come in? They come in documents. Now, the question is, is there such a thing as an architecture without a document? Is there such a thing as an architecture without a design? Now, this one gets into those navel-gazing conversations, so we're not going to stay there long. But this is the fundamental failure of most of the architect teams that I've ever seen is to debate this. Because it does no good. There's a smaller group out there that says architecture is about the decisions that you make. What is the good decision? Should I use HTTP in my architecture? So architecture is the decisions that make up this document or this diagram. Meaning, what did it take for us to put... Okay, that was weird. What did it take? What were the pieces of the system? So here's your visual design. And here's a descriptive documentation example. We say, the system will use a thin client. The client will be a browser. And the system will support... The browsers will be Internet Explorer 9 and Firefox, whatever I put. That is often what a design document looks like and what people often call an architecture. Want this one? Or this one? The third one is the decision. Now, if you get to this level of architecture documentation, I'm proud of you because very, very few people even do this. We will use a thin client because it will remove the need to install. We documented our decision. The difference between this and this is now at least linked this concept of value or requirement to the concept of the decision. The system will support Internet Explorer 9. These browsers are a part of our corporate standard blob. I'm not going to sit here and read slides to you. But the idea here is that most architects don't even go this far. Even today. Now, people are getting better at it because we've pounded this into them for 10 years. But to justify a design decision based on a requirement, a technology choice, is still a very rare occurrence. Now, often that happens in around the coffee, you know, the coffee pot. But the problem that I have with this is it still doesn't answer the question, how is this different than a design document? Isn't this just a design? How is this an architecture? What makes this unique? Why have so much fervor over a word that is semantically equivalent to design? Now, how many of you get this far in your architectural work? I got that far and it gets fired. I only got that far and it gets fired. You got that far at what? If I only got that far, it would get fired. Thank God. Thank God. The number of places that you saw, we had five hands raised. Architectural documentation is about understanding the value of the decision you're going to make. But here's where the design document ends up, right? You end up in a good design document with the system we use a thin client, those reasons behind it. You've got some choices around technology that get made. We're going to go with IE and Firefox. This would have a dotnet stack or a Java stack or a PHP or whatever app servers or whatever tier design you're using. This would have a... Should I pick one of the vendors at the event? Should I show them? Data store. This would have some sort of storage for data that either does or doesn't use SQL. And maybe some of that data is big. Anyway. And then your architects often have to... Your architects say, well, I did a prototype. So they get to go play with the technology. Your software architect goes in and writes a couple of kind of fake pages and connects all these pieces together and says, woohoo, I'm done. You guys go implement. Throws it over the pad. We don't recommend that as a best practice, by the way. Just so you know. So I come back to this. What's the difference? In that situation... Is anybody here just a developer? Not just, I apologize, I mean it that way. Is anybody here a senior developer or just an application developer? Does not an architect? Okay, good. If you and I wrote that document, and we wrote basically the same document, which we generally would do because that document stands in and of itself. Most project teams come up with some version of that. Well, no. I wish most project teams came up with some version of that, I should say. Why am I an architect and you're not? Because I likely make more money than you do at the same company. Is it because I put it on my card and I said I'm an architect and they believed me? I mean is that the only difference? And this is what we were asking at ISA, and this is what you have to ask yourself when you're at work, is what am I doing differently? How am I taking, what's your name? Mike. How am I not taking away Mike's skill and expertise and brain? I'm an architect. He's a developer. How can I be a peer, a partner to Mike? How are we doing different jobs? How is it not just hey, Mike, are you done with that code yet? I need to review your code. I need to make sure, you know, since you're kind of a monkey guy and just all you do is write getters and setters that you didn't mess it all up. You know, what we have to distinguish is what value am I adding as an architect that's different than a tech lead or a developer that designs a solution? And in our minds, the question is, what's the definition of good? Now let me link these concepts together for you. So the dictionary.com definition is suitable or efficient for a purpose. What is the primary purpose of most projects? What is the primary purpose that drives technology decision? Purposes, I'll call them to give you a hint. There are multiple purposes generally written in a document by a business analyst. Requirements. We say in a project that the good is whatever is in those requirements. What ISA has said and determined that I think is going to be, that I think and have seen is fundamentally changing the industry is that architects define good differently than project teams, developers, business analysts and pretty much anybody else. Because we don't really, let me not say it that way. Requirements are not our primary driver. Requirements are a fundamental part of a project which is a temporally limited activity to deliver a set of functions to an organization or a group or an entity. Those functions have profitability, constituent value, reuse, market size impact or market quality impact. How many of you have seen a requirement that said something like, something equivalently silly as, we need to be able to change the color of the buttons on our interface every other month, right? Where you just kind of, you sit there and you go, am I dyslexic? Does it actually say that? This is a $600,000 project and we have to go write all of the technology to change the color of the button. That sounds kind of cool. I wonder how I did that, right? Which is what we normally do. We kind of go, well, okay, it's a requirement, let's get it done. The architect says why? Why? I call it the cornflower blue button syndrome. Do you ever watch Fight Club? See, I had a couple of people who just napped a laugh immediately. I know my Fight Club guys are right away. But the point is, in Fight Club, there's a scene where his boss says, can I get those buttons in cornflower blue? It's his favorite color. And then of course the vendor says yes, yes, yes, yes, yes, because vendors don't say no. Who says no? Architects. Who else says no? Business people. When we want to do something, they say no. You know when they say yes? When it shows profitability, constituent value, reuse, growth and market size, and growth and market quality. And I'm spending a lot of time on this because this is how Mike and I get to talk about and do similar documents but have fundamentally different jobs. Mike's job is to implement it as good as possible according to the project requirements because if he didn't do so, if he asked these questions about everything, we'd never get any code written, right? His job is to deliver on time and on budget, just like the project is, against the requirements. But as an architect, I think that's a terrible way to measure the success of a project. Do you measure the success of a marketing engagement, an advertising campaign based on whether or not it was delivered on time and on budget? Some people do. And those people generally don't do really well in the long run with their marketing team. And the marketing team tends to go the same way that our IT teams or technology teams do because that's a terrible way to evaluate the success of a marketing campaign. What is the success of a marketing campaign? Profitability, constituent value, reuse, growth and market size, and growth and market quality. And I bring that up because these are the driving factors for every business unit except for IT. Now, we know that's not true. How many of you have worked on a strategic project and a piece of technology that you know has fundamentally changed the way your business works and the value that you're capable of providing as an organization, not just as an IT department? The hands are going up, you're thinking about it. There were at least six or seven of us. Generally speaking, if you get around the water cooler or have a beer with most technology people will say, yeah, this was really, really cool. And you know what it enabled? It allows us to do this stuff with the supply chain that blah, blah, blah, blah, blah system could do. And we could never do before. And the marketing team is thrilled because now everything's Facebook enabled and they can click on like a boss. Anyway, they can do anything with technology. We want to provide value with technology. We've just never codified it before. Enter the definition of good for architects. The reason Mike and I can work so successfully together on a project and what my job is on that project is not to review his code. Though I may do so for other purposes than do you write decent code? I expect a tech lead and chief lead engineer, lead developer would know how to review his team for writing good code. What I'm looking for when I review good code is are we actually delivering on the ROI of the technology that we're investing in? Are these components strategic to us as a company? And I don't mean all of a sudden an enterprise architect. I mean for this project in its deployed environment are we going to make the money that we think we're going to make? Does this enable features or functions that we haven't thought of that maybe some other project is doing? How many of you have more than one persistence mechanism in your current customer's environment, current employer's environment? The rest of you use one persistence mechanism? Really? How you persist data? The tool or technology that you use to put data in a database? That is a possible, I guess. That would be a company I would be interested in seeing. In fact, I would love to see that, the case study. The non-data storage, storing company, do you think they could just like change their business model every day? Does that mean they have no data stored anywhere? You win. That's a cool idea, I don't know. But this whole concept of how does technology fundamentally impact our business at a strategic level? And again, I don't mean I'm going to go from working on the Human Resources project that I'm on that's a $100,000 project to go on and talk to the CEO the next day, but this is how you end up doing that. So if you want to become a great architect, these are the questions you're asking. What you should walk away from here with is, if I'm not asking these questions, then I'm not architecting. Because these are really the questions you're asking. Does this mean that I have to be any less technical? No. How does this impact my overall deployment environment? How does this look in my topology when it's deployed? You have to know everything the tech lead and developers know, because otherwise they don't respect you enough to even listen to you. So if I go in and I say, Mike, sorry, but the JDBC driver we're using is just not going to cut it. Or whatever. He's got to respect me enough as a software architect that he's going to go, I'll take a look at that, let me go check that out. And the only way he's going to respect me is if I know my stuff. But I'm not telling him that because the team is bad and they've picked the wrong technology. I'm telling Mike that because that JDBC driver likely breaks one of these questions. It doesn't fit in with one of these questions. Like, should this be built? Can the organization handle it? Yeah, go ahead. So if you're finding good for a software architect's profitability, is there any room or requirement for a software architect in a strictly open source world? Absolutely. Notice there's room for architects and nonprofits, which will blow your mind after a while. There are five categories and this is actually taken from early work in valuation of technology as an investment in the US government. And I can show you a couple of papers after the talk if you want or more later if you email me that talk about this. Originally the bottom two said increased democracy and things of that nature. Profitability, constituent value is fundamental to what's our number two priority after sales, customer service. Constituent value is about how do we help our customer? How do we work with people? How do we create reuse? How do we grow market size and market quality? So we can invest in lots and lots of things as long as we measure the value we received in some fashion. And that might just be X number of percent of our customers are more happy with us as measured by the following survey. So there are a lot of different ways you can take that. The one we're talking about today because it's the one that's most often used in investment decisions is profitability, is ROI, things of this nature. Notice I pulled out things like this, will the organization accept it? You may have the best solution, but if you can't sell it, if you don't have the human dynamic skills you need, it doesn't really matter. So again, an architect must describe why technology decisions are being made, connect requirements to those design choices, but fundamentally the new piece here is include cost and benefit analysis. Benefit, again, analysis could also be measurements that are not profitability based. We may design a whole series of measurements just to understand the value we created. And one of those skills that we talk about so much that architects must possess is the ability to measure the value of the solutions and design that they created. This starts looking more like an architecture. This will remove the need to install a client at systems. Guess what that impacts? These numbers right here. But guess what it impacts here? Because this is web based, this one little puny little line here that says some users need access to the system from a remote site. Well, you could do that with a VPN, right? But if we put this... Do you mean like looking through a telescope or do you mean a remote location? You spelled it wrong. Oh, thank you. I misspelling there. Sorry about that. Good catch, though. You can review all my design documents from now on. Quality assurance, as it was. This is a really interesting figure down here because we put it on the web. Guess what? We've got customers that can access it. So this is an arbitrary make-believe deal. But this to me is what we see as the trend as to what makes an architecture versus what makes a design. This is a very, very simplified example. If we go back... Just a question. Isn't that second one some user analysis system from the remote site something that they put this requirement not architecture decision? It is actually. In fact, these are... If I wasn't clear, this is the architectural decision. These are the requirements that back it up. And this is linked to the cost-benefit analysis, to the series of cost-benefit analysis that we do as architects. So from the decision by architect, because we have those requirements, right? No, this happens all before any code is written. So you get a requirement from... Generally what will happen in a project is some form of business analyst, hopefully an architect as well, will work with a series of other business units to describe a potential solution. That solution will be assigned some form of ROI and some form of pre-design. Again, these are effectively meta-requirements, right? This is not what we would expect to see in a requirements document. It's not granular enough. It's a meta-requirement. It's going to be out on the web. This is going to be web-based. Those meta-requirements, which look like they're above sea level, if you look at some of the early requirements, you know, UML and requirements, documentation stuff, tend to be the constraints that help define your solution. The definition of those solution elements are almost often in the hands of software solution architect. Those impact profitability in numerous ways. And what ends up happening is either those... those ROI calculations are generally way off because, well, they're created by people who have no idea what the value of using a web-based client would be to the company. What happens here is we link those meta-requirements to some form of architectural decision, to some form of cost-benefit analysis of the options that we evaluated, so that we have a track of, A, why we made the decision, and, B, what we expect to gain from that decision so that we can measure the effectiveness in our deployed topology. Therefore, improving our architectural decisions over time. So, real requirements would generally come after this step, the really detailed stuff. And that's where we tend to fall down on our faces because the architect, especially in those situations where the architect goes, here's your document, I'm done. This is why we talk about an ongoing relationship between the tech lead and the architect in a proactive development fashion. Not because, again, I'm there to make sure that the code is good, but to make sure that we don't invest into anything that didn't get included on these line items. Oh, all of a sudden we've got 20 JavaScript libraries in this new thin client that we didn't, I never said anything about, and we have to maintain those in, oh wait, that blows up our entire web infrastructure because it's incompatible with the 15 that we already have, and all of a sudden our costs go through the roof. And this $2 million of benefit down here disappears because we have to redeploy every server in the infrastructure over 15 JavaScript libraries. I say that with some, it's almost like it's make-believe, but I've seen this, something, a simple decision like that fry entire development environments and delivery environments. Now, just in case any of you heard what most people hear when I do this, the port of this talk is, well, it sounds to me like you're an accountant, but I'm a technical architect. I like my technology. Well, I like my technology, too. The difference is most of us techies tend to lack the piece that's most necessary to make this value happen and to put technologists on the map as business people the way they should be. And that is the human dynamics and business skills that I've just started to demonstrate. Describing value of your solutions doesn't make you less technical as an architect. In fact, it makes you more technical because the research you have to do to understand the impact of a persistence mechanism to share price is pretty weird stuff. It doesn't really... It makes us understand our solutions in more depth and this is where you need to take your career if you truly want to be an architect in the long run. Because more and more, all around the world, I see organizations moving to differentiating between technology delivery and technology as investment. I'm working with the largest pharmaceuticals, the largest banks, the largest manufacturers, retail, all of that, and each one of them have begun to truly adopt this as a definition and are looking at technology now and saying, wait a second. If I offer $100 million, let's say I'm a bank and I want to buy $100 million worth of new teller, not new teller machines, new stores, new locations, then I can offer a bond out to the marketplace as a capital investment and then pay 5%, 3%, 6%, whatever on that bond. So basically the marketplace is going to take care of my investment for me. But if I want to spend $100 million on a cloud strategy or a big data strategy, I'm hosed. I got to pay for that all myself because nobody understands how technology fundamentally changes my competitive advantage. And they're all saying, wait a second, this is not right. Anybody here see that the Mercedes ad about a month, about nine months ago where the Google exec was sitting in his chair and he says, my Mercedes saved my life. It doesn't really show him rolling up to a big party with this huge Google salary and whatever, looking like a superstar. They're not selling the design of the car. He says, look, I almost got in a wreck, but the software onboard saved my life. That was it. The whole commercial was about the software that was embedded in that vehicle as a fundamental differentiator of why to buy a Mercedes. Now, this is as powerful a message to us as could be given, as we could receive. Get with the program. This is a business differentiator. The technology we use, fuzzy logic, no SQL, fundamentally impacts our ability to compete both positively and negatively. And as architects, what you'll be doing is setting that strategy, defining that value and that difference. You're not a product manager necessarily. You're not a project manager. You're not a business analyst. Business analysts still have to work and define detailed requirements and those kinds of pieces. You'll work with the PMO as a software architect, as a project level technical guy or gal. You'll work with the PMO. You'll work with the business analyst groups. You'll work with the business users directly. But this is what we have to be able to do. We have to be able to use our business and human dynamic skills to define the value, sell it, lead it, and ensure that all the stakeholders agree. Now, I'm going to skip these two slides because I think it's easier to see, or three slides, because I think it's easier to see here. This is, as best, the single most adopted skills taxonomy I've found. We have mapped it to BCS, the British Computer Society, Hong Kong, throughout South Asia. We've mapped it to multiple participating organizations. As I mentioned, pharmaceutical banking. You'll be seeing this in an architect job in your future. This is the skills taxonomy. It says, here's what you have to know to be an architect. This is the very highest level view. And it basically says this. Here's the baseline set of skills you need, the body of knowledge that all architects possess. Your average IT person has IT environment, which is how you build software and how you build technology stuff. And quality attributes, which are cross-cutting concerns. That's here, security, reliability, manageability, that kind of stuff. Your average IT person has those already. Where we've been missing. Business technology strategy, which is the value that we just did as a group. What we just covered was, how do I show that technology is strategic to my company? How do I make people aware that what I'm working on isn't some geeky little thing? This thing's going to fundamentally redefine the way we integrate with our supply chain. Human dynamics is how you lead, communicate, how you deliver those solutions to a group of people in a way they understand. How do I walk into the CEO's office in one minute and then walk over to the data center and know that I can communicate at their level the elements of the strategy that they need to know in a way that fundamentally gets their buy-off in the direction that I want to take us. And design. Believe it or not, as good as we all may be with UML and box diagrams, at the beginning of this conference, I was talking with the meeting coordinator, a meeting event planner, Maya. Obviously she's put together a great event and the diversity's put together a great event. And she said, you know what's funny? I keep hearing in the rooms these words like elegance and beauty. Design isn't, it's not just the skills for an architect that are about, you know, did I use enough patterns or did we use a prototype pattern on this or singleton? It's, you know, do I know UML or SysML? It's how do I design effectively and minimally? These are the areas where most technologists need to work on to become architects. Now finally, I wanted to mention the engagement concept. Engagement is one of those things that people tend to forget. When we talk about engagement at ISA, we talk about every way a group of architects touch their business. I once saw a company lose $70 million a week on a decision that was made around a water cooler. I'm not kidding. They decided to integrate something they shouldn't have integrated around a water cooler if there was no documentation. I just, I was just there. They asked me to sit in. And that was architecture to them. Believe me, they fired every architect after that. But they thought of it as an architectural decision. You know why? Because two of the people that were in that, around that water cooler were architects. So it doesn't, it just has to be a formal design document. It's really, engagement is really about how architects touch an organization. And that's good or bad. So think about every time an architect talks to anyone, delivers anything and that's your engagement model. Engagement is how you deploy your architects. Now, at least I, let's, I leave you with a misconception. This does not mean that enterprise architects only work in these two groups. This means enterprise architects work at this level up here at the enterprise. Business architects, this is a generic model, basically says enterprise architects look at the entire thing, but they cannot function without the rest of these architects touching the rest of the organization. So we have business architects working at the line of business and the business capability level. Information, data architects tend to work the same place. Software architects most effectively work at the solution, which is the multi-project, what's often known in PMOs as the program level, and the project level. And infrastructure architects most commonly work at the center level in coordination with these two. All of these people have to report up into the enterprise architecture group. Dot it lined, I don't care. If you federate them, you federate them. If you centralize them, you centralize them. If you have a report to a business unit, that's fine. As long as they work together as a team, you have a solid engagement model. I will tell you, you generally have very little hope of being successful as an architect team if you do not have all these people working together, knowing each other and covering the entire enterprise that way. I see too many organizations fail because they have a pocket of architects over here and a pocket of architects over there. And then finally, the career path. Now, the reason I'm skipping through this real fast is you can find all this stuff on our website like 18 different ways. You can actually learn this in depth, but I think it's a $125 membership fee and you get a free eight-hour, seven-hour class online that's self-paced that'll walk you through all of these skills in depth, and that doesn't include the in-person stuff training that we do on top of that. But the career path is pretty simple. You're going to follow. You're going to take foundation, certification, and training. That's just to get the update. That's just to figure out what architecture is. Again, that's the training that we do of self-paced. We also do that in person. So you can get that foundation certification just about as cheap as possible. I think it's whatever. It's 100 bucks to study and 300 bucks or something for the start. The associates where it gets exciting, that's the depth skills. That's where we start getting into the real super detail on human dynamics, BTS, software architecture and practice, IT environment quality attributes. But again, these two levels of certification are really about knowledge. The next step up for you from there is going after your professional credential. Your professional credential is a board certification. You will sit for two, two and a half hours in front of the board of peers. You will present your experience, not your knowledge. So you'll work with a mentor during your internship experiential gathering phase. And then you'll go sit in front of a board. Generally, this is somewhere between 7 and 10 years of experience. Finally, if you choose, you may go on to the master level of certification, which is really for industry thought leaders. It's for people who, you know, Frank Lloyd Wright was a master building architect. It didn't mean he was good at everything. He was really terrible at office buildings. He was great at homes, you know. Chief architects are this level generally. This professional certification career path has been picked up by significant numbers of companies. We have a number of companies that actually just require certification now. They just don't want to worry about it. So it's gaining traction. But more importantly, if you're like me, what this does is answer the question, how do I become an architect? We've got plenty of information on that. Like I said on the website, I'm not here to pitch our career path to other ways to do it that we can talk about. But basically, the whole goal of this entire career path is to create stable practitioners that have the skills that I just mentioned, and that can show this kind of value. So with that, I am five minutes over. I'm sorry, folks. I stopped looking at the watch once I got into it. So I guess I could take questions outside, but somebody's moving. So that's it. Thank you very much.