Service Oriented Architecture
By Dominic Pazzula, President, Talon Risk, Inc. and Jay Pearson, Vice President of Technology, Talon Risk, Inc.
Service Oriented Architecture, or SOA, is one of the hottest buzz-words in IT. But what is an SOA and why is it important to the Energy Risk industry? SOA is a software architecture that stresses component reuse through loosely coupled “services.” For the energy industry, SOA helps bring a unified vision of corporate data and analytics and helps reduce the time and cost of developing new software systems. SAS software provides key components in an SOA through the SAS Metadata Server and SAS Stored Processes. RiskAdvisory, and their newest partner Talon Risk, Inc. have embraced SOA and are delivering solutions built around this architecture.
While there are many different interpretations of what a Service Oriented Architecture is, it is generally accepted that an SOA is a loose coupling of program components or services. These services each perform a well defined task. Further, most implementations of an SOA provide a means of discovery. Through this discovery mechanism client applications can retrieve a list of available services along with the parameters necessary to execute a service.
SOA enables different programs throughout the IT infrastructure to call on services to perform their tasks. A service need only be coded once; after that the service can be reused throughout the organization. This saves software development time. It also helps to ensure all applications use the same information by providing a consistent interface to that information.
Let’s take a look at a typical Energy company and see how an SOA could be used. Imagine if you will:
1. Historical market prices are stored in an ETRM system.
2. A corporate forecasting department develops price forecasts used for corporateplanning. These forecasts are stored in a proprietary SQL Server database.
3. A trader uses Microsoft Excel to price potential complex transactions.
Everyday current price data is input into the corporate ETRM system. However, the forecasting department does not know how to use the ETRM system so they pull market data from the web. The forecasting department uses this data to create forecasted potential future prices to help the corporate budgeting department. A trader that deals in complex transactions prices his deals in Microsoft Excel. The trader's pricing routine simulates potential prices, but because he does not know of the work of the forecasting department, he uses his own model.
With an SOA, the ETRM group could publish a service that provides current and historic market prices to anyone in the corporation that needs the data. The forecasting department can now consume this service in their forecasting system. Further, they can also publish a service to provide their forecasts. The corporate budgeting department is their main user; however the trader can also consume the forecasts. This concept can be taken one step further. The trader could make his pricing method available through a service. The ETRM group, needing a better way to price the trader’s transactions, could utilize the trader's method.
While this may sound like a major headache, it really is not. The beauty of SOA is the discovery mechanism. It tells clients, not only what services exist, but how to talk to them. Standards based communication (i.e. SOAP, Message Queues, etc) can be used to further reduce the time required to implement an SOA client.
SAS is uniquely positioned to help clients achieve an SOA. The SAS 9 platform enables organizations to harness the power of SAS inside of an SOA. SAS Stored Processes are SAS programs that are stored on a server and can be executed as required by requesting applications. Stored Processes can be accessed through SAS clients such as SAS Enterprise Guide and the SAS Stored Process Web Application, or programmatically through COM, Java programs, and Web Services.
The SAS Metadata Server provides the discovery for SAS Stored Processes. It also contains information about the parameters that each process expects, the parameter types, potential and default parameter values, etc. Further, the Metadata Server provides security around the processes so that only authorized users are able to discover and execute them.
The power of the SAS platform enables anyone to develop and register SAS Stored Processes. People familiar with the SAS programming language can directly code a process. Analysts unfamiliar with the language can use a tool such as SAS Enterprise Guide to point and click their way into creating a SAS Stored Process. Because SAS provides top tier data integration along with second to none analytics, no job is too big or small.
RiskAdvisory, a Division of SAS, and Talon Risk, Inc. – a SAS partner – provide SAS system design, implementation, and support to the energy industry. They are able to help clients move toward an SOA and extract the maximum value from their software investment.
Talon Risk, Inc. is a SAS Alliance member with experience throughout the energy industry. Talon Risk has software forthcoming that leverages the SOA of the SAS Platform and extends its functionality. This software represents a great leap forward for SAS and energy risk management.