SOA in Black and White.


There are many companies that at the moment are working in SOA initiatives oriented to develop and build new information systems centered in services, services composition and services orchestration. During the ride, on this rusty travel, raises several questions on the realities, business benefits, and facts behind this exotic word that everyone is speaking out there. On the following lines I'm going to try to explain the Facts and Realities behind SOA based on a couple of big real-life SOA projects where I have had the opportunities to work.

Before I start to introduce the Realities and Facts behind SOA, I want to tell you some basic principles:

- SOA is different to SOAP Web services.
- Webservices is just one of many ways to build and deploy a service.
- There are many technologies that can be used to build a SOA Service such as: RMI, CORBA, .NET Remoting, and any other RPC based technology.
- The real value behind SOA is “Connectivity & Flexibility”.
- SOA, BPM, BAM and ESB all of them are different buzzwords.
- SOA is much more that a technology approach for building new systems, it’s an architectural approach that aims to break the natural barriers generated by heterogeneous technologies that should be integrated for supporting the company’s real business needs goals and processes; and decoupled the business functionalities provided by the IT applications from the underlying technology.

Please take in mind the above principles for compiling ;) the following facts:

¿How hard is to start a new Enterprise Application?

On the last days I have been working on a big enterprise project. As part of my professional assignments are the Software architecture and Project management activities. I came to the project three months later the Project's starting point. Like any computer geeker ;) I supposed that all project's planning and scoping have been established without problem but it's not true.

Therefore, I tried to find out the causes of this situation but I couldn't find any valid answer... So I decided to identify the issues that fired those project's anormal situations. Some of them are described below:

- Lacks of project's Scope Definitions.
- Too much methodology guides to manage and control the project but nothing related to project execution.
- Bigger promises from the vendors technical plataforms but smaller realities from them.
- Lacks of the business specifications (Business process specications and use cases)
- Many non-validated expectations from the management team on the capabilities of SOA architectural approach and J2EE Platforms.

What complex is to develop a new information system today ?
From business procedures automation to business processes automation

During the last days I have been working in the preparation of the XXV Salón de Informatica: "Software's Enterprise Architecture", the most important event of ACIS (The Colombia's bigger association of computer science professionals). As part of the preparation activities, I have discussed some interesting subjects on software development with my co-worker Juan Carlos Cardenas.

One of them is the complexity associated for developing a new software solution that support the today business requirements. The new software solutions must be structured around business processes but the old software solutions were structured around business procedures.

- Business processes or business procedures What are the differences?

Since twenty years ago the end-users of the software application have been employees, for those who the automation of some specific manual procedures was enough to increase the productivity of their activities. But right now, the end-users of the new solutions are the customers, who are requesting to the company the automation of the business processes that define the company value chain. Each interaction performed by one customer to the company implies or fires a set of events crossing the company, affecting all information systems and humans that support the business process that solves the customer request or deliveries the goods.

This approach shows the importance for a company to align all IT and software initiatives to the business processes. In this way, the complexity related to develop new software solutions is directly associated to the process-oriented "fashion" under the new information system should be built.

It's so nice to hear comments, examples, news and anything else from you around this issue.

Building a technical infrastructure that allows to support the concepts, principles and architectural approaches behind SOA.

SOA is a "hot" word. Everybody is speaking about it out there, but What is it? What are the ideas supporting this concept? Well, in this post I 'm going to analyse and define SOA under a technical and business view; and present a logical architecture that can be used to run a SOA designed application.

SOA "Services Oriented Architecture" points a way to model and organize the interactions among several application in a decoupled, standardized and business processes oriented way. Each application must express your business functionalities to the external world as services. A service is a decoupled and well-formed interface that defines all things that the application wants to share to the other applications.

The interactions among the applications is driven by an open and standardized protocol. This protocol must be text-oriented and technical ubiquitous. ( Transversal to any technology).

SOA as an architectural approach needs a physical platform which allows to deploy and execute each designed and implemented application using services as core concept and component. That physical platform should offer support to several non-functional requirements -NFR-, such as: transaction management, security, availability, reliability, scalability and many other NFRs required to run a big scale enterprise application.

Enterprise Services Bus (ESB) platforms are emerging as that SOA's physical platform. Technically speaking, an ESB platforms is a kind of runtime infrastructure that allows to integrate many disparated systems using synchronous and asynchronous mechanisms. It combines services (such as: webservices, RMI oriented interfaces, CORBA, .NET remoting, DNA, and so on) and queues (queues, topics) to exchange messages among different enterprise applications, each one built on different technical languages and for either different operating systems or hardware architecture (RISC, CISC).

According to my -many-years- experience and several enterprise deployment, I think that one ESB can be structured around the following logical layers:

a- Services Layer
b- Connector layer
c- BPM layer
d- Middleware layer
e- Management layer
f- Security layer.

The description of each one layer is presented nearly as one posting blog.