One of my favorite metaphors to aid in the creative search for sustainable systems and architectures is the ecosystem. Although much is written nowadays about organizational ecosystems, SOA ecosystems, ecosystems of webservices etc. the most important part is missing in almost every buzz cascade: the answer to the question »What the heck is an ecosystem?«.

The thoughts of Fritjof Capra provided the desperately needed de-buzzing for my part. Although having absolutely nothing to do with IT or business systems, his basic principles of ecology provided what I was looking for.

Capra assigns five basic attributes to ecosystems:

1. There is no waste. The waste of one member of an ecosystem is the food of another.
2. Matter cycles continually through the web of life.
3. The energy driving these cycles flows from the sun.
4. Diversity assures resilience.
5. Life thrives not by combat but through cooperation, partnership, and networking [1].

All principles together culminate in a sustainable system of cooperating but essentially independent (sub-)systems.

To get the most out of this metaphor we have to interpret it for the context at hand.

What does principle number 4 e. g. mean for the field of enterprise architecture? One interpretation could be that there is no need searching for the one technology to serve them all. Treat the separate units and divisions as the individual organisms they are and specify just the interfaces and cross-cutting concerns (web of life, no waste) connecting them. If you interpret the sun as an orientation point towards the single organisms can navigate by, the governance bodies and the sponsorship needed to organize such a web of life bring principles 3 and 2 to life.

The interpretations and possibilities of these principles are seemingly endless and powerful. As with every powerful thing the danger of misusing (misinterpreting?) them are there, too and can’t be denied. As a tool to break out of internalized mindsets and (in this case) transfer knowledge between different domains, metaphors are essential.

What are your favorite metaphors?

Read Capras original paper here. Get the slides on the subject from OOP2009.

Update:

[1] It always seemed to me that a sort of »proof« was needed for this statement:

»In the long history of humankind (and animal kind, too) those who learned
to collaborate and improvise most effectively have prevailed«
Charles Darwin

On Monday I blogged about the potential values of Cloud Computing. Today I want to jump straight into the same topic and enlarge the introduced model by analyzing the value of Cloud Computing from a public and a private perspective.

Public means, that the cloud offerings are owned and managed by a third party. From these remote installations others can rent capacities. The private perspective puts the focus on infrastructure that you install and own, but that implements many of the technology platform features found in large “scale-out” server farms run by public cloud providers.

Thicker lines around the value element mean, that more emphasis is placed on that element. Fainter lines mark the less important or missing value elements.

As the diagram says, strategic and economic values seem to be more important in public cloud offerings. Architectural values can be found as well, even if people do not always keep this value category in mind. In contrast, private cloud offerings are limited only to the architectural values.

From this point of view, public and private cloud offerings seem to be the complete opposite of each other. That does not mean, one is better than the other. It’s just necessary to understand the differences and benefit from that knowledge.

How can public and private cloud offerings be combined to receive the maximum value? Are there other points to be considered in the value model? What are your thoughts about cloud values? Let me know what you think!

Found at: mwdadvisors.com

It seems there is a good chance that NUMMI the famous joint venture between GM and Toyota is going out of business. For the lean insiders among you this news has to be at least a little suprising.

Why? And why is this news for a blog like this? To get the full picture of this news we have to look at the history of NUMMI.

When it opened for production in 1984, NUMMI was the first joint venture automotive plant in the United States. For Toyota it was a chance to expand its manufacturing to North America. GM on the other side saw this joint venture as an opportunity to learn about the ideas of lean manufacturing from the inventer of lean itself.

Since its beginning the plant, its management values, methods and techniques  served as the shining example and proof that lean and the resulting benefits could be implemented anywhere. Classic lean books like The Toyota Way praise NUMMI for following all 14 principles of lean. The most important and basic being:

Principle 1: Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.

The book cites a few situations in which Toyota indeed decided against closing the plant. For example instead of following the trend of the times and moving all of production to places like mexico management only moved a part of the work and found other things for the plant to do. The rationale of all this being that the workers themselves at the end »couldn’t be blamed for having done anything wrong«. The ultimate goal of humanity before profit seemed reachable.

Times seem to be really different this time. To all »believers« in lean values it will be very interesting to watch Toyotas next actions.

Will it stay loyal to its own principles? Or is a paradigm shift near, crushing down the »old «values? Will management give in to the crisis and the omnipresent subliminal call for »drastic actions«?

We’ll stay tuned.

One concept which goes with almost all discussions of PaaS (Platform-as-a-Service) is the  application marketplace or app store.

The Promise…

