OSF 2: What makes architecture for an OBA different?

  • Article

[OBA Solution Framework Index]

An OBA is an emerging class of business application that bridges the gap between productivity tools like MS Office, and back-office systems such as ERP and other line-of-business applications. My colleague Mike Walker discusses this in more detail in blog postings here and here - so I'm not going to talk about what an OBA is. I'll just focus on what makes architecture for an OBA different from that of traditional enterprise applications.

Most business applications fall into one of three categories today:

  1. Transactional apps (traditionally data entry such as processing orders)
  2. Collaborative apps (traditionally email, FTP, or IM)
  3. Decision Support apps (traditionally BI tools for reporting, or analytics) 

An OBA is different - you can think of this as a composite that combines elements of ALL three of these kinds of applications, and in ways that can be personalized by end users. For example an OBA might be a set of role-specific dashboards that offer document sharing and management, reports, forms, and real-time communications - all in the context of specific business functions.

Now consider a traditional 3-tier architecture for business apps:

This model works well only for the first kind of applications - the transactional ones (e.g. data entry). However it incompletely describes applications for decision support or collaboration. The problem is that it doesn't account for the differences between human workflows (e.g. people-to-people interactions) and system workflows (e.g. automation of business proceses). Human workflows involve people and roles, while system workflows involve applications and services. Human workflows are flexible and dynamic, while system workflows are prescriptive and formalized. Human workflows revolve around unstructured data and documents, while system workflows involve a different set of structured and / or transactional data.

So an architecture for an OBA needs to accomodate five separate tiers as shown below. This does not mean that all OBAs must have ALL five tiers, although this might be expected from OBAs that  deliver composition across all three types of business applications above.

So for example, the five tiers in this figure could be mapped to specific platform capabilities as follows.