Open architecture, open organizations

At first sight, these two topics seem totally unrelated. After all, isn't organizational openness a question of corporate strategy and responsibility of all these suits throwin buzzwords around? Isn't architecture the product of long-haired dudes with poor personal hygiene and little interest in anything else but stuff like exactly how clock signal propagates in a microchip. Let me explain.

Back in the days of Estonian Tax and Customs Board, we were gathered for a management meeting. One of the topics was whether or not (and if, then on what terms) should we grant another state agency a right to make a certain query towards our system. After a lengthy discussion it was decided that as the information was not really sensitive and didn't also fall under data privacy laws we should do it. The meeting progressed with other topics while I pinged one of our developers on MSN (didn't know Skype back then). He took a small query our own systems used, mapped it to WSDL, deployed the result into the x-tee infrastructure we had already in place, run some tests and was done. By the time it was time for meeting minutes I could report of the solution being live.

Why was the decision-making much harder than the actual development? Because, by nature, a tax organization is a closed one. It deals with data that absolutely needs to be kept private and runs systems that have to be shut away behind as many firewalls as feasible. It's core is secrecy, it's culture closed. Thus, it is naturally reluctant to move towards an open architecture even if it is technically relatively easy to build.

This observation aligns nicely with the holistic organizational view discussed in earlier posts. Organizational culture is part of the organizational architecture that is dependent on the technical architecture (and vice versa of course). Based on that model I'd claim that there is no way to build a really open architecture without having a really open culture in the organization.

Why is all this important? The other day I ran through another team behavior training and heard myself state once again that "open communication and more generally, the spirit of openness and trust, is the key to successful teamwork". Then it all clicked to place. You see, the greasy-haired guys are as much part of the whole organization as the people with ties. Neither will probably admit it, but they share the same culture, the same fundamental values and beliefs about how that organization should be run.

An example. When you build an API that is open for people to use, you take responsibility. Add an element to the payload XML document and all AXIS-based clients will break. Only an outwardly person, a person that cares, will voluntarily take responsibilities like this, the same applies to organizations. And even when there's some sort of drive to build that API and make it work, it will not yield the expected results. Documentation for developers? That's secondary. Support? Do we need to talk to strangers? Access? You sure you are not going to flood us with requests? Cooperation? You must be after our client base.

So an organization with a closed and inward-oriented culture is unlikely to have an open (and thus extensible) architecture.

Turns out the relationship is actually two-ways. Cultures can be changed and deliberately taking on those responsibilities, building an architecture that fosters openness and trust is a great tool for that. Why do you think Amazon opened up their queue APIs and does application hosting. In terms of business it must be minuscule. Only an organization with as open atmosphere as Google is able to create and support the amount of APIs they have. You can't really do any mashups if your basic assumption is that everybody out there is going to hurt you. Of course, there are organizations that are closed by nature (all sorts of financial institutions, certain state agencies and so forth) but the link between dominant organizational culture and qualities of the architecture in use is to be managed explicitly.

The conclusion? An organization needs to be open and outwardly on all levels to be successful. And you can't tell the IT organization to start "doing APIs". It takes a wee bit more than that.