Trailblazing the first delivery of a software system requires courage and conviction, especially on projects that replace existing business critical software. When I’ve been acting as system architect I’ve employed a number of tricks in order to structure functionality and technical solutions in such a way that we can complete these early deliveries without sleepless nights. The most important is to find a subset of functionality that can be used with the rest being completed and investing in bridges from the old to the new.

This Norwegian language post describes my response to the report from a task force exploring a common IT-architecture for the public sector in Norway. Den norske regjeringen har besluttet at en felles IKT-arkitektur for offentlig sektor ville være fint. Jeg fikk greie på arbeidet på tirsdag, og har lest rapport til den store gullmedalje. Jeg er fortsatt ikke helt sikker på hva som menes med “felles IKT-arkitekt”, men jeg kan se omrisset av mange store evighetsprosjekter i dokumentet.

Sometimes it feels like I’m stating the obvious. But the fact that users only care about the interface of the service is something we often say, but seldom understand. If this is true, how can we think that we can develop the interface as an after though to the central system. Not all your users might be human. And the computerized users are treated even worse. If the non-human users also care about the interface, how do we think that they will be satisfied with the same interface that is used internally between different parts of the application?

Warning: This article requires a lot of editing love before it is very useful. It might be somewhat incoherent. Read at your own risk. ;-) Silo (software): A silo system cannot easily integrate with any other system. In software, the term “silo” is used to refer to a system that is constructed as one unit from the front end to the data storage. Everything is tied together to work with the rest of the silo, but not with other elements.

This article is a Norwegian-language version of my article Four bold claims about SOA. Dette er et utkast til en artikkel jeg ønsker å få publisert. Jeg setter stor pris på tilbakemeldinger om uklare tanker og formuleringer. To av de vanskeligste problemene vi møter innen programvareutvikling er integrasjon og det som gjerne kalles “business-IT alignment” eller forretningsorientering, altså: IT skal understøtte virksomhetens strategiske mål. Tjenesteorientert arkitektur, eller Service Oriented Architecture (SOA), hevder å kunne løse begge disse problemene.

CIO JP Rangaswami at investment bank Dresder Kleinwort Wasserstein talks about why he considers open source a corporate IT asset. In this talk, Rangaswami describes how DrKW wanted to create an internal incubator environment in order to combat skill attrition in the late 90s. In the course of doing this, they acquired OpenAdaptor and discovered almost accidentally benefits of the open source development model. The talk is a bit fleeting and unstructured (and someone’s phone keeps ringing during the presentation!

Inspired by Per Mellqvist (and myself, to be fair), I wanted to explore the possibility of using a generic DAO or Repository interface for REST. Based on this simple idea, I was able to create a very cute and testable prototype of a full Web Service stack for REST based Web Services. The most interesting aspect was creating a universal test case for Repositories. This article shows how little code is required to implement and test a REST based Web Service in Java, despite the horror of the Java HTTP client API.

Some time back, I watched a video David Heinemeier Hansson give a talk on ActiveResource on RailsConf. The thing that struck me is how much Rails’ ideas are connected to those of Domain-Driven Design. Watching DHH is like seeing a version of Eric Evans on speed. The video is long, but very entertaining. And it is well worth watching even if you couldn’t care less about Rails. DHH explains in real concrete terms how to think in terms of Domain-Driven Design, even though from the sound of it, I don’t think he’s heard of the term.

In my last post, I wrote about four integration scenarios using databases: Reference data, Consolidated view, Subscription and Publishing. Of these, the Consolidated View scenario requires the most interaction between the server and the client roles. This post will examine how to make the pieces fit together. Consolidated view joins the data of multiple clients into a consolidated view. This makes you able to create administrative applications that span a set of subapplications without having to change the central view when a new application joins the mix.

In my last post on using the database for integration, I argued that the best metaphor for creating systems that are interconnected is that of One-Large Database. Carl-Henrik asked some very relevant questions about this, which I will interpret (for now) mainly as “how do you avoid drowning in complexity”. This post will address the issue of maintainability, especially when things grow to be large. The On Large Database metaphor is mostly useful as a starting point.

Status: This article is currently pretty dry. I’d like feedback on how to make it more eloquent. In my previous blog post, I promised to write more about using databases as the main integration strategy. In the current post, I plan to cover maybe the most important question: “Why?” Imagine an application where every time it wants to communicate with another system, it reads or writes to the database. For now, let’s ignore how this would work, and how it would evolve, which will be the subject of later posts.

Before Web Services, there was CORBA. Before CORBA, there was DCOM. Before DCOM, there was RPC. Before RPC, there was BSD sockets. Before sockets, there were databases. And as it was in the beginning, so shall it too be in the end. The only systematically successful strategy in the history of computing is databases. I have discovered more and more lately that integration using a database is well-defined (DDLs - a WSDL that works!

What happens when a customer asks for a simple new bit of functionality? Do you have to execute changes on four different systems, test each in isolation and in combination, involve a separate testing, infrastructure and operations team? If so, your architecture is probably not service oriented. In this post, I will examine the real meaning of coupling, and how it relates to SOA. I will, like others taking about SOA, try to define what I mean by SOA in this post.

When I see people after they have read about SOA or attended a conference with SOA, there are a few ideas that seem to pop up repeatedly. I have even been guilty of using these ideas myself. These ideas were proven to be bad before SOA came around, and (some) SOA evangelists seem to think that SOA solved these problems. It did not. It just refused to learn from history. Some of these ideas work under some circumstances, but recent SOA-itis has caused them to be used in inappropriate contexts.

Barcelona I just returned from The ServerSide JavaSymposium Europe. Great conference, with interesting tracks and good opportunities to get to know people. The conference was in Barcelona, which was interesting, because hardly anyone (taxi drivers and waiters included) understand English here. It’s the first time where I’ve been a place where I am totally unable to communicate verbally with people around me. So it as a bit of an adventure. My only gripe about the location is the price of WiFi access in Spanish hotels.

Roger Sessions has just published “A Better Path to Enterprise Architectures”. His main point is that large, centralized, big-bang enterprise architecture efforts fail. I could not agree more. Sessions gives some good arguments for why you would want to deliver incrementally. He calls this approach SOA. This is a fairly common way of defining SOA - basically SOA is another name for incremental deliveries. If this is SOA, I don’t hate SOA at all.

In my previous post, I talked about how I feel SOA encourages rigid design. Of course, in some situations, you may not really have a choice. When creating Business-to-Business (B2B) integration, interfaces will naturally be much more rigid. There is no way around it, SOA or SOA-not. Ian Robinson recently published an article on Martin Fowler’s webpage titled Consumer-Driven Contracts: A Service Evolution Pattern. The article gives some very clever ideas of how to make the consumers drive the service definition instead of doing this on the provider side (this is related to Lean Software Development, by the way).

On JavaZone 2005, I talked about “Why I hate SOA”. I found it hard then, and I’ve still found it hard for a while to express this sentiment concisely. I think I’ve finally got it! One of the most common inefficiencies I discover in organizations is poorly designed boundaries. I find that people suffer when a boundary is too ridig, not when it is too loosely defined. Contractual interfaces create a “mine versus yours” mentality, where every problem beyond the boundary is not corrected, but instead wrapped in even more code.

Joel Spolsky had a blog entry seems eerily familiar: The Architecture Astronauts (in outer space) I’m starting to see a new round of pure architecture astronautics: meaningless stringing-together of new economy buzzwords in an attempt to sound erudite. I’ve seen the type, and I’m glad to say that we haven’t got any of those around. A bad architect can cause enormous damage.