I’ll be flying out to Lawson towards the end of August to discuss their support for Service Oriented Architecture (SOA) and Web Services. Below is a statement and (growing) list of questions that I’ll take along.
Service Oriented Architecture and Web Services specifically have been endorsed as the desired interoperability architecture by the CIO Council (CIO’s from all of the UW campuses and the UW-System), Common Systems Review Group (CIOs and Business Officers from various UW Campuses and UW System who oversee the shared applications and infrastructure), Common Systems Interoperability Architecture Working Group (CSIAWG), Information Technology Managers Council (ITMC), UW-Madison CIO and others through-out the UW-System. Any integration that does not follow the SOA/Web Services design principles creates a technical deficit and prevents the UW System and campuses from moving forward in their strategic direction.
APBS/HRIS will be the system of record for enterprise data and business processes related to UW employment. As such, there is a business need for Lawson to integrate with the UW-System infrastructure as well as the infrastructure of each UW campus. This will require many integration points that will have to expose the data and complex business processes.
Example Questions for Lawson:
(1) Where is Service Oriented Architecture (SOA) and Web Services on Lawson’s Roadmap?
(2) Does Lawson’s HR Application currently provide standardized Web Service interfaces for their business functions?
— If not, when will they?
(3) Do Lawson’s applications expose their data in industry standard XML formats such as the schemas defined by HR-XML.ORG for Human Resource data, OFX (Open Financial Exchange) for finance data, eduPerson for person information?
– If not, when will they?
– What schema documentation exists for these interfaces?
– What process does Lawson follow if they need to extend an industry standard schema?
– How do they document those extensions?
(4) Does Lawson have WSDL (Web Service Description Language) documents for all of their exposed Web Service interfaces?
– If so, where are these WSDLs published?
– What is the process for modifying the WSDLs?
– What are Lawson’s best-practices around maintenance, development, publishing and changing of WSDLs and Web Services interfaces?
(5) Are Lawson’s Web Service Interfaces exposed in a way to discoverable and interoperable with UDDI version 1, 2 and 3 (OASIS, Ratified Feb 2005) registries ?
– What about BPEL?
(6) Are Lawson’s applications composed of reusable business process components?
– If so, are these components exposed as Web Services?
– Are they consumable and reusable via BPEL, Web Services Registries and Enterprise Service Bus technologies?
– Does Lawson use BPEL, WS-Choreography or another open architecture to build their applications from these reusable business process components? If so, which?
(7) What methods of Message Oriented Middleware are in place within Lawson?
– Are these methods exposed to the outside world for messaging integration points?
– Are these methods and points documented and supported as integration functions?
(8) In which standards bodies does actively Lawson participate?
– Which standards does Lawson see as critical to their integration and interoperability plans?
– Which standards have they submitted?
– What other vendors is Lawson working with to develop industry standards?
– Does Lawson work closely with the standards bodies such that the standards represent Lawson’s needs?
(9) How and where does Lawson represent and enforce their WS Policy?
– Does a change in policy (e.g. Security, Quality of Service, Routing, Mediation) require changing of core-code, reconfiguration and redeployment or can the changes be made on the fly?
– Does Lawson use intermediary Policy Enforcment Points (e.g. Policy Enforcement Points that are outside of the actual Web Service interface that are invoked as a proxy or a filter)?
(10) Does Lawson expose the business functions (services) as WSRP portletts?
– What about JSR168 portletts?