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.

Bashing EAI

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

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

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

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

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

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.