October, 2008

Application Integration Views

The project that I’m working on currently, is deploying a solution that makes use of no less than 7 integration methods. This time I cannot provide examples as the solution is confidential. I developed 7 different views of the integration using exactly the same basic diagram that depicts the various components of the solution. Each view however only shows the integration paths that use that specific method, e.g. MQ Messaging paths are shown seperately, so is the integration using SOAP. From an MQ point of view this is useful for the analyst who is responsible for MQ deployment and the maintenance team who looks after MQ in Production.

Application Integration Methods

Standards such as COM/DCOM, CORBA, EJB (Enterprise Java Beans),
and XML work to assure that applications can communicate easily.
Components written to the same standard can interoperate, but mixing
these technologies results in an environment that requires another level
of integration (usually more adapters). Microsoft’s COM allows two
applications running on the same computer to communicate easily, but
CORBA and EJB are better suited for applications operating on different
computers. While CORBA is a messaging specification, products that
implement it (object request brokers, such as BEA’s MessageQ and
IBM’s MQSeries) are not. Some variants of the standard may be more
difficult to implement than others, and most do not communicate freely
with others.

Application Integration Introduction

Modern applications, when deployed in a distributed environment, rely heavily on integration methods to communicate to databases and user-facing frontends. Large organisations typically have application landscapes that span various platforms and environments, especially where legacy applications are still being maintained. The application architecture of an end-to-end solution can therefore include some views of integration methods.

Application Views - Layered

Here’s an example of an Application Architecture view that will actually be of value to a variety of audiences. It features the different levels of a “top-to-bottom” solution along the lines of the EA framework that I shared in earlier blogs. At the top the users and roleplayers are shown as well as the channels they use to interact with the solution. On the next layer the business processes are shown that happen to be automated by this solution. The next level down shows the components or application “services” that make up the solution and the bottom ones show the infrastructure services and hardware that support the solution.
pvb-layered-view-nonames.pdf

Application Views - Decision Makers

Management and Architects are likely to require Application Architecture views that show an application’s lifecycle (is it ageing, or when is a review required of its continued suitability), costs of supporting and running it and the dependencies on 3rd parties such as a vendor for support and future releases. Views that compare an application or application suite to other products available, or scenario’s to redevelop it in-house if it is nearing end-of-life, will also be of value to audiences that operate on a decision-making level in the organisation.

Application Views - BAs

We’re still on the topic of Application Architectures and the various views that one can develop for this domain of Enterprise Architecture. Different views will be of value to different audiences (e.g. Management, Business Analysts, Solution Analysts, Developers, Architects, etc.). For a BA it’s likely that views are required that show an application’s business functions, the processes it supports and instructions on how to operate the application.

Application Portfolio Views: Conformance 2

The attached graph is the 2nd of 2 examples that show how an organisation can measure its application portfolio against a set of standards. In these examples 10 standards are each measured with a simple score out of 100. This graph shows the 10 standards and the footprint across 20 applications for these standards.

Application Portfolio Views: Conformance 1

An organisation may wish to see some concolidated views of how their applications measure up to standards. In the next 2 posts I will show 2 graphs that I helped develop for an organisation. These 2 examples were created using a spreadsheet that scores 10 criteria for 20 applications on a percentage scale. Graph 1 attached here shows the “before” and “current” footprints for the 10 questions across the 20 applications.

Another Application Definition

While collecting some views of Application Architectures, I came across yet another way of defining an application. I liked it, as it aligns with my reasoning that an application is simply the automation of a business function using technology.

An analyst named Tom Richards wrote the following in an Enterprise Application Integration paper:

“A business process is not just a systems topic; it is also a business management
and human performance topic. It is a series of activities,
grouped into three areas, that convert business inputs into outputs:
• Inputs – data, outputs from another linked process, and/or an event
(sometimes referred to as a stimulus) that initiates the process and/
or provides the information needed to perform a task;
• Work – rules and workflow that process the inputs, including skill
sets, knowledge, motivation, feedback, performance standards and
consequences; and
• Outputs – the result of the process, which may include data or a
response or a link to another dependent process.
Automation performs a vital supporting role in assuring the desired outcomes
of these activities. Automating a business process allows the consistent
execution of the process; consistent application of business logic,
policy and rules; and increased, scalable capacity.”

Application Architecture Content 3

In my organisation a short document exists for each major business application. This is called the Application Architecture Document and it follows a consistent framework to address specific topics for each application: Business objectives, users that use it, business functions performed, information stores maintained, platform and tools used for development and testing, integration with other applications and the infrastructure (hardware) that it runs on. This is an adequate view for business, solution designers and architects who require an overview of an application.