Legacy Business Processes and Business Architecture

Today’s reality is that most if not all of the businesses of any significant size have legacy systems and processes and we do not have the luxury of creating a business architecture from scratch. Any business architecture effort must take this fact into account. In a legacy dominated world, one of the difficulties in creating business architecture is having to deal with the processes that have evolved around the limitations imposed by technology. In such environment, a typical business process may involve multiple steps where the user must manually gather information from multiple sources, restructure/refine the information in a excel spreadsheet (or a paper) and upload into another system for further activity.

In such situations the business process reflects the problems associated with the underlying technology, where data is not integrated and/or is of poor quality. Additionally, applications supporting the business process are inadequate. This might be a good opportunity to re-engineer the business process and not simply automate the manual steps. At the same time, the representation of business design (business architecture) must reflect the current state.

I think it is important to have a good understanding of the business events that initiate business processes and the outcome of the process. Capturing of business events and how a business reacts to such events should be an important component of any business architecture.

Ashok Kumar

Vendors need to incorporate SOA infrastructure in legay applications

The majority of the IT budget (over 80%) is typically committed to supporting the existing infrastructure and applications. Even though adopting SOA brings substantial value over the long term, the short-term impact actually increases the support cost in two ways.

First, IT organizations will need to procure additions infrastructure components such as the Enterprise Service Bus, Registry/Repository, SOA Manager, SOA Governance tools, etc. Products like these not only requires upfront initial investment, it also adds one more layer of abstraction (hop) in the existing environment impacting the end-to-end performance.

Second, the support organization shall need to increase headcount and hardware infrastructure to support this next generation of infrastructure.

Even though most of the existing packaged applications are re-architecting their solution to run on the SOA platform, we are still years aways from wide deployment of these next generation applications.

It for this reason, it may make sense for the packaged application vendors to actually focus on retrofitting their previous versions of applications with the SOA infrastructure such as replace proprietary work flow by BPEL or XPDL, service enable (better) some of the business processes/services. It should be done in such a manner that the developers could still use the existing (proprietary) tools, keep the current functionality as is, limit functionality changes and roll this out as a patch release for the existing ERP, CRM applications.

This approach shall accelerate the adoption of SOA within and enterprise. In addition, enterprises shall be willing to pay incremental support to get this capability, a win-win for both the vendors and their customers.