A Services-Oriented Approach to Lease Management Software

by Madhu Natarajan and Jay Mehra July/August 2007
Indeed, the reality is that no lease management system, however comprehensive, can ideally meet every last need of running a leasing business. In confronting this reality then, communication-ready applications are certainly worth considering. This is exactly what the Services Oriented Architecture approach to designing leasing software brings to the table.

The efficiency of every busy restaurant is directly impacted by the competency of its waiter. Shuttling between the kitchen and his table assignments, he has to give each table the time it needs (but never more) to decide on food, note multiple orders accurately and, of course, time appetizers, drinks and dessert so everyone at each table is enjoying the right course at the right moment.

The pickier among us add another layer of complexity: we like our martinis only stirred and never shaken, the steak just so, our wines perfectly decanted. Needless to say the margin of error cannot be too large and the service is expected to come with a smile. In many ways, the demands placed on the waiter are very analogous to what the typical leasing company expects from its lease management systems:

  • Sales needs to submit transactions through mobile devices
  • Credit requires immediate access to quantitative information
  • Document management has to ensure all legal considerations are addressed
  • Accounts payable needs to know what assets have been accepted on which invoices
  • Syndication has to manage bank relationships and plan funding
  • Account management has to ensure the transaction is appropriately set up and that billing is triggered
  • Client services needs to cater to concerns from different parts of the customer’s business
  • Collections can only be as effective as it has access to relevant account and contact information
  • Remarketing needs to be a few steps ahead of lease termination

Suddenly, waiting tables doesn’t seem to be so bad, especially considering the typical challenges of running a leasing company are made more complex because its underlying systems work as disconnected information and process silos. While these systems may not be short on overall functionality, they do not effectively communicate with each other; often times, critical applications work independent of one another even though the business functions they support do not.

At best, rigid integration mechanisms may bring some together and, at worst, manual intervention may be the only available Band-Aid. Indeed, the reality is that no lease management system, however comprehensive, can ideally meet every last need of running a leasing business.

In embracing this reality then, approaching design such that applications are built to be communication-ready is certainly an idea worth considering. This is exactly what the Services Oriented Architecture (SOA) approach to designing leasing software brings to the table.

SOA is a conceptual approach to design, which essentially breaks down and streamlines functionality into services made ready for integration. Generally, there are three main players in this approach: the user (who consumes the service), the service (that gets data from the user) and, of course, the business engine (that carries out a given function). Each of these players, while dependent on others for exchanging information, acts as a separate and independent entity once the necessary information is obtained.

This process is similar to the restaurant where the customer, acting as the user, places whatever order she wishes from a menu of options; the waiter, acting as the service, takes any order that is given and independently shuttles it to the kitchen; and the kitchen, acting as the business engine, simply processes each order received. In system design, functionality within each application is broken down into specific services, each of which can act on its own; the function to book a lease, for example, may be separated out as a service, just like another that changes the location of a given group of assets.

What makes this approach truly powerful is that each service acts in exactly the same manner whether it is called from within the application or from any other outside system. The concept of an application then really becomes nothing more than a collection of “a la carte” services, which in theory, can be availed of from anywhere by anyone at anytime. In other words, each service is integration-ready by design.

Given the accessibility of services under the SOA design, key business partners and stakeholders in the “lease value chain” can be tied-in through natural extensions of the lease management system itself. Services can be adjusted to be exposed to outside parties, giving external users the same functional ability as internal ones.

For instance, as discussed above, the function to change the location of a given asset could be bundled into a service. Certainly, this service can be invoked from within relevant parts of the core lease management application. But it can also be exposed to a “customer-portal” from where customers can avail of the same service, independently. This is the equivalent of being able to order the very same entrée from inside the restaurant or through a takeout service, whether by phone or online.

Other business partners, such as funding sources, vendors, remarketing auction sites, insurance companies, etc. can be similarly tied into the leasing system wherever relevant by exposing the appropriate services for their consumption. Allowing stakeholders to serve themselves not only adds efficiency to the leasing company but, by extension, also enhances the productivity of the lease supply value itself. And the beauty of the SOA approach is that such extensions do not have to be known at the time of design and can be progressively added over time, as desired.

In streamlining functionality, SOA also allows for easier integration between various parts of the system; typically, where the lease management system doesn’t integrate functions effectively, manual intervention and strong business processes are needed. If Document Management isn’t integrated with the rest of the lease management system, information transfer has to be manually carried out or through integrations built as “after thoughts.”

The structure of systems based on SOA, on the other hand, inherently allows for integrations even if they weren’t foreseen during design. Each functionality (or service) within the system itself needs to integrate with others in order for the application to function as a whole; the interaction with outside services or systems is seen merely as an extension of this same idea.

To elucidate, let’s take the example of a service that books leases when provided with the necessary information. Certainly, this service would be called through the user-interface when entering in lease-booking data. But, as the service is “blind” to the data source (i.e., all it looks for is the requisite data it needs, irrespective of where it comes from), it can be called from outside the system, by a third-party, “front-end” application processing system or from a vendor portal that manages different vendor programs. As long as the outside system provides the service with the information it needs, the lease will be booked just the same.

