Using a Common Architecture for the Services Product Line

I introduced the data services product line in earlier posts here and here. As  a follow up I wanted to set the context for a common architecture for this product line. The idea is to have all products in a services product line need to share the same underlying architecture. The common architecture enables the development of a set of common software components and also facilitates variation management, product configuration, and consistent behavior across all the services.

The architecture typically consists of both domain agnostic technical assets and domain specific assets. The domain agnostic assts includes logging, error handling, auditing, metrics, and legacy service invocation modules. The domain specific assets includes data assets, relationships, domain events, and business process workflow components that get triggered based on rules. The common architecture also provides components to integrate with the workflow engine, initialize business processes, as well as provide approval, routing, and escalation steps for any kind of enterprise data entity.

The architecture needs to be reviewed to ensure that it meets the product line’s non-functional requirements such as availability, scalability, and runtime performance.  For instance, supporting high availability can be tricky when data repositories undergo scheduled maintenance on a periodic basis. Scalability is also a key quality attribute that needs to be addressed by the architecture where the need for connection pools, thread pools, and messaging session pools are extensively utilized. Additionally, the architecture can provide caching capabilities for most accessed data records as well as integrate with a lightweight rules engine for fast and efficient rule execution.

Data visibility is another key capability that the architecture needs to address – it can do so by providing an extension point in the processing lifecycle to integrate visibility logic (e.g. filtering attributes, masking data, or utilizing a third party authentication service to validate the identity of the caller etc.).  Ability to assign priorities to jobs in the processing queue based on SLA needs is another feature that could be provided by the common architecture.

Finally, the architecture needs to support several utility features: manage connectivity to each data source, allocate dedicated processor threads based on message volume, and monitor the health of each integration point outside the data service logic. The common product line architecture can potentially address both domain agnostic & domain specific needs.

In a follow up post, I will provide more detail on each of these capabilities and how they align with an agile software reuse approach.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: