Many dismiss Service Oriented Architecture (SOA) as a buzzword when it pops up in discussions. In some sense it’s like the term “Web 2.0”. It just doesn’t stick with many developers, who find it to be a container term lacking meaning. But at least Web 2.0 resonates with managers. It’s new. It’s cool. You need it. But when it comes down to SOA, even most managers aren’t sure what to make of it.

Personally I think that there is great promise in SOA technology. It’s about letting go of that two-tier silo perspective on things. No longer can businesses and divisions afford to think in that two layer “database plus front end” paradigm. Chances are you need to connect with other businesses and divisions now – and that you’ll need to connect to more later.

SOA technology really is all about constructing systems around flexibility. You want to connect another supplier, expose another point of sale somewhere, move a little here, change a little there. You want the IT flexibility to rapidly adapt as company strategy and tactics adapt. You have got to to cope with the fast-paced market dynamics and keep winning customers. You couldn’t do that with silo-based applications or hard-coded system integration. Enter SOA to provide you with that flexibility.

That flexibility is what should resonate with managers. But it hasn’t yet, really.

Fear, uncertainty, and doubt

The fact that SOA remains fairly uncharted territory to most must be attributed to the fact that many managers in both IT and business departments have little up-to-date knowledge about IT to get to gripes with SOA. There’s a lot of fear, uncertainty, and doubt out there. Here’s a list of things I’ve encountered:

• Fear of lacking interoperability. Most managers have been involved in system integration before, and most have seen it fail. Data interchange and synchronization has been tough. XML-based open standards and message buses have arrived to save the day, but there’s a lot of animosity here.

• Fear of increased IT risk. IT departments have won many struggles to stabilize systems that are currently in place, and from their perspective that’s as good as it can get. Many IT departments are not overly concerned with corporate business drivers or aware of their supportive role in the process. They are to keep those systems running. Why fix it if it ain’t broken? Why change the mix when we’ve finally gotten to this level of satisfaction?

• Fear of losing power. Having full control over systems, internal traceability, and dependence on the internal IT department is worth quite a bit. Being in control gives the idea of also being able to manage the risk, and being dependent on the IT department gives them a sense of power they like. When SOA comes in and dependencies shift, so do established power balances. This is politics, and that hurts.

Architecture and services are novel concepts to most IT managers. Without understanding what they are about, most will be ill to gladly sign off on SOA projects and rather keep protecting the status quo.

I reckon that showcasing successful past projects in similar industries will prove more useful than sending those IT managers off to training.

Tooling and sit-ups

The large enterprise software vendors such as BEA, IBM, Microsoft, Oracle, and Sun are all offering SOA frameworks and solutions. Only recently have I had the experience to work with them.

In spite of all the goodness that SOA should offer, the tools felt like a throwback.

Let me start by saying this – the graphical tools are unparalleled. Having used a host of business process designers and software modelers, these SOA suites rock. Creating a web service is as easy as dragging a component on the canvas. Want to look up variables in a database? Sure thing. You can connect any activity or decision point to any JDBC or ODBC supported database connection. Want to simulate that process? Just click and see the tokens fire. Got a deadlock? You’ll hear about it.

If that sounded to good to be true, then it was. Before I even got that canvas I had spent 8 hours of configuration in XML files, database connection pools, and application server containers. Add another 3 hours of debugging byte compilation errors due to different versions of Java, and you get an idea of the mess I had gotten myself in.

Even in the graphical tools I missed the convention over configuration that I had taken for granted ever since Rails landed on me. For every web service I created, I also had to explicitly link in the properties XML file. And for every invocation, I had to get into a dialog screen three layers deep to browse through an enormous list of possible input and output variables.

I know that my complaints are in part ungrounded. This is the state of the art, and the fact that we’ve gotten here is an accomplishment in itself. It’s one of the first realizations I’ve seen of model driven engineering done right: going from a model representation to an executable process complete with front end and all is only a single click away.

Welcoming web services

So would I recommend the current SOA tooling? Sure, if it fits your bill. This kind of flexibility comes at a cost, and there’s no point in nuking a fly. If you can fairly accurately forecast with what and whom you need to interconnect, and can afford a month or two of development time when a new network partner comes along, then hard-coded web services will still be your ticket.

You know what? Whether you choose the SOA suite or the hard-coded web service integration; you’ll be walking the web service route either way. Give yourself a pat on the back and watch the competition drool of jealousy.

Roderick van Domburg
Chief Operating Officer

This year’s RailsConf Europe is going down in Berlin and boy are we excited about going. The speaker and tutorial lineup sure is impressive and I’m certainly looking forward to meet up with friends both old and new.

Drop me a note if you’re going too and we’ll share drinks!

Roderick van Domburg
Chief Operating Officer

I would not at all say that I detest RSpec in any way, but I do find it to be rather besides the point. It just never caught on to me, you know?

When I first looked at RSpec, I thought it was rather cryptic. This boils down to a matter of taste, I know, but all those “recipes” (I don’t know the term) really aren’t all that legible to me. “bowling.score.should == 0”? “should” is equal to 0? Is it any more expressive than “assert 0, bowling.score”? Again, it’s personal preference, but this is one DSL that I don’t care for. So I dismissed it in favor of the Test::Units I have come to cherish.

Then I attended a lecture by Aslak Hellesøy. I mean, with so many people around raving about RSpec, I must be missing the point right? But I was let down: Alsak demonstrated it to be a wrapper DSL around Test::Unit for “people who find it hard to come to gripes with TDD”. So it’s a sort of workaround? I was disappointed by that statement of his.

He says Test::Unit is tightly coupled to the actual code and that that’s a bad thing. I say I like that coupling, because it keeps a sharp edge on the test-before-you-write principle: if you’re mucking around code or tests that worked before, you’ll find yourself pressed to advocate that change and express it in an additional or revised test.

Moving from personal preference into the field of computer science, there is no argument that I know of favoring either in code coverage or testing metrics. (Indeed, “coupling” and “cohesion” have so far only referred to the functional components themselves, not their tests.) This doesn’t prove either Alsak or me wrong or right, but does iterate that it’s a matter of preference.

“But,” some might say, “we’re testing behavior here. That’s different. We can clean up methods, throw code around, but as long as the behavior remains the same, then that’s OK.” I see it as the same discussion about white box testing and black box testing, but with a twist.

As a black box, the bowling example on the RSpec home page seems to work fine. As a white box, it’s lacking in every respect because the algorithm we assume to be present is, in fact, completely absent. I like to test the algorithm, because if I don’t prove the behavior of the algorithm to be correct then I will need to verify every possible outcome instead. That kind of verification isn’t very efficient.

So the twist is this: this time around, we’re mixing up black box testing by dubbing it “behavior” and white box testing by performing actual method calls. I’ve been searching for a rationale, but could only find the one by Alsak that I was disappointed by before.

The way I see it, RSpec is just a matter of preference, and a bit of a hype at that. Perhaps I’m misunderstanding, and if so, I’d love to see the entire mantra clarified. But until then, I’m preferring Test::Unit for its readability and code coupling, and saying nay to all those who preach that RSpec is a level beyond Test::Unit.

Looking forward to your responses.

Roderick van Domburg
Chief Operating Officer

As of yesterday our website and backup mail exchange is happily running on a FreeBSD virtual private server provided by JohnCompanies. They have got awesome support and sales responsiveness, impressive technical know how, and all of this at a good price and very comfortable terms of service (free backups, border firewall rules, and DNS service, anyone?).

If you are looking for a FreeBSD or Linux VPS, you might want to consider them. We chose them because of their FreeBSD support, their competitive price point, and the stockpile of raves about them on the web.

Full disclosure: we are not engaged in any affiliate program, receiving any discount, threatened to having the /dev/null fairy sprinkle her magic dust over our disk platters, or otherwise being pushed or financially benefited by telling you this.

I just love FreeBSD for its performance, stability, and its ports tree that is truly unmatched in terms of being up-to-date. Indeed I have been partial to FreeBSD ever since I received my first UNIX training in it a good 9 years ago.

Now that we have redeployed, we took the liberty of converting to the nginx web server to front our Mongrel cluster. It’s a breeze to set up, has great performance characteristics, and an unbelievably low memory consumption. And just in case you are interested, we whipped up a little mongrel_cluster BSD-style rc.d script for you to download and peruse.

Roderick van Domburg
Chief Operating Officer

Increasing availability of IT systems boils down to a single and simple rule: have everything double. But how far you want to take that mantra is another question.

