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?

SOA Cloud Symposium 2011

The SOA Cloud Symposium 2011 logo has just been released. In 2011 the SOA Symposium will be held on April 27 and 28 in Brasilia the capital of Brasil.

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.

Audi S5

Besides innovation it is said in the Dutch magazine Management Team that reuse is one of the driving forces. It is great to have another example of how the principles behind Service Orientation not only deliver value in IT but also – or probably mainly – for the business when applied e.g. in other engineering disciplines.

Reusable building blocks

Audi has limited the number of modules engineer are allowed to use to construct a new model. There are two main lines, based on how the engine is placed:

• Modulare Querbaukastensystem – transverse engine platform
• Modulare Längsbaukastensystem – longitudinal engine platform

Limiting the number of construction modules for engines, gearboxes, air conditioning results in several benefits:

• Lower costs per car compared to it’s competitors.
• Serve a larger number of niche markets compared to the competition.
• Shortened time-to-market.
• At production lines both employees and robots can work on several models. This enables Audi to produce the models that are in demand, while at the same time keeping a high utilization rate.

Audi claims to save 20% per manufactured car, and to save 30% on the development of new models. The economies of scale are further leveraged because of the reuse of components in the Volkswagen Group.

The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.

BPEL is an execution language. There is for example no standard graphical notation in the BPEL standard. The main focus is not on readability, it is on execution.
So BPMN and BPEL aim for different goals. It should come as no surprise that there is gap. There are several resources that describe the mapping, provide translation, or transforming BPMN to BPEL.

Guidelines

Here are some guidelines that help you bridge the BPMN to BPEL gap:

• Be as specific as possible in BPMN diagrams (In Oracle Business Process Analysis Suite you can use e.g. automated activity, notification , and human tasks.).
• Add additional information in BPMN activities. Sure this doesn’t enable automatic transformation, but it does reduce the need for additional design documentation. This will improve documentation consistency, and reduce the required governance.
• Use templates in your BPMN activities. Structure and check completeness of your descriptions.
• Use a Service repository. This will enable both designers and developer to communicate about “the same thing”
• Use a GUI components reposity, for the same reasons as you use a Service repository

Still searching for the correct answer on the question: What skyline is in the picture on slide 12?