The Rise of The Cloud

There is an interesting read over at eWeek on what McDonald's is doing in the cloud.  Okay so I know most of you don't think of flexibility and IBM toolsets in the same sentence but that's what the article is about(Just joking IBM, you have very nice tools).  I was more interested in this quote in the article from an IT Manager at McDonald's:

“McDonald’s is a hamburger company; we don’t want to be in the IT business,” Farnum said. “We want to focus on what we do best.

What seems to be a simple and obvious statement is not at all what it appears.   How many IT managers can walk down the line and directly tie their employees day to day activities with what the company is trying to achieve?  How many employees are constantly on thought, what am I doing today to help make better X and sale more X?

By now some of the more astute of you are trying to figure out the blog title and how it is related to this post.  The rise of the cloud has surfaced an ugly truth within some IT departments.  There are a fair number of IT employees if not whole departments engaged in simple self preservation in response to the rise of the cloud.  The irony in this is that they should be doing just the opposite.  You know how Anakin went to the dark side in order to save Padme but that very act is what caused her death, it's just like that.

The cloud if used correctly can provide the IT department with the tools to be the responsive agile group it's business partner so desperately wants it to be.  There are a few basic things one should know before embarking on this journey.  I'm not going to cover the hard stuff, you'll have to figure those out for yourself just like I did, have fun.

-First thing, it's a journey you have to take.  If you ignore the cloud you will be consumed by lava and forced into a life on the dark side.  Seriously don't let your business users get out ahead of you, they will create a mess and leave you behind in the process.

-Don't ignore and take for granted your data privacy policies.  The big cloud guys are likely to be more secure than you but don't take their word for it.  Understand the issues, know what you can and cannot let into the cloud.

-Don't just try and port your crappy architecture into the cloud.  Ha Ha I know you don't have crappy architecture but seriously there are ways of doing stuff in the cloud that will let you take advantage of all that elasticity.  Moving your applications/infrastructure to the cloud doesn't relieve you of understanding the architecture, be sure to know what is going on behind the curtain.

-Don't be afraid, remember fear is the path to the dark side.  I took a cloud development class a while back for a certain vendor and was amazed at how many developers would not sign up for the free account. Microsoft's Azure, Amazon, Salesforce (if you want to try some SaaS) all have developer programs that will cost you nothing to next to nothing.  Jump in and try it out.

Get out in front of this and make your IT department the hero of the business and not the slow moving self-preserving Luddite.

The Cloud Architect

David Linthicum had a very good post over on InfoWorld about cloud architects versus enterprise architects. I'm summarizing David but in a nutshell the article is about the need for SOA skills to be a cloud architect. While I totally agree with the need for SOA skills in the cloud space, I think cloud architecture may encompass more than one type of architect.

The uber architect generally just doesn't exist in corporate IT. There generally is a conglomerate of architects that make up the "virtual" uber architect for a corporate IT shop. The cloud really expands on this need because of the different areas of expertise needed in more detail i.e. security, infrastructure and SOA (for sure). Let's also throw in parallel computing for kicks and grins so that we can take advantage of the potential elastic nature of compute nodes. A SOA Architect would have the best chance of having most of the skills in various levels of depth but I think finding all of these in one architect is going to be difficult. SOA itself requires a broad range of skills difficult to find in one person.

Remember the ICC? Integration Competency Center. I'm seeing a future for the CCC or C3 (Cloud Competency Center). In all seriousness it's going to take several architects to screw in the cloud powered light bulb.

End-Users Are Getting Smarter

We know that the end-user is getting smarter. The exposure to computing and applications at a very early age is at an all time high. That knowledge brings different expectations.

Image by Free-StockPhotos.com

The question becomes how does the modern IT shop deal with this? The answer is drum roll please ...... Cloud Computing. Ha just kidding with you. The answer is actually there isn't any one answer.

The issues facing the modern IT shop due to the increasing intelligence of the average end-user are multifaceted. There are data issues, security issues, interaction issues, privacy issues, usage issues, maintainability issues and the list goes on. Certainly some of the traditional ways of dealing with these issues will still apply but I think new ways of thinking are needed for the "IT Shop" to stay relevant.

First it's important to understand that we are dealing with evolution and not revolution. The evolution we are discussing is happening but not overnight. This is not a dinosaur extinction event yet. Here are a few thoughts on not only survival but on thriving as an IT community.

-IT quit using the term "the business". I cringe every time I hear someone in "IT" say "the business" wants this or "the business" needs that. You are the business, start acting like it.

-End-users aren't dumb, stop treating them that way. Talk to them, listen when they speak and realize you are all in the same boat wanting the same thing.

-Waterfall is dead, it was hit by an asteroid. Stop trying to use it and move on for Pete's sake.

-Cloud computing is for real but it's not for everything. Learn how to leverage it for the right things and make sure your end-users aren't leveraging for the wrong things.

