Friday, December 29, 2006

2007 Predictions

I promised last week to post some predictions for 2007.

Here goes . . .

  1. Even the day coders will run screaming from WS-*. The battle is won; we night coders killed it because we didn't want to be controlled by vendor-pires and it is fundamentally flawed technology. Sadly, even though I believe that it is dead, it will take 2 more years before the industry echo chamber comes to terms with it. Software vendors who are heavily invested in WS-* will spend 2007 doing two things: one last gasp at making WS-* happen and quietly writing their Plan B MRDs.
  2. REST usage will increase in lieu of WS-*, but it won't unseat messaging and other middleware.
  3. People will settle down a tad about Ajax. It's great and all, but I've been seeing more and more botched impls. Like just about everything, its just a tool not a dogma.
  4. XML will finally be considered one tool in the tool chest just like every other technology. Development teams will only use XML where it actually adds value and not force it into places where it does not belong.
  5. The virtualization march will continue.
  6. Distributed Cache and JavaSpace usage will accelerate as more people grok the power of this architecture style.
  7. Apache River will breathe new life into Jini/JavaSpaces. Both will see lots of new interest and implementations. 2007 will be a "rebuilding year" (as they say in sports) - 2008 will be the big year for a Jini/JavaSpaces come back. Someone from Sun will formally apologize to all the people maimed by J2EE in 2009 and acknowledge that they should have marketed Jini as a service technology from the beginning (ok just kidding that isn't going to happen).
  8. The Open Source patent war will begin in earnest.
  9. Community Source Software will slowly start to take off in industry verticals as more executives grok the possibilities and come to terms with the fact that they are already sharing industry vertical software with their competitors; they just don't have access or any control of the source code. Look for a success or two in 2007 which will set the stage for a pandemic by 2009.
  10. Even more smart people will start blogs or at least start reading blogs which result in even more transparency and open collaboration between software vendors, customers, and consultants and ultimately better software, more innovation, and less waste.
Alright, that is all I have . . . mostly just a bunch of blather, sorry. I am very excited about 2007. Should be an exciting year to say the least.

Thursday, December 28, 2006

SBA & EDA Lessons Learned

I am still getting my head around SBA (Space Based Architecture)/distributed caching patterns.

I have a ways to go, but the more I read about it (blogs, docs, specs, etc.), talk about it with my insanely smart co-workers, and do stuff with it (hands on) the more I like it.

Like most humans, my mind works quickest when I can associate concepts. As I have mentioned before, I see a lot of parallels between SBA and EDA - specifically Message-Centric EDA. Last Spring, I did a series on lessons learned from an implementation of what I consider Message-Centric EDA. I'm going to pick out a few notable differences that I have noticed so far that makes SBA extremely appealing to me.

  1. Content Based Routing
    Content Based Routing, Itinerary Based Routing, any service orchestration you can think of other than frightening things like BPM/BPEL are all achievable with SBA. And its done by using the state of your objects, not Topics, XML and all the complexity and angst that comes with it.
  2. Choose Topics over Queues
    SBA wins hands down. Instead of mapping your system into using Hierarchical Topic Names including event types and states you put objects into the space and the state of the objects drives the service orchestration (take, notify, etc.). It's insanely simple. This eliminates 2 mappings: system state to Hierarchical Topic Names and Object to XML (and back). In a large system, this results in heaps and heaps of complexity eliminated.
  3. Persistence
    No XML shredding in SBA, the space fits the transient data solution I mentioned. It can be configured to be persistent/reliable & in some implementations mirrored, clustered, etc. Getting relational databases out of the transient state business is great for simplicity / flexibility / maintainability / scalability. Again, one less mapping to deal with - only persist to long term storage at well defined states (again based on your objects, not a serialized XML version of them).

SBA basically turns messaging patterns upside down. The patterns are similar, just simpler in SBA. At first look, the SBA versions seem better. Perhaps the grass is greener, perhaps not.

The right answer is probably all of the above / both SBA and EDA. The really hard part is figuring out where to use which in building loosely coupled cohesive systems.

Update 29-DEC-2006 I was inspired thinking about this further on the walk to work this morning . . . I mention complexity and mapping above. Things like object to XML (and back) (OX), system state to hierarchical Topic names (and back), object to relational db (OR), Object to XML (Castor, JAXB, etc.), XML to relational db (XML shredding). Why do you care about all this? I'll tell you why you do. Not having this cruft in your system results in:

  1. Hundreds of conversations and meetings that you will not have sorting this mapping out
  2. Many design decisions / design details you won't care about
  3. Thousands of unit tests you won't write
  4. Hundreds of defects that you won't file, ponder, fix, and unit test

Update 07-FEB-2007 Appeasing the "then" vs. "than" police.

Update 22-JUL-2007 As this page is linked to from a Wikipedia page on Space Based Architecture, and gets a fair amount of referrals, I think that I have a responsibility to temper my original comments with what I believe today. I continue to have high hopes for Tuple Spaces, JavaSpaces, and SBA. In my opinion, however, there are not enough viable alternatives today. This is very important to me. I am watching with great interest what will happen with Apache River prior to making any further investment in this technology.

Apache River

Apache River is a new Apache podling (incubated project).

This should be fun to watch.

2007 is going to be fun I think.

"River" is a good enough name - I like it, but then again, I love rivers

Powerbook Rot

Jon Udell complains about Powerbook Rot.

Sadly, I have experienced the same thing with mine.

I drive mine pretty hard because, well, it's a laptop. And my 20 month old daughter pokes at it - maybe that is my problem.

My biggest beef is the power cord. I am on my second one ($100 or so) and it is cracked with electrical tape all over it (fire threat) and barely works. I have to keep one hand on it half the time. Lame. They brag about the magnetics, but I think it isn't durable enough. Next beef is the battery - they go to crap pretty quickly. I think this is just laptop batteries in general though.

Anyway, in general I love OS X. It is the only thing to have your family on. I just think there is some room for improvement around durability. How sweet would a ruggedized Powerbook be? Maybe they have those somewhere.

Annyway . . .

Wednesday, December 27, 2006

First Turducken

I had my first Turducken Christmas Eve.

It was delicious.

Here is a picture of it.

Yes this is ridiculous, but don't knock it until you try it.

We didn't do the hard work of assembling it. We just bought it at my wife's childhood butcher (and now my sisters) and baked it. The truly experienced apparently deep-fry them.

Friday, December 22, 2006

2007 Predictions Starting

Here come the 2007 predictions. Who doesn't like these? Perhaps we need another round of blog tag on that ;)

Patrick Logan has one that I'd like to see come true. I'd at least like to see a good hard look at it. I've lived web services, ESB, EDA, and they all have their issues. I'm sure Jini/JavaSpaces has its as well, but perhaps the best of all of them is the right fit (ok REST not web services).

As the industry comes to term with the failure of WS-* we can either start over and reinvent things again or perhaps take a look back at some of the technology that should have been front and center to begin with.

I will post my prediction next week.

VMWare for OS X

The virtualization march continues . . .

VMWare has an OS X beta.

Saw this on Matt Raible's blog.

Monday, December 18, 2006

Jini Red Pill

My point is, that all this JBI/BPM/Web Services/'Lets Ra-ra-ra about RoR' is what you get and what you accept when you take the Blue Pill, so the thing is why don't you have a go with something different, could be anything (for those that have never tried Jini but have even a slight interest in SOA, have a look it doesn't bite). Follow your enthusiasm, you'll never know where it might take you. Take a chance - take the Red Pill

