Views in Enterprise Application Architecture

Enterprise Application Architecture (EAA) is typically the second-most mature and well-defined area of EA, after Enterprise Technology Architecture (ETA).  Makes sense, as applications are seen to be the responsibility of the IT group as much as the infrastructure.  ETA is often described/organized in terms of domains (i.e. server, middleware, network, database), while EAA is often organized by application class (back office, customer facing, operations, etc.).  However, recently, we have had several companies wondering how to establish standards for the EAA when they are essentially taking a portfolio or functional view of the application environment.

In order to address that need, I want to add one element for your consideration.  That is the notion of “platforms” – not the way it is typically used as a domain name – such as server platform, mainframe platform, etc. – which is usually a hardware-based platform designation.  What I am talking about is sometimes referred to as pattern or configuration, but I think that the term platform is best.

You could roughly define a platform as a specific, standardized set of IT components (i.e., hardware, firmware and software) that is configured to provide a specific infrastructure capability.  From a metaphor standpoint, the platform represents what you build upon – solutions are built upon platforms, but if you choose the correct platform, you don’t have to change it, just use it.  I think the argument we are trying to make is that each individual business solution (regardless of functionality) should not require their own platform, but rather a business solution should try to leverage/conform to the existing platform that best suits its processing needs.  For instance, one portal application should be built on the same “platform” (set of infrastructure components configured to provide portal capabilities) as any other.  Another example, if Home grown apps and ERPs and other packages apps want to integrate with other apps, they should use the same integration platform (ESB, EAI, message-based, etc.).

Examples of platforms:

• ERP
• Integration (ESB, EAI, message-based, etc.)
• Application Development
• Data Management
• Workstation
• Mobile or Handheld
• Collaboration
• Workflow
• Document management
• Communications
• Identification/Authentication
• Storage Management
• Portal
• ERP

Some of these platforms may be visible to the business community (handheld/mobile, ERP, collaboration) while others are more like technical platforms (storage management, security, data management) that support other platforms.  In any case, the platforms have a few characteristics that I think are important to note:

1. The components of a platform tends to cross the traditional technical domains.  For instance a platform is likely to have hardware, data management, network, middleware, and other software components that come from multiple domains.  This provides a basis for collaboration across domain teams.
2. The platform provides a cross reference between application and infrastructure views.  An application uses one or more platforms, while the platforms employ components from multiple infrastructure domains.  Again, this provides a basis of collaboration, this time between the application community and the infrastructure community.
3. The platform view tends to be more consumable by a non-technical audience.

In the end, the technology domains are useless by themselves, but once you define the platforms, now they are a goal for the technical community (infrastructure, data and application professionals alike) and consumable by the application development and integration community, as well as the basis of communicating the output/benefits of IT architecture.  Really when you think about it, this is the root of EA – providing standard adaptable platforms of components already architected to meet the enterprise’s needs upon which specific business solutions can be assembled to meet specific business needs.