Architectural Requirements for a Line-of-Business Product

I was recently asked for my views as an architect on what factors to consider when procuring a line-of-business product for an organisation. Keeping in mind that business SMEs (Subject Matter Experts) were likely to be covering the functional aspects of the product quite adequately, I came up with this list:

1. Coarse-grained business functions (e.g., underwriting, claims and reinsurance in the insurance industry) should be modular with well-defined service-based interfaces. There should be no implicit dependencies between modules (e.g., no shared tables or other knowledge of another module's internals). This will make it easier for a module to be swapped out for a better one from another source, if required. [Obviously, product vendors will fight to prevent this from happening, but the customer organisation must skew their evaluation rules in such a way that the vendor is forced to see a competitive negative as a positive.]

2. Data models of the interfaces (not the internal domain models) should conform to standards as far as possible (If a data model exists for that industry domain, that's to be preferred). The IP relating to the external data model (the universal metadata model governing the data transfer objects/XML documents) should be revealed to the customer in any case, and guaranteed to be stable across product versions, with a well-defined version strategy for service enhancements. The internal data model can remain the vendor's IP. In fact, the more opaque that is, the better. It will prevent unwitting dependencies from being built by applications external to this one. If a compact and standard vocabulary is established, it will make it much easier for other applications to integrate with this one by "learning" to speak the same language.

3. Technology platform dependencies should be minimal – commodity infrastructure is preferred (e.g., Intel, Linux, plain Java-based web servers). The product should offer choices, not constraints. Ideally, it should be able to run on any platform from mainframes to Intel-based systems, and the customer organisation should choose the most commoditised platform that will suit its needs. If the product is Java-based, it should not require an EJB container. The Spring framework is preferred. Database dependencies should be minimised (wherever possible) through an appropriate ORM layer. Again, the customer organisation should be free to choose the most commoditised database that meets their requirements.

4. Services support should include both SOAP and REST in order to support the widest variety of external service consumers (and producers). SOAP services should be true contract-first services and not automated remoting of object methods. REST services should exhibit support for enterprise requirements through simple patterns for security (SSL), reliability/idempotence, asynchronous processing with callback options, horizontal scalability through statelessness, etc.

5. Technical skills requirements should be as basic as possible (e.g., commonly available skills like Java, XML, HTML, JavaScript, etc.). There should be minimal requirement for specialised skills. Very importantly, the product should not require vendor consultancy on an ongoing basis to make modifications to extend the product's use. Extensibility of the design and flexibility of the service interface are key enablers here.

I'm sure there are other good requirements, but these should provide reasonable guidance, I think. Working through my thought process, I guess these were my guiding principles:

1. Ensure high cohesion and low coupling between functional units, keep interfaces as small as possible (this includes the shared vocabulary).
2. Be conservative in what you produce, be liberal in what you accept.
3. Aim for simplicity (but beware of expediency masquerading as simplicity).
4. Seek to use commodity building blocks as far as possible - try to source technology from competitive markets rather than from "market leaders".