Dis-economies of scale

One of the main reasons for centralization is to gain economies of scale. Less known are the dis-economies of scale. I’ll give some examples in the paragraphs below.

The cost of communication between the central group and the rest of the organization. Although there are lots of tools that make communication easier. Distance in the physical sense or within an organization can create boundaries. These have to be dealt with and there are costs incurred for that. Besides that it has to be clear who to communicate for what matters. This, in my experience, is not always the case. With a greater (organizational) distance more effort has to be put into this.

There is a large possibility that top heavy management in a centralized department becomes isolated from the effects of their decisions. In other words the feedback loop is broken. Because the communication loop is broken, decision become more and more dysfunctional. This due to the lack of real world knowledge that should be incorporated in these decisions.

Centralization can lead to reduced agility. On one hand standardization is a great asset. The larger part of architecture, whether it is enterprise architecture, process architecture or infrastructure architecture, is about standards and reducing the “solution space”. This has several advantages, among which the reduction of software- and systems entropy. The downside of a centralized body that maintains standards is that it probably will lead to inertia and unwillingness to change.

I’m a big fan of (open) standards. They simplify life! However we should not neglect that standardization comes at a cost. There are the costs for implementing, adapting to and maintaining standards in our organization. Say for example that we use a canonical (data) model. There is are maintenance costs (at least some effort) while adopting to change outside and within our organization. These costs of standardization tend to be hidden.

What to do?

Bring the effects described before into the business case for centralization. You did make sure that there was some sort of trade off when you decided to centralize a certain part of your organization didn’t you?

Take measures to prevent these risks. It goes without saying that these measures will take effort, time and possibly money. Now you know you’re going to take measures don’t you?

The value of reference models whether it contains data models, standardized messages, processes of a reference architecture, is or should be in a faster time to market and better quality of the solution.

Handle with care

What makes it hard to achieve this value, is the fact that these models contain always far more than is needed. That can be considered a waste. Even the parts that are not used still require attention while implementing and maintaining. This incurs work to understand the complex model, hide the details you don’t need, and customize and extend the parts you need.

Implementing a reference model requires spending time to determine how and to what extend this model meets the needs of your business? That is typically something you have to discover for yourself. It is where the majority of the time is spend! If you don’t go through the effort of understanding your business requirements, you are missing understanding of how the business can and should use the model. That makes it very hard to determine the value of the end solution to the business.

When using a reference models you should be aware that your business is not average. In some shape or form it delivers value to your customers in away a reference model doesn’t provide. Reference models should be used with care your business deserves.

This seminar will take place on Thursday September the 15th at our Whitehorses head office in Nieuwegein, the Netherlands. It’s in Dutch and aimed at our customers or potential customers. More information on the seminar program.

We’re looking forward to share our ideas with you. Hope to see you there!

ADF is the “Paint by the Numbers” for web front end development.

The most common application integration tools/solutions used are Post-it and a paper notepad.

However the real gem I discovered during this first day was:

User Experience Design Patterns

Madhuri Kolhatkar has delivered a great presentation on the effort Oracle has put into creating and implementing User Experience Design Patterns. Extended information is available on the Usable Apps pages of the Oracle website. Great insight on how this can help you in developing and delivering your applications can for example for OBIEE be found on Design Patterns and Guidelines for Oracle Applications. Take special note of the Pattern Selection Tool.

Real-life accounts of successful and failed SOA projects discussed first-hand by those that experienced the project lifecycles and have a story to tell. These veteran practitioners will provide advice and insights regarding challenges, pitfalls, proven practices, and general project information that demonstrates the intricacies of implementing and governing service-oriented solutions in the real world.

I will be presenting the first session in this track on Using a Service Bus to Connect the Supply Chain. If you have any topics or questions in advance that you think I should address, please post them in the comments. Hope to meet you in Berlin.

There is a call for presentations:

The SOA and Cloud Symposium 2010 program committees invite submissions on all topics related to SOA and Cloud, including but not limited to those listed in the preceding track descriptions. While contributions from consultants and vendors are appreciated, product demonstrations or vendor showcases will not be accepted.

All submissions must be received no later than June 30, 2010. An overview of the tracks can be found here. Other resources:

• My blogpost of the SOA Symposium 2009.
• Presentations from 2009.

There are loads of examples in litterature but also in more popular books like Freakonomics that:

People respond to incentives

In the animation you’ll see the kind of incentives that work well for tasks that go beyond mechanical skills and that require rudimentary cognitive skills (like conceptual and creative thinking). These incentives include the following aspects :

• Autonomy – Which demands engagement instead of management and control.
• Mastery – It is great fun to learn things and sometimes even be (really) good at something!
• Purpose – Humans are purpose maximizers even more than money maximizers.

Please note that money isn’t one of them. In short for organizations and managers it boils down to:

Treat people as people!

Let me know what you think on this subject in the comments….

Many of the arguments that have traditionally been brought forward in favor of Spring are invalid or outdated, because they target disadvantages of J2EE 1.4 and prior versions, rather than Java EE 5/6. … the original argument that this is not supported by Java EE is simply gone, and the remaining argument, if present, is much weaker.

If you’re in a position where evaluating these alternatives read the entire blogpost. Generally speaking there is no best way to go. Both are viable frameworks for writing Java applications.

The choice should be made by taking into account the particular requirements and technology strategy of the organizations building and using the application.

If there’s an opportunity we’ll see if we can come up with some rules of thumb for the selection.