Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.
Today we welcome our listeners to a special sponsored podcast discussion, coming to you from
The Open Group’s 23rd Enterprise Architecture Practitioners Conference in Toronto. This podcast, part of a series of events and live discussions here the week of July 20, 2009, centers on the fast changing role and expanding impact of enterprise architecture (EA).The EA role is in flux, especially as we consider the heightening interest in cloud computing and in the fluid sourcing options for IT applications, data services and infrastructure, not to mention business processes that fall outside of IT entirely.
The down economy has clearly focused IT spending and analysis on priorities and doing cost-benefit types of activities, with an eager eye to seek out faster, better, and cheaper means to acquire and manage IT functions and business processes.
We've already seen a great deal of interest and activity around platform as a service (PaaS) and the application development and testing phases of an application's lifecycle. Many of us expect to see a great deal more of the application lifecycle, from design time and long-term production and integration across different aspects of processes inside and outside of the organization to become more part of a mixture of services.
These will become internal, external, and hybrid, and a lot of different sourcing innovations are yet to come. Soon many of these will skirt IT altogether.
So, as these service components shift in their origins and delivery models, the task of meeting or exceeding business requirements based on these services becomes all the more complicated. The new services era calls for powerful architects who can define, govern, and adjust all of the necessary ingredients that they must creatively support and improve upon during a lifecycle over many years.
Who or what will step into this gulf between the traditional means of IT and the new cloud
ecology of services? These demands will be extended, of course, across different organizations and the requirements that they have.The architect's role, still a work in progress at many enterprises even today, may well become the key office where the buck stops in this era. What then should be the role and therefore the new opportunity for enterprise architects?
Here to help us lead the way in understanding that complex and dynamic issue set, we're joined by Tim Westbrock, managing director of EAdirections. Welcome, Tim.
Tim Westbrock: Thank you.
Gardner: We're also joined by Sandy Kemsley, an independent IT analyst and architect herself. Welcome.
We're also joined by John Gotze, international president for the Association of Enterprise Architects. Thank you, John.
Let me go to Tim first. What are you seeing as a general set of what we would now consider architects? What are they doing?
Two different kinds
Westbrock: On average, you have two different kinds of enterprise architects. One is a very
solution-oriented enterprise architect. They're ones that do try to keep the breadth of the enterprise in focus, but they are focused on individual solutions. They're focused on it holistically, meaning they're not just looking at a specific technology or a specific application.They're bringing that holistic advantage, but they tend to be less transformational. They tend to be driven by operational goals. They tend to be driven by immediacy. That is one of the biggest reasons that we don't have a lot of reuse, because of the lack of breadth at the solution layer.
The other one is still not in the main. The more strategic enterprise architects depend on the strategic nature of the executives of the organization. If we're going to bring it into layers of abstraction, they don't go more than a layer or two down from strategy. They tend to be the ones that do develop a community of practice that has solution architects involved in it. Their takeaway from that is the EA's perspective, and they have to take that down to the solution layer. That's what I see in the main today.
Gardner: Does that mean we're primarily dealing with tactical issues?
Westbrock: In the large, enterprise architects are still more tactically oriented.
Gardner: Sandy?
Sandy Kemsley: I absolutely agree, I see that a lot. I work a lot with companies to help them
implement business process management (BPM) solution, so I get involved in architecture things, because you're touching all parts of the organization then. As you say, Tim, a lot of very tactical solution architects are working on a particular project, but they're not thinking about the bigger picture.Gardner: John, it seems that the economy has focused people's attention at looking at the bigger picture. If you stay tactical, you can control and manage costs. You can manage complexity. You can't transform very well. How, in your perception, is this down economy and these new pressures, shifting this role?
John Gotze: Actually, it's helping to change the focus in EA from the more tactical to the more strategical issues. I've seen this downturn in the economy before. It's reinforcing the changes in the discipline, and EA is becoming more and more of a strategic effort in the enterprise.
There are some who call us enterprise architects by profession, and this group at The Open Group conference is primarily people who are practitioners as enterprise architects. But, the role of EA is widening, and, by and large, I would say the chief executive is also an enterprise architect, especially with the downturn.
Gardner: We saw some indications earlier that there is potentially a growth opportunity for these architects to report to the COO perhaps, rather than the CIO, the information officer. Tim, does that present to you sort of a harbinger of what you would expect?
Less technology-only focus
Westbrock: I was a little surprised to see that, quite honestly. Maybe it's because a lot of CIOs and CTOs report up through a CFO or COO. If you looked at that wording, it was "Ultimately, where does the EA report?" But, I don't see that a lot.
Combining this with a little of the answers to the last question, one of the good transformations, or evolutionary steps that I have seen in enterprise architects is less of a technology-only focus. Enterprise architect used to be synonymous with some kind of a technology architect, a platform architect, or a network architect, and now you are seeing broader enterprise architects.
I still don't think business architecture is within the domain of most IT enterprise architects. I think the economy, maybe -- external service providers, maybe. There are some different drivers that are getting some organizations to think more holistically about how the business operates.
That leads to modeling. Modeling means we need architects. We're getting involved in some of these more transformational elements, and because of that, need to look at the business. As that evolves more, you might see more business ownership of enterprise architects. I don't see it a lot right now.
Gardner: Okay. Sandy, we talked a little bit about the economic pressures, but this is
You also have to look at the authority. Who has responsibility for keeping the lights on -- for running the systems once they are in there?
happening in tandem with some other large technology trends: a greater emphasis on services orientation, more emphasis on governance, and trying to bring in services from a variety of sources.Looking at what should be core and internal and what might be outsourced or provisioned from a cloud environment, whether it's yours or someone else's or some combination, where does the authority shift from an IT department when we start bringing in these larger external organizations?
Kemsley: That's an interesting question. We do see a shift in terms of who has authority for making the architecture decisions. You also have to look at the authority. Who has responsibility for keeping the lights on -- for running the systems once they are in there?
In many of the companies that I work with -- and maybe this is just a Canadian perspective -- architecture, in many cases, means mostly IT architecture. There is this struggle between the IT architects and or the enterprise architects, who are really IT architects, looking at, how we need to bring things in from the cloud and how we need to make use of services outside.
But, as they speak to the IT masters, of course, they're vowing to have all of that come through IT, through the technology side. This puts a huge amount of overhead on it, both from a governance standpoint, but also from an operational standpoint. That's causing a lot of issues. If you don't get EA out of IT, you're going to have those issues as you start going outside the organization.
Gardner: So the authority, the governance, the managing, the decisions about which sourcing option should be ultimately pursued, does that just get shoehorned into IT? That doesn't sound like it's going to scale. John, where does this new office reside? Is it something that grows out of IT, or is it something that comes down from some other aspect of the organization at large?
IT won't disappear
Gotze: More the latter, I think, but the IT department will not disappear, of course. It's
naive to say that IT doesn't matter, as Nicholas Carr said many years ago. It's not the point that IT is irrelevant or anything, but it's the emphasis on the strategic benefits for the enterprise.The whole notion of business-IT alignment, as we saw in the survey here, is still the predominant emphasis and concern. I actually think that it's yesterday's concern, in the sense that business-IT alignment is really about capturing business needs and designing better IT. We've done that for 20, 30, 40 years now, and it's time to move on.
It's more about thinking about the coherent enterprise that everything should fit together. It's not just alignment. You can have perfectly well aligned systems and processes, without having a coherent enterprise. So, the focus basically must be on coherency in the enterprise.
Westbrock: I don't think that this is a new problem. If you look back to the late '80s and '90s, when there was a big boom in large outsourcing, the organizations that did well were ones that didn't make IT decisions about their outsourcers. They were ones that took what we were calling then "value chains" and said, "What are the parts of our value chain where we get a lot of value out? We need to invest internal resources more heavily." -- versus -- "What are more the commodity elements of our chain? That may be a place that we can have an outsourcer to take over."
The difference between '80s and '90s and now is that it's not a chain with seven big links. It's an intricate network with hundreds, if not thousands of pieces. Instead of there being 10 or 12 big, targeted vendors to help us, there is an infinite number of vendors. That adds complexity an element of governance that we need to mature towards.
Organizationally, we're probably okay. We're probably positioned okay to handle it. Where is
You're still going to do due diligence around who you're connecting to, but you don't have as many concerns about that as you do in the bad, old days of outsourcing.
that expertise going to come from? How are we going to capture which vendors that popped up this week are still going to be around next week? The longevity of these organizations is measured more in months than it is years.Kemsley: That's frightening for a lot of IT groups in large organizations. All of a sudden, they have all of these new vendors to deal with. They don't really know which ones are going to be around and which ones are not going to be around, and they don't know how to create the appropriate separation between the internal and the external.
If you get some governance in place, so that you can say, "Well, I can snap out this service and snap in another one, if that vendor goes out of business," then you don't worry as much.
You're still going to do due diligence around who you're connecting to, but you don't have as many concerns about that as you do in the bad, old days of outsourcing. This is still going on, where all of a sudden the whole business process goes out to somewhere else, or a huge piece of your infrastructure goes out somewhere else.
Gardner: Let's go back to the start of our discussion. There are so many different flavors of architects now -- different descriptions, different roles, different budgeting, and authority patterns.
When those architects start interfacing with architects at other organizations, if they have very different roles, are they going to be in that position of pulling this together? Does that really call for the need of a more general definition of this new-age architect? Anyone?
Levels of experience
Westbrock: This is an issue that we've been dealing with since the term EA started being used. I don't think that's changing any time soon. Right now, that's the nature of our "profession." I use the quotes on profession because there are several, very valid efforts to standardize the profession of enterprise architect. There are several certification efforts. There are several different levels of experience. There is not a common and consistent and unified approach to doing this.
We're going to have more standardization, more commonality, but right now, what I do, what I make a living at, is helping organizations figure out how they can be effective as enterprise architects. The reason I make a good living is because company A has to do different things to be effective as enterprise architects than company B does, than company C does, than company D does.
Gardner: Well then, will it not be architects that help combine the ways in which these organizations interface at a services level, or are we going to look for someone else to do that? John?
Gotze: Absolutely. There will be a lot of innovation in the discipline. There will also be a
If you're just consuming a service, as long as that service works the way it's supposed to and is there when you need it, you don't really get the architects to talk to each other.
standardization and certification, and so on. That will not go away. I hope not. I'm also certifying architecture. But, the strategic level of architecture is one where you must have an emphasis on innovation and diversity to make it work.Kemsley: I'm not sure I agree, because if you're looking in a cloud-services paradigm, you don't necessarily care about the architecture of the service provider. You care about the interfaces and the functionality of that service.
So, it really depends on whether you're talking about a partnership between two companies, where they are getting very much involved with each other, or whether you're really talking about consuming a service from someone. If you're just consuming a service, as long as that service works the way it's supposed to and is there when you need it, you don't really get the architects to talk to each other.
Gardner: We're getting quite a bit of additional role and responsibility thrown in, I suppose, when we think about the architect as starting to foster business transformation above and beyond the IT roles and some of the communication and collaboration issues.
But, if we talk about the more horizontal architecting of entire business processes among a variety of different service options, this is where we get caught between the organic "each company has to have its own definition for its business transformation," and then that more strategic, methodological standardized approach.
Are we going to look at this as a hybrid model, and there is no other way around it? John?
A hybrid model
Gotze: It will be some kind of hybrid model. Look at how government is working with it. They are enterprises after all -- it's not just a private sector. There's much more emphasis in government about getting all the agencies and departments to work together and to understand each other.
We just heard here from the Canadian government about the reference models and the excellent work they've done with the GSL, the strategic reference model.
That's really important. We have the same language and we understand each other across agencies. Who knows? There might be a new election tomorrow, and they'll reshape, reform, and reshuffle the agencies. So, you have to be agile also in that sense.
Westbrock: Since we're at a framework event, I'm going to relate it to frameworks a little bit. One of the steps that we need to take as a profession, from a framework standpoint, is to look at all four of the levels.
Traditionally, we have a business and information or data and an application or solutions and a
We're still decades away from any kind of maturity in the business architecture space, whether that be method, process, or organization.
technology or infrastructure layer. I think there is a lot of maturity and a lot of standardization in the technical frameworks that exist. If you look at different models, they might use different words, but they're all covering the same thing. The specific maturity that we need now is in the applications and the data spaces.We're still decades away from any kind of maturity in the business architecture space, whether that be method, process, or organization. But, we're now at the point where more standardization in the applications or solutions and the data or information layers is going to help us with this particular challenge that's facing enterprise architects.
Gardner: Let's take a question from the audience. The questioner asked, "I'm seeing companies getting lost in the complexities that you're describing. What are the attributes of people and organizations that are more successful at managing this?"
As you say, we've been through this before. It's sort of the peeling-the-onion approach, even as the external issues and variables change. Do we have any poster children to look at and say, "Aha, that’s how you do it?" Sandy?
Handling a complex world
Kemsley: I certainly see some characteristics with companies that I work with, some that work well and some that don’t work well. I don’t know if I've got any poster children to bring forward.
The ones that can handle this new world of complexity well are ones that can bring some of the older aspects of governance, because you still have to worry about the legacy systems and all of the things that you have internally. You're not going to throw that stuff away tomorrow and bring in some completely new architecture. But, you need to start bringing in these new ideas.
It's the ones who are starting to regenerate their architect community internally -- both with business architects and with architects on the IT side -- who can bring these ideas about cloud computing, different kinds of models, things like using business process modeling notation (BPMN) that can be done by the business architects and even business people, as opposed to having all of that type of work done in the IT area.
Gardner: John, any radical instances of success?
Gotze: I see some in the European context, because that’s the one I know the best. By and large, I agree with Sandy. It’s really how pervasive and embedded the architecture work is in the organization. The more you have enterprise architects and other architects living in ivory towers, the less success you have.
Some in the financial sector in Europe are doing quite well, even though the financial sector is
. . . we get a lot of energy, instantiate the processes, put the governance in place, build the models, do the transformations, and then we fall back on old habits.
not doing well as such. But, the survival strategies brought froward by the strategists and the architects are actually very valuable to the companies.Westbrock: People are looking for names, right? Prudential has done a really good job. National City Bank did a tremendous job right around the turn of the century. They were engaged in a very, wide-reaching transformational effort called The Bank of the 21st Century. They actually endorsed at a shareholder's meeting the role that EA would play in enabling the transformation to the banks of the 21st Century -- DuPont, Bank of America.
Here’s the funny thing, though. I've seen a lot of organizations that have reached a tremendous level of maturity and effectiveness with EA, due to a large SAP implementation or a strategic initiative like the transformation to The Bank of the 21st Century, but it doesn’t sustain. I can’t point to somebody who, on a consistent basis over 20 years, has done this well.
What happens is that we get a lot of energy, instantiate the processes, put the governance in place, build the models, do the transformations, and then we fall back on old habits. We don’t update the documentation. We forget the strategic imperatives. We get back down into the nitty-gritty. We're fixing bugs, and we lose sight of the big picture again.
Gardner: John, you wanted to add something?
Gotze: Just by way of example, I'd mention the Swiss-based Syngenta, which is in the field of producing seeds and stuff. So, for every tomato, or every fifth tomato, that you eat, they've made the seeds.
EA supporting science
It's an atypical business to be in for EA, but they're doing extraordinarily good work. There’s a lot of science in this, and how do you support science and research through architecture? They actually managed to do that by having very well functioning communities internally and a special way to get people to get the title of architect. They have about 2,000 architects, but not by title.
Gardner: From your responses, it sounds as if these are more the exception than the rule, and that even when they are the rule they can be fleeting.
Westbrock: I think this goes back to the expectations that the organization has of EA. I don’t think that the expectations for most enterprise architects are to enable business transformation. In most organizations that I deal with it’s to help with better solutions here and there. It’s to do some technology research and mash it up against business capabilities. It’s not this grand vision that I think most of us have as enterprise architects in the profession of what we can accomplish.
Kemsley: That’s right. They're there to bless the designs of a solution, but not to really do the big architectural picture.
Gardner: Here’s another question from our audience that addresses that. As we get towards that goal of business transformation, don’t you think that executives, as they become more aware that these opportunities exist, will want to then move in and take their role within that larger role. The technologists who come up as architects might get overtaken or usurped by more general business leadership or politics? Sandy?
Kemsley: I don’t see the business leadership clamoring to take over architecture anytime soon.
I think the executive leadership will want to take over the work that the strategic EA is doing. They might not call it EA, but they will be the ultimate architect.
In large part, it’s seen as being mostly an IT role. They just see it as part of IT. When you look at those survey results, it said that 60-70 percent of the architecture groups reported through to the CIO or the CTO. That’s how people think about it. It’s a piece of the IT department. So, you're not going to get the CEO coming in and saying on day one, "Oh, I want to takeover that architecture stuff."Gotze: I agree, but that’s also because we in the profession have managed to create a vocabulary that's nearly impossible-to-understand for people outside the profession.
I think the executive leadership will want to take over the work that the strategic EA is doing. They might not call it EA, but they will be the ultimate architect. The CEO is the ultimate chief architect for a forward-looking and an innovative enterprise.
Westbrock: I thought that question was going someplace else completely. I thought that question was going to say, "Once they realize what enterprise architects can do, are they going to be interested in taking advantage of it?" When I mentioned some of those examples of companies that have done this well, that’s what has happened. There’s been real relationship that exists between the EA teams -- it's not a person -- and the board.
The board members know the EA team at these organizations, because there is a relationship of partnering there. It didn’t start out that way. It started out with the EA team becoming aware of the vision, and they did that in interactions, but it was a one-way. It was, "What can we take from you, Board of Directors?
Two-way conversation
But, as they evolved their sets of artifacts and positioned those sets of artifacts to be communicable to executives rather than developers, they were able to communicate the strategic nature of what they're doing as enterprise architects. Then it became a two-way conversation.
Gardner: Well, whoever fills this role and from wherever they come within the organization, it’s going to be an extremely powerful role, if we follow through with what we've seen with globalization, outsourcing, business process issues, outsourcing an entire department, perhaps to an overseas organization.
What’s left of the enterprise but the architecture, the rules, the governance, the policies, if there are in fact all sorts of other organizations supporting the underlying services? So, doesn’t this role become something that should be board level role?
Kemsley: It should. We have to learn to use EA power for good, rather than evil, though. In a lot of cases, it’s just about implementation. It’s sort of downward looking. Enterprise architects tend to look down into the layers rather than, as Tim was saying, feed it back up to the layers above that.
How EA is perceived within the enterprise and how it presents itself needs a total makeover. It’s
When we talk to folks about the kinds of capabilities, skills, and credentials that they're looking for in enterprise architects, deep technical ability is nowhere on the list.
just so that people, especially the executives at the high level, the board members, and so on, can see the value and what this brings to them.Gardner: Well, saying they need a makeover is another way of saying there is a tremendous opportunity for an innovative promoter, to get involved and to pull some of these threads together, because there is a gulf or a vacuum.
Westbrock: When we talk to folks about the kinds of capabilities, skills, and credentials that they're looking for in enterprise architects, deep technical ability is nowhere on the list. It's not because that deep technical ability is not useful. It's because generally people that are performing those deep technical task lack the breadth of experience that make enterprise architects good.
They have that deep technical knowledge, because they've done that a long time. They've become experts in that silo. That's very, very much needed, which is why EA is a collaborative forum. The folks that are going to be called to function as enterprise architects are folks that need a much broader set of skills and experience.
Gotze: I agree. The deep technical skills will come way down the list. Communication is very high on the list -- understanding, contracting, and so on, because we have the cloud and similar stuff also very high on the list.
Career promotion path
Kemsley: But, it's being used as a career promotion path for people who start out in technology. It used to be, if you were like a programmer and you got to a certain level, it was like, "Well, we'll promote you. We'll make you project manager." Somebody who has no ability, no skills, and no experience to do that was given that as a title, because that was in the career path.
That's happening to some degree with architecture as well. You get to a certain level as a very deep technical person within an organization, and one of your career options is, "Well, you can move into architecture." It doesn't mean that somebody has the skills or even the inclination to do that, but that's the only way they can move up the chain.
Gotze: Then, if they're not competent, they move into management.
Gardner: Here's another question from the audience that says, "There are quite a number of anti-architecture forces in play, for perhaps a variety of reasons. Are they going to run out of gas?" Is there so much complexity with the economy, with source options, with this shift towards business transformation and efficiency of processes, when the organization does architecture well and receives the rewards and bears the fruit of that do the anti-architecture forces finally collapse? Any prophecies?
Kemsley: Well, they will, but it's dependent on that statement you said, "When architecture is done well." In many organizations, architecture is not done all that well. It's done on an ad hoc basis. It's done at more of the deep technical level. I can understand why the anti-architecture people get frustrated with that type of architecture, because it's not really EA.
Gardner: We see the need. We have the vision. They have the technical understanding of what
The folks that have been successful are the ones that take the time to do two things. They build artifacts and processes that work down, they build artifacts and processes that work up, and they realize that they're different.
IT is capable of. Are we talking about a lack of power and budget? What needs to happen?Westbrock: Quite honestly, it's our own fault. It's the way we talk about EA in the main. We don't talk about EA as a strategic enabler or as a translation of strategy into activities. We say alignment, but what does that mean?
The folks that have been successful are the ones that take the time to do two things. They build artifacts and processes that work down, they build artifacts and processes that work up, and they realize that they're different. You don't build an artifact for a developer and take that to a member of the board. You don't build project design review processes and then say, "Okay, we're going to apply that same process at the portfolio level or at the department level."
We don't have communication strategies that are going to facilitate the broadcast of results to the people that use the standards, and then use the same strategy and modes of communication for attaining strategic understanding of business drivers. It's really been a separation, knowing that there's a whole different set of languages and models and artifacts that we need here and a whole different set here.
Gardner: Here is another very interesting question from our audience. Is it too pessimistic to expect that cloud vendors will offer architecture as a service? In the past, we've seen that when there is a vacuum in a business, a consulting or outside opportunity for filling that comes in. Should we expect architecture to go in the same direction?
Not effective as a service
Kemsley: I'm not sure that's something you can really do effectively as a service. It's one thing to talk about a consulting service that helps you with architecture, offering it as a service in the way that a cloud vendor offers a service, I'm not sure that fits.
Gardner: First is the problem with the acronym.
Kemsley: That's true.
Gardner: John, you can't outsource it?
Gotze: I would never outsource my architecture. When I helped the Danish government in launching the national EA program, the top mantra was "Take home your architecture," the responsibility for the architecture. If Google, MSN, or whichever cloud vendors come out now and say, "Well, you don't have to bother with this architecture tricky stuff. Let us take care of it," we're back to a model from the '70s and the '80s, where we outsource everything and give the power to the vendor.
I strongly believe in architecture as a service, but that's an internal service, rather than ivory tower architecture or whatever. It's a service offered in the enterprise whenever it's needed.
Gardner: Tim, an alternative view?
Westbrock: I don't disagree with our esteemed colleagues here, but the question was whether
It's been proven time and again that it's not a great idea, but absolutely, there will continue to be architecture-as-a-service offerings.
we should expect it to be offered, and I think it already is.Gardner: How so?
Westbrock: It always has been. I used to work for a Big Six. I won't mention them by name, but I was, at one time, called an Android. It's not uncommon to find the architecture from the consulting group, from the vendor, a three-inch binder sitting on somebody's shelf. That was an attempt for an external service provider to do architecture for you. It's been proven time and again that it's not a great idea, but absolutely, there will continue to be architecture-as-a-service offerings.
Gardner: Do you want to respond to that -- perhaps not a service from the cloud, but a professional service capability?
Kemsley: Certainly, that will be done as a professional service. I don't know if that's the best way to do it. If you're really doing EA at the levels that it should be done, it's corporate strategy, and you don't outsource your corporate strategy.
Gotze: But, you can buy consultants that can help you in that. So, of course yes, it will be a service in the market.
Looking to the future
Gardner: Why don't we begin to wind down a little bit and take an opportunity to look to the future? I'm primarily interested in this opportunity that we're seeing with cloud. There's a tremendous amount of interest.
The business side of the house is wondering if this is going to cause them to be able to cut budgets, reduce the total cost as a percentage that they devote to IT, and, at the same time, give them what's generally referred to as better agility.
Sandy, this cloud thing, what's the impact, from your perspective, on the role and position of the enterprise architect?
Kemsley: There are a lot of different ways you can implement the cloud. The role of the enterprise architect is to look at how it comes in. One is to do something that totally bypasses IT. Salesforce.com is sort of ideal, where the business goes out and works directly with a cloud provider to give them a service that use to be provided by IT.
EA is certainly in a position to say, "Well, this is the best way to handle this sort of thing, to
EA is certainly in a position to say, "Well, this is the best way to handle this sort of thing, to outsource this particular functionality."
outsource this particular functionality."The second choice is, when you're looking at orchestrating business processes of various sorts, you need to call services. So, you've got a service-oriented architecture (SOA) together with some BPM. You want to look at calling services from the cloud. Then, it's almost like you're calling out to Google Maps, or you're calling to a variety of other services that might provide a discrete function within a piece of functionality there. That's pretty common and is going on. It doesn't even need to be addressed necessarily at an architectural level, but certainly the one where the business goes out.
What does happen, though, in many cases is that, this will still be done. It might start out as, "Let's look at doing things in the cloud and reducing our cost and so on." It ends up being a big IT outsourcing operation.
IT is still there and all they're doing is taking some big severs and moving them from one building to another building. It doesn't provide the kind of benefits that can be there. Again, that's something that's probably below, or could be below, the radar of what the architects are doing, except for network architects or solution architects, who are concerned with how all this gets wired together.
Gardner: John, impact of the cloud?
Incoherency and chaos
Gotze: There will be a huge impact, of course, and hopefully more than we see already. But, it has to be in the hands of someone, and that's a real tricky one. If it's just that line-of-business units go out and one contracts Salesforce and another contracts "whatever force," then we'll have incoherency and chaos.
My best bet or suggestion is to control the contracting and have the architects do the filtering on contracts. Of course, with free services, you cannot avoid people just choosing all of these services, but as long as it's something that cost money, you can control the budget. That's one way to sit on the decisions, but allow for innovation.
So, apart from the contracting, try to get the principles of the architecture as embedded as possible in the organization, so that people really understand that it's bloody stupid, if you are in government, to put personal, private data out in the cloud, if it's an insecure cloud. So, yeah, it's a challenge.
Gardner: Something to keep us busy for a while.
Gotze: Yeah.
Gardner: Tim?
Westbrock: There is a huge opportunity for enterprise architects relative to not just the cloud.
The cloud is just one more of the enablers of service orientation, not SOA, service orientation. Somebody needs to own the services portfolio.
The cloud is just one more of the enablers of service orientation, not SOA, service orientation. Somebody needs to own the services portfolio. Maybe we're going to call them the "Chief Services Architect." I don't know. But, what I see in so many organizations is service oriented infrastructure being controlled by one group, doing a good job of putting in place the kinds of foundational elements that we need to be able to do service orientation.Then, we see application development teams and groups figuring out which frameworks to use, where are we going to put the library, and they're building services and they're integrating services. What's missing is somebody with this portfolio, meaning holistic, enterprise-wide view of what services we need, what services we have, where we can go get other services -- basically the services portfolio. Enterprise architects are uniquely positioned to do that justice.
Gardner: Well, great. I want to thank our panelist for their tremendous and insightful input. We've been joined by Tim Westbrock, managing director of EAdirections. Thank you.
Westbrock: Thank you, Dana.
Gardner: Sandy Kemsley, independent IT analyst and architect. Thank you so much.
Kemsley: Thank you.
Gardner: And John Gotze, the international president of the Association for Enterprise Architects.
I also want to thank the audience for some really great questions.
I'm Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a BriefingsDirect special presentation from The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto. Thanks for listening, and come back next time.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.
Transcript of a BriefingsDirect sponsored podcast on the role of architecture within the enterprise. Recorded live at The Open Group's 23rd Enterprise Architecture Practitioners Conference in Toronto. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