-In a complete contradiction to the above suggestion, you will almost certainly lose control of your data at some point. Figure out how to deal with that eventuality.

-Social networking is not only not going to go away it's going to get a lot bigger. The key point here is that it really doesn't matter whether you get it or not, the end-users do and they are going to want more of it. Learn to deal with it least you become a target of that asteroid.

-Security has to move out of the I hate to have to deal with security to being at the forefront of all things. End-users even though smart have to be educated even more on data security.

-IT Developers, you going to hate this but you are more valuable the less code you write. Learn about SOA, embrace reuse. Learn and use tools that help you achieve this. There are jobs out there for code jockeys but the IT shop generally isn't it anymore.

The modern end-user is smart and very comfortable with technology. To keep up the "IT Shop" must embrace this.

Cloud Stuff - Did you get the source code?

David Linthicum's recent post on cloud providers dropping either user sites or applications reminded me of the old vendor source code negotiations. The basic premise is before purchasing a really expensive piece of software you got the vendor to agree to give you the source code in the event they go out of business. This was suppose to alleviate some of the fears of the big check that was about to be written. The vendor goes out of business you still have working software plus the source code(No I don't know what you would do with it).

The cloud has changed the game. Not only do you not get the source code, the vendor can turn you off in an instance leaving you with no working software at all. As David points out, getting vendors to sign SLAs that help you more than them is pretty tough. This obviously is cause for concern with a lot of IT organizations consider moving applications, services and infrastructure to the cloud. Of course there are tons of ways to mediate all of this and still take advantage of what the cloud has to offer. Things such as SOA, Governance, EA and even the old EAI(Practice not the platform) standby all still apply when designing for the cloud(location independence takes on a more significant role).

The take home message is get out in front and don't throw good architecture practices out the window because there is something shiny and new out there. The cloud demands your architecture be more sound than ever.

The Future of IT

ZapThink has an interesting article out on the looming Enterprise App Vendor Crisis. The article is really a continuation of several thoughts that ZapThink has on the state of the IT organization and its role in the modern business world. The overall underlying theme is that IT organizations are undergoing a major change that will result in a substantially different appearance in the next few years.

The article offer a lot of insightful and rational points in its trek back to 2004 and back to present day. For those of us who work in "The IT Shop" I think we can see the reality of the predictions in small doses. It's probably a reasonable assumption to make that most understand these type of predictions are generally made with a broad stroke. There are literally thousands of IT shops and businesses so sweeping generalizations must be applied when making predictions.

One issue I think most analysts have is that they generally are interacting with the facade layer of a given organization. The guts of an organization and how it really operates is generally hidden from external view. Of course this is a generalization as well on my part but I think a fairly valid one based upon my experiences. This really isn't the fault of the analyst.

There are a significant number of analyst engagements that are initiated by senior level staff within either the IT group or a line of business within an organization. The reasons can vary for these engagements but a common theme is usually checking your direction/thoughts on strategy, projects etc with that of an expert(s) external to your organization. It's really not a bad idea when you think about it however the problem develops in your presentation of yourself.

This leads us back to our external analysts. Analyst engage and work with an organization based on a highly filtered view of that organization. Organizations just like the people that work in them tend to present themselves in a very favorable light. ZapThink's predictions resonate with me and have logical progression. The issue I think is that the predictions are based upon a state that in most cases is actually not known.

IT still has a very bright future in the modern business world. It will change over time as ZapThink suggest but that rate of change will be much slower and will probably fork off the predicted path many times just as evolution tends to do.

Random Thoughts on Enterprise Architecture

Enterprise Architecture (EA) is getting a lot of press lately some of which is good and some not so good. There seems to be a lot of disagreement on what EA is and isn't. There is also disagreement on the value of EA. I'm not attempting to address either of those items just jotting down some observations as I monitor these conversations.

-How come it take so long for us IT folks to get a definition of something locked down? SOA, Cloud Computing, EA all are still debated on simple definition. This just serves to confuse others and generally hurts the overall progress.

-EA is evolving into distinct camps: Traditional EA which is IT based and heavy on the frameworks, business based which wants to evolve EA into the entire enterprise with IT just another component of that and a hybrid camp which is trying to bridge the gap.

-All of the EA discussions appear to still be IT based. I haven't seen a lot of business leaders jumping into the discussions. Some IT folks want to evolve EA beyond IT but have the business folks bought into that? Are the business schools focused in or have any discussions on EA at all?

-To much focus on the EA Frameworks can hurt the overall effort of EA. EA's become paper pushers and not architects.

Those are some random thoughts/observations I had while monitoring these ongoing EA conversations. The scope of EA seems to be the most hotly debated. EA is obviously focused on the business but at what level? I think that one is going to be tough to answer without business leaders joining in the conversation.

Software Quality

