Wyde Deployment Solutions

 

 

Philosophy -- Build Once, Deploy Anywhere

The fundamental Wyde application development philosophy is that applications are built independently of the technology and architecture on which they run.  In today's fast-changing world, it makes no sense to lock in one given technology before an application is finished.  Instead, Wyde suggest that applications be built in e-WAM completely independently of how they will run when deployed.  Only once the application is completely modeled and tested in this technology-neutral environment, do the development and management teams decide which technological solution makes business sense at the time of deployment.  Then, the integration teams use e-WAM's automatic production tools to produce their applications for the chosen technology and architecture.

Using this philosophy, a company's Active Models built with e-WAM are easily portable from one technology to another.  A company thus preserves development investment even as technical and business needs evolve.

 

Preparation for Deployment

To be deployed, the integration and technical teams must prepare their application for the chosen target environment.  There are several phases to this step, and e-WAM contains seamlessly integrated tools for each.

Phase Description e-WAM Tools
Data base mapping Mapping the application business classes to the chosen relational data base tables for optimum efficiency
  • Data Base Definition Tool
  • Data Base Schema Mapping Tool
Code production Producing the application's business rules as executable code
  • C++ Producer Tool
  • Java Producer Tool
Optimization Fine-tuning the application to optimize execution efficiency
  • Code Analyzer
  • Code Profiler
  • Data Base Access Analyzer
  • Data Base Tracer
  • Memory Viewer
  • Meta Model Browser
  • Object Oriented Debugger
Integration Building versioned deliveries of sub-sets of an application and arranging them in consistent configurations
  • Configuration Management Tool
Migration Migrating legacy data from the old application to the new application
  • Data Migration Tool
  • Versioning Motor

 

Deployment Architectures

There can be no one-size-fits-all approach to deploying today's applications.  Each business situation needs to be studied, and the best technological solution needs to be determined.  Here are some examples relating to an Insurance Application, and the corresponding architectural decisions that can be deduced.

Case Criteria Best Adapted Architecture
Insurance Product Insurance products contain many parameters, and they are generally manipulated by relatively few actuaries at a company.  A rich, Windows-like interface is best suited to presenting lots of data, and the users will most likely be linked to a common data base at their headquarters. Rich client application running in a standard client/server architecture
In-house Insurance Call Center Insurance contracts are complex and have many parameters.  The call center employees are unlikely to be at the company's headquarters, and they may even be at several different locations. Rich interface in a light client architecture where the client machines can be configured
External Insurance Call Center Because the call center is an external company, the insurance company cannot impose a technical solution on the call center employees. Rich interface in a light client architecture where the client machines need not be configured
Insurance Client An insurance client should be presented with relatively little data, and a simple HTML-like interface is thus appropriate.  The clients will be connecting through the Internet. Browser light client using HTML (XML/XSL) interface
Collaboration with Other Company An insurance company might grant to another company or division certain limited information about their products, clients, contracts, ....  The other companies or divisions might have completely different technical architectures. A web-services solution running on a standard application server

In the above example, the same business concepts (notably insurance contracts, products, clients, ...) are being manipulated, and the same business rules are being applied.  A common business application is built using the e-WAM tool.  However, each situation requires a different deployment architecture.  Wyde supports a variety of architectures to correspond to such varied needs.

 

Deployment Technologies

Besides the architecture, there is the question of technology.  Wyde supports today's standard technologies.

If, for business reasons, a company switches from Windows to Sun, there's no problem -- just produce the application for the new operating system.  Similarly, if a new version of a data base proves more efficient, it is a piece of cake to produce the application for that new data base. 

Furthermore, due to the modular nature of the Wyde tools, these lists are guaranteed to evolve as new standards emerge in the fast-paced world of technology.  Therefore, applications built today with e-WAM will be deployable on the architectures and technologies of tomorrow!

 

Coexistence

As can be seen from the above example, each business case has its own criteria and its own solution best suited to that criteria.  A huge advantage of the Wyde philosophy is that a given application can be deployed with N coexisting technical solutions.  Technical teams model their business concepts and business processes once in e-WAM, they give appropriate interfaces to these entities according to the various business cases, and they produce their application automatically for the given architecture(s).

Applications are built and maintained once, and deployed N times!  Thus, companies save huge development expenses and greatly increase their ROI!