Putting lipstick on a pig isn’t the right approach to web services. Only by adopting a new model can we overcome the inefficiencies of today’s architecture.
In all of the discussion about web services and their enablement and orchestration via the highly touted SOA middleware (think Oracle’s Fusion middleware, SAP’s NetWeaver , and so on), there has been far too little attention paid to the importance of basing those services on fresh, correct, and sufficiently granular HRM object models.
Many of the IT analysts have failed to make the tight connection between getting the models right and getting the expected business benefits from SOA/web services. Even with the clean slate that startup Workday has, if the company doesn’t get its enterprise and HRM models right, it won’t matter that it has great enabling technology. Here the advantage may go to Meta4 , the full-scope HRMS software vendor whose migration to web services has been enabled by nearly a decade of experience with fresh models of the HRM domain.
Getting those models right not only requires that the business analysts doing the modeling work have deep and repeated experience developing HRM object models but also that the vendors are willing to create significant data and process discontinuities with their installed base and with conventional ways of thinking about HRM. Needless to say, even where vendors are willing to create these discontinuities, they are loath to discuss it. But, whether by evolution, revolution, or intelligent design, our industry won’t be able to take full advantage of web services and SOA unless we commit ourselves to leaving flawed, never-modeled, or simply outdated HRM data and process models behind and adopt 21st Century HRM object models.
In HRM, it’s well past time to make a fresh start. The design of most established HRM software never envisioned the integrated and durable use of contingent workers, the extent to which all HRM processes are linked strategically via competencies, the fact that a single employee might work part-time in two different positions within the same enterprise, or that organizations would have multiple and concurrent views of themselves. All of these considerations and many more lead to quite different object models of the HRM domain. Unless the shiny new web services and SOA versions of older software and new software are based on a very contemporary, complete, global, and correct understanding of the HRM domain, we will suffer the same cost and pain in many of today’s implementations, operations, and service delivery.
New, underlying HRM models will present a historical data conversion challenges. When the underlying data design changes anywhere in HRM software, we are facing at best a highly automated data conversion process subject to manual review. At worst, a ton of brute force remapping and review will be needed. So when Oracle says its next-generation Fusion applications will be based on EBS , it’s telling you that PeopleSoft customers are going to have a substantial data conversion challenge in addition to whatever else it takes to get to Fusion. But this may be worth the effort if Fusion HRM is built on fresh models of the HRM domain.
When SAP tells you that its SOA by Design/A1S new products for the middle market are similarly a fresh start, it’s telling you the same thing. Here, too, the migration may be worth the effort if the new product fully considers new HRM models.
I could go on, vendor by vendor, but the clear message is that web services are only as good as the object models on which they are based. If we’re going to pay the price in data discontinuities and new implementations to get to an SOA and web services future, let’s at least be confident that web services are based on models that will be durably correct.
Are we ready to step up to the real heavy lifting, the fresh modeling of HRM that’s needed to make a success of web services and SOA? Are we prepared to undertake new implementations and discontinuities with historical data to get the real benefits of these fresh models? Our major software vendors clearly think that we aren’t ready, or they wouldn’t be so reluctant to discuss these challenges. However we get there, we aren’t going to have the software we need to support modern organizations unless we’re willing to make a painful and difficult break with the past. And we haven’t even begun to discuss these points with senior management.