CartLog In

Line of Business Systems Ltd

About Our Company

Line of Business Systems is a provider of made to measure LOB and EAS (enterprise application suite) systems for the SME sector. While there are many systems that occupy the EAS space, SME's often encounter a number of drawbacks with their adoption including the following:

  • often they are a poor fit out-of-the box and incur potentially prohibitive cost arising from either:

    • changing existing business processes to fit the system or
    • modifying the software to fit existing business processes.

  • certain areas of functionality may exceed client requirements resulting in a system that is unnecessarily complex.
  • they rarely include specific “vertical” line of business modules.
  • integration of external or bespoke modules may not be seamless.
  • up-front and on-going customization may be compromised or costly if the system does not provide sufficient flexibility.
  • their user interfaces may be dated leading to an increased user training requirement and inefficient system usage.
  • they may be tied to expensive databases that are excess to requirement.

Line of Business Systems' proposition is to supply made to measure LOB / EAS solutions that avoid these drawbacks while remaining quick to implement and competitively priced.

Requirement

In order to meet its goals, it was clear that there was a requirement for a base platform comprising a repository of reusable modules that could be assembled to form the bulk of each implementation with modifications and additional modules completing the bespoke client solution. The following schematic illustrates this.

The following commercial and technical factors and constraints were among those considered when deciding the best route to develop the base platform:

  • 1. The base platform should be composed of reusable modules.
  • 2. The modules should be easily altered and extended on a per-project basis.
  • 3. It should be straightforward to exclude or hide module complexity when not required.
  • 4. New modules should integrate seamlessly with the existing ones.
  • 5. The system should be able to target multiple databases.
  • 6. There should be no arbitrary limitation on what functionality can be implemented.
  • 7. Third party tools should be fully supported and from a reputable supplier.
  • 8. Final client systems need to be comparable to competitive EAS applications in terms of cost, functionality and usability.
  • 9. An initial version of the system was required within 8 months to meet immediate client demand.
  • 10. Up-front and on-going development costs should be minimised without compromising quality.

Solution

The following options were evaluated in the course of deciding how to implement the base platform and client solutions:

  • A. Develop a framework from scratch and the modules on top of that.
  • B. Develop the modules on top of an existing framework.
  • C. Select an existing EAS package and customise as required.

While option A would have provided maximum flexibility, it was eliminated due to time and budgetary constraints (9 & 10). Option C was also ruled out since the packages that were investigated would not have provided the flexibility required for 3 & 4 and in certain cases targeted a single database (5).

When looking into option B, I would draw a distinction between what might be referred to as architectures and frameworks. At one end of the scale, architectures predominantly tend to be blueprints for a system structure whereas, at the other end, frameworks tend to be implementations of a blueprint. I.e. architectures provide greater freedom by leaving much of the blueprint to be implemented (or TBD in DX speak ;-)) whereas frameworks allow less scope to adapt the design but require significantly less effort to deliver a working solution.

Under option B, the two candidates that were given serious consideration were CAB (and SCSF) and eXpressApp Framework (XAF). CAB lies somewhere between architecture and framework, providing a powerful (if complex) foundation but none of the higher level services that are required in a typical LOB application such as security, reporting etc. XAF is, as the name suggests, very much a framework with support for most typical LOB services. In the end, time and budget constraints (8 & 9) plus the fact that CAB was a Patterns & Practices offering with no guarantee of continuity or support (7) tilted the scales strongly in favour of XAF.

Benefits

