Simplification patterns as a subset of migration patterns

I'm going to try to get back to architecture in this blog. 

I spent some time this afternoon going through the simplification patterns that I have identified to date with another member of the Microsoft Enterprise Architecture team, Matt Willis.  He's a very smart guy, and he was looking for patterns that could be used to describe the strategies used in migration from a present state to a future state architecture.

One of the things that became apparent fairly quickly is that there are patterns that are useful in migration, both in terms of strategy and in terms of tactics, that are not simplification patterns.  They don't, in and of themselves, yeild a simpler set of systems.  Yet, in the course of a series of projects that will, ultimately, yield a simpler system, these patterns are needed in order to shelter one system from changes in another, either in terms of integration protocols or in terms of data dependencies. 

Yet, while these patterns yield static structures, they are just as dynamic as the simplification patterns I have identified already, because many of the static structures generated as part of a migration strategy are put in place for a specific reason, and may be solely a temporary thing.

Just as civil engineers will design a road improvement project to include 'temporary lanes' for traffic to flow through while a permanent lane is being constructed or paved, architects may have to move capabilities into temporary systems, or in less-than-final data pathways, to allow for one system to change independently of another.

One example is a contracts system that I work with.  It has a very stable and well-put-together database that captures the rules for composing contracts as well as handling aspects such as formatting, red-lining, versioning, assembly, approval, activation, and document life-cycle.  The front end, however, is an aging VB6 client-server app that isn't too amenable to adding capabilities. 

Another team needs a contract system, and they want it to be web based.  I want to end up with one system, not two.  Now, the easy thing would be to give the source code to the legacy system over to the other team and walk away.  They build what they want, and we are done.  However, we will go from having one system to having two... hardly a good stroke for overall IT simplification.  On the other hand, there is a good strategy here.  By moving the second business stream to the same tool, I can improve the tool to be able to handle both business streams.  Also, if I want to replace the tool with a commercial package, including Office 12's document lifecycle capabilities, I will end up killing two birds with one stone.

So short term, we will copy the database to another server, and allow the other team to build their own web interface.  At this point, we will have two systems.  We will then, as a step 2, migrate the data and additional functions to the web-based version and kill off the older version.  There are two patterns here.  The first is to extend the original tool to add new capabilities, and the second is to see two overlapping systems and to replace them with one.  I have names for both patterns.  (Build to Suit, and Marry Up).  However, it is the two-step process that produces the resulting simplification. 

That process is itself a pattern.  It is not tactical, like Build to Suit, or Marry Up.  It is a strategy pattern.  It says "combine streams onto a tool by allowing the tool to be extended for the second team, and then to onboard the first team to the extended tool, rather than extending in place."  Implementing this strategy an be done using the two tactical patterns above.  However, those tactical patterns can be used in other situations as well.

This changes things for me.  My article on simplification patterns now expands to cover the notions of migration strategy patterns, capability simplification patterns, and dependency simplification patterns.

I still haven't described the patterns in a public paper.  I'm hopeful I'll get something up in a few days. 

I just wanted to get back to some sense of life and, for me, what passes for normalicy.  I'll dedicate the book to the leader of the band.