March 3, 2021
Hot Topics:

Book Review: Enterprise Application Architecture

  • By Sam Huggill
  • Send Email »
  • More Articles »

We have covered a lot of material inthis book, so in this chapter I will try to pull all of the differenttopics we have discussed into a single vision of the overall system.We'll start by taking another look at the physical architecture thatwill host our applications. Now that you have actually worked throughthe coding of some objects with both data centric and user centrichalves, I think that the server farm designs we looked at earlier maymake a little more sense. While we look at the physical architecture,we will view the computers in the server farm more as softwareelements, SQL Server, MTS, IIS, rather than as hardware elements CPUs,disks, and memory.

What we'll do in this chapter is walkthrough each step that must be taken to deploy an application acrossour enterprise. Before we begin, let's take a minute to define theoutcome we expect to achieve with this deployment. We need to considerseveral issues before we can develop and deliver an application to ourusers. Of course the first thing we need to do is to handle thedevelopment of the application itself. What that means to us, usingECDOs, is that we need to:

  • Determine the application's functionality
  • Acquire the base objects necessary to deliver that functionality
  • Extend the base objects with type definitions if necessary
  • Connect the objects
  • Add the business rules
  • Handle deployment issues

I guess if you think about it, thislist shows that we have really taken the huge leap into the world ofdistributed architecture development. Most of this book, until now,has really bee about handling steps 2 through 5 in a professionalmanner. I guess I always took it for granted that if you picked up abook on Enterprise Application Architecture that you are probably amaster at determining the functionality for an application. Anyway,what we have to do now is to take a look at exactly what it means todeploy a distributed application across our architecture.

The Application Methodology

Before we go on to talk about deploymentspecifics I want to take the time to outline the life-cycle ofdeveloping applications for our enterprise.


Developing applications with data objectsis really a lot of fun when you get used to it. Of course as you haveseen, the actual code we need to write when we build an ECDO ischallenging to say the least. But, once you have built one, you can useit again and again. During the development stages, we spend a goodamount of time searching through the ECDOs that we have already built.Most applications really seem to make use of the same set of base ECDOs:

  • The Person object extended intoone or more different types of people; Doctor, Patient, Employee,Engineer, etc.
  • The Organization object.Extensions for the object include things like Company,Incorporation, and Government Agencies. As a hint about how youmight think of an Organization object, I've found that Icould use the Organization object to represent a family or acollection of Person objects.
  • The Address object Obvious
  • The Telephone Number object Obvious
  • The Email Address object Obvious

Of course there are other ones that weuse quite frequently like the Cash and Time objects, butyou get the idea. The first thing we do is to actively look for waysthat we can reuse the objects we have already built. The keyhere is to be creative. You need to learn to think about, say,the Person object as a real person. Remember that youcan always add an OTD and a Property Bag to the base object and turnthe object into anything that a real person can be. The same goes forthe Organization or any other 4-Dimensional Data Object thatyou have taken the time to build.

Only after we have exhausted the reusepossibilities do we even think about creating any new ECDOs. Usuallywe find that we do need to make a few new ones to handle some specialkind of information for an application. At this point, we STOP. Wetake time to THINK about the FUTURE, and we work hard to design thebase property set for any new ECDOs - so that we might be able toreuse them in the future.

The next step in this process is towork through the relationships between the objects. When we areworking with ECDOs that means that we need to think about Connectorobjects. In just about every application, we do need to build at leasta few Connector objects. But as we saw in the chapters on Connectorsand Veneers it is possible to package common relationships like Person Address Telephone Number Email Address into something wecall a component. This frees us up from having to develop the samekind of Connector objects over and over again. Think about how youmight design an Organization object. You know, one that managesthings like companies, agencies, and even families. Now try to thinkabout even one organization you know that doesn't have at least oneperson associated with it.

Anyway, organizations tend to havepeople. They also usually have contact information like Address Telephone Number and maybe even an Email Address. This means thatwe need to think about these things and consider the possibility thatwe might design something like an Organization component.Again, this frees us up from having to work through the relationshipproblem over and over again.

Notice what you just did! You werethinking about different kinds of organizations and theirrelationships to people.

You did not think about a table inthe database.

That is what we do during development:

  • We think about real things.
  • Then we build objects to model thosethings.
  • Once we have the objects, we thinkabout the real world connections between those things.
  • Then we build objects to model thoseconnections.
  • The last step in this process is towork through the business rules that our organization uses to managethe connections we have made possible with our data objects andtheir associated connectors.
  • We take these rules and package theminto something we call a Veneer.

This is where we do most of the work inapplication development. We write specialized business rules into atiny bit of VB project that we call a Veneer.

The Location of Development

During development, we usually copy allof the DLLs for the objects we need onto a local workstation. Duringvery early development phases, we might even use a local SQL Serverrather than our common development box. We don't normally use MTS atthis time. We try to keep things as simple as possible. Thisallows us to focus on the real problem we are left with when weare developing an application using ECDOs - the business rules in theveneer.

