The Road to Enterprise Cloud Computing
I'm at a company that has a number of fairly high traffic web sites. Essentially, there is a holding company that does the "IT Stuff" and there are a number of brands that we support. Problem is, all these brands want the same sort of stuff, but just slightly differently. For example, they all want a store locater, they all want to search for things by categories and attributes, they all want a movie player, new/blog service...
Historically, we'd get the request for a "rewrite" of a brand site. We'd spin up a project, start copy/pasting code from other sites and assemble a fresh new application from the pieces of the old ones.
This is good, we're at least reusing some things instead of simply recoding everything from scratch.... but, it's also bad. Why? Because we're creating independent copies of code that does the exact same thing (see copy/paste coding).
Our previous solution to this problem was to not really update anything after it's been released. Sure, we'd put some new imagery out there, but for the most part it was one for one swaps of things that where already there. In addition, if we DID decide to create a component, it was done via server integration. This meant that... sure we've got a jar file or dll that is a reusable runtime component, but we STILL needed to redeploy any updates across every site that needed it.
We've made an adjustment and are now going down a different path. We're now developing shared services that are URL addressable and can be linked into individual web pages by front-end developers (similar to google maps)
Our initial results are very positive, we've tried this out and have been able to reuse (at runtime) a service that folks have been clamoring for across the enterprise. Instead of copying a bunch of files from server to server, we embedded a bit of javascript in a web site and tada! we now have this new bit of functionality in other web sites.
This is modeled after how google maps allows you to embed a map in your browser. This is where the big money is to be made (or saved) for enterprise cloud computing and/or Service Oriented Architectures (SOA). Extract stand-alone services out so that they can be URL addressable and enable your front end teams to assemble novel and useful applications from a grab-bag of components that are available via the net.
For example, if I need a store locater service... I should be able to embed a link to a piece of javascript and have a store locater in my site. This can and should be done on the front end with no copying of files whatsoever. The back end server gnomes should be building these services... not necessarily so they can interact with each other (traditional SOA focus), but so that they can enable specific functionality in the enterprise.
So, SOA/ESB/ECC folks... stop worrying about creating monstrous infrastructure projects that may never yield results and start thinking about how to enable your enterprise developers to be more productive. For example, if you are a company of any size and you have a corporate hierarchy... build a service for the next project that needs "corporate hierarchy browse" that is completely stand-alone and anyone can use with only a one-line javascript link. Don't worry about Service busses, SOA blueprints, SOAP, ESB, other great big boondoggles being foisted on you by "arm chair architects". Worry about stuff that people need and use every day and make that really easy.
Historically, we'd get the request for a "rewrite" of a brand site. We'd spin up a project, start copy/pasting code from other sites and assemble a fresh new application from the pieces of the old ones.
This is good, we're at least reusing some things instead of simply recoding everything from scratch.... but, it's also bad. Why? Because we're creating independent copies of code that does the exact same thing (see copy/paste coding).
Our previous solution to this problem was to not really update anything after it's been released. Sure, we'd put some new imagery out there, but for the most part it was one for one swaps of things that where already there. In addition, if we DID decide to create a component, it was done via server integration. This meant that... sure we've got a jar file or dll that is a reusable runtime component, but we STILL needed to redeploy any updates across every site that needed it.
We've made an adjustment and are now going down a different path. We're now developing shared services that are URL addressable and can be linked into individual web pages by front-end developers (similar to google maps)
Our initial results are very positive, we've tried this out and have been able to reuse (at runtime) a service that folks have been clamoring for across the enterprise. Instead of copying a bunch of files from server to server, we embedded a bit of javascript in a web site and tada! we now have this new bit of functionality in other web sites.
This is modeled after how google maps allows you to embed a map in your browser. This is where the big money is to be made (or saved) for enterprise cloud computing and/or Service Oriented Architectures (SOA). Extract stand-alone services out so that they can be URL addressable and enable your front end teams to assemble novel and useful applications from a grab-bag of components that are available via the net.
For example, if I need a store locater service... I should be able to embed a link to a piece of javascript and have a store locater in my site. This can and should be done on the front end with no copying of files whatsoever. The back end server gnomes should be building these services... not necessarily so they can interact with each other (traditional SOA focus), but so that they can enable specific functionality in the enterprise.
So, SOA/ESB/ECC folks... stop worrying about creating monstrous infrastructure projects that may never yield results and start thinking about how to enable your enterprise developers to be more productive. For example, if you are a company of any size and you have a corporate hierarchy... build a service for the next project that needs "corporate hierarchy browse" that is completely stand-alone and anyone can use with only a one-line javascript link. Don't worry about Service busses, SOA blueprints, SOAP, ESB, other great big boondoggles being foisted on you by "arm chair architects". Worry about stuff that people need and use every day and make that really easy.
Comments