I like all references to the (now) eternal Red Pill. I loves the Red Pills. They keep me spry and handome.

I also like all things and people that are wise enough to diss JBI/BPM/Web Services in one sentence. Now that is a skill.

Mind you I have heaps to learn about Jini and JavaSpaces. Just saying I like this sentence.

All I know is WS-* is dead, REST doesn't cut it for (a lot of) the stuff I do, and I know enough already about the problems with ESBs and Messaging. I want some new problems to deal with. Or at least I want to fix a couple problems. No idea where it will go at this point.

I will say that I am going to be really pissed at Sun if Jini does turn out to be great. I mean I lived through 5 years (5 years!!!) of J2EE - all of it - even CMP!! If Jini is heaps better and Sun put me through that misery just because they totally botched the marketing campaign around Jini then I'm going to be a little upset.

Sunday, December 17, 2006

Blog Tagged

Patrick Logan blog tagged me.

You are supposed to share 5 little known things about yourself.

Update 15-DEC-2006 Patrick Logan wondered why I didn't take the time to explain my nickname, "fuzzy" and "panic" (i.e., Panic From Fuzzy). So I'll work it into my five things. Just a warning - it isn't very exciting.

Here are my 5:

  1. Probably the best thing that ever happened to me was being "held back" (i.e., failed) the first grade. I was just a late bloomer. But who knows what would have happened if I continued on when I wasn't quite ready. I give my parents *a lot* of credit for letting me fail at lots of things when I was young. They also encouraged me to pick myself back up. Based on my experience, I think the best thing parents can do is let their children fail. It teaches them resilience. If they don't fail when they are young they will not know how to deal with things that are hard when they are in the real world. If they aren't failing once in a while, you aren't doing your job as a parent.
  2. In high school I played hockey, tennis, and soccer (for 1 year). I liked hockey best. I quit soccer to play hockey more (I had some catching up to do). I was an average player. Getting up for 5:30 AM ice time was very good for teaching me work ethic. I received the nickname "Fuzzy" on my high school hockey team. No particular reason - you know how nicknames sometimes just stick. My Dad calls me Fuzzy and me friends from college and high school do as well. I basically stopped it once I entered "the real world", but it has seen a resurgence since I named my blog this (go figure).
  3. I attended The University of Dayton. It is a Catholic school. The brothers there are Marionist and their philosophy is to "Promote quality education of the whole person". This worked well for me. I studied a lot, but also "socialized" a lot. I really enjoyed my years at UD. Today I am not that into organized religion. But I am still a spiritual person. I need to figure out what to do about this in the next year or two as my child grows. I want her to be spiritual too. I might go religion shopping or I might just go to a Catholic church.
  4. I got a C in my first computer science class. Programming was very hard for me at first. You may laugh, but the concept of loops *blew my mind*. I remember sitting in my professor's office telling him how hard I was working (I was) and having him say that computer programming isn't for everyone and maybe I should hang it up. My resilience kicked in here and I eventually got it. I am very glad I stuck with it because I really love what I do for a living. The term "panic" came from UD. My friends and I were very into lingo (using clever word plays etc.). For whatever reason, the word "panic" was used often. I still think that it is a very versatile word and that it is applicable to heaps of "real world" situations.
  5. I love the outdoors. I hike and fly fish as much as I can (less since I had a child 1.5 years ago). My favorite activity is definitely fly fishing. I stop thinking about work related stuff for hours on end when I go fly fishing
