In the first step towards implementing a BizTalk 2009 environment, from development through to live, I put forward a proposal that detailed the options available, as well as the costs and benefits associated with these options, to allow an informed discusion to take place with the business drivers and budget holders of the project. This ultimately lead to a decision being made to implement an initial BizTalk Server 2009 environment using the Standard Edition of the product.
It is my hope that in the long term, as projects require it and allow, we will be looking to implement my ideal recommendation of a multi-server enterprise level environment, but given the differences in cost and the likely initial work load for the environment this was not something that I could fully recommend at this time. However, it must be noted that this decision was made in full awareness of the limits of the standard edition, and the business drivers of this project were made fully aware of the risks associated with running without the failover capabilities of the enterprise edition.
When considering the creation of this new BizTalk Server 2009 environment, I have also recommended the creation of the following pre-production environments:
Usage
Environment
Development
Development of solutions; Unit testing against technical specifications; Initial load testing; Testing of deployment packages;
Visual Studio; BizTalk; SQL; Client PCs/Laptops; Server environment similar to Live implementation;
Test
Testing of Solutions against business and technical requirements;
BizTalk; SQL; Server environment similar to Live implementation;
Pseudo-Live
As Live environment to allow testing against Live implementation; Acts as back-up hardware in case of failure of Live environment;
BizTalk; SQL; Server environment identical to Live implementation;
The creation of these differing environments allows for the separation of the various stages of the development cycle.
The development environment is for use when actively developing a solution, it is a potentially volatile environment whose state at any given time can not be guaranteed. It allows developers to carry out initial tests in an environment that is similar to the live environment and also provides an area for the testing of deployment packages prior to any release to the test environment.
The test environment is intended to be a semi-volatile environment that is similar to the live environment. It will change periodically through the development of a solution (or solutions) but should be otherwise stable. It allows for the continued testing of a solution against requirements without the worry that the environment is being actively changed by any ongoing development. This separation of development and test is crucial in ensuring the quality and control of the tested solution.
The pseudo-live environment should be considered to be an almost static environment. It should mimic the live environment and can act as back up hardware in the case of live failure. This environment acts as an area to allow for “as live” testing, where the performance and behaviour of the live solutions can be replicated. There should be relatively few changes to this environment, with software releases limited to “release candidate” level releases prior to going live.
Whereas the pseudo-live environment should always mimic the live environment, to save on costs the development and test servers could be implemented on lower specification hardware. Consideration can also be given to the use of a virtual server environment to further reduce hardware costs in the development and test environments, indeed this virtual approach can also be extended to pseudo-live and live assuming the underlying technology is in place.
Although there is no requirement for the development and test server environments to be identical to live, the overriding architecture implemented should be the same as in live and an understanding must be gained of the performance differences to be expected across the different environments.
