March, 2008

Is RUP suitable for SOA?

What is your SOA methodology?

Read this article and let me know what do you think about using RUP for SOA projects.

This article focuses on combining RUP with MSOAM to create a process to do business modeling.

I never had heard anything about MSOAM (Mainstream SOA Methodology). If you want to know more about MSOAM, here you find it.

Don’t forget the retrofit cost

The IT departments of many companies are creating web services. Interoperability makes it easy to connect an application to another. Often, however, these web services are created without any control.

Everybody knows that web service environment is not the same as SOA environment. Reuse, for instance, is frequently described as a benefit of SOA. But achieving reuse demands policies and tools to manage the whole service life-cycle. It´s necessary to implement SOA governance.

When the IT department faces this gap between a SOA environment and its web services environment, it realizes that the first step to solve the problem is to select a repository of services.

At this moment a new problem is detected. This kind of tool is built based on web services standards. Then, the IT people realize that its web services don’t follow the standards, they aren’t compatible with the tools and all of they must be changed. This implies in saying that an expansive retrofit in the web services must be made.

My conclusion is: if you don’t follow standards, don’t forget to include the retrofit cost in the ROI evaluation of new projects. Undoubtedly the retrofit will be necessary.

Why selling SOA projects is harder than selling EAI projects?

My team started to perform EAI projects some time ago. We have experienced what happens with new technologies. Initial sales were hard, but they became easier with time. Now we start to sell SOA projects and we are realizing that this is even more complex. The main reason is SOA adoption requires a broader change in IT environment.

EAI emerged to organize exchange of information between applications. Applications always had to exchange data. But, prior to EAI there was not a standard way to do that. The connections between applications were point-to-point. When an application was changed, all the applications connected to it had to be changed too.

EAI introduced a big change in this scenario. All the applications were directly connected to the EAI middleware through standard adapters. But, it is important to notice that this was not a big change in each application itself. The structure and concept of the application remained the same.

On the other hand, SOA requires a deep change. The concept of application is different. It is necessary to break down the systems into services. Then, the applications are created with these services. This architecture makes it easy to reuse assets and aligns IT with business needs. It is clear that this architectural change is bigger than the change due to EAI adoption.

In my opinion, selling SOA projects is hard due to more than the newness of the technology. The actual reason is the wideness of the change.