Here are my 5 tags: Sarge Dodge, Mike Dierken, Matt Asay, markg, Kris Tuttle

Friday, December 15, 2006

Hiring

So we have some killer jobs opening in Portland, Oregon and Indianapolis, Indiana if you are interested.

The job description is a wee bit enterprisey, but that is just how our CTO talks. He's a great dude and isn't enterprisey to a fault. Very empowered place to work. Come join the fun. Let me know if you are interested (mherrick66 AT yahoo DOT com).

Basically you need to be a digital assassin, a leader, play exceptionally well in the sandbox with all kinds and have communication skills. You know commodity type skill set ;)

You know, like nunchuck skills, bowhunting skills, computer hacking skills..

Update 18-DEC-2006 To apply online go here. It is req# 27179BR. For the Portland job, you need to have some mainframe experience (e.g., VSE, iSeries-AS400, zSeries-MVS). You also have to have IT portfolio management experience. This job has a range of levels that you can be hired in as depending on your experience.

Technologist/Architect Job Description

Serves in multiple leading architectural roles across multiple projects and domains. Role is for the highest level professional ranking within IT. Must be capable of handling an aggressive and challenging workload at the highest levels of quality and throughput.

Responsible for developing business systems plans, roadmaps, and strategies that drive the delivery of software solutions which provide competitive advantage in the three to five year time frame. Works with solution delivery teams to provide direction, guidance, and hands-on mentoring. Reviews and develops architectural models and solution artifacts at both conceptual and detailed levels. Analyses highly complex enterprise wide system, technical, process and product issues to develop strategic direction and transformation plans -- participates in and is responsible for effective execution.

