Community Roundtable: Architecture, Confidence, and the Cloud

I hesitate to say this because when anything first comes out, it's going to be the Holy Grail. It's going solve everyone's problems. But I have a lot of hope for cloud from a couple of perspectives.

As I see people migrating to the cloud, I see more and more people creating enterprise architectures and creating what they call Centers of Excellence. They're saying, "This is going to be the Center of Excellence. Our data center is going to have HP Blades, this type of database, this type of app server. If you're going to move your departmental system into the cloud, you got to adhere to this." In a way, it's a forced march, but I think a lot of times you need a forced march, because if you have each department controlling their enterprise, and you have an enterprise architecture for each department, they're going to continue to use whatever vendor gives them the biggest Christmas gift, or whatever is the flavor of the day.

I hold out a lot of hope that cloud will cause companies to have Centers of Excellence, and have enterprise-level architectures, as opposed to fragmentation.

Pat, as an Enterprise Architect, do you think that the cloud lends even greater emphasis to the need for an enterprise-wide architecture?

Absolutely! The fundamental question is, are you going to have a private cloud or a public cloud? The decision you make affects people's jobs. It affects how data is accessed. Even that first fundamental question you ask yourself has such wide impact on your organization, that absolutely, it's critical. From that point on you've got to build the Enterprise Architecture around that approach and understand how things are going to move from your private data center into a public cloud, because it's going to take time. You're just not going to do it one day.

Or vice versa. Maybe some things, over time, might move back down from a public cloud. I'm working with one customer right now who's going to move some of their stuff into a public cloud, for now, for an initial implementation. But then at a certain point, when they get their maturity up to snuff in certain areas, they want to be able to bring it back down. The Enterprise Architecture development, the whole cycle of building your architecture around the strategy, what you need to do make it happen, to govern this, to make sure it stays on the rails, becomes more important than ever.

I would have to think, also, that an enterprise perspective on this has to be absolutely critical because at a basic level, we're talking about service orientation. If cloud is an extension of that idea—that the benefit of service orientation is that as you deploy services that can be used across silos—you're talking about reuse. Old story, still valid.

But a whole new level. Because I think what you're talking about is the traditional thought of a service. You call it and it does something for you, and great. But in this case, the service can be elevated all the way up to something like we do with Amazon Cloud. It might be the allocation of an entire environment. That's a service.

Right! That's what fascinates me about not just the idea of service orientation, but especially as this expands into the cloud. You have all these aaS's. Platform as a Service. Infrastructure as a Service. Software as a Service. This all relates back to a very old discussion of software reuse. It all comes back to the idea that you're reusing something. The chunks of what we're reusing have gotten bigger and more complex. But it's still the same process.

If you have a service, you want it to be as widely used as possible. You want to avoid duplication of that service. Again, all the more reason to have some sort of broader, big-picture sense of architecture that guides what you do. It guides how you move forward, so that you can avoid the idea that you may have individual silos within an organization that are creating and deploying duplicate services when that duplication is completely unnecessary.

For my company, cloud is a little bit off the architecture right now because of the privacy concerns, because we deal with a lot of children's data. We try to explore what we can do, but so far we are realizing that we couldn't move towards the cloud at this point.

Tom, from that perspective, based on Karina's concerns, does that make a case for private cloud?

Private cloud or hybrid cloud. The US government is one of the biggest adopters of the cloud. Now, it's not a pure public cloud they're going to, it's more of a private cloud or a hybrid cloud. But I think that with privacy and security concerns, it's going to be hard for big institutions to move to a pure public cloud, like Amazon, or Salesforce.com.

That being said, the cloud has been around since the 1960s. The mainframe with a TSL interface was the original cloud because it was one big shared service. If you take a look at every major bank in the world, they're running on a mainframe that might not be a public cloud, but in a lot of cases, it's private cloud or hybrid cloud that they're running on.

Yes, and the one that will be really, really secure will probably cost a lot of money for us. So we have optimized what we can do and what we cannot do with the current resources. For now, we've decided that we'll stay the way we are. We are exploring Cloud, and we'll eventually, definitely move in that direction because that's the future. It's much easier, and as you've said, there's no duplication. In our case, we really don't want to duplicate what we are doing. But we're still in the exploring process.

Something that I was thinking about, and that kind of concerns me, is that infrastructure in clouds becomes very opaque and you don't really know, or maybe you don't even care, what's running underneath the service that's provided. You don't really have any insight or control into securing it properly. You have to really rely on that the service provider takes the required steps to secure the system as much as it can, that updates are being installed and applied.

If you look at a virtual machine in the cloud environment, it runs an operating system underneath that needs to be properly updated and patched. I think this becomes more and more complex, the more stuff is being moved into the Cloud. That's an area where I'm a bit worried and concerned about how things will evolve.

I don't know if you folks saw the story about Global Payments, one of the largest credit card processors in the country. I don't know if it's been made public in the press, but I know the service provider that runs them. That's a good example of what you just mentioned, that the security is only as good as what the service provider is providing.

In that case, obviously the service provider had a big flaw there. It's not just across one customer. Global Payment services payments for thousands of banks, it impacts every bank out there.

So, Cloud-based services—in the vernacular of reuse—are black box assets. You have a way to tap into it to make use of that service, but as Lenz pointed out, you don't always have any insight into what's inside the box. You use it. You hope it works. But you have to take it on faith that it's going to work, and particularly with regard to security, you need some assurances.

This relates back to a conversation that arose during a group discussion at one of the Architect Day events, the idea of a cloud computing prenup. So that before you enter into a relationship with a Cloud service provider, you better know what you're getting into and you better know how to get out of it.

