email article printer friendly

Breaking Down Walls
Building the SOA you need means managing your silos better
by Roger Sippl

April 27, 2005

Note: Roger Sippl is the cofounder and chairman of Above All Software. He will be speaking at Enterprise Architect Summit (Key Biscayne, Florida, May 22–24) on "Enterprise Thinking in a Services-Oriented World."

When I started Informix Software in 1980 my goal was the same as the goal of service-oriented architecture (SOA) today: to break down silo walls. At that time the silos were just simple tables of data, usually read and written by COBOL programs. The Customer file would be managed by one COBOL program, and the Orders file by another. If the boss wanted a report of all the customers, each listed with all their orders, a third program would have to be written, and the programmer would have to get the file definition parts of the source code for each program copied into this new "composite application" that they were creating. That was our tool to make the silo wall go away between that Customer file and that Orders file.

I am glad to say that we got smarter over time, so we invented the relational database management system to do it in a less labor-intensive way. It is now the most valuable tool in all of data processing, relating millions of tables with each other every second of the day all over the world. But we have used it so much that we have created new silos—each enterprise application has its own database and its own application server. That application server was also a great invention, and during my days at Vantive and Visigenic Software it was a privilege to join with others and pioneer the "three-tier architecture" where application servers held the running business logic that did transactions with the databases.

Since a silo's database might have thousands of tables, and how they relate to each other might be subject to change daily as restructuring is done for performance or other reasons, it is only safe now to interact with the logic in the application server that knows how to do things like find a customer or put an order or credit on hold. Those "little software robots" of business logic might work with one database one day, but maybe need to check three databases the next day after a merger of companies, or even just a merger of product lines within a company. Because change is constant, we as a species have graduated to another level of modeling. The business logic in our production servers is now the model of how our enterprise works. This model used to be a tower of babble, with some of that code being expressed as C functions, some as COBOL subroutines or CICS transactions, Java methods, or whatever flavor on whatever operating system using a wide variety of remote procedure call mechanisms. Web services resolve that. The mechanics of how to talk to any "little software robot" is now clear.