In-depth knowledge of business operations, objectives and strategies; in-depth understanding of global business and technology trends and the financial services industry. Experienced in applying best practices of architecture governance, methodology, and agile methods at both project and enterprise levels. Leads projects of strategic impact. Drives end-to-end life cycle improvements in IT processes.

Must have superior verbal and written communication skills, and have demonstrated application at all levels of business, systems, and executive interaction. Role requires extensive development of materials ranging from proposals, strategies, standards, architecture assessments, research papers, and presentation materials for diverse audiences.

Generally, the following minimum requirements apply: 15 years of related experience; Bachelors or Masters Degree in Computer Science or similar; current mastery of multiple architecture specializations (i.e. information, data, application, solution, integration, or enterprise architecture); current experience and mastery of IT concepts, strategies, software engineering, and modeling techniques.

Candidates will be required to demonstrate proficiency via sample written exercises, modeling scenarios in one or more disciplines, and potentially analytical and/or software engineering tests.

Range of technical skills required include: Information Management (governance, strategy, meta data processes); Data Management (logical data modeling, enterprise warehousing, business intelligence, object-relational modeling); Enterprise Architecture (business and technical reference models, solution architecture, legacy systems modernization, business process modeling); Software Engineering (full lifecycle development, including management, compliance, UML modeling); Network and Infrastructure Architecture; Enterprise Application Integration (mainframe architecture, J2EE middleware, ERP implementation); Enterprise Program and Portfolio Management.

Thursday, December 14, 2006

Jini/JavaSpaces & Distributed Caching

We are taking a gander at some space / cache technology and looking at ideal ways to do service orchestration with it in the architecture.

I am fortunate enough to work with Patrick Logan and he has some good questions. He worked for Gemstone a while ago so he knows their are opportunities to hurt oneself if one chooses unwisely.

I like JMS enough, but it has its issues. If there is a better, simpler way to do service orchestration I'm all ears.

Master/Worker with spaces might work. What else?

I like location transparency. It’s neat.

Update 27-DEC-2006 Just tickling your RSS reader - some good comments on this post. Please chime in if you have an opinion. I am becoming fascinated with this topic. There are a lot of parallels between SBA/distributed caching and EDA service orchestration models. I'm spending some time getting my hands dirty trying to get my head around it better.

Wednesday, December 06, 2006

OSDL Layoff

OSDL had a layoff the other day.

I have gotten to know a number of these fine people. They have been very good to me. I wish them luck. There are some good people left - Mike Temple and Tom Hanrahan certainly know stuff.

I also wish Stuart Cohen luck in his new venture. I certainly share his enthusiasm for it . . . its just a tough nut to crack (speaking from experience).

Not nearly as complicated as sharing code amongst your peers via some predatory vendor (and only having access to the binaries - not the source), but large companies have a hard time groking this. And there are forces that don't want this to happen.

We just need some more success stories . . .

Linux has won - some people just don't get that yet, but it won. Open Source still needs defenders and custodians like OSDL. Patents are obviously the next battle. Diane M. Peters knows a lot about that.

So I don't know if this is bad news or just a blip. My gut says its a blip. Times are changing . . . Linux won - old structures require change.

OSS is crawling up the stack . . . if Stewart has his way, the last big $$ maker will fall next. And then everyone will have to compete on business value rather then intellectual property lock in.

Wouldn't that be nice?