Impact of Cloud Computing on Enterprise Architecture

Download Impact of Cloud Computing on Enterprise Architecture

Post on 05-Jan-2016

32 views

Category:

Documents

2 download

Embed Size (px)

DESCRIPTION

Impact of Cloud Computing on Enterprise Architecture. Perspectives, Best Practices, & Pitfalls. David Bressler. @djbressler March 2009. Cultural Challenges. Data. Integration is hard. Expensive. Infrastructure. Data Integration. Adds meaning. Data Integration is hard. - PowerPoint PPT Presentation

TRANSCRIPT

<ul><li><p>Impact of Cloud Computing on Enterprise ArchitecturePerspectives, Best Practices, &amp; PitfallsDavid Bressler@djbresslerMarch 2009</p><p> 2008 Progress Software Corporation*</p><p>Cultural Challenges</p><p> 2008 Progress Software Corporation*</p><p>Integration is hardData</p><p> 2008 Progress Software Corporation*</p><p> Data Integration</p><p> 2008 Progress Software Corporation*</p><p>Data Integration is hard</p><p> 2008 Progress Software Corporation*</p><p> 2008 Progress Software Corporation*</p><p>Users are a pain, well install what comes out of the box, and thats what theyll get.Real Life PHB</p><p> 2008 Progress Software Corporation*</p><p>Financial &amp; Logistics Challenges</p><p> 2008 Progress Software Corporation*</p><p>Cost v. BenefitTime (Cost v. Benefit) </p><p> 2008 Progress Software Corporation*</p><p>Traditional Software PurchasePurchase softwareFind space in data centerSetup development &amp; testConfigure databasesMore </p><p> 2008 Progress Software Corporation*</p><p>The Easy WayGet a login</p><p> 2008 Progress Software Corporation*</p><p>Data Integration is hardCosts dont match benefits</p><p> 2008 Progress Software Corporation*</p><p>How do we make integration easier, and deliver benefits more quickly?</p><p> 2008 Progress Software Corporation*</p><p>Define Cloud Computing</p><p> 2008 Progress Software Corporation*</p><p>How do we make integration easier, and deliver benefits more quickly?Could computing is a way make integration easier, and deliver benefits more quickly</p><p> 2008 Progress Software Corporation*</p><p>Turn a commodity into a utilityintegration ^Necessary, but not differentiating</p><p> 2008 Progress Software Corporation*</p><p>Not everythings a commodity</p><p> 2008 Progress Software Corporation*</p><p>Web Server Farms. Commodity.</p><p> 2008 Progress Software Corporation*</p><p>Much Enterprise Software. Commodity</p><p> 2008 Progress Software Corporation*</p><p>Email. A commodity.</p><p> 2008 Progress Software Corporation*</p><p>Messaging. Maybe not a commodity.</p><p> 2008 Progress Software Corporation*</p><p>What if we just gave IT a platform to create their own data models, interfaces, and processes on a dynamic infrastructure [that met corporate requirements] &amp; simply existed as needed?</p><p> 2008 Progress Software Corporation*</p><p>Results in elevated IT relevance</p><p> 2008 Progress Software Corporation*</p><p>Other ResultsFocus on integration will evolve to a more disciplined approachMatch expenses to benefitsEnable new classes of applications</p><p> 2008 Progress Software Corporation*</p><p>Best Practices</p><p> 2008 Progress Software Corporation*</p><p>Mediation. A secret weapon.</p><p> 2008 Progress Software Corporation*</p><p>Service Level Management. Dont even start with my piece is working fine!</p><p> 2008 Progress Software Corporation*</p><p>Security. Its not (only) what you think it needs to be.</p><p> 2008 Progress Software Corporation*</p><p>Make mistakes.</p><p> 2008 Progress Software Corporation*</p><p>Build a culture of collaboration.</p><p> 2008 Progress Software Corporation*</p><p>Map out a strategy. Reward innovation. Reward relevance.</p><p> 2008 Progress Software Corporation*</p><p> 2008 Progress Software Corporation*</p><p>David Bressler bressler@progress.com http://blogs.progress.com @djbressler</p><p>*Infrastructure Integration includes networks, servers, app servers, data bases, web servers, and in my mind, even application installation. </p><p>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</p><p>*This is the POINT behind all the infrastructure integration efforts. If not for teasing out information about our data in a way thats usable, we wouldnt do any of the other stuff. The other stuff is just necessary evil. Its 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, youll see some neat stuff.*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, its harder to do that with off-the-shelf software to the extent that its needed!*Whats scary is, Ive actually heard this for real!</p><p>Explain why I have this as a cultural challenge. Integration is so frustrating, non technical people dont 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 dont know what you need to do until you start. Regular managers who hear waffling have a reaction to ask more questions. And, Im not sure what well 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 dont know what were doing. Often, a response I hear if we give more specifics Didnt we do that already well, yeah, but for the other stuff. why cant we use their stuff? Well, because none of this interoperates.**Its Data integration thats hard (and expensive). And, importantly, its hard to explain to others, so they discount it. *This is really less of a definition, and more of putting an edge around a concept. And, that edge doesnt fully surround the concept, only it gives it some shape. *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*Of course, Ive still not defined anything. Just trying to put some parameters around it. I defined integration earlier, now Im saying turn commodity integration (defined as necessary, but not differentiating) into a utility.*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.*Not talking about ESB- or inter-app style messaging. Im 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 its very very basic integration that doesnt 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 cant 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.</p><p>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. Its not just about Master Data Management, and having a uniform customer record (thats hard too), but it is about having a view on my relationship with the customer so I can make better business decisions.**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 whats important.</p><p>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.*This is really less of a definition, and more of putting an edge around a concept. And, that edge doesnt fully surround the concept, only it gives it some shape. *Visibility, protect from change, service level management.*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 theyd want a refund. However, the network people were bonused on network uptime, not on middleware uptime, so they didnt 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 wasnt working from their perspective. This is a hard problem, least so with respect to technology.*Security needs to change to application or message layer security. Today we rely too heavily upon network layer efforts, and frankly, its just not secure enough. We know that, but its hard to change. I believe this resistance to change will hinder cloud efforts.*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 whos 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 youve learned to evaluate a commercial solution (if thats the direction you want to go). Its a much cheaper approach, and the risk is much much lower because you become an educated consumer before spending a ton of money.**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.</p><p>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. Theyll never be committed when they just understand what. Technical people like what and we let them because we usually cant understand the why.***</p></li></ul>

Recommended

View more >