These last 2 years as software architect and lead developer for Sapo Services project, I learned a lot about what is service orientation and what works better. These conclusions are of course taken from my real-world experience implementing this and other projects I take as an independent consultant and not a law you will see applied in every case. I will make a two-post series on this subject, also giving fundament for every argument I'll present.

I'll begin with what service-orientation is not:

1) It is not easier:

Service orientation is not easier to implement than a monolithic architecture, OOP or CBD. One big ball of anything is obviously easier to do, compared to many separated balls who communicate as a complex system. There are many industry best practices involved in a service orientation project and your knowledge of them is critical to success. You will need good communication skills with all stakeholders and to be specially disciplined as you drive them out of chaos.

2) It is not faster:

Service orientation projects do not take less time to deliver than a classic .NET or Java project. Because applications are more complex, there is little to gain from it in time to market terms. It is faster to continue doing things the same way than changing old habits. You will need people to assume there's need for a change and likewise naturally accept that nothing like what is promised in SO will come for free.

3) It is not cheaper:

You will have new roles with SO advent and this can mean hiring. There is a lot of new technology to deal with and this means training. The organization implementing SO will change dramatically and naturally this implies more cost than before. 

4) It is not revolutionary:

There is nothing new in SO, besides the fact of joining, standardizing and demanding together some of the best practices from previous technologies. This means you are not supposed to forget what you've learned about the best way to build a class or a component. There are specific aspects to consider when doing a service but underlying it we'll need well built components, as before.

5) It is not a product:

No matter what corporate sellers will tell you, ignore them. You can't buy SO. There is a lot more about SO that what will come in that package they will try to sell you. You don't buy business agility, you have to get more agile processes. This requires people to have a common vision and cooperate to fulfill it. SO is all about cooperation and transparency. Will this come in a software box?

6) It is not about just doing services:

Many times I hear people saying they are now service oriented because they have built some services. SO is more about best practices than is about services. Sure, you will have services in SO but you also can have hundreds of services and never reach a service oriented state for your business processes. In fact, SO is much more a road you should follow than a place you can go. I prefer to say: "we are on a way to SO". This makes much more sense to me.

8) It is not self-managed:

Introducing SO, you have lots of new reasons to monitor the systems pro-actively. You need to know a lot about your services: when they fail and why, what is affected and get notified in multiple ways. Even if you are building a super-cool architecture with a lot of P2P agents and smart stuff, service governance will not be done automatically: you will need specific services, applications and the people who operate them.

9) It is not a developers problem:

You may be a bit worried if you hear someone saying that SO is a developer's problem, not our department. But you can get really worried if you hear your CEO saying so. That will mean something is wrong with your SO initiative. Check point 5).

10) Finally, will not vanish if we just sit and wait:

Depending on how much you are allowing your company to loose, you can ignore SO. There have been several trends like this and you are still open to public, I know, but how long will you sustain not having the business agility demanded by customers and showed by competitors? Will you keep your big ball of anything?

After exploring SO misconceptions, in Part II, I will focus on some facts. Until there, please accept my invitation to comment on your own SO experience.