Major- and Minor Tyrannies in software

Serviceorientated Architecture (SOA) can enable/support redesign of business processes that can help organizations tap more of their potential or even providing uniquely new products and services.

But there are som pitfalls that might show up later in the process as obstacles, caused by lack of/forced- or accidental decisions. The pitfalls I will elaborate on here are those that dictate projects to use inapropriate technologies for the problem they are supposed to solve. I call these majority and minority software architecture tyrannies. Software architects must spot these and handle them properly.

Majorities
Majorities often force inappopriate solutions on other projects in an organization, disquising this as standard solutions to be used. This eliminates good and qualified decisions in projects that is doing something different than previous project. Doing something different is the norm in software projects, as it often is part of renewal/change in business/technology.

Such standards is often invasive and impossible, or at least very hard, to change later.
Majority tyrannies must be met with knowledge about better alternatives, and how they can contribute to better supporting requirements and business strategy. In cases where standard noninvasive technology is forced, an isolation layer can be introduced to prevent unwanted dependency diffusion into architecture and code.

Standards often appears as a relieve, liberating the project architect from making decisions. Not staying alert can prove fatal to the project later on.

Minorities
Survivor projects clinging to old or inappropriate technology can prevent others from moving on to better or more suitable technologies. Measures dependant projects can take is to create a Integration Anti Corruption Layer (orginal definition from DDD Anti Corruption) layer, so it will be easier to replace later.

A subset of minority tyranny cases is lack of proper versioning of dependencies, making releases of different projects interdependant. In SOA this is amplified and has become a runtime challenge, as opposed to earlier where this was primarily a build time problem. Several versions of shared services (and components) must be supported simultaneously to enable independent and smooth releases. In SOA the most flexible way of version handling is using the Evolving Endpoint pattern.

Consequences and how to deal with this
The concequence of making wrong/forcing/avoiding architecture decisions is high complexity in release management and ineffective software for supporting business processes. Since both organizations and software technology changes continously, decisions can not be be written on stone tablets. Previous decisions must be challenged, and discarded as they are
a) proven wrong
b) outdated
c) proved unecessary

This is part of SOA Governance and must be handled by a Center Of Excellence or Policy Advisory Board

Especially majorites often lead to Architectural monocultures, which is bad both seen from innovation (evolution) and security point of views. These are strong motivators for evaluating and make architectural decisions based on business requirements rather than what has worked before.

This post may appear as a anti standard manifest, but that is not my intention. Good standards have been reevaluated many many times, and survived these evaluations. This "process" will run the test-of-time on standards and give feedback for refinement. I think it can be viewed as variation of natural selection, where the fittest survive. Natural selection, by the way does, not apply in monocultures. Monocultures can produce odd mutations and eventually they collapse.

On a per service this manifests itself as providing multiple endpoints, that makes it as accesible, usable and flexible as possible. A service consumed by many clients gives it a strong position in the organization(s) using it, and thus it may itself become a well proven standard.

Monocultures are unhealthy - even in software

Making the assumption that every project should be based on the same software stack, is just another variation over Silver Bullet.

In the software world the temptation to default to an architeture that has worked before is unhealthy. The result is almost always a constant struggle for the project to overcome limitations and find workarounds for architetural monstrosities.

Monocultures fosters very little learning in the organisation and leads to forcing inappropiate solutions to problems. According to epidemology theories monocultures is very vulnerable and is unable to evolve to tackle changing environment. Thinking of epidemology naturally leads to thinking about security issues as well. Monocultures is only able to resist specific types of threats, and given that the threats is certainly evolving at a blazing speed there is a obvious need to have variation.

In the longer term Monoculture will hinder innovation, and this can disastrous for an organization whose business model is e.g. developing and selling software.

But of course not all variations will be good, and should be dismissed. When experimenting with a technology new to the organization or a given project, do it in the small before going full scale. The opposite of genetical monoculture is diversity. Healthy software architecture in an organisation is probably best grown in an evolutionary way, allowing varations, promote the things that work well (but not restrict to only that). More important: things that do not work well must die.

All systems should be architected with the "right set" of technologies for the problem it is suppose to solve. One should start with what you know for sure, and make as few assumptions about the future as possible. The Cantara Software foundation has a wiki discussing these issues among other things, and I will try to post more in this topic there.

Yesterday I came across a blog post in Cutter Consortium, about uncertainty in a leadership perspective. This applies to software architects too. This should be in the architect's mind when evolving the software arcitecture for the organization.

What can Open do for you?

Yesterday Totto noticed me of this Gartner blog about how CIO's should answer when asked about what IT contributes to the enterprise. Mark McDonald suggest that the answer should be how IT contributes to the core business model. This way it can be shed some light on how business models and IT can both be improved to be better positioned against the competition.

Another blog post that caught my interest yesterday was Matt Asay's
Cloud computing: A natural conclusion of open source? Here Asay is writing about Tim O'Reilly's prediction that Cloud Computing will make Open Source licenses irrelevant. A bit far from what my post is about, but it stresses that new software will be consuming/provider of services. In order for new software based on the SOA/Cloud Computing paradigms, open data formats and open standards will be quite important. Open Source is a natural way of implementing both data formats and standards, and hopefully this is going to happen. Even inside enterprises these thoughts should be considered, so it will be possible to combine the result of different development efforts to create even more valuable software to support the core business model.

2 days ago, I fell in love with this blogpost from Rickard Öberg about quickness. Although this post is about quickness at the individual developer and team level, it applies to organizations as well. To quickly reposition against the competition and market demand, sharp services exposing open data formats and beeing based on open standards will be crucial.

The CIO should understand what Open can do for the core business model, as this will be utterly important as more software is SOA based, running in the cloud. The ability to move quickly has been important at all times, but in some ways the changes in paradigms is accelerating and it will be more visible when you does not posess this ability.