A few thoughts on software quality which seems to be a topic coming up more frequently these days. The first I'm throwing out there is software quality can be a fairly complex topic so a simple blog post is not going to attempt to do it justice. The next thought is software quality means different things to different businesses or organizations. The expectations of the space shuttle crew of their software is different from the folks who need an internal web page to track office supplies. Although it may seem like the folks who need the web page are in fact launching a space shuttle, that is not the case and the same rigor cannot and should not be applied.

Two areas in particular that I'm ranting a bit about are SOA and Agile(as in the development methodology). I read this post over at CIO.com on the issues that SOA and Agile bring out when it comes to software quality. I'm going to answer the question it's posing up front - no SOA and Agile do not lead to crappy business agility. I think most would agree that have had successful practices established around SOA or used the Agile development methodology correctly that the end result are more agile applications.

Organizations that skimmed the service of SOA or Agile could have implemented complete disasters for software. Does that make SOA or Agile the culprit? I think not and in fact I think those same organizations would struggle within any architecture or methodology. SOA and Agile don't shed the traditional principals of good software development practices, they simply enhance them to insure business needs are met in a timely manner. Like any architecture or development methodology if implemented incorrectly SOA or Agile can lead to bad results. If you have any thoughts on why SOA or Agile in particular lead to poor quality software, I'm all ears.

CERN Discovers "God Particle"

And its name is Fred and lives in Topeka, Kansas. Happy April Fools.

Upcoming Topics - The Cloud, SOA Revisted, and Open Source Updates

I know it’s been a while since I’ve posted anything.  It’s been a crazy few months for me with work.  There are several topics I’m going to be covering in more depth over the next month or so. 

 

The Cloud – I’ve been giving a lot of thought to this topic especially from what I call a practical in the trenches kind of viewpoint.  There is a ton of hype around “The Cloud” out in the media world right now.  Making practical sense of all the hype can be a bit challenging.  Heck just getting folks to agree on what “The Cloud” is has proven to be challenging.

 

SOA – Not to beat this horse to death but I hope to share some more practical experience from what I have found to actually work.  One thing to throw out there is that we have made this subject much more complex that it has to be.  Again this is real world experience not just talk.

 

Open Source – No secret that I’m a big fan of open source software although not for some of the “traditional” reasons.  I hope to share some insight on a comparison I’m doing with Microsoft’s new MVC framework compared to some open source ways of doing the similar thing such as CakePHP.  Yes I know Microsoft has “open sourced” the MVC framework but I think you will get the point when I get more into it.

 

That’s what I’m thinking about right now so hope to have more in-depth discussions soon.  Stay tuned.

SOAP vs REST

Okay it's a bait and switch tactic. I'm not going to attempt to answer the SOAP vs REST question. It just degenerates into a religious war and ultimately serves no point. IBM's recent announcement about more REST in its Websphere product line prompted some conversation about it.

It probably doesn't really matter which way you go but I do think there are a few points that need clearing up and some further explanation. First there is this comment I got off of Joe McKendrick's post about it (Believe the comment is from Lorain Lawson) -

"However, IBM’s growing support of REST is “too promising to ignore.” That’s because the REST architectural approach opens up the door to potentially stronger SOA deployments – “with easier integration and more reuse of services (read: more agile) than you’ll get from an SOA built on an ESBs or the SOAP-based WS-*.”"

That really hasn't been my experience. I think when a comment like that is made more explanation as to why that might be true should be given. SOAP style Web Services are actually pretty easy to work with in most cases. REST has easier integration? More reuse? Why would that be? How many folks when using SOAP style Web Services have to worry about or get into the details of SOAP? How about REST style? Little more involved isn't it?

Easier integration? REST lends itself to more tightly coupled integration especially in the wrong hands. That's not the intent of the REST style architecture but I think it lends itself to that. I think developers will read about REST and end up just embedding URL's every where and call it REST. The end result is a mess. That's kind of what a lot of folks did when SOAP based Web Services came out. It turned out to be just a bunch of tightly coupled RPC calls.

The REST style of architecture is not bad but there is little tooling for it which means working with raw less than structured data. Most toolsets/platforms present SOAP style Web Services as just another class to the developer. REST proponents might say this is bad and they probably would not be to fond of ORM frameworks as well. That's not an incorrect view just different which is okay.

Another quote from Joe's post (Again from Lorian) -

"“it’s unlikely IBM’s shift to REST will settle the whole REST versus SOAP debate, since SOAP has a heavyweight of its own: Microsoft and its popular SharePoint.”"

Microsoft has REST embedded pretty well with their WCF framework which is part of .Net Framework 3.5. Not a big deal but Microsoft has obviously not ignored REST.

I'm personally not against the REST style of architecture. My issues have always been the way it's presented. Simple, easy to do, it's just the web right? No it's not and the web by the way is not an example of REST architecture contrary to popular belief. Go forth and get some REST or use some SOAP, it really doesn't matter just know what you are getting into.