Enterprise Architecture Types

Architectural Style Transitions

This section attempts to deal with the fact that the majority of organizations are usually in a state of flux, just look around you as to how many IT projects are currently on-going. This means that any organization will typically be somewhere between the architectural extremes that have been identified above.

Transition Models

Before we investigate the different transition paths a note on transition models. A transition model is essentially a method by which we can replace one IT system with another, or even multiple IT systems with other IT systems. There are two general transition models that can be used, either ‘big bang’ or ‘gradual’.

When any IT transition takes place there are a number of softer requirements that must be taken into account before a transition path is decided upon.

  • User Training – users must be re-trained to use the new system before it is in place
  • Support model – the support team must be in place to support the new system ready for roll out
  • Keeping the lights on during the transition – a decision must be made by the business if there is a need to keep the business running whilst the transition is taking place.
  • Dual Running – in some instances the business will insist that both the old and new systems continue to run ‘side by side’ for a period of time so that outputs of the systems can be compared.
  • Existing tasks being processed (esp. long running tasks) – What is to happen to any items that are being processed when the transition starts – are we going to stop and re-start them or wait for them to complete

 

Big Bang Transition

A big bang transition is essentially an approach to transitioning IT systems that follows the steps detailed below.

  1. Stop people using the old system
  2. Back up the old system(s)
  3. Extract the data from the old system(s)
  4. Turn off the old system(s)
  5. Transform the extracted data from the old system(s) to the new system(s) format
  6. Import the transformed data into the new system(s)
  7. Turn on the new system(s)
  8. Test
  9. Let people access the new system(s)

This model works well only for a few scenarios

  1. An organization that is not concerned about significant downtime. From the steps above the system is not available from steps 1-9. In most medium to large enterprises simply extracting the information from a core database could take up to a day. Meaning the complete upgrade can take days. During this time these systems are not available and this will impact most businesses.
  2. Small organizations, this is simply because they can generally take the outage, their data set is usually smaller (which makes the outage window smaller) and also they do not have distributed offices and stores.
  3. For sub units of a large organization that can be tightly controlled. For example this may work for a small component within a ‘wild west’ architecture such as a pricing service but would not work well for a large POS terminal system for an organization with 1000 branches.

If you have an a complex organization which has multiple sites, multiple IT systems, large data sets and cannot afford large outage periods (usually counted in days) then Big Bang approaches to system transition should be discounted.

One last point about Big Bang transitions is that they are often much more complex than this, involving tens of steps not just the 9 detailed above.  Most of these steps are likely to be manual and therefore prone to error[3]. If errors occur in the sequence then you may have to roll back to the old system and re-plan the migration, roll back that step, or try and fix forward the error[4]. All of these steps will increase the outage window and cost the business.  Put simply, Big Bang transitions on anything other than the scenarios listed above is a huge risk to the business and should be avoided.

Gradual

A gradual transition is one that is designed to allow the organization to minimize the risk of transitioning to new software components. In essence it allows the business to:

  1. Keep the lights on – so the business can continue to run whilst the transition is being progressed
  2. Reduce risk – including:
    1. by migrating smaller components or capabilities at a time
    2. by migrating geographic locations at a time e.g. one branch or store at a time instead of all in one go
    3. Dual running systems to check end of month values etc.

A gradual transition is a lot harder to achieve for Monopolistic, Wild West or Bespoke systems than a big bang approach, but it is something that the New Wave architectures must be designed to allow.

2 thoughts on “Enterprise Architecture Types”

Comments are closed.