In Austin, Texas at the TeleLogic User Group, Innovation 2008. We've got another guest to talk with us. Would you like to introduce yourself? Yes, my name is Martin Owen. I'm the Vice President of Product Management for Enterprise Architecture. Catching us up to where we are now, in the TeleLogic world, since that's sort of the world that you come from, what is Enterprise Architecture? How does it work out in the systems world? Enterprise Architecture is really about describing the business operations, the goals, the tactics, the motivation for an organization and why they do things, but also planning that out further down into application development and solution delivery. In essence, it's very, very simple. It's about specification and planning and understanding at a very high level what you have as an organization and how it ties to what you're trying to achieve as an organization. In that context, especially in the context of systems thing, what type of person usually is, or people I guess I should say, I shouldn't think it's just one. What type of people are fulfilling that role of Enterprise Architecture? In terms of building the Enterprise Architecture. Yeah. You normally have Enterprise Architects or the business process community. They're normally developing and maintaining the architecture. But you have a range of other stakeholders that are involved in accessing and using the information within the architecture to make business decisions, or to in fact feed solution delivery or software development or systems development later. As far as architecture, it also touches on other aspects of the Argon portfolio. Right. In terms of product portfolio management, project portfolio management. So, with Enterprise Architecture, you can start to plan out the different projects you have, but also start to understand the IT infrastructure you already have as an organization. Right. And the different software development projects that are on the go. And also the organizational infrastructure that affects all of that as well. Being a tools vendor, if you will. Yeah. The combination of TeleLogic and Rational brings a whole bevy of different tools that I think everyone knows and can figure out, help out with this process. In that kind of process, where are things starting to fit in?
2:00Like, what tools fit the different parts of the process of doing it? Interestingly enough, when TeleLogic were acquired by IBM, they didn't have an Enterprise Architecture tool, per se. And they were putting together a series of tools to fulfill that role of Enterprise Architecture. Right, right. Were the offerings more sort of requirements-oriented? There's a mixture. There's requirements tools. Yeah. There were modeling tools, primarily for UML. Right. There are also other tools built around asset management. And other tools around, you know, visualization. And some of the other brands of IBM providing tools that could help visualize some of that information, like Cognos and some of the other brands as well. So, bringing technology into that portfolio is providing them with an Enterprise Architecture toolkit out of the box. And it expands the vision in terms of being able to describe, you know, really top-down within an organization. And putting all the pieces around that that connect into Enterprise Architecture. So, giving you a much more holistic view, a much better view for being able to plan your IT architecture and to be able to relate that back to the business. Whenever you're doing any type of software, one of the problems you always get is figuring out if you're going to get done. Or like, at what point you're going to get done. And then more importantly, getting feedback throughout the process so you can sort of course correct or whittle things in sort of like the evolving sort of Enterprise Architecture that you're seeing. How do you sort of get that pulse of what's going on so that you can start to say like, you know, we need to fix something or do something differently or go about getting to what we want. Yes, there's really two ways of doing that. There's the traditional way, which is really where the traditional rational tools fit in. Where they're very strong in terms of building and implementation. And then you have the requirements management, you have the testing, you have the ongoing lifecycle management of the actual delivery of the project itself. Right, right. But at a much higher level, there's obviously business changes that affect projects. There are environmental changes, there's cultural changes in the business, there's different goals and directions that business wants to go in. So that's a completely different change paradigm to projects that have been used to in the past.
4:02Bringing Enterprise Architecture into play allows us now to control and govern those projects from a much higher level within the organisation. The most traditionally possible, just looking at projects in isolation. You look at the bigger picture, you're looking at bigger implications on things like cost savings of projects and turning around the business to be able to react quicker to change. And you keep getting to an interesting aspect that when I was developing software for an ISV, software to sell, not for a company, we were doing a lot of agile software development. And most of the problems that we would encounter would be, as you sort of keep alluding to, organizational problems. Where each individual group was using a tool to perfection or whatever, right? And doing the right thing by the tool and the process. But the different gears didn't really mesh up together too well. Enterprise Architecture traditionally has been in the IT domain. So a lot of the current Enterprise Architects live in or under the banner of the IT departments. Right. But what's happening now is that the CIO within the organisation, who didn't necessarily used to be on the Board of Directors, is now on the Board of Directors. And the Enterprise Architects tend to report into the CIO and are much more affecting the business strategy. And that's requiring a different set of skills. So it's not just IT focused and understanding systems and technology. But it's also being able to communicate to different stakeholders in the organisation. And be able to communicate in a way which demonstrates business value and decision making about IT architectures. And other things that affect that as well, like organisational structure, like the different locations you're doing business. It sounds like the sort of end result is a lot of reporting that's sort of mapping the activity that's going on in the development process, if you will. Or in IT or things that are happening and mapping that towards sort of, to use another overloaded term, sort of business outcomes. Or, you know, when you boil it down, are we making money or losing money? Yeah, a lot of it is to do with costs. So IT is quite often seen as a cost on the business rather than an enabler. So enterprise architecture is very much about making IT an enabler for business by selecting the right programs and the projects of work within the context of what the business is trying to achieve.
6:05Right. And making that very visible to the CXOs within the organisation makes IT that enabling part of the business. So to ask an overly grand question, I mean, how do you do that? And I ask that, you know, coming from sort of the IT world, you know, it's just sort of business, people get, a large part of why people get into IT is to not get into business. Right? I mean, they're sort of different mindsets that people have learned and cultured themselves with. It is a challenge, without a doubt. But interestingly enough, the world is changing. Most business people now, a lot of them are techie or savvy with technology. Oh, right, right. So things like Blackberries and all sorts of other things. So it's becoming more mainstream that that link between IT and business is okay. It's okay for the business. Right. It's okay for the business to have some technology. It's not alien to them. I guess you have less business people whose secretary answers all their email for them, right? Yes. They do everything on their own and everything. Yes. A lot of people, I use Expedia a lot. I use flight booking services and book my holidays and stuff like that. So I use technology a lot. And the business does as well. But you still have to make the information available to those parts of the organisation in the correct format. Right. So it's taking the same set of information that describes a business and the IT infrastructure and making it palatable for the different people. So for a CXO, you would not present to them, for example, a UML cell diagram. Right. You'll get thrown out in the boardroom. So what you really need to do is go in with four or five PowerPoint slides that are succinct explaining what you're trying to achieve, but that are derived from some underlying architecture that has a foundation. Right. And similarly, if you communicate with operational staff, the people that are the domain experts in the business, you really want to show those people things like business processes. Things that are relevant to their everyday jobs. And similarly, if you take a deep dive down into the architecture itself, you should also be able to take that same information and take it apart for a technical person. So you can actually dive into the detail.
8:05Right. So it's about taking the same information that's an enterprise architecture and disseminating into different ways and different communications. Exactly the same if you think about architecture and building architectures. So if you present it to the owner of the house, they're probably interested in the operational plan of the house. So they're probably interested in where the sockets go. They're interested in what rooms they have, what functions those rooms produce. But in terms of other stakeholders in the street or the road, they're probably just interested in what does it look like? What are the aesthetics of the building? What's the impact on me? Whereas if you go into or talk to the electrician, he has a completely different view on the house in terms of how things are wired together. Are you using standards? But it's the same set of plans. It's the same architecture, same building. Right. But it's just conveyed in different ways depending on the audience. I'm curious when you go into an enterprise or a company and they're sort of, I guess to be kind, sort of lacking in enterprise architecture like abilities. Yeah. Like how, I mean, what sort of like the process or the program to sort of ramp them up to this nice, to this thing where, you know, the plumber can worry about the plumber and the electrician can worry about the electrician. Normally, and he's still going through the IT department because it's, again, it's normally still seen to some extent as a technology. Right. And it's modeling and it's an art and it's building something. So, normally you will go into the, talk to the IT director or the CIO and he normally has a handle. He's trying to address business problems. So, normally it's going into that part of the organization, picking a specific business problem to address and addressing the enterprise architecture, proving the value of that in a small way. And then building on that and actually doing it as proof of concept and actually, you know, proving the enterprise architecture, you know, delivers value to the business. Having a sort of incremental successes to get to a final big bang, if you will. Very hard to actually go into a company and say, here's your return on investment. Right. Because enterprise architecture is part of the infrastructure of the organization. Yeah. It's a culture as well. So, if you don't have that culture of being able to, you know, understand your business, want to understand it, want to be able to plan properly, then it's going to be very difficult.
10:06Right. But, yeah, nowadays, the world's changing. A lot of people now realize, a lot of organizations realize, they have to understand what they have to be able to respond quickly to change. One of the good things about, obviously, IBM acquiring TeleLogic is bringing the enterprise architecture products into a company like IBM with all of the concepts that they have. We can really make enterprise architecture mainstream and convey that message. The one thing that was always difficult to convey to, as I always like to call them, the gold holders, sort of the business side, you know, when we were doing software and that was the, the sort of business value of flexibility and, and being able to change, you know, dynacism, to use another crazy word. Right. And, you know, it's, it is a difficult thing to say, like, we're, we're going to do this, this part of the system that's going to have no visible effect or whatever, right? But, but, you know, six months from now, you'll be thanking me about it. Yeah. The architecture's living and breathing. Right. Once you start it off, once you've got somewhere down the road, you can start to, to ask questions of the architecture. Right. So you can do impact analysis. So as soon as you, you're, you're out there talking to the business and you understand there's an issue that they need to address, you can use the architecture to, to address those questions. So immediately, as soon as you start doing enterprise architecture, you're, you're adding benefit to the, to the business structure. Right, right. And it's demonstrable. So, so what you have to do really is be able to capture information from those domain stakeholders. Right. So you have to have visibility in the fact that what you're providing is not an IT tool for developers. What you're providing is a, is an architectural repository that the company can rely on. And that the information within that repository is built from the people that understand the business. Right, right. So once they're contributing to that, and without technology you can do that, then the decisions you're pulling out of that repository, you know, are fairly accurate and fairly, fairly, important in terms of the stakeholders asking the question. Yeah, yeah. I mean a repository of information. It's probably a better way to describe it. Right. A repository of information about the business and its underlying IT systems. Because enterprise architecture is an overloaded word. It sounds very technical as well. Right, right. So you wouldn't probably communicate those terms to the stakeholders. Right, right. And it also has that danger of architect is sort of like the supreme technical level.
12:07Right. Yeah. And so it, it becomes everything that, that every technologist eventually wants to be with their life, right. Yeah. Instead of, instead of a narrowly defined sort of thing. Yeah. And what you don't want to do is build an ivory tower of enterprise architecture. Exactly. Which has no influence on the business and has no, has no buy-in. So you really need to get the buy-in of the business by having them contribute and build the architecture. Well, thanks for being part of the Rational Talk series. Okay. That's great. Thank you.