1 / 33

Impact of Cloud Computing on Enterprise Architecture

maura
Download Presentation

Impact of Cloud Computing on Enterprise Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Impact of Cloud Computing on Enterprise Architecture Perspectives, Best Practices, & Pitfalls

    3. Infrastructure Integration includes networks, servers, app servers, data bases, web servers, and in my mind, even application installation. These are well defined, usually have their own staff… and they take up a large part of budget/effort, but because they are visible, for the most part, they are accounted for (time-wise). Unfortunately, as we all know, this is just the “setup”… next, you have the magic… The magic of DATA integration Infrastructure Integration includes networks, servers, app servers, data bases, web servers, and in my mind, even application installation. These are well defined, usually have their own staff… and they take up a large part of budget/effort, but because they are visible, for the most part, they are accounted for (time-wise). Unfortunately, as we all know, this is just the “setup”… next, you have the magic… The magic of DATA integration

    4. This is the POINT behind all the infrastructure integration efforts. If not for teasing out information about our data in a way that’s usable, we wouldn’t do any of the other stuff. The other stuff is just necessary evil. It’s the boat ride you have to take to the dive site… it might make you queasy, but you can deal with it because once you get there, you’ll see some neat stuff.This is the POINT behind all the infrastructure integration efforts. If not for teasing out information about our data in a way that’s usable, we wouldn’t do any of the other stuff. The other stuff is just necessary evil. It’s the boat ride you have to take to the dive site… it might make you queasy, but you can deal with it because once you get there, you’ll see some neat stuff.

    6. Whereas with infrastructure integration, where you can point at a server, or even a database, and say, it needs to be configured, it needs to be integrated with my environment, it’s harder to do that with off-the-shelf software… to the extent that it’s needed!Whereas with infrastructure integration, where you can point at a server, or even a database, and say, it needs to be configured, it needs to be integrated with my environment, it’s harder to do that with off-the-shelf software… to the extent that it’s needed!

    7. What’s scary is, I’ve actually heard this for real! Explain why I have this as a cultural challenge. Integration is so frustrating, non technical people don’t want to hear about it. Worse, they hear about servers, databases, etc… and have quantifiable and well understood explanations of what needs to be done (I need to create tables, add IP addresses, etc), but when it comes to integration, you often don’t know what you need to do until you start. Regular managers who hear “waffling” have a reaction to ask more questions. And, “I’m not sure what we’ll find, but if we budget two weeks, I know we can most likely solve it” is NOT a good answer. Makes us sound like we don’t know what we’re doing. Often, a response I hear if we give more specifics… “Didn’t we do that already” – well, yeah, but for the other stuff. “why can’t we use their stuff?” “Well, because none of this interoperates.”What’s scary is, I’ve actually heard this for real! Explain why I have this as a cultural challenge. Integration is so frustrating, non technical people don’t want to hear about it. Worse, they hear about servers, databases, etc… and have quantifiable and well understood explanations of what needs to be done (I need to create tables, add IP addresses, etc), but when it comes to integration, you often don’t know what you need to do until you start. Regular managers who hear “waffling” have a reaction to ask more questions. And, “I’m not sure what we’ll find, but if we budget two weeks, I know we can most likely solve it” is NOT a good answer. Makes us sound like we don’t know what we’re doing. Often, a response I hear if we give more specifics… “Didn’t we do that already” – well, yeah, but for the other stuff. “why can’t we use their stuff?” “Well, because none of this interoperates.”

    9.

    10. Traditional Software Purchase

    11. The Easy Way

    12. It’s Data integration that’s hard (and expensive). And, importantly, it’s hard to explain to others, so they discount it. It’s Data integration that’s hard (and expensive). And, importantly, it’s hard to explain to others, so they discount it.

    14. This is really less of a definition, and more of putting an edge around a concept. And, that edge doesn’t fully surround the concept, only it gives it some shape. This is really less of a definition, and more of putting an edge around a concept. And, that edge doesn’t fully surround the concept, only it gives it some shape.

    15. This is not really a definition, but it does help keep our eyes on the prize and measure the success we have with it. I prefer to think of it as…This is not really a definition, but it does help keep our eyes on the prize and measure the success we have with it. I prefer to think of it as…

    16. Of course, I’ve still not defined anything. Just trying to put some parameters around it. I defined integration earlier, now I’m saying turn commodity integration (defined as necessary, but not differentiating) into a utility.Of course, I’ve still not defined anything. Just trying to put some parameters around it. I defined integration earlier, now I’m saying turn commodity integration (defined as necessary, but not differentiating) into a utility.

    20. Talk about thinking outside the box. If email is commodity, everything below it in the infrastructure stack is too. And, of course, this is a great example, in some cases, perhaps email is not a commodity. Perhaps there are some Outlook customizations for sales force automation, ACT plugins or whatever, that makes email a tool instead of a commodity. But, even then, it illustrates the point… using salesforce.com, and email, you want to bring that information together. The more you can do that… the more relevant IT will be. Yet, when each app is a closed silo, where the efforts are on integration rather than connectivity, it becomes a real challenge to leverage the cross-app data and relationships.Talk about thinking outside the box. If email is commodity, everything below it in the infrastructure stack is too. And, of course, this is a great example, in some cases, perhaps email is not a commodity. Perhaps there are some Outlook customizations for sales force automation, ACT plugins or whatever, that makes email a tool instead of a commodity. But, even then, it illustrates the point… using salesforce.com, and email, you want to bring that information together. The more you can do that… the more relevant IT will be. Yet, when each app is a closed silo, where the efforts are on integration rather than connectivity, it becomes a real challenge to leverage the cross-app data and relationships.

    21. Not talking about ESB- or inter-app style messaging. I’m talking about email messaging. There are messages that are part of the conversation everywhere. But they lose context in email. Yeah, maybe there is a link back to relevant information, but it’s very very basic integration that doesn’t even server technical users well. We want to bring information together. Best example I can think of, however trivial, are those silly facebook messages that say “you have an email” but, I can’t respond, I need to go to facebook and respond. I have messages all over the place, there is no reason why Facebook, LinkedIn, Twitter, Email, Progress, and all these places have different places where I have to go and bring this information together manually. Now, this (messaging) is maybe not important to my enterprise, but other similar things are. How about, customer information. There is customer information all over the place, in the sales force automation system, in the provisioning system, in shipping, maybe in contracts administration, etc. Maybe in multiple places. It’s not just about Master Data Management, and having a uniform customer record (that’s hard too), but it is about having a view on my relationship with the customer so I can make better business decisions.Not talking about ESB- or inter-app style messaging. I’m talking about email messaging. There are messages that are part of the conversation everywhere. But they lose context in email. Yeah, maybe there is a link back to relevant information, but it’s very very basic integration that doesn’t even server technical users well. We want to bring information together. Best example I can think of, however trivial, are those silly facebook messages that say “you have an email” but, I can’t respond, I need to go to facebook and respond. I have messages all over the place, there is no reason why Facebook, LinkedIn, Twitter, Email, Progress, and all these places have different places where I have to go and bring this information together manually. Now, this (messaging) is maybe not important to my enterprise, but other similar things are. How about, customer information. There is customer information all over the place, in the sales force automation system, in the provisioning system, in shipping, maybe in contracts administration, etc. Maybe in multiple places. It’s not just about Master Data Management, and having a uniform customer record (that’s hard too), but it is about having a view on my relationship with the customer so I can make better business decisions.

    24. Other Results… If all IT does is integrate (data and processes), it will have to become more disciplined, and there will be time to do so. I believe clouds help us get rid of the low level things IT focus on, to help us raise the bar and focus on what’s important. New classes of applications: Really more mashup-like, rapidly created, possibly with short lifespans, that help users synthesize and visualize relevant data and events so they can better execute the business. Data is no longer locked into the silo. In fact, silos simply disappear and we have a full federation of services.If all IT does is integrate (data and processes), it will have to become more disciplined, and there will be time to do so. I believe clouds help us get rid of the low level things IT focus on, to help us raise the bar and focus on what’s important. New classes of applications: Really more mashup-like, rapidly created, possibly with short lifespans, that help users synthesize and visualize relevant data and events so they can better execute the business. Data is no longer locked into the silo. In fact, silos simply disappear and we have a full federation of services.

    25. This is really less of a definition, and more of putting an edge around a concept. And, that edge doesn’t fully surround the concept, only it gives it some shape. This is really less of a definition, and more of putting an edge around a concept. And, that edge doesn’t fully surround the concept, only it gives it some shape.

    26. Visibility, protect from change, service level management.Visibility, protect from change, service level management.

    27. When I was working at Radianz, I was responsible for delivering a middleware layer on top of a shared network. Forget the technology. One of the big problems was around culture and contracts. If the network was up, but the middleware service was down, it was down from the customer perspective, and they’d want a refund. However, the network people were bonused on network uptime, not on middleware uptime, so they didn’t look at it the same way. Then, our customer support needed to be trained not to say “well, the network is up” to the customer, why would the customer care? It wasn’t working from their perspective. This is a hard problem, least so with respect to technology.When I was working at Radianz, I was responsible for delivering a middleware layer on top of a shared network. Forget the technology. One of the big problems was around culture and contracts. If the network was up, but the middleware service was down, it was down from the customer perspective, and they’d want a refund. However, the network people were bonused on network uptime, not on middleware uptime, so they didn’t look at it the same way. Then, our customer support needed to be trained not to say “well, the network is up” to the customer, why would the customer care? It wasn’t working from their perspective. This is a hard problem, least so with respect to technology.

    28. Security needs to change to application or message layer security. Today we rely too heavily upon network layer efforts, and frankly, it’s just not secure enough. We know that, but it’s hard to change. I believe this resistance to change will hinder cloud efforts.Security needs to change to application or message layer security. Today we rely too heavily upon network layer efforts, and frankly, it’s just not secure enough. We know that, but it’s hard to change. I believe this resistance to change will hinder cloud efforts.

    29. Caution does not mean eliminating mistakes. Also, with less invested upfront, mistakes are much easier to recover from. At least you have learned something. Personally, I wonder why a company who’s never used an ESB before would even consider a commercial ESB. Use an open source one, learn about what makes it good/bad, then use what you’ve learned to evaluate a commercial solution (if that’s the direction you want to go). It’s a much cheaper approach, and the risk is much much lower because you become an educated consumer before spending a ton of money.Caution does not mean eliminating mistakes. Also, with less invested upfront, mistakes are much easier to recover from. At least you have learned something. Personally, I wonder why a company who’s never used an ESB before would even consider a commercial ESB. Use an open source one, learn about what makes it good/bad, then use what you’ve learned to evaluate a commercial solution (if that’s the direction you want to go). It’s a much cheaper approach, and the risk is much much lower because you become an educated consumer before spending a ton of money.

    31. Reward relevance… figure out a way to reward those who collaborate with the business and deliver results. Measure these things, and track them. Build excitement. Training people on how to do something, is not the same as training them to sell it. This is the same internally – you MUST help people understand why this change is important, and help them feel a part of it. They’ll never be committed when they just understand what. Technical people like “what” and we let them because we usually can’t understand the “why.”Reward relevance… figure out a way to reward those who collaborate with the business and deliver results. Measure these things, and track them. Build excitement. Training people on how to do something, is not the same as training them to sell it. This is the same internally – you MUST help people understand why this change is important, and help them feel a part of it. They’ll never be committed when they just understand what. Technical people like “what” and we let them because we usually can’t understand the “why.”

More Related