Documenting architecture

How do we document the decisions we use to flush out our architecture?

One of my goals is to be able to leave my current employer and have my work continued by those that follow. I do not intend for the work to be carried out by fiat, but that the principles used to construct our enterprise architecture be understood, challenged, and when enough new information is learned, the architecture evolves.

In our current architecture we have three main platforms and I’m about to introduce a fourth. The first platform is our AS/400 system followed by our .NET 1.1 environment, our .NET 2.0 environment and our new 2008 environment.

Our AS/400 environment was the hub of our universe. It had just about every application we needed as an organization, but as we started to pull pieces out of the system, the system began to lose its position as the hub. We pulled out six major functions and we decided to pull out the last four functions and move to a Windows based infrastructure.

Our .NET 1.1 environment was grounded in quicksand with an enormously expensive, a classic clunky web application. The rumor was that it cost around one million dollars per web page developed, has a backlog of defects, and keeps 2-3 people busy full time with workarounds and fixing data that the application either can’t access or it just corrupts outright. The good news is that we were able to move the largest remaining piece from the AS/400 system. We introduced VMWare into the organization and virtualized just about everything. This caused significant overhead for our SQL Server 2000 infrastructure.

Our .NET 2.0 environment introduced publish and subscribe messaging with BizTalk 2006 at its core. We introduced a common tracing and logging strategy with the introduction of Paul Bunyan, we rolled out a new website based on a web content management system named Sitecore introduced the Microsoft Enterprise Library June 2005 and moved what we could to a new Physical x64 SQL 2005 infrastructure. Most importantly we did it for less than one million dollars per web page and without introducing a bunch of new workarounds and data corruption. Executive confidence in the IS organization improved. The last three pieces are almost implemented and the AS/400 is slated for shutoff at the end of June. We learned that as the technology improved we were now discovering process opportunities that needed to be addressed.

Right now we are in an ackward middle place. We are in the process of improving all sorts of processes. We are learning about ITIL, having some meetings and beginning to discuss what it means to us, and proceeding with a deliberate pace. We hired an Enterprise Business Analyst, who happens to be leading our implementation of the Rational Unified Process (RUP). We have a number of internally named processes specific to the update of software in production Program Change Request (PCR) and we have processes to fix data in production called Program Update Request (PUR). These processes are being evaluated, and re-implemented to meet the current organizational needs. This should keep us busy for the next few years. Maybe I’ll write more on this process stuff. It’s much harder than enterprise architecture. I get to herd cats (easy). Enterprise process improvement is more like building an ark (harder).

Office 2007, Exchange 2007, Communicator, MOSS 2007, System Center 2007, VMWare 3.x promise to be very disruptive technologies for us as we move into 2008.

Now on to our 2008 architecture. Developers really enjoy working with the Paul Bunyan product. It gives us the ability to really trace messages between servers in our organization in real time, but doesn’t really give us an efficient way to aggregate all of the messages on all servers in our environment in a single place. Windows Server 2008 will be out soon and we are beginning to make plans to migrate all of our code on to that platform as soon as it becomes available. This really gives us a solid automated deployment strategy using the web.config file to configure the web server portions of our ASP.NET configuration files. We are moving to the VMWare 3.x platform which gives us a real advantage in the types of devices we can have in our VMWare infrastructure. We are looking at ESX server’s ability to restart machines during hardware failure as an alternative to a server farm for uptime reliability. We are looking into hosting a virtual Google Mini search appliance for DR purposes and hosting a Virtual Network Load Balancers such as the ServerIron XL in a VMWare platform. VMWare has made significant increases in the performance story. With 2.5.x we were really limited to one processor, 4GB ram and 32bit processing. With 3.x the ceiling is much higher. We are now looking at moving Microsoft SQL Server 2005 back into the VMWare infrastructure and improving our Business Continuity Story. Visual Studio Code Named “Orcas” is slated for us some time in 2008. We’ve got some upgrading to do on our Team System Infrastructure.

Then comes the really fun stuff. The giant initiatives in 2008 are:
- Implement Office 2007, MOSS 2007, Communicator, VOIP and CRM
- Create composite applications using a SOA backend
- Implement System Center 2007 and integrate it with domestic and commercial applications
- Integrate TFS with Quality Center and Requisite Pro
- Leverage VMWare
- Integrate RUP, StageGate and Agile into a single view of project governance, management and execution.
- All the other stuff the business wants

Like many things this post is becomming way to long, I'll be back with more later.