Archive for March, 2008

Should I reorganize Testaco?

Sunday, March 30th, 2008

I am back in the SW business.

As of february 14, I am a principal consultant at Objectware in Oslo. Feels good. This also means I have started developing again.

One of the first things that happened is that grabbed hold of Testaco again. All of a sudden, the itch is back. Need to sort my own tests.

One of the ideas I have had is to drop the testing framework of Testaco and replace it with Unitils, leaving Testaco as an eclipse plugin that automates maintenance of tests. The tests would run using Unitils. I have talked to the developers of unitils, and they are not against the idea.

My problem is that I don’t know how large a user base Testaco has, if any.

Going through with this refactoring would mean breaking backwards compatibility for Testaco. Repairing it again could be done mostly by scripting, though.

So – what do you think? If you are a Testaco user, please comment this post. If you think Testaco is a good idea and would like to see it stabilized I would also appreciate some feedback.

Is SOA coming of age?

Friday, March 21st, 2008

Finally, something seems to happen to SOA.

My take on SOA is that it is one of the most over-hyped bandwagons the software community has seen since the three-tiered “enterprise model” appeared around 2000. Everyone seems to have written a SOA book, often only slapping the “SOA” label on a set of technologies before setting them free in a cruel world. There is no consensus on what a SOA architecture is, how to talk about one, much less hos to make one successfully. People mostly talk about what SOA is not.

The same thing happened to the three-tier application model, where an application is split into a presentation layer, a business layer and a data storage layer, with each layer being remoted. The remoting (once again, a technology push) was there to enforce separation of presentation and business logic.

After a while, real-world considerations caught up with this model. Things like latency requirements and usability pushed the application of the model backwards to a middle point where all requirements were taken into account. The presentation layer would still be separate, but the remoting between the presentation and business layers was removed because it didn’t carry its own weight.

I was very glad this morning when I read Jabows is the enemy of enterprise SOA. I wholeheartedly agree with the statements in this blog posting – SOA, or any architecture for that matter, is not primarily a function of technology. It is mostly a function of people and business needs.

Hopefully, this is all going to lead to a set of best practices for creating SOA services that are workable, and which are not vendor- or technology-centric. There are people who know how to do this today – I work with a couple of them right now – but up until now, people have learnt by trial and error. Perhaps someone is going to step forward and create these guidelines now.

Perhaps SOA is growing up.

Happy easter.

Geir