The argument hype goes something like this: If you specify an platform standard, get more than one hoster to host it and finally convince people to develop little applications (or widgets) for it, everyone wins:

• the hoster can leverage its existing customer base including the possibility of cross-sells
• the application developer can sell his app leveraging the combined numbers of customers of all participating hosters
• the customer having access to a huge selection of apps able to be integrated into his homepage

etc.

Reality sets in

Besides technical and cooperational problems the equation bases on the assumption that you get a lot of small or medium sized ISVs (Independent Software Vendors) to program against your platform specification. If you are aiming for business developers this means there has to be enough money in there for them to lock into the platform constraints. The promise now is that electronic marketplaces lower the barrier of entry for these developers enough to ensure profit for all.

Promise? Maybe you’ll say »Hey, I know this works! What about Apples app store?« Exactly my first thoughts but let’s look at the numbers provided in a recent blog post of an developer who has to know:

According to the developer of Zen Jar which ranked around position #30 when the article was written he earns as much as……20$ a day with his app. Considering that there are currently over 36.000 applications to choose from I personally had expected much more profit from entering the Top 50 in a popular category.

What are the reasons for this? For one it’s the standard pricing of .99$. To become really rich at this price you have to sell a lot. Looking at the numbers in the article at position #34 you can expect 30-35 downloads a day. If this is not enough for you you have to do marketing which cuts your profit even further.

As also is mentioned in the article this doesn’t mean the business model is wrong. It just shows that app stores aren’t the 1, 2, 3, PROFIT guarantee as some people suggest. There are still some problems to make the model work as »advertised«.

So what?

Just providing a platform to develop and run applications on is not enough. Providing a place to list this apps and provide services for licensing and billing is not enough, either. What is often missing in the discussion of the »application marketplace« is how to aid developers in marketing their product. If you leave the myriads of »little« business oriented developers alone with this task they won’t have enough resources to do it on their own and still be profitable enough.

One more challenge to overcome in the PaaS opportunity…

[This article is a rerun from the old blog. Because the matter is still interesting (to us) we migrated and republished it.]

Today I want to answer a question which I  pondered about for quite a long time:

»What does lightweight really mean?  Does it mean anything at all?«

What annoyed me most was that everyone nowadays seems eager to point out (MULTIPLE TIMES AND IN CAPS) how lightweight his process or framework or whatever is supposed to be. The fact that no one seems to gloat over the fact how »heavyweight« their product is arose the suspicion in me that the whole heavy- vs.  lightweight comparison is more a marketing- or coolness thingy than something helpful to dispute or even base decisions and strategies on.

I deliberately used past tense in the last paragraph because thanks to Lu Kim Man and Keith Chan these times of doubt are finally over for me! In their book »Software Development Rhythms«  these guys give a definition of »lightweight« even  I can understand an use:

The weightiness of software processes and practices is a matter of the values that arise from them and the degree to which activities directly benefit and contribute to core developers (i.e., people) and core software programming (i.e., products). [...] For example, a software process that requires writing all-embracing design documentation for commercial database applications may be considered heavyweight as it does not directly create value for the core development.

They further state:

Heavyweight processes have their place. In this case, detailed documents come in handy when we are going to outsource technical support and software maintenance abroad.

This finally makes the term a useful tool to use in discussions and for decision making. The meaning is clear and the trade-off between the extreme opposites can be assessed and evaluated in concrete contexts.

For those wondering: The emphasis of people and product in the quotation refers to the agile mantra »People over Processes, Working Code (=product) over Documentation. Seen this way one could reason that »the more lightweight you do the more agile you are (little padawan)« but this is a job for the evangelists out there which I don’t want to awake with my humble shenanigans. If you are interested in my opinion: It’s BS.

Let’s summarize:

• The weight of a tool or process can be defined as: »How directly do developers and programming tasks benefit from it?«  In other words: If the answer to »Does it speed up development in the short term?«  is Yes we are on the lightweight track.
• Sometimes we sacrifice short term benefits in favour of long term, project overarching goals. By doing this we enter the heavyweight realm.
• There is place for both strategies. Neither one is evil.

Amen.

Can you live with this definition? How do you define »lightweight«?

Complex(ity) – another word for “Dunno”?

Our research shows that the terms complex and complexity are often used to hide that the person has little or no sufficient understanding of the thing that he is describing as complex.

It is a very complex situation/problem/software/process/organisation/business or whatever tends to reveal an insufficient diagnosis of the context. No DBA would speak of a complex database but any business guy will for sure. On the other hand any IT guy has seen complex business rules or processes first hand.

I vote for banning the word complex from your active vocabulary and see what happens. Vote Stefan!