The Grey Lines

The Rise of The Cloud

2011-06-28T21:20:00.000-04:00

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

2011-03-22T19:08:00.000-04:00

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

2010-12-30T10:12:00.003-05:00

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?

2010-12-21T20:01:00.000-05:00

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

2010-11-29T08:31:00.002-05:00

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

2010-08-18T08:00:00.001-04:00

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

2010-04-29T21:22:00.001-04:00

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"

2010-04-01T08:42:00.000-04:00

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

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

2010-02-19T15:38:00.001-05:00

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

2009-11-29T19:32:00.001-05:00

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.

Bashing EAI

2009-10-26T21:04:00.000-04:00

A bit of EAI bashing going on these days. I suspect a lot of people, myself included, who have successfully implemented an EAI style of architecture are probably scratching their heads going hmm what did I do so wrong? Answer: nothing.

SOA is the latest new kid on the block (actually Cloud Computing is but we are not going there) so the natural tendency is to bash everything that came before it. The practice of EAI had and does contain a ton of good architectural principles. Those are being thrown out and replaced with the notion that EAI and it's evolution the ESB style of architecture are all about products and not architecture. It's simply not true.

Don't get me wrong, SOA is a very good thing. My issue is the stark contrast being drawn between it and EAI. Yes there are differences but they share more in common that is being explained by the bashers. Abstraction, loose coupling, common data types, composibility, discovery and yes even standards all existed in the EAI world.

EAI, ESB's, SOA and even Cloud Computing all have their place in the modern enterprise. Understand your architecture which means what works and what doesn't, evolve where needed but don't throw your successful practices out with the bath water because of the latest buzz.

S0A-Manifesto

2009-10-26T11:15:00.002-04:00

A group of very smart and respected folks have put together a SOA-Manifesto. You can find the Manifesto - http://www.soa-manifesto.com/ . Overall it's pretty high-level stuff but good stuff. I have one big issue however with one of the principles. "Intrinsic interoperability over custom integration". If just glanced at it sounds like something that makes sense but the devil is in the details.

Intrinsic means in this context that services using some sort of standards should do the talking between your existing applications versus doing "custom integration". This concept is going to be confusing to an average IT shop. The question will arise what's the difference between putting in a service and putting in a custom integration solution? How do I get to the last mile of the interface with a third party application? Or do you mean my services should contain all the business logic? But isn't that custom because you had to write it? Standards based stuff is fine but it's still custom if you have to write the service. Sounds like a lot of academic semantics I know but I think its important to understand some important principles.

Unless your entire business portfolio is going to be made up of custom services that you write then you are going to have to do some integration. It's just the nature of most businesses. My problem with "Intrinsic interoperability" is that I believe it will lead to a spaghetti set of custom integrations. The very thing it was trying to avoid. Custom is custom. In other words if you didn't buy it then it's custom. Whether it's "standards based" or not has no bearing on whether it's custom or not or whether it becomes spaghetti or not. I think well defined distributed services that have "Intrinsic interoperability" are going to be beyond the grasp of a lot of IT shops both to develop and certainly to maintain/govern. If you are going that route be sure to go over to Todd Biske's site - http://www.biske.com/blog/ and study up on governance (Going to need governance regardless, but for distributed "Intrinsic interoperability" you really going to need it).

Ultimately I believe the "Intrinsic interoperability" piece was put in to kind steer folks away from ESB's and the older EAI model of integration. While I understand this from a pure academic view, I think in the actual wild it has issues. It has the same issues that ESB's and EAI had because of lack of understanding of the methodology that went along with successful implementations.

Overall the SOA-Manifesto is a good set of guiding principles. Having a set of principles like this that everyone in the organization understands and embraces can go a long way to developing and maintaining a successful SOA style of architecture.

Windows 7

2009-10-23T10:49:00.001-04:00

I upgraded to Windows 7 on my laptop yesterday. Overall the upgrade went smooth but it was time consuming (About 3 hours, of course I have a lot of stuff on my laptop). I think the average home user will probably not upgrade to Windows 7 but rather acquire it through a new PC purchase. That's probably a good thing for the end user.

Here are few things I noticed during the upgrade. The first thing that jumped out is that the upgrade process is still not geared towards the average end user. The upgrade process is going to do a compatibility check before allowing the upgrade to proceed. If it finds things that are not compatible it's going to ask you to uninstall them. While not an issue for an IT person like myself, I suspect an average home user is now confused. Especially when it asks you to uninstall your wireless network card. I did like the fact that it tells you iTunes is probably not going to work correctly anymore. Nice marketing play there Microsoft. Of course it works fine after the upgrade.

On the positive side, Windows 7 takes up less memory and runs a bit faster. On the downside they got rid of their little built in mail client which is a bummer. I liked that client, really don't like web mail interfaces, sorry Google but I like to work disconnected sometimes. Plus I don't like a million things on my screen other than the email when I working on email. I know there are a million email clients out there to be had but I liked that one, it was simple and efficient.

It did detect all my hardware and configure it correctly which is a step up from the past. The interface is clean and seems to be pretty logical. Overall I'd give Windows 7 a thumbs up. I'll post back any observations as I get more accustomed to it in the coming weeks.

