Dreaming up an enterprise application architecture

It was fathers day and I had too much to eat for my Sunday dinner. No sooner had by posterior hit the sofa than I was in a deep, noisy snooze. Fortunately for me, some combination of the lamb and mint sauce conspired to produce an interesting hallucinogenic dream state. Normal people would, in such a state, engage in wildly interesting travels. I, on the other hand, ended up in a debate about enterprise application architectures.

Herewith, the trip report:

Me: Okay guys, no expense has been spared getting you lot together around this table to advise us on our enterprise application architecture. I'm looking forward to a quick debate and some solid action points today.

All: OK.

Me: Here is the situation. There is a lot of stuff going on out there with Web Services and SOAs and ESBs and event driven architectures and model view controllers and such like. The chairman of the board is worried that it amounts to a volatile cocktail of vendor-driven hot air mixed with half cooked academic rocket fuel.

As a company, we want to have our own vision for how applications will work together in our enterprise for the next decade. We do not want to be slaves to anyone else's vision. The question you need to answer today is this. What are the key architectural tenets we should put on the table when talking with vendors? What are the key technologies we should train our people on?

Murphy: I'm way out of my intellectual depth at this table. As you all know, my job is simply to cause trouble by enforcing Murphy's Law. However, even in this exalted company, I am totally confident in asserting that an architecture is only as good as its ability to deal with failures. Networks, disks, software modules will all fail sometime. That's my law and I spend a lot of time in computer rooms enforcing it. Architecture needs to build Murphy in on day one, otherwise Murphy will get you.

Democritus: Your are indeed a formidable adversary Mr. Murphy. I agree completely with you and would add that it is important to get the decomposition correct in any IT architecture. The atomic structure of systems in terms of words like "module" and "component" and "layers" are often not cleanly delineated anywhere other than on the Powerpoint slides. This lack of true componentization at run-time (as opposed to design time) is a big problem in my opinion. It makes systems hard to debug, hard to modify and hard to understand. There is no reason these days to design things so closely coupled together. We have all of the technology required to build much more loosely coupled systems.

Heisenberg: I agree. I would add that the very concept of decomposition into fundamental units is, at least at the software level, subject to challenge. Followers of the Web Services debate will no doubt have noticed that the atomic decomposition into objects, so favored by technologies such as CORBA and DCOM, is not how Web Services work.

It seems to me that the existence or otherwise of a live business system behind its Web Services interface is irrelevant. All that is important is the external observable, effects. There might be no "objects" there at all.

All: Yes.

Heisenberg: The "O" in SOAP shows an example of the premature rush to standardization that has occurred in Web Services. Now that its obvious that Web Services will not work by getting objects to talk directly to each other, there is an element of backpedaling, not only in the acronym (which no longer stands for Simple Object Access Protocol).

All: (Assorted sniggers and snorts).

Heisenberg: I think this can also be seen in the increasing emphasis on the asynchronous, one-way nature of web service communications.

Einstein: Yes. One-way communications is vitally important. You must build two-way communications on top of one-way communications. Otherwise you are letting time dominate your architecture.

Once you add a network into the equation, once you step beyond a tightly coupled world that you have complete control over (like a LAN), you cannot cheat the laws of physics. Regardless of Moore's Law, Seattle and Dublin will always be separated by enough milliseconds to ensure that synchronous communications, so beloved by those who think in terms of objects, will bite you. Even if it didn't, Murphy is always there - like some pervasive form of dark matte - ensuring that network latency fluctuates wildly, computers go down etc.

Murphy: Yes, I will bring tears to the eyes of anyone who thinks they can architect on the basis of everything working and all bits talking to each other in synchronous lock-step. All architecture should be pessimistic, not optimistic. Design with failure in mind. It's the only way. An asynchronous approach to time ordering is critical.

Rockefeller: Let us ask ourselves why we are interconnecting computers in the first place. We are here because we are in business right. We are talking about e-business right?

All: Right.

Rockefeller: Well, business is all about exchanging value. That value exchange occurs in parallel with an exchange of documents. Shouldn't document exchange be the bedrock of an enterprise application architecture?

Murphy: Yes. I long ago intervened in the real world to ensure that postal systems would be inadequate for business use. That is why courier companies were invented. Guaranteed once and only once delivery is a "must have" for document-oriented e-business. I'd go further and say that document oriented e-business is basically what Web Services are all about, or will be, once a few more deliciously expensive mistakes have been made. The answer is staring the industry in the face and has been for 30 years. It is called reliable messaging.

Rockefeller: Yes, reliability is vital but so too is using XML technology to describe business documents. I want to see Web Services used to send real business documents to and fro. Stuff I can understand, not all that RPC, marshaled object stuff. Business documents!

Wittgenstein: I quite agree. The internal reality of computer systems have been allowed to dictate to the external realities. This has resulted in engineer level abstractions (such as objects) being the cornerstone of e-business systems.

Web Services, and their point of contact with the real world - URLs - are the key to reasserting the preeminence of the document model of business in enterprise application architectures.

It is useful to consider URLs as merely the observable reality of an otherwise unknowable internal reality. Indeed that internal reality may be an object oriented one if it suits the engineers to implement it that way. There is no conflict necessary between URLs and objects. The conflict lies in the perception that sending documents to business processes (which Web Services is all about) is directly bound to invocations of business logic.

URLs which are *not* entry points to business logic, but instead act as persistent, reliable messaging conduits for business documents are a useful way to think of Web Services.

Rockefeller: I cannot say I follow everything you just said Mr. eh...

Wittgenstein: Wittgenstein, the name is Wittgenstein.

Rockefeller: Yes, Mr. Wittgenstein. I don't follow it all but there is a guy who writes articles for ITworld called McGrath. He is always going on and on about how documents are the very essence of XML and the essence of EAI.

Wittgenstein: Never heard of him.

Me: Gentlemen, would I be right in summarizing the conversation as follows.

1. An enterprise architecture should be business document focused.

2. These business documents should be expressed in XML and expressed in purely business terms.

3. These documents should flow around business processes using reliable messaging. Reliable messaging ensures that Murphy's Law is thwarted and also provides the vital asynchronous substrate.

4. Systems should be designed from day one using an asynchronous model. If synchronous behavior is required, it should be implemented on top of the asynchronous substrate.

All: Good summary.

Me: Thank you gentlemen. Hear are your purchase order numbers, the invoice address is top left.

Join the newsletter!

Error: Please check your email address.

More about Object Oriented

Show Comments