This section highlights the benefits of adopting XAF by discussing how it satisfies each of the requirements mentioned above.

  • 1. The base platform should be composed of reusable modules.

    While XAF does not currently provide any explicit support for domain model reusability, the underlying eXpressPersistent Objects (XPO) ORM layer allows the domain model to be structured such that reusability can be achieved. There are planned changes that will add reusability support directly into XAF.

  • 2. The modules should be easily altered and extended on a per-project basis.

    An XPO domain model can be altered and extended via sub-classing and partial classes. Built-in controller functionality can be easily altered and extended by sub-classing existing controllers or introducing new ones. Since the XAF controller factory will only create the most specialised controllers, sub-classing an existing one is all that is needed to modify or replace standard behaviour.

  • 3. It should be straightforward to exclude or hide module complexity when not required.

    XAF includes the ability to include / exclude domain classes and properties in the module designer. This provides the ability to reduce the visible surface of a domain model effectively hiding classes and properties that are not required. UI-related functional complexity can be hidden using the technique above in (2) or by editing the model to remove unwanted actions.

    The ability to easily modify the views on a per-project basis is also useful for hiding details that are surplus to client requirements. In addition, the view variant functionality allows the user to choose between simplified and more complex views where both might be required.

  • 4. New modules should integrate seamlessly with the existing ones.

    Since the base platform does not rely on an external EAS system, seamless integration can be guaranteed. XAF services such as presentation layer and reporting ensure a consistency of user experience across existing and new modules.

  • 5. The system should be able to target multiple databases.

    XPO targets a sufficiently broad range of databases to fit most client scenarios.

  • 6. There should be no arbitrary limitation on what functionality can be implemented.

    One of the biggest risks associated with adopting a framework is that its architecture may limit what features can be implemented. Furthermore, it is often not easy to assess what limitations may be encountered in the relatively small amount of time usually available to evaluate a high learning curve product such as XAF.

    Since XAF allows the developer to incorporate standard win / web forms (and pages) into the target application and the data layer is XPO, there is no theoretical limit to either the UI or the processes that a XAF application can accommodate. Clearly, the further a target application is from what might be considered a typical data-centric LOB application, the less return will be realised but then no one is suggesting that XAF be used to create a spreadsheet application.

    Below are images from a module that includes a specialised UI and integration with Mappoint. The use case covers a small fleet delivery scheduling activity. Points to note are that XAF does not provide native support for scheduler custom draw or drag and drop and the integration with Mappoint includes two-way selection synchronisation and live updating. Also, the use case is dual monitor aware and automatically locates the mapping window on a second monitor if available.

    Unscheduled sales orders can be dragged onto the vehicle delivery schedule as required.

    Pushpin size and shape reflect order / shipment status and hovering over one provides the user with a summary of the pertinent details of the related document.

    Integration with Mappoint allows the user to view and sanity check vehicle routes and provide drivers with routing information if required.

    The following example image demonstrates integration with TAPI with the ability to dial out and answer / "pop" incoming client details. Note the call popup is a normal WinForms window.

    Incoming calls are resolved to the entity owning the incoming caller id and the user can click the call popup to open the detail view associated with that entity.

    This final example demonstrates integration with a rapid addressing package.

    If rapid addressing is included then all postcode entry editors automatically support rapid addressing via any integrated addressing provider.

    Note that XAF's ability to add the above modules by simply including the assemblies add configuring the application to load then automatically provides an easy-to-use plug in mechanism that makes deployment straightforward.

  • 7. Third party tools should be fully supported and from a reputable supplier.

    I think I have to say that XAF meets this requirement!

  • 8. Final client systems need to be comparable to competitive EAS applications in terms of cost, functionality and usability.

    XAF provides a royalty-free deployment license so there is no framework-related variable cost to factor into the selling price.

    There are certain usability aspects and functional elements that are essential in a LOB application / EAS that XAF provides out-of-the box. The user experience that XAF / DXperience provide is reasonably up-to-date and well known / easily learnt by new users. The flexibility afforded by the UI customisation features exceeds most users' expectations. The built-in security system is adequate for most scenarios. The included scheduling capabilities and end-user report designer are high-level features that are expected in an EAS and not necessarily trivial to integrate tightly from scratch. All in all, XAF provides a set of services for these types of application that would otherwise require significant cost and time to implement and maintain.

    Below are examples of UI customisation and end-user report designer functionality that may be included without code.

    The XtraLayout Control (and XtraGrid) customisation dialogs are fully integrated with the XAF model.

    The above applies to the report designer as well.

    It is worth noting that, as pointed out by Ray in a recent blog, the XtraGrid and XtraPivotGrid in conjunction with XtraPrinting Library provide pretty powerful but, above all, easy to use end-user report tools for non-power users.

  • 9. An initial version of the system was required within 8 months to meet immediate client demand.

    Two aspects of XAF were particularly helpful in meeting this constraint. Firstly, the out-of-the box services mentioned above saved a large amount of development time. Secondly, XAF's excellent prototyping ability – create domain classes, tidy up the auto-generated UI and demonstrate – was instrumental in being able to develop efficiently.

  • 10. Up-front and on-going development costs should be minimised without compromising quality

    As (9) above outlines key areas where up-front cost savings were made. In terms of on-going savings, the benefits of XAF include the following:

    • - Since Developer Express are continuously upgrading and extending XAF, much of the development costs of keeping the framework integrated with DXperience suite releases and migrating to next generation UI's should be saved.
    • - As new value-add features such as the planned integration with pivot grid and support for KPI's are added, these become available to deploy as potentially chargeable additions to client systems.

    It is also worth noting that the XAF architecture is designed to allow built-in functionality to be altered / extended where necessary, saving the effort of “reinventing the wheel”. An example of this was the ability to use a custom UI strategy that allows TAPI screen popping by removing window modality.

Summary

In the interests of balance and expectation management (and before this case study begins to sound like a Developer Express plant!), I would draw your attention to a few areas of XAF that I believe require more work to meet common requirements and to bring them up to the standard of the remainder of the product:

  • View layout (equivalent to form design) could be more efficient.
  • The web UI is feels less responsive and is less fully featured than the win UI. That said, XAF generates usable web applications, but in contexts where response time is a critical factor, it may struggle to comply.
  • The report design environment has a few limitations that require some effort to work around.
  • There is no support for environments where there is a requirement for an active middle tier between client and database (i.e. where the middle tier implements custom processing). This is primarily an XPO limitation. Note however that XPO will support simple distributed scenarios in which a client talks to a remote passive middle tier via technologies such as remoting, WCF, RemObjects etc.
  • The learning curve is quite steep and long and would benefit from a comprehensive set of samples / tutorials and, perhaps, a more realistic and therefore convincing demonstration application.

To summarise, if you are in the market for a fully-featured application framework from a leading vendor that targets data-centric win and web UI's and you would rather avoid expending time and money developing and maintaining your own framework then XAF may well represent an excellent addition to your tool set.

Jascha Gordon,
Line of Business Systems, Ltd.