Particularly the exporting of data. Data information is really one of your key assets. If you rely on a single service provider that uses proprietary applications that only he is capable of maintaining, you might not be able to get your data out and migrate it to something else, if you're not careful.

Yes, which actually brings to mind one case I heard about maybe about six or seven months ago, when one company decided to part with the Cloud, and all they got back were the TXT files. All the data was dumped into the TXT files. That's all they got. Then they spent a lot of money trying to put those data back into some appropriate format so they could become usable again.

Guess what? That all should have been identified as part of the data portion of the Enterprise Architecture. That's the danger of doing these quick departmental one-offs—"Let's do this new technology and this new approach." If it's done outside the scope of the big boxes, the capabilities, and the big planning, then that's the kind of thing you're going to get.

Exactly! Yes, you're right. "Let's do it. Let's see how it works and then figure out how to get out of it."

Then it comes back around and someone says, "Wait a minute, who approved this thing?" Then it's: "Well, we didn't really look at it from the security viewpoint." Why didn't you? That should have been part of the Enterprise Architecture.

So maybe having a definition of what kind of data export format you get, or what possibilities, in general, you have for getting your data back should be part of any agreement you have with a Cloud provider.

Yes! To tie this to the idea of a prenup, I ran into a customer eight months ago, one of the largest insurance companies in the country, and they're bringing everything in-house. They're moving from sort of a hybrid public cloud, bringing everything in-house into a private cloud.

They had a lot of agreements in place that they could get the data out, but of course, the vendor doesn't want to lose them, so they're just dragging their feet. So they'll print an output file and it doesn't have all the data. Then they say, "Oh, yeah, we screwed up. Give us another couple more months." Unfortunately, I think you need to be very specific about when and how you'll get your data, because this company is struggling with potentially not getting all of their data for maybe three years.

This actually brings up another question. To create that type of an agreement, you really have to know what kind of questions to ask. Because yes, the agreement can be in place, but how would you know what questions to ask? It really has to be thought through at every possible point. What if the data format changes during those two years while we're still there with the Cloud? It brings up the real level of the qualifications of the people asking those questions and preparing those agreements. It really needs a very special type of person who combines business intelligence with the technical intelligence.

It sounds like we're also talking about someone with a legal background.

There is a new opportunity for IT professionals who have the IT background, a degree in computer science and a law degree.

[Laughing] I think we have a business opportunity! Let's start a company!

Great! Okay, any attorneys out there, here's your next opportunity. Start picking the brains of your friends in IT, and then hang your shingle out, and start writing prenuptial agreements that will govern the relationship between cloud service providers and cloud service consumers.

That's a great point. Like Karina said, you've got to understand what data is coming back. But also to Tom's point, there are legal contracts that need to be in place that go way beyond just technical shaking of hands, or protocols, or things like that. When you set up the Cloud, there is a lot riding on it, and you need to be ready to have all those expectations legally formatted, and to allow time for those legal proceedings to occur. There is a lot involved here and it's not as simple as one might think.

But in the end, isn't this scaring people off from migrating to the cloud? Isn't this a reason for them to think otherwise? Or, is this another reason that might drive people to consider migrating to private clouds, rather than completely discarding the idea of migrating to the Cloud, so that they control both ends of the relationship?

It may be the latter. I think people do realize that there is value in using the developments and technologies available with Cloud Computing for their data centers. But, yes, it may make, especially larger corporations, hesitant or maybe scared off of being too enthusiastic. They don't want to be an early adopter who gets burned by something like this.

But, under the weight of these concerns, if organizations elect to move into private clouds, does it then follow that after achieving some success, after seeing how this works in the private cloud, wouldn't that then make them a bit more amendable to branching out into a public cloud for certain elements of their IT infrastructure?

If private cloud is successful for them, yes, I think they will consider it. But, again, most people haven't had much chance to get any experience with the Cloud. It's still a very new technology. It's not something that people know for sure, like mainframe. People know mainframe works because it's been around for 40 years.

I see companies who are very hesitant even to consider moving from, or supplementing, mainframes with something else because this technology, despite the fact that it's very old, is working. It's delivering. It produces considerably fewer errors than any other technology.

So with all this in mind—and Tom, as the cloud guy here, I'll direct this to you, at least initially—What would be a great argument, a great case, for an organization to move into the public cloud? What kind of an argument could you make that would make that really attractive to them at this point? Under what circumstances would that be really attractive for them?

I don't know if this answers your question, but prior to you even asking that question, I was going to say that for most companies that are moving to the public cloud, the people in charge are the bean counters. The people that are making technology decisions are the people that control the budget from a business perspective.

If it's the CFO, and they want to move from a CAPEX to OPEX expensing, and they want to save some initial costs, and they don't really care about security or being locked in, all they see are dollar signs. I think those are the people that are really driving it. I don't see a lot of CTOs and technical people saying, "Oh, let's move to the public cloud." When you talk to business people, they're more enamored with the public cloud because they see it as, "I don't have to buy this hardware anymore. I don't knave to amortize this software cost. I don't have to deal with 50 different software vendors and different hardware vendors."

If you wanted to really sell the cloud, I think the people that are really interested in the public cloud are the business users and the financial people. To the point about the mainframe, business users don't care if the system is running on a mainframe, an AS400, a VAX. They don't really care. "Can I log in, and can I get my data, and can I get it in a timely fashion?" That's all they care about.

So we're back to that black box idea, that as long as it works, I don't care what's in the box.

Yes.