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.
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.
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.
All pretty standard, best practices for Enterprise Application development as represented by our Layered Architecture Diagram.
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.
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”.
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.
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.
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.