Once again, because the lease booking function isn’t subsumed as an inextricable part of the lease management module, it can be used with greater flexibility. Because the service is decoupled from the consumer (whether this is the system’s own user interface or an outside application) and the processing engine (the lease entry function), service-oriented applications are inherently extensible beyond the core application for which they were initially designed.

The SOA approach to design, in bundling functionality into compartmentalized services, allows for each individual service to be enhanced incrementally without impacting the wider system adversely. The interoperability of services is determined as part of initial design; once dependencies (i.e., the specifics around how each service contributes to and is dependent upon the functioning of other services) are established and, assuming that touch points between services are not changed, what happens inside each individual service can be enhanced independently as needed.

For example, let’s assume Syndication is a dedicated service that ultimately needs to tag a pool of leases, gather the relevant information behind their sale, carry out the requisite calculations and accounting entries, and finally stamp each affected lease as “sold” along with related sale information.

There are essentially two places with touch points for this service: upfront, when it is given the leases that need to be pooled for syndication and at the end, when it needs to look up each affected lease and indicate that syndication was completed. The touch points need to first be built so that the service can be placed as a functioning piece into the system. However, what happens between the touch points can be incrementally enhanced, built or changed as needed, provided that the touch points themselves are kept unchanged.

For example, the first implementation of the Syndication functionality may essentially act as a placeholder that is fed the lease and sale-related information, which it then uses to carry out the stamping process to indicate completion of the sale. All other activities, including the requisite calculations and accounting, may be carried out through a manual process outside the system. Then, over time, the underlying business processing logic can be incrementally reconstructed and enhanced whereby the ability to do calculations is added first, the management of accounting entries second and even an electronic interface with the funding source is added at the end.

As each of these enhancements is introduced, the overall system continues to function uninterrupted because the service that requests the Syndication to run is the same. Amazingly, this is the equivalent of getting an engine tune-up and tire replacement while the car continues to be in motion.

Extrapolating from the compartmentalized design of services under the SOA approach, another significant advantage is the ability to naturally accommodate any number of presentation mediums simultaneously. A well-designed system using the SOA paradigm would be multi-layered, with multiple possible presentation layers. The screens through which the user interfaces with the system do not have any more underlying intelligence than to simply function as a conduit for obtaining and passing on information.

The validation, manipulation and storage of this information becomes the domain of various other dedicated layers. The medium used for presentation, therefore, can be approached with flexibility without impacting the functioning of the overall system. Sales reps working remotely would likely prefer interacting with the system through rich client or mobile devices whereas data entry staff would certainly want a more traditional and stationary set up; satellite offices, on the other hand, may require online Web-based access to the system.

With a service-oriented design, where information comes from and how it enters the system become immaterial as all information, irrespective of source, is treated in exactly the same way; again, this makes the system immediately extensible. Equally important, this implies that there is a consistent (and real time) view of information about the portfolio, customer and other business relationships. While traditional systems could, with added effort, be built with an equivalent level of flexibility, the SOA approach inherently allows for this by virtue of its design.

In the dynamic and turbulent leasing environment of the 21st century, change is as certain as death and taxes. Companies need to become increasingly adept at responding to changing realities and have to evolve with the needs of the marketplace, whether this means adding a new CRM system or a better Customer Services interface. Concepts such as “rapid and continuous improvement,” which are becoming increasingly popular, are indeed proactive efforts at addressing this very challenge.

In each case, however, the degree of agility that can be realized is impacted directly by the potential and limitations of the underlying technological infrastructure. This is where an SOA approach to systems design makes a significant difference. The lease management system cannot exist as a loose collection of information silos. In fact, even if a leasing system is functionally rich, there is always some level of integration and interfacing needed with other co-existing systems.

Here again, the SOA approach is vastly more future-ready by anticipating the reality of integrations and enhancements to functional changes that may be, as yet, unforeseen. In fact, it allows for the very concept of “rapid and continuous improvement” to be extended to the lease management system and, by doing so, can itself become a complimentary, synchronized and integral part of such corporate initiatives.

Whether the goal is greater employee productivity, closer and more automated relationships with customers, vendors and other business partners, or simply more efficient decision making, the SOA approach increases the probability for success. A perfectly served steak is always great, but if it can be combined with individually timed and perfected accompaniments from wine to cappuccino, it would be that much more enjoyable.


Madhu Natarajan Headshot

Madhu Natarajan is the chief executive officer of Odessa Technologies, Inc. and has been with the company for the past ten years. Before joining Odessa, he worked for Crowe-Chizek, LLP, and brings extensive experience in software technologies, lease management and lease accounting. He has spoken on a wide range of leasing topics at various national and international forums. He has also written for leading industry publications. Natarajan graduated magna cum laude from Monmouth College with a degree in Computer Science and minors in Business Administration and Accounting.

Jay Mehran Headshot

Jay Mehra is the chief operating officer of Odessa Technologies and brings specialized experience in software technologies and operations management. Before joining Odessa, he worked for Ernst and Young, LLP and then for PricewaterhouseCoopers, LLP.

At Ernst & Young, he was involved in the State of Industry report for India’s auto-finance industry. He was also involved in the design and deployment of proprietary Intellectual Asset Management software, which helped large multinational corporations manage their patent portfolios and budget their R&D spending. Mehra graduated magna cum laude from Haverford College, with a Mathematical Economics degree with high honors.

Leave a comment

No tags available