Notice that I said that we might use alocal SQL Server rather than the our common development box. I want youto think about all of the work we did passing Connect strings betweenall of the different spheres in our system. You didn't write one pieceof code that didn't require a Connect string. I am sorry if this wastroubling at the time, but let's think about what it means to us now. Wehave objects that are capable of creating their own tables, views, andstored procedures. This means that we can drop a few of these guys onour desktop, create a disposable local database, and hack away at thebusiness problems. This gives us the same kind of interactivedevelopment process at the application level that makes VB so powerfulat the user interface level.

Once a developer has finished, I am goingto call it understanding the problem (hacking away), then we generallytake the small step of pointing the ECDOs at the common development SQLServer box. We also take any new ECDOs or Connectors that the developerhas created and perform a standard set of tests against them. We use theObject Factory to make the ECDOs so we don't normally have problems inthis area, but these objects are reusable so we do test them before wemove them into the common development MTS/IIS servers. Once the objectsare in the common development area, they become a part of the process wetalked about earlier. In other words, we try to find reuse possibilitiesfor all of the ECDOs.

After we have moved the data store andthe objects to the common development platform, the developer continuesto work through the business rules. This step also gives the developerthe opportunity to see exactly how the ECDOs are performing across thecommon development platform, which is really just three machines that weuse to model a server farm. This allows us to catch any problems thatmight occur in this area before we get into the staging platform.


By the time an application has moved intostaging, most of the bugs, including any that might arise from operatingacross a distributed platform, have been worked out. Our stagingplatform is a perfect, but scaled down replica of our production system.You can think of it as a 'piece of pie' rather than as the whole pieusing the vision of the concentric ring server farm from Chapter 3.

Normally, the move of an 'application'from development into the staging arena is not all that difficult. Thatis because we reuse ECDOs. This means that often most of the dataobjects we need for an application have already been installed on thestaging platform. This is a blessing. It means that at least a portionof each application has been tested under staging conditions. The thingswe do have to install on the staging machines for new applications areusually just a few Connector objects across the three inner spheres, aVeneer that only exists on the User Centric sphere, and the Interface onthe IIS servers on the Presentation Sphere.

The next thing we do may seem a littlestrange, but immediately after we deploy the ASP interface on thestaging IIS machines and perform some basic tests, we bring thecustomers into the development process. We usually give one developerauthority for an application at this point and that developer works withthe users in real time. This means that every day we ask the users to"play" with the application deployed across the stagingplatform. During this time, we impress upon the users that thisapplication is theirs, and that now is the time for them to suggest anychanges, modifications, or point out any problems. Thanks to ourweb-based deployment technique, we have the ability to make changes tothe interface and have those changes on the users' desks in minutes. Ofcourse, I like things to be consistent, so we don't actually update thestaging system in real time. Instead, we try to get a list of commentsfrom the user test base each day. Then we take that list, and work outthe issues on that list on the development platform. Each night, we takeany changes we have made and tested on the development platform andimplement those changes on the staging platform.

As I said earlier, our staging platformhas been purposefully designed to model the production system. In otherwords, it has the full set of capabilities of the production systemincluding the correct positioning of the Cluster Servers. This gives usan opportunity to do things that we can't do in the development system,like perform fail-over test scenarios.

In many ways, I consider our stagingsystem a choke point for our development process. Although ourcore object team is purposefully small, the objects are made availableto a wide range of developers with a wide range of talents. The stagingplatform gives everyone of those developers a model to follow and a setof standards to meet. If the application they developed cannot exist onthe staging platform, then it will not be moved into productionuntil it can. This is not as ominous as it sounds, in actual practice,the move from development to staging is one place where all thedevelopers get to "meet" and a lot of learning takes placehere.

The staging system is not just a one-waystreet from development to production. We also perform a nightlyreplication of data from the production system back to the stagingsystem. This keeps the staging servers synchronized a day behind theproduction system in terms of the data stored in the system. That allowsus to work with not only the type of information stored in theproduction system but also to work with about the same volume ofinformation. This gives us the opportunity to do things like test theeffects of adding indexes to the database, etc. It also gives us a safeplace we can use to replicate any problems that the users of theproduction systems may have been experiencing. If we are experiencing aproblem in production, we replicate the problem on the staging machinesand "have a conversation" with the users using the stagingmachines as our medium. Once we have nailed down the bug, we hack awayat the bug on the development system, fix it. Then we move it back tostaging and test it. Only when we, and the users, have signed off on theproblem does the fix get placed into production.

You should notice that the rolloutprocess from development towards staging may be a long and drawn out,but that is by design. The staging step in process is intended toprovide a tough hurdle on the way to deployment on the productionsystem.


The deployment of an application on theproduction system really doesn't involve anything more than installingeach of the new pieces required on the proper servers and making surethat the correct connect strings are being passed to the correct dataobjects. By this time, the tables, views, and stored procedures that thenew data objects will create in the system have been tested at leasttwice. The new data objects, the Connector objects, the business rulesin the Veneer, and the user interface have undergone a thorough testingon the staging platform. Once the pieces have been installed on thecorrect servers, all we need to do to deploy an application is to givethe correct user base the permission to access the application using theEntApp object and the Person object extended as an ITCustomer.

Page 1 of 4

This article was originally published on November 20, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date