Solution Architecture: Loose Coupling with CAB
The superiority of rich client applications over browser-based applications for dedicated users has been proven time and again. I once did a study for a health care client in which I calculated that every extra mouse click in a user interface, when multiplied by the number of PCs in the enterprise and the frequency of their usage, cost the client $125,000 per year in extra employee time. Every. Single. Click. (Bang! just went a third of a million dollars in those last three words.) So optimizing the user interface is not optional for an industrial-strength line-of-business application.
Even more important than lowering this constant friction, a better user interface lowers the chance of a catastrophic error. Consider the case of a hospital system, where a doctor wants to view information about a specific patient. An individual patient's data is probably scattered in separate silos—the pharmacy system, the X-ray system, the surgery scheduling system, etc. Each of these has its own data, its own storage and retrieval system, its own user application, its own jealously guarded fiefdom. The doctor has to use a separate application to access each silo, according to each application's rules, with little or no coordination among them, using his own brain to string together these separate pieces of information into his own mental context describing one specific patient. At best, this system consumes time and mental energy that the doctor would rather use for thinking about what's wrong with the patient and how to fix it. At worst, it leads to catastrophic errors, as you can see about to happen in Figure 1-1. Possibly a cut or paste operation failed and the doctor didn't notice. ("Oops. Dang. Sorry. Do you want us to try to sew that leg back on?")
The doctor needs a rich client application that ties together data from all of these separate silos and presents it in a coherent whole, organized and optimized according to the doctor's own thought processes rather than the internal implementations produced by the back-end silo owners. The sample program shown in Figure 1-2, from Rolling Thunder Hospital ("We help the blind to walk and the lame to see"), illustrates these principles. The user selects a patient from the left side of the screen, and the patient's details, such as sex and date of birth, appear in that panel, reassuring the doctor that he's selected the right patient. Each data silo is represented in a tab on the right side of the screen. Each tab automatically knows which patient the doctor selected and automatically displays the data from its own silo that describes the current patient. The doctor/user sees a coherent whole. He doesn't waste time or mental energy switching between applications and having to memorize the behavior, often contradictory, of all the separate applications. And the sort of error that he made in the previous example is much harder (not impossible, nothing's impossible that involves human error, but hardER) to make than it was before. The world is a better place. That's what we need.
OK, that's the sort of application that we need to produce. From a software design standpoint, what do we need to accomplish it?
From a user standpoint, the requirements are relatively easy to state. They are
Common and consistent user interfaces, reducing mistakes and their costs, which can be extremely high in medical and financial applications. A consistent user interface also reduces end-user training needs and support calls, and increases user throughput. Automatic sharing of data between application parts, removing the need for manual copy-and-paste techniques, improving throughput and reducing errors. You want users thinking about their business logic ("That sounds like a lot of morphine. Maybe I'd better double-check") rather than the application ("Dang, what's the key combo again?").
An architectural team will want
A consistent and predictable way of developing, packaging, rolling out, and updating business components to enforce architectural standards independent of business logic.
A way to scale design techniques and guidance enterprise-wide, hence multiplying the benefits of expensive specialists.
Those crazy programmer geeks will appreciate
A framework that hides complexity and boosts productivity.
The abstraction and separation of concerns, meaning that developers can focus solely on business logic or user interface (UI) design or infrastructure services without requiring knowledge of other parts of the overall application.
Operations teams, the people charged with deploying, administering, and supporting applications, often feel that they get the short end. To some extent, this feeling is justified. Programmers don't like thinking about that kind of stuff because to them it isn't fun. But as the combat infantryman always says, "You're just as dead." Money spent on operations staff is just as spent; errors and downtime caused by operations issues are just as erroneous and just as down as those caused by programming bugs. Like losing weight or getting exercise or having money left in your wallet at the end of the month, operational efficiency is a very good thing, and it doesn't just happen on its own. You have to go out and make it happen; otherwise, it won't.
Operations teams would like
The consolidation of shell applications resulting in the need for only one executable file to be shipped, reducing the number of potential common language runtime (CLR) versioning issues.
Easier rollout of common business elements and modules, resulting in consistent configuration management and instrumentation implementations across a suite of applications.
A pluggable architecture that enables basic services (such as authentication and catalog provisioning) to be driven from server-side infrastructures, which, in turn, enables central management of many smart client applications at a time.
Now that we see what the application needs, what sort of design would best produce it? There's an awful lot of stuff going on inside it. The main screen contains multiple collaborating parts, each one addressing a specific aspect of a business process: patient selection, X-rays, surgery scheduling, and so on. We need the parts to be integrated visually to provide a consistent user experience, and we need to share information with each other to some extent.
Ten years ago, the classic design would have been to build a monolithic application in which every part knew about every other part at compile time. But that design doesn't work well in today's enterprise, because the difficulty of developmentincreases exponentially as program size increases. The application quickly gets so complicated that no one can keep track of all the side effects and back channels, and it becomes unmaintainable, unextendable, and unusable. Microsoft Office is the classic example of a complex monolithic application.
Instead, it would be better to separate the parts of the program and reduce their dependencies on each other to a minimum. They'd be developed by different teams. Since each part knows less about the other parts, the side effects would be minimized, and the development effort would approach linearity to size of the program. The parts would interact independently with their own back-end systems and could be independently versioned, deployed, and updated.
Consider the evolution of program design in the past 30 or so years. We went from GoTo statements to functions and then from functions to objects. With each step, we knew less about each piece of the program so that we could effectively deal with more pieces. We've gone about as far as we can go with tightly coupled objects, and we now need to take the next step.
联系客服
