An Innovative Application Architecture

This diagram reflects the way I tend to design a typical multi-tier architecture for transactional and operational type of thin or rich client applications.

It takes some innovative approach to go a few steps beyond three tier architecture. A few popular design patterns are still being used here such as MVC, Service Façade, Domain Model, and DTO. However the differences will make this architecture much more flexible and modular by achieving higher degree of de-coupling.

I have always advocated that one of the most critical tasks for any architects in a project is to set the appropriate boundaries among the different software pieces. From vertical perspective, we can set boundaries from function, class, package, components, services, subsystems and etc. As the boundaries go wider, the higher circle will encapsulate the lower circles. From horizontal perspective, the most popular practice among IT shops is to set the boundaries using projects, which is what this architecture tries to address and avoid.

Here is what I like to point out further:

1. The diagram takes a holistic view to package code within a business segment (Life Insurance, for instance) in side a company, not each individual project view. So there are no project names in the packages.

2. The boundaries among the packages are set using four most critical packages: business domains, business rules, business processes and data services. This is an innovative way to achieve de-coupling and modularity.

3. The Service Façade package serves as the glue like a chassis to a car to tie everything else together. In the integration type of project, this will be different, which I will address later.

4. Further more, only the Service Façade package can access to the Data Service package, NOT any other packages. The data that Business Process and Business Rule packages need will be fed by Service Façade package. This is the cleanest solution to achieve the goal that Business Processes and Business Rules are self-contained, therefore, can be easily re-used, re-deployed, and extended – another innovation here.

5. Another unusual aspect of this architecture is that the Data Service package can call Business Rule package. One of the reasons is that sometimes Data Service needs business rules to form the WHERE clause of SQL statements.

6. The data that these packages needs will be carried by the Data Transfer Object (DTO design pattern), which in turn contains one or collections of Business Domain objects.

Layered Painting SDLC Methodology

This diagram summarizes my view on SDLC methodology, which gathers my experience and thoughts, and research during these years delivering one project after the other. It is powerful, flexible and effective.

I will explain it later.

Starting Small – One Little Example

It sounds anti-intuitive: the larger and more complex a project is, the smaller and simpler pieces I usually start to tackle the project after gaining an overall and high level landscape of the project.

For instance, when I face many dispersed data stores with all kinds of technologies and challenges such as data accessibility, data quality and data redundancy, and business demands a single view of their data (among other factors), I might tend to create a centralized ODS (Operational Data Store) using MDM architecture and techniques. This is a very daunting task actually, more than it looks like on the surface.

My starting point of this endeavor will be to just create a Person table with 4 attributes (First Name, Last Name, Birth Date, and SSN) to begin with. The goal is to put all the human beings from multiple systems into this one table. Sound too easy. As a matter of fact it is not. Actually, if we can accomplish this, we will test many situations down the road. Let me explain.

First of all, finding these human beings in these systems sometimes are is obvious. Some legacy systems store these 4 attributes in more than one table/file. First name and last name could be in one place and birth date in another place, and SSN yet another place. It takes a while to identify where they are.

Secondly, some legacy systems are not that accessible from outside world. Yes, you could spend some money to put technologies such as adapters into the systems. One of the problems is that these adapters for some systems are very expensive and might not perform well for large amount of data retrieval. So we need to settle the data accessibility issues.

Thirdly, we need to figure out the data refresh frequency of the data movement. For many reasons, the real time is not feasible. Batch job is mostly used in the situation. Then we need to deal with the permutations of things like how about the job fails.

Fourthly, we need to settle the data transportation: protocol, security and etc.

Fifthly, now the data is ready to be put into the Person table. But wait a minute. These data may not be consistent. For example, for the same person, one system may use his first name as Mike, one system may use Michael. Which one will be the winner? We can say whichever the last one in is the winner. Then if the person uses our system, one time he sees his first name as Mike, the other time is Michael. Will he like it? Or we can have little rules to guard this. Or we can use business users to mandatorily pick one. The same applies to the other three. For instance, how does the system know which SSN is the right one when one person has more than one SSNs? It is more complex than the first name situation.

Sixthly, OK, after all the 5 chaos, we finally have a Person table that store clean, complete and accurate data about these 4 attribute. We know the truth of each human being. We also know at this moment that some of the systems don’s store the truth. What should we do with these systems? The natural answer to some IT folks is, well, let’s write a module to reach to these systems and automatically fix the wrong data about these 4 attribute. Sometimes the business people accept and appreciate your help; sometimes they don’t. They know there are un-intended consequences if you change the data without them to examine it. I have had this resistance more than once.

Seventhly, who will own this pretty Person table and its data? Since there are already teams that own their own systems, this Person table is new and does not belong to and originate from any single systems, it could easily become an orphan. Along the same line, who will govern the table, for one thing, to make sure it will always store the clean, complete and accurate data in the future? Some politics even could involve here.

In summary, by just tackling one table with 4 attributes, we can gain and know a lot. For instance, can we deal with all the 7 situations? If not, people will wonder that if we are not capable of even one rudimentary table with 4 attributes, are we capable of handling much more complex tables, their relationships and attributes with larger volumes? So it tests us, which is very important because IT people often feel stronger than what we actually can do. It is called “wise” when we know our true capabilities. And based on that, we can set the real expectations with our business partners, instead of disappointing them one after another, or digging around excuses, or worse, finger-pointing each other.

So starting small is not because we are timid; it is because there are many benefits by doing that. I only use one little example to illustrate how and why it is as such.