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.

 

 

 

 

Bernard Madoff

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

Oracle 11g

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

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

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

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

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.