It was the start of Month Nineteen and Steve and his fellow developers were finally seeing the light at the end of the tunnel. For the past eight months, they had all been working overtime to deliver Enterprise Financials, a financial reporting application estimated to be finished in six months.

At first, the application didn't seem too difficult to do. Enterprise Financials required a single database (which was already designed) that received exports of the general ledger (which it was already doing) and provided several different groups various reports (which it already did). All that was left to do was rewrite the existing reporting so that it worked in a consistent manner. And even this didn't seem to be too difficult to do – the reporting was already entirely in several different .NET applications that just needed to be combined with consistent security, look, and navigation. Naturally, solving this problem wasn't so simple.

The main issue was that the solution envisioned ("combine applications for consistency") wasn't enterprise. Everyone knows that a *real* enterprise solution utilizes something like BizTalk. And since Enterprise Financials was to be a *real* enterprise solution, *it* was to use BizTalk. Of course, the only problem was that the architect (whose decision it was to use BizTalk) had never used BizTalk before. Neither had anyone else in the company.

Fast forward a year and a half and we're back to Steve and his fellow struggling developers. The reason that see this "light at the end of the tunnel" is because Enterprise Financials has finally been deployed. Their job now is to figure out, among many other things, how they can improve the speed of the application.

Prior to Enterprise Financials, a request for the day's transactions would take but an instant. Now, on good days, it takes a few minutes to display. A process flow might explain why ...

  1. The page builds an EnterpriseQuery object. This object has, among other attributes, an ArrayList of search criteria and a placeholder for an EnterpriseResultset.
  2. The page calls, via remoting, a serialization service that converts the object to an array of bytes
  3. The page passes the byte array, via remoting, to another service that communicates with BizTalk
  4. BizTalk deserialize the object and determines what type of sub-class it is
  5. The "Main" Orchestration in BizTalk determines what report type (Finance, Transactions, etc) it is from the QueryClass property and loads the appropriate sub-orchestration
  6. The sub-orchestration inspects the QueryType property to find what the EnterpriseQuery is trying to do so that it can decide what web service and what method on the web service it should call
  7. The sub-orchestration serializes (via the serialization service) the EnterpriseQuery, converts the byte array to Base64, and sends it to the web service
  8. The web service method decodes the object, wraps it in a DalQuery and sends it, via remoting, to the DalServer
  9. The DalServer decomposes the DalQuery and reads the ArrayList and builds the EnterpriseResultset
  10. The web service places the EnterpriseResultset in the EnterpriseQuery, serializes (via the remoting service) the object, Base64-encodes it, and returns it to BizTalk
  11. Biztalk decodes, deserializes, reserializes, and returns the object to the communication service
  12. The communication service returns the object to the web page
  13. The web page finally displays the transactions for the given date

... the developers are hoping they can fix this without having to change the architect's grand design. He's fought to keep it for the past year and has no intention of letting it go. As he says, it's the cost of enterprise.