The Value of Enterprise Architecture

2009-10-04T08:01:00.004-04:00

It's always kind of interesting when you have to explain and justify what seems like common sense. But like SOA, Enterprise Architecture seems to need constant justification and explanation. Why is that? Is it because we make what should be fairly straightforward concepts overly complicated? I tend to think so. Take a look at many of the EA frameworks available and your eyes will probably roll back in your head and you will lose consciousness.

I think keeping things simple tend to lead to more success. A major medical institution that will go unnamed spent millions of dollars on an automated medical scrubs dispensing system. It was going to save lots of money, folks wouldn't be allowed to take home and keep extra scrubs. After installing and testing the system, all things were go. Unfortunately there was one major flaw, a human being still had to load the machines each day with the clean scrubs.

As you might imagine, scrub machine loader is not the top end of the job spectrum. Scrubs are not one size fits all and each machine was responsible for dispensing the correct sizes. You can see this train wreck coming yes? After only a few months and tired of not ever being able to get the right size of scrubs, the employees figured out how to defeat the machines and keep out more scrubs than was suppose to be allocated. Millions spent and nothing gained.

When I was a young Army officer many years ago, I learned a very valuable lesson. Everyone needs to understand the mission. And by understanding it I mean be able to execute it. It seems like common sense doesn't it? If the leader becomes unable to perform his or her duties it falls to the next in line to carry out the mission.

In my simple world EA is also very simple. Define the destination, show everyone how to get there and then help them along the way to make sure they stay on course. Of course the downside to simplicity is that things don't tend to fail in such a grandiose way like when they are over engineered and over architected. Still it is important to realize that simplicity is not easy to achieve. Complex systems tend to form naturally.

Ultimately I think one of the keys to achieving simplicity is constant vigilance. How you get this working state of vigilance is the topic of another post. The hint is, there is not one answer for all.

Life as a Corporate Software Developer and Architect

2009-08-24T18:10:00.002-04:00

I really haven't had time to blog lately just to busy to be completely honest. Being responsible for numerous development projects, by responsible I mean design, develop and deploy, has really placed an interesting challenge out there for my other assignment which is architecture. One of the benefits with working in a small software shop is the requirement for lots of hands on, one of the disadvantages is the requirement for lots of hands on.

Small software shops don't have the luxury of dedicated architects. Multiple roles have to be assumed in order to meet all the demands. Of course the big benefit I think is more usable and realistic architecture which tends to come from this type of environment. At any rate I hope to have some more technical post out here sometime in the near future as time permits.

Random Musings on Software Architecture

2009-07-24T14:39:00.002-04:00

Many many years ago I was a young Army executive officer(XO) in a tank company doing some training at Ft. Bragg, North Carolina. My CO and I were conducting some tactical training exercises for our tank crews. We were using parachute signal flares to signal the tanks to do certain things during the exercise. As luck would have it one of the flares came down on what appeared to be a small patch of grass several hundred yards away from our position. We saw some smoke rising from the patch of grass but we chose to ignore it and continue with the exercises. To make a long story short, the small patch of grass was actually much bigger than we thought. We spent the next several hours in 95 degree heat putting out the rather large fire (We had no water, only shovels).

Software architecture in the corporate IT landscape is very much like the small grass fire that turns into a very real wildfire. We tend to either ignore it completely or over indulge it. Neither of which is very good for the primary business and usually gets out of control pretty fast. There is a delicate balancing act that has to occur on a daily basis in a corporate IT shop. The needs of business have to be met. There really isn't any arguing with that. It's how you meet those needs that is the question.

There really isn't a one size fits all answer to that question. Despite opinions coming from analyst, bloggers(including myself) and others, there isn't one correct way. What works for each individual organization is going to vary. Finding the middle path which balances good enough architecture with the dynamic needs of the business is really the key. These are the two two questions you should be asking in my opinion; Am I delivering the value to the business that the business wants? Is my architecture or lack there of negatively impacting the business? If you are delivering the value, by the businesses measurement not yours, and your architecture is not causing issues for the business then you probably have found the middle path.

The last piece of advice is do not ignore the small smoking grass fires.

Bernard Madoff

2009-07-14T18:16:00.002-04:00

Ah my claim to fame. I'm originally from Butner, a small town in central North Carolina. Welcome Bernie!

Oracle 11g

2009-07-04T07:01:00.002-04:00

Oracle just recently announced it's 11g monster. Here is Joe McKendrick's take on it. My take is that it's great for consultants, there will be lots of money to be made trying to implement this beast. It's bad news for companies trying to implement it.

The corporate IT mantra is keep it simple, keep it quick and deliver a lot of value to the business. There is nothing simple about 11g and with the Sun acquisition things will only get more complex.

SOI and A Very Dead Horse

2009-06-22T19:31:00.002-04:00

ZapThink put this out on SOI(Service Oriented Integration). We kind of have been beating this horse to death for a while but after reading the article I see we are still not completely there yet. This question in particular got me -

is SOA's purpose to solve integration problems, or is it more of a business transformation approach centered on implementing agile business processes?

