IT Architects™ Application Architecture

The Application Architecture represents all the applications and systems that support the business processes of an organization. This includes the interfaces and middleware to support the inter-connectivity of these applications and systems. The IT Architects™ Application Architecture framework guides organizations in understanding how their application and system functions map to business process requirements; and how these applications/systems support processing across business functional domains. For example, a customer service rep enters a sales order delivery into a Customer Order System. This transaction then sends sales order delivery data to a Warehouse Management System through an interface. Warehouse staff then pick, pack and ship the product before they close out the sales order delivery in the Warehouse Management System. Once the sales order delivery is closed out, a confirmation is sent back to the Order Entry System to change the status of the delivery as closed.

In this example, a customer order transaction is sourced in the Order Handling functional domain where the customer order is accepted, verified and recorded by the customer service rep. The order data is then sent to a Materials Management functional domain where the order is filled, shipped and closed out by warehouse staff. A confirmation sent back to the Order Handling domain informs sales staff that the order has been closed out so that subsequent accounting activities can be performed. The Customer Order System and Warehouse Management System support the work activities or end-to-end business processes for completing an order across these functional boundaries or domains, namely Order Handling and Materials Management.

How well these systems support these corss-functional business processes with all their gaps and inefficiencies, and the blueprint to optimize these systems to support the business processes can be determined by a well-defined Application Architecture. This Application Architecture must provide a holistic view of the inter-dependencies of applications and their support of business processes across the enterprise.

 

Although an Application Architecture seems to be a physical specification describing how these applications and systems work together, the requirements of a target physical specification defining application/system functionality start with an understanding of the underlying business processes and how those processes span the various physical boundaries. In other words, we need to figure out what business processes and related activities will be performed by what application software, databases, servers, etc.

An Application Architecture reveals a system’s dependencies on other systems or their dependencies on the system. For example, a system may interact with a credit-card processing service via the Internet, access data from a legacy relational database, or produce an XML data structure for another internal application. Network Diagrams and UML Deployment Diagrams are very useful for identifying these dependencies, as are process-oriented models such as Workflow Diagrams, UML Activity Diagrams, and Data Flow Diagrams. The implication is that these dependencies indicate the potential need to formalize Contract Models between the system team, and the owners of the systems that it shares dependencies with. This will ensure a cohesive and well-managed integrated application environment.

The requirement for interfaces between applications (A2A) and those with outside companies (B2B) are changing the appearance and substance of corporate systems. The appeal of languages such as XML is being able to meld business processes with application data, eclipsing existing technologies such as EDI and extended intranets. Languages such as XML are poised to affect just about everything corporate IT does – from E-commerce applications to legacy data.

The Application Architecture representing the connectivity between different applications and systems today is based on a fundamental mechanism for the automated exchange of data and the processes that act on that data. This type of data transformation mechanisms go beyond operating environments, transport protocols, and the arcane barriers of the applications to present true inter-application communication.