Marc Andreessen’s blog The three kinds of platforms you meet on the Internet is a very accurate description of the choices facing HR software developers today.

I think most people would agree a browser is the user interface of choice for the future and the Internet is the preferred network. The question is what platform should it run on?

Marc describes three platform options: Level 1 “Access API” is where the application code lives outside of the platform and probably executes on a server elsewhere. The application calls the web services API (Application Programming Interface) to access data and services. The entire application development, including runtime system, programming language, database, servers, storage and so on, is the responsibility of the developer. The Human Capitalist blog places most HR applications today on that platform and I agree.

Level 2 is what Marc Andreessen describes as “Plug-In API”. Developers build new functions that can be “plugged in” the core application. Like Level 1 the developer builds the function and the core application calls it up to execute as part of a total solution. In HR terms that is like joining third party applications for functions such as recruiting, benefits, training, and so on. In reality, the HR application becomes a portal and the third party applications contain their own unique attributes including database and screens. There are many HR vendors that promote their products as web service or SOA (Services Oriented Architecture) designed simply because they can be called up by a “plug in” API but are nowhere close to integrated.

Level 3 is described as the “Runtime Environment” where third party code actually runs inside the platform and developers are given access to code via a browser to build or change applications. Marc believes Level 3 platforms are the future and when it comes to HR applications, I agree. Some of the advantages Marc discusses include the ease of developing with simplified development tools (expertise levels drops by 90%) and cost is minimal (the level of money needed drops to $0). Marc claims the “sky’s the limit in terms of how much development can happen on a platform like that”.

An example of an organisation that provides a Level 3 platform mentioned by Marc is Salesforce.com. Salesforce.com are into CRM (Customer Relationship Management) applications but have only started to scratch the surface when it comes to HR applications. Marc suggests you can “provide a marketplace that lets people buy and sell code”. To some extent Salesforce.com do that via their AppExchange initiative but an HR ecosystem to support Level 3 applications require much more than that. There must be design standards to develop applications and a marketplace based on HR business process to facilitate the discovery of components.

If the “sky’s the limit” what is in the pipeline now for HR applications?

The Salesforce.com model is a good guide to the future. We know Oracle and SAP are dragging their feet when it comes to moving to Marc’s Level 3 Platform. They have invested heavily in their current platforms and change will not be quick or easy for them. On the other hand Workday have gone to market with an offering that fits Marc’s Level 3 better than any other product I know. However, it does not open up the code to developers to build their own variation to functions, in the same way Salesforce.com allows custom built components. Communities of developers can build components using Workday’s toolset and expand the functionality of the core system but true Level 3 applications require more than that.

From a development perspective, integration of components (possibly by multiple developers) is critical. There are many workarounds, but there is no substitute for a commonly available database that can be accessed (with create, read, update and delete capabilities) by all applications developed to work within the vendor’s framework application. Any other form of integration is only a developer’s way of dodging the real issue.

Regarding INTEGRATION, under Marc’s Level 1 application integration relied on protocols such as CORBA, COM and EJB or XML file transfers. That didn’t work. Under Marc’s Level 2 integration was not taken seriously. Data duplication thrived and data exchange was the only way to make information coming out of the systems meaningful: Even then accuracy and consistency could not be assured because solutions usually involved multiple proprietary systems from different vendors using different database structures. The Level 3 code and database on the same server provide some chance of success, if they can conform to published specifications and standards.

From a commercial perspective, an elegantly designed Level 3 application will not be successful unless an appropriate market operation is in place to support the component discovery and delivery process. That involves the ultimate consumer of Level 3 HR applications, and that is the business user. There is a point where technical design must give over to business implementation and finding the right mix of components and services cannot be left to chance. Developer communities, vendors and the HR industry must agree a way of cataloguing components for system assembly rather than rely on semantic discovery techniques. Otherwise the Level 3 platform on the Internet will end up being just another good idea the business community failed to embrace.

In this Jeitocast, Karen Beaman interviews John Macy, Senior Global Advisor for Jeitosa Group in Asia Pacific and founder of Competitive Edge Technology, on the subject of SOA and services / component architectures. John is also the founder of Human Resource Component Software Application Standard (HR-CSAS) which defines the component structure for Human Resource Management Systems.

As we know, no one system can ever meet all of a customer’s needs, so the issue becomes integration. SOA or Service Oriented Architecture allows what the technologists call a “loose coupling” between components or services. That means it doesn’t really matter what programming language a component is built with and what platform it uses. “In theory, a client can go to the market and find the right mix of products that suits their needs and assemble them into one consolidated system using SOA features.” John talks about how SOA is changing to the way we do business by enabling a modular, Lego-like approach to building systems. The real value of web services and component architectures for HR systems is the ability to easily integrate a diverse mix of products into one consolidated system.

It’s important to stress, however, that care must be taken in the evaluation and selection of SOA products. There are some products on the market, like Dave Duffield’s new Workday product, that are built from the ground-up using native SOA and web technologies. There are many others “posing” as SOA products that are really just SOA “wrappers” around 20- or 30-year old technology. So be sure to look under the covers before making your decision.

Web services and SOA technology is becoming mainstream. Some predictions about SOA indicate that by 2008 80% of new business applications built will use SOA. For those considering the move to an SOA platform, John provides six basic steps to help companies get started on their SOA journey.

 

 What is a component based architecture? [19:20m]: Play Now | Play in Popup | Download