Generally, all business enterprises are dependent on information technology regardless of size. Historically, developing an information technology system has been a complex and expensive task requiring an IT department and a large cash outlay for equipment. Over the course of decades, custom developed systems become the company in a way COTS (Commercial Off The Shelf) systems never can. They become a never ending memory of a companies business rules.
Some software vendors refer to custom in-house systems by the derogatory term Legacy Systems. Other software houses have begun calling these systems Heritage Systems because they truly are the heritage of the company. Long after every person who created them have turned to dust, these systems will still remember what they did and be able to do it again. Rather than abandoning their heritage, smart corporations are embracing it and expanding the scope of their Heritage Systems via Service Oriented Architecture.
Service Oriented Architecture is a term often mistakenly associated with the Internet. While it is true some of this access comes in the form of Web pages and sites which allow anyone in the world to start doing business with the company, much of SOA happens on private and internal networks. Today we have businesses communicating directly with each other by both highly secured private networks and Virtual Private Networks (VPN). These B2B (Business to Business) communications systems pass data, usually in the form of XML, via secure messaging portals. The XML messages are then translated into something understood by the Heritage System and passed into it for processing.
Many of these Heritage Systems have been in place since the late 1970s. They run operating systems most college graduates have never touched, like OpenVMS from HP and MVS from IBM. Despite all claims to the contrary by sales shills and industry pundits, COBOL still has the most lines of code in business today. Yes, there may be trillions of lines of Java and other Web associated languages involved in communicating with these systems, but, they are only one of many feeder systems.
Do you ever think about the computer system handling your ATM transaction? How about the Web page you visit to manage your bank accounts? If you have our paycheck sent to your checking account via direct deposit, do you ever wonder how that transaction takes place? Probably not. The odds are quite high that your bank or credit union is running OpenVMS or MVS as their central banking system. The ATMs and Web pages are simply feeder systems which allow the bank to do more business and provide a higher level of service. The fundamentals of checking, savings, and IRA haven’t changed since they were introduced. There are periodic changes to rules and interest rates, but the processing of the accounts remains the same.
Heritage Systems have expanded access in many ways. Most relational databases like RDB on OpenVMS provide port services so Web based languages like Java can communicate with the database. These services allow customers far greater flexibility in how they do their banking. Many people reading this will be too young to remember a time when the only way to get cash or deposit your paycheck (yes, they used to actually print checks) was to go into your bank. Other than when you opened your account you probably haven’t been to your bank’s lobby.
Java and other Web based languages have been ported to many of these Heritage Systems so newer developers can begin getting their feet wet on the system which actually makes the company money. Some of the business rules have been integrated into the relational databases via special code snippets called stored procedures. These pieces of code can only access information contained within the database. What is special about them is that they contain many of the business rules of the Heritage Systems. This means that no matter how you access your banking, the same business rules can be applied without a significant amount of additional coding and testing expense for the bank.
Forward thinking enterprises have thus been embracing and expanding their use of systems like OpenVMS and MVS because of their rock solid stability. Companies which actually understand what it takes to provide 24×7 availability under all circumstances have been placing these powerhouse backbone systems in multiple data centers spread across different multi-state power grids to ensure the systems are always there. In short, this is how you build a cloud which won’t be blown away by the wind. The world famous Amazon cloud outage of April 2011 has proven to the world that cloud capabilities can only be provided by architectures which allow companies to “survive a fire” rather than recover from it.
Great Service Oriented Architecture Designs tend to have OpenVMS as the rock they stand on. Others, well, they use the same systems as Amazon and pay the price for it. When September 11 happened, companies using a distributed OpenVMS platform had a service hesitation of minutes while the cluster determined a location was gone. They continued trading until the end of the day without losing any transactions. How many transactions were processed by the impacted companies during the less severe EC2 outage?