I go back to this post - http://www.thegreylines.net/2009/01/soa-versus-soi-continued.html . Agile business processes? How exactly would you do that without bringing systems together (integration)? You would pretty much just have to have the one system. Anybody work in enterprises like that? We are not talking about moving data from point a to point b, again see previous post.

Designing Services in the SOA World

2009-06-04T17:46:00.002-04:00

The Grumpy Architect has appeared and apparently it's Brenda Michelson. What's making Brenda so grumpy? The state of software design especially as it relates to services. I'm not going to rehash the great points Brenda makes, please go read her post it's loaded with goodness.

I don't think there is any one reason why the state of service design is where it's at. Here are a few of the causes in my opinion:

*It's not taught or emphasized in CS programs. That's a generalization of course because some programs do but if you do a quick survey of undergraduate CS programs you will find very little emphasis on it. It does show up more in the grad level programs.

*We are to tool centric. We judge someone's competence in software design by how well they know the platform or tool. Give me someone who understands abstraction and loose coupling over someone who knows ever class in the .Net framework any day but produces 8000 line methods.

*The business, the business, the business. Don't underestimate the extreme demands placed on corporate software developers to churn stuff out. Developers and their managers take what they perceive to be the easy way out in order to meet the demands. That environment is very difficult to work in sometimes and the software design is usually what suffers.

*Time and motivation. Well if you didn't get it in school, you now have to learn it on the job. Some folks are self starters and some are not. Mentors and architects can help but they can only do so much.

*Short-sighted. Designing brittle, difficult to maintain and ultimately unsustainable software is actually really easy. We do tend to take the easy path.

I think one of the issues with the current state of SOA is that a lot of folks made the assumption that developers understood all of this and the software side of SOA was going to be the easy part. If you worked in a corporate IT environment you know nothing could be further from the truth. I have noticed especially in the past year that the amount of available information on the technical side of SOA is finally starting to catch up with the hype.

Larry at JavaOne

2009-06-03T12:26:00.001-04:00

And so the long arduous process of Oracle messing up another acquisition begins - http://www.theserverside.com/news/thread.tss?thread_id=54827

Seriously, he's really focused on JavaFX?

MVC

2009-05-08T06:53:00.002-04:00

In addition to my webMethods stuff, I've being doing a fair amount of .Net stuff lately. I decided to run through the new MVC framework tutorial from Microsoft just to see their new take on this old pattern. The tutorial is located here.

I must give props to folks over at the ASP.NET web site. They have done a very nice job with the content on MVC. This particular tutorial was very straightforward and explained MVC very well. If you are inclined to check it out pay particular attention to section 4 on abstraction and loose coupling. That is really good stuff. This section is written in terms of OO concepts but they apply as well to the services world. Thomas Erl explains some of the differences between OO and services here and here if you want more detail.

MVC has long been a highly regarded pattern in the user interface world. The interesting thing is this same pattern with some modification can be used in the SOA world even when GUIs are not involved. The Service Facade pattern as explained here by Thomas Erl is closely related in concept to MVC. There are differences but I think you will see the overlap and the potential of MVC in the services world.

I think one of the biggest mistakes some developers and architects make when jumping into the SOA world is to wrap existing stuff in a standards based interface and then go at it directly. While there is really nothing wrong with wrapping existing stuff in a standard based interface, invoking it directly is another issue. Spending some time with the Facade pattern and MVC can pay off in a more agile and resilient set of services. I have personally found that the associated overhead of these extra layers of abstraction are minimal and well worth the small cost.

Rob Eamon has also gone through some MVC content and has posted his thoughts on the Nerd Dinner walk through on his blog. Check that out when you get the chance.

Oracle to buy Sun

2009-04-20T08:21:00.001-04:00

Not nearly as a good idea as the IBM purchase. Here is the link - http://www.wral.com/business/story/4985700/

Cloud Computing and Trust

2009-04-07T06:16:00.002-04:00

For me one of the biggest hurdles for cloud computing is trust. I read this post recently from Jonathan Schwartz's blog over at Sun on cloud computing. One thing that jumped out at me was the little graphic Jonathan posted from OpenOffice. The graphic showed file manager from an OpenOffice beta and its ability to "save to the cloud". Looked pretty cool right? But then I thought, what would I save there?

Jonathan's graphic of OpenOffice is nothing new. Google has been doing this a while with Google Docs and so have many others albeit not on the scale of Google. I have used Google Docs to store documents and spreadsheets but I have never put anything out there that I would consider sensitive. It's a trust issue and a privacy issue. In fact a lot of companies even block that kind of thing through firewalls and proxies for just that reason.

Cloud computing is obviously a lot more than just a big document repository I used for an example. However, the trust issue which is mainly a perception issue in my mind will have to be overcome to allow cloud computing to reach the potential others are touting. I also believe smaller sized business will be more likely to take the perceived risk than the bigger ones. What do you think? Are you ready to start using the public clouds for business critical sensitive information?

Sun and IBM Continue to Court

2009-04-02T19:12:00.001-04:00

Sun and IBM are continuing to dance according to the latest news.