It’s simple math. Suppose there are three system components and let x, y, and z be their predicted individual uptime. System uptime will then be x*y*z = 73%. Have X double and you’re looking at (1-((1-x)*(1-x))*y*z = 80%. Have Y double too and you’re looking at 88%.

So how to meet 100% availability? Have everything double, replicate everything, have a center for disaster control, and have regularly tested contingency planning. That sounds easy enough, but it doesn’t scale in terms of either performance or costs. Replication is tough enough as it is, and everything really does mean everything, and that gets pricey fast.

The past two weeks we here were bitten by it hard. We’ve got a lot double, mind you. But who was expecting for this fully fault-tolerant RAID5 disk array to go offline because of a failing controller? We did not have the spare part on stock. I guess that was a hard lesson learned.

In the end though, it still comes down to a question of cost. Not only will you need to have double execution with hot failover in place for everything, you’ll also need the spare parts to back it all up. And will you be buying spare parts for each and every part? I’m talking double power units, mainboards, memory, CPUs, cabling, disks, cooling, UPSs – everything.

None of us can afford downtime anymore. But can we afford inventory levels, stale stock and the advance financing? It’s a tough call to make. Quantitative risk management helps, but that is by no means common or a cheap affair either.

Research shows that IT exploitation and procurement is largely an ad hoc affair in SMEs. Are you like the rest of those? With IT becoming the key enabler of business processes, you might want to reconsider lest you too will fall victim under the simple math of IT availability.

Roderick van Domburg
Chief Operating Officer

Lead Rails developer Sjoerd and I had the pleasure of attending and speaking at RubyEnRails 2007 last week, and we had a blast! With 240 participants, three international speakers, and a great buzz surrounding it, it’s a writing on the wall on the success that Rails (and Ruby) is having and gaining still. A big thanks goes out to the sponsors and organizing team.

Our talk was a 45-minute live coding demonstration in which we developed WhooTube: a proof-of-concept showing off Flash video streaming using Ruby technologies. Even though we had done a successful general rehearsal we ran out of time before we knew it.

In hindsight it only comes naturally that you want to expand on a couple of topics, and that you have to deal with room changes, so we could have known. But hey – this gave us a great opportunity to discuss and do Q&A with a lot of interested people during the lunch and coffee breaks. Thank you for your keen interest!

Many of you will be excited to hear that we have open sourced WhooTube. We’d love to hear your feedback and look forward to seeing you at RubyEnRails 2008.

Roderick van Domburg
Chief Operating Officer

Here at Nedforce we’ve always been supporting and developing Microsoft .NET applications. .NET is feature-rich, corporate-backed, future-proof, and most of all: a simple fact of life. Many organizations and especially enterprises work on the .NET platform, and so we’ve made sure to have the skills to do the same.

And now it seems that .NET is shaping up to be more than just a fact of life. Or is it Ruby that’s making a move? Just take a look at this exciting IronRuby announcement:

[…] Microsoft has developed the Dynamic Language Runtime, software that allows developers to write .Net applications using dynamic, or scripting, languages.

Specifically, Scott Guthrie, general manager in Microsoft’s Server and Tools division, announced IronRuby, a version of the Ruby language for .Net. Over the past few years, Microsoft has hired experts in dynamic languages, including Python and JavaScript, to expand support for these languages.

Like IronPython–the version of Python for .Net–the source code for IronRuby will be available with an open source-style license, Guthrie said.

Great news for us Ruby zealots and Ruby enterprise acceptance.

Roderick van Domburg
Chief Operating Officer

When you use Ruby on Rails on a daily basis as we do, then there will almost certainly be a point in time where you run into a missing feature or even a bug. Why wait for “them” to fix it up when you can work it up yourself?

That’s right – at Nedforce we take joy in taking active part in the community. Here are some patches we have pending that you might find useful:

#8049: Improve PostgreSQL adapter compatibility, feature set, and performance
#7987: Fix column type detection while loading fixtures
#7981: Include missing ActiveRecord test fixtures

Roderick van Domburg
Chief Operating Officer

Doing international business is great. No matter my international background, I am still learning every day.

In business I find that the differences in risk awareness versus risk acceptance are most directly noticable. Here in the Netherlands we’re pretty uncertainty avoiding. That’s good for customers from the stance of code quality (hey, we don’t do continuous integration and 100% code coverage just for us), but isn’t always as productive for anyone when negotiating deals.

Here in the Netherlands there’s usually quite a lot to do about contracts and terms. That’s fine when you’re used to it. That’s how it goes, right? You do the price setting dance, you get to cover some of your risks, the other gets to cover some of his, and there’s a little to be given into for everyone. That ritual typically takes a number of weeks while in the meanwhile not much is happening. Everybody knows it, and that’s just the way it goes.

But when you’re doing international business, it’s exciting to see how different things can be. Take a recent international client as an example. He was looking to get this Rails thing done in fairly short notice. Can do! So there I was doing my Dutch dance when I quickly discovered it just didn’t work that way. And I wasn’t sorry for it either. Price-setting was a quick and simple matter, not too many worries over legal terms, but just work towards reaching the task at hand. Exchanging pictures of holidays in the meantime. That’s what I call a great business relationship.

Looking at Hofstede’s research, we see that the Netherlands uncertainty avoidance is about down the middle: half risk aware, half risk accepting. I think that’s a great starting position to do international business from. It’s a sign of dependability on the one hand and a sign of innovation on the other.

Globalization is quite the thing. Reading about it is one thing. But actually walking it is an experience like no other.

Roderick van Domburg
Chief Operating Officer

When you’re looking to create innovative products, choosing the India route isn’t always the best way to go. Making innovations a success in great part depends on forging partnerships with people and organizations that are like-minded innovators and add unique value to your envisioned product. It’s the positive innovative climate and unique value that counts.

Van der Meer, a leading scholar in the field of creativity and innovation management and accomplished entrepreneur to boot, tells us why: innovating is the total set of activities leading to the introduction something new, resulting in strengthening the defendable competitive advantage of a company. It’s all about getting that edge. You’ve got to be unique.

So let’s talk innovative countries. Who are innovative and who aren’t? Well, according to the Networked Readiness Index 2006 that’s published annually by the World Economic Forum and Insead business school things are looking on the upside for the Netherlands:

That’s right: the Netherlands is the greatest runner up, clocking in at 6th place and showing the most improvement. So what about India? Well, they dropped four places to 44th. The booming Chinese economy may have all the answers either, dropping nine places to 59th.

It makes sense. India is about low labor, price competition, and makes a living by offshoring services in popular everyday technologies. When you’re talking about creating niches and leveraging unique technology, that may not be the best fit strategically. It may work. They might work out your ideas, and that’s cool.

But if you’re in for the long haul, getting that unique technology to make you stand out, and finding that level-headed partner that actually contributes to even improve upon your already great idea, then you’re starting to talk strategic innovation. And when you do, you might just want to look at that top 10 listed above. Why not bet on the most promising horse? Here at Nedforce in the Netherlands, we bid you a warm welcome.

Roderick van Domburg
Chief Operating Officer

Corporate Ruby programmer and Rails core contributer Alexey Verkhovsky just put up an interesting post over at the Ruby on Rails forum on Ruby in the enterprise. I think it’s a great and positive read that really puts the finger on it:

Fellow Rubyists, Ruby is now mainstream. […] Ruby applications are now developed for banks, telecoms, investment companies, newspapers… not just cool Web 2.0 startups anymore. Every middleware, operating system and IDE product vendor has a dynamic languages strategy. This is a new situation that Ruby community has to deal with.

The discussion largely flows into a question of definitions, but I think that’s besides the point. The way I see it is this: no matter the exact definition, enterprise applications always have a lot to deal with both politically and technically.

In politics it’s about the money and power structures. Who’s deciding which technology to use? And the architectural choices to be made? When an organization has a running partnership with one of them big guys (think IBM, Oracle or Capgemini), that’s usually pretty well anchored at the top. And when something’s anchored, you’ll have trouble getting it loose.

Politically and psychologically, people defend the choices that they make. They defend their previous successes with a certain type of technology. They defend the partnership they made with them big guys (think Oracle or IBM). They defend their current architectures. Admitting to something else may have severe impact on existing business relations and organization. And many intuitively believe that drifting from a set course is admitting to personal failure. Again others may always have evangelized a certain technology or architecture, and always will. The point in here is this: if you’re to break today’s politics with new technology then that technology had better be pretty well regarded, lest none will commit to it nor will any organization uptake it.

Technically it’s about interoperating with legacy systems, scaling performance and capacity, and meeting availability requirements. When systems make entire enterprises tick, there’s got to be technical excellence underpinning those systems. Having great programmers and architects comes a long way, but any chain is as strong as it’s weakest link. Enterprise technology should be stable, mature, extensible, and performant.

So where does that put Ruby? Looking back at Alex’s post, Ruby has spanned both bridges. It has gotten through to those enterprises. Even without the mass marketing campaigns the big guys offer, so it really must be pretty good, lest no one would propose it right? And indeed it is pretty good. Even now that Ruby is gaining momentum, it manages to remain a stable and productive platform to develop on. Rails is the best example of its extensibility, and has also shown how to successfully scale Ruby applications. Ruby is here to stay, and enterprises know it.

Roderick van Domburg
Chief Operating Officer

Computerworld, a highly regarded source for the critical information needs of senior IT management at medium-size to large companies, has named Rails the #1 technology to know for 2007:

Equal parts design philosophy and development environment, Rails offers developers a few key code-level advantages when constructing database-backed Web applications. One of the central tenets emphasizes using less code for application development by avoiding redundancy and following Rails conventions. This means increased performance and, ideally, decreased development times.

And not to forget improved quality by leveraging the great opportunities for automated testing. Here at Nedforce we love to practice test driven development, and we’ve got the numbers to prove our software quality.

This is great and truthful PR for Rails, and a pat on the back for us Rails experts.

Roderick van Domburg
Chief Operating Officer