Last Friday we defined the “What” and “Why” of our new Active Integration world.

So why don’t we start getting straight into the “How” and pick out some User Interface for each of our application classes?

Not so fast, let’s get some Solid Architecture principles in place before we start chasing up that pretty road Toto.

The core issue is that most development teams, when faced with some user requirement, immediately start thinking about the Presentation Mechanism they will use to satisfy that requirement. They will think about the best approach to address some new range of users.

  • Should it be a Rich Client or Web based Application for the Expert users?
  • Is a Web Portlet applicable for Tactical / Managerial Users or for the Opportunistic Call Centre users?
  • Should I use Web services or Services Oriented Architecture (SOA) approach to integrate between disparate systems or with physical devices?
  • How am I going to incorporate Email, Instant Messaging, Messaging, etc?

Presentation Veneers for Active Integration Applications

However, these user oriented presentation veneers (Web, Portlet and SOA) plus the message based mechanisms for interaction with the user or other systems (Email, IM and Messaging) are incremental to the core logic of the business process. Also in a well architected system the underlying data model is typically distinct from the presentation veneer. Therefore the User Interface or Presentation Veneer is NOT where you should start your architectural journey.

Architecture First

So we start with the “What” and “Why” of the Solid Architecture Principles we need to work within if we are going to successfully create Active Integration Applications.

  • Layered Architecture: We start with the concept of a layered architecture where we can explicitly identify, develop and manage code that is used in the User Interface layer or the Business Service Layer or the Data Access Layer.

  • Isolation: This is used to help separate the layers in order to make the development and management process easier. To do this we define Interfaces within our code and then provide Implementations against these. We can test individual layers by exercising the implementations of a given interface.
  • Cohesion: This is another aspect of the Layered Architecture whereby we keep all the element of a given layer (and the associated development approach) together. This could be in terms of code packages or namespaces as well as addressing the differing needs of the groups that develop the different layers of the application.
  • Data Access Object pattern: As these will be Database oriented applications we need to employ the Data Access Object (DAO) design pattern (so no SQL in the middle of Web pages please).
  • Loose Coupling and Stateless Operation: While this is a Presentation Veneer driven issue, in that it relates to Stateless Web and Web service applications, it is architecturally significant concept and so makes our architecture list right from the beginning.

All pretty standard, best practices for Enterprise Application development as represented by our Layered Architecture Diagram.

Layered Architecture


An alternative way to draw this Layered Architecture is in its vertical or stack based form as it is sometimes easier visualize the layers this way.

Vertical Architecture Stack

Note we added an Infrastructure element to indicate where something beyond our code might be involved. Infrastructure is one of those things you should only need to build once, so long as you build it correctly. If you can achieve this you will be able Leverage it, Extend it and Reuse it across a wide range of projects. Infrastructure comes in many forms including common code elements that you use in every project to achieve some task (logging, data access, etc) or the build environment that you use to consistently create your application. It is something that you typically want a small group of experts to develop, manage, and ultimately integrate or weave into the fabric of your development organization, so just like the Electricity or Gas Supply within a city “it is just there”.

Workload Management

As we are developing applications that will be part of an Active Data Warehouse it is appropriate to think about Active Workload Management right up front. This means knowing something about the Context of each application and its queries.

Why are we interested in Application or Query Context, well consider the other parameters that go with our new ADW users, namely Query Complexity and Query Performance.
Workload Management

The Expert user wants a responsive application while they are in Online Mode but understands that when they hit the big GO button that Query Complexity is going to go up as will response times. They may not even wait for a response but expect an email when the job is done. As we walk along the graph Tactical user applications might periodically issue complex monitoring queries (under the covers) with longer response times but when something goes wrong their user will expect higher prioritization as they drill down to identify and solve the problem. In the world of the Opportunistic users and the Devices there is no time like the present, sub second response times to simple queries are required. For An Active Data Warehouse to manage all of these different workloads it needs to know something about what is going on with the Applications that are issuing all of these queries. Remember not all Queries are created equal in this new ADW world.

More “What” & “Why” than “How”

So really this was more “What” and “Why” than the “How” promised last week. Sorry Toto but that is the way it has to be if we are going to make it down this road.

In the next Friday Night Project we will set out the outline for the Teradata Sample Application (TZA-Insurance) that we are going to build (including explaining why it is called TZA). There might even